On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote: > The main problem with component framework is that componentization > significantly changes every driver and changes it in a way which is not > compatible with traditional drivers, so devices which are intended to > work with different DRM masters are hard to componentize if some of DRMs > are componentized and some not. Many of the problems which the component helpers are designed to solve are those where you need the drm_device structure (or snd_card, or whatever subsystem specific card/device representation structure) pre-created in order to initialise the components. In the case of DRM, you can't initialise encoders or connectors without their drm_device structure pre-existing - because these components are attached to the drm_device. Your solution to that is to delay those calls, but the DRM subsystem is not designed to cope like that - it's designed such that when the connector or encoder initialisation functions are called, it is assumed that the driver is initialising its state. (I've raised this point before but you've just fobbed it off in the past.) Another issue here is that the order of initialisation matters greatly. Take CRTCs for example. In DRM, the order of attachment of CRTCs defines their identity, changing the order changes their identity, and changes how they are bound to their respective connectors. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |