On Wed, 2011-01-05 at 18:55 +0530, ext Semwal, Sumit wrote: > Hi Tomi, > > On Wed, Jan 5, 2011 at 4:57 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> wrote: > > Hi, > > > > Does this even work if the DSS is compiled as a module? I have the > > recollection that a module can only have one initcall, and in this case > > omapdss would have many. > > [Sumit]: we haven't tried compiling DSS as module - I guess we will > have to create each dss hw IP also as a separate module. Having them as separate modules makes things quite complex: then you need to be able to load only the modules you want (eg. leave dsi.ko out). But you'd also need to be able to load the dsi.ko later, after you decide to use a dsi based panel. This would of course be very neat, but I don't believe it's a very easy task. For the time being I would keep the DSS as one module, and if needed, try dividing it into separate modules later as a separate task. > About making one common initcall, then I think we would need to have > all platform_driver related functions either as global or in one file. > is this a better option than having each as a separate module? I'd say it's better in the sense that a) it would work and b) it would be much easier than dividing DSS into multiple modules. I'd say have the platform driver code in their respective files (dsi.c, venc.c etc), and call dsi_init_platform_driver() from the probe function. That would keep the code clean if we decide to split the DSS into multiple modules. Also, shouldn't there be platform_driver_unregister() calls somewhere? You should definitely also test with DSS as a module =). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
