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
