From: Suman Anna <s-anna@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer
Date: Mon, 20 Jul 2015 11:13:37 -0500 [thread overview]
Message-ID: <55AD1E31.8020107@ti.com> (raw)
In-Reply-To: <20150716071640.GI17550@atomide.com>
Hi Tony,
On 07/16/2015 02:16 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna@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
WARNING: multiple messages have this Message-ID (diff)
From: s-anna@ti.com (Suman Anna)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer
Date: Mon, 20 Jul 2015 11:13:37 -0500 [thread overview]
Message-ID: <55AD1E31.8020107@ti.com> (raw)
In-Reply-To: <20150716071640.GI17550@atomide.com>
Hi Tony,
On 07/16/2015 02:16 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna@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
next prev parent reply other threads:[~2015-07-20 16:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 20:43 [PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer Suman Anna
2015-07-10 20:43 ` Suman Anna
2015-07-16 7:16 ` Tony Lindgren
2015-07-16 7:16 ` Tony Lindgren
2015-07-20 16:13 ` Suman Anna [this message]
2015-07-20 16:13 ` Suman Anna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55AD1E31.8020107@ti.com \
--to=s-anna@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.