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

[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.
> > There it can be handled easily by adding a flag to the mssr_mod_clk
> > structure.
> I see. Yet, this sounds like a core group task, or? Is there time for
> this? Maybe we can apply my "virtual sd" with a FIXME comment?

I don't think the conversion would be very difficult, if you have a bit of 
time to spare you could give it a try yourself :-)

-- 
Regards,

Laurent Pinchart

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

[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 structure.

I see. Yet, this sounds like a core group task, or? Is there time for
this? Maybe we can apply my "virtual sd" with a FIXME comment?



signature.asc
Description: PGP signature

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

[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 be
> anywhere. My best bet so far would be encoding this in DT, because all
> the heuristics I could think of seem too fragile to me. That's because I
> assume in a clock tree, anything is possible.

Whether we want a clock to influence its parent is policy, not hardware
description. So IMHO it doesn't belong in DT.

> Changing DTs having MSTP clocks is quite intrusive, though...

Indeed (regardless of the above).

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

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[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 could think of seem too fragile to me. That's because I
assume in a clock tree, anything is possible.

Changing DTs having MSTP clocks is quite intrusive, though...



signature.asc
Description: PGP signature

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

[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 the short CC list. The full series will have
> better documentation.
>
> The flaw is: On r8a7740, the MSTP clocks for SDHI have HP directly as
> their parent. With my updates, SDHI driver changes clock rates. HP clock
> shouldn't be changed since other IP cores are connected to it. So, this
> solution puts a fixed-factor (1:1) "sd" clock between HP and SDHI MSTP.

Thanks for your series!

While I don't doubt your approach will work, this "virtual sd" clock doesn't
match the hardware, so I have to object against it.

Hence I think it should be handled in the driver.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

[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, the MSTP clocks for SDHI have HP directly as
their parent. With my updates, SDHI driver changes clock rates. HP clock
shouldn't be changed since other IP cores are connected to it. So, this
solution puts a fixed-factor (1:1) "sd" clock between HP and SDHI MSTP.



signature.asc
Description: PGP signature

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

[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 not make me understand.

Also, when you are modifying or extending the DT ABI please include
information in the commit log about which data sheet version that the
DT hardware description is based on.

Thanks,

/ magnus