Re: Armada DRM: bridge with componentized devices

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

On Mon, Jan 07, 2019 at 10:55:15PM +0100, Daniel Vetter wrote:
> On Mon, Jan 7, 2019 at 5:13 PM Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> >
> > On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 03, 2019 at 01:11:47PM +0000, Russell King - ARM Linux wrote:
> > > > This is the long-standing problem with the conflict between bridge
> > > > support and component support, and I'm not sure that there is really
> > > > any answer to it.
> > > >
> > > > I've gone into the details of the two several times on the list,
> > > > particularly about the short-comings of the bridge approach, but it
> > > > seems no one cares to fix those short-comings.
> > > >
> > > > You are re-identifying some of the issues that I've already pointed
> > > > out - such as what happens to DRM drives when the bridge driver is
> > > > unbound (it's really not about modules being unloaded, and the problem
> > > > can't be solved by taking a module reference count - all that the
> > > > module reference count does is ensure that the module doesn't go
> > > > away unexpected, there is no way to ensure that the device isn't
> > > > unbound.)
> > > >
> > > > The issue of unbinding is precisely the issue which the component
> > > > support was created to solve - but everyone seems to prefer the buggy
> > > > bridge approach, and no one seems willing to do anything about the
> > > > bugs or even acknowledge that it's a problem.  It's strange - if one
> > > > identifies bugs that result in kernel oops in other kernel subsystems,
> > > > one is generally taken seriously and the problem is solved.
> > >
> > > Unbinding is really not the most important feature, especially for SoC. If
> > > you feel different, working together with others, getting some agreement,
> > > getting the patches reviewed and finding someone to get them merged is
> > > very much appreciated. But just complaining won't move this forward.
> >
> > Sorry, I disagree.  Unbinding is important if the current state results
> > in crashes and oops - the lack of unbinding support in bridge makes it
> > harder to develop without constantly rebooting the target machine.
> >
> > If all you care about is the end user who probably never removes a
> > module, then yes, it's low priority, but if you care about efficient
> > development, then the story is rather different.
> 
> Unloading i915 needs a very careful script, or you'll get a rather
> bright fireworks. Afaik all other drm drivers (except maybe udl) are
> the same. At least if you do anything fancy, where fancy includes:
> fbdev emulation, prime buffer sharing, shared dma fences, or well
> anything really that goes beyond a dummy boot splash. The lifetimes of
> all these things are flat-out broken. udl tries to at least wrap some
> duct-tape around it, and Noralf greatly improved the situation in the
> past year at least.
> 
> So still not seeing what exactly the massive blocker here is.

The fact that I can unload armada drm/tda998x modules without incident
today, and have done many times through development, and I don't wish
to regress from that position.  As far as I'm concerned, this is a
solved problem, but the pressure I'm under to convert tda998x to a
bridge driver is causing bugs that I've already solved by _not_ using
that to be introduced.

You've mentioned in your previous mail about me not trying to solve
the situation - I have tried, I've proposed a way around the component
vs bridge issue but I don't think it went anywhere.

If I can't get traction on issues, then I can only state what the
current state of affairs is to folk asking about it.  That is _not_
"whinging" about it, that is informing people and being helpful.

-- 
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