[PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer
Suman Anna
s-anna at ti.com
Mon Jul 20 09:13:37 PDT 2015
Hi Tony,
On 07/16/2015 02:16 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna at ti.com> [150710 13:45]:
>> The OMAP IOMMU driver has been adapted to the IOMMU framework
>> for a while now, and it no longer supports being built as a
>> module. Cleanup all the module related references both from
>> the code and in the build.
>>
>> While at it, also relocate a comment around the initcall to
>> avoid a checkpatch strict warning about using a blank line
>> after function/struct/union/enum declarations.
>
> OK applying into omap-for-v4.3/soc.
Thanks.
>
> You may want to check few things after this:
>
> - Does it still need to be omap_subsys_initcall or can it
> happen later? Anything we can initialize later on is worth
> doing as then we have proper debug console available.
This code will be cleaned up once the non-DT references/users for OMAP3
IOMMUs go away. I will do this in the next merge window once Laurent's
OMAP3ISP legacy device creation cleanup series gets into mainline [1].
>
> - For multi_v7_defconfig it would be nice to be able to
> make the driver/iommu components into standard Linux
> loadable modules.
We used to be module before, and the built-in is coming from the IOMMU
framework. The init function in the OMAP IOMMU driver already handles
the multi_v7_defconfig scenario, so no issues there.
>
> - Actually you can probably get rid of mach-omap2/omap-iommu.c
> completely by implementing PM runtime and and possibly
> reset controller.
Yeah, any need for this file after the non-DT device creation removal
would arises from the PRCM/reset dependencies against API present in
mach-omap2 layer only.
regards
Suman
[1] http://marc.info/?l=linux-omap&m=143705130631733&w=2
More information about the linux-arm-kernel
mailing list