On Mon, Oct 21, 2013 at 11:27:30AM +0200, Sascha Hauer wrote: > If you have a better vision how imx-drm can be implemented without > getting crazy I'd love to hear about it. Please also think about the two > IPUs the i.MX6 has, the single one on i.MX5, parallel displays, HDMI > displays, LVDS displays, VGA encoder on i.MX53, external I2C slave > encoders,... Well, the multi-driver solution is just too fragile: the problem with it is you can never be sure when all the drivers have definitely finished initialising. This problem is made much worse should one of them use deferred probing. To put it another way - with a multi-driver solution, there is no definite point you can say "okay, we got everything". So, as long as a subsystem contains something that needs to be done once everything is known (such as initialising the fb_helper), there is a fundamental disconnect between a multi-driver solution and the subsystem. To put it another way, a multi-driver solution should not be used. The I2C slave encoder problem doesn't really come into this because it's not really a separate driver - yes, it's modelled by a separate driver but when analysed, it's not really using the driver model at all. The driver model is only really used to locate the required driver. Conceptually, the imx-drm hardware is not much different from the the Armada/Dove display hardware: it too has the problem that there can be several CRTCs and several display outputs. In some ways it's worse there because there isn't the same level of integration found on i.MX - it just has VGA and parallel outputs. If you want something else, you need to stick a chip on the output. In the case of HDMI, that's a TDA998x device. For that, I've opted not to even _try_ to come up with a DT solution at present, because I know that trying to come up something that represents the hardware will not work properly with DRM. That's exactly what everyone else should have done. Then the effort would not be spent trying to come up with individual DT solutions and driver specific hacks, but instead would be spent on trying to sort out the DRM core to allow it to handle separately pluggable connectors, encoders and crtcs. I have been getting is pressure to come up with a fudge for the Armada DRM to make it work with DT just like everything else: there was even suggestions that the driver should not be merged because it doesn't support DT, and as everyone is going DT, it would have very few users. Quite rightfully, I refuse to fudge the driver and create yet another abomination. Thankfully, the subsystem maintainers agree that this is something that can be worked on independently: it should be, it's not a specific driver problem, it's a subsystem problem and it needs solving for everyone. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
