From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Paul Walmsley <paul@pwsan.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: Rajendra Nayak <rnayak@ti.com>, Benoit Cousson <b-cousson@ti.com>
Subject: RE: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
Date: Wed, 8 Dec 2010 15:18:27 +0530 [thread overview]
Message-ID: <0adb8bf19a1586d582ac168dcbfc4f5e@mail.gmail.com> (raw)
In-Reply-To: <20101208061829.30541.99531.stgit@twilight.localdomain>
Paul,
> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Wednesday, December 08, 2010 11:49 AM
> To: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Cc: Rajendra Nayak; Santosh Shilimkar; Benoīt Cousson
> Subject: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific
> accessor/mutatorfunctions
>
> In some ways, the OMAP4 PRCM register layout is quite different than
> the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a
> register layout point of view, all CM instances were located in the CM
> subsystem, and all PRM instances were located in the PRM subsystem.
> OMAP4 changes this. Now, for example, some CM instances, such as
> WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a
> "local PRCM" exists for the MPU - this PRCM combines registers that
> would normally appear in both CM and PRM instances, but uses its own
> register layout which matches neither the OMAP2/3 PRCM layout nor the
> OMAP4 PRCM layout.
>
> To try to deal with this, introduce some new functions, omap4_cminst*
> and omap4_prminst*. The former is to be used when writing to a CM
> instance register (no matter what subsystem or hardware module it
> exists in), and the latter, similarly, with PRM instance registers.
> To determine which "PRCM partition" to write to, the functions take a
> PRCM instance ID argument. Subsequent patches add these partition IDs
> to the OMAP4 powerdomain and clockdomain definitions.
>
Thanks a lot for this cleanup.
> As far as I can see, there's really no good way to handle these types
> of register access inconsistencies. This patch seemed like the least
> bad approach.
>
> Moving forward, the long-term goal is to remove all direct PRCM
> register access from the PM code. PRCM register access should go
> through layers such as the powerdomain and clockdomain code that can
> hide the details of how to interact with the specific hardware
> variant.
>
One more possible road block of removing the direct register access
from PM code is DEVICE PRM module. Even with this clean-up for DEVCIE
PRM related registers. I guess we still need to use the lowest level
APIs.
> While here, rename cm4xxx.c to cm44xx.c to match the naming convention
> of the other OMAP4 PRCM files.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Benoīt Cousson <b-cousson@ti.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/Makefile | 4 +
> arch/arm/mach-omap2/cm1_44xx.h | 5 +
> arch/arm/mach-omap2/cm2_44xx.h | 6 ++
> arch/arm/mach-omap2/cm44xx.c | 52 ++++++++++++++
> arch/arm/mach-omap2/cm4xxx.c | 62 -----------------
> arch/arm/mach-omap2/cminst44xx.c | 118
> ++++++++++++++++++++++++++++++++
> arch/arm/mach-omap2/prcm.c | 26 -------
> arch/arm/mach-omap2/prcm44xx.h | 42 +++++++++++
> arch/arm/mach-omap2/prcm_mpu44xx.c | 45 ++++++++++++
> arch/arm/mach-omap2/prcm_mpu44xx.h | 8 ++
> arch/arm/mach-omap2/prm44xx.c | 65 ++++++++++++++++++
> arch/arm/mach-omap2/prm44xx.h | 6 ++
> arch/arm/mach-omap2/prminst44xx.c | 74 ++++++++++++++++++++
> arch/arm/mach-omap2/prminst44xx.h | 25 +++++++
> arch/arm/plat-omap/include/plat/prcm.h | 7 +-
> 15 files changed, 454 insertions(+), 91 deletions(-)
> create mode 100644 arch/arm/mach-omap2/cm44xx.c
> delete mode 100644 arch/arm/mach-omap2/cm4xxx.c
> create mode 100644 arch/arm/mach-omap2/cminst44xx.c
> create mode 100644 arch/arm/mach-omap2/prcm44xx.h
> create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.c
> create mode 100644 arch/arm/mach-omap2/prminst44xx.c
> create mode 100644 arch/arm/mach-omap2/prminst44xx.h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions
Date: Wed, 8 Dec 2010 15:18:27 +0530 [thread overview]
Message-ID: <0adb8bf19a1586d582ac168dcbfc4f5e@mail.gmail.com> (raw)
In-Reply-To: <20101208061829.30541.99531.stgit@twilight.localdomain>
Paul,
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Wednesday, December 08, 2010 11:49 AM
> To: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: Rajendra Nayak; Santosh Shilimkar; Beno?t Cousson
> Subject: [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific
> accessor/mutatorfunctions
>
> In some ways, the OMAP4 PRCM register layout is quite different than
> the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a
> register layout point of view, all CM instances were located in the CM
> subsystem, and all PRM instances were located in the PRM subsystem.
> OMAP4 changes this. Now, for example, some CM instances, such as
> WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a
> "local PRCM" exists for the MPU - this PRCM combines registers that
> would normally appear in both CM and PRM instances, but uses its own
> register layout which matches neither the OMAP2/3 PRCM layout nor the
> OMAP4 PRCM layout.
>
> To try to deal with this, introduce some new functions, omap4_cminst*
> and omap4_prminst*. The former is to be used when writing to a CM
> instance register (no matter what subsystem or hardware module it
> exists in), and the latter, similarly, with PRM instance registers.
> To determine which "PRCM partition" to write to, the functions take a
> PRCM instance ID argument. Subsequent patches add these partition IDs
> to the OMAP4 powerdomain and clockdomain definitions.
>
Thanks a lot for this cleanup.
> As far as I can see, there's really no good way to handle these types
> of register access inconsistencies. This patch seemed like the least
> bad approach.
>
> Moving forward, the long-term goal is to remove all direct PRCM
> register access from the PM code. PRCM register access should go
> through layers such as the powerdomain and clockdomain code that can
> hide the details of how to interact with the specific hardware
> variant.
>
One more possible road block of removing the direct register access
from PM code is DEVICE PRM module. Even with this clean-up for DEVCIE
PRM related registers. I guess we still need to use the lowest level
APIs.
> While here, rename cm4xxx.c to cm44xx.c to match the naming convention
> of the other OMAP4 PRCM files.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Beno?t Cousson <b-cousson@ti.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/Makefile | 4 +
> arch/arm/mach-omap2/cm1_44xx.h | 5 +
> arch/arm/mach-omap2/cm2_44xx.h | 6 ++
> arch/arm/mach-omap2/cm44xx.c | 52 ++++++++++++++
> arch/arm/mach-omap2/cm4xxx.c | 62 -----------------
> arch/arm/mach-omap2/cminst44xx.c | 118
> ++++++++++++++++++++++++++++++++
> arch/arm/mach-omap2/prcm.c | 26 -------
> arch/arm/mach-omap2/prcm44xx.h | 42 +++++++++++
> arch/arm/mach-omap2/prcm_mpu44xx.c | 45 ++++++++++++
> arch/arm/mach-omap2/prcm_mpu44xx.h | 8 ++
> arch/arm/mach-omap2/prm44xx.c | 65 ++++++++++++++++++
> arch/arm/mach-omap2/prm44xx.h | 6 ++
> arch/arm/mach-omap2/prminst44xx.c | 74 ++++++++++++++++++++
> arch/arm/mach-omap2/prminst44xx.h | 25 +++++++
> arch/arm/plat-omap/include/plat/prcm.h | 7 +-
> 15 files changed, 454 insertions(+), 91 deletions(-)
> create mode 100644 arch/arm/mach-omap2/cm44xx.c
> delete mode 100644 arch/arm/mach-omap2/cm4xxx.c
> create mode 100644 arch/arm/mach-omap2/cminst44xx.c
> create mode 100644 arch/arm/mach-omap2/prcm44xx.h
> create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.c
> create mode 100644 arch/arm/mach-omap2/prminst44xx.c
> create mode 100644 arch/arm/mach-omap2/prminst44xx.h
>
next prev parent reply other threads:[~2010-12-08 9:48 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 6:18 [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part two Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutator functions Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 9:48 ` Santosh Shilimkar [this message]
2010-12-08 9:48 ` [PATCH 01/11] OMAP4: PRCM: add OMAP4-specific accessor/mutatorfunctions Santosh Shilimkar
2010-12-11 1:55 ` Paul Walmsley
2010-12-11 1:55 ` Paul Walmsley
2010-12-11 7:32 ` Santosh Shilimkar
2010-12-11 7:32 ` Santosh Shilimkar
2010-12-08 12:33 ` Rajendra Nayak
2010-12-08 12:33 ` Rajendra Nayak
2010-12-15 6:48 ` Paul Walmsley
2010-12-15 6:48 ` Paul Walmsley
2010-12-15 11:08 ` Rajendra Nayak
2010-12-15 11:08 ` Rajendra Nayak
2010-12-15 11:57 ` Santosh Shilimkar
2010-12-15 11:57 ` Santosh Shilimkar
2010-12-15 12:43 ` Cousson, Benoit
2010-12-15 12:43 ` Cousson, Benoit
2010-12-18 10:47 ` Paul Walmsley
2010-12-18 10:47 ` Paul Walmsley
2010-12-08 13:50 ` Rajendra Nayak
2010-12-08 13:50 ` Rajendra Nayak
2010-12-08 19:46 ` Paul Walmsley
2010-12-08 19:46 ` Paul Walmsley
2010-12-08 20:16 ` Paul Walmsley
2010-12-08 20:16 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 02/11] OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 03/11] OMAP2/3: PRM/CM: prefix OMAP2 PRM/CM functions with "omap2_" Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 04/11] OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 05/11] OMAP2+: clockdomains: split the clkdm hwsup enable/disable function Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 23:12 ` Kevin Hilman
2010-12-08 23:12 ` Kevin Hilman
2010-12-09 0:00 ` Paul Walmsley
2010-12-09 0:00 ` Paul Walmsley
2010-12-11 1:36 ` Paul Walmsley
2010-12-11 1:36 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 06/11] OMAP4: CM instances: add clockdomain register offsets Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 07/11] OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 08/11] OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM register accesses Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 09/11] OMAP2+: clockdomain: move header file from plat-omap to mach-omap2 Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-15 5:39 ` Paul Walmsley
2010-12-15 5:39 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 10/11] OMAP2+: powerdomain: " Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-15 5:37 ` Paul Walmsley
2010-12-15 5:37 ` Paul Walmsley
2010-12-15 5:51 ` Paul Walmsley
2010-12-15 5:51 ` Paul Walmsley
2010-12-08 6:18 ` [PATCH 11/11] OMAP3: control/PM: move padconf save code to mach-omap2/control.c Paul Walmsley
2010-12-08 6:18 ` Paul Walmsley
2010-12-09 14:19 ` [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38, part two Jarkko Nikula
2010-12-09 14:19 ` Jarkko Nikula
2010-12-09 17:41 ` Paul Walmsley
2010-12-09 17:41 ` Paul Walmsley
2010-12-14 14:40 ` [PATCH 00/11] OMAP: PRCM/powerdomain/clockdomain patches for 2.6.38,part two Rajendra Nayak
2010-12-14 14:40 ` Rajendra Nayak
2010-12-15 3:57 ` Paul Walmsley
2010-12-15 3:57 ` Paul Walmsley
2010-12-15 11:14 ` Rajendra Nayak
2010-12-15 11:14 ` Rajendra Nayak
2010-12-15 4:15 ` Santosh Shilimkar
2010-12-15 4:15 ` Santosh Shilimkar
2010-12-15 4:27 ` Paul Walmsley
2010-12-15 4:27 ` Paul Walmsley
2010-12-15 6:15 ` Santosh Shilimkar
2010-12-15 6:15 ` Santosh Shilimkar
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=0adb8bf19a1586d582ac168dcbfc4f5e@mail.gmail.com \
--to=santosh.shilimkar@ti.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rnayak@ti.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.