>>>>> >>>> >>>> I think we need to start considering a framework where subdrivers just >>>> add drm objects themselves, then the toplevel node is responsible for >>>> knowing that everything for the current configuration is loaded. >>>> >>> >>> It would be nice to specify the various pieces in dt, then have some >>> type of drm notifier to the toplevel node when everything has been >>> probed. Doing it in the dt would allow standalone drm_bridge/drm_panel >>> drivers to be transparent as far as the device's drm driver is >>> concerned. >>> >>> Sean >>> >>> >>>> I realise we may need to make changes to the core drm to allow this >>>> but we should probably start to create a strategy for fixing the API >>>> issues that this throws up. >>>> >>>> Note I'm not yet advocating for dynamic addition of nodes once the >>>> device is in use, or removing them. >>>> >> >> I do wonder if we had some sort of tag in the device tree for any nodes >> involved in the display, and the core drm layer would read that list, >> and when every driver registers tick things off, and when the last one >> joins we get a callback and init the drm layer, we'd of course have the >> basic drm layer setup prior to that so we can add the objects as the >> drivers load. It might make development a bit trickier as you'd need >> to make sure someone claimed ownership of all the bits for init to proceed. >> > > Yeah, that's basically what the strawman looked like in my head. > > Instead of a property in each node, I was thinking of having a > separate gfx pipe nodes that would have dt pointers to the various > pieces involved in that pipe. This would allow us to associate > standalone entities like bridges and panels with encoders in dt w/o > doing it in the drm code. I *think* this should be Ok with the dt guys > since it is still describing the hardware, but I think we'd have to > make sure it wasn't drm-specific. >
I suppose the question is how much dynamic pipeline construction there is, even on things like radeon and i915 we have dynamic clock generator to crtc to encoder setups, so I worry about static lists per-pipe, so I still think just stating all these devices are needed for display and a list of valid interconnections between them, then we can have the generic code model drm crtc/encoders/connectors on that list, and construct the possible_crtcs /possible_clones etc at that stage. Dave.
