[PATCH v3 01/13] clk: sunxi: register factors clocks behind composite

Boris Brezillon b.brezillon at overkiz.com
Tue Jan 7 15:46:18 EST 2014



"Emilio López" <emilio at elopez.com.ar> a écrit :
>Hi Boris,
>
>[ Apologies if the email looks weird and for using a link; I'm not
>using my typical email client ]
>
>> I'm currently working on the sunxi NFC (Nand Flash Controller) driver
>> and I need to set the NAND clk (which is a mod0 clk type) rate.
>>
>> It seems that the composite clk fallbacks to the mux_hw's
>determine_rate
>> instead of calling the rate_hw's (or factors hw) round_rate, if
>rate_hw
>> does not implement determine_rate.
>
>That is to be expected; if you have a composite clock that has all
>fixed parents you'd not implement the determine_rate on the rate
>component but on the mux one.
>

Right, but this is not the case for mod0 
clks, is it ?

>(...)
>
>> But anyway, I think there is a drawback in the way composite clk
>> implement the determine_rate handler.
>> Mike, shouldn't we choose the best parent (using mux) fullfilling the
>> rate_hw needs ?
>
>Someone using the composite clock may not want their clocks to start
>changing parents though. I believe it's easier and better to just
>implement determine_rate as on this patch on my tree (which I haven't
>sent yet, but it's literally the next in queue.)
>

Fair enough (I did pretty much the same thing in my first attempt to fix this bug ;-))


>http://git.elopez.com.ar/linux/commits/5b4eb3ac406b9c98965714d40e8dd6da943d1ab0
>
>Let me know if that resolves your issue.

I'll try it tomorrow.

BTW, I managed to get a working NAND driver (without DMA and hw ECC).

I'll post it on the ML soon (just need to clean it up a little bit).

Best regards,

Boris

>
>Cheers,
>
>Emilio




More information about the linux-arm-kernel mailing list