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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
