Hi Daniel, On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > > On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > >> Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be > >> enough, or not? My idea is to use this for the case where the only > >> thing in dt is the panel, with no real bridge chip. And I think we > >> don't need anything beyond that one _init function, plus maybe some > >> additional paramaters ... > > > > There should be no bridge then. If you want the DRM core to manage panels > > automatically, then we should create specific helpers for that, not abuse > > the bridge infrastructure. Bridges should be instantiated from a hardware > > device and bound to drivers as usual. > > I guess that's the part where I disagree: Just because there's physically > no bridge doesn't mean we shouldn't just treat it as one in the software > abstraction. If it looks and acts like a bridge (even an empty one), then > imo it can be a bridge. > > If you insist on panels being panels, then I guess we need some other kind > of glue to bind them into arbitrary bridge chains. But given that the > callbacks match very closely, I don't see the point. > > In an idea world a panel would probably derive from a drm_bridge, but > we're not in that universe unfortunately ;-) Or both would derive from another object, but I agree that's how it should work. That's what I want to achieve, one step at a time. Creating dummy bridges isn't a step in that direction in my opinion, so I'd rather not do that, but work towards the right abstraction. -- Regards, Laurent Pinchart
