Re: [PATCH v3 3/8] drm/imagination: Use pwrseq for TH1520 GPU power management

[Krzysztof Kozlowski <krzk@kernel.org>]

On 13/06/2025 11:49, Michal Wilczynski wrote:
> 
> 
> On 6/13/25 10:25, Michal Wilczynski wrote:
>>
>>
>> On 6/13/25 08:44, Krzysztof Kozlowski wrote:
>>> On 11/06/2025 14:01, Michal Wilczynski wrote:
>>>>
>>>> However, this leads me back to a fundamental issue with the
>>>> consumer side implementation in the generic pvr_device.c driver. The
>>>> current fallback code is:
>>>>
>>>> /*
>>>>  * If the error is -EPROBE_DEFER, it's because the
>>>>  * optional sequencer provider is not present
>>>>  * and it's safe to fall back on manual power-up.
>>>>  */
>>>> if (pwrseq_err == -EPROBE_DEFER)
>>>>         pvr_dev->pwrseq = NULL;
>>>>
>>>> As Krzysztof noted, simply ignoring -EPROBE_DEFER is not ideal. But if I
>>>> change this to a standard deferred probe, the pvr_device.c driver will
>>>
>>> Why? You have specific compatible for executing such quirks only for
>>> given platform.
> 
> I realized now that you may have meant the "thead,th1520-gpu" compatible,
> not the "thead,th1520" SoC compatible.
> 
> In any case, the whole reason for using the pwrseq framework is to avoid
> polluting the generic driver with SoC specific logic and instead offload
> that responsibility to a pwrseq provider. Therefore, I can't simply add
> a check like if (compatible == "thead,th1520-gpu") to the generic driver
> to decide whether to get a power sequencer. This entire matching
> responsibility was intended to be offloaded to the pwrseq framework.

No, just do how all drivers are doing - driver match data, describing
that there is some component, e.g. quirks/flags, number of clocks and
their names typically. In your case - name or presence of pwrseq.



Best regards,
Krzysztof