[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <978fb5a1-64f3-7ee6-3e98-1e31b8b6a88b@linaro.org>
Date: Tue, 22 Nov 2022 11:23:23 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Herve Codina <herve.codina@...tlin.com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Magnus Damm <magnus.damm@...il.com>,
Gareth Williams <gareth.williams.jx@...esas.com>,
linux-renesas-soc@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: [PATCH v2 2/7] dt-bindings: clock: renesas,r9a06g032-sysctrl: Add
h2mode property
On 22/11/2022 10:01, Geert Uytterhoeven wrote:
>>>>> 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.
That was the argument from Herve, that ordering is guaranteed by clocks.
> 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.
If not clocks, what else is guaranteeing the ordering? You did not
express it in DT.
Best regards,
Krzysztof
Powered by blists - more mailing lists