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.
> 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
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
> 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
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
> 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,
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