[PATCH v2t2 00/17] omap: mailbox:

[Felipe Contreras]

On Sat, May 22, 2010 at 8:14 AM, Hiroshi DOYU <Hiroshi.DOYU at nokia.com> wrote:
> From: ext Felipe Contreras <felipe.contreras at gmail.com>

>> 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