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