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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
