Hi Heiko,

On 2016年01月02日 10:34, Xing Zheng wrote:

Hi Heiko,
    Thank you for your patch, I will apply and test it later.

Thanks.

quoted

在 2016年1月2日，06:10，Heiko Stübner [off-list ref] 写道：

Hi Xing,

Am Dienstag, 29. Dezember 2015, 10:34:09 schrieb Xing Zheng:

quoted

On 2015年12月29日 09:59, Yakir Yang wrote:

quoted

On 12/28/2015 08:41 PM, Heiko Stübner wrote:

quoted

Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:

quoted

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>

I tested your patch just now, it seems to work well. I will do more tests.

Thank you. :-)