[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <01110793-A349-4006-82A2-4489CE832B19@rock-chips.com>
Date: Sat, 2 Jan 2016 10:34:46 +0800
From: Xing Zheng <zhengxing@...k-chips.com>
To: Heiko Stübner <heiko@...ech.de>
Cc: Yakir Yang <ykk@...k-chips.com>,
Mark Rutland <mark.rutland@....com>,
devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Michael Turquette <mturquette@...libre.com>,
Kumar Gala <galak@...eaurora.org>,
Stephen Boyd <sboyd@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
Rob Herring <robh+dt@...nel.org>,
linux-arm-kernel@...ts.infradead.org, keescook@...gle.com,
linux-clk@...r.kernel.org, leozwang@...gle.com,
xing.zheng@...k-chips.com
Subject: Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock
Hi Heiko,
Thank you for your patch, I will apply and test it later.
Thanks.
> 在 2016年1月2日,06:10,Heiko Stübner <heiko@...ech.de> 写道:
>
> Hi Xing,
>
> Am Dienstag, 29. Dezember 2015, 10:34:09 schrieb Xing Zheng:
>> On 2015年12月29日 09:59, Yakir Yang wrote:
>>> On 12/28/2015 08:41 PM, Heiko Stübner wrote:
>>>> Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
>>>>> Due to referred old version TRM, there is incorrect emac clock node,
>>>>> we should fix it. The SEL_21_9 is the parent of SEL_21_4.
>>>>>
>>>>> In the emac driver, we need to refer HCLK_MAC, and because There are
>>>>> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
>>>>> GPLL, and it is unable to provide the accurate rate for mac_ref which
>>>>> need to 50MHz probability, we should let it under the APLL and are
>>>>> able to set the freq which integer multiples of 50MHz, so we add these
>>>>> emac node for reference.
>>>>
>>>> I don't really follow here. While I do understand that the emac needs
>>>> 50MHz, I
>>>> don't think using the APLL as source is helpful.
>>>>
>>>> The APLL is the main clocksource for the cpu-cores, including frequency
>>>> scaling, and while it currently only lists 816MHz as sole frequency,
>>>> you're
>>>> pretty much guaranteed to not get your correct multiple of 50MHz from
>>>> there
>>>> either. And limiting the cpu to just do 600MHz to get the mac working
>>>> sounds
>>>> pretty bad ;-) .
>>>>
>>>>
>>>> In the rk3036 cru-node the gpll gets set to 594MHz. Is there a
>>>> special reason
>>>> why it needs to be 594MHz and cannot be a round 600MHz? Because that
>>>> would
>>>> also provide your 50MHz-multiple nicely.
>>>
>>> Yes, this magic 594MHz would help to support the standard HDMI
>>> resolutions, here are the math:
>>>
>>> 1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
>>> 1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
>>> 720x480-60Hz DCLK = 27MHz = 594MHz / 22
>>>
>>> Thanks,
>>> - Yakir
>>
>> Thanks Yakir.
>>
>> Hi Heiko,
>> From the above, do you have better idea for the RK3036's emac without
>> ext-oscillator?
>
> During the last days I did play a bit with the clock framework. As I don't
> have a Kylin (or any rk3036) board, I did build a test-case with pclk_cpu on
> the rk3188 (which can be affected by the armclk if not reparented to the
> gpll), which got sucessfully adapted to get back to (or near) the originally
> requested frequency.
>
> So ideally you could roll back your mux/div split here and try the attached
> diff. In theory it should help :-) .
> As can be seen by the FIXMEs, not fully finished, but I'd like to determine if
> it fixes the issue at least.
>
>
> Heiko
> <clk-keep-req-rate.diff>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists