[PATCH 0/3] omapdrm: Fix runtime PM issues at module load and unload time

[Tomi Valkeinen]

On 01/11/18 14:13, Laurent Pinchart wrote:

>> Thanks for debugging this! I have to say I really don't like these
>> (well, 2 is fine), as they feel like hacks.
> 
> I assume you also have nothing against the first hunk of patch 3/3.

Yes. And after our discussion, I think 1 is fine too, so the only
problem is the latter part of patch 3.

>> Can we not defer the probe of the submodules until the dependencies have
>> been probed?
> 
> That would be difficult, as the submodules don't know about the DSS. It goes 
> the other way round, it's the DSS that gathers a list of submodules.
> 
> Furthermore the DSS probe is deferred due to the devices connected to the DPI 
> and SDI outputs not being probed yet. See dpi_init_output_port(), the call to 
> omapdss_of_find_connected_device() returns -EPROBE_DEFER. This is why the DSS 
> probe is deferred if you load the omapdss module before all the other modules 
> for the external components. Getting hold if the next device in the chain was 
> needed to reverse the chain control direction.

Ok.

> I would like to also point out that regardless of the underlying issue, I 
> think creating the DSS children in the DSS driver instead of mach-omap2 code 
> is the right thing to do, as the DSS really handles the bus through which the 
> children are accessed. This is similar to how an I2C adapter creates the I2C 
> slaves.

Agreed.

>> And considering these issues, is the assumption that "There's no reason
>> to delay initialization of most of the driver (such as mapping memory
>> I/O or enabling runtime PM) to the component bind handler." still valid?
>> edb715dffdee71bb8216ee4d71c0714d932e9acf doesn't really state any
>> benefit for this move either. Clearly there's a reason to do this in
>> bind, although it doesn't solve the dispc dependency.
> 
> We could try moving code back to the bind handler, but that would get in the 
> way of probe deferral until bridges are available. In order to solve that we 
> would need to convert all bridges to the component framework, which we can't 
> do as they're used by display drivers that don't use components. Lovely, isn't 
> it ?
> 
> There's a nearly infinite amount of problems to fix and I wish I could tackle 
> them all at the same time, but that's unfortunately not possible. I would like 
> at some point in the future to add an asynchronous bind mechanism to DRM 
> bridge itself, whose usage would be optional, unlike the component framework. 
> This would help with probe handling, but it's way down the road.

Yep, this seems to be rather complex issue. So, maybe we can go with the
third patch too, but perhaps split it in two, as the first hunk is fine.
And perhaps add mark the rest clearly as HACK, also in the suspend.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki