Hi Daniel, On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote: > On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote: > > On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote: > >> On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote: > >>> +panel/bridge reviewers. > >>> > >>> This does make things much cleaner, but it seems a bit strange to > >>> create a drm_bridge when there isn't really a HW bridge in the display > >>> chain (i.e, when the DSI encoder is directly connected to a DSI panel). > >>> > >>> There are kms drivers that use drm_panel, but don't have simple stub > >>> connectors that wrap around a drm_panel. They have more complicated > >>> connector ops, and may call drm_panel_prepare() and related functions > >>> a bit differently. We won't be able to use drm_panel_bridge for those > >>> drivers. > >>> > >>> For msm, we check whether the DSI encoder is connected directly to a > >>> panel or an external bridge. If it's connected to an external bridge, > >>> we skip the creation of the stub connector, and rely on the external > >>> bridge driver to create the connector: > >>> > >>> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L22 > >>> 7 > >>> > >>> The msm solution isn't very neat, but it avoids the need to create > >>> another bridge to glue things together. > >> > >> Since I suggested this, yes I like it. And I think just unconditionally > >> creating the panel bridge is probably even simpler, after all bridges > >> are supposed to be chainable. I guess there's always going to be drivers > >> where we need special handling, but I'm kinda hoping that for most cases > >> simply plugging in a panel bridge is all that's need to glue drm_panel > >> support into a driver. The simple pipe helpers do support bridges, and > >> part of the goal there very much was to make it easy to glue in panel > >> drivers. > > > > As I've just explained in another reply, I don't see the point in doing > > this when we can instead refactor the bridge and panel operations to > > expose a common base object that will then be easy to handle in core > > code. This isn't just for panels, as connectors should have DT nodes, it > > makes sense to instantiate an object for them that can be handled by the > > DRM core, without having to push connector handling in all bridge > > drivers. > > Imo you're aiming too high. We have 21 bridge drivers and 11 panel > drivers. Asking someone to refactor them all (plus all the callers and > everything) means it won't happen. At least I personally will definitely > not block a contribution on this happening, that's a totally outsized > demand. I think you're aiming too low. When the atomic update API was introduced I could have told you that converting all drivers was an impossible task ;-) Jokes aside, I believe it might be possible to implement something simple. I'm flexible about the naming, so instead of creating a new base structure and refactor drm_bridge and drm_panel to embed it, we could as a first step use drm_bridge as that base structure. We would only need to embed a drm_bridge instance in drm_panel and add a few connector-related operations to the bridge ops structure. As existing bridge drivers wouldn't need to provide those new ops, they wouldn't need to be touched. > What we could do instead is slowly merge these two worlds together, and > this here is definitely a step into that direction. Let's please not throw > out useful improvements by insisting that we only merge perfect code. We > already did merge both drm_panel and drm_bridge (plus a few more earlier > attempts), clearly we're not only merging perfect code :-) > > Or you go ahead and deliver that refactoring, that's another option ofc > ... It's on my to-do list for the near future actually, in order to convert the omapdrm-specific bridge and panel drivers into standard DRM drivers. I'd like to get a general agreement on the direction I'd like to take before converting everything though, so I'd appreciate your feedback on the thoughts above. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
