Re: Armada DRM: bridge with componentized devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter <daniel@xxxxxxxx> wrote:
> > >
> > > On Wed, Jan 9, 2019 at 10:31 AM Russell King - ARM Linux
> > > <linux@xxxxxxxxxxxxxxx> wrote:
> > > > On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote:
> > > > > On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote:
> > > > > >
> > > > > > +CC: Rafael J. Wysocki <rafael@xxxxxxxxxx>
> > > > > >
> > > > > > On 08.01.2019 16:07, Russell King - ARM Linux wrote:
> > > > > > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> > > > > > >> On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> > > > > > >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> > > > > > >>>> On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> > > > > > >>>>> On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> > > > > > >>>>>> Issues with device links have nothing to do with hotplugging, they are
> > > > > > >>>>>> generic - lifetime of the objects (drm_bridge, drm_panel) is just
> > > > > > >>>>>> slightly different of lifetime of device links, and this is racy even if
> > > > > > >>>>>> you do not want hotplugging. Moreover since drm_dev is not device (has
> > > > > > >>>>>> no associated struct device) assuming we can reuse its parent to create
> > > > > > >>>>>> device link results in circular dependencies.
> > > > > > >>>>> How about having the device links created depending on whether the
> > > > > > >>>>> main drm driver wants them or not - that would mean that Exynos
> > > > > > >>>>> could continue avoiding them, but others that want them can have
> > > > > > >>>>> the links?
> > > > > > >>>> That should be OK for Exynos. But regardless of Exynos device_links at
> > > > > > >>>> the current state will not work correctly with bridges/panels as I
> > > > > > >>>> described earlier.
> > > > > > >>> However, I'm not sure you're correct with your interpretation of the
> > > > > > >>> documentation.  Firstly, the documentation says:
> > > > > > >>>
> > > > > > >>>    Another example for an inconsistent state would be a device link that
> > > > > > >>>    represents a driver presence dependency, yet is added from the consumer's
> > > > > > >>>    ->probe callback while the supplier hasn't probed yet: Had the driver core
> > > > > > >>>    known about the device link earlier, it wouldn't have probed the consumer
> > > > > > >>>    in the first place. The onus is thus on the consumer to check presence of
> > > > > > >>>    the supplier after adding the link, and defer probing on non-presence.
> > > > > > >>>
> > > > > > >>> This is fine - if we add the device link from of_drm_find_bridge(), we
> > > > > > >>> will be in the consumer's ->probe function, and the supplier must have
> > > > > > >>> been probed for us to find the struct drm_bridge.
> > > > > > >>
> > > > > > >> Supplier usually is registered in it's probe time, so there is short
> > > > > > >> period of time when supplier is available, but the probe is not yet
> > > > > > >> finished - quite unsafe, but not impossible, especially if there exists
> > > > > > >> some kind of notifications about resource appearance (MIPI-DSI case).
> > > > > > > At some point during the supplier probe, the resource becomes available
> > > > > > > to consumers.  At that point, device links can be setup before the
> > > > > > > supplier has finished probing.  So any driver that provides resources
> > > > > > > to another driver will, at some point during the provider's probe,
> > > > > > > make resources available, and therefore be a candidate for device links
> > > > > > > to be created _before_ the probe function has returned.
> > > > > > >
> > > > > > > What is a problem is if the provider publishes resources, and then fails
> > > > > > > its probe function, causing the resource to disappear.
> > > > > >
> > > > > >
> > > > > > But creating link to not-probed provider is still incorrect usage from
> > > > > > device_links framework PoV, and my tests showed indeed that device link
> > > > > > created before end of provider's probe does not work at all - and since
> > > > > > it is stated in the documentation I guess it is by design.
> > > > >
> > > > > Yes, it is.
> > > >
> > > > So is the regulator support and the use of it being proposed for the CCF
> > > > all going against the design of device links?  In both those cases,
> > > > device links _can_ be created while the supplier is still in the probe
> > > > function by a consumer finding the resource.
> > > >
> > > > This seems fragile by design.
> > >
> > > Rafael, can you confirm?
> >
> > Let me quote from
> > https://www.kernel.org/doc/html/latest/driver-api/device_link.html :
> >
> > "When driver presence on the supplier is irrelevant and only correct
> > suspend/resume and shutdown ordering is needed, the device link may
> > simply be set up with the DL_FLAG_STATELESS flag. In other words,
> > enforcing driver presence on the supplier is optional."
> >
> > Which is exactly the case at hand here AFAICS.
>
> That is not what we're discussing.  We are discussing using device
> links to solve the problem with DRM bridges which may be removed
> today from DRM without the rest of the DRM system being aware.

Still, I think, the DL_FLAG_STATELESS flag should work for you as it
turns the state tracking off entirely.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux