Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-18 Thread Laurent Pinchart
Hi Wolfram, On Monday 18 Apr 2016 11:33:20 Wolfram Sang wrote: > > Whether we want a clock to influence its parent is policy, not hardware > > description. So IMHO it doesn't belong in DT. > > Yeah, I agree to that. > > > IMHO it's more worthwhile to convert r8a7740 to use the CPG/MSSR driver.

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-18 Thread Wolfram Sang
> Whether we want a clock to influence its parent is policy, not hardware > description. So IMHO it doesn't belong in DT. Yeah, I agree to that. > IMHO it's more worthwhile to convert r8a7740 to use the CPG/MSSR driver. > There it can be handled easily by adding a flag to the mssr_mod_clk

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-18 Thread Geert Uytterhoeven
Hi Wolfram, On Mon, Apr 18, 2016 at 10:09 AM, Wolfram Sang wrote: >> Hence I think it should be handled in the driver. > > I knew it ;) > > If we change the MSTP driver, we should do it in a generic way. MSTP > clocks which should/should not change the parent's clock rate can

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-18 Thread Wolfram Sang
> Hence I think it should be handled in the driver. I knew it ;) If we change the MSTP driver, we should do it in a generic way. MSTP clocks which should/should not change the parent's clock rate can be anywhere. My best bet so far would be encoding this in DT, because all the heuristics I

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-18 Thread Geert Uytterhoeven
Hi Wolfram, On Mon, Apr 18, 2016 at 8:46 AM, Wolfram Sang wrote: >> Can you please give more detail about this r8a7740 issue? Just >> "r8a7740 flaw" does not make me understand. > > Ah, sorry. This RFC series was merely meant as a "right direction?" > series for Geert, thus

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-18 Thread Wolfram Sang
> Can you please give more detail about this r8a7740 issue? Just > "r8a7740 flaw" does not make me understand. Ah, sorry. This RFC series was merely meant as a "right direction?" series for Geert, thus the short CC list. The full series will have better documentation. The flaw is: On r8a7740,

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-17 Thread Magnus Damm
Hi Wolfram, On Sun, Apr 17, 2016 at 9:46 PM, Wolfram Sang wrote: > Here is a less intrusive approach of handling the r8a7740 flaw when handling > SDHI clocks. Let me know what you think of it. Can you please give more detail about this r8a7740 issue? Just "r8a7740 flaw" does

[RFC 0/2] r8a7740: fix SDHI clock handling

2016-04-17 Thread Wolfram Sang
Here is a less intrusive approach of handling the r8a7740 flaw when handling SDHI clocks. Let me know what you think of it. Not tested due to no hw! Thanks, Wolfram Wolfram Sang (2): clk: renesas: r8a7740: add an "sd" clock ARM: shmobile: r8a7740: add "sd" clock and use it