On Tue, Jan 08, 2019 at 12:39:36AM +0000, Russell King - ARM Linux wrote: > 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. And hdlcd and mali-dp have been unloaded and loaded back multiple times on my dev boards. I can't comment on other Arm SoC drm drivers, but I'll be prepared to bet that at least another one is capable of doing the same thing. Now, the fact that you might have an fbcon that binds to the framebuffer and makes life a bit harder ... that's another thing. Best regards, Liviu > > 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 -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
