On 04/06/2025 13:53, Michal Wilczynski wrote:

quoted

quoted

The GPU node will depend on the AON node, which will be the sole
provider for the 'gpu-power' sequencer (based on the discussion in patch
1).

Therefore, if the AON/pwrseq driver has already completed its probe, and
devm_pwrseq_get() in the GPU driver subsequently returns -EPROBE_DEFER
(because pwrseq_get found 'no match' on the bus for 'gpu-power'), the
interpretation is that the AON driver did not register this optional
sequencer. Since AON is the only anticipated source, it implies the
sequencer won't become available later from its designated provider.

I don't understand why you made this assumption. AON could be a module
and this driver built-in. AON will likely probe later.

You're absolutely right that AON could be a module and would generally
probe later in that scenario. However, the GPU device also has a
'power-domains = <&aon TH1520_GPU_PD>' dependency. If the AON driver (as
the PM domain provider) were a late probing module, the GPU driver's
probe would hit -EPROBE_DEFER when its power domain is requested
which happens before attempting to get other resources like a power
sequencer.

Huh, so basically you imply certain hardware design and certain DTS
description in your driver code. Well, that's clearly fragile design to
me, because you should not rely how hardware properties are presented in
DTS. Will work here on th1520 with this DTS, won't work with something else.

Especially that this looks like generic Imagination GPU code, common to
multiple devices, not TH1520 only specific.

So, if the GPU driver's code does reach the devm_pwrseq_get(dev,
"gpu-power") call, it strongly implies the AON driver has already
successfully probed.

This leads to the core challenge with the optional 'gpu-power'
sequencer: Even if the AON driver has already probed, if it then chooses
not to register the "gpu-power" sequence (because it's an optional
feature), pwrseq_get() will still find "no device matched" on the
pwrseq_bus and return EPROBE_DEFER.

If the GPU driver defers here, as it normally should for -EPROBE_DEFER,
it could wait indefinitely for an optional sequence that its
already probed AON provider will not supply.

Anyway I think you're right, that this is probably confusing and we
shouldn't rely on this behavior.

To solve this, and to allow the GPU driver to correctly handle
-EPROBE_DEFER when a sequencer is genuinely expected, I propose using a
boolean property on the GPU's DT node, e.g.
img,gpu-expects-power-sequencer. If the GPU node provides this property
it means the pwrseq 'gpu-power' is required.

No, that would be driver design in DTS.

I think the main problem is the pwrseq API: you should get via phandle,
not name of the pwrseq controller. That's how all producer-consumer
relationships are done in OF platforms.

It's also fragile to rely on names in case of systems with multiple
similar devices. This does not affect your platform and this hardware in
general, but shows issues with interface: imagine multiple gpus and
multiple pwr sequence devices. Which one should be obtained?
gpu-power-1? But if GPUs are the same class of devices (e.g. 2x TG1520
GPU) this is just imprecise.


Best regards,
Krzysztof