On Wed, Jun 25, 2014 at 11:32:46AM -0300, Ezequiel García wrote: > (Ccing Guido back) > > Hello Russell, Darren, > > On 25 Jun 02:00 PM, Russell King - ARM Linux wrote: > > On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote: > > > If I recall, the late_initcall stuff was done to try and make sure the > > > tda998x/i2c subsystem came up before tilcdc. > > That doesn't make any sense. Using late_initcall for the tilcdc DRM > driver would make the tilcdc DRM get probed before any other regular > module_init driver, including the tda998x encoder. A module_init() is a device_initcall(), which is at level 6. A late_initcall() is at level 7. Level 6 initcalls are run before level 7 initcalls. The tda998x is a module_init(), so the tda998x gets initialised *before* tilcdc's late_initcall(). Now, if you build everything as a module, then you have no initialisation ordering, and you can't rely on any kind of order. Initialisation functions can even run in parallel on different CPUs due to modules being loaded from userspace in a multi-threaded way. So anything which relies on a certain initcall ordering is fundamentally broken if it can be modular. > > There's a solution to that... > > A solution to *what* ? Maybe if you left the context above that line in place, you might understand that my "that" refers to what was discussed in that context. That being the initialisation ordering. Convention and proper Internet etiquette is to trim the quoted text and place relies below the paragraph to which they refer, the quoted paragraph giving the context to the reply. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
