On Thu, Mar 02, 2017 at 02:30:09AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote: > > 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. > > Do you object getting this patch merged as-is as a first step in the right > direction ? :-) Well, I'm definitely no fan at all of typing code that's only there to satisfy some fairly arbitrary normative choices we attach to the words we pick for our abstraction. But I'm also not going to stop you, just don't complain if I ask the next dummy panel to reuse your LVDS bridge :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
