Re: Armada DRM: bridge with componentized devices

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Tue, Jan 08, 2019 at 09:35:21AM +0100, Andrzej Hajda wrote:
> On 07.01.2019 22:56, Daniel Vetter wrote:
> > If you call drm_dev_register before you have all the components
> > assembled (i.e. anywhere else than in master bind) that sounds like a
> > driver bug.
> 
> 
> This is how components work, every component calls component_add usually
> in probe, and this function checks if all components are present, if yes
> (ie. during probe of the last component) master bind is called and it
> creates drm device and then registers it. If you add device link at this
> moment, it is still before end of probe of the last component.

I wonder if device links will create more problems with the component
stuff, because we'll end up with two different systems fighting to
achieve the same aim.

1) a component device is probed, and is added to the component helper
   as a component.  (Repeat for as many component devices as are
   required.)
2) the main device is probed, added as a master.  The system is
   complete, so the master bind is called, and device links are
   created - the component device is a provider, and the main
   device is a consumer.
3) the component device is unbound, which triggers the device links
   to unbind the provider device.  This undoes everything, removing
   the device links and removing the main device from the component
   helper.
4) the component device is re-probed, and added to the component
   helper again.

At this point, there is nothing that causes the main device to be
re-probed.  As far as userspace is concerned, that's confusing because
userspace never asked for any change of status of the provider device.

Without device links, the main device would not be unbound, and there
would be an additional stage:

5) the component helper notices the re-appearance of the component
   device, notices that the system is again complete, and re-binds
   the master device bring the system back up.

This seems to be a disadvantage with device links, but there is an
advantage that device links offer - the ability to deal with other
resources (such as clocks, regulators, etc) going away more
gracefully than is possible today - but folk have to understand
that a consumer device will only ever be unbound, it will never be
re-bound automatically when the resources re-appear.

I suppose that could be fixed by moving the consumer devices onto
the deferred probe list, so when a device is re-bound, they are
retried.  At that point, the component helper becomes entirely
redundant, since its functionality can be implemented completely
using device links.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel