From: Omar Ramirez Luna <omar.ramirez@ti.com>
To: Tony Lindgren <tony@atomide.com>, Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Cc: Russell King <linux@arm.linux.org.uk>,
Hari Kanigeri <h-kanigeri2@ti.com>,
Paul Walmsley <paul@pwsan.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
Benoit Cousson <b-cousson@ti.com>,
Omar Ramirez Luna <omar.ramirez@ti.com>,
"Govindraj.R" <govindraj.raja@ti.com>,
Charulatha V <charu@ti.com>, Ramesh Gupta <grgupta@ti.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/6] omap: iommu: hwmod support and code reorganization
Date: Fri, 5 Nov 2010 19:19:50 -0600 [thread overview]
Message-ID: <1289006396-27230-1-git-send-email-omar.ramirez@ti.com> (raw)
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
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(-)
WARNING: multiple messages have this Message-ID (diff)
From: omar.ramirez@ti.com (Omar Ramirez Luna)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/6] omap: iommu: hwmod support and code reorganization
Date: Fri, 5 Nov 2010 19:19:50 -0600 [thread overview]
Message-ID: <1289006396-27230-1-git-send-email-omar.ramirez@ti.com> (raw)
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
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(-)
next reply other threads:[~2010-11-06 1:30 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 1:19 Omar Ramirez Luna [this message]
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 1:19 ` Omar Ramirez Luna
2010-11-06 19:11 ` Cousson, Benoit
2010-11-06 19:11 ` Cousson, Benoit
2010-11-07 15:55 ` Ramirez Luna, Omar
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 1:19 ` Omar Ramirez Luna
2010-11-06 19:15 ` Cousson, Benoit
2010-11-06 19:15 ` Cousson, Benoit
2010-11-07 16:00 ` Ramirez Luna, Omar
2010-11-07 16:00 ` Ramirez Luna, Omar
2010-11-08 23:05 ` Cousson, Benoit
2010-11-08 23:05 ` Cousson, Benoit
2010-11-08 23:52 ` Ramirez Luna, Omar
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 1:19 ` Omar Ramirez Luna
2010-11-06 20:47 ` Cousson, Benoit
2010-11-06 20:47 ` Cousson, Benoit
2010-11-07 16:18 ` Ramirez Luna, Omar
2010-11-07 16:18 ` Ramirez Luna, Omar
2010-11-08 23:21 ` Cousson, Benoit
2010-11-08 23:21 ` Cousson, Benoit
2010-11-08 23:48 ` Ramirez Luna, Omar
2010-11-08 23:48 ` Ramirez Luna, Omar
2010-11-09 0:03 ` Cousson, Benoit
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 1:19 ` Omar Ramirez Luna
2010-11-06 21:05 ` Cousson, Benoit
2010-11-06 21:05 ` Cousson, Benoit
2010-11-07 16:21 ` Ramirez Luna, Omar
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 1:19 ` Omar Ramirez Luna
2010-11-06 21:17 ` Cousson, Benoit
2010-11-06 21:17 ` Cousson, Benoit
2010-11-07 16:24 ` Ramirez Luna, Omar
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 1:19 ` Omar Ramirez Luna
2010-11-06 8:34 ` Felipe Contreras
2010-11-06 8:34 ` Felipe Contreras
2010-11-07 16:29 ` Ramirez Luna, Omar
2010-11-07 16:29 ` Ramirez Luna, Omar
2010-11-06 21:28 ` Cousson, Benoit
2010-11-06 21:28 ` Cousson, Benoit
2010-11-07 16:27 ` Ramirez Luna, Omar
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 1:32 ` Ramirez Luna, Omar
2010-11-06 18:31 ` Cousson, Benoit
2010-11-06 18:31 ` Cousson, Benoit
2010-11-07 15:43 ` Ramirez Luna, Omar
2010-11-07 15:43 ` Ramirez Luna, Omar
2010-11-08 21:56 ` Cousson, Benoit
2010-11-08 21:56 ` Cousson, Benoit
2010-11-06 18:56 ` Cousson, Benoit
2010-11-06 18:56 ` Cousson, Benoit
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=1289006396-27230-1-git-send-email-omar.ramirez@ti.com \
--to=omar.ramirez@ti.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=b-cousson@ti.com \
--cc=charu@ti.com \
--cc=govindraj.raja@ti.com \
--cc=grgupta@ti.com \
--cc=h-kanigeri2@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paul@pwsan.com \
--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.