Re: [PATCH v2 2/7] dt-bindings: clock: renesas,r9a06g032-sysctrl: Add h2mode property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Krzysztof,

On Tue, Nov 22, 2022 at 9:42 AM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
> On 22/11/2022 09:25, Geert Uytterhoeven wrote:
> > On Tue, Nov 22, 2022 at 8:45 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> >> On 21/11/2022 21:46, Geert Uytterhoeven wrote:
> >>>> This does not change anything. Herve wrote:
> >>>>
> >>>>> probe some devices (USB host and probably others)
> >>>>
> >>>> Why some can be probed earlier and some not, if there are no
> >>>> dependencies? If there are dependencies, it's the same case with sysctrl
> >>>> touching the register bit and the USB controller touching it (as well
> >>>> via syscon, but that's obvious, I assume).
> >>>>
> >>>> Where is the synchronization problem?
> >>>
> >>> The h2mode bit (and probably a few other controls we haven't figured out
> >>> yet) in the sysctrl must be set before any of the USB devices is active.
> >>> Hence it's safest for the sysctrl to do this before any of the USB drivers
> >>> probes.
> >>
> >> Again, this does not differ from many, many of other devices. All of
> >> them must set something in system controller block, before they start
> >> operating (or at specific time). It's exactly the same everywhere.
> >
> > The issue here is that there are two _different drivers_ (USB host
> > and device). When both are modular, and the driver that depends on the
> > sysctrl setting is loaded second, you have a problem: the sysctrl change
> > must not be done when the first driver is already using the hardware.
> >
> > Hence the sysctrl driver should take care of it itself during early
> > initialization (it's the main clock controller, so it's a dependency
> > for all other I/O device drivers).
>
> I assumed you have there bit for the first device (which can switch
> between USB host and USB device) to choose appropriate mode. The
> bindings also expressed this - "the USBs are". Never said anything about
> dependency between these USBs.
>
> Are you saying that the mode for first device cannot be changed once the
> second device (which is only host) is started? IOW, the mode setup must
> happen before any of these devices are started?

Exactly.

> Anyway with sysctrl approach you will have dependency and you cannot
> rely on clock provider-consumer relationship to order that dependency.
> What if you make all clocks on and do not take any clocks in USB device?

Enabling the clocks does not have anything to do with this ordering.
Clock consumers that are part of the clock domain are probed after
clock providers.  If the clock is missing, that would be an incorrect
description in DTS.

> Broken dependency. What if you want to use this in a different SoC,
> where the sysctrl does not provide clocks? Broken dependency.

This is the "renesas,r9a06g032-sysctrl" DT bindings document.
It talks about this SoC implementation specifically.
This is not a random synthesizable IP Core that can appear anywhere.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux