On Sat, May 22, 2010 at 1:15 AM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Sat, May 22, 2010 at 01:09:12AM +0300, Felipe Contreras wrote: >> On Sat, May 22, 2010 at 12:57 AM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> wrote: >> > The only reason 3 would be loaded due to that dependency is if 2 were >> > being modprobed, which means it's going to be inserted after 3 anyway. >> > >> > I don't see anything else in 3 which would trigger it to be loaded. >> > >> > The "platform:omap2-mailbox" module alias of 2 should result in 2 >> > being modprobed, >> >> I see, at initialization? > > That's the theory - and it should be that same mechanism which allows > things like already plugged in PCMCIA and the like cards to be properly > dealt with at boot time. > >> > causing 3 to be loaded to satisfy the dependency. >> > As already pointed out, this should happen as a result of udev or >> > (older) hotplug initialization. >> >> Well, in the minimal system I have in my beagleboard it doesn't >> happen. I load bridgedriver, which loads mailbox, but fails >> immediately because mailbox_mach is not there. > > I assume that having the MMC host driver built in, but the MMC block > driver as a module also doesn't work on your setup? I wouldn't know because my file-system is on the MMC. > I don't see this as something that should be worked around in the > kernel by making things non-modular - I view the missing userspace > functionality causing the problem. First of all, most of the cleanups are independent of the built-in option, although that was my motivation, the patches are good by themselves: there's no need to export omap_mbox_register()/_unregister() unnecessarily when the platform data can be used, right? Now, regarding the built-in mode; for the iommu case you said it should be built-in: http://article.gmane.org/gmane.linux.ports.arm.kernel/58555 Apparently it's not, so it's not clear to me how omap3-iommu would be loaded since there's no "platform:" alias. Moreover, Tony says that anything that registers platform devices should be built-in, but omap3-iommu does register devices and is not built-in. We could make it built-in as you suggested, but according to you, things should be modular. So, I have a bunch of questions: 1) should platform devices be built-in? 2) should platform modules like omap3-iommu and mailbox-mach have a "platform:" alias? 3) should such modules follow a guideline like foo-mach, or $mach-foo? >From what I can see there's already a lot of code that adds platform data at registering time, which is built-in, but I guess you object because of the size of all the extra data and code that would come by making mach-omapX/mailbox.c as built-in. Am I right? If that's the case I agree, although I have the feeling that the platform-specific data can be reduced a lot. But again, only one of the patches makes the code built-in, the rest of the patches are independent of that. -- Felipe Contreras -- 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
