RE: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present
-Original Message- From: Hilman, Kevin Sent: Friday, November 18, 2011 12:51 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present Premi, Sanjeev pr...@ti.com writes: [...] If PMIC is not TWL family, then I don't expect any functions in twl_common.c to be called. This is the reason I wanted to know if the check on .irq in the patch is sufficient. If any PMIC requires sets pmic_i2c_board_info.irq then both omap3_twl_init() and omap4_twl_init() will be called. Only TWL PMICs should be calling these functions, as they are in code for TWL PMICs *only*. If you have a non-TWL PMIC, then you should not be using the omap_pmic_* functions. Admittedly, these omap_pmic_* functions should be renamed to be clear that they are TWL specific. Thanks. We also need mechanism - may be name - to identify the PMIC family at this stage; and that should be used to select the corresponding init function. ~sanjeev Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present
-Original Message-
From: Hilman, Kevin
Sent: Thursday, November 17, 2011 5:25 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with
voltage layer when device is present
Premi, Sanjeev pr...@ti.com writes:
-Original Message-
From: Hilman, Kevin
Sent: Friday, November 11, 2011 12:04 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with
voltage layer when device is present
Premi, Sanjeev pr...@ti.com writes:
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 khil...@ti.com
[...]
I have been out-of-loop from PM for some time. So my query may be
redundant:
1) What happens when different PMIC (not TWL series) is
registered
for AM35x? e.g. TPS65023
http://www.spinics.net/lists/linux-omap/msg48630.html
2) Wouldn't we still fall back into omap3_twl_init()?
I'm not sure I follow the question.
If you're not using a TWL PMIC (or similar derivative) then
omap*_twl_init() should not be called.
If you are using a TWL PMIC, then no, the omap*_twl_init functions
should not be called.
When I read this function (in the patch), if pmic_i2c_board_info.irq
is non-zero, omap3_twl_init() and omap4_twl_init() are called.
So my question was, for the case when PMIC is not TWL family. Then,
is checking .irq sufficient to prevent the execution of
twl specific
functions.
If PMIC is not TWL family, then I don't expect any functions in
twl_common.c to be called.
This is the reason I wanted to know if the check on .irq in the
patch is sufficient. If any PMIC requires sets pmic_i2c_board_info.irq
then both omap3_twl_init() and omap4_twl_init() will be called.
[quote]
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();
}
[/quote]
OR, is there something - beyond this patch that I may be missing.
~sanjeev
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present
-Original Message-
From: Hilman, Kevin
Sent: Friday, November 11, 2011 12:04 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with
voltage layer when device is present
Premi, Sanjeev pr...@ti.com writes:
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 khil...@ti.com
[...]
I have been out-of-loop from PM for some time. So my query may be
redundant:
1) What happens when different PMIC (not TWL series) is registered
for AM35x? e.g. TPS65023
http://www.spinics.net/lists/linux-omap/msg48630.html
2) Wouldn't we still fall back into omap3_twl_init()?
I'm not sure I follow the question.
If you're not using a TWL PMIC (or similar derivative) then
omap*_twl_init() should not be called.
If you are using a TWL PMIC, then no, the omap*_twl_init functions
should not be called.
When I read this function (in the patch), if pmic_i2c_board_info.irq
is non-zero, omap3_twl_init() and omap4_twl_init() are called.
So my question was, for the case when PMIC is not TWL family. Then,
is checking .irq sufficient to prevent the execution of twl specific
functions.
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();
}
Shouldn't we check for some signature or equiv, before calling the
PMIC specific init? This signature can be set when the PMIC is
registered?
Another simplification would be to register the PMIC specific init
function itself during registration; and call here.
~sanjeev
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Which toolchain are we using?
Hi all, I have been running latest linux-omap/master on OMAP3EVM (boot from MMC). When building with CodeSourcery 2011.03-41, I see frequent hangs just after Uncompressing Linux... done, booting the kernel However, builds with CodeSourcery 2009q1-203 boot consistently all the time. Before trying to investigate further, wanted to know if someone else has seen the problem. If no, which toolchain is being used. ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Wednesday, November 09, 2011 5:45 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
Subject: [PATCH] ARM: OMAP: 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 khil...@ti.com
---
Barring any objections, will be queued as a fix for v3.2-rc cycle.
Originally posted here:
http://marc.info/?l=linux-omapm=131831996730420w=2,
but posting again since it was buried inside this thread.
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 1e79bdf..00bff46 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -24,6 +24,7 @@
#include powerdomain.h
#include clockdomain.h
#include pm.h
+#include twl-common.h
static struct omap_device_pm_latency *pm_lats;
@@ -226,11 +227,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 52243577..10b20c6 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;
Kevin,
I have been out-of-loop from PM for some time. So my query may be
redundant:
1) What happens when different PMIC (not TWL series) is registered
for AM35x? e.g. TPS65023
http://www.spinics.net/lists/linux-omap/msg48630.html
2) Wouldn't we still fall back into omap3_twl_init()?
~sanjeev
+
+ 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
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] arm: omap: Fix errors and warnings when building for one board
-Original Message- From: Premi, Sanjeev Sent: Thursday, October 13, 2011 9:44 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Premi, Sanjeev Subject: [PATCH v2] arm: omap: Fix errors and warnings when building for one board When customizing omap2plus_defconfig to build for only one board (omap3evm), I came across these warnings and errors (filenames truncated): arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used arch/arm/mach-omap2/built-in.o: In function `omap2420_init_early': arch/arm/mach-omap2/io.c:364: undefined reference to `omap2_set_globals_242x' arch/arm/mach-omap2/io.c:366: undefined reference to `omap2xxx_voltagedomains_init' arch/arm/mach-omap2/io.c:367: undefined reference to `omap242x_powerdomains_init' arch/arm/mach-omap2/io.c:368: undefined reference to `omap242x_clockdomains_init' arch/arm/mach-omap2/io.c:369: undefined reference to `omap2420_hwmod_init' arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early': arch/arm/mach-omap2/io.c:376: undefined reference to `omap2_set_globals_243x' arch/arm/mach-omap2/io.c:378: undefined reference to `omap2xxx_voltagedomains_init' arch/arm/mach-omap2/io.c:379: undefined reference to `omap243x_powerdomains_init' arch/arm/mach-omap2/io.c:380: undefined reference to `omap243x_clockdomains_init' arch/arm/mach-omap2/io.c:381: undefined reference to `omap2430_hwmod_init' arch/arm/mach-omap2/built-in.o: In function `omap4430_init_early': arch/arm/mach-omap2/io.c:436: undefined reference to `omap2_set_globals_443x' arch/arm/mach-omap2/io.c:438: undefined reference to `omap44xx_voltagedomains_init' arch/arm/mach-omap2/io.c:439: undefined reference to `omap44xx_powerdomains_init' arch/arm/mach-omap2/io.c:440: undefined reference to `omap44xx_clockdomains_init' arch/arm/mach-omap2/io.c:441: undefined reference to `omap44xx_hwmod_init' This patch fixes them. Signed-off-by: Sanjeev Premi pr...@ti.com --- Changes since v1: - #if defined() to #ifdef - Moved an #ifdef to take care of additional warning related to sdp4430_twldata. Had missed squashing the patch before sending v1. Adding ifdefs makes the code bit ugly and is prone to propagate further. Not sure if DT will help here, but this patch would be useful for people trying to build for individual boards. Compile tested for OMAP3EVM. Applies to linux-omap/master at: fb4df0f : ARM: OMAP1: Fix warnings about enabling 32 KiHz timer arch/arm/mach-omap2/board-generic.c |8 arch/arm/mach-omap2/io.c|6 ++ 2 files changed, 14 insertions(+), 0 deletions(-) Tony, Just wanted to check the status of this patch. ~sanjeev-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin Sent: Tuesday, September 27, 2011 12:16 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; p...@pwsan.com; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Mohammed, Afzal Subject: Re: [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources hvaib...@ti.com writes: From: Afzal Mohammed af...@ti.com This patch updates the common machine specific source files for support for AM33XX/AM335x with cpu type, macros for identification of AM33XX/AM335X device. Signed-off-by: Afzal Mohammed af...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com [...] @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void) * Lock DPLL5 -- here only until other device init code can * handle this */ - if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0)) + if (!cpu_is_ti816x() !cpu_is_am33xx() + (omap_rev() = OMAP3430_REV_ES2_0)) omap3_clk_lock_dpll5(); This is getting ugly. Instead of continuing to expand this if-list, I think it's time for a new feature-flag for whether or not an SoC has DPLL5 instead. I agree that the code is really getting ugly here. But, isn't feature-flag going to be over-used with this and similar features? Just thinking ahead, for these possible cases: 1) An soc adds DPLL6. 2) An soc uses DPLL5, but mechanism to lock is different. Wouldn't it be better to have a scheme like this: 1) Define a simple structure for DPLLs. 2) Initialize the unused DPLLs to be null/ -1 early in arch/soc specific init. 3) The DPLL functions check for corresponding flag on entry. ~sanjeev Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3505 revisions?
Paul, Looks like I was unsubscribed from linux-omap sometime last week. Why? no idea! Anyways, I just looked at your mails. Will be responding with details in next hour. Will also attempt to re-subscribe in meantime. ~sanjeev -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, September 13, 2011 11:33 PM To: Premi, Sanjeev Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org Subject: OMAP3505 revisions? Hi Sanjeev Am looking at your commit 4cac6018, which touches arch/arm/mach-omap2/id.c. That commit implements SoC detection for the 3505 in a different way than the implementations for other OMAP2+ devices: it doesn't enumerate the possible TAP revisions for OMAP3505. The TRM doesn't seem to list those, either. And unfortunately that is blocking some of the omap_chip removal work. Could you send me a list of the possible revision values for the 3505/3517, along with mappings to ES levels, please? thanks - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3505 revisions?
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, September 13, 2011 11:33 PM To: Premi, Sanjeev Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org Subject: OMAP3505 revisions? Hi Sanjeev Am looking at your commit 4cac6018, which touches arch/arm/mach-omap2/id.c. That commit implements SoC detection for the 3505 in a different way than the implementations for other OMAP2+ devices: it doesn't enumerate the possible TAP revisions for OMAP3505. The TRM Paul, In the function omap3_check_revision(), the revision is being extracted from the TAP register for AM3505/AM3517 devices thru same code used for OMAP34xx registers. OR, Am I missing something? ~sanjeev doesn't seem to list those, either. And unfortunately that is blocking some of the omap_chip removal work. Could you send me a list of the possible revision values for the 3505/3517, along with mappings to ES levels, please? thanks - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3505 revisions?
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, September 14, 2011 5:11 PM To: Premi, Sanjeev Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org Subject: RE: OMAP3505 revisions? On Wed, 14 Sep 2011, Premi, Sanjeev wrote: Looks like I was unsubscribed from linux-omap sometime last week. Why? no idea! Bummer. Anyways, I just looked at your mails. Will be responding with details in next hour. Will also attempt to re-subscribe in meantime. Thanks. Could you try a test boot of the 'id_3517_cleanup_3.2' branch of git://git.pwsan.com/linux-2.6 on an AM3517/3505, or ask someone to try that out? Sure I will get this tested. ~sanjeev thanks, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3505 revisions?
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, September 14, 2011 7:19 PM To: Premi, Sanjeev Cc: nota...@gmail.com; t...@atomide.com; Igor Grinberg; linux-omap@vger.kernel.org Subject: RE: OMAP3505 revisions? On Wed, 14 Sep 2011, Premi, Sanjeev wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, September 14, 2011 5:11 PM To: Premi, Sanjeev Cc: nota...@gmail.com; t...@atomide.com; linux-omap@vger.kernel.org Subject: RE: OMAP3505 revisions? Thanks. Could you try a test boot of the 'id_3517_cleanup_3.2' branch of git://git.pwsan.com/linux-2.6 on an AM3517/3505, or ask someone to try that out? Sure I will get this tested. I just repushed this branch with changes to fix a bug that Igor found. If you've pulled it already, could you re-pull? I'm particularly interested in a test on a 3505 board. [sp] The pull is in progress (... bit slow). Not sure if we have a AM3505 board, but it can be simulated. ~sanjeev - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] omap_twl: Prevent SR to enable for am3517/am3505devices
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Tuesday, August 23, 2011 7:14 PM
To: Koyamangalath, Abhilash; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; li...@arm.linux.org.uk; Cousson, Benoit;
t...@atomide.com; linux-ker...@vger.kernel.org; Hiremath,
Vaibhav; linux-arm-ker...@lists.infradead.org
Subject: RE: [PATCH v2 2/2] omap_twl: Prevent SR to enable
for am3517/am3505devices
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Abhilash K V
Sent: Tuesday, August 23, 2011 6:51 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; li...@arm.linux.org.uk; b-cous...@ti.com;
t...@atomide.com; linux-ker...@vger.kernel.org; Vaibhav Hiremath;
Abhilash K V; linux-arm-ker...@lists.infradead.org
Subject: [PATCH v2 2/2] omap_twl: Prevent SR to enable for
am3517/am3505devices
From: Vaibhav Hiremath hvaib...@ti.com
In case of AM3517 AM3505, Smart Reflex is not applicable so
we must not enable it. So add check for absence of SR feature
in omap3_twl_init() and return -ENODEV if absence, else continue.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/omap_twl.c|8
arch/arm/plat-omap/include/plat/cpu.h |2 ++
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..da71098 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -202,7 +202,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/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 07d6140..47e27b5 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -269,6 +269,14 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
+ /*
+* In case of AM3517/AM3505 we should not be going down
+* further, since SR is not applicable there.
+*/
+ if (!omap3_has_sr()) {
+ return -ENODEV;
+ }
I do not understand what has vp_max and vp_min configuration
to do with
SR. This parameter indicates the maximum and minimum voltage
supported by
respective PM IC.
[sp] omap3_twl_init() shouldn't be executed for AM35x.
Considering that we are using SR as feature, the check
should be PMIC centric not SR centric.
~sanjeev
Vishwa
+
if (cpu_is_omap3630()) {
omap3_mpu_volt_info.vp_vddmin =
OMAP3630_VP1_VLIMITTO_VDDMIN;
omap3_mpu_volt_info.vp_vddmax =
OMAP3630_VP1_VLIMITTO_VDDMAX;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-
omap/include/plat/cpu.h
index 67b3d75..294e015 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -491,6 +491,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) \
@@ -507,6 +508,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
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP3: Remove auto-selection of PMICs
From: Samuel Ortiz [sa...@linux.intel.com] Sent: Monday, August 22, 2011 8:33 PM To: Koyamangalath, Abhilash Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk; Hilman, Kevin; Shilimkar, Santosh; Premi, Sanjeev; david.woodho...@intel.com Subject: Re: [PATCH 3/3] OMAP3: Remove auto-selection of PMICs Hi Anhilash, On Fri, Aug 19, 2011 at 05:19:33PM +0530, Abhilash K V wrote: The current implementation almost assumes that only TWL4030/TWL5030/TWl6030 are (or can be) used with the OMAP processors. This is, however, not true. I don't like the mfd/Kconfig change. Why would those drivers be only buildable on OMAP processors ? Unless there is a real reason for this, you should fix the drivers instead. You are right. The change for config item TWL4030_CORE should be removed. - depends on I2C=y GENERIC_HARDIRQS + depends on I2C=y GENERIC_HARDIRQS (ARCH_OMAP3 || ARCH_OMAP4) In fact, change for TWL4030_POWER should be - depends on TWL4030_CORE ARM + depends on TWL4030_CORE This would allow these PMICs to be used with other processors as well. There may be issues run-time issues; but they would most likely surface only when there is a combination without any of the OMAPs. (We would try a dummy build for another processor with TWL4030 selected.) The original idea was to ensure that nothing else breaks when the auto selection of the PMICs is removed. ~sanjeev Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] mfd: twl4030: Fix mismatch in mutex lock-unlock
-Original Message- From: Premi, Sanjeev Sent: Monday, July 11, 2011 8:51 PM To: linux-omap@vger.kernel.org Cc: Premi, Sanjeev; J, KEERTHY; Samuel Ortiz Subject: [PATCHv2] mfd: twl4030: Fix mismatch in mutex lock-unlock A mutex is locked on entry into twl4030_madc_conversion(). Immediate return on some error conditions leaves the mutex locked. This patch ensures that mutex is always unlocked before leaving the function. Signed-off-by: Sanjeev Premi pr...@ti.com Cc: Keerthy j-keer...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Samuel, Keerthy, Just wanted to ping both of you on this patch. ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
-Original Message- From: Kristo, Tero Sent: Thursday, July 14, 2011 12:41 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin Subject: RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6 On Wed, 2011-07-13 at 19:49 +0200, Premi, Sanjeev wrote: Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo, Tero Sent: Wednesday, July 13, 2011 7:31 PM To: linux-omap@vger.kernel.org Cc: broo...@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6 Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz. Signed-off-by: Tero Kristo t-kri...@ti.com --- [snip]...[snip] [sp] Basic support for 720MHz was already closed early this year. See: http://marc.info/?l=linux-omapm=129735630928696w=2 I cannot check the current tree status right now; but I assume the patch should already be in. Yea, I heard this was agreed upon, however it is not in the tree yet. Thus I just added this patch in the set for testing purposes... and tagged as TEMP. I noticed this today morning. Will be reposting it today after rebase. ~sanjeev ~sanjeev -- 1.7.4.1 Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo, Tero
Sent: Wednesday, July 13, 2011 7:31 PM
To: linux-omap@vger.kernel.org
Cc: broo...@opensource.wolfsonmicro.com; Girdwood, Liam; Hilman, Kevin
Subject: [PATCHv2 4/5] TEMP: OMAP3: beagle rev-c4: enable OPP6
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can
run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 32
+++
arch/arm/mach-omap2/opp3xxx_data.c |4 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d7ae648..5ab507d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -592,6 +592,38 @@ static void __init beagle_opp_init(void)
return;
}
+ /* Custom OPP enabled for C4 */
+ if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+ struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *dh = omap_hwmod_lookup(iva);
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+ __func__, mh, dh);
+ }
+ /* Enable MPU 720MHz opp */
+ dev = mh-od-pdev.dev;
+ r = opp_enable(dev, 72000);
+
+ /* Enable IVA 520MHz opp */
+ dev = dh-od-pdev.dev;
+ r |= opp_enable(dev, 52000);
+
+ if (r) {
+ pr_err(%s: failed to enable higher opp %d\n,
+ __func__, r);
+ /*
+ * Cleanup - disable the higher freqs -
we dont care
+ * about the results
+ */
+ dev = mh-od-pdev.dev;
+ opp_disable(dev, 72000);
+ dev = dh-od-pdev.dev;
+ opp_disable(dev, 52000);
+ }
+ }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(mpu, true, 55000,
OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6,
OMAP3430_VDD_MPU_OPP5_UV),
+ /* MPU OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(mpu, false, 72000,
OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage
for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(iva, true, 4,
OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000,
OMAP3430_VDD_MPU_OPP5_UV),
+ /* DSP OPP6 : omap3530 high speed grade only */
+ OPP_INITIALIZER(iva, false, 52000,
OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
[sp] Basic support for 720MHz was already closed early this year.
See: http://marc.info/?l=linux-omapm=129735630928696w=2
I cannot check the current tree status right now; but I assume
the patch should already be in.
~sanjeev
--
1.7.4.1
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus:
0115040-6. Kotipaikka: Helsinki
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [lm-sensors] [PATCH] mfd: twl4030: Fix mismatch in mutex lock-unlock
-Original Message- From: Jean Delvare [mailto:kh...@linux-fr.org] Sent: Saturday, July 09, 2011 12:21 PM To: Premi, Sanjeev Cc: lm-sens...@lm-sensors.org; linux-omap@vger.kernel.org Subject: Re: [lm-sensors] [PATCH] mfd: twl4030: Fix mismatch in mutex lock-unlock On Fri, 8 Jul 2011 18:27:59 +0530, Sanjeev Premi wrote: A mutex is locked on entry into twl4030_madc_conversion(). Immediate return on some error conditions leaves the mutex locked. This patch ensures that mutex is always unlocked before leaving the function. Signed-off-by: Sanjeev Premi pr...@ti.com Cc: Keerthy j-keer...@ti.com --- Compile tested only. drivers/mfd/twl4030-madc.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c index 3941ddc..b5d598c 100644 --- a/drivers/mfd/twl4030-madc.c +++ b/drivers/mfd/twl4030-madc.c (...) Wrong list. This isn't a hwmon driver, so lm-sensors isn't suitable. scripts/get_maintainer.pl says that you should send this patch to: Samuel Ortiz sa...@linux.intel.com [sp] I picked the list from the patch where this functionality was first introduced. Assumed that Samuel would on this list itself... sorry for noise :( ~sanjeev Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AM3505/3517 support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Wednesday, July 06, 2011 12:26 PM To: Raphaël Assénat; Paul Walmsley Cc: linux-omap@vger.kernel.org Subject: Re: AM3505/3517 support * Raphaël Assénat r...@8d.com [110705 07:30]: On 05/07/11 07:19 AM, Tony Lindgren wrote: * Raphaël Assénat r...@8d.com [110704 12:51]: The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem. Can you please describe where you need CHIP_IS for am3505? It seems that your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too? Actually it's only needed for the 3505/3517 specific UART 4 which should not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c) But there are also cases where OMAP3430 hwmods must not be registered on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's. Sounds like we should be able to handle both uart and gptimer12 the same way as we'll be handling the hwmod reset for special cases like gptimer12 for secure mode. So addding Paul to Cc. Basically we can have a am35xx specific arch_initcall that sets the special flags for these devices like noreset, disabled or unavailable. In this case we would just set some devices as unavailable on am35xx. [sp] AM35x is already supported in the kernel. Specifically for the changes being discussed, see this commit: commit 3cc4a2fc2ed7727828f410ab092111cb56cefd61 Author: Ranjith Lohithakshan ranji...@ti.com Date: Wed Feb 24 12:05:55 2010 -0700 AM35xx: Add clock support for new modules on AM35xx I believe this patch already contains most AM35xx specific changes related to clocks. I'd rather see us improve the code so we can support am3505 properly without a need to patch all over the place.. Maybe instead of having one big array of hwmods registered for all CPUs in omap_hwmod_3xxx_data we could have a separate one for am35xx (and maybe, eventually others) such as: static __initdata struct omap_hwmod *omap3xxx_hwmods[] static __initdata struct omap_hwmod *am35xx_hwmods[] ...and maybe also a 'common' array. [sp] I did sumbit a similar patch making 2 arrays, but Paul has sumbitted an updated patch that seemes to do away with need to make 2 arrays. http://marc.info/?l=linux-omapm=129983254729228w=2 The init function would then register the appropriate hwmod array(s). The only thing I don't like is that for this to work we would have to keep setting CHIP_IS_OMAP3430 even on AM35xx CPUs. But maybe we could change the behaviour of omap_hwmod_register to trust the caller and accept the hwmods without looking at the omap_chip member. By doing this I think we could drop all the .omap_chip = OMAP_CHIP_INIT(...) instances. Otherwise I think the current approach, despite the size of the initial patch, has at least the benefit of being explicit and less confusing than (ab)using the CHIP_IS from a different CPU. Well let's see how far we can get with passing the special case flags with omap2_init_devices(). Initially we can call that from the board-*.c file that should get your board booting. Then we can add the am35xx specific arch_initcall. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] AM3505/3517 ZCN package support
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat
Sent: Wednesday, July 06, 2011 8:59 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH] AM3505/3517 ZCN package support
This patch adds support for the AM35xx ZCN package specific muxmodes.
Signed-off-by: Raphael Assenat r...@8d.com
[sp] Few quick comments below:
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4ae6257..5c880de 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -103,6 +103,9 @@ config OMAP_PACKAGE_CBL
config OMAP_PACKAGE_CBS
bool
+config OMAP_PACKAGE_ZCN
+ bool
+
comment OMAP Board Type
depends on ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..f227503 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -62,6 +62,7 @@
/* Flags for omapX_mux_init */
#define OMAP_PACKAGE_MASK0x
+#define OMAP_PACKAGE_ZCN 9 /*
491-pin 0.65 */
#define OMAP_PACKAGE_CBS 8 /*
547-pin 0.40 0.40 */
#define OMAP_PACKAGE_CBL 7 /*
547-pin 0.40 0.40 */
#define OMAP_PACKAGE_CBP 6 /*
515-pin 0.40 0.50 */
diff --git a/arch/arm/mach-omap2/mux34xx.c
b/arch/arm/mach-omap2/mux34xx.c
index 17f80e4..d42ac2e 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -37,6 +37,9 @@
.balls = { bb, bt },
\
}
+#define _OMAP3_NULL_MUXENTRY(M0) _OMAP3_MUXENTRY(M0, 0,
NULL, NULL, \
+ NULL, NULL, NULL, NULL, NULL, NULL)
+
/*
* Superset of all mux modes for omap3
*/
@@ -651,51 +654,50 @@ static struct omap_mux __initdata
omap3_muxmodes[] = {
gpio_166, NULL, NULL, safe_mode),
/* Only on 3630, see omap36xx_cbp_subset for the signals */
- _OMAP3_MUXENTRY(GPMC_A11, 0,
- NULL, NULL, NULL, NULL,
- NULL, NULL, NULL, NULL),
[snip]...[snip]
+ _OMAP3_NULL_MUXENTRY(GPMC_A11),
+ _OMAP3_NULL_MUXENTRY(SAD2D_MBUSFLAG),
+ _OMAP3_NULL_MUXENTRY(SAD2D_MREAD),
[sp] These changes don't go with the current patch description.
You may want to keep them in a separate patch; and use here.
+
+ /* Only on AM35xx, see am35xx_zcn_subset for the signals */
+ _OMAP3_NULL_MUXENTRY(CCDC_PCLK),
+ _OMAP3_NULL_MUXENTRY(CCDC_FIELD),
+ _OMAP3_NULL_MUXENTRY(CCDC_HD),
+ _OMAP3_NULL_MUXENTRY(CCDC_VD),
+ _OMAP3_NULL_MUXENTRY(CCDC_WEN),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA0),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA1),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA2),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA3),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA4),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA5),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA6),
+ _OMAP3_NULL_MUXENTRY(CCDC_DATA7),
+ _OMAP3_NULL_MUXENTRY(RMII_MDIO_DATA),
+ _OMAP3_NULL_MUXENTRY(RMII_MDIO_CLK),
+ _OMAP3_NULL_MUXENTRY(RMII_RXD0),
+ _OMAP3_NULL_MUXENTRY(RMII_RXD1),
+ _OMAP3_NULL_MUXENTRY(RMII_CRS_DV),
+ _OMAP3_NULL_MUXENTRY(RMII_RXER),
+ _OMAP3_NULL_MUXENTRY(RMII_TXD0),
+ _OMAP3_NULL_MUXENTRY(RMII_TXD1),
+ _OMAP3_NULL_MUXENTRY(RMII_TXEN),
+ _OMAP3_NULL_MUXENTRY(RMII_50MHZ_CLK),
+ _OMAP3_NULL_MUXENTRY(USB0_DRVVBUS),
+ _OMAP3_NULL_MUXENTRY(HECC1_TXD),
+ _OMAP3_NULL_MUXENTRY(HECC1_RXD),
+
[sp] Extra line.
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -2026,6 +2028,490 @@ static struct omap_ball __initdata
omap36xx_cbp_ball[] = {
#define omap36xx_cbp_ball NULL
#endif
+/*
+ * Signals different on AM35XX ZCN package comapared to 34XX
CBC package
+ */
+#if defined(CONFIG_OMAP_MUX) defined(CONFIG_OMAP_PACKAGE_ZCN)
+static struct omap_mux __initdata am35xx_zcn_subset[] = {
[snip]...[snip]
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define am35xx_zcn_subsetNULL
+#endif
+
+/*
+ * Balls for AM35XX ZCN package
+ * 491-pin s-PBGA Package, 0.65mm Ball Pitch
+ */
+#if defined(CONFIG_OMAP_MUX) defined(CONFIG_DEBUG_FS)
\
+ defined (CONFIG_OMAP_PACKAGE_ZCN)
+static struct omap_ball __initdata am35xx_zcn_ball[] = {
[snip]...[snip]
+
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define am35xx_zcn_ball NULL
+#endif
+
+
[sp] Extra line.
int __init omap3_mux_init(struct omap_board_mux
*board_subset, int flags)
{
struct omap_mux *package_subset;
@@ -2048,6 +2534,10 @@ int __init omap3_mux_init(struct
omap_board_mux *board_subset, int flags)
package_subset = omap36xx_cbp_subset;
package_balls = omap36xx_cbp_ball;
break;
+ case OMAP_PACKAGE_ZCN:
+ package_subset = am35xx_zcn_subset;
+ package_balls
RE: AM3505/3517 support
-Original Message- From: Raphaël Assénat [mailto:r...@8d.com] Sent: Wednesday, July 06, 2011 7:29 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: AM3505/3517 support On 05/07/11 05:59 AM, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat Sent: Tuesday, July 05, 2011 12:59 AM To: linux-omap@vger.kernel.org Subject: AM3505/3517 support Hello, We have a custom designed based on the AM3505 and we wish to run a modern kernel on it. Unfortunately, it seems a lot of efforts have been made to support other OMAP chips and that some work is still required to support the AM3505/3517 completely. (does not boot as-is) Is there anyone working on this right now? Not knowing, I have already started working on it. The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem. I will send my patches in a moment for comments and hopefully, after a few iterations, they will be acceptable. I know a lot of cleanup is happening right now and as a result my patches may not apply or conflict. Please let me know and I will be happy to rebase them as needed. Looking forward to your comments and help. One of the next things I'll look at is how to properly support the ZCN package. Right now, the CBB package is used (board-am3517evm.c for instance) but there are differences that prevent some GPIOs from being configured properly. It would be nice to know if someone is working on this before I start... Raphael, The AM35x support has been trailing on the linux-omap. Usually, due to delays in dependency resolution: If you are not specifically looking for the latest kernel, revision you can get the sources from: http://arago-project.org/git/projects/?p=linux-omap3.git Use the tag: v2.6.37_OMAPPSP_04.02.00.07 This tree is supported by TI. The patches contained here, are being reworked for upstream submission... When possible, I prefer working on the latest version. But at least I'll have a look to make sure I'm not duplicating anyone's work. By the way, is there a specific mailing list for discussing this git tree? [sp] There is no mailing list. But you can use the e2e.ti.com. Select Linux Forum under Embedded Software to post query. ~sanjeev Best regards, Raphaël Assénat -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: AM3505/3517 support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Raphaël Assénat Sent: Tuesday, July 05, 2011 12:59 AM To: linux-omap@vger.kernel.org Subject: AM3505/3517 support Hello, We have a custom designed based on the AM3505 and we wish to run a modern kernel on it. Unfortunately, it seems a lot of efforts have been made to support other OMAP chips and that some work is still required to support the AM3505/3517 completely. (does not boot as-is) Is there anyone working on this right now? Not knowing, I have already started working on it. The am3505 is apparently so similar to the 3430 that it was treated as such (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a few differences that need to be addressed. I have therefore created a new CHIP_IS and patched clocks, hwmod and power management related files consequently. My system now boots until it complains that it is unable to mount its root filesystem. I will send my patches in a moment for comments and hopefully, after a few iterations, they will be acceptable. I know a lot of cleanup is happening right now and as a result my patches may not apply or conflict. Please let me know and I will be happy to rebase them as needed. Looking forward to your comments and help. One of the next things I'll look at is how to properly support the ZCN package. Right now, the CBB package is used (board-am3517evm.c for instance) but there are differences that prevent some GPIOs from being configured properly. It would be nice to know if someone is working on this before I start... Raphael, The AM35x support has been trailing on the linux-omap. Usually, due to delays in dependency resolution: If you are not specifically looking for the latest kernel, revision you can get the sources from: http://arago-project.org/git/projects/?p=linux-omap3.git Use the tag: v2.6.37_OMAPPSP_04.02.00.07 This tree is supported by TI. The patches contained here, are being reworked for upstream submission... ~sanjeev Best regards, Raphaël Assénat 8D Technologies inc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, June 27, 2011 4:46 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Gregoire Gentil; Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents * Sanjeev Premi pr...@ti.com [110627 03:33]: From: Hrishikesh Bhandiwad hrishikes...@ti.com Present current selection of the GPTIMER on Beagleboard was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1][2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. Also, the clock source for GPTIMER12 is much less frequency stable than clock sources for GPTIMER1. Using GPTIMER12 can result in major time skew over a fairly short interval. I don't think omap3_beagle_init_rev is even called when the timer is set? [sp] I verified the patch based on the print indicating that GPTIMER1 being used as clockevent source. http://marc.info/?l=linux-omapm=130893319726456w=2 But even if it was, this is not a good fix because of the dependency issues it causes to mux and gpio framework in omap3_beagle_rev_init. The best way to fix this is to set a separate machine ID for the working beagle boards like I commented earlier. It allows just setting the .timer based on that, the rest of the code can be shared. [sp] Sorry missed reading your comment. I wasn't checking mails while sending the updated patch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, June 27, 2011 6:02 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Gregoire Gentil; Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents * Premi, Sanjeev pr...@ti.com [110627 05:08]: From: Tony Lindgren [mailto:t...@atomide.com] I don't think omap3_beagle_init_rev is even called when the timer is set? [sp] I verified the patch based on the print indicating that GPTIMER1 being used as clockevent source. http://marc.info/?l=linux-omapm=130893319726456w=2 I suspect the test always fails though, so it probably never gets set to gptimer12 on any board :) [sp] While I take my time understanding things on devel-timer; I had a quick question - at risk of being flamed. Adding a new machine ID would trickle to u-boot and same uImage (default) may not work across board revisions. How does this scheme look like: - GPTIMER1 is used as default - as it works for most boards. - GPTIMER12 is used based on a static config option OR a board specific bootarg I know both these options aren't general practice. Still wanted to know your views in the current context. ~sanjeev Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, June 27, 2011 9:00 PM To: Premi, Sanjeev; Tony Lindgren Cc: Koen Kooi; linux-omap@vger.kernel.org List; linux-arm-kernel Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents On Mon, 27 Jun 2011, Tony Lindgren wrote: This fix will cause bad dependency issues with sys_timer. This patch has a dependency to omap3_beagle_init_rev, which depends on the mux framework and gpio framework. Not cool for init_early. We just want to initialize sys_timer early without any complicated dependencies. The best way to fix this is to set a separate machine ID for the properly working beagle boards like xm, then just set the .timer entry to omap3_timer for working beagle boards and omap3_secure_timer for non-working beagle boards. The rest of the board-*.c file can be shared. Sanjeev, want to take care of this? Machine ID update info is in linux/arch/arm/tools/mach-types. This strategy will unfortunately involve patching bootloaders. But if the default is to use GPT12, it should work out okay. [sp] Just sent another query to Tony on this specific issue. But, if different mach-type is the way forward, then I will take it forward. Hopefully we won't have to do the same thing for the other Beagle-derived boards, Devkit8000, Touchbook, etc. etc. Then again, I suppose this will eventually just be another property passed in via DT, with a single machine ID. [sp] Can you look at my query to Tony? Will that be an acceptable workaround until DT. Going to two machine IDs and then unifying back again could cause confusion - esp. during transition times. ~sanjeev The above assumes the patches in devel-timer branch where we no longer have the non-standard timer interface, but use the sys_timer entries instead like we should. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Sunday, June 26, 2011 1:41 AM To: linux-omap@vger.kernel.org List Cc: linux-arm-kernel; Paul Walmsley Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Saturday, June 25, 2011 1:47 PM To: linux-omap@vger.kernel.org List Cc: linux-arm-kernel; Paul Walmsley Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven: The current selection of the GPTIMER on was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1] [2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. [sp] I didn't include a reason - because the problem may not be reproducible on the public trees. During tests performed in internal development trees, the BogoMIPS calculations @ 1GHz wouldn't go beyond 830-850 range. While there was no such inconsistency on OMAP3EVM. After few days of debug GPTIMER12 came to be only difference. Tracing GPTIMER12 in the spec proved quite a challenge; the as timer is not included in the TRM and corresponding interrupt is marked reserved. Paul (in cc:) obviously had access to documents that we don't. This patch is merely trying to bring parity in use of GPTIMER across OMAP3 boards (AND use documented IP) - taking note of many Beagleboards where current code is necessary. I get a value of 1010 ±10 bogoMIPS consistently with .39 + dvfs patches. Having said that, this patch does seem to be an improvement, but has it actually been tested on real beagleboard hardware with a recent kernel? [sp] It was tested on BeagleXM RevB on top of linux-omap master - as on day of submitting th patch. Especially on the boards affected by the capacitor issue on the external clock.-- [sp] The patch relies on the check for board revision to continue using GPTIMER12 on affected boards - which I am assuming to be right. I don't have access to any of these versions, trying to find some early users. Hope someone on the list with Ax/Bx version can share the result... To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Sunday, June 26, 2011 4:17 AM To: Koen Kooi; Premi, Sanjeev Cc: linux-omap@vger.kernel.org List; linux-arm-kernel Subject: RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents On Sun, 26 Jun 2011, Premi, Sanjeev wrote: [sp] I didn't include a reason - because the problem may not be reproducible on the public trees. During tests performed in internal development trees, the BogoMIPS calculations @ 1GHz wouldn't go beyond 830-850 range. While there was no such inconsistency on OMAP3EVM. There are some other reasons to avoid GPTIMER12 when possible, which you should probably put in the patch description. The most important, in my view, is that the clock source for GPTIMER12 is much less frequency-stable than the clock sources for GPTIMER1. So using GPTIMER12 can result in major time skew over a fairly short interval. [sp] Thanks for details. I will include in next rev. I've been meaning to send a patch like this for some time, so I'm happy to see this fixed. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Sunday, June 26, 2011 12:39 AM To: Premi, Sanjeev Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Hilman, Kevin Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation On Sun, Jun 26, 2011 at 12:23:31AM +0530, Premi, Sanjeev wrote: [sp] I thought we were solving a problem - but this makes it look like race for addding sign-offs - which I am not interested in. No, it's called packaging the patch up and getting it ready, putting it out on the list for people to test and provide Tested-by's, acked-by's etc. [sp] Agree. Would you rather people sat on fixes doing nothing with them for a month instead, watching broken -rc after broken -rc going by? [sp] The original patch was just few hours ago... not month(s). ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Hilman, Kevin Sent: Saturday, June 25, 2011 1:44 AM To: Russell King - ARM Linux Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, Jun 24, 2011 at 11:20:44PM +0530, Premi, Sanjeev wrote: I was able to test BogoMIPS calculations via /proc/cpuinfo for both with without CONFIG_SMP selected. For most part things work fine - but I do notice occassional Oops and segmentation faults while doing cat /proc/cpuinfo With CONFIG_SMP enabled, system doesn't recover from the Oops; but without SMP - I noticed segmentation faults/ BUG but system does recover. They could be unrelated - but i didn't see any of these earlier today. I will continue debug on MON. I don't think these are related to the patch - I think there's something up with your hardware. Let's take the first. [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo [ 73.832366] Internal error: Oops - undefined instruction: 0 [#1] SMP Ok an undefined instruction. So... [ 73.839019] Modules linked in: [ 73.842193] CPU: 0Not tainted (3.0.0-rc3-14002-g40b6752-dirty #21) [ 73.849121] PC is at __do_fault+0x1c0/0x450 [ 73.853485] LR is at __do_fault+0x2b0/0x450 [ 73.857879] pc : [c010fa18]lr : [c010fb08] psr: 0113 [ 73.857879] sp : c7907d48 ip : fp : c5d518c0 [ 73.869873] r10: 0200 r9 : 40214000 r8 : [ 73.875335] r7 : c2692f98 r6 : c0ad7600 r5 : 87fb018f r4 : [ 73.882141] r3 : 87fb0a3e r2 : 0800 r1 : 87fb01cf r0 : c5d518c0 [ 73.888977] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 73.896423] Control: 10c5387d Table: 8795c019 DAC: 0015 [ 73.902435] Process cat (pid: 449, stack limit = 0xc79062f8) ... lets look at the code line: [ 74.176879] Code: e1a01005 e3a02000 ebfd1694 e59d0014 (eb07fcba) and disassemble it: 0: e1a01005mov r1, r5 4: e3a02000mov r2, #0 ; 0x0 8: ebfd1694bl 0xfff45a60 c: e59d0014ldr r0, [sp, #20] 10: eb07fcbabl 0x1ff300 There is no way that 0xeb07fcba should ever cause an undefined ARM instruction on a properly functioning system. It points at a hardware problem - are you using a socketed SoC? Is it properly socketed? Is the socket dirty? And all other questions related to hardware integrity... And in particular, since we're talking CPUfreq, are you running at a frequency that the SoC and especially the memory support? Yes. the frequencies are 300 - 800MHz range. The same board is also quite stable for 1GHz operations (tested ARM only) - with sources hosted at: http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary For testing, I was changing frequencies in a tight 'forever' loop. But, as I mentioned earlier that issues could be unrelated. And the loop could be exposing something else. ~sanjeev Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Saturday, June 25, 2011 1:47 PM To: linux-omap@vger.kernel.org List Cc: linux-arm-kernel; Paul Walmsley Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven: The current selection of the GPTIMER on was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1] [2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. [sp] I didn't include a reason - because the problem may not be reproducible on the public trees. During tests performed in internal development trees, the BogoMIPS calculations @ 1GHz wouldn't go beyond 830-850 range. While there was no such inconsistency on OMAP3EVM. After few days of debug GPTIMER12 came to be only difference. Tracing GPTIMER12 in the spec proved quite a challenge; the as timer is not included in the TRM and corresponding interrupt is marked reserved. Paul (in cc:) obviously had access to documents that we don't. This patch is merely trying to bring parity in use of GPTIMER across OMAP3 boards (AND use documented IP) - taking note of many Beagleboards where current code is necessary. ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Shilimkar, Santosh Sent: Saturday, June 25, 2011 12:18 AM To: Russell King - ARM Linux Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Hilman, Kevin Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Russell, On 6/24/2011 8:12 AM, Russell King - ARM Linux wrote: Right, thanks for the file. Here's the patch. [.] Notice how we adjust _both_ the per-cpu loops_per_jiffy, and that we adjust them with reference to the initial values. If you adjust lpj with reference to the last, then you _will_ build up a progressively bigger and bigger error in the value over time. Thanks Russell for the change. This change should fix the global lpj for UP machine as well when build with SMP_ON_UP. Can you have a look at below complete change which should make the BOGOMIPS happy on all OMAP2PLUS machines. Generated against Kevin's cpufreq branch. url = git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git pm-wip/cpufreq. Just compile tested with UP and SMP OMAP builds. After your review, I can give a test. Regards Santosh From 9a6154c0f68e39c4d1fbc4ef3fef5ce577ba87d4 Mon Sep 17 00:00:00 2001 From: Russell King rmk+ker...@arm.linux.org.uk Date: Fri, 24 Jun 2011 10:51:17 -0700 Subject: [PATCH] OMAP2+: CPUfreq: update lpj with refernce value to avoid progressive error. Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate them with with reference to the initial values to avoid a progressively bigger and bigger error in the value over time. While at this also re-use the notifiers for UP/SMP since on UP machine or UP_ON_SMP policy-cpus mask would contain only the one CPU. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [santosh.shilim...@ti.com: rebased against omap cpufreq upstream branch] Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Kevin Hilman khil...@ti.com [sp] I thought we were solving a problem - but this makes it look like race for addding sign-offs - which I am not interested in. [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 8:42 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
Right, thanks for the file. Here's the patch.
--- omap2plus-cpufreq.c~ 2011-06-24 15:50:32.0 +0100
+++ omap2plus-cpufreq.c 2011-06-24 16:00:08.0 +0100
@@ -44,6 +44,16 @@
static char *mpu_clk_name;
static struct device *mpu_dev;
+#ifdef CONFIG_SMP
+struct lpj_info {
+ unsigned long ref;
+ unsigned intfreq;
+};
+
+static DEFINE_PER_CPU(struct lpj_info, lpj_ref);
+static struct lpj_info global_lpj_ref;
+#endif
+
static int omap_verify_speed(struct cpufreq_policy *policy)
{
if (!freq_table)
@@ -109,14 +119,25 @@
freqs.new = omap_getspeed(policy-cpu);
#ifdef CONFIG_SMP
- /* Adjust jiffies before transition */
+ /* Adjust per-cpu loops_per_jiffy before transition */
for_each_cpu(i, policy-cpus) {
- unsigned long lpj = per_cpu(cpu_data,
i).loops_per_jiffy;
-
- per_cpu(cpu_data, i).loops_per_jiffy =
cpufreq_scale(lpj,
- freqs.old,
- freqs.new);
+ struct lpj_info *lpj = per_cpu(lpj_ref, i);
+ if (!lpj-freq) {
+ lpj-ref = per_cpu(cpu_data, i).loops_per_jiffy;
+ lpj-freq = freqs.old;
+ }
+
+ per_cpu(cpu_data, i).loops_per_jiffy =
+ cpufreq_scale(lpj-ref, lpj-freq, freqs.new);
+ }
+
+ /* And don't forget to adjust the global one */
+ if (!global_lpj_ref.freq) {
+ global_lpj_ref.ref = loops_per_jiffy;
+ global_lpj_ref.freq = freqs.old;
}
+ loops_per_jiffy = cpufreq_scale(global_lpj_ref.ref,
global_lpj_ref.freq,
+ freqs.new);
#endif
/* Notify transitions */
Notice how we adjust _both_ the per-cpu loops_per_jiffy, and that we
adjust them with reference to the initial values.
If you adjust lpj with reference to the last, then you _will_ build up
a progressively bigger and bigger error in the value over time.
Russell,
I was able to test BogoMIPS calculations via /proc/cpuinfo for
both with without CONFIG_SMP selected.
For most part things work fine - but I do notice occassional Oops
and segmentation faults while doing cat /proc/cpuinfo
With CONFIG_SMP enabled, system doesn't recover from the Oops;
but without SMP - I noticed segmentation faults/ BUG but system
does recover.
They could be unrelated - but i didn't see any of these earlier
today. I will continue debug on MON.
Here are details:
[1] This log comes corresponds to CONFIG_SMP enabled.
[2] This corresponds to running cat /proc/cpuinfo in a tight
loop. (CONFIG_SMP disabled).
[3] Saw only once today - but had seen it few days ago. None
of my local changes included. (CONFIG_SMP disabled).
[http://marc.info/?l=linux-omapm=130884641524123w=2]
~sanjeev
=== [1]
[root@OMAP3EVM cpufreq]# cat /proc/cpuinfo
[ 73.832366] Internal error: Oops - undefined instruction: 0 [#1] SMP
[ 73.839019] Modules linked in:
[ 73.842193] CPU: 0Not tainted (3.0.0-rc3-14002-g40b6752-dirty #21)
[ 73.849121] PC is at __do_fault+0x1c0/0x450
[ 73.853485] LR is at __do_fault+0x2b0/0x450
[ 73.857879] pc : [c010fa18]lr : [c010fb08]psr: 0113
[ 73.857879] sp : c7907d48 ip : fp : c5d518c0
[ 73.869873] r10: 0200 r9 : 40214000 r8 :
[ 73.875335] r7 : c2692f98 r6 : c0ad7600 r5 : 87fb018f r4 :
[ 73.882141] r3 : 87fb0a3e r2 : 0800 r1 : 87fb01cf r0 : c5d518c0
[ 73.888977] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 73.896423] Control: 10c5387d Table: 8795c019 DAC: 0015
[ 73.902435] Process cat (pid: 449, stack limit = 0xc79062f8)
[ 73.908355] Stack: (0xc7907d48 to 0xc7908000)
[ 73.912902] 7d40: 0008 c795d008
c5d4d050 c5d518f4
[ 73.921447] 7d60: 000c 40214000 c0ad7600 0002 000c
c795d008
[ 73.929992] 7d80: 40214000 c5d518c0 40214000 c2692f98 be91579c c0110760
000c
[ 73.938537] 7da0: c00bb088 0002 c5d518c0 c03111a0
c795c000
[ 73.947113] 7dc0: c795d008 0201 40214000 c5d518c0 c2692f98
be91579c c084
[ 73.955657] 7de0: c795d008 c2692f98 c7907fb0 0017 402140ea
c5d518c0 402140ea
[ 73.964202] 7e00: c5d51914 c031138c c78c6180 0002 002f
0017 c78c6180
[ 73.972747] 7e20: c08da030 c00b9184 c08da030 c00b9184 c5d518c4 c00b7860
c78c6180 c78c6180
[ 73.981292] 7e40: c04787dc c04af0e0 013e
0002
RE: [PATCH 2/2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
On Fri, Jun 24, 2011 at 04:05:42PM +0530, Sanjeev Premi wrote:
Currently, loops_per_jiffy is being calculated before calling
cpufreq_notify_transition().
However, generic cpufreq driver adjusts the jiffies as well.
Double adjustment leads to incorrect value being assigned to
loops_per_jiffy.
Are you sure the generic cpufreq driver adjusts the per-cpu
loops_per_jiffy
values? I don't believe it does.
Russell,
I am quoting the function from drivers/cpufreq/cpufreq.h
Follow the arrows:
[quote]
void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
{
[snip]...[snip]
case CPUFREQ_PRECHANGE:
[snip]...[snip]
srcu_notifier_call_chain(cpufreq_transition_notifier_list,
CPUFREQ_PRECHANGE, freqs);
adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
break;
case CPUFREQ_POSTCHANGE:
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
[snip]...[snip]
}
}
[/quote]
Same can be viewed here:
http://lxr.free-electrons.com/source/drivers/cpufreq/cpufreq.c?a=arm#L300
~sanjeev
[snip]...[snip]--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:22 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
On Fri, Jun 24, 2011 at 04:18:31PM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
On Fri, Jun 24, 2011 at 04:05:42PM +0530, Sanjeev Premi wrote:
Currently, loops_per_jiffy is being calculated before calling
cpufreq_notify_transition().
However, generic cpufreq driver adjusts the jiffies as well.
Double adjustment leads to incorrect value being assigned to
loops_per_jiffy.
Are you sure the generic cpufreq driver adjusts the per-cpu
loops_per_jiffy
values? I don't believe it does.
Russell,
I am quoting the function from drivers/cpufreq/cpufreq.h
Follow the arrows:
Let's go to war with quotes then, because clearly you haven't
read the code
properly:
[sp] Peace. No war!
Looks like I missed the ifndef in systax highlighting on my
editor. As mentioned, I couldn't test on OMAP4.
The patch obvioulsy works for A8... SMP needs to be fixed.
v2 coming soon.
~sanjeev
| #ifndef CONFIG_SMP
^
| static unsigned long l_p_j_ref;
| static unsigned int l_p_j_ref_freq;
|
| static void adjust_jiffies(unsigned long val, struct
cpufreq_freqs *ci)
| {
| ... code to adjust jiffies ...
| }
| #else
| static inline void adjust_jiffies(unsigned long val, struct
cpufreq_freqs *ci)
| {
| return;
| }
| #endif
Notice how if CONFIG_SMP is set, adjust_jiffies becomes a
no-op. So if
CONFIG_SMP=y, loops_per_jiffy will _not_ be scaled by core code.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message-
From: Shilimkar, Santosh
Sent: Friday, June 24, 2011 6:16 PM
To: Russell King - ARM Linux
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
Sanjeev,
On 6/24/2011 4:21 PM, Russell King - ARM Linux wrote:
On Fri, Jun 24, 2011 at 04:18:31PM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 4:14 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
On Fri, Jun 24, 2011 at 04:05:42PM +0530, Sanjeev Premi wrote:
Currently, loops_per_jiffy is being calculated before calling
cpufreq_notify_transition().
However, generic cpufreq driver adjusts the jiffies as well.
Double adjustment leads to incorrect value being assigned to
loops_per_jiffy.
Are you sure the generic cpufreq driver adjusts the per-cpu
loops_per_jiffy
values? I don't believe it does.
Russell,
I am quoting the function from drivers/cpufreq/cpufreq.h
Follow the arrows:
Let's go to war with quotes then, because clearly you
haven't read the code
properly:
| #ifndef CONFIG_SMP
^
| static unsigned long l_p_j_ref;
| static unsigned int l_p_j_ref_freq;
|
| static void adjust_jiffies(unsigned long val, struct
cpufreq_freqs *ci)
| {
| ... code to adjust jiffies ...
| }
| #else
| static inline void adjust_jiffies(unsigned long val,
struct cpufreq_freqs *ci)
| {
| return;
| }
| #endif
Notice how if CONFIG_SMP is set, adjust_jiffies becomes a
no-op. So if
CONFIG_SMP=y, loops_per_jiffy will _not_ be scaled by core code.
As Russell rightly pointed out, you need to take care of
UP/SMP and UP
OVER SMP.
The generic code updates in only in case of UP build. I thought, the
comment is the code was well explaining that part.
[sp] I did read the code but took long to understand most of it.
Hence patch 1 of this series.
I already accepted that I didn't notice definition of adjust_jiffies.
...call it perils of leaving job half-done across a good-night-sleep!
As is, the calculations of UP are incorrect... which I was fixing.
Anyway, I have an updated patch - currently testing with CONFIG_SMP
enabled. Will be posting soon.
~sanjeev
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] omap2+: pm: Use if...else instead of goto
-Original Message- From: Shilimkar, Santosh Sent: Friday, June 24, 2011 6:18 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto On 6/24/2011 4:05 PM, Sanjeev Premi wrote: This patch replaces the use of goto with simple if...else syntax. No change in functionality. This also means that the comment describing the dependency between CONFIG_SMP and calculation of loops_per_jiffy can be unified. Signed-off-by: Sanjeev Premipr...@ti.com --- Don't see need of this patch as well considering your second patch. So NAK. [sp] May be it isn't needed - but it surely highlights some bad code that does find way upstream. ~sanjeev-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] omap2+: pm: Use if...else instead of goto
-Original Message- From: Shilimkar, Santosh Sent: Friday, June 24, 2011 6:29 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto On 6/24/2011 6:24 PM, Premi, Sanjeev wrote: -Original Message- From: Shilimkar, Santosh Sent: Friday, June 24, 2011 6:18 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/2] omap2+: pm: Use if...else instead of goto On 6/24/2011 4:05 PM, Sanjeev Premi wrote: This patch replaces the use of goto with simple if...else syntax. No change in functionality. This also means that the comment describing the dependency between CONFIG_SMP and calculation of loops_per_jiffy can be unified. Signed-off-by: Sanjeev Premipr...@ti.com --- Don't see need of this patch as well considering your second patch. So NAK. [sp] May be it isn't needed - but it surely highlights some bad code that does find way upstream. If you think of using if else makes code better than use of goto, then I just ignore your comment. Because that means core scheduler code is also bad as per your remark which makes use of goto. [sp] No. It is context based - and in this context goto isn't any good... because code it evaluates to simple if..else as we goto over just another instruction. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Premi, Sanjeev Sent: Friday, June 24, 2011 7:24 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Premi, Sanjeev Subject: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Currently, loops_per_jiffy is being calculated twice for non-SMP processors. - Before calling cpufreq_notify_transition() - From within cpufreq_notify_transition() Double adjustment leads to incorrect value being assigned to loops_per_jiffy. This manifests as incorrect BogoMIPS in cat /proc/cpuinfo. The value of loops_per_jiffy needs to be calculated only when CONFIG_SMP is true. It is the core change included in this patch. The patch also leverages the definition of for_each_cpu() with and without CONFIG_SMP to consolidate the mechanism to call cpufreq_notify_transition(). Signed-off-by: Sanjeev Premi pr...@ti.com --- Changes since v1: * loops_per_jiffy are updated when CONFIG_SMP is true. * leverage definition of for_each_cpu() Tested on OMAP3EVM with and without CONFIG_SMP. Since the log is rather long, will be posting the log in a follow-up mail. [snip]...[snip] Snapshot of test log - with and without SMP included here: To ensure compile-time and run-time checks for SMP are visible, the patch was tested with this code inserted at enty of function omap_target(). #ifdef CONFIG_SMP printk (KERN_ERR I am defined SMP!\n); #else printk (KERN_ERR I am not defined SMP!\n); #endif if (is_smp()) printk (KERN_ERR Runtime evaluating to SMP!\n); else printk (KERN_ERR Runtime evaluating to no SMP!\n); With CONFIG_SMP disabled [root@OMAP3EVM /]# cd /sys/devices/system/cpu/cpu0/cpufreq/ [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat scaling_available_frequencies 30 60 80 100 [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# echo 30 scaling_setspeed [ 56.278137] I am not defined SMP! [ 56.281768] Runtime evaluating to no SMP! [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat cpuinfo_cur_freq 30 [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 298.32 Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 Hardware: OMAP3 EVM Revision: 0020 Serial : [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# echo 80 scaling_setspeed [ 96.938049] I am not defined SMP! [ 96.941833] Runtime evaluating to no SMP! [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 796.19 Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 Hardware: OMAP3 EVM Revision: 0020 Serial : [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# echo 10 scaling_setspeed [ 110.865631] I am not defined SMP! [ 110.870025] Runtime evaluating to no SMP! [root@OMAP3EVM cpufreq]# echo 100 scaling_setspeed [ 116.258941] I am not defined SMP! [ 116.262725] Runtime evaluating to no SMP! [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat cpuinfo_cur_freq 100 [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 996.74 Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 Hardware: OMAP3 EVM Revision: 0020 Serial : [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# With CONFIG_SMP enabled [root@OMAP3EVM /]# cd /sys/devices/system/cpu/cpu0/cpufreq/ [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat scaling_available_frequencies 30 60 80 100 [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# echo 30 scaling_setspeed [ 25.040496] I am defined SMP! [ 25.043884] Runtime evaluating to no SMP! [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) processor : 0 BogoMIPS: 298.32 Features: swp half
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Shilimkar, Santosh Sent: Friday, June 24, 2011 8:05 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation On 6/24/2011 7:23 PM, Sanjeev Premi wrote: Currently, loops_per_jiffy is being calculated twice for non-SMP processors. - Before calling cpufreq_notify_transition() - From within cpufreq_notify_transition() Double adjustment leads to incorrect value being assigned to loops_per_jiffy. This manifests as incorrect BogoMIPS in cat /proc/cpuinfo. The value of loops_per_jiffy needs to be calculated only when CONFIG_SMP is true. It is the core change included in this patch. The patch also leverages the definition of for_each_cpu() with and without CONFIG_SMP to consolidate the mechanism to call cpufreq_notify_transition(). Signed-off-by: Sanjeev Premipr...@ti.com NAK. This patch again doesn't make sense considering your issue. Also jiffies should not be undated before changing the freq. If the set_rate failed for some reason then you will have wrong jiffies value. I understand your issue now. The code for global lpj updation should have been checking smp_on_up() instead of is_smp(). That one line change is enough. I will post a patch on the same once I reach to office. [sp] Suggest reading the patch before NAKing. The patch is updating the loops_per_jiffy value AFTER the frequency change has happenned and BEFORE post change notification is sent. ~sanjeev Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Friday, June 24, 2011 8:42 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix
loops_per_jiffy calculation
Right, thanks for the file. Here's the patch.
--- omap2plus-cpufreq.c~ 2011-06-24 15:50:32.0 +0100
+++ omap2plus-cpufreq.c 2011-06-24 16:00:08.0 +0100
@@ -44,6 +44,16 @@
static char *mpu_clk_name;
static struct device *mpu_dev;
+#ifdef CONFIG_SMP
+struct lpj_info {
+ unsigned long ref;
+ unsigned intfreq;
+};
+
+static DEFINE_PER_CPU(struct lpj_info, lpj_ref);
+static struct lpj_info global_lpj_ref;
+#endif
+
static int omap_verify_speed(struct cpufreq_policy *policy)
{
if (!freq_table)
@@ -109,14 +119,25 @@
freqs.new = omap_getspeed(policy-cpu);
#ifdef CONFIG_SMP
- /* Adjust jiffies before transition */
+ /* Adjust per-cpu loops_per_jiffy before transition */
for_each_cpu(i, policy-cpus) {
- unsigned long lpj = per_cpu(cpu_data,
i).loops_per_jiffy;
-
- per_cpu(cpu_data, i).loops_per_jiffy =
cpufreq_scale(lpj,
- freqs.old,
- freqs.new);
+ struct lpj_info *lpj = per_cpu(lpj_ref, i);
+ if (!lpj-freq) {
+ lpj-ref = per_cpu(cpu_data, i).loops_per_jiffy;
+ lpj-freq = freqs.old;
+ }
+
+ per_cpu(cpu_data, i).loops_per_jiffy =
+ cpufreq_scale(lpj-ref, lpj-freq, freqs.new);
+ }
+
+ /* And don't forget to adjust the global one */
+ if (!global_lpj_ref.freq) {
+ global_lpj_ref.ref = loops_per_jiffy;
+ global_lpj_ref.freq = freqs.old;
}
+ loops_per_jiffy = cpufreq_scale(global_lpj_ref.ref,
global_lpj_ref.freq,
+ freqs.new);
#endif
/* Notify transitions */
Notice how we adjust _both_ the per-cpu loops_per_jiffy, and that we
adjust them with reference to the initial values.
If you adjust lpj with reference to the last, then you _will_ build up
a progressively bigger and bigger error in the value over time.
Russell,
I definitely didn't see so many things through your comments. But
that may just be reflection of my naivety with SMP!
I am currently testing another patch for beagle - will apply and
test on OMAP3EVM (just to be sure).
Can I include it in my next patch rev?
~sanjeev
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
-Original Message- From: K, Mythri P Sent: Thursday, June 23, 2011 11:21 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi Subject: Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Hi Sanjeev, On Mon, Jun 20, 2011 at 7:03 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P Sent: Friday, June 17, 2011 1:47 PM To: linux-omap@vger.kernel.org; Valkeinen, Tomi Cc: K, Mythri P Subject: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address [sp] HDMI appears twice on the subject. One of these can be removed. Also, it isn't clear (though implied) whose base address is being passed. The changes in the patch aren't limited to DSS alone. See updated to hdmi_core_audio_config(), hdmi_wp_audio_config_format(), hdmi_wp_audio_config_dma(), etc. The changes are related to the HDMI driver which as of this patch is in DSS. You see any concerns ? It is only later that those functions are moved out . [sp] The subject of mail indicates that changes are meant for DSS. How are the functions I quoted related to DSS? Unless DSS on OMAP4 supports audio... - r = hdmi_read_reg(PLLCTRL_CFG1); + r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1); r = FLD_MOD(r, fmt-regm, 20, 9); /* CFG1_PLL_REGM */ r = FLD_MOD(r, fmt-regn, 8, 1); /* CFG1_PLL_REGN */ - hdmi_write_reg(PLLCTRL_CFG1, r); + hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r); [sp] hdmi_pll_base(ip_data) is used at many places withing this function. Have you checked if saving the result in a local variable generates any better code than repetitive ADD operation in the function. Same comment applies to similar use in other functions modified in this patch. I had this comment from Tomi as well , Yes in some places it makes sense to have a local variable to save , but then in certain functions where there are four writes with 3 different base address it doesn't make sense to add 3 variables. [sp] I don't see base address for the IP changing within the function. so a local variable still makes sense - instead of using CPU cycles to do reduntant calculations each time. [snip]...[snip] + , HDMI_CORE_DDC_CMD, 0x9, 3, 0); [sp] Misplaced , at beginning of the line. Not a part of the patch i suppose? [sp] Actually the + indicates it is very much part of the patch. Ideally it should be at end of prev line. [quote] /* Clear FIFO */ - REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x9, 3, 0); + REG_FLD_MOD(hdmi_core_sys_base(ip_data) + , HDMI_CORE_DDC_CMD, 0x9, 3, 0); [/quote] ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
-Original Message- From: K, Mythri P Sent: Thursday, June 23, 2011 4:30 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi Subject: Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Hi Sanjeev, snip The changes in the patch aren't limited to DSS alone. See updated to hdmi_core_audio_config(), hdmi_wp_audio_config_format(), hdmi_wp_audio_config_dma(), etc. The changes are related to the HDMI driver which as of this patch is in DSS. You see any concerns ? It is only later that those functions are moved out . [sp] The subject of mail indicates that changes are meant for DSS. How are the functions I quoted related to DSS? Unless DSS on OMAP4 supports audio... Some of the Audio configuration for HDMI is part of DSS (as of 2.6.40) , This patch series is precisely to separate the DSS portion from non-DSS portion of HDMI. It would be great if you have a look at the 2.6.40 kernel and this gitorious tree with my patch set to get a fair idea. [sp] Then I suggest dropping DSS from the subject. ~sanjeev-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3evm: observing bug in lockdep
Hi all, I am currently on the pm branch. And my HEAD is at: commit 40d10207b5389184333bacb786d27036cbcee500 Merge: 6b10874 b830f73 Author: Kevin Hilman khil...@ti.com Date: Thu Jun 16 16:31:51 2011 -0700 rebuild PM from branches Every now and then EVM doesn't boot at all. OR shows this error (at end of this mail). Otherwise, there is no problem at all! The uImage was build with omap2plus_defconfig with only OMAP3EVM and OMAP3BEAGLE selected. Haven't yet tried to update my repo - but wanted to share the issue. Best regards, Sanjeev Uncompressing Linux... done, booting the kernel. [0.00] Linux version 3.0.0-rc3-13998-g40d1020-dirty (premi@mylinux) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #3 Thu Jun 23 21:12:56 IST 2011 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP3 EVM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.1 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] Reprogramming SDRC clock to 4000 [0.00] dpll3_m2_clk rate change failed: -22 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: console=ttyO0,115200n8 mem=128M root=/dev/ram0 rw initrd=0x8160,24M ip=dhcp earlyprintk=serial,ttyO0,115200 [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 128MB = 128MB total [0.00] Memory: 95576k/95576k available, 35496k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xc880 - 0xf800 ( 760 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0034000 ( 176 kB) [0.00] .text : 0xc0034000 - 0xc03f806c (3857 kB) [0.00] .data : 0xc03fa000 - 0xc043e090 ( 273 kB) [0.00] NR_IRQS:410 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.000732] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) [0.093780] pid_max: default: 32768 minimum: 301 [0.094177] Security Framework initialized [0.094360] Mount-cache hash table entries: 512 [0.097381] CPU: Testing write buffer coherency: ok [0.105743] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core [0.105743] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per [0.105773] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup [0.106079] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck. [0.121002] omap_hwmod: i2c1: softreset failed (waited 1 usec) [0.134460] omap_hwmod: i2c2: softreset failed (waited 1 usec) [0.147918] omap_hwmod: i2c3: softreset failed (waited 1 usec) [0.152343] print_constraints: dummy: [0.153259] GPMC revision 5.0 [0.160003] omap_device: omap_gpio.0: new worst case activate latency 0: 61035 [0.161834] OMAP GPIO hardware version 2.5 [0.173095] omap_mux_init: Add partition: #1: core, flags: 0 [0.181579] omap_device: omap_uart.0: new worst case activate latency 0: 30517 [0.184814] hw-breakpoint: debug architecture 0x4 unsupported. [0.193725] OMAP DMA hardware revision 5.0 [0.220489] bio: create slab bio-0 at 0 [0.227294] SCSI subsystem initialized [0.227844] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517 [0.230194] omap_device: omap2_mcspi.1: new worst case deactivate latency 0: 30517 [
RE: [PATCH 1/2] OMAP4 :TWL6030: Regulator set the default behavior of LDO's
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ghongdemath, Girish Sent: Wednesday, June 22, 2011 5:55 AM To: linux-omap Cc: Ghongdemath, Girish Subject: [PATCH 1/2] OMAP4 :TWL6030: Regulator set the default behavior of LDO's TWL6030 below table shows the default state each LDO's can be put into. [sp] Can you point to the relevant document instead of drawing the full table here? +---+ | LDO | Usage | state | +---+ | VANA | sources internal | Always ON | | | analog voltage| | +---+ | VAUX1 | eMMC | MMC Driver needs to handle| | | | | +---+ | VAUX2 | A/V switch| Driver needs to handle| +---+ | VAUX3 | 5MP CAMp | Driver needs to handle| +---+ | VCXIO | supplies DPLL's | Can be put OFF when OMAP hits | | | | OFF mode. | +---+ | VDAC | HDMI, CDC chip| Always ON | +---+ | VMMC | MMC | Driver needs to handle| +---+ | VPP | VPP pins of OMAP | Used while burning fuses in | | | | OMAP. This can be turned OFF| | | | by default when kernel comes | | | | up. | +---+ | VRTC | VBRTC/RTC | Always ON | +---+ | VUSB | USB OTG pins | Driver needs to handle| +---+ | VUSIM | VDDS_SIM, SIM cage| Driver needs to handle. | +---+ | CLK32K| 32KHz o/p clk | WIFI/BT/FM/GPS driver needs | | | | to handle | +---+ [snip]...[snip] ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP4 :TWL6030: Regulator set the default behavior of LDO's
-Original Message- From: Ghongdemath, Girish Sent: Wednesday, June 22, 2011 7:23 PM To: Premi, Sanjeev Cc: linux-omap Subject: Re: [PATCH 1/2] OMAP4 :TWL6030: Regulator set the default behavior of LDO's On Wed, Jun 22, 2011 at 6:18 AM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ghongdemath, Girish Sent: Wednesday, June 22, 2011 5:55 AM To: linux-omap Cc: Ghongdemath, Girish Subject: [PATCH 1/2] OMAP4 :TWL6030: Regulator set the default behavior of LDO's TWL6030 below table shows the default state each LDO's can be put into. [sp] Can you point to the relevant document instead of drawing the full table here? This info not available as is in public TRM's or any doc. Relevant schematics will help.. [sp] In this case, it is possibly more useful to add the information as comment - next to the code where specific LDOs are being marked always_on. It should address another concern from Balaji on sync between code and description. ~sanjeev Regards, Girish -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Omap3 - AM37xx change cpu-frequency
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Arno Steffen Sent: Monday, June 20, 2011 12:24 PM To: linux-omap@vger.kernel.org Subject: Omap3 - AM37xx change cpu-frequency Currently I am using 2.6.33 on an OMAP3. I would change from a 600MHz Omap35xx to a pincompatible 1GHz AM37xx. Where is to change the clock frequencies/dividers? Is it done in x-loader, uboot or in kernel itself (and if so where?). Are there other Software-issued to take care in this migration? Best regards [sp] Are you looking for one time change to 1GHz OR would you be scaling the frequency run-time? ~sanjeev -Arno -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] config: omap2+: force fb and dss support as built-in
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tushar Behera Sent: Monday, June 20, 2011 4:16 PM To: linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-fb...@vger.kernel.org; linux-omap@vger.kernel.org Cc: li...@arm.linux.org.uk; t...@atomide.com; let...@linux-sh.org; linaro-...@lists.linaro.org; patc...@linaro.org; Nilofer, Samreen Subject: [PATCH 1/2] config: omap2+: force fb and dss support as built-in In certain board files, there are references to vram related functions which are defined in drivers/video/omap2/vram.c. Because of this direct dependency, CONFIG_FB_OMAP2 should be a built-in feature. As per the current architecture, CONFIG_FB_OMAP2 is dependent on CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also be selected by default. Cc: Tony Lindgren t...@atomide.com Cc: Samreen samr...@ti.com Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init': linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97: undefined reference to `omap_vram_set_sdram_vram' arch/arm/plat-omap/built-in.o: In function `omap_reserve': linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined reference to `omap_vram_reserve_sdram_memblock' arch/arm/plat-omap/built-in.o: In function `omap_detect_sram': linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined reference to `omap_vram_reserve_sram' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 arch/arm/configs/omap2plus_defconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..c32 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -138,11 +138,11 @@ CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_OMAP_LCD_VGA=y -CONFIG_OMAP2_DSS=m +CONFIG_OMAP2_DSS=y CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y -CONFIG_FB_OMAP2=m +CONFIG_FB_OMAP2=y CONFIG_PANEL_GENERIC_DPI=m CONFIG_PANEL_SHARP_LS037V7DW01=m CONFIG_PANEL_NEC_NL8048HL11_01B=m [sp] Instead of changing the omap2plus_defconfig, shouldn't the board specific file be fixed instead? ~sanjeev -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] config: omap2+: force fb and dss support as built-in
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, June 20, 2011 5:51 PM To: Premi, Sanjeev Cc: Tushar Behera; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-fb...@vger.kernel.org; linux-omap@vger.kernel.org; t...@atomide.com; let...@linux-sh.org; linaro-...@lists.linaro.org; patc...@linaro.org; Nilofer, Samreen Subject: Re: [PATCH 1/2] config: omap2+: force fb and dss support as built-in On Mon, Jun 20, 2011 at 05:37:07PM +0530, Premi, Sanjeev wrote: [sp] Instead of changing the omap2plus_defconfig, shouldn't the board specific file be fixed instead? The board specific configuration files in the mainline kernel are deprecated and are gradually being removed. [sp] I didn't mean board specific config file, but: linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c ~sanjeev-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Friday, June 17, 2011 1:47 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI
timings structure
Define new HDMI timings structure to replace the OMAP DSS
timing strucutre in hdmi.c
[sp] Fix spelling of structure.
to have the HDMI include defintion out of DSS.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 23 ---
drivers/video/omap2/dss/hdmi.h | 15 ++-
2 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
index 4ee879a..c24d573 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -593,6 +593,20 @@ static int read_edid(struct hdmi_ip_data
*ip_data, u8 *pedid, u16 max_length)
return 0;
}
+static void copy_hdmi_to_dss_timings(struct
hdmi_video_timings hdmi_timings,
+ struct omap_video_timings *timings)
[sp] Assuming that we really need 2 separate structures, suggest
renaming function to copy_hdmi_timings_to_dss or
copy_timings_hdmi_to_dss for better readability.
+{
+ timings-x_res = hdmi_timings.x_res;
+ timings-y_res = hdmi_timings.y_res;
+ timings-pixel_clock = hdmi_timings.pixel_clock;
+ timings-hbp = hdmi_timings.hbp;
+ timings-hfp = hdmi_timings.hfp;
+ timings-hsw = hdmi_timings.hsw;
+ timings-vbp = hdmi_timings.vbp;
+ timings-vfp = hdmi_timings.vfp;
+ timings-vsw = hdmi_timings.vsw;
+}
+
static int get_timings_index(void)
{
int code;
@@ -617,7 +631,7 @@ static struct hdmi_cm
hdmi_get_code(struct omap_video_timings *timing)
{
int i = 0, code = -1, temp_vsync = 0, temp_hsync = 0;
int timing_vsync = 0, timing_hsync = 0;
- struct omap_video_timings temp;
+ struct hdmi_video_timings temp;
struct hdmi_cm cm = {-1};
DSSDBG(hdmi_get_code\n);
@@ -775,7 +789,8 @@ static void hdmi_read_edid(struct
omap_video_timings *dp)
code = get_timings_index();
- *dp = cea_vesa_timings[code].timings;
+ copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings, dp);
+
}
static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
@@ -1234,7 +1249,9 @@ static int hdmi_power_on(struct
omap_dss_device *dssdev)
hdmi_read_edid(p);
}
code = get_timings_index();
- dssdev-panel.timings = cea_vesa_timings[code].timings;
+ copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings,
+ dssdev-panel.timings);
+
update_hdmi_timings(hdmi.cfg, p, code);
phy = p-pixel_clock;
diff --git a/drivers/video/omap2/dss/hdmi.h
b/drivers/video/omap2/dss/hdmi.h
index f57ef4a..dcc30b7 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -188,9 +188,22 @@ struct hdmi_reg { u16 idx; };
#define REG_GET(base, idx, start, end) \
FLD_GET(hdmi_read_reg(base, idx), start, end)
+struct hdmi_video_timings {
+ u16 x_res;
+ u16 y_res;
+ /* Unit: KHz */
+ u32 pixel_clock;
[sp] Could be:
u32 pixel_clock; /* unit: KHz */
+ u16 hsw;
+ u16 hfp;
+ u16 hbp;
+ u16 vsw;
+ u16 vfp;
+ u16 vbp;
+};
+
/* HDMI timing structure */
struct hdmi_timings {
- struct omap_video_timings timings;
+ struct hdmi_video_timings timings;
int vsync_pol;
int hsync_pol;
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Friday, June 17, 2011 1:47 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass
base_address
[sp] HDMI appears twice on the subject. One of these can be removed.
Also, it isn't clear (though implied) whose base address is being
passed.
The changes in the patch aren't limited to DSS alone.
See updated to hdmi_core_audio_config(), hdmi_wp_audio_config_format(),
hdmi_wp_audio_config_dma(), etc.
As the base_address of the HDMI might differ across SoC's,
[sp] Is 'base_address' a variable? OR did you mean 'base address'?
offset of the HDMI
logical blocks and base address got from the platform data are passed
dynamically to the functions that modify HDMI IP registers.
[sp] Overall, the sentence can be simplified.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 518
drivers/video/omap2/dss/hdmi.h | 292 +++
2 files changed, 452 insertions(+), 358 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
index 5e5b98b..1d16ee2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -43,11 +43,17 @@
#include hdmi.h
#include dss_features.h
+#define HDMI_WP 0x0
+#define HDMI_CORE_SYS0x400
+#define HDMI_CORE_AV 0x900
+#define HDMI_PLLCTRL 0x200
+#define HDMI_PHY 0x300
+
static struct {
struct mutex lock;
struct omap_display_platform_data *pdata;
struct platform_device *pdev;
- void __iomem *base_wp; /* HDMI wrapper */
+ struct hdmi_ip_data hdmi_data;
int code;
int mode;
u8 edid[HDMI_EDID_MAX_LENGTH];
@@ -146,21 +152,51 @@ static const int code_vesa[85] = {
static const u8 edid_header[8] = {0x0, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0x0};
-static inline void hdmi_write_reg(const struct hdmi_reg idx, u32 val)
+static inline void hdmi_write_reg(void __iomem *base_addr,
+ const struct hdmi_reg idx, u32 val)
+{
+ __raw_writel(val, base_addr + idx.idx);
+}
+
+static inline u32 hdmi_read_reg(void __iomem *base_addr,
+ const struct hdmi_reg idx)
+{
+ return __raw_readl(base_addr + idx.idx);
+}
+
+static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data
*ip_data)
+{
+ return (void __iomem *) (ip_data-base_wp);
+}
+
+static inline void __iomem *hdmi_phy_base(struct
hdmi_ip_data *ip_data)
{
- __raw_writel(val, hdmi.base_wp + idx.idx);
+ return (void __iomem *) (ip_data-base_wp +
ip_data-hdmi_phy_offset);
}
-static inline u32 hdmi_read_reg(const struct hdmi_reg idx)
+static inline void __iomem *hdmi_pll_base(struct
hdmi_ip_data *ip_data)
{
- return __raw_readl(hdmi.base_wp + idx.idx);
+ return (void __iomem *) (ip_data-base_wp +
ip_data-hdmi_pll_offset);
}
-static inline int hdmi_wait_for_bit_change(const struct hdmi_reg idx,
+static inline void __iomem *hdmi_av_base(struct hdmi_ip_data
*ip_data)
+{
+ return (void __iomem *)
+ (ip_data-base_wp +
ip_data-hdmi_core_av_offset);
+}
+
+static inline void __iomem *hdmi_core_sys_base(struct
hdmi_ip_data *ip_data)
+{
+ return (void __iomem *)
+ (ip_data-base_wp +
ip_data-hdmi_core_sys_offset);
+}
+
+static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
+ const struct hdmi_reg idx,
int b2, int b1, u32 val)
{
u32 t = 0;
- while (val != REG_GET(idx, b2, b1)) {
+ while (val != REG_GET(base_addr, idx, b2, b1)) {
udelay(1);
if (t++ 1)
return !val;
@@ -225,21 +261,22 @@ int hdmi_init_display(struct
omap_dss_device *dssdev)
return 0;
}
-static int hdmi_pll_init(enum hdmi_clk_refsel refsel, int dcofreq,
+static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
+ enum hdmi_clk_refsel refsel, int dcofreq,
struct hdmi_pll_info *fmt, u16 sd)
{
u32 r;
/* PLL start always use manual mode */
- REG_FLD_MOD(PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
+ REG_FLD_MOD(hdmi_pll_base(ip_data),
PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
- r = hdmi_read_reg(PLLCTRL_CFG1);
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
r = FLD_MOD(r, fmt-regm, 20, 9); /* CFG1_PLL_REGM */
r = FLD_MOD(r, fmt-regn, 8, 1); /* CFG1_PLL_REGN */
- hdmi_write_reg(PLLCTRL_CFG1, r);
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
[sp] hdmi_pll_base(ip_data) is used at many places withing this
RE: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Friday, June 17, 2011 1:47 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver
to DSS and IP
Splitting HDMI IP dependent IP configuring code from HDMI DSS
dependent code and
moving to a new IP file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Makefile |1 +
drivers/video/omap2/dss/hdmi.c | 751
---
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 781
.../video/omap2/dss/{hdmi.h = hdmi_ti_4xxx_ip.h} |9 +-
include/video/hdmi_ti_4xxx_ip.h| 10 +
[sp] Is it okay to have 2 files by same name in two dirs?
'include/video' and 'drivers/.../omap2/dss'.
Compiler won't complain, but my comments is more from readability.
There has to be something characteristically different in these
headers - maybe this should reflect in the names as well.
~sanjeev
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Trouble with newer kernels on Gumstix Overo boards
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Yegor Yefremov Sent: Monday, June 20, 2011 7:02 PM To: Daniel Mack Cc: Gadiyar, Anand; Tony Lindgren; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: Trouble with newer kernels on Gumstix Overo boards [snip]...[snip] Are you using some extra patches? I have a custom board based on am3517 SoC and I have much more errors during booting as I can see from your boot log. I have no problems booting 2.6.32/37 though. Any idea? [sp] You may want to follow this thread: http://marc.info/?t=12986417803r=1w=2 It was few months ago, and I am not sure if I tested updated patch(es) working. But, something to verify... ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3evm: Add Mistral WL12XX config support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shahar Lev Sent: Tuesday, June 14, 2011 5:46 PM To: linux-omap@vger.kernel.org Cc: linux-arm; Tony Lindgren; Shahar Lev Subject: [PATCH] omap3evm: Add Mistral WL12XX config support Add Kconfig entries indicating the existence of omap3evm's wlan/bt wl12xx daughter card (see http://mistralsolutions.com/component/jumi/Download_Common_Cod e.html?docid=298), and the exact reference clock type that the wl12xx device is hardwired to (the wl12xx driver must know this). In addition, start using CONFIG_OMAP3EVM_MISTRAL_WL12XX in the omap3evm's board file instead of CONFIG_WL12XX_PLATFORM_DATA, because the latter only indicates that the driver is being built, and shouldn't be used to assume the existence of extension cards. Signed-off-by: Shahar Lev sha...@wizery.com --- arch/arm/mach-omap2/Kconfig | 23 +++ arch/arm/mach-omap2/board-omap3evm.c | 12 ++-- 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 19d5891..8ef012d 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -342,6 +342,29 @@ config OMAP3_SDRC_AC_TIMING wish to say no. Selecting yes without understanding what is going on could result in system crashes; +config OMAP3EVM_MISTRAL_WL12XX [sp] Could this be renamed simply as: OMAP3EVM_WL12XX? OR is there a specific reason to add vendor/manufacturers' name to the defintion? ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: pm: Downgrade WARN for no wakeup source
-Original Message- From: Hilman, Kevin Sent: Thursday, June 16, 2011 8:52 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source Hi Sanjeev, Sanjeev Premi pr...@ti.com writes: When multiple wakeup sources are defined in a system, there is a small window, when more than one source can trigger wakeup interrupt. In the current implementation, the do-while() loop can handle all wakeup sources that are recorded when probing the status register in prcm_interrupt_handler(). When the ISR executes due to next queued wakeup, it there is nothing to be handled and value of c is 0. Thanks for tracking this one down. However, It's still not clear to me what is happening here. Why is the IRQ firing if there is nothing to be handled? That suggests to me that the IRQ status is not properly being cleared. [SP] On the contrary the IRQ status is actually getting cleared, but there are more than 1 PRCM interrupts queued. The do-while() clears all the interrupt sources that are flagged in the status register. When the next wakeup interrupt is getting processed, the status register doesn't contain any source to handle. and value of c is returned as 0 leading to the warning. ~sanjeev Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: pm: Downgrade WARN for no wakeup source
-Original Message- From: Hilman, Kevin Sent: Thursday, June 16, 2011 11:55 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source Premi, Sanjeev pr...@ti.com writes: -Original Message- From: Hilman, Kevin Sent: Thursday, June 16, 2011 8:52 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: pm: Downgrade WARN for no wakeup source Hi Sanjeev, Sanjeev Premi pr...@ti.com writes: When multiple wakeup sources are defined in a system, there is a small window, when more than one source can trigger wakeup interrupt. In the current implementation, the do-while() loop can handle all wakeup sources that are recorded when probing the status register in prcm_interrupt_handler(). When the ISR executes due to next queued wakeup, it there is nothing to be handled and value of c is 0. Thanks for tracking this one down. However, It's still not clear to me what is happening here. Why is the IRQ firing if there is nothing to be handled? That suggests to me that the IRQ status is not properly being cleared. [SP] On the contrary the IRQ status is actually getting cleared, but there are more than 1 PRCM interrupts queued. The do-while() clears all the interrupt sources that are flagged in the status register. When the next wakeup interrupt is getting processed, the status register doesn't contain any source to handle. Still confused. If a wakeup interrupt is fired, it was caused by something. IOW, if the status register doesn't contain any source, how is if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK | OMAP3430_IO_ST_MASK)) ever true? [sp] I had been hesitant to say nesting because the wakeup interrupts seem to be independent of each other. But now I think - from SW perspective, it should/could be considered as nesting. ~sanjeev Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap3: ftrace on latest 3.0.0-rc2
Hi all, I am unable to enable ftrace on the 3.0.0-rc2. Have tried with Codesourcery toolchain using GCC v4.3.3 and 4.5.1. Before moving to debug, I just wanted to know if it is a known problem. ~sanjeev Linux version 3.0.0-rc2-11092-gc04c67c (premi@mylinux) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #2 SMP Mon Jun 13 15:23:22 IST 2011 [root@OMAP3EVM tracing]# uname -a Linux OMAP3EVM 3.0.0-rc2-11092-gc04c67c #2 SMP Mon Jun 13 15:23:22 IST 201 1 armv7l GNU/Linux [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# zcat /proc/config.gz | grep TRACER CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_GENERIC_TRACER=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set # CONFIG_SCHED_TRACER is not set CONFIG_STACK_TRACER=y [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# dmesg | grep -i tracer [0.841461] Testing tracer function: PASSED [1.932708] Testing tracer function_graph: [1.933349] Failed to init function_graph tracer, init returned -19 [5.950775] Failed to enable function tracer for event tests [root@OMAP3EVM tracing]# pwd root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# cat available_tracers nop Linux version 3.0.0-rc2-11092-gc04c67c (premi@mylinux) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #3 SMP Mon Jun 13 17:29:19 IST 2011 [5.845520] Testing all events: OK [5.898864] [ cut here ] [5.903808] WARNING: at kernel/trace/trace_events.c:1662 event_trace_s elf_tests_init+0x5c/0x80() [5.913085] Modules linked in: [5.916351] [c007ac20] (unwind_backtrace+0x0/0x104) from [c04bbb3c] (dump_stack+0x20/0x24) [5.925476] [c04bbb3c] (dump_stack+0x20/0x24) from [c00b3c78] (warn _slowpath_common+0x5c/0x74) [5.934967] [c00b3c78] (warn_slowpath_common+0x5c/0x74) from [c00b3c bc] (warn_slowpath_null+0x2c/0x34) [5.945190] [c00b3cbc] (warn_slowpath_null+0x2c/0x34) from [c0020ecc ] (event_trace_self_tests_init+0x5c/0x80) [5.956054] [c0020ecc] (event_trace_self_tests_init+0x5c/0x80) from [c0066598] (do_one_initcall+0x44/0x194) [5.966705] [c0066598] (do_one_initcall+0x44/0x194) from [c0008454] (kernel_init+0xbc/0x170) [5.976013] [c0008454] (kernel_init+0xbc/0x170) from [c0073ab8] (ke rnel_thread_exit+0x0/0x8) [5.985321] ---[ end trace 3c0bd3405257eb98 ]--- [5.990203] Failed to enable function tracer for event tests [root@OMAP3EVM tracing]# uname -a Linux OMAP3EVM 3.0.0-rc2-11092-gc04c67c #3 SMP Mon Jun 13 17:29:19 IST 2011 armv7l GNU/Linux [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# cat available_tracers nop [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# [root@OMAP3EVM tracing]# zcat /proc/config.gz | grep TRACER CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_GENERIC_TRACER=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set # CONFIG_SCHED_TRACER is not set CONFIG_STACK_TRACER=y [root@OMAP3EVM tracing]# -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3+: Kconfig: has EHCI only if USB present
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Friday, June 10, 2011 8:45 PM To: linux-omap Cc: Tony; linux-arm; Balbi, Felipe; Menon, Nishanth Subject: [PATCH] OMAP3+: Kconfig: has EHCI only if USB present Attempting to disable USB generates the following warning at the moment: warning: (ARCH_OMAP3 ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) Signed-off-by: Nishanth Menon n...@ti.com --- based on 3.0-rc2 arch/arm/mach-omap2/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ef7e12f..d5cf1a8 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -33,7 +33,7 @@ config ARCH_OMAP3 depends on ARCH_OMAP2PLUS default y select CPU_V7 - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4 select ARCH_HAS_OPP select PM_OPP if PM @@ -50,7 +50,7 @@ config ARCH_OMAP4 select ARM_ERRATA_720789 select ARCH_HAS_OPP select PM_OPP if PM - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT comment OMAP Core Type depends on ARCH_OMAP2 Here is earlier discussion on the same subject: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42064.html Exactly same patch was proposed. ~sanjeev -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC] OMAP2PLUS: Enable HIGHMEM
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Thursday, June 02, 2011 5:36 PM To: linux-omap@vger.kernel.org Cc: Shilimkar, Santosh Subject: [PATCH RFC] OMAP2PLUS: Enable HIGHMEM HIGMEM support is kernel is quite mature now and we have boards [sp] ^^ replace with in like ZOOM, PANDA, SDP where 1 GB memories are installed. Enable HIGMEM to make use of the additional memory. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- This won't boards which doesn't have excess memory. Tested on OMAP4430 SDP [sp] Comment is unclear on what happens on the boards with lesser memories esp. since the change will impact all boards. You may want to explain. arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 19d5891..25e819e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -19,6 +19,7 @@ config ARCH_OMAP2PLUS_TYPICAL select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 + select HIGHMEM help Compile a kernel suitable for booting most boards -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 1/9] OMAP: ID: introduce chip detection for OMAP4460
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: V, Aneesh; Menon, Nishanth
Subject: [RFC][PATCH 1/9] OMAP: ID: introduce chip detection
for OMAP4460
From: Aneesh V ane...@ti.com
Add support for detecting the latest in the OMAP4 family: OMAP4460
Among other changes, the new chip also can support 1.5GHz A9s,
1080p stereoscopic 3D and 12 MP stereo (dual camera). In addition,
we have changes to OPPs supported, clock tree etc, hence having a
chip detection is required.
Starting from OMAP4460 ES1.0, we are moving from HAWKEYE to
Ramp system
for chip identification. Since the bit offsets are the same,
just rename
the variable for dual use.
For more details on OMAP4460, see
Highlights:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?c
ontentId=53243navigationId=12843templateId=6123
Public TRM is available here as usual:
http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?t
emplateId=6123navigationId=12667
[n...@ti.com: cleanups and introduction of ramp system]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
---
arch/arm/mach-omap2/id.c | 19 ++-
arch/arm/plat-omap/include/plat/cpu.h | 12
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2537090..724be0a 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -331,7 +331,7 @@ static void __init omap3_check_revision(void)
static void __init omap4_check_revision(void)
{
u32 idcode;
- u16 hawkeye;
+ u16 hawkeye_ramp;
[sp] Why is this change required?
u8 rev;
~sanjeev
[snip]...[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Sonasath, Moiz; Menon, Nishanth
Subject: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1
during HWMOD init
[sp] typo in the subject. DO - Do
Another nit: Are 2 HWMODs required in the subject?
~sanjeev
From: Moiz Sonasath m-sonas...@ti.com
For OMAP4460, GPIO-7 of bank1 is used for controling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
drop to 0.9 V.
Originally from:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae
4f0de03b17c064d9ce90a580230f1a596ec1
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27
---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2f51a5a..27319c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk
gpio1_opt_clks[] = {
{ .role = dbclk, .clk = gpio1_dbclk },
};
-static struct omap_hwmod omap44xx_gpio1_hwmod = {
+static struct omap_hwmod omap443x_gpio1_hwmod = {
.name = gpio1,
.class = omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio1_irqs,
@@ -1761,7 +1761,27 @@ static struct omap_hwmod
omap44xx_gpio1_hwmod = {
.dev_attr = gpio_dev_attr,
.slaves = omap44xx_gpio1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+static struct omap_hwmod omap446x_gpio1_hwmod = {
+ .name = gpio1,
+ .class = omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_gpio1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs),
+ .main_clk = gpio1_ick,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
+ },
+ },
+ .opt_clks = gpio1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks),
+ .dev_attr = gpio_dev_attr,
+ .slaves = omap44xx_gpio1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
};
/* gpio2 */
@@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod
*omap44xx_hwmods[] = {
omap44xx_dss_venc_hwmod,
/* gpio class */
- omap44xx_gpio1_hwmod,
+ omap443x_gpio1_hwmod,
+ omap446x_gpio1_hwmod,
omap44xx_gpio2_hwmod,
omap44xx_gpio3_hwmod,
omap44xx_gpio4_hwmod,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 4/9] OMAP4: clocks: distinguish 4430 and 4460
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Nayak, Rajendra
Subject: [RFC][PATCH 4/9] OMAP4: clocks: distinguish 4430 and 4460
From: Rajendra Nayak rna...@ti.com
omap4460 platform has a few clock nodes which are added
and a few which are missing (compared to the 4430 platform)
rename current 4430 definitions to 44XX and followon patches
will introduce the 4460 changes
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 659
+
arch/arm/plat-omap/include/plat/clkdev_omap.h |2 +
arch/arm/plat-omap/include/plat/clock.h |2 +
3 files changed, 335 insertions(+), 328 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8c96567..96c0e3e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Clock data
+ * OMAP44xx Clock data
*
- * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Texas Instruments, Inc.
[sp] Since you are changing it, it should read:
Copyright (C) 2009-2011 Texas Instruments Incorporated
* Copyright (C) 2009-2010 Nokia Corporation
*
* Paul Walmsley (p...@pwsan.com)
@@ -127,42 +127,42 @@ static struct clk virt_3840_ck = {
};
[snip]...[snip]
int __init omap4xxx_clk_init(void)
{
struct omap_clk *c;
- u32 cpu_clkflg;
+ u32 cpu_clkflg = 0;
- if (cpu_is_omap44xx()) {
+ if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
cpu_clkflg = CK_443X;
+ } else if (cpu_is_omap446x()) {
+ cpu_mask = RATE_IN_4460;
+ cpu_clkflg = CK_446X;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h
b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index f1899a3..324446b 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -39,11 +39,13 @@ struct omap_clk {
#define CK_36XX (1 10) /*
36xx/37xx-specific clocks */
#define CK_443X (1 11)
#define CK_TI816X(1 12)
+#define CK_446X (1 13)
#define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS)
#define CK_AM35XX(CK_3505 | CK_3517) /* all Sitara AM35xx */
#define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX)
+#define CK_44XX (CK_443X | CK_446X)
[sp] Unrelated to this change, but extra whitespacing can be corrected.
#endif
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 006e599..21b1beb 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -58,10 +58,12 @@ struct clkops {
#define RATE_IN_36XX (1 4)
#define RATE_IN_4430 (1 5)
#define RATE_IN_TI816X (1 6)
+#define RATE_IN_4460 (1 7)
#define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
#define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
#define RATE_IN_3XXX (RATE_IN_34XX | RATE_IN_36XX)
+#define RATE_IN_44XX (RATE_IN_4430 | RATE_IN_4460)
/* RATE_IN_3430ES2PLUS_36XX includes 34xx/35xx with ES =2,
and all 36xx/37xx */
#define RATE_IN_3430ES2PLUS_36XX (RATE_IN_3430ES2PLUS |
RATE_IN_36XX)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 8/9] OMAP4: clockdomain: Use CHIP_IS_44XX to reuse all CD's on 4460
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, May 26, 2011 7:27 AM To: linux-omap Cc: Nayak, Rajendra Subject: [RFC][PATCH 8/9] OMAP4: clockdomain: Use CHIP_IS_44XX to reuse all CD's on 4460 [sp] Is CD as standard nomenclature? In any case CD's is different from CDs. ~sanjeev From: Rajendra Nayak rna...@ti.com The 4460 platform has no difference in the clockdomains as compared to the 4430 platform. Hence just update the .omap_chip field to make sure the same clockdomains model data can be reused on the 4460 platform. [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH 7/9] OMAP4: powerdomain: Update MPU powerdomain for 4460
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Thursday, May 26, 2011 7:27 AM
To: linux-omap
Cc: Nayak, Rajendra
Subject: [RFC][PATCH 7/9] OMAP4: powerdomain: Update MPU
powerdomain for 4460
From: Rajendra Nayak rna...@ti.com
The 4460 platform has changes in the MPU powerdomain,
hence model a new powerdomain for it and identify
is using the CHIP_IS_OMAP446X macro.
Also move all the common powerdomains to use
CHIP_IS_44XX so they are reused on OMAP4460.
[snip]...[snip]
+static struct powerdomain mpu_446x_pwrdm = {
+ .name = mpu_pwrdm,
+ .prcm_offs= OMAP4430_PRM_MPU_INST,
+ .prcm_partition = OMAP4430_PRM_PARTITION,
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
[sp] This change doesn't go with the description above.
Shouldn't this be CHIP_IS_OMAP44XX or CHIP_IS_OMAP446X
to be more future safe?
~sanjeev
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Cousson, Benoit; Paul Walmsley
Subject: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO
and rev_ids
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
(bothe OMAP 2420 and 2430) not for OMAP3 which is incorrect.
Fix the above by providing non-wakeup GPIO information through pdata
specific to the SoC.
The GPIO rev id provided in the hwmod database is the same
for OMAP2420
and OMAP2430. Change the GPIO rev ids in hwmod database as given below
so that it can be used to identify OMAP2420 and OMAP2430.
OMAP2420 - 0
OMAP2430 - 1
OMAP3- 2
OMAP4- 3
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_2420 0
#define GPIO_REV_2430 1
#define GPIO_REV_34XX 2
#define GPIO_REV_44xx 3
We don't have to refer back to this comment while reading the code.
I also believed that HWMODs were auto generated.
Can the changes to structures in this patch recreated using current
scripts?
~sanjeev
Signed-off-by: Charulatha V ch...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/gpio.c | 26
--
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio_omap.c | 11 +++
6 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 0446bd1..6cd26b4 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -56,6 +56,28 @@ static int omap2_gpio_dev_init(struct
omap_hwmod *oh, void *unused)
return -ENOMEM;
}
+ switch (oh-class-rev) {
+ case 0:
+ if (id == 1)
+ /* non-wakeup GPIO pins for OMAP2420 Bank1 */
+ pdata-non_wakeup_gpios = 0xe203ffc0;
+ else if (id == 2)
+ /* non-wakeup GPIO pins for OMAP2420 Bank2 */
+ pdata-non_wakeup_gpios = 0x08700040;
+ break;
+ case 2:
+ if (id == 2)
+ /* non-wakeup GPIO pins for OMAP3 Bank2 */
+ pdata-non_wakeup_gpios = 0x0001;
+ else if (id == 6)
+ /* non-wakeup GPIO pins for OMAP3 Bank6 */
+ pdata-non_wakeup_gpios = 0x0800;
+ break;
[sp] Where is the description on non-wakeup GPIOs in OMAP3?
Here is text from AM37x TRM:
[quote ...only relevant text]
Each GPIO module provides 32 dedicated general-purpose pins with input
and output capabilities; These pins can be configured for the
following applications:
- Data input (capture)/output (drive)
- Keyboard interface with a debounce cell
- Interrupt generation in
- Wake-up request generation in idle mode
[/quote]
Otherwise, what are the GPIO2_WAKEUPENABLE (0x4905 0020) and
GPIO6_WAKEUPENABLE (0x4905 8020) meant for?
+ default:
+ /* No non-wakeup GPIO pins for other SoCs */
+ break;
+ }
+
~sanjeev
[snip]...[snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/15] OMAP: GPIO: Remove hardcoded offsets in ctxt save/restore
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
To: linux-omap@vger.kernel.org
Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; DebBarma, Tarun Kanti;
Varadarajan, Charulatha
Subject: [PATCH 11/15] OMAP: GPIO: Remove hardcoded offsets
in ctxt save/restore
It is not required to use hard-coded offsets any more in context
save and restore functions and instead use the generic offsets
which have been correctly initialized during device registration.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/gpio.c |2 +
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio_omap.c | 123
++--
3 files changed, 40 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 0f8782f..5c888dd 100644
[snip]...[snip]
diff --git a/drivers/gpio/gpio_omap.c b/drivers/gpio/gpio_omap.c
index 28390a9..05c2857 100644
--- a/drivers/gpio/gpio_omap.c
+++ b/drivers/gpio/gpio_omap.c
@@ -1395,96 +1395,47 @@ restore_gpio_ctx:
void omap_gpio_save_context(struct gpio_bank *bank)
{
[sp] The [PATCH 06/15] OMAP4: GPIO: Save/restore context
seems to be doing exactly opposite:
It introduces the checks for
[quote]
+ if (bank-method == METHOD_GPIO_24XX) {
...
...
+ } else if (bank-method == METHOD_GPIO_44XX) {
[/quote]
and this patch removes the same checks.
Am I missing something?
~sanjeev
- if (bank-method == METHOD_GPIO_24XX) {
- bank-context.irqenable1 = __raw_readl(
- bank-base +
OMAP24XX_GPIO_IRQENABLE1);
- bank-context.irqenable2 = __raw_readl(
- bank-base +
OMAP24XX_GPIO_IRQENABLE2);
- bank-context.wake_en = __raw_readl(
- bank-base +
OMAP24XX_GPIO_WAKE_EN);
- bank-context.ctrl = __raw_readl(
- bank-base +
OMAP24XX_GPIO_CTRL);
- bank-context.oe = __raw_readl(
- bank-base + OMAP24XX_GPIO_OE);
- bank-context.leveldetect0 = __raw_readl(bank-base +
- OMAP24XX_GPIO_LEVELDETECT0);
- bank-context.leveldetect1 = __raw_readl(bank-base +
- OMAP24XX_GPIO_LEVELDETECT1);
- bank-context.risingdetect = __raw_readl(bank-base +
- OMAP24XX_GPIO_RISINGDETECT);
- bank-context.fallingdetect = __raw_readl(bank-base +
- OMAP24XX_GPIO_FALLINGDETECT);
- bank-context.dataout = __raw_readl(
- bank-base +
OMAP24XX_GPIO_DATAOUT);
- } else if (bank-method == METHOD_GPIO_44XX) {
- bank-context.irqenable1 = __raw_readl(
- bank-base +
OMAP4_GPIO_IRQSTATUSSET0);
- bank-context.irqenable2 = __raw_readl(
- bank-base +
OMAP4_GPIO_IRQSTATUSSET1);
- bank-context.wake_en = __raw_readl(
- bank-base +
OMAP4_GPIO_IRQWAKEN0);
- bank-context.ctrl = __raw_readl(
- bank-base + OMAP4_GPIO_CTRL);
- bank-context.oe = __raw_readl(
- bank-base + OMAP24XX_GPIO_OE);
- bank-context.leveldetect0 = __raw_readl(bank-base +
- OMAP4_GPIO_LEVELDETECT0);
- bank-context.leveldetect1 = __raw_readl(bank-base +
- OMAP4_GPIO_LEVELDETECT1);
- bank-context.risingdetect = __raw_readl(bank-base +
- OMAP4_GPIO_RISINGDETECT);
- bank-context.fallingdetect = __raw_readl(bank-base +
- OMAP4_GPIO_FALLINGDETECT);
- bank-context.dataout = __raw_readl(
- bank-base +
OMAP4_GPIO_DATAOUT);
- }
+ bank-context.irqenable1 =
+ __raw_readl(bank-base + bank-regs-irqenable);
+ bank-context.irqenable2 =
+ __raw_readl(bank-base +
bank-regs-irqenable2);
+ bank-context.wake_en =
+ __raw_readl(bank-base +
bank-regs-wkupstatus);
+ bank-context.ctrl = __raw_readl(bank-base + bank-regs-ctrl);
+ bank-context.oe = __raw_readl(bank-base +
bank-regs-direction);
+ bank-context.leveldetect0 =
+ __raw_readl(bank-base +
bank-regs-leveldetect0);
+
RE: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti Sent: Tuesday, May 24, 2011 7:55 PM To: linux-omap@vger.kernel.org Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha Subject: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure From: Charulatha V ch...@ti.com gpio_context array, which is used to save gpio bank's context, is used only for OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that it can be specific to each gpio bank and can be used for any OMAP architecture TODO: extend the gpio save/restore context function for OMAP4 architecture. This is done in one of the next patches in this series [sp] Should this TODO be part of commit? BTW, this is the last patch in the series. ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure
-Original Message- From: Premi, Sanjeev Sent: Thursday, May 26, 2011 3:29 PM To: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha Subject: RE: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti Sent: Tuesday, May 24, 2011 7:55 PM To: linux-omap@vger.kernel.org Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha Subject: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure From: Charulatha V ch...@ti.com gpio_context array, which is used to save gpio bank's context, is used only for OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that it can be specific to each gpio bank and can be used for any OMAP architecture TODO: extend the gpio save/restore context function for OMAP4 architecture. This is done in one of the next patches in this series [sp] Should this TODO be part of commit? BTW, this is the last patch in the series. Sorry, mistake... This showed up last on my mailbox. ~sanjeev ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 3:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul Walmsley
Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
GPIO and rev_ids
On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
From: Charulatha Vch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
(bothe OMAP 2420 and 2430) not for OMAP3 which is incorrect.
Fix the above by providing non-wakeup GPIO information
through pdata
specific to the SoC.
The GPIO rev id provided in the hwmod database is the same
for OMAP2420
and OMAP2430. Change the GPIO rev ids in hwmod database as
given below
so that it can be used to identify OMAP2420 and OMAP2430.
OMAP2420 - 0
OMAP2430 - 1
OMAP3- 2
OMAP4- 3
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_2420 0
#define GPIO_REV_2430 1
#define GPIO_REV_34XX 2
#define GPIO_REV_44xx 3
Well, it is not a magic number, it is a revision id that is
incremented
each time there is a difference in the IP.
The OMAP version - IP version link is done at hwmod level.
The driver
does not have to know it is an OMAP3 or OMAP4. In that case we did
change the IP version for every revisions, but OMAP5 will use
the OMAP4
revision.
I'm not even considering all the Davinci variants that are not named
OMAP but do use OMAP IPs... as you already know...
That can provide a rather confusing information for my point of view.
Whereas a comment like that will give you the exhaustive information.
0: OMAP2420
1: OMAP2430
2: OMAP3, DMxxx
3: OMAP4, OMAP5, DM816x
That being said, some drivers already did that, so I'm not opposed to
such change. I just think it is not the best approach.
At least it gives a pointer to the TRM that contains the IP doc.
[sp] Benoit, your are right from generation perspectove where the
it is easier to increment numbers but when we use comparison
code - as in this patch, comparison against a number isn't
readable.
As example:
+ switch (oh-class-rev) { ## This is auto-generated.
+ case 0: ## But this is our code.
I am recommending this to read as:
+ switch (oh-class-rev) { ## This is auto-generated.
+ case GPIO_REV_2420: ## More readable.
~sanjeev
We don't have to refer back to this comment while
reading the code.
I also believed that HWMODs were auto generated.
Can the changes to structures in this patch recreated
using current
scripts?
Only OMAP4 5 are generated today, and in anycase this
information is
some custom data added by driver owner. So we just have to
update that
information.
I cannot really use the real HW IP version because it is
irrelevant most
of the time. Maybe in the future we will be able to force the
HW team to
provide relevant data in that field :-)
Regards,
Benoit
~sanjeev
Signed-off-by: Charulatha Vch...@ti.com
Cc: Cousson, Benoitb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
---
arch/arm/mach-omap2/gpio.c | 26
--
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
arch/arm/plat-omap/include/plat/gpio.h |1 +
drivers/gpio/gpio_omap.c | 11 +++
6 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpio.c
b/arch/arm/mach-omap2/gpio.c
index 0446bd1..6cd26b4 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -56,6 +56,28 @@ static int omap2_gpio_dev_init(struct
omap_hwmod *oh, void *unused)
return -ENOMEM;
}
+ switch (oh-class-rev) {
+ case 0:
+ if (id == 1)
+ /* non-wakeup GPIO pins for OMAP2420 Bank1 */
+ pdata-non_wakeup_gpios = 0xe203ffc0;
+ else if (id == 2)
+ /* non-wakeup GPIO pins for OMAP2420 Bank2 */
+ pdata-non_wakeup_gpios = 0x08700040;
+ break;
+ case 2:
+ if (id == 2)
+ /* non-wakeup GPIO pins for OMAP3 Bank2 */
+ pdata-non_wakeup_gpios = 0x0001;
+ else if (id == 6)
+ /* non-wakeup GPIO pins for OMAP3 Bank6 */
+ pdata-non_wakeup_gpios
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 5:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul Walmsley
Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
GPIO and rev_ids
On 5/26/2011 1:47 PM, Premi, Sanjeev wrote:
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 3:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul Walmsley
Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
GPIO and rev_ids
On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
From: Charulatha Vch...@ti.com
Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
(bothe OMAP 2420 and 2430) not for OMAP3 which is incorrect.
Fix the above by providing non-wakeup GPIO information
through pdata
specific to the SoC.
The GPIO rev id provided in the hwmod database is the same
for OMAP2420
and OMAP2430. Change the GPIO rev ids in hwmod database as
given below
so that it can be used to identify OMAP2420 and OMAP2430.
OMAP2420 - 0
OMAP2430 - 1
OMAP3- 2
OMAP4- 3
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_2420 0
#define GPIO_REV_2430 1
#define GPIO_REV_34XX 2
#define GPIO_REV_44xx 3
Well, it is not a magic number, it is a revision id that is
incremented
each time there is a difference in the IP.
The OMAP version - IP version link is done at hwmod level.
The driver
does not have to know it is an OMAP3 or OMAP4. In that case we did
change the IP version for every revisions, but OMAP5 will use
the OMAP4
revision.
I'm not even considering all the Davinci variants that are
not named
OMAP but do use OMAP IPs... as you already know...
That can provide a rather confusing information for my
point of view.
Whereas a comment like that will give you the exhaustive
information.
0: OMAP2420
1: OMAP2430
2: OMAP3, DMxxx
3: OMAP4, OMAP5, DM816x
That being said, some drivers already did that, so I'm not
opposed to
such change. I just think it is not the best approach.
At least it gives a pointer to the TRM that contains the IP doc.
[sp] Benoit, your are right from generation perspectove where the
it is easier to increment numbers but when we use comparison
This is not even related to generation. A version number is a number.
If OMAP2 is using GPIO v1.6 and OMAP3 the version v2.2, only that IP
version is relevant for the driver.
For the documentation point of view, since we do not have a
per IP TRM,
then it can make sense to know where that IP is documented. But as I
said a comment is enough and will allow a much more relevant level of
details information than a define.
code - as in this patch, comparison against a number isn't
readable.
As example:
+ switch (oh-class-rev) { ## This is auto-generated.
+ case 0: ## But this is our code.
I am recommending this to read as:
+ switch (oh-class-rev) { ## This is auto-generated.
+ case GPIO_REV_2420: ## More readable.
More readable, maybe, but not necessarily relevant nor
accurate if the
same IP version is used in another chip or revision.
What IP version is used in a DM816x? GPIO_REV_3430, GPIO_REV_4430?
How is value 0 accurate?
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
-Original Message- From: Cousson, Benoit Sent: Thursday, May 26, 2011 6:17 PM To: Premi, Sanjeev Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha; Paul Walmsley Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids On 5/26/2011 2:38 PM, Premi, Sanjeev wrote: -Original Message- From: Cousson, Benoit Sent: Thursday, May 26, 2011 5:41 PM To: Premi, Sanjeev Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha; Paul Walmsley Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids On 5/26/2011 1:47 PM, Premi, Sanjeev wrote: -Original Message- From: Cousson, Benoit Sent: Thursday, May 26, 2011 3:41 PM To: Premi, Sanjeev Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha; Paul Walmsley Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids On 5/26/2011 11:23 AM, Premi, Sanjeev wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of DebBarma, Tarun Kanti Sent: Tuesday, May 24, 2011 7:55 PM From: Charulatha Vch...@ti.com Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx (bothe OMAP 2420 and 2430)not for OMAP3 which is incorrect. Fix the above by providing non-wakeup GPIO information through pdata specific to the SoC. The GPIO rev id provided in the hwmod database is the same for OMAP2420 and OMAP2430. Change the GPIO rev ids in hwmod database as given below so that it can be used to identify OMAP2420 and OMAP2430. OMAP2420 - 0 OMAP2430 - 1 OMAP3- 2 OMAP4- 3 [sp] Magic numbers should be avoided. Suggest using something like: #define GPIO_REV_2420 0 #define GPIO_REV_2430 1 #define GPIO_REV_34XX 2 #define GPIO_REV_44xx 3 Well, it is not a magic number, it is a revision id that is incremented each time there is a difference in the IP. [sp] Just to quote a definition: [quote]The term magic number or magic constant also refers to the programming practice of using numbers directly in source code. [/quote] It has no relation to whether/how it can signify something important. The OMAP version - IP version link is done at hwmod level. The driver does not have to know it is an OMAP3 or OMAP4. In that case we did change the IP version for every revisions, but OMAP5 will use the OMAP4 revision. [sp] I don't understand the confusion because IPs are anyways going to be used across. Many macros originally created for OMAP34XX are true/valid for OMAP36XX. And same holds good (probably) for OMAP24XX as well. But in each context, we are aware of the intended usage and can relate to the use and reuse better because it is quite evident. Use of OMAP2_CONTROL_GENERAL in OMAP34xx specific function is not accurate by your example below, but we all know the meaning and need for the same. I'm not even considering all the Davinci variants that are not named OMAP but do use OMAP IPs... as you already know... That can provide a rather confusing information for my point of view. [sp] So now what happens when existing IP gets changed to fix an issue in existing OMAP3 design. Going by same logic will we add another id for the same? Whereas a comment like that will give you the exhaustive information. 0: OMAP2420 1: OMAP2430 2: OMAP3, DMxxx 3: OMAP4, OMAP5, DM816x That being said, some drivers already did that, so I'm not opposed to such change. I just think it is not the best approach. [sp] Taking same point further, if the IP from OMAP4 above gets used to create OMAP3699 (for example). How does this case get handled? OR we expect users to know about exceptions each time they read code? Leaving aside the fact the situation is hypothetical; design should be generic to handle such situations. At least it gives a pointer to the TRM that contains the IP doc. [sp] Benoit, your are right from generation perspectove where the it is easier to increment numbers but when we use comparison This is not even related to generation. A version number is a number. If OMAP2 is using GPIO v1.6 and OMAP3 the version v2.2, only that IP version is relevant for the driver. For the documentation point of view, since we do not have a per IP TRM, then it can make sense to know where that IP is documented. But as I said
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: Menon, Nishanth Sent: Thursday, May 19, 2011 7:28 PM To: Premi, Sanjeev Cc: Hilman, Kevin; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled On Thu, May 19, 2011 at 05:30, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Hilman, Kevin Sent: Wednesday, May 18, 2011 10:04 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled Hi Sanjeev, Sanjeev Premi pr...@ti.com writes: There is an implicit assumption in current implementation that debugfs is always enabled. When debugfs is disabled, these errors are noticed during boot: omap_voltage_late_init: Unable to create voltage debugfs main dir vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu vdd_debugfs_init: Unable to create debugfs directory for vdd_core This patch fixes these errors by enclosing code related to debugfs in #ifdef CONFIG_DEBUG_FS..#endif. Boot tested on OMAP3EVM. Signed-off-by: Sanjeev Premi pr...@ti.com Sorry for the delay here, I've been on the road and finally catching up on the list. Basically, I'm in the process of a pretty major cleanup of the VC/VP and SR layers. For example, in my pm-wip/voltdm_* branches, the debugfs interface to the voltage layer has been completely removed. I'm also thinking of removing the SR debugfs interface also, as I don't really think we need a userspace interface for this. A board-level interface is probably enough (/me waits for flame from Nishanth :) That being said, your approach below isn't quite right in its usage of #ifdefs. Use of #ifdefs like this is frowned upon for many reasons. For starters, take a look the '#ifdefs are ugly' section of Documentation/SubmittingPatches. [sp] I don't like #ifdefs either but each time we cannot create a new file changes like this. The current code is a mess with debugfs used too frequently. And - all of it is not for debug. The location of ifdefs in in the patch illustrates it quite well. BTW, this isn't the only use of ifdefs in a C file in Linux. in reality the only reason you've had to do this patch was because we had a wicked handling of debugfs entries in voltage layer - with voltdm_c these are all gone. further any entries remaining (e.g. SR) are: dentry for debugfs file - just a minor overhead not deserving a #ifdef all other functions of debugfs (as per include/linux/debugfs.h) when debugfs is disabled in .config will be static inlined and we will not need any #ifdefs at all The real pending question is about functional SR debugfs entries that need to loose it's critical functionality. [sp] good argument for future not the present and past. Fact is that wicked handling of debugfs entries made their way. I am not worried about the patch in or out - few folks who were stuck on the issue would have used it anyway. But, whether each fix for today can be postponed for future restructuring. #ifdefs were just easy target for the postponement. ~sanjeev Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message-
From: Hilman, Kevin
Sent: Wednesday, May 18, 2011 10:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap:pm: Fix boot-time errors with
debugfs disabled
Hi Sanjeev,
Sanjeev Premi pr...@ti.com writes:
There is an implicit assumption in current implementation that
debugfs is always enabled.
When debugfs is disabled, these errors are noticed during boot:
omap_voltage_late_init: Unable to create voltage debugfs main dir
vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
vdd_debugfs_init: Unable to create debugfs directory for vdd_core
This patch fixes these errors by enclosing code related to debugfs
in #ifdef CONFIG_DEBUG_FS..#endif.
Boot tested on OMAP3EVM.
Signed-off-by: Sanjeev Premi pr...@ti.com
Sorry for the delay here, I've been on the road and finally
catching up
on the list.
Basically, I'm in the process of a pretty major cleanup of
the VC/VP and
SR layers. For example, in my pm-wip/voltdm_* branches, the debugfs
interface to the voltage layer has been completely removed. I'm also
thinking of removing the SR debugfs interface also, as I don't really
think we need a userspace interface for this. A board-level interface
is probably enough (/me waits for flame from Nishanth :)
That being said, your approach below isn't quite right in its usage of
#ifdefs. Use of #ifdefs like this is frowned upon for many reasons.
For starters, take a look the '#ifdefs are ugly' section of
Documentation/SubmittingPatches.
[sp] I don't like #ifdefs either but each time we cannot create
a new file changes like this.
The current code is a mess with debugfs used too frequently.
And - all of it is not for debug. The location of ifdefs in
in the patch illustrates it quite well.
BTW, this isn't the only use of ifdefs in a C file in Linux.
~sanjeev
Kevin
---
Patch was created and tested on the pm branch at commit:
d695569 : rebuild PM from branches
I am still finding my way around new code sructure. Haven't
been able to verify if smartreflex and voltage layer are
properly initialized. Though I do understand that smartreflex
won't work without debugfs.
arch/arm/mach-omap2/smartreflex.c | 15 +++
arch/arm/mach-omap2/voltage.c |8
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2ce2fb7..b757632 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -54,7 +54,9 @@ struct omap_sr {
struct list_headnode;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain*voltdm;
+#ifdef CONFIG_DEBUG_FS
struct dentry *dbg_dir;
+#endif
};
/* sr_list contains all the instances of smartreflex module */
@@ -826,7 +828,9 @@ static int __init omap_sr_probe(struct
platform_device *pdev)
struct omap_sr *sr_info = kzalloc(sizeof(struct
omap_sr), GFP_KERNEL);
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
+#ifdef CONFIG_DEBUG_FS
struct dentry *vdd_dbg_dir, *nvalue_dir;
+#endif
struct omap_volt_data *volt_data;
int i, ret = 0;
@@ -903,6 +907,7 @@ static int __init omap_sr_probe(struct
platform_device *pdev)
* If the voltage domain debugfs directory is not created, do
* not try to create rest of the debugfs entries.
*/
+#ifdef CONFIG_DEBUG_FS
vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info-voltdm);
if (!vdd_dbg_dir) {
ret = -EINVAL;
@@ -952,14 +957,22 @@ static int __init
omap_sr_probe(struct platform_device *pdev)
(void) debugfs_create_x32(name, S_IRUGO |
S_IWUSR, nvalue_dir,
(sr_info-nvalue_table[i].nvalue));
}
+#else
+ omap_voltage_get_volttable(sr_info-voltdm, volt_data);
+ if (!volt_data) {
+ ret = -ENODATA;
+ }
+#endif /* CONFIG_DEBUG_FS */
return ret;
+#ifdef CONFIG_DEBUG_FS
err_debugfs:
debugfs_remove_recursive(sr_info-dbg_dir);
err_iounmap:
list_del(sr_info-node);
iounmap(sr_info-base);
+#endif
err_release_region:
release_mem_region(mem-start, resource_size(mem));
err_free_devinfo:
@@ -988,8 +1001,10 @@ static int __devexit
omap_sr_remove(struct platform_device *pdev)
if (sr_info-autocomp_active)
sr_stop_vddautocomp(sr_info);
+#ifdef CONFIG_DEBUG_FS
if (sr_info-dbg_dir)
debugfs_remove_recursive(sr_info-dbg_dir);
+#endif
list_del(sr_info-node);
iounmap(sr_info-base);
diff --git a/arch/arm/mach-omap2/voltage.c
b/arch/arm/mach-omap2/voltage.c
index 9ef3789..6153211 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2
RE: [PATCH] omap3: boot message is not an error
-Original Message- From: Hilman, Kevin Sent: Wednesday, May 18, 2011 2:27 PM To: Jarkko Nikula Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap3: boot message is not an error Jarkko Nikula jhnik...@gmail.com writes: On Tue, 17 May 2011 19:33:41 +0200 Kevin Hilman khil...@ti.com wrote: Hi Sanjeev, On Tue, 2011-05-17 at 20:32 +0530, Sanjeev Premi wrote: With current level, it shows up on the console despite using 'silent' in bootargs. Signed-off-by: Sanjeev Premi pr...@ti.com --- 1) Couldn't find better text on commit message. Any suggestions? 2) Though pm34xx.x is changed, the change itself is no related to power management. Hence, did annotate pm: Well, it's a change to PM core code, so PM prefix is fine. How about: OMAP3: PM: boot message is not an error, use pr_info Also, please Cc linux-arm-kernel, and I will queue this fix for 2.6.40. ... arch/arm/mach-omap2/pm34xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Does this bootup info print here bring any benefit for pm developers and users? For me it looks it can be removed as the pm34xx.c is always compiled and initialized for CONFIG_ARCH_OMAP3 so IMHO only error prints from pm34xx.c are relevant. Good point. It's probably better to simply remove the printk. Ok. I will resend the patch with removal... Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: Menon, Nishanth Sent: Wednesday, May 18, 2011 1:55 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled On Thu, May 12, 2011 at 14:16, Premi, Sanjeev pr...@ti.com wrote: [...] This patch fixes these errors by enclosing code related to debugfs in #ifdef CONFIG_DEBUG_FS..#endif. generic - couple of comments - I think the #defs should be isolated off to headers - maybe the right approach may be to move the debugfs [sp] None of the code encapsulated here is header material. I guess you have seen the patch below. entries off to a separate file? or pm-debug.c?? [sp] I wish it was all debug code. It is operational code. Check the Kconfig in plat-omap. Smartreflex is not even expected to work without debugfs. Though I believe much of the data put in debugfs can be in local lists/structures. That was supposed to be my next set of patches - as I understand the implementation better. [...] Could I suggest Kevin's volt cleanup series - based off _c branch if there are cleanups to be done? [sp] I didn't see it updated for 5 weeks. hence used this. but patch should apply cleanly... While cleaning up voltdm_c set earlier this week, I think your changes apply better there. btw, I could incorporate a bit of your code into my patch, esp the one Tony commented on http://marc.info/?l=linux-omapm=130570559515977w=2 but, overall, on the topic of SR, either: a) move SR autocomp into sysfs (and dump the rest of the debugfs - it is useful for validation, but does'nt really provide additional info) - given that it used to reside in /sys/power/sr_vddx_autocomp and then moved to debugfs, I am not sure if this is the right path b) move SR autocomp into a board defined configuration.. more intrusive, but folks would really want to enable SR as an option at times from userspace - many distros and devices do this (e.g. N900).. [sp] I am not sure what you are suggesting. Can't we take in the patch and then do the movements? ... the ones that doesn't seem to be implemented so far (based on your comments). ~sanjeev Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: Menon, Nishanth Sent: Wednesday, May 18, 2011 2:36 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled On Wed, May 18, 2011 at 04:00, Premi, Sanjeev pr...@ti.com wrote: While cleaning up voltdm_c set earlier this week, I think your changes apply better there. btw, I could incorporate a bit of your code into my patch, esp the one Tony commented on http://marc.info/?l=linux-omapm=130570559515977w=2 ok this part got rejected pending regulator framework for scalable voltage domains.. but, overall, on the topic of SR, either: a) move SR autocomp into sysfs (and dump the rest of the debugfs - it is useful for validation, but does'nt really provide additional info) - given that it used to reside in /sys/power/sr_vddx_autocomp and then moved to debugfs, I am not sure if this is the right path b) move SR autocomp into a board defined configuration.. more intrusive, but folks would really want to enable SR as an option at times from userspace - many distros and devices do this (e.g. N900).. [sp] I am not sure what you are suggesting. Can't we take in the patch and then do the movements? ... the ones that doesn't seem to be implemented so far (based on your comments). depends on what Kevin thinks is the future of voltdm(in terms of which .4x target) - might be good to focus our attention into a single branch and cleanit up for upstream.. I am personally not sure what should autocomp's future should be - I think option of having boards be able to define it - maybe as part of regulator framework + debugfs cleanup similar(as voltdm_c has removed I believe all of voltage debugfs - so your patch can be much smaller and effective there).. [sp] Reworking the patch for different branch is fine. But what about the pm branch today. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Friday, May 13, 2011 6:18 PM To: linux-omap@vger.kernel.org Cc: Menon, Nishanth Subject: RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled [snip]...[snip] [sp] I can try this on Panda. Will be able to get one tomorrow. Tested same uImage on Panda as well. Just pasting the top header here... [0.00] Linux version 2.6.39-rc4-13782-gd695569-dirty (premi@mylinux) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #6 SMP Thu May 12 21:40:58 IST 2011 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] Truncating RAM at 8000-bfff to -afff (vmalloc region overlap). [0.00] OMAP4430 ES2.1 Kevin, Wanted to check if you have look at this patch? ~sanjeev [snip]...[snip]-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 0/2] [RFC] Shrink clock data utilizing preprocessor
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Tuesday, May 17, 2011 6:37 PM
To: Vladimir Zapolskiy
Cc: Tony Lindgren; Cousson, Benoit;
linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCHv2 0/2] [RFC] Shrink clock data utilizing
preprocessor
Vladimir Zapolskiy vzapols...@gmail.com writes:
This change shows a possibility to utilize C preprocessor to remove
redundant data from clock definitions for OMAP4 architecture.
If the change is evaluated as a positive one, the same
approach could
be applied in reducing LOCs from other files, which contain
monotonous
data enumeration.
Now that I can apply these patches and look at the result, I
still have
the same opinion. For me, this results in a major loss of
readability.
[sp] I agree here. __VA_ARGS__ in most of the macros make it difficult
to undertsand the containment relation.
Multiple inclusion of macros within another makes it difficult
to follow the chain/ sequence.
Using a set of changes to illustrate issue with scalability of
the macros as well:
-static const struct clksel dpll_core_m2_div[] = {
- { .parent = dpll_core_ck, .rates = div31_1to31_rates },
- { .parent = NULL },
-};
+DEFINE_CLKSEL(dpll_core_m2_div, dpll_core_ck, div31_1to31_rates);
...
... many lines below...
...
-static const struct clksel iva_hsd_byp_clk_mux_sel[] = {
- { .parent = sys_clkin_ck, .rates = div_1_0_rates },
- { .parent = div_iva_hs_clk, .rates = div_1_1_rates },
- { .parent = NULL },
-};
+DEFINE_CLKSEL2(iva_hsd_byp_clk_mux_sel, sys_clkin_ck, div_iva_hs_clk);
In DEFINE_CLKSEL() we need to pass the rate as argument
and in DEFINE_CLKSEL2() it isn't because we they are hardcoded
for current implementation.
But then,
+#define DEFINE_CLKSEL3(_name, _parent0, _parent1, _parent2)\
+ static const struct clksel _name[] = { \
+ { .parent = _parent0, .rates = div_1_0_rates },\
+ { .parent = _parent1, .rates = div_1_1_rates },\
+ { .parent = _parent2, .rates = div_1_2_rates },\
+ { .parent = NULL }, \
+ }
All these definitions don't scale well.
~sanjeev
Changes just to make nice diffstats are fine, but not when it impacts
readability, etc. Especially since this data will likely be
eventually
moved to device tree, I'd rather see consolidation efforts focused
elsewhere.
Kevin
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs
-Original Message- From: Munegowda, Keshava Sent: Friday, May 13, 2011 12:04 PM To: Igor Grinberg Cc: Premi, Sanjeev; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: Re: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs On Thu, May 12, 2011 at 4:58 PM, Igor Grinberg grinb...@compulab.co.il wrote: On 05/12/11 13:49, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAME usbhs-omap +#define USBHS_DRIVER_NAME usbhs_omap #define OMAP_EHCI_DEVICE ehci-omap #define OMAP_OHCI_DEVICE ohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? Also, can't we avoid once again changing the clock names (at least for a while...)? Is that really necessary? Can't hwmod use current clock names? Because, Linus is sooo happy each time he sees that kind of changes This was actually earlier comment saying use _ as the convention for hwmod and runtime pm. only usbhs_omap uses the hwmod; the ehci and ohci drivers are children of usbhsh and they get the data from usbhs. Hence the older name of ehci and ochi drivers are retained as it is. if it is really needed, to change ehci and ohci driver names , then i can make it as another patch. [sp] A common convetion helps. Another patch will definitely help usability. ~sanjeev -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Friday, May 13, 2011 12:46 AM To: Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled [sp] Last I tried, with Vishwa's dvfs branch on panda without voltage registrations, things could crash :( if I get some time I will try to port Vishwa's series onto kevin's branch as well and test and provide any patches necessary. [sp] I can try this on Panda. Will be able to get one tomorrow. Tested same uImage on Panda as well. Just pasting the top header here... [0.00] Linux version 2.6.39-rc4-13782-gd695569-dirty (premi@mylinux) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #6 SMP Thu May 12 21:40:58 IST 2011 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] Truncating RAM at 8000-bfff to -afff (vmalloc region overlap). [0.00] OMAP4430 ES2.1 ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin Sent: Friday, May 13, 2011 6:46 PM To: Tony Lindgren Cc: Cousson, Benoit; Vladimir Zapolskiy; Paul Walmsley; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] [RFC] OMAP4: clock: shrink clock data utilizing preprocessor. Tony Lindgren t...@atomide.com writes: * Cousson, Benoit b-cous...@ti.com [110513 15:18]: Signed-off-by: Vladimir Zapolskiyvzapols...@gmail.com Unfortunately I don't have an automated tool, but that would be great to have such a script. For this time I've checked the correctness of the change comparing the preprocessed output. In fact these files are already generated automatically, as written in the header file. So changing the output format should straightforward. At least for OMAP4... OMAP2 and OMAP3 were done manually some time ago. Sounds like the important thing to consider here is how these macros should be set up considering the upcoming generic clock framework and device tree changes. So let's wait a few days for comments from Benoit and Paul on the format for the macros so we don't need to redo them again later. Of course there might be other things to consider too.. ... like readability. After seeing the patch (thanks Benoit), I think this is bad tradeoff between readability and lines-of-code. Personally, I don't think we should be trading readability for diffstat goodness. I have a strong dislike for these multi-line macros, but it's up to Paul/Benoit to decide how this should look. [sp] Was the patch posted again? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAMEusbhs-omap +#define USBHS_DRIVER_NAMEusbhs_omap #define OMAP_EHCI_DEVICE ehci-omap #define OMAP_OHCI_DEVICE ohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? ~sanjeev -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: Menon, Nishanth Sent: Thursday, May 12, 2011 11:32 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled On Thu, May 12, 2011 at 12:36, Sanjeev Premi pr...@ti.com wrote: There is an implicit assumption in current implementation that debugfs is always enabled. thanks for doing this. When debugfs is disabled, these errors are noticed during boot: omap_voltage_late_init: Unable to create voltage debugfs main dir vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu vdd_debugfs_init: Unable to create debugfs directory for vdd_core This patch fixes these errors by enclosing code related to debugfs in #ifdef CONFIG_DEBUG_FS..#endif. generic - couple of comments - I think the #defs should be isolated off to headers - maybe the right approach may be to move the debugfs [sp] None of the code encapsulated here is header material. I guess you have seen the patch below. entries off to a separate file? or pm-debug.c?? [sp] I wish it was all debug code. It is operational code. Check the Kconfig in plat-omap. Smartreflex is not even expected to work without debugfs. Though I believe much of the data put in debugfs can be in local lists/structures. That was supposed to be my next set of patches - as I understand the implementation better. Boot tested on OMAP3EVM. Signed-off-by: Sanjeev Premi pr...@ti.com --- Patch was created and tested on the pm branch at commit: d695569 : rebuild PM from branches Could I suggest Kevin's volt cleanup series - based off _c branch if there are cleanups to be done? [sp] I didn't see it updated for 5 weeks. hence used this. but patch should apply cleanly... I am still finding my way around new code sructure. Haven't been able to verify if smartreflex and voltage layer are properly initialized. Though I do understand that smartreflex won't work without debugfs. Last I tried, with Vishwa's dvfs branch on panda without voltage registrations, things could crash :( if I get some time I will try to port Vishwa's series onto kevin's branch as well and test and provide any patches necessary. [sp] I can try this on Panda. Will be able to get one tomorrow. ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
From: Steve Calfee [stevecal...@gmail.com] Sent: Wednesday, May 11, 2011 11:46 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; Girdwood, Liam Subject: Re: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type [snip]...[snip] Hi, I removed all but the linux-omap list for my question. [sp] Using a separate thread for this issues would have gotten more eyes! I am trying to get the beagleboardxm to work with an external codec. I am trying to use a mcbsp1 via the trainer board where it level shifts to 5 volts. I have applied this patch (I am on 2.6.39rc4), but still no joy. I have a small analyzer attached to the I/O pins and important things like the bit clock does not wiggle. First a side question. In the arch/arm/mach-omap2/Kconfig when I select BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference manual says The BeagleBoard-xM processor is the DM3730CBP 1GHz version which to me implies the proper package selection should be OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for them, but I cant quickly tell the difference. Does this matter for mcbspx? [sp] Check this page to find the differences: http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide ~sanjeev [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap2/omapfb: make DBG() more resistant in if-else constructions
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Niels de Vos
Sent: Tuesday, May 10, 2011 2:51 PM
To: linux-omap@vger.kernel.org
Cc: linux-fb...@vger.kernel.org;
linux-ker...@vger.kernel.org; Niels de Vos
Subject: [PATCH] omap2/omapfb: make DBG() more resistant in
if-else constructions
When DBG() is used in a simple if-else, the resulting code path
currently depends on the definition of DBG(). Inserting the
statement in
a do { ... } while (0) prevents this possible misuse.
Signed-off-by: Niels de Vos nde...@redhat.com
---
Note, I have not found any offenders, but a mistake can
easily be made.
The following example shows what can go wrong if little intention is
paid to the definition of the DBG() macro.
Example:
if something_went_wrong()
DBG(oh no, something went wrong!\n);
else
printk(all went fine\n);
Old result where the else is placed inside the first if-statment:
if something_went_wrong() {
if (omapfb_debug) {
printk(KERN_DEBUG oh no, something
went wrong!\n);
} else {
printk(all went fine\n);
}
}
New result where the else is an alternative to the first if-statement:
if something_went_wrong() {
do {
if (omapfb_debug)
printk(KERN_DEBUG oh no,
something went wrong!\n);
} while (0);
} else {
printk(all went fine\n);
}
---
drivers/video/omap2/omapfb/omapfb.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb.h
b/drivers/video/omap2/omapfb/omapfb.h
index 1305fc9..a01b0bb 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -34,8 +34,10 @@
#ifdef DEBUG
extern unsigned int omapfb_debug;
#define DBG(format, ...) \
- if (omapfb_debug) \
- printk(KERN_DEBUG OMAPFB: format, ## __VA_ARGS__)
+ do { \
+ if (omapfb_debug) \
+ printk(KERN_DEBUG OMAPFB: format, ##
__VA_ARGS__); \
+ while (0)
A real good find. Wondering if it really didn't create any problems so far...
~sanjeev
#else
#define DBG(format, ...)
#endif
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Valentin, Eduardo Sent: Wednesday, April 13, 2011 8:51 PM To: Paul Walmsley; Kevin Hilman Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL As per OMAP3 erratum (i671), ROM code adds extra latencies while restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1. This patch stores 0's in scratchpad content area corresponding to AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since it won't respect proper programing scheme. This register is then stored in prcm context. The saving and restore is now done by kernel side. Here follow the erratum description DESCRIPTION After OFF mode transition, among many restorations, the ROM Code restores the CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL. In case the restoration data stored in scratchpad memory contains a field CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and locks the PER DPLL does not respect the PER DPLL programming scheme. In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER DPLL, the ROM Code does not hang. Only extra latencies are introduced at wake-up. [sp] You seem to have missed this patch: http://marc.info/?l=linux-arm-kernelm=129735383925285w=2 ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
-Original Message- From: Valentin, Eduardo Sent: Thursday, April 14, 2011 11:04 PM To: Premi, Sanjeev Cc: Valentin, Eduardo; Paul Walmsley; Kevin Hilman; Linux-OMAP; Linux-ARM Subject: Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL Hello Sanjeev, On Thu, Apr 14, 2011 at 09:13:14AM -0500, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Valentin, Eduardo Sent: Wednesday, April 13, 2011 8:51 PM To: Paul Walmsley; Kevin Hilman Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL As per OMAP3 erratum (i671), ROM code adds extra latencies while restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1. This patch stores 0's in scratchpad content area corresponding to AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since it won't respect proper programing scheme. This register is then stored in prcm context. The saving and restore is now done by kernel side. Here follow the erratum description DESCRIPTION After OFF mode transition, among many restorations, the ROM Code restores the CM_AUTOIDLE_PLL register, and after that, it tries to relock the PER DPLL. In case the restoration data stored in scratchpad memory contains a field CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM Code restores and locks the PER DPLL does not respect the PER DPLL programming scheme. In that case, the DPLL might not lock. Meanwhile, when trying to lock the PER DPLL, the ROM Code does not hang. Only extra latencies are introduced at wake-up. [sp] You seem to have missed this patch: http://marc.info/?l=linux-arm-kernelm=129735383925285w=2 Right, But that one doesn't clear the AUTO_PERIPH_DPLL bits in the scratchpad area to avoid rom code extra overhead (check my patch description). Besides, why do we want to add more code inside omap_sram_idle, if we have better places to this SR? Didn't see that as a comment earlier? ~sanjeev ~sanjeev All best, -- Eduardo Valentin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets into VDD structure
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Hilman, Kevin
Sent: Saturday, March 19, 2011 5:49 AM
To: linux-omap@vger.kernel.org
Cc: Paul Walmsely; Cousson, Benoit
Subject: [PATCH 2/7] OMAP2+: voltage: move PRCM mod offets
into VDD structure
Eliminate need for global variables for the various PRM
module offsets by
making them part of the VDD structure.
Eventually, these will likely be moved again, or more likely removed,
but for now just getting rid of them as global variabes so that the
voltage domain initialization can be cleaned up.
Signed-off-by: Kevin Hilman khil...@ti.com
[sp] This is almost what I intended to do in the clean-up patches
posted earlier; but for few differences.
Putting them here as well.
[snip...snip]
diff --git a/arch/arm/mach-omap2/voltage.h
b/arch/arm/mach-omap2/voltage.h
index e9f5408..44edc1e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -133,6 +133,9 @@ struct omap_vdd_info {
struct dentry *debug_dir;
u32 curr_volt;
bool vp_enabled;
+
+ s16 prm_mod;
+ s16 prm_irqst_mod;
[sp] Can we match the type with the functions these are eventually
passed to?
Also, prm_mod is comstant for the silicon.
Shouldn't it be a local static instead. Else, same value is
repeated for each vdd.
~sanjeev
[snip...snip]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFCv2 2/2] AM35x: voltage: Basic initialization
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, March 16, 2011 4:33 PM
To: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: RE: [RFCv2 2/2] AM35x: voltage: Basic initialization
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sanjeev Premi
Sent: Wednesday, March 16, 2011 1:02 PM
To: linux-omap@vger.kernel.org
Cc: Sanjeev Premi
Subject: [RFCv2 2/2] AM35x: voltage: Basic initialization
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
Many functions emply fucntions have been defined to plug
into existing voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
[snip]...[snip]
+/**
+ * AM35x - Empty initialization of voltage processor
+ */
+static void __init am3517_vp_init(struct omap_vdd_info *vdd)
+{
+}
+
+/**
* omap_voltage_early_init()- Volatage driver early init
*/
static int __init omap_voltage_early_init(void)
{
int i;
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ vdd_info= am3517_vdd_info;
+ nr_scalable_vdd =
AM3517_NR_SCALABLE_VDD;
As you have mentioned that there is no voltage scaling supported, then
shoudn't nr_scalable_vdd = 0?
If nr_scalable_vdd is 0, then you probably would not need any
other TPS
specific changes in Voltage.c as VP and VC initialization itself is
skipped.
[sp] Yes, there is no voltage scaling; but there are two problems in the
flow.
Notice I had this value 0 in previous RFC; and yes I expected the
vp and vc to be excluded as you say; however, code isn't really
meant to do so.
Few loops using nr_scalable_vdd fail as value 0 doesn't meet the
entry criteria. This problem is/was easily fixes by an additional
if statement.
The things, however, get stuck in HWMOD again when the parent of
omap3xxx_l3_main_hwmod is set as core. Changing this causes
another cascade of changes leading to almost duplicating the complete
hwmod structure for AM35x.
Easy solution was to set use core. Rest of the changes in the patch
ensure that code flows properly - and there is no scaling.
~sanjeev
Vishwa
+ vc_init = am3517_vc_init;
+ vp_init = am3517_vp_init;
+ vdd_data_configure = am3517_vdd_data_configure;
+ } else if (cpu_is_omap34xx()) {
vdd_info = omap3_vdd_info;
nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
vc_init = omap3_vc_init;
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
FW: omap2+ voltage: Few queries
Hi all,
While trying to understand the voltage layer, i have few comments and
doubts. This is not a comprehensive list, but for starters:
1) Functions omap3_voltage_read_reg(), omap3_voltage_write_reg()
which in turn call omap2_prm_read_mod_reg and omap2_prm_write_mod_reg()
These functions are always called via function pointer contained
in omap_vdd_info.
What is the need for additional layer?
shouldn't be just do the following:
vdd-read_reg = omap2_prm_read_mod_reg ;
vdd-write_reg = omap2_prm_write_mod_reg ;
Same holds good for similar functions for OMAP4.
2) Structure omap_volt_data is used to describe the nominal voltage
for each OPP, However, presence of sr_efuse_offs, sr_errminlimit,
vp_errgain make assumptions on presence of SmartReflex and VP.
Value 0 to these fields cannot safely be used to indicate the
not used status - esp for sr_xx fields.
Shouldn't we delink them. something like:
struct omap_volt_data {
u32 volt_nominal;
u8 vp_errgain; /* Assuming that value 0 is equiv to not used */
struct volt_sr_data* sr_data;
}
3) Struct omap_volt_pmic_info should be trimmed to keep only PMIC
related info. Will make it easier to add support for other PMICs.
Suggestion:
struct omap_pmic_info {
int slew_rate;
int step_size;
u8 i2c_slave_addr;
u8 pmic_reg;
struct omap_pmic_extra_info * extra;
unsigned long (*vsel_to_uv) (const u8 vsel);
u8 (*uv_to_vsel) (unsigned long uV);
};
BTW, what does the PMIC register indicate? target addr on PMIC?
/* Not all PMICs would be able to support these features */
struct omap_pmic_extra_info {
u32 on_volt;
u32 onlp_volt;
u32 ret_volt;
u32 off_volt;
};
extra is just random name, even aux standing for auxilliary
should do.
struct omap_vp_info { /* just random name for this mail only */
u8 vp_erroroffset;
u8 vp_vstepmin;
u8 vp_vstepmax;
u8 vp_vddmin;
u8 vp_vddmax;
u8 vp_timeout_us;
};
Can this/ Should this be combined with an existing structure?
e.g. omap_vp_common_data?
I have some work-in-progress changes. Based on the responses, i will
tailor them and send across tomorrow.
Best regards,
Sanjeev
(folks in cc: sorry for resend. Original mail in
was mistakenly sent in HTML format;
and not delivered to the list)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap3: voltage: fix variable type and name
-Original Message- From: Hilman, Kevin Sent: Friday, March 18, 2011 1:42 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 2/2] omap3: voltage: fix variable type and name Sanjeev Premi pr...@ti.com writes: In all usages, variables prm_mod_offs and prm_irqst_ocp_mod_offs are expected to be u16 but have been declared as s16. What kind of problem is that causing? [sp] No, it wasn't causing any problems 0 because offset value wouldn't reach the signed / unsigned limits; but didn't seem right while reading the code. ~sanjeev Kevin In addition, renamed prm_irqst_ocp_mod_offs to ocp_sysreg_prm_offs for better association with the TRM. Original name perhaps came from the current usage of this offset to reach PRM_IRQSTATUS_MPU offset. [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] omap3: voltage: remove unnecessary param passing
-Original Message-
From: Hilman, Kevin
Sent: Friday, March 18, 2011 1:41 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/2] omap3: voltage: remove unnecessary
param passing
Sanjeev Premi pr...@ti.com writes:
It is not necessary to pass the params prm_mod and
prm_irqst_mod to omap_voltage_early_init().
Signed-off-by: Sanjeev Premi pr...@ti.com
Hi Sanjeev,
I also started working on cleaning some of this up, but I took a
slightly different approach[1], namely I make these offsets
part of the
VDD structure so that this data stays in the data files.
I'm still working on the series, but the work-in-progress is in my
pm-wip/voltdm branch, which I expect to post for comment tomorrow.
Kevin
[1]
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p
m.git;a=commit;h=185cdf40ad978a466106b52fce9b68ca7081f358
[sp] I had considered this, but the PRM offset wouldn't change for
each VDD. Therefore, opted to keep static in the file just as
few other files e.g. control.c
~sanjeev
[2]
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-p
m.git;a=shortlog;h=refs/heads/pm-wip/voltdm
---
arch/arm/mach-omap2/voltage.c | 18
++
arch/arm/mach-omap2/voltage.h |3 +--
arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +
arch/arm/mach-omap2/voltagedomains44xx_data.c |6 +-
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c
b/arch/arm/mach-omap2/voltage.c
index c6facf7..ce3098a 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -1096,12 +1096,22 @@ int __init omap_voltage_late_init(void)
}
/* XXX document */
-int __init omap_voltage_early_init(s16 prm_mod, s16
prm_irqst_ocp_mod,
- struct omap_vdd_info
*omap_vdd_array[],
+int __init omap_voltage_early_init(struct omap_vdd_info
*omap_vdd_array[],
u8 omap_vdd_count)
{
- prm_mod_offs = prm_mod;
- prm_irqst_ocp_mod_offs = prm_irqst_ocp_mod;
+ if (cpu_is_omap44xx()) {
+ prm_mod_offs = OMAP4430_PRM_DEVICE_INST;
+ prm_irqst_ocp_mod_offs = OMAP4430_PRM_OCP_SOCKET_INST;
+ } else if (cpu_is_omap34xx()) {
+ prm_mod_offs = OMAP3430_GR_MOD;
+ prm_irqst_ocp_mod_offs = OCP_MOD;
+ } else {
+ /* TODO:
+* What should be done for OMAP24xx?
+* Would we even reach here?
+*/
+ }
+
vdd_info = omap_vdd_array;
nr_scalable_vdd = omap_vdd_count;
return 0;
diff --git a/arch/arm/mach-omap2/voltage.h
b/arch/arm/mach-omap2/voltage.h
index e9f5408..b56530e 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -151,8 +151,7 @@ struct omap_volt_data
*omap_voltage_get_voltdata(struct voltagedomain *voltdm,
unsigned long volt);
unsigned long omap_voltage_get_nom_volt(struct
voltagedomain *voltdm);
struct dentry *omap_voltage_get_dbgdir(struct
voltagedomain *voltdm);
-int __init omap_voltage_early_init(s16 prm_mod, s16 prm_irqst_mod,
- struct omap_vdd_info
*omap_vdd_array[],
+int __init omap_voltage_early_init(struct omap_vdd_info
*omap_vdd_array[],
u8 omap_vdd_count);
#ifdef CONFIG_PM
int omap_voltage_register_pmic(struct voltagedomain *voltdm,
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index def230f..6f6999d 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -70,8 +70,6 @@ static struct omap_vdd_info *omap3_vdd_info[] = {
/* OMAP3 specific voltage init functions */
static int __init omap3xxx_voltage_early_init(void)
{
- s16 prm_mod = OMAP3430_GR_MOD;
- s16 prm_irqst_ocp_mod = OCP_MOD;
if (!cpu_is_omap34xx())
return 0;
@@ -88,8 +86,7 @@ static int __init
omap3xxx_voltage_early_init(void)
omap3_vdd2_info.volt_data = omap34xx_vddcore_volt_data;
}
- return omap_voltage_early_init(prm_mod, prm_irqst_ocp_mod,
- omap3_vdd_info,
+ return omap_voltage_early_init(omap3_vdd_info,
ARRAY_SIZE(omap3_vdd_info));
};
core_initcall(omap3xxx_voltage_early_init);
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index cb64996..208a67d 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -81,9 +81,6 @@ static struct omap_vdd_info *omap4_vdd_info[] = {
/* OMAP4 specific voltage init functions */
static int __init omap44xx_voltage_early_init(void)
{
- s16
RE: [RFC][PATCH 2/3] OMAP PM: Add support for bypassing VP/VC in Voltage layer
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath Sent: Tuesday, March 15, 2011 8:04 PM To: linux-omap@vger.kernel.org Cc: Sripathy, Vishwanath Subject: [RFC][PATCH 2/3] OMAP PM: Add support for bypassing VP/VC in Voltage layer Currently Voltage layer assumes that all PMICs use VP/VC for Voltage scaling. There can be some instances where PMIC would want to bypass VP/VC for voltage scaling. So make VOltage layer flexible enough to handle this. [sp] This series still considers various PMICs meaning various PMICs in TWL family. However, this isn't always the case. I had posted an RFC indicating issues that we come across when PMIC is not TWLx0y0. I now have an update version of these patches - will be posting them shortly - for reference. In my opinion the cleanup needs to start at the basic PMIC integration - only then we can have separation of concerns - opp, voltage and smartreflex. See: http://marc.info/?l=linux-omapm=129848392424250w=2 ~sanjeev Signed-off-by: Vishwanath BS vishwanath...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [HELP] Audio on BeagleBoard xM can't work
-Original Message- From: Bob Liu [mailto:lliu...@gmail.com] Sent: Wednesday, March 16, 2011 9:09 AM To: Premi, Sanjeev Cc: Jarkko Nikula; linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; l...@metafoo.de; p...@pwsan.com; peter.ujfal...@nokia.com; Koyamangalath, Abhilash Subject: Re: [HELP] Audio on BeagleBoard xM can't work On Wed, Mar 16, 2011 at 12:21 AM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bob Liu Sent: Tuesday, March 15, 2011 3:27 PM To: Jarkko Nikula Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; l...@metafoo.de; p...@pwsan.com; peter.ujfal...@nokia.com Subject: Re: [HELP] Audio on BeagleBoard xM can't work On Tue, Mar 15, 2011 at 5:53 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Tue, 15 Mar 2011 11:12:17 +0800 Bob Liu lliu...@gmail.com wrote: It seems that the code in sound/soc/omap/omap-mcbsp.c uses the function cpu-is-omap343x() which fails and returns ENODEV. But I have enabled OMAP3430 support in System Type / TI OMAP2/3/4 Specific Features, why it still return ENODEV? (Attached my kernel config). And after I changed that check to cpu-is-omap34xx(), there was no error message but neither any audio output, I can't hear any sound. Is the DMA running after you change the cpu_is_omap34xx and try to play e.g. aplay /dev/urandom? If audio is running you should see DMA interrupt count increasing with grep DMA /proc/interrupts. Yes, DMA interrupt count increased after aplay /dev/urandom or some other audio file. Thanks If that is working then issue could be in codec side. I don't have a beagle at the moment to verify but IRCC something like ~10 TWL4030 ALSA controls must be adjusted in order to route audio from DAC to outputs at proper volume. I don't have HW with me right now, can you try the following? (Got the steps over phone from Abhilash) 1) run command alsamixer 2) Un-mute by pressing the key m 3) Play the audio using aplay If it doesn't work, you may want to check the options used by alsamixer. I will be able to try it myself tomorrow morning. Thanks for your reply. It seems pressing the key m has no effect during alsamixer and there are so many options I don't know how to adjust it. I haven't yet come to running this test myself. m (or as the wiki here mentions M) is meant to toggle mute. See : http://alsa.opensrc.org/Alsamixer for more details on alsamixer. ~sanjeev -- Regards, --Bob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [HELP] Audio on BeagleBoard xM can't work
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bob Liu Sent: Tuesday, March 15, 2011 3:27 PM To: Jarkko Nikula Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk; l...@metafoo.de; p...@pwsan.com; peter.ujfal...@nokia.com Subject: Re: [HELP] Audio on BeagleBoard xM can't work On Tue, Mar 15, 2011 at 5:53 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Tue, 15 Mar 2011 11:12:17 +0800 Bob Liu lliu...@gmail.com wrote: It seems that the code in sound/soc/omap/omap-mcbsp.c uses the function cpu-is-omap343x() which fails and returns ENODEV. But I have enabled OMAP3430 support in System Type / TI OMAP2/3/4 Specific Features, why it still return ENODEV? (Attached my kernel config). And after I changed that check to cpu-is-omap34xx(), there was no error message but neither any audio output, I can't hear any sound. Is the DMA running after you change the cpu_is_omap34xx and try to play e.g. aplay /dev/urandom? If audio is running you should see DMA interrupt count increasing with grep DMA /proc/interrupts. Yes, DMA interrupt count increased after aplay /dev/urandom or some other audio file. Thanks If that is working then issue could be in codec side. I don't have a beagle at the moment to verify but IRCC something like ~10 TWL4030 ALSA controls must be adjusted in order to route audio from DAC to outputs at proper volume. I don't have HW with me right now, can you try the following? (Got the steps over phone from Abhilash) 1) run command alsamixer 2) Un-mute by pressing the key m 3) Play the audio using aplay If it doesn't work, you may want to check the options used by alsamixer. I will be able to try it myself tomorrow morning. ~sanjeev -- Regards, --Bob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type
-Original Message- From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Monday, March 14, 2011 7:31 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type On Mon, 14 Mar 2011 15:55:42 +0200 Jarkko Nikula jhnik...@gmail.com wrote: On Mon, 14 Mar 2011 19:01:53 +0530 Sanjeev Premi pr...@ti.com wrote: Current check for cpu type is too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com --- sound/soc/omap/omap-mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) There are two other cpu_is_omap343x tests as well. Care to check them too? Sorry, only one additional test. I forgot the commit 2686e07 ASoC: McBSP: get hw params from McBSP driver that is coming via linux-omap and which removes one test. Checking now... ~sanjeev -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Monday, March 14, 2011 7:47 PM To: Jarkko Nikula Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type -Original Message- From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Monday, March 14, 2011 7:31 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH] omap3: alsa-soc: Remove restrictive check for cpu type On Mon, 14 Mar 2011 15:55:42 +0200 Jarkko Nikula jhnik...@gmail.com wrote: On Mon, 14 Mar 2011 19:01:53 +0530 Sanjeev Premi pr...@ti.com wrote: Current check for cpu type is too restrictive leading to failures for other silicons in same family. The problem was found while testing audio playback on AM37x and AM35x processors. But should exist on OMAP36xx as well. Signed-off-by: Sanjeev Premi pr...@ti.com --- sound/soc/omap/omap-mcbsp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) There are two other cpu_is_omap343x tests as well. Care to check them too? Sorry, only one additional test. I forgot the commit 2686e07 ASoC: McBSP: get hw params from McBSP driver that is coming via linux-omap and which removes one test. Checking now... Other check shouldn't be there are well... Had asked someone (off-this -list) to help me test the change - but seems to be in todo. Will test it myself and post updated patch today... ~sanjeev -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 4/9] OMAP4 : DSS2 : HDMI: HDMI driver header file addition
-Original Message- From: K, Mythri P Sent: Thursday, March 10, 2011 10:32 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi Subject: Re: [PATCH v4 4/9] OMAP4 : DSS2 : HDMI: HDMI driver header file addition [snip]...[snip] [sp] Any specific reason to keep header file in separate patch? When i had posted it earlier there were several compliants that the patch is huge, if i include header file with the corresponding c file , and hence difficult to review. So it just to make reviewers job easy. [sp] Final say on the issue rests with the maintainer. But it I found it difficult to review the .c file with when looking for structure definitions, members etc. If they were together, we wouldn't need this in a separate patch: [PATCH v4 7/9] OMAP4 : DSS : HDMI: Call to HDMI module init to... ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/9] OMAP4 : DSS2 : HDMI: HDMI dispc gamma table disable.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH v4 3/9] OMAP4 : DSS2 : HDMI: HDMI dispc gamma table
disable.
[sp] HDMI seems repetitive in the subject in this and some of the subsequent
Patches.
Adding changes to set gamma table bit for TV interface to make sure it is
disabled
[sp] Is this bit expected to be enabled by default? If no, how can/would
this bit get enabled.
The subject and description of the patch doesn't match the contents.
The patch is adding a function that can *both* enable/disable gamma
table - not just disable.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dispc.c | 10 ++
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index 4a368c4..0defe16 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1008,6 +1008,16 @@ void dispc_set_burst_size(enum omap_plane plane,
enable_clocks(0);
}
+void dispc_enable_gamma_table(bool enable)
+{
+ /* This is partially implemented to support only
+ * disabling of the gamma table.
+ */
+ BUG_ON(enable);
[sp] Is BUG_ON really needed. Can't this be a WARN or equiv?
+
+ REG_FLD_MOD(DISPC_CONFIG, enable, 9, 9);
[sp] I don't understand HDMI much, but if enabling gamma causes BUG_ON,
then why would we need implementation to disable it.
Instead, shouldn't the function be empty - if it can't be avoided
altogether?
+}
+
static void _dispc_set_vid_color_conv(enum omap_plane plane, bool enable)
{
u32 val;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 29f31fd..008cbf4 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -363,6 +363,7 @@ void dispc_set_plane_size(enum omap_plane plane, u16
width, u16 height);
void dispc_set_channel_out(enum omap_plane plane,
enum omap_channel channel_out);
+void dispc_enable_gamma_table(bool enable);
[sp] Is this patch really standalone? I suggest merging it with the patch
where the API is actually used.
In effect, nothing gets disabled in this patch.
int dispc_setup_plane(enum omap_plane plane,
u32 paddr, u16 screen_width,
u16 pos_x, u16 pos_y,
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 5/9] OMAP4 : DSS2 : HDMI: HDMI driver addition in the DSS
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of K, Mythri P
Sent: Wednesday, March 09, 2011 5:15 PM
To: linux-omap@vger.kernel.org; Valkeinen, Tomi
Cc: K, Mythri P
Subject: [PATCH v4 5/9] OMAP4 : DSS2 : HDMI: HDMI driver addition in the
DSS
Adding the hdmi interface driver(hdmi.c) to the dss driver.
It configures the audio and video portion of HDMI based on
functionality called by the panel driver.
Signed-off-by: Mythri P K mythr...@ti.com
Yong Zhi y-...@ti.com
---
drivers/video/omap2/dss/Kconfig |8 +
drivers/video/omap2/dss/Makefile |1 +
drivers/video/omap2/dss/display.c |3 +
drivers/video/omap2/dss/dss.h | 43 ++
drivers/video/omap2/dss/hdmi.c| 1315
+
5 files changed, 1370 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi.c
diff --git a/drivers/video/omap2/dss/Kconfig
b/drivers/video/omap2/dss/Kconfig
index db01473..7749ddb 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -60,6 +60,14 @@ config OMAP2_DSS_VENC
help
OMAP Video Encoder support for S-Video and composite TV-out.
+config OMAP2_DSS_HDMI
+ bool HDMI support
+ depends on ARCH_OMAP4
+default y
+ help
+ HDMI Interface. This adds the High Definition Multimedia
Interface.
+ See http://www.hdmi.org/ for HDMI specification.
+
[sp] This may have been discussed earlier... but if the interface is
supported only on OMAP4, wouldn't it be better to rename
OMAP2_DSS_HDMI as OMAP4_DSS_HDMI?
Or, the implementation can be used by OMAP3 as well. If so, you
may want to update the depends.
config OMAP2_DSS_SDI
bool SDI support
depends on ARCH_OMAP3
diff --git a/drivers/video/omap2/dss/Makefile
b/drivers/video/omap2/dss/Makefile
index 7db17b5..5998b69 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -5,3 +5,4 @@ omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
+omapdss-$(CONFIG_OMAP2_DSS_HDMI) += hdmi.o
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index c40bcbd..a85a6f3 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -418,6 +418,9 @@ void dss_init_device(struct platform_device *pdev,
r = dsi_init_display(dssdev);
break;
#endif
+ case OMAP_DISPLAY_TYPE_HDMI:
+ r = hdmi_init_display(dssdev);
+ break;
default:
DSSERR(Support for display '%s' not compiled in.\n,
dssdev-name);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 008cbf4..3eb2661 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -174,6 +174,16 @@ struct dsi_clock_info {
bool use_sys_clk;
};
+/* HDMI PLL structure */
+struct hdmi_pll_info {
+ u16 regn;
+ u16 regm;
+ u32 regmf;
+ u16 regm2;
+ u16 regsd;
+ u16 dcofreq;
+};
+
struct seq_file;
struct platform_device;
@@ -437,6 +447,39 @@ static inline void venc_uninit_platform_driver(void)
}
#endif
+/* HDMI */
+#ifdef CONFIG_OMAP2_DSS_HDMI
+int hdmi_init_platform_driver(void);
+void hdmi_uninit_platform_driver(void);
+int hdmi_init_display(struct omap_dss_device *dssdev);
+#else
+static inline int hdmi_init_display(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+static inline int hdmi_init_platform_driver(void)
+{
+ return 0;
+}
+static inline void hdmi_uninit_platform_driver(void)
+{
+}
+#endif
+int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev);
+void omapdss_hdmi_display_disable(struct omap_dss_device *dssdev);
+#ifdef CONFIG_OMAP4_PANEL_HDMI
+int hdmi_panel_init(void);
+void hdmi_panel_exit(void);
+#else
+static inline int hdmi_panel_init(void)
+{
+ return 0;
+}
+static inline void hdmi_panel_exit(void)
+{
+}
+#endif
+
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
int rfbi_init_platform_driver(void);
diff --git a/drivers/video/omap2/dss/hdmi.c
b/drivers/video/omap2/dss/hdmi.c
new file mode 100644
index 000..6852843
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -0,0 +1,1315 @@
+/*
+ * hdmi.c
+ *
+ * HDMI interface DSS driver setting for TI's OMAP4 family of processor.
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated -
http://www.ti.com/
+ * Authors: Yong Zhi
+ * Mythri pk mythr...@ti.com
+ *
+ *
[sp] Extra blank lines here
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License version 2 as
published by
+ * the Free Software Foundation.
+ *
+ * This
RE: [PATCH v4 7/9] OMAP4 : DSS : HDMI: Call to HDMI module init to register driver.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of K, Mythri P Sent: Wednesday, March 09, 2011 5:15 PM To: linux-omap@vger.kernel.org; Valkeinen, Tomi Cc: K, Mythri P Subject: [PATCH v4 7/9] OMAP4 : DSS : HDMI: Call to HDMI module init to register driver. calling the platform registration of HDMI driver from core during initialization. [sp] Contrary to the subject, patch adds calls for both init and uninit functions. Shouldn't this be included in same patch where init and uninit are being defined? [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 4/9] OMAP4 : DSS2 : HDMI: HDMI driver header file addition
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of K, Mythri P Sent: Wednesday, March 09, 2011 5:15 PM To: linux-omap@vger.kernel.org; Valkeinen, Tomi Cc: K, Mythri P Subject: [PATCH v4 4/9] OMAP4 : DSS2 : HDMI: HDMI driver header file addition Adding the hdmi interface driver header file (hdmi.h) to the dss driver. Register and structure declaration done here. [sp] Any specific reason to keep header file in separate patch? [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
