From: b-cousson@ti•com (Cousson, Benoit)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/6] omap: iommu: hwmod support and code reorganization
Date: Sat, 06 Nov 2010 14:56:41 -0400 [thread overview]
Message-ID: <4CD5A4E9.1050106@ti.com> (raw)
In-Reply-To: <1289006396-27230-1-git-send-email-omar.ramirez@ti.com>
On 11/5/2010 9:19 PM, Ramirez Luna, Omar wrote:
> Boot tested on omap 3430 and 3630, functionality on iva2 only.
>
> Introduced hwmod data and support for omap3 (iva2 mmu& isp mmu) and
> omap4 (ducati mmu& tesla mmu).
>
> Minor cleanup due to this changes.
>
> There is an issue (present without patches too):
>
> Doing a cycle of insmod-rmmod to iommu module and then full
> insmod of bridgedriver (with all dependencies) causes the next
> read of iommu registers to dump an unhandled fault log; this,
> because when rmmod of iommu is called it tries to clean the
> iommu tables and flush any old entry prior to removing the driver,
> however these reads/writes are attempted while the MMU is under
> reset and will timeout on the L3 IVA target agent, which will leave
> MMU unusable until the proper restore sequence to clear this L3
> error is executed.
>
> Fix would be to move page table allocation to iommu get and its
> correspondent free to iommu put, however it will fall entirely
> under iommu user responsibility, as it needs to clear the mmu
> reset bit, before calling iommu functions that read/write into
> mmu registers (which should apply only for first boot or on
> baseimage reload); trading this restriction in order to keep
> the same generic iommu code for all omap iommu devices.
>
> This issue has been seen on omap3 iva2 mmu, same restriction should
> apply for tesla mmu.
>
> For discussion: should iommu handle mmu reset source directly?
> This register is grouped into an IVA PRM register which handles
> sequencer, iva2 mmu and dsp resets. As mentioned iommu handles
> cam, iva2 mmu (OMAP3) and tesla, ducati mmu (OMAP4), only tesla
> and iva2 should suffer from this restriction and according changes
> should be needed to handle both cases on mach-omap2 code. This
> also affects hwmod, since, if defined, it tries to read SYSC
> registers at boot time when registering the hwmod and causing the
> same issue.
>
> Omar Ramirez Luna (6):
> omap: iommu: remove redundant clock usage
> OMAP3: hwmod data: Add mmu for iva2 and isp
> OMAP4: hwmod data: add mmu hwmod for ducati and tesla
> omap: iommu: intial hwmod support
> omap: iommu: hwmod device enable/disable routines
> omap: iommu: code reorganization and cleanup
Could you please try to use a consistent naming in the subjects?
OMAP3, OMAP4, OMAP2 --> OMAP and not omap.
Thanks,
Benoit
>
> arch/arm/mach-omap2/omap-iommu.c | 168 +++++++++-------------------
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 103 +++++++++++++++++
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 105 +++++++++++++++++
> arch/arm/plat-omap/include/plat/iommu.h | 19 +++-
> arch/arm/plat-omap/include/plat/omap34xx.h | 2 +
> arch/arm/plat-omap/iommu.c | 64 ++++-------
> 6 files changed, 299 insertions(+), 162 deletions(-)
>
prev parent reply other threads:[~2010-11-06 18:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 1:19 [PATCH 0/6] omap: iommu: hwmod support and code reorganization Omar Ramirez Luna
2010-11-06 1:19 ` [PATCH 1/6] omap: iommu: remove redundant clock usage Omar Ramirez Luna
2010-11-06 19:11 ` Cousson, Benoit
2010-11-07 15:55 ` Ramirez Luna, Omar
2010-11-06 1:19 ` [PATCH 2/6] OMAP3: hwmod data: Add mmu for iva2 and isp Omar Ramirez Luna
2010-11-06 19:15 ` Cousson, Benoit
2010-11-07 16:00 ` Ramirez Luna, Omar
2010-11-08 23:05 ` Cousson, Benoit
2010-11-08 23:52 ` Ramirez Luna, Omar
2010-11-06 1:19 ` [PATCH 3/6] OMAP4: hwmod data: add mmu hwmod for ducati and tesla Omar Ramirez Luna
2010-11-06 20:47 ` Cousson, Benoit
2010-11-07 16:18 ` Ramirez Luna, Omar
2010-11-08 23:21 ` Cousson, Benoit
2010-11-08 23:48 ` Ramirez Luna, Omar
2010-11-09 0:03 ` Cousson, Benoit
2010-11-06 1:19 ` [PATCH 4/6] omap: iommu: intial hwmod support Omar Ramirez Luna
2010-11-06 21:05 ` Cousson, Benoit
2010-11-07 16:21 ` Ramirez Luna, Omar
2010-11-06 1:19 ` [PATCH 5/6] omap: iommu: hwmod device enable/disable routines Omar Ramirez Luna
2010-11-06 21:17 ` Cousson, Benoit
2010-11-07 16:24 ` Ramirez Luna, Omar
2010-11-06 1:19 ` [PATCH 6/6] omap: iommu: code reorganization and cleanup Omar Ramirez Luna
2010-11-06 8:34 ` Felipe Contreras
2010-11-07 16:29 ` Ramirez Luna, Omar
2010-11-06 21:28 ` Cousson, Benoit
2010-11-07 16:27 ` Ramirez Luna, Omar
2010-11-06 1:32 ` [PATCH 0/6] omap: iommu: hwmod support and code reorganization Ramirez Luna, Omar
2010-11-06 18:31 ` Cousson, Benoit
2010-11-07 15:43 ` Ramirez Luna, Omar
2010-11-08 21:56 ` Cousson, Benoit
2010-11-06 18:56 ` Cousson, Benoit [this message]
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=4CD5A4E9.1050106@ti.com \
--to=b-cousson@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox