Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
From: Krzysztof Kozlowski
Date: Wed Dec 09 2015 - 21:21:29 EST
On 10.12.2015 11:17, Chanwoo Choi wrote:
> On 2015ë 12ì 10ì 11:04, Krzysztof Kozlowski wrote:
>> On 10.12.2015 11:00, Chanwoo Choi wrote:
>>> On 2015ë 12ì 10ì 10:20, Krzysztof Kozlowski wrote:
>>>> On 10.12.2015 10:09, Chanwoo Choi wrote:
>>>>> On 2015ë 12ì 10ì 09:44, Krzysztof Kozlowski wrote:
>>>>>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>>>>>> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 SoC.
>>>>>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
>>>>>>> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
>>>>>>> block.
>>>>>>>
>>>>>>> Following list specifies the detailed relation between the clock and DMC block:
>>>>>>> - The source clock of DMC block : div_dmc
>>>>>>>
>>>>>>> Signed-off-by: Chanwoo Choi <cw00.choi@xxxxxxxxxxx>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos3250.dtsi | 34 ++++++++++++++++++++++++++++++++++
>>>>>>> 1 file changed, 34 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>>>>>>> index 2f30d632f1cc..7214c5e42150 100644
>>>>>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>>>>>> @@ -687,6 +687,40 @@
>>>>>>> clock-names = "ppmu";
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>> +
>>>>>>> + bus_dmc: bus_dmc {
>>>>>>> + compatible = "samsung,exynos-bus";
>>>>>>> + clocks = <&cmu_dmc CLK_DIV_DMC>;
>>>>>>> + clock-names = "bus";
>>>>>>> + operating-points-v2 = <&bus_dmc_opp_table>;
>>>>>>> + status = "disabled";
>>>>>>> + };
>>>>>>> +
>>>>>>> + bus_dmc_opp_table: opp_table1 {
>>>>>>
>>>>>> This is the firsy opp_table, right? So:
>>>>>> s/opp_table1/opp_table0/
>>>>>
>>>>> Right. It is first opp_table in exynos3250.dtsi.
>>>>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>>>>> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
>>>>
>>>> Ok
>>>>
>>>>>
>>>>>>
>>>>>>> + compatible = "operating-points-v2";
>>>>>>> + opp-shared;
>>>>>>> +
>>>>>>> + opp00 {
>>>>>>> + opp-hz = /bits/ 64 <50000000>;
>>>>>>> + opp-microvolt = <800000>;
>>>>>>> + };
>>>>>>> + opp01 {
>>>>>>> + opp-hz = /bits/ 64 <100000000>;
>>>>>>> + opp-microvolt = <800000>;
>>>>>>> + };
>>>>>>> + opp02 {
>>>>>>> + opp-hz = /bits/ 64 <134000000>;
>>>>>>> + opp-microvolt = <800000>;
>>>>>>
>>>>>> Why 134, not 133 MHz?
>>>>>
>>>>> When I used the 133000000, the source clock is changed to 100Mhz instead of 133MHz.
>>>>> I add following test result on exynos3250-rinato board.
>>>>>
>>>>> Case1.
>>>>> When I use the 134 MHz, the source clock is changed to 133MHz
>>>>> : exynos-bus soc:bus_dmc: old_freq(200000000) -> new_freq (134000000) (real: 133333334)
>>>>>
>>>>> Case2.
>>>>> When I use the 133 MHz, the source clock is changed to 100MHz
>>>>> : exynos-bus soc:bus_dmc: old_freq(200000000) -> new_freq (133000000) (real: 100000000)
>>>>
>>>> Now I remember that issue. You could use here directly 133333334 but
>>>> that also would look a little bit weird... so 134 is ok for me. Could
>>>> just add a comment that desired frequency is actually "133 MHz"?
>>>
>>> Do you prefer among following example?
>>>
>>> Example1.
>>> opp02 {
>>> /* The desired frequency is 133MHz because
>>> * clock change has the dependency on clock driver.
>>> * When set rate as 134MHz, the clock driver would
>>> * change the 133MHz actually instead of 134MHz.
>>> */
>>> opp-hz = /bits/ 64 <134000000>;
>>> opp-microvolt = <800000>;
>>> };
>>>
>>> Example2.
>>> opp02 {
>>> opp-hz = /bits/ 64 <133333334>;
>>> opp-microvolt = <800000>;
>>> };
>>
>> I would prefer the second one (133333334) but I don't have strong
>> feelings about it.
>
> If you ok, I want to maintain the original approach as following:
>
> opp02 {
> opp-hz = /bits/ 64 <134000000>;
> opp-microvolt = <800000>;
> };
OK
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/