On Sat, May 22, 2010 at 8:14 AM, Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> wrote: > From: ext Felipe Contreras <felipe.contreras@xxxxxxxxx> >> Apparently it's not, so it's not clear to me how omap3-iommu would be >> loaded since there's no "platform:" alias. > > This alias is only necessary for platform drivers. So, omap3-iommu should be built-in (since it would not be loaded automatically), so the "platform:" alias is not _required_, but can't hurt anyway. Right? >> Moreover, Tony says that anything that registers platform devices >> should be built-in, but omap3-iommu does register devices and is not >> built-in. > > It seems that this makes you confused. It should have been > build-in;). This is going to be integrated into omap hwmod framework > soon. The hwmod framework will deal with the resources, not with the platform device. Somebody, presumably the current omap3-iommu, would have to call omap_device_build() with the right hwmod and platform data. >> 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? > > Yes. > >> 2) should platform modules like omap3-iommu and mailbox-mach have a >> "platform:" alias? > > No. They must have it when compiled as a module, but if not, it's not _needed_, but does it hurt? >> 3) should such modules follow a guideline like foo-mach, or $mach-foo? > > No, this is not a guideline. Just to avoid the module name cofliction. I know there is no guideline, I'm asking if there _should_ be one. It would be interesting to do lsmod | grep "^*-mach". >> 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? > > Yes. > >> If that's the case I agree, although I have the feeling that the >> platform-specific data can be reduced a lot. > > Then, eventually the code would result in the one which the current > "devices.ko" has at present. > > The point is that, only 17 lines of patch does the same, more > simply. The conversion of your fake platform device doesn't make > much sense. I'm not sure what you mean. Anyway, I started playing with hwmod on top of my branch and I found that there same cleanups are possible without the need to move platform_device resources. I will split the series in two: one for cleanups, and one for hwmod + platform_device split (RFC). And hopefully the possibilities would be clear. Cheers. -- 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
