* [PATCH v5 0/3] AM3517: Booting up
@ 2011-09-30 6:12 Abhilash K V
2011-09-30 6:12 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Abhilash K V
0 siblings, 1 reply; 13+ messages in thread
From: Abhilash K V @ 2011-09-30 6:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Abhilash K V <abhilash.kv@ti.com>
This patch-set gets the kernel booting up on a AM3517 EVM.
The board is able to boot with ramdisk after this,but the MMC and Ethernet
drivers are not up yet. Lots of warnings remain which will be addressed in
subsequent patches.
The patches are tested on master of git://github.com/tmlind/linux.git
Kernel version is 3.1.0-rc8 and last commit on top of which these patches
were added is:
1dd8838c74476fe13e51334ad2444e6c963cf5ff: Linux-omap rebuilt:
Updated to -rc8, merged l3 fixes
Cc: Sanjeev Premi <premi@ti.com>
---
Changes in v5:
-[1/3] was reworked to use the new method to select hwmods between
different omap3 variants/revisions.
-minor code reformatting in [3/3]
Changes in v4:
-Rebased and tested against the latest 3.1.0-rc6.
-Added a patch [3/3] to check for missing PMIC info in vp init.
Changes in v3:
Presence of SR feature is now used to decide if TWL4030 initialisation is to
be done or not.
Changes in v2: Incorporated Kevin's comments to add SmartReflex as a FEATURE,
and use omap3_has_sr() to fall out of omap3_twl_init() for AM35x case.
Abhilash K V (3):
AM35x: Using OMAP3 generic hwmods
omap_twl: Prevent SR to enable for am3517/am3505 devices
OMAP2+: voltage: add check for missing PMIC info in vp init
arch/arm/mach-omap2/id.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 ++++++++++++-----
arch/arm/mach-omap2/pm.c | 3 ++-
arch/arm/mach-omap2/vp.c | 7 +++++++
arch/arm/plat-omap/include/plat/cpu.h | 2 ++
5 files changed, 24 insertions(+), 7 deletions(-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods
2011-09-30 6:12 [PATCH v5 0/3] AM3517: Booting up Abhilash K V
@ 2011-09-30 6:12 ` Abhilash K V
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Abhilash K V @ 2011-09-30 6:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Abhilash K V <abhilash.kv@ti.com>
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
New in v5: reworked to use the new approach to select
device-specific hwmods as suggested by PaulW here
http://marc.info/?l=linux-kernel&m=131671863104802&w=2
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3008e16..8de6dc4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3159,7 +3159,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_mmc2_hwmod,
&omap3xxx_mmc3_hwmod,
&omap3xxx_mpu_hwmod,
- &omap3xxx_iva_hwmod,
&omap3xxx_timer1_hwmod,
&omap3xxx_timer2_hwmod,
@@ -3188,8 +3187,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_i2c1_hwmod,
&omap3xxx_i2c2_hwmod,
&omap3xxx_i2c3_hwmod,
- &omap34xx_sr1_hwmod,
- &omap34xx_sr2_hwmod,
/* gpio class */
&omap3xxx_gpio1_hwmod,
@@ -3211,8 +3208,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_mcbsp2_sidetone_hwmod,
&omap3xxx_mcbsp3_sidetone_hwmod,
- /* mailbox class */
- &omap3xxx_mailbox_hwmod,
/* mcspi class */
&omap34xx_mcspi1,
@@ -3225,31 +3220,43 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
/* 3430ES1-only hwmods */
static __initdata struct omap_hwmod *omap3430es1_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap3430es1_dss_core_hwmod,
+ /* mailbox class */
+ &omap3xxx_mailbox_hwmod,
NULL
};
/* 3430ES2+-only hwmods */
static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap3xxx_dss_core_hwmod,
&omap3xxx_usbhsotg_hwmod,
+ /* mailbox class */
+ &omap3xxx_mailbox_hwmod,
NULL
};
/* 34xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap34xx_sr1_hwmod,
&omap34xx_sr2_hwmod,
+ /* mailbox class */
+ &omap3xxx_mailbox_hwmod,
NULL
};
/* 36xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap36xx_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap3xxx_uart4_hwmod,
&omap3xxx_dss_core_hwmod,
&omap36xx_sr1_hwmod,
&omap36xx_sr2_hwmod,
&omap3xxx_usbhsotg_hwmod,
+ /* mailbox class */
+ &omap3xxx_mailbox_hwmod,
NULL
};
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
2011-09-30 6:12 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Abhilash K V
@ 2011-09-30 6:12 ` Abhilash K V
2011-09-30 6:12 ` [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init Abhilash K V
2011-09-30 21:00 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Kevin Hilman
2011-09-30 8:17 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Paul Walmsley
2011-10-07 9:12 ` Paul Walmsley
2 siblings, 2 replies; 13+ messages in thread
From: Abhilash K V @ 2011-09-30 6:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Abhilash K V <abhilash.kv@ti.com>
In case of AM3517 & AM3505, SmartReflex is not applicable so
we must not enable it. So omap3_twl_init() is now not called
when the processor does not support SR.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/id.c | 2 +-
arch/arm/mach-omap2/pm.c | 3 ++-
arch/arm/plat-omap/include/plat/cpu.h | 2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d27daf9..b7e3082 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -188,7 +188,7 @@ static void __init omap3_check_features(void)
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK;
if (!cpu_is_omap3505() && !cpu_is_omap3517())
- omap_features |= OMAP3_HAS_IO_WAKEUP;
+ omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
omap_features |= OMAP3_HAS_SDRC;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 0844e2e..6835198 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -250,7 +250,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
/* Init the OMAP TWL parameters */
- omap3_twl_init();
+ if (omap3_has_sr())
+ omap3_twl_init();
omap4_twl_init();
/* Init the voltage layer */
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 2f90269..cc6fcd3 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -413,6 +413,7 @@ extern u32 omap_features;
#define OMAP4_HAS_MPU_1GHZ BIT(8)
#define OMAP4_HAS_MPU_1_2GHZ BIT(9)
#define OMAP4_HAS_MPU_1_5GHZ BIT(10)
+#define OMAP3_HAS_SR BIT(11)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -429,6 +430,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
OMAP3_HAS_FEATURE(sdrc, SDRC)
+OMAP3_HAS_FEATURE(sr, SR)
/*
* Runtime detection of OMAP4 features
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
@ 2011-09-30 6:12 ` Abhilash K V
2011-09-30 18:41 ` Paul Walmsley
2011-09-30 21:10 ` Kevin Hilman
2011-09-30 21:00 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Kevin Hilman
1 sibling, 2 replies; 13+ messages in thread
From: Abhilash K V @ 2011-09-30 6:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Abhilash K V <abhilash.kv@ti.com>
If PMIC info is not available in omap_vp_init(), abort.
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/vp.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 66bd700..0ed3d13 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
u32 val, sys_clk_rate, timeout, waittime;
u32 vddmin, vddmax, vstepmin, vstepmax;
+ if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
+ pr_err("%s: PMIC info requried to configure VP for "
+ "vdd_%s not populated.Hence cannot initialize VP\n",
+ __func__, voltdm->name);
+ return;
+ }
+
if (!voltdm->read || !voltdm->write) {
pr_err("%s: No read/write API for accessing vdd_%s regs\n",
__func__, voltdm->name);
--
1.7.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods
2011-09-30 6:12 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Abhilash K V
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
@ 2011-09-30 8:17 ` Paul Walmsley
2011-10-07 9:12 ` Paul Walmsley
2 siblings, 0 replies; 13+ messages in thread
From: Paul Walmsley @ 2011-09-30 8:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Abhilash,
On Fri, 30 Sep 2011, Abhilash K V wrote:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
> the base omap3xxx_hwmods list, so that they can be excluded
> for am35x.
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
Looks good to me, provisionally queued for 3.2 fixes.
- Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
2011-09-30 6:12 ` [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init Abhilash K V
@ 2011-09-30 18:41 ` Paul Walmsley
2011-09-30 22:14 ` Kevin Hilman
2011-09-30 21:10 ` Kevin Hilman
1 sibling, 1 reply; 13+ messages in thread
From: Paul Walmsley @ 2011-09-30 18:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On Fri, 30 Sep 2011, Abhilash K V wrote:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> If PMIC info is not available in omap_vp_init(), abort.
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
> ---
> arch/arm/mach-omap2/vp.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 66bd700..0ed3d13 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
> u32 val, sys_clk_rate, timeout, waittime;
> u32 vddmin, vddmax, vstepmin, vstepmax;
>
> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
> + pr_err("%s: PMIC info requried to configure VP for "
> + "vdd_%s not populated.Hence cannot initialize VP\n",
> + __func__, voltdm->name);
> + return;
> + }
> +
Just wondering about the intent of this patch. Is the goal here to not
call omap_vp_init() for chips that don't have a VP IP block? If so, then
implementing code that does that directly seems like a better approach
than using the PMIC data? Because it seems likely that even SoCs without
VP IP blocks will have PMICs on the board, right?
- Paul
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
2011-09-30 6:12 ` [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init Abhilash K V
@ 2011-09-30 21:00 ` Kevin Hilman
2011-09-30 23:27 ` Kevin Hilman
1 sibling, 1 reply; 13+ messages in thread
From: Kevin Hilman @ 2011-09-30 21:00 UTC (permalink / raw)
To: linux-arm-kernel
Abhilash K V <abhilash.kv@ti.com> writes:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> In case of AM3517 & AM3505, SmartReflex is not applicable so
> we must not enable it. So omap3_twl_init() is now not called
> when the processor does not support SR.
This still isn't right.
The reason to skip the TWL PMIC init is not because SR is not available
(TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
init is because the PMIC is not present.
Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
only registered if a TWL driver is registered.
So, please drop hunk #2 from this patch, and just make this patch add a
new feature for the existence of SmartReflex. Removing the assumptions
and init for the existence of the TWL is a separate problem.
Kevin
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
> ---
> arch/arm/mach-omap2/id.c | 2 +-
> arch/arm/mach-omap2/pm.c | 3 ++-
> arch/arm/plat-omap/include/plat/cpu.h | 2 ++
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index d27daf9..b7e3082 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -188,7 +188,7 @@ static void __init omap3_check_features(void)
> if (cpu_is_omap3630())
> omap_features |= OMAP3_HAS_192MHZ_CLK;
> if (!cpu_is_omap3505() && !cpu_is_omap3517())
> - omap_features |= OMAP3_HAS_IO_WAKEUP;
> + omap_features |= (OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_SR);
>
> omap_features |= OMAP3_HAS_SDRC;
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 0844e2e..6835198 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -250,7 +250,8 @@ postcore_initcall(omap2_common_pm_init);
> static int __init omap2_common_pm_late_init(void)
> {
> /* Init the OMAP TWL parameters */
> - omap3_twl_init();
> + if (omap3_has_sr())
> + omap3_twl_init();
> omap4_twl_init();
>
> /* Init the voltage layer */
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
> index 2f90269..cc6fcd3 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -413,6 +413,7 @@ extern u32 omap_features;
> #define OMAP4_HAS_MPU_1GHZ BIT(8)
> #define OMAP4_HAS_MPU_1_2GHZ BIT(9)
> #define OMAP4_HAS_MPU_1_5GHZ BIT(10)
> +#define OMAP3_HAS_SR BIT(11)
>
>
> #define OMAP3_HAS_FEATURE(feat,flag) \
> @@ -429,6 +430,7 @@ OMAP3_HAS_FEATURE(isp, ISP)
> OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
> OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP)
> OMAP3_HAS_FEATURE(sdrc, SDRC)
> +OMAP3_HAS_FEATURE(sr, SR)
>
> /*
> * Runtime detection of OMAP4 features
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
2011-09-30 6:12 ` [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init Abhilash K V
2011-09-30 18:41 ` Paul Walmsley
@ 2011-09-30 21:10 ` Kevin Hilman
1 sibling, 0 replies; 13+ messages in thread
From: Kevin Hilman @ 2011-09-30 21:10 UTC (permalink / raw)
To: linux-arm-kernel
Abhilash K V <abhilash.kv@ti.com> writes:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> If PMIC info is not available in omap_vp_init(), abort.
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
Looks good.
After minor fixup below, adding to the next round of voltage cleanups
(branch: for_3.2/voltage-cleanup-2.)
> ---
> arch/arm/mach-omap2/vp.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
> index 66bd700..0ed3d13 100644
> --- a/arch/arm/mach-omap2/vp.c
> +++ b/arch/arm/mach-omap2/vp.c
> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
> u32 val, sys_clk_rate, timeout, waittime;
> u32 vddmin, vddmax, vstepmin, vstepmax;
>
> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
> + pr_err("%s: PMIC info requried to configure VP for "
> + "vdd_%s not populated.Hence cannot initialize VP\n",
Added space after '.'
Thanks,
Kevin
> + __func__, voltdm->name);
> + return;
> + }
> +
> if (!voltdm->read || !voltdm->write) {
> pr_err("%s: No read/write API for accessing vdd_%s regs\n",
> __func__, voltdm->name);
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init
2011-09-30 18:41 ` Paul Walmsley
@ 2011-09-30 22:14 ` Kevin Hilman
0 siblings, 0 replies; 13+ messages in thread
From: Kevin Hilman @ 2011-09-30 22:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Paul,
Paul Walmsley <paul@pwsan.com> writes:
> On Fri, 30 Sep 2011, Abhilash K V wrote:
>
>> From: Abhilash K V <abhilash.kv@ti.com>
>>
>> If PMIC info is not available in omap_vp_init(), abort.
>>
>> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
>> ---
>> arch/arm/mach-omap2/vp.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
>> index 66bd700..0ed3d13 100644
>> --- a/arch/arm/mach-omap2/vp.c
>> +++ b/arch/arm/mach-omap2/vp.c
>> @@ -41,6 +41,13 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
>> u32 val, sys_clk_rate, timeout, waittime;
>> u32 vddmin, vddmax, vstepmin, vstepmax;
>>
>> + if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel) {
>> + pr_err("%s: PMIC info requried to configure VP for "
>> + "vdd_%s not populated.Hence cannot initialize VP\n",
>> + __func__, voltdm->name);
>> + return;
>> + }
>> +
>
> Just wondering about the intent of this patch. Is the goal here to not
> call omap_vp_init() for chips that don't have a VP IP block? If so, then
> implementing code that does that directly seems like a better approach
> than using the PMIC data? Because it seems likely that even SoCs without
> VP IP blocks will have PMICs on the board, right?
You're right, this isn't really relevant for this series since AM35x
doesn't have VP, and hence shouldn't even be calling omap_vp_init().
However, this does fix a bug on devices that do have VP where the VP is
initialized before PMIC info has been registered.
So, I'll queue this patch as a fix for the voltage layer, but it should
not have been included in the AM35x series.
Kevin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
2011-09-30 21:00 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Kevin Hilman
@ 2011-09-30 23:27 ` Kevin Hilman
2011-10-11 7:59 ` Koyamangalath, Abhilash
0 siblings, 1 reply; 13+ messages in thread
From: Kevin Hilman @ 2011-09-30 23:27 UTC (permalink / raw)
To: linux-arm-kernel
Abhilash,
Kevin Hilman <khilman@ti.com> writes:
> Abhilash K V <abhilash.kv@ti.com> writes:
>
>> From: Abhilash K V <abhilash.kv@ti.com>
>>
>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>> we must not enable it. So omap3_twl_init() is now not called
>> when the processor does not support SR.
>
> This still isn't right.
>
> The reason to skip the TWL PMIC init is not because SR is not available
> (TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
> init is because the PMIC is not present.
>
> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
> only registered if a TWL driver is registered.
>
Below is a test patch that is a first pass at implementing what I
suggested above. I tested this (along with your patch 3/3) on a
3430/n900 after removing the omap_pmic_init() call frome the board file.
Can you let me know if this solves the problem you're seeing on
platforms that don't have TWL PMICs?
After digging into this more, I'm increasingly aware that the way we're
managing the init of PMIC stuff is a mess. Guess I need another round
of voltage layer cleanups to fix that up.
Kevin
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods
2011-09-30 6:12 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Abhilash K V
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
2011-09-30 8:17 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Paul Walmsley
@ 2011-10-07 9:12 ` Paul Walmsley
2 siblings, 0 replies; 13+ messages in thread
From: Paul Walmsley @ 2011-10-07 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Fri, 30 Sep 2011, Abhilash K V wrote:
> From: Abhilash K V <abhilash.kv@ti.com>
>
> Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
> the base omap3xxx_hwmods list, so that they can be excluded
> for am35x.
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
I've dropped the mailbox class comments from this patch -- updated patch
below:
- Paul
From: Abhilash K V <abhilash.kv@ti.com>
Date: Fri, 7 Oct 2011 03:08:56 -0600
Subject: [PATCH] AM35x: Using OMAP3 generic hwmods
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
[paul at pwsan.com: dropped 'mailbox class' comments]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..ac12cd5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3132,7 +3132,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_mmc2_hwmod,
&omap3xxx_mmc3_hwmod,
&omap3xxx_mpu_hwmod,
- &omap3xxx_iva_hwmod,
&omap3xxx_timer1_hwmod,
&omap3xxx_timer2_hwmod,
@@ -3161,8 +3160,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_i2c1_hwmod,
&omap3xxx_i2c2_hwmod,
&omap3xxx_i2c3_hwmod,
- &omap34xx_sr1_hwmod,
- &omap34xx_sr2_hwmod,
/* gpio class */
&omap3xxx_gpio1_hwmod,
@@ -3184,8 +3181,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_mcbsp2_sidetone_hwmod,
&omap3xxx_mcbsp3_sidetone_hwmod,
- /* mailbox class */
- &omap3xxx_mailbox_hwmod,
/* mcspi class */
&omap34xx_mcspi1,
@@ -3198,31 +3193,39 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
/* 3430ES1-only hwmods */
static __initdata struct omap_hwmod *omap3430es1_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap3430es1_dss_core_hwmod,
+ &omap3xxx_mailbox_hwmod,
NULL
};
/* 3430ES2+-only hwmods */
static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap3xxx_dss_core_hwmod,
&omap3xxx_usbhsotg_hwmod,
+ &omap3xxx_mailbox_hwmod,
NULL
};
/* 34xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap34xx_sr1_hwmod,
&omap34xx_sr2_hwmod,
+ &omap3xxx_mailbox_hwmod,
NULL
};
/* 36xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap36xx_hwmods[] = {
+ &omap3xxx_iva_hwmod,
&omap3xxx_uart4_hwmod,
&omap3xxx_dss_core_hwmod,
&omap36xx_sr1_hwmod,
&omap36xx_sr2_hwmod,
&omap3xxx_usbhsotg_hwmod,
+ &omap3xxx_mailbox_hwmod,
NULL
};
--
1.7.6.3
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
2011-09-30 23:27 ` Kevin Hilman
@ 2011-10-11 7:59 ` Koyamangalath, Abhilash
2011-10-11 17:40 ` Kevin Hilman
0 siblings, 1 reply; 13+ messages in thread
From: Koyamangalath, Abhilash @ 2011-10-11 7:59 UTC (permalink / raw)
To: linux-arm-kernel
hi Kevin,
Apologies for the delayed response, I was on vacation.
On October 01, 2011 4:57 AM, Hilman, Kevin wrote:
>
> Abhilash,
>
> Kevin Hilman <khilman@ti.com> writes:
>
>> Abhilash K V <abhilash.kv@ti.com> writes:
>>
>>> From: Abhilash K V <abhilash.kv@ti.com>
>>>
>>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>>> we must not enable it. So omap3_twl_init() is now not called
>>> when the processor does not support SR.
>>
>> This still isn't right.
>>
>> The reason to skip the TWL PMIC init is not because SR is not available
>> (TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
>> init is because the PMIC is not present.
[Abhilash K V] yes, I understand now.
>>
>> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
>> only registered if a TWL driver is registered.
>>
>
> Below is a test patch that is a first pass at implementing what I
> suggested above. I tested this (along with your patch 3/3) on a
> 3430/n900 after removing the omap_pmic_init() call frome the board file.
[Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not already
pulled it into your branch).
>
> Can you let me know if this solves the problem you're seeing on
> platforms that don't have TWL PMICs?
[Abhilash K V] It should, I have validated on am3517_evm
>
> After digging into this more, I'm increasingly aware that the way we're
> managing the init of PMIC stuff is a mess. Guess I need another round
> of voltage layer cleanups to fix that up.
[Abhilash K V] True, and to add to this, the changes required to support only
ONE voltage-domain for am35xx would be too many, I believe.
>
>
> Kevin
>
> From 1cd49077829a262155b96f8fdcdcdd6c54d83ed5 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@ti.com>
> Date: Fri, 30 Sep 2011 11:24:04 -0700
> Subject: [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when
> device is present
>
> Current code registers voltage layer details for TWL PMIC even when a TWL
> has not been registered. Fix this to only register the TWL with voltage
> layer when the TWL PMIC is initialized by board-level code.
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/pm.c | 6 ++----
> arch/arm/mach-omap2/twl-common.c | 11 +++++++++++
> arch/arm/mach-omap2/twl-common.h | 3 +++
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index d34fc52..602fc66 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -23,6 +23,7 @@
> #include "powerdomain.h"
> #include "clockdomain.h"
> #include "pm.h"
> +#include "twl-common.h"
>
> static struct omap_device_pm_latency *pm_lats;
>
> @@ -251,11 +252,8 @@ postcore_initcall(omap2_common_pm_init);
>
> static int __init omap2_common_pm_late_init(void)
> {
> - /* Init the OMAP TWL parameters */
> - omap3_twl_init();
> - omap4_twl_init();
> -
> /* Init the voltage layer */
> + omap_pmic_late_init();
> omap_voltage_late_init();
>
> /* Initialize the voltages */
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index daa056e..47133fa 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -30,6 +30,7 @@
> #include <plat/usb.h>
>
> #include "twl-common.h"
> +#include "pm.h"
>
> static struct i2c_board_info __initdata pmic_i2c_board_info = {
> .addr = 0x48,
> @@ -48,6 +49,16 @@ void __init omap_pmic_init(int bus, u32 clkrate,
> omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
> }
>
> +void __init omap_pmic_late_init(void)
> +{
> + /* Init the OMAP TWL parameters (if PMIC has been registerd) */
> + if (!pmic_i2c_board_info.irq)
> + return;
> +
> + omap3_twl_init();
> + omap4_twl_init();
> +}
> +
> #if defined(CONFIG_ARCH_OMAP3)
> static struct twl4030_usb_data omap3_usb_pdata = {
> .usb_mode = T2_USB_MODE_ULPI,
> diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
> index 5e83a5b..275dde8 100644
> --- a/arch/arm/mach-omap2/twl-common.h
> +++ b/arch/arm/mach-omap2/twl-common.h
> @@ -1,6 +1,8 @@
> #ifndef __OMAP_PMIC_COMMON__
> #define __OMAP_PMIC_COMMON__
>
> +#include <plat/irqs.h>
> +
> #define TWL_COMMON_PDATA_USB (1 << 0)
> #define TWL_COMMON_PDATA_BCI (1 << 1)
> #define TWL_COMMON_PDATA_MADC (1 << 2)
> @@ -30,6 +32,7 @@ struct twl4030_platform_data;
>
> void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
> struct twl4030_platform_data *pmic_data);
> +void omap_pmic_late_init(void);
>
> static inline void omap2_pmic_init(const char *pmic_type,
> struct twl4030_platform_data *pmic_data)
> --
> 1.7.6
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
2011-10-11 7:59 ` Koyamangalath, Abhilash
@ 2011-10-11 17:40 ` Kevin Hilman
0 siblings, 0 replies; 13+ messages in thread
From: Kevin Hilman @ 2011-10-11 17:40 UTC (permalink / raw)
To: linux-arm-kernel
"Koyamangalath, Abhilash" <abhilash.kv@ti.com> writes:
> hi Kevin,
> Apologies for the delayed response, I was on vacation.
>
> On October 01, 2011 4:57 AM, Hilman, Kevin wrote:
>>
>> Abhilash,
>>
>> Kevin Hilman <khilman@ti.com> writes:
>>
>>> Abhilash K V <abhilash.kv@ti.com> writes:
>>>
>>>> From: Abhilash K V <abhilash.kv@ti.com>
>>>>
>>>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>>>> we must not enable it. So omap3_twl_init() is now not called
>>>> when the processor does not support SR.
>>>
>>> This still isn't right.
>>>
>>> The reason to skip the TWL PMIC init is not because SR is not available
>>> (TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
>>> init is because the PMIC is not present.
> [Abhilash K V] yes, I understand now.
>>>
>>> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
>>> only registered if a TWL driver is registered.
>>>
>>
>> Below is a test patch that is a first pass at implementing what I
>> suggested above. I tested this (along with your patch 3/3) on a
>> 3430/n900 after removing the omap_pmic_init() call frome the board file.
> [Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not already
> pulled it into your branch).
I haven't posted/merged this yet, but I will now that you've tested it.
Thanks.
>>
>> Can you let me know if this solves the problem you're seeing on
>> platforms that don't have TWL PMICs?
> [Abhilash K V] It should, I have validated on am3517_evm
Thanks, will add a Tested-by from you.
>> After digging into this more, I'm increasingly aware that the way we're
>> managing the init of PMIC stuff is a mess. Guess I need another round
>> of voltage layer cleanups to fix that up.
> [Abhilash K V] True, and to add to this, the changes required to support only
> ONE voltage-domain for am35xx would be too many, I believe.
I don't see that part to be an obstacle.
Let's just be sure to use the clock, clockdomain, powerdomain &
voltagedomain data files to describe the hardware. That is the only
scalable and maintainable way to support these devices.
Any core code changes to fix assumption's we've made that are now wrong
need to be raised and addressed.
Stated differently, we know we have assumptions in the PM core code that
may now be mistaken in light of these new AM3xxx devices. Rather than
try to trick the core PM code into thinking these devices are "normal"
OMAP3/4 devices, let's fix those assumptions so we can properly support
the new devices.
Kevin
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-10-11 17:40 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-30 6:12 [PATCH v5 0/3] AM3517: Booting up Abhilash K V
2011-09-30 6:12 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Abhilash K V
2011-09-30 6:12 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Abhilash K V
2011-09-30 6:12 ` [PATCH v5 3/3] OMAP2+: voltage: add check for missing PMIC info in vp init Abhilash K V
2011-09-30 18:41 ` Paul Walmsley
2011-09-30 22:14 ` Kevin Hilman
2011-09-30 21:10 ` Kevin Hilman
2011-09-30 21:00 ` [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices Kevin Hilman
2011-09-30 23:27 ` Kevin Hilman
2011-10-11 7:59 ` Koyamangalath, Abhilash
2011-10-11 17:40 ` Kevin Hilman
2011-09-30 8:17 ` [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods Paul Walmsley
2011-10-07 9:12 ` Paul Walmsley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).