Re: [PATCH v7 16/21] OMAP2+: UART: Remove custom activate funcs and use generic funcs.
On Sat, Nov 5, 2011 at 3:30 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
The custom hwmod activate and deactivate funcs does hwmod_enable
and idle same can be done with omap_device generic API's.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
This one needs a minor update for current mainline...
---
arch/arm/mach-omap2/serial.c | 18 ++
1 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 7c65410..7658a03 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -78,24 +78,10 @@ static struct omap_uart_port_info
omap_serial_default_info[] __initdata = {
},
};
-static int uart_idle_hwmod(struct omap_device *od)
-{
- omap_hwmod_idle(od-hwmods[0]);
-
- return 0;
-}
-
-static int uart_enable_hwmod(struct omap_device *od)
-{
- omap_hwmod_enable(od-hwmods[0]);
-
- return 0;
-}
-
static struct omap_device_pm_latency omap_uart_latency[] = {
{
- .deactivate_func = uart_idle_hwmod,
- .activate_func = uart_enable_hwmod,
+ .activate_func = omap_device_enable_hwmods,
+ .deactivate_func = omap_device_idle_hwmods,
.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
If we're just using default pm_latency struct, it can be passed to
omap_device_build as NULL, and a default one will be configured.
yes, will update this.
--
Thanks,
Govindraj.R
--
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 v7 19/21] OMAP2+: UART: Use custom activate func for console uart.
On Sat, Nov 5, 2011 at 4:30 AM, Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Omap-uart can be used as console uart to print early boot
messages using earlyprintk so for console uart prevent
hwmod reset or idling during bootup.
Identify the console_uart set the id and use the custom
pm_latency ops for console uart for the first time
to idle console uart left enabled from bootup and then enable
them back and reset pm_latency ops to default ops.
Thanks to Kevin Hilman khil...@ti.com for suggesting
this approach.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 79
-
1 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e1eba7f..55903f0 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -63,6 +63,7 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
+static u8 console_uart_id = -1;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate
(us) */
#define DEFAULT_RXDMA_BUFSIZE 4096 /* RX DMA buffer size
*/
@@ -87,6 +88,29 @@ static struct omap_device_pm_latency omap_uart_latency[]
= {
},
};
+static int console_uart_enable_hwmod(struct omap_device *od)
+{
+ /* For early console we prevented hwmod reset and idle
+ * So before we enable the uart clocks idle and then
+ */
minor: fix multi-line comment style (search for multi-line in
Documentation/CodingStyle). Another one below.
will correct this.
Notice that you're moving existing code here, but also changing the
functionality without a description as to why. Based on the existing code:
You need a console_lock() here...
+ omap_hwmod_idle(od-hwmods[0]);
+ omap_hwmod_enable(od-hwmods[0]);
...and this should be omap_device_enable().
And you need a console_unlock() here.
Yes, you're subsequent patches avoid this problem, but we still need a real
fix other than checking for 'debug/loglevel', and when that happens,
we'll need a console lock here.
yes correct, we need console_lock/unlock binding here will update this.
--
Thanks,
Govindraj.R
--
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] cbus-tahvo: Add tahvo_write_reg locking
On Mon, 7 Nov 2011 08:10:45 +0200
Felipe Balbi ba...@ti.com wrote:
Hi,
On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
tahvo_write_reg() needs to take the mutex to avoid a race
condition with tahvo_set_clear_reg_bits:
tahvo_set_clear_reg_bits(): | tahvo_write_reg():
__tahvo_read_reg()|
| __tahvo_write_reg() -- race here
__tahvo_write_reg() |
Signed-off-by: Michael Buesch m...@bues.ch
---
Index: linux-3.1/drivers/cbus/tahvo.c
===
--- linux-3.1.orig/drivers/cbus/tahvo.c 2011-11-05 17:03:39.598846119
+0100
+++ linux-3.1/drivers/cbus/tahvo.c 2011-11-05 17:04:36.274768324 +0100
@@ -104,7 +104,9 @@ void tahvo_write_reg(struct device *chil
{
struct tahvo*tahvo = dev_get_drvdata(child-parent);
+ mutex_lock(tahvo-mutex);
__tahvo_write_reg(tahvo, reg, val);
+ mutex_unlock(tahvo-mutex);
yeah, my bad. The same should be done with tahvo_read_reg(). Care to
resend this patch adding the change to tahvo_read_reg() too...
I think tahvo_read_reg is fine without a lock.
read vs write is already atomic due to the cbus lock.
it's the same situation as for retu. where we also don't need the lock in
retu_read_reg.
--
Greetings, Michael.
--
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] cbus-tahvo: Add tahvo_write_reg locking
Hi,
On Mon, Nov 07, 2011 at 09:18:36AM +, Michael Büsch wrote:
On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
tahvo_write_reg() needs to take the mutex to avoid a race
condition with tahvo_set_clear_reg_bits:
tahvo_set_clear_reg_bits(): | tahvo_write_reg():
__tahvo_read_reg()|
| __tahvo_write_reg() -- race here
__tahvo_write_reg() |
Signed-off-by: Michael Buesch m...@bues.ch
---
Index: linux-3.1/drivers/cbus/tahvo.c
===
--- linux-3.1.orig/drivers/cbus/tahvo.c 2011-11-05 17:03:39.598846119
+0100
+++ linux-3.1/drivers/cbus/tahvo.c2011-11-05 17:04:36.274768324
+0100
@@ -104,7 +104,9 @@ void tahvo_write_reg(struct device *chil
{
struct tahvo*tahvo = dev_get_drvdata(child-parent);
+ mutex_lock(tahvo-mutex);
__tahvo_write_reg(tahvo, reg, val);
+ mutex_unlock(tahvo-mutex);
yeah, my bad. The same should be done with tahvo_read_reg(). Care to
resend this patch adding the change to tahvo_read_reg() too...
I think tahvo_read_reg is fine without a lock.
read vs write is already atomic due to the cbus lock.
it's the same situation as for retu. where we also don't need the lock
in retu_read_reg.
ok then, makes sense.
FWIW:
Acked-by: Felipe Balbi ba...@ti.com
--
balbi
signature.asc
Description: Digital signature
[PATCH v2 0/2] OMAP2+: DMA: fix src/dst position reporting
Hello, Changes since v1: - Move the check after the ERRATA_3_3 re-read test If the user asks for the sDMA current position before the first data has been transmitted (before the first DMA request has been generated), the reported position is not valid: src position: CSAC is uninitialized dst position: CDAC is 0 The return values in both case considered invalid. This sitation can be identified by checking if the CDAC register is 0 (it is initialized to 0 in omap_dam_start call). In this case return the programmed source/destination address. The affected omap_get_dma_src_pos/omap_get_dma_dst_pos functions are used by the audio stack mainly for checking the current position of the audio stream. Regards, Peter --- Peter Ujfalusi (2): OMAP2+: DMA: Workaround for invalid source position OMAP2+: DMA: Workaround for invalid destination position arch/arm/plat-omap/dma.c | 22 +- 1 files changed, 21 insertions(+), 1 deletions(-) -- 1.7.7.2 -- 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
[PATCH v2 1/2] OMAP2+: DMA: Workaround for invalid source position
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..a9983b6 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1034,6 +1034,18 @@ dma_addr_t omap_get_dma_src_pos(int lch)
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = p-dma_read(CSAC, lch);
+ if (!cpu_is_omap15xx()) {
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed source start address in this case.
+*/
+ if (likely(p-dma_read(CDAC, lch)))
+ offset = p-dma_read(CSAC, lch);
+ else
+ offset = p-dma_read(CSSA, lch);
+ }
+
if (cpu_class_is_omap1())
offset |= (p-dma_read(CSSA, lch) 0x);
--
1.7.7.2
--
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
[PATCH v2 2/2] OMAP2+: DMA: Workaround for invalid destination position
If the DMA destination position has been asked before the
first actual data transfer has been done, the CDAC
register still contains 0 (it is initialized to 0 at
omsp_dma_start).
If CDAC == 0, return the programmed start address.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index a9983b6..002fb4d 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1074,8 +1074,16 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
* read before the DMA controller finished disabling the channel.
*/
- if (!cpu_is_omap15xx() offset == 0)
+ if (!cpu_is_omap15xx() offset == 0) {
offset = p-dma_read(CDAC, lch);
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed destination start address in this case.
+*/
+ if (unlikely(!offset))
+ offset = p-dma_read(CDSA, lch);
+ }
if (cpu_class_is_omap1())
offset |= (p-dma_read(CDSA, lch) 0x);
--
1.7.7.2
--
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 ISP DMA status
Hi ALL, I meet a problem when developing scan device (such as a camera) driver on OMAP3 platform (my MPU is AM3715). The scan application may change the scan hardware settings (such as exposure time), and try to find out the best one. But sometimes, after applied the new settings, the scan hardware may did not output data, so the application blocked. Since i can't modify the application, the driver should notify this event to app. So my question is that, can the driver query the ISP DMA status such as how many bytes the DMA has transferred? BRs, Lei.Bian -- 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
[PATCH] ARM: omap4: prm: Fix up swapped offset macros
The offset macros for OMAP4_RM_RSTST and OMAP4_RM_RSTTIME are wrongly swapped up. Thanks to Gina Glaser for identifying and reporting this. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Gina Glaser g-gla...@ti.com --- arch/arm/mach-omap2/prm44xx.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 3d66ccd..aa8593e 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -62,8 +62,8 @@ /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST0x0004 -- 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
Re: [PATCH v8 16/24] gpio/omap: use pm-runtime framework
On Fri, Nov 4, 2011 at 10:43 PM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync() for enabling/disabling clocks appropriately. Remove syscore_ops and instead use SET_RUNTIME_PM_OPS macro. Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/gpio.c | 2 - drivers/gpio/gpio-omap.c | 67 +--- 2 files changed, 44 insertions(+), 25 deletions(-) diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c index 5ae1cf3..a992802 100644 --- a/arch/arm/mach-omap2/gpio.c +++ b/arch/arm/mach-omap2/gpio.c @@ -146,8 +146,6 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused) return PTR_ERR(od); } - omap_device_disable_idle_on_suspend(od); - No description in the changelog about this change. (Yes, I understand why it's removed, but it needs to be described in the changelog so when I forget, I'll have a way to remember.) Yes, I will put a description explaining that this is not needed after driver is runtime adapted. -- Tarun 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 v8 REPOST 21/24] gpio/omap: save and restore debounce registers
On Fri, Nov 4, 2011 at 10:27 PM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: From: Nishanth Menon n...@ti.com GPIO debounce registers need to be saved and restored for proper functioning of driver. OK. To save the registers, we cannot cut the clock before the save, hence move the clk disable after the save. This patch doesn't move any clk disable. I suspect you made some changes to the original patch from Nishanth. Please note that in the changelog. This is typically done by adding something like: [m...@email.addr: describe changes made] just before your signoff. Yes, quite a bit of changes happened which not captured in the description. The save context has been moved from *_runtime_suspend() to _set_gpio_debounce() as part of your comment in v6 to reduce overhead. Also, the clock disable is moved to *_prepare_for_idle(). I will add changelog to capture above changes. -- Tarun 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 v8 24/24] gpio/omap: handle set_dataout reg capable IP on restore
On Fri, Nov 4, 2011 at 10:23 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on what is available restore the dataout settings
to the right register.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4009446..3df7a98 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1073,7 +1073,7 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
bank-get_context_loss_count = pdata-get_context_loss_count;
bank-regs = pdata-regs;
- if (bank-regs-set_dataout bank-regs-clr_dataout)
+ if (bank-regs-set_dataout)
This change isn't right.
The _set_gpio_dataout_reg function depends on the existence of
-clr_dataout too.
Ok, I will add the clr_dataout condtion as well.
bank-set_dataout = _set_gpio_dataout_reg;
else
bank-set_dataout = _set_gpio_dataout_mask;
@@ -1351,7 +1351,12 @@ static void omap_gpio_restore_context(struct
gpio_bank *bank)
bank-base + bank-regs-risingdetect);
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
- __raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+ if (bank-regs-set_dataout)
Why the check again? The check has already been done in probe.
Just use bank-set_dataout() here.
Sure, i will make the change.
--
Tarun
Kevin
+ __raw_writel(bank-context.dataout,
+ bank-base + bank-regs-set_dataout);
+ else
+ __raw_writel(bank-context.dataout,
+ bank-base + bank-regs-dataout);
__raw_writel(bank-context.oe, bank-base + bank-regs-direction);
if (bank-dbck_enable_mask) {
--
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
[PATCH] OMAP2+: Fix Compilation break on current mainline
I see below errors and warnings on latest mainline commit b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig. Patch to fix the same. arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:184: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:184: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:215: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:215: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:215: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:228: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:228: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:228: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:234: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:234: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:234: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:240: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:240: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:240: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:248: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:248: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:248: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:294: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:294: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:294: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:302: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:302: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:302: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:316: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:316: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:316: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:344: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:344: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:344: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:361: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:361: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:361: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:380: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:380: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:380: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:406: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:406: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:406: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:443: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:443: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:443: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:468: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:468: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:468: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:494: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:494: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:494: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:517: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:517: warning: type
[PATCH] BUILD FIX:hwspinlock: do not return any value from void funtion
Fixes below compilation error -
CC arch/arm/mach-omap2/hwspinlock.o
cc1: warnings being treated as errors
In file included from arch/arm/mach-omap2/hwspinlock.c:22:0:
include/linux/hwspinlock.h: In function '__hwspin_unlock':
include/linux/hwspinlock.h:121:2: error: 'return' with a value, in function
returning void
make[1]: *** [arch/arm/mach-omap2/hwspinlock.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
include/linux/hwspinlock.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 08a2fee..192710a 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -118,7 +118,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
static inline
void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
{
- return 0;
+ return;
}
static inline int hwspin_lock_get_id(struct hwspinlock *hwlock)
--
1.7.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
Re: [PATCH] OMAP2+: Fix Compilation break on current mainline
On Mon, Nov 7, 2011 at 6:08 PM, Govindraj.R govindraj.r...@ti.com wrote: I see below errors and warnings on latest mainline commit b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig. Patch to fix the same. Patches are already posted and applied by Tony on linux-omap master. http://www.spinics.net/lists/linux-omap/msg59848.html http://www.spinics.net/lists/linux-omap/msg59847.html 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] BUILD FIX:hwspinlock: do not return any value from void funtion
Hi Vaibhav,
On 11/07/11 14:58, Vaibhav Hiremath wrote:
Fixes below compilation error -
CC arch/arm/mach-omap2/hwspinlock.o
cc1: warnings being treated as errors
In file included from arch/arm/mach-omap2/hwspinlock.c:22:0:
include/linux/hwspinlock.h: In function '__hwspin_unlock':
include/linux/hwspinlock.h:121:2: error: 'return' with a value, in function
returning void
make[1]: *** [arch/arm/mach-omap2/hwspinlock.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
include/linux/hwspinlock.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 08a2fee..192710a 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -118,7 +118,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
static inline
void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
{
- return 0;
+ return;
Isn't it better to just remove this line?
}
static inline int hwspin_lock_get_id(struct hwspinlock *hwlock)
--
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] ARM: omap4: prm: Fix up swapped offset macros
Hi Rajendra, On 11/7/2011 11:06 AM, Rajendra Nayak wrote: The offset macros for OMAP4_RM_RSTST and OMAP4_RM_RSTTIME are wrongly swapped up. Thanks to Gina Glaser for identifying and reporting this. Signed-off-by: Rajendra Nayakrna...@ti.com Cc: Gina Glaserg-gla...@ti.com --- arch/arm/mach-omap2/prm44xx.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 3d66ccd..aa8593e 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -62,8 +62,8 @@ /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST 0x0004 In fact these defines were already defined correctly later (with a slightly different name): /* PRM.DEVICE_PRM register offsets */ [...] #define OMAP4_PRM_RSTST_OFFSET 0x0004 #define OMAP4430_PRM_RSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x0004) #define OMAP4_PRM_RSTTIME_OFFSET0x0008 #define OMAP4430_PRM_RSTTIME OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x0008) I don't know where these defines are used, but we'd better use the existing ones. 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] BUILD FIX:hwspinlock: do not return any value from void funtion
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Monday, November 07, 2011 6:37 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org; t...@atomide.com; o...@wizery.com
Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from
void funtion
Hi Vaibhav,
On 11/07/11 14:58, Vaibhav Hiremath wrote:
Fixes below compilation error -
CC arch/arm/mach-omap2/hwspinlock.o
cc1: warnings being treated as errors
In file included from arch/arm/mach-omap2/hwspinlock.c:22:0:
include/linux/hwspinlock.h: In function '__hwspin_unlock':
include/linux/hwspinlock.h:121:2: error: 'return' with a value, in
function
returning void
make[1]: *** [arch/arm/mach-omap2/hwspinlock.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
include/linux/hwspinlock.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 08a2fee..192710a 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -118,7 +118,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int
mode, unsigned long *flags)
static inline
void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long
*flags)
{
- return 0;
+ return;
Isn't it better to just remove this line?
[Hiremath, Vaibhav] Yeup, we can do that... Submitting it again.
Thanks,
Vaibhav
}
static inline int hwspin_lock_get_id(struct hwspinlock *hwlock)
--
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 v8 REPOST 17/24] gpio/omap: fix debounce clock handling
On Fri, Nov 4, 2011 at 10:10 PM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
Currently debounce clock state is not tracked in the system.
??
bank-dbck_enable_mask ?
As I understand, this only tells which all GPIOs have debounce timeout enabled.
But, during system operation as debounce clocks are enabled and disabled I need
additional flag to keep track of current state (enabled/disabled).
This is what I meant.
The bank-dbck
is enabled/disabled in suspend/idle paths irrespective of whether debounce
interval has been set or not.
No. It's conditional based on bank-dbck_enable_mask, which is based on
whether or not debounce has been enabled.
You are right. I need to rephrase my description.
Ideally, it should be handled only for those
gpio banks where the debounce is enabled.
AFAICT, it is. Please explain more what is actually happening in the
patch, and why.
Yes, as I explained above, it is more about the tracking the debounce clock
enabled/disabled state for those GPIOs whose debounce timeouts are enabled.
I will modify the patch description.
In _set_gpio_debounce, enable debounce clock before accessing
registers.
This is a separate issue/bug and wants its own patch with descriptive
changelog.
OK.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
During further internal testing it was found that image was crashing within
_set_gpio_debounce(). It is observed that we are trying to access registers
without enabling debounce clock. This patch incorporates the change whereby
the debounce clock is enabled before accessing registers and disabled at the
end of the function.
drivers/gpio/gpio-omap.c | 60
-
1 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index fa6c9c5..85e9c2a 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -65,6 +65,7 @@ struct gpio_bank {
struct clk *dbck;
u32 mod_usage;
u32 dbck_enable_mask;
+ bool dbck_enabled;
struct device *dev;
bool is_mpuio;
bool dbck_flag;
@@ -156,6 +157,22 @@ static inline void _gpio_rmw(void __iomem *base, u32
reg, u32 mask, bool set)
__raw_writel(l, base + reg);
}
+static inline void _gpio_dbck_enable(struct gpio_bank *bank)
+{
+ if (bank-dbck_enable_mask !bank-dbck_enabled) {
+ clk_enable(bank-dbck);
+ bank-dbck_enabled = true;
+ }
+}
+
+static inline void _gpio_dbck_disable(struct gpio_bank *bank)
+{
+ if (bank-dbck_enable_mask bank-dbck_enabled) {
+ clk_disable(bank-dbck);
+ bank-dbck_enabled = false;
+ }
+}
+
/**
* _set_gpio_debounce - low level gpio debounce time
* @bank: the gpio bank we're acting upon
@@ -184,22 +201,22 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
+ clk_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
__raw_writel(debounce, reg);
reg = bank-base + bank-regs-debounce_en;
val = __raw_readl(reg);
- if (debounce) {
+ if (debounce)
val |= l;
- clk_enable(bank-dbck);
- } else {
+ else
val = ~l;
- clk_disable(bank-dbck);
- }
+
bank-dbck_enable_mask = val;
__raw_writel(val, reg);
+ clk_disable(bank-dbck);
}
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
@@ -485,8 +502,10 @@ static int omap_gpio_request(struct gpio_chip *chip,
unsigned offset)
* If this is the first gpio_request for the bank,
* enable the bank module.
*/
- if (!bank-mod_usage)
+ if (!bank-mod_usage) {
+ _gpio_dbck_enable(bank);
pm_runtime_get_sync(bank-dev);
+ }
spin_lock_irqsave(bank-lock, flags);
/* Set trigger to none. You need to enable the desired trigger with
@@ -549,8 +568,10 @@ static void omap_gpio_free(struct gpio_chip *chip,
unsigned offset)
* If this is the last gpio to be freed in the bank,
* disable the bank module.
*/
- if (!bank-mod_usage)
+ if (!bank-mod_usage) {
pm_runtime_put_sync(bank-dev);
+ _gpio_dbck_disable(bank);
Why not add this to the -runtime_suspend() callback?
Yes, I can move there and test.
+ }
}
/*
@@ -829,8 +850,10 @@ static int gpio_debounce(struct gpio_chip *chip,
unsigned offset,
if (!bank-dbck) {
bank-dbck = clk_get(bank-dev, dbclk);
- if (IS_ERR(bank-dbck))
+ if (IS_ERR(bank-dbck)) {
dev_err(bank-dev, Could not get gpio dbck\n);
+ return -EINVAL;
+ }
}
spin_lock_irqsave(bank-lock, flags);
@@ -1086,6 +1109,8 @@ static int omap_gpio_suspend(struct device
Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from void funtion
On Mon, Nov 7, 2011 at 2:58 PM, Vaibhav Hiremath hvaib...@ti.com wrote: Fixes below compilation error - Thanks. We already have this fix queued up though (reported by Axel awhile ago). -- 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] BUILD FIX:hwspinlock: do not return any value from void funtion
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Monday, November 07, 2011 7:25 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from void funtion On Mon, Nov 7, 2011 at 2:58 PM, Vaibhav Hiremath hvaib...@ti.com wrote: Fixes below compilation error - Thanks. We already have this fix queued up though (reported by Axel awhile ago). [Hiremath, Vaibhav] I did try to search before fixing this...but I did not find any patch for this. Can you point me to it? If it is already queued up, no point in submitting it again. Thanks, Vaibhav -- 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] BUILD FIX:hwspinlock: do not return any value from void funtion
On Mon, Nov 7, 2011 at 3:58 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: [Hiremath, Vaibhav] I did try to search before fixing this...but I did not find any patch for this. Can you point me to it? http://comments.gmane.org/gmane.linux.kernel/1210678 -- 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+: Fix Compilation break on current mainline
On 11/7/2011 1:59 PM, Shilimkar, Santosh wrote: On Mon, Nov 7, 2011 at 6:08 PM, Govindraj.Rgovindraj.r...@ti.com wrote: I see below errors and warnings on latest mainline commit b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig. Patch to fix the same. Patches are already posted and applied by Tony on linux-omap master. Except the missing semicolon... This is a similar issue that Ohad reported for hwspinlock. It will build fine until you will try to build the omap_l3_noc as a module. Govind, You can maybe repost a fix for that one only. Regards, 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] BUILD FIX:hwspinlock: do not return any value from void funtion
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Monday, November 07, 2011 7:25 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; t...@atomide.com Subject: Re: [PATCH] BUILD FIX:hwspinlock: do not return any value from void funtion On Mon, Nov 7, 2011 at 2:58 PM, Vaibhav Hiremath hvaib...@ti.com wrote: Fixes below compilation error - Thanks. We already have this fix queued up though (reported by Axel awhile ago). Found it... http://comments.gmane.org/gmane.linux.kernel/1210678 Thanks, Vaibhav -- 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
[RFC PATCH] arm:omap: cleanup split omap2/3/4_check_revision function
This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for ID and feature detection; makes
easier to add new SoC (especially for AM devices where we do not have
feature register).
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/id.c | 48 +---
arch/arm/mach-omap2/io.c |6 +++-
arch/arm/plat-omap/include/plat/cpu.h |4 ++-
3 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 7f47092..f1784ee 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -226,9 +226,9 @@ static void __init omap4_check_features(void)
}
}
-static void __init ti816x_check_features(void)
+static void __init omap3_add_def_features(void)
{
- omap_features = OMAP3_HAS_NEON;
+ omap_features = OMAP3_HAS_NEON | OMAP3_HAS_L2CACHE;
}
static void __init omap3_check_revision(const char **cpu_rev)
@@ -456,37 +456,29 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
printk()\n);
}
-/*
- * Try to detect the exact revision of the omap we're running on
- */
-void __init omap2_check_revision(void)
+void __init omap2xxx_check_revision(void)
+{
+ omap24xx_check_revision();
+}
+
+void __init omap3xxx_check_revision(bool has_feature_reg)
{
const char *cpu_rev;
- /*
-* At this point we have an idea about the processor revision set
-* earlier with omap2_set_globals_tap().
-*/
- if (cpu_is_omap24xx()) {
- omap24xx_check_revision();
- } else if (cpu_is_omap34xx()) {
- omap3_check_revision(cpu_rev);
+ omap3_check_revision(cpu_rev);
- /* TI816X doesn't have feature register */
- if (!cpu_is_ti816x())
- omap3_check_features();
- else
- ti816x_check_features();
+ if (has_feature_reg)
+ omap3_check_features();
+ else
+ omap3_add_def_features();
- omap3_cpuinfo(cpu_rev);
- return;
- } else if (cpu_is_omap44xx()) {
- omap4_check_revision();
- omap4_check_features();
- return;
- } else {
- pr_err(OMAP revision unknown, please fix!\n);
- }
+ omap3_cpuinfo(cpu_rev);
+}
+
+void __init omap4xxx_check_revision(void)
+{
+ omap4_check_revision();
+ omap4_check_features();
}
/*
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 25d20ce..da9bc4a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -321,7 +321,6 @@ void __iomem *omap_irq_base;
static void __init omap_common_init_early(void)
{
- omap2_check_revision();
omap_ioremap_init();
omap_init_consistent_dma_size();
}
@@ -363,6 +362,7 @@ static void __init omap_hwmod_init_postsetup(void)
void __init omap2420_init_early(void)
{
omap2_set_globals_242x();
+ omap2xxx_check_revision();
omap_common_init_early();
omap2xxx_voltagedomains_init();
omap242x_powerdomains_init();
@@ -375,6 +375,7 @@ void __init omap2420_init_early(void)
void __init omap2430_init_early(void)
{
omap2_set_globals_243x();
+ omap2xxx_check_revision();
omap_common_init_early();
omap2xxx_voltagedomains_init();
omap243x_powerdomains_init();
@@ -393,6 +394,7 @@ void __init omap2430_init_early(void)
void __init omap3_init_early(void)
{
omap2_set_globals_3xxx();
+ omap3xxx_check_revision(true);
omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
@@ -425,6 +427,7 @@ void __init am35xx_init_early(void)
void __init ti816x_init_early(void)
{
omap2_set_globals_ti816x();
+ omap3xxx_check_revision(false);
omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
@@ -439,6 +442,7 @@ void __init ti816x_init_early(void)
void __init omap4430_init_early(void)
{
omap2_set_globals_443x();
+ omap4xxx_check_revision();
omap_common_init_early();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index aa52d1e..51a0262 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -420,7 +420,9 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP446X_CLASS 0x44600044
#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8))
-void omap2_check_revision(void);
+void omap2xxx_check_revision(void);
+void omap3xxx_check_revision(bool has_feature_reg);
+void omap4xxx_check_revision(void);
/*
* Runtime detection of OMAP3 features
--
1.7.0.4
--
To unsubscribe from this list:
[PATCH] arm:omap:serial:cleanup: use module rev instead of cpu_is_xxxx
For OMAP3 uarts (module rev = 0x52) and all successor devices
(omap4, TI81xx, AM33xx, etc...) empty fifo read errata is applicable,
so we can get rid of cpu_is_ check and simply check for module rev here.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
NOTE: This patch has been tested on OMAP3EVM, and I expect to work on all OMAP3
family of devices (including TI816x, TI814x, AM335x, etc...).
but I am quite not sure about OMAP2 device, can anybody comment/test?
arch/arm/mach-omap2/serial.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 9992dbf..ac274dc 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -740,16 +740,16 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata)
p-private_data = uart;
/*
-* omap44xx, ti816x: Never read empty UART fifo
+* all omap3 family of devices: Never read empty UART fifo
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev =0x52
*/
uart-regshift = p-regshift;
uart-membase = p-membase;
- if (cpu_is_omap44xx() || cpu_is_ti816x())
- uart-errata |= UART_ERRATA_FIFO_FULL_ABORT;
- else if ((serial_read_reg(uart, UART_OMAP_MVER) 0xFF)
- = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ if (cpu_is_omap34xx() (serial_read_reg(uart, UART_OMAP_MVER) 0xFF)
+UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-errata = ~UART_ERRATA_FIFO_FULL_ABORT;
+ else
uart-errata |= UART_ERRATA_FIFO_FULL_ABORT;
if (uart-errata UART_ERRATA_FIFO_FULL_ABORT) {
--
1.7.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
RE: [PATCH] arm:omap:serial:cleanup: use module rev instead of cpu_is_xxxx
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, November 07, 2011 8:28 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hiremath, Vaibhav
Subject: [PATCH] arm:omap:serial:cleanup: use module rev instead of
cpu_is_
For OMAP3 uarts (module rev = 0x52) and all successor devices
(omap4, TI81xx, AM33xx, etc...) empty fifo read errata is applicable,
so we can get rid of cpu_is_ check and simply check for module rev
here.
Ideally, isn't module errata information should come
from HWMOD data? I think it should...does it make sense?
Thanks,
Vaibhav
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
NOTE: This patch has been tested on OMAP3EVM, and I expect to work on all
OMAP3
family of devices (including TI816x, TI814x, AM335x, etc...).
but I am quite not sure about OMAP2 device, can anybody comment/test?
arch/arm/mach-omap2/serial.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 9992dbf..ac274dc 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -740,16 +740,16 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata)
p-private_data = uart;
/*
- * omap44xx, ti816x: Never read empty UART fifo
+ * all omap3 family of devices: Never read empty UART fifo
* omap3xxx: Never read empty UART fifo on UARTs
* with IP rev =0x52
*/
uart-regshift = p-regshift;
uart-membase = p-membase;
- if (cpu_is_omap44xx() || cpu_is_ti816x())
- uart-errata |= UART_ERRATA_FIFO_FULL_ABORT;
- else if ((serial_read_reg(uart, UART_OMAP_MVER) 0xFF)
- = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ if (cpu_is_omap34xx() (serial_read_reg(uart, UART_OMAP_MVER)
0xFF)
+ UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+ uart-errata = ~UART_ERRATA_FIFO_FULL_ABORT;
+ else
uart-errata |= UART_ERRATA_FIFO_FULL_ABORT;
if (uart-errata UART_ERRATA_FIFO_FULL_ABORT) {
--
1.7.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
Re: 10-bit address support in i2c-omap and i2c-davinci
Adding linux-omap and linux-davinci lists Jean Delvare kh...@linux-fr.org writes: Both bus drivers i2c-omap and i2c-davinci apparently handle 10-bit addresses: (i2c-omap.c) if (msg-flags I2C_M_TEN) w |= OMAP_I2C_CON_XA; (i2c-davinci.c) /* if the slave address is ten bit address, enable XA bit */ if (msg-flags I2C_M_TEN) flag |= DAVINCI_I2C_MDR_XA; However neither driver declares functionality flag I2C_FUNC_10BIT_ADDR, so chip drivers would normally refuse to bind to these buses. If 10-bit address support is incomplete or broken then it should be removed completely. If it works then these drivers should declare so by adding I2C_FUNC_10BIT_ADDR to the functionality flags they return. -- 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 4/4] arm:omap:am33xx: Add low level debugging support
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, October 07, 2011 4:39 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm- ker...@lists.infradead.org; Mohammed, Afzal Subject: Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support * hvaib...@ti.com hvaib...@ti.com [110920 06:59]: From: Afzal Mohammed af...@ti.com Add support for low level debugging on AM335X EVM (AM33XX family). Currently only support for UART1 console, which is used on AM335X EVM is added. Let's wait a bit on this one as there are other DEBUG_LL patches pending from Nico. Tony, Is there any branch or repo against which I can rebase my patches? Thanks, Vaibhav 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
[PATCH 1/1] mmc: omap_hsmmc: DMA unmap only once in case of MMC error
From: Per Forlin per.for...@linaro.org
Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
WARNING: at lib/dma-debug.c:811 check_unmap
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x80933000] [size=20480 bytes]
In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup()
and then again in omap_hsmmc_post_req(). Resolve this by clearing the
host_cookie to indicate there is no DMA mapped memory to unmap.
Signed-off-by: Per Forlin per.for...@linaro.org
Tested-by: Balaji T K balaj...@ti.com
---
Repost with my Tested-by
drivers/mmc/host/omap_hsmmc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 101cd31..d5fe43d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1010,6 +1010,7 @@ static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host
*host, int errno)
host-data-sg_len,
omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(dma_ch);
+ host-data-host_cookie = 0;
}
host-data = NULL;
}
@@ -1575,8 +1576,10 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc,
struct mmc_request *mrq,
struct mmc_data *data = mrq-data;
if (host-use_dma) {
- dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
-omap_hsmmc_get_dma_dir(host, data));
+ if (data-host_cookie)
+ dma_unmap_sg(mmc_dev(host-mmc), data-sg,
+data-sg_len,
+omap_hsmmc_get_dma_dir(host, data));
data-host_cookie = 0;
}
}
--
1.7.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
Re: 10-bit address support in i2c-omap and i2c-davinci
On Mon, 07 Nov 2011 07:09:38 -0800, Kevin Hilman wrote: Adding linux-omap and linux-davinci lists Good point, sorry for missing that. Maybe the following would help? List i2c-omap and i2c-davinci in MAINTAINERS. Signed-off-by: Jean Delvare kh...@linux-fr.org --- MAINTAINERS |3 +++ 1 file changed, 3 insertions(+) --- linux-3.2-rc0.orig/MAINTAINERS 2011-11-07 17:55:46.0 +0100 +++ linux-3.2-rc0/MAINTAINERS 2011-11-07 17:55:55.0 +0100 @@ -4675,6 +4675,8 @@ Q:http://patchwork.kernel.org/project/l T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git S: Maintained F: arch/arm/*omap*/ +F: drivers/i2c/busses/i2c-omap.c +F: include/linux/i2c-omap.h OMAP CLOCK FRAMEWORK SUPPORT M: Paul Walmsley p...@pwsan.com @@ -5940,6 +5942,7 @@ L:davinci-linux-open-source@linux.davin Q: http://patchwork.kernel.org/project/linux-davinci/list/ S: Supported F: arch/arm/mach-davinci +F: drivers/i2c/busses/i2c-davinci.c SIS 190 ETHERNET DRIVER M: Francois Romieu rom...@fr.zoreil.com -- 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: [RFC/PATCH] ARM: OMAP: Fix build for OMAP3 only builds
On Thu, Nov 03, 2011 at 11:30:02AM -0700, Tony Lindgren wrote: Considering we now have the DT branch merged, I'll apply the earlier patch from Sanjeev with a minor modification to avoid a build warning in board-generic.c. Updated patch below, Sekhar Thomas, care to ack? When are we likely to see this patch in mainline given that my OMAP builds are yet again broken during the merge window? (You can *and should* send fixes for regressions during the merge window. If you want to batch them up and send them towards the end of the merge window, that's a good idea too. But to have a broken -rc1 is bad practice.) -- 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: OMAP CRAP: The Continuing Story Of Brokenness
* Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]: Yet again I find that I'm having to email about crap on OMAP3. I'm getting really fed up with OMAP stuff which keeps breaking in idiotic ways - and the way there's fatal build errors at EVERY merge window. The OMAP workflow is totally broken. Something MUST change in the way the OMAP community works to stop the continual breakage at every single bloody merge window. Hmm he following fixes are queued elsewhere and now merged: omap_hsmmc: fix missing parenthesis in pr_info PM / OPP: Fix build when CONFIG_PM_OPP is not set net: Add back alignment for size for __alloc_skb Or have you seen some other build errors? FYI, now all the compile warnings are finally gone with what I have in fixes branch. One is new: WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174() usb_musb_init: could not find omap_hwmod for usb_otg_hs Modules linked in: Backtrace: [c0017920] (dump_backtrace+0x0/0x10c) from [c02d9368] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:008d [c02d9350] (dump_stack+0x0/0x1c) from [c003adfc] (warn_slowpath_common+0x58/0x70) [c003ada4] (warn_slowpath_common+0x0/0x70) from [c003aeb8] (warn_slowpath_fmt+0x38/0x40) r8: r7:0013 r6:c0374b05 r5:c03f06e4 r4:c0374190 [c003ae80] (warn_slowpath_fmt+0x0/0x40) from [c03ceb54] (usb_musb_init+0xc0/0x174) r3:c02df894 r2:c03707d9 [c03cea94] (usb_musb_init+0x0/0x174) from [c03ce02c] (omap_ldp_init+0xb0/0x100) r6:c003e7d8 r5:c03f06e4 r4:c04053e4 [c03cdf7c] (omap_ldp_init+0x0/0x100) from [c03c6788] (customize_machine+0x24/0x30) r4:c03f03a8 [c03c6764] (customize_machine+0x0/0x30) from [c0008710] (do_one_initcall+0x9c/0x164) [c0008674] (do_one_initcall+0x0/0x164) from [c03c3284] (kernel_init+0x7c/0x120) [c03c3208] (kernel_init+0x0/0x120) from [c003e7d8] (do_exit+0x0/0x62c) r5:c03c3208 r4: Felipe, care to check what the status of the musb hwmod issue above is? ---[ end trace 1b75b31a2719ed1c ]--- omap_timer.1: alias fck already exists omap_timer.2: alias fck already exists omap_timer.3: alias fck already exists omap_timer.4: alias fck already exists omap_timer.5: alias fck already exists omap_timer.6: alias fck already exists omap_timer.7: alias fck already exists omap_timer.8: alias fck already exists omap_timer.9: alias fck already exists omap_timer.10: alias fck already exists omap_timer.11: alias fck already exists omap_timer.12: alias fck already exists omap-mcbsp.2: alias fck already exists omap-mcbsp.3: alias fck already exists The fix for this is queued as: ARM: OMAP2+: clock data: Remove redundant timer clkdev 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: [RFC/PATCH] ARM: OMAP: Fix build for OMAP3 only builds
* Russell King - ARM Linux li...@arm.linux.org.uk [07 08:31]: On Thu, Nov 03, 2011 at 11:30:02AM -0700, Tony Lindgren wrote: Considering we now have the DT branch merged, I'll apply the earlier patch from Sanjeev with a minor modification to avoid a build warning in board-generic.c. Updated patch below, Sekhar Thomas, care to ack? When are we likely to see this patch in mainline given that my OMAP builds are yet again broken during the merge window? This is queud in fixes branch now. (You can *and should* send fixes for regressions during the merge window. If you want to batch them up and send them towards the end of the merge window, that's a good idea too. But to have a broken -rc1 is bad practice.) Right, sorry for the delays. I think I have all the pending fixes now queued finally. 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: OMAP CRAP: The Continuing Story Of Brokenness
On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Yet again I find that I'm having to email about crap on OMAP3. I'm getting really fed up with OMAP stuff which keeps breaking in idiotic ways - and the way there's fatal build errors at EVERY merge window. The OMAP workflow is totally broken. Something MUST change in the way the OMAP community works to stop the continual breakage at every single bloody merge window. One is new: WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174() usb_musb_init: could not find omap_hwmod for usb_otg_hs Modules linked in: Backtrace: [c0017920] (dump_backtrace+0x0/0x10c) from [c02d9368] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:008d [c02d9350] (dump_stack+0x0/0x1c) from [c003adfc] (warn_slowpath_common+0x58/0x70) [c003ada4] (warn_slowpath_common+0x0/0x70) from [c003aeb8] (warn_slowpath_fmt+0x38/0x40) r8: r7:0013 r6:c0374b05 r5:c03f06e4 r4:c0374190 [c003ae80] (warn_slowpath_fmt+0x0/0x40) from [c03ceb54] (usb_musb_init+0xc0/0x174) r3:c02df894 r2:c03707d9 [c03cea94] (usb_musb_init+0x0/0x174) from [c03ce02c] (omap_ldp_init+0xb0/0x100) r6:c003e7d8 r5:c03f06e4 r4:c04053e4 [c03cdf7c] (omap_ldp_init+0x0/0x100) from [c03c6788] (customize_machine+0x24/0x30) r4:c03f03a8 [c03c6764] (customize_machine+0x0/0x30) from [c0008710] (do_one_initcall+0x9c/0x164) [c0008674] (do_one_initcall+0x0/0x164) from [c03c3284] (kernel_init+0x7c/0x120) [c03c3208] (kernel_init+0x0/0x120) from [c003e7d8] (do_exit+0x0/0x62c) r5:c03c3208 r4: ---[ end trace 1b75b31a2719ed1c ]--- omap_timer.1: alias fck already exists omap_timer.2: alias fck already exists omap_timer.3: alias fck already exists omap_timer.4: alias fck already exists omap_timer.5: alias fck already exists omap_timer.6: alias fck already exists omap_timer.7: alias fck already exists omap_timer.8: alias fck already exists omap_timer.9: alias fck already exists omap_timer.10: alias fck already exists omap_timer.11: alias fck already exists omap_timer.12: alias fck already exists omap-mcbsp.2: alias fck already exists omap-mcbsp.3: alias fck already exists And this, which I reported on August 26th - so it's now over three months old is still there. Clearly, no one cares about this driver so shall I delete the omap-hsmmc driver, or is someone going to clean up their crap? Or shall we revert all those patches for adding the asynchronous mapping of MMC requests until the _REGRESSION_ is fixed properly? mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 0x900, card status 0xb00 [ cut here ] WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c() omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x8000] [size=16384 bytes] Modules linked in: Backtrace: [c0017920] (dump_backtrace+0x0/0x10c) from [c02d9368] (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:0361 [c02d9350] (dump_stack+0x0/0x1c) from [c003adfc] (warn_slowpath_common+0x58/0x70) [c003ada4] (warn_slowpath_common+0x0/0x70) from [c003aeb8] (warn_slowpath_fmt+0x38/0x40) r8:c1af7d48 r7: r6:4000 r5: r4:8000 [c003ae80] (warn_slowpath_fmt+0x0/0x40) from [c018bfc8] (check_unmap+0x1b0/0x76c) r3:c0375450 r2:c038b8f7 [c018be18] (check_unmap+0x0/0x76c) from [c018c6fc] (debug_dma_unmap_sg+0x100/0x134) [c018c5fc] (debug_dma_unmap_sg+0x0/0x134) from [c0019848] (dma_unmap_sg+0x24/0x7c) [c0019824] (dma_unmap_sg+0x0/0x7c) from [c021112c] (omap_hsmmc_post_req+0x48/0x54) [c02110e4] (omap_hsmmc_post_req+0x0/0x54) from [c0204a8c] (mmc_start_req+0x9c/0x128) r4:c1ab2000 [c02049f0] (mmc_start_req+0x0/0x128) from [c020e6a4] (mmc_blk_issue_rw_rq+0x80/0x4e8) r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24 [c020e624] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [c020ef04] (mmc_blk_issue_rq+0x3f8/0x428) [c020eb0c] (mmc_blk_issue_rq+0x0/0x428) from [c020fa8c] (mmc_queue_thread+0xa0/0x104) [c020f9ec] (mmc_queue_thread+0x0/0x104) from [c0055bf0] (kthread+0x88/0x90) [c0055b68] (kthread+0x0/0x90) from [c003e7d8] (do_exit+0x0/0x62c) r7:0013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c ---[ end trace 1b75b31a2719ed1e ]--- This hsmmc issue is fixed by this patch sent out today.. http://marc.info/?l=linux-mmcm=132068306510134w=2 -- 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: OMAP CRAP: The Continuing Story Of Brokenness
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]: Yet again I find that I'm having to email about crap on OMAP3. I'm getting really fed up with OMAP stuff which keeps breaking in idiotic ways - and the way there's fatal build errors at EVERY merge window. The OMAP workflow is totally broken. Something MUST change in the way the OMAP community works to stop the continual breakage at every single bloody merge window. Hmm he following fixes are queued elsewhere and now merged: omap_hsmmc: fix missing parenthesis in pr_info PM / OPP: Fix build when CONFIG_PM_OPP is not set net: Add back alignment for size for __alloc_skb Or have you seen some other build errors? FYI, now all the compile warnings are finally gone with what I have in fixes branch. It was the errors in the ARM: OMAP: Fix build for OMAP3 only builds thread. However, rebuilding today gives brand new breakage - for my OMAP4430SDP config. This seems to be because more linux/module.h includes have been deleted from include/linux/*.h includes. arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:184: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:184: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:215: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:215: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:215: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:228: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:228: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:228: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:234: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:234: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:234: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:240: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:240: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:240: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:248: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:248: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:248: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:294: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:294: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:294: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:302: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:302: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:302: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:316: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:316: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:316: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:344: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:344: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:344: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:361: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:361: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:361: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:380: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:380: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:380: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:406: warning: data definition has no type or storage class arch/arm/plat-omap/dmtimer.c:406: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/arm/plat-omap/dmtimer.c:406: warning: parameter names (without types) in function declaration arch/arm/plat-omap/dmtimer.c:443: warning:
Re: OMAP CRAP: The Continuing Story Of Brokenness
Hi,
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]:
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way there's fatal build errors at EVERY merge
window. The OMAP workflow is totally broken. Something MUST change
in the way the OMAP community works to stop the continual breakage
at every single bloody merge window.
Hmm he following fixes are queued elsewhere and now merged:
omap_hsmmc: fix missing parenthesis in pr_info
PM / OPP: Fix build when CONFIG_PM_OPP is not set
net: Add back alignment for size for __alloc_skb
Or have you seen some other build errors?
FYI, now all the compile warnings are finally gone with what
I have in fixes branch.
One is new:
WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174()
usb_musb_init: could not find omap_hwmod for usb_otg_hs
Modules linked in:
Backtrace:
[c0017920] (dump_backtrace+0x0/0x10c) from [c02d9368]
(dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:008d
[c02d9350] (dump_stack+0x0/0x1c) from [c003adfc]
(warn_slowpath_common+0x58/0x70)
[c003ada4] (warn_slowpath_common+0x0/0x70) from [c003aeb8]
(warn_slowpath_fmt+0x38/0x40)
r8: r7:0013 r6:c0374b05 r5:c03f06e4 r4:c0374190
[c003ae80] (warn_slowpath_fmt+0x0/0x40) from [c03ceb54]
(usb_musb_init+0xc0/0x174)
r3:c02df894 r2:c03707d9
[c03cea94] (usb_musb_init+0x0/0x174) from [c03ce02c]
(omap_ldp_init+0xb0/0x100)
r6:c003e7d8 r5:c03f06e4 r4:c04053e4
[c03cdf7c] (omap_ldp_init+0x0/0x100) from [c03c6788]
(customize_machine+0x24/0x30)
r4:c03f03a8
[c03c6764] (customize_machine+0x0/0x30) from [c0008710]
(do_one_initcall+0x9c/0x164)
[c0008674] (do_one_initcall+0x0/0x164) from [c03c3284]
(kernel_init+0x7c/0x120)
[c03c3208] (kernel_init+0x0/0x120) from [c003e7d8] (do_exit+0x0/0x62c)
r5:c03c3208 r4:
Felipe, care to check what the status of the musb hwmod issue
above is?
doesn't seem to be a bug on usb-musb.c, looking at
omap_hwmod_3xxx_data.c:
$ git grep -A 1 -e static struct omap_hwmod \w\+usbhsotg_hwmod = {\
arch/arm/mach-omap2/omap_hwmod*data.c
arch/arm/mach-omap2/omap_hwmod_2430_data.c:static struct omap_hwmod
omap2430_usbhsotg_hwmod = {
arch/arm/mach-omap2/omap_hwmod_2430_data.c- .name = usb_otg_hs,
--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c:static struct omap_hwmod
omap3xxx_usbhsotg_hwmod = {
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c- .name = usb_otg_hs,
--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c:static struct omap_hwmod
am35xx_usbhsotg_hwmod = {
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c- .name =
am35x_otg_hs,
in fact, that part of the code hasn't changed during this merge window:
$ git log v3.1..linus/master -- arch/arm/mach-omap2/usb-musb.c
commit f718e2c034bf6ff872106344935006230764cb12
Author: Benoit Cousson b-cous...@ti.com
Date: Wed Aug 10 15:30:09 2011 +0200
ARM: OMAP2+: devices: Remove all omap_device_pm_latency structures
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d86af3c..47fb5d6 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -60,14 +60,6 @@ static struct musb_hdrc_platform_data musb_plat = {
static u64 musb_dmamask = DMA_BIT_MASK(32);
-static struct omap_device_pm_latency omap_musb_latency[] = {
- {
- .deactivate_func= omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static void usb_musb_mux_init(struct omap_musb_board_data *board_data)
{
switch (board_data-interface_type) {
@@ -150,8 +142,7 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
return;
pdev = omap_device_build(name, bus_id, oh, musb_plat,
- sizeof(musb_plat), omap_musb_latency,
- ARRAY_SIZE(omap_musb_latency), false);
+ sizeof(musb_plat), NULL, 0, false);
if (IS_ERR(pdev)) {
pr_err(Could not build omap_device for %s %s\n,
name, oh_name);
commit c541c15fb5ab48c47bc9b90121538fd30d152f23
Merge: 5c30cdf be73246 7d33910 ab4eb8b dc9ca24
Author: Tony Lindgren t...@atomide.com
Date: Tue Oct 4 09:47:06 2011 -0700
Merge branches 'cleanup-part3', 'voltage', 'dmtimer' and 'l3' into dt-base
could the below be the bug ?
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
Re: OMAP CRAP: The Continuing Story Of Brokenness
* Russell King - ARM Linux li...@arm.linux.org.uk [07 09:12]: On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [06 03:44]: Yet again I find that I'm having to email about crap on OMAP3. I'm getting really fed up with OMAP stuff which keeps breaking in idiotic ways - and the way there's fatal build errors at EVERY merge window. The OMAP workflow is totally broken. Something MUST change in the way the OMAP community works to stop the continual breakage at every single bloody merge window. Hmm he following fixes are queued elsewhere and now merged: omap_hsmmc: fix missing parenthesis in pr_info PM / OPP: Fix build when CONFIG_PM_OPP is not set net: Add back alignment for size for __alloc_skb Or have you seen some other build errors? FYI, now all the compile warnings are finally gone with what I have in fixes branch. It was the errors in the ARM: OMAP: Fix build for OMAP3 only builds thread. OK, that's queued up. However, rebuilding today gives brand new breakage - for my OMAP4430SDP config. This seems to be because more linux/module.h includes have been deleted from include/linux/*.h includes. arch/arm/plat-omap/dmtimer.c:184: warning: data definition has no type or storage class ... Got a fix for that one queued up too. In addition, for OMAP3430 LDP: arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration Looks like there's a fix for this one posted, will add that. arch/arm/mach-omap2/mailbox.c:417: error: expected declaration specifiers or '...' before string constant arch/arm/mach-omap2/mailbox.c:417: warning: data definition has no type or storage class arch/arm/mach-omap2/mailbox.c:417: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE' ... drivers/video/omap/dispc.c:276: warning: data definition has no type or storage class drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' Yeah after pulling in the current mainline I see at least the above two need to be patched. It might be an idea to do this: grep -rl EXPORT_SYMBOL arch/arm/*omap* | xargs grep -L linux/export.h and for any OMAP drivers as well. This gives: arch/arm/mach-omap1/id.c arch/arm/mach-omap1/lcd_dma.c arch/arm/mach-omap1/io.c arch/arm/mach-omap1/ams-delta-fiq.c arch/arm/mach-omap2/gpmc.c arch/arm/mach-omap2/id.c arch/arm/mach-omap2/io.c arch/arm/plat-omap/ocpi.c arch/arm/plat-omap/mcbsp.c arch/arm/plat-omap/omap_device.c arch/arm/plat-omap/mux.c arch/arm/plat-omap/devices.c arch/arm/plat-omap/io.c arch/arm/plat-omap/dma.c arch/arm/plat-omap/dmtimer.c arch/arm/plat-omap/mailbox.c which probably should all be fixed before any more of these errors spring up. Except for the ones that have module.h included as that already includes export.h. At least the dmtimer.c will be moved to drivers, and could be a loadable module so module.h is better there. Anyways, will check these and post patches. 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
[PATCH] arm: omap2+: hwmod: fix breakage introduced by d6504acd
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a hwmod available only on ES2.0
of OMAP3430.
MUSB hwmod has always be available on all OMAP revisions
since OMAP2430.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3008e16..74f1454 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3232,7 +3232,6 @@ static __initdata struct omap_hwmod *omap3430es1_hwmods[]
= {
/* 3430ES2+-only hwmods */
static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
omap3xxx_dss_core_hwmod,
- omap3xxx_usbhsotg_hwmod,
NULL
};
@@ -3240,6 +3239,7 @@ static __initdata struct omap_hwmod
*omap3430es2plus_hwmods[] = {
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
omap34xx_sr1_hwmod,
omap34xx_sr2_hwmod,
+ omap3xxx_usbhsotg_hwmod,
NULL
};
--
1.7.8.rc0
--
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 4/4] arm:omap:am33xx: Add low level debugging support
* Hiremath, Vaibhav hvaib...@ti.com [07 06:42]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, October 07, 2011 4:39 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Hilman, Kevin; p...@pwsan.com; linux-arm- ker...@lists.infradead.org; Mohammed, Afzal Subject: Re: [PATCH-V3 4/4] arm:omap:am33xx: Add low level debugging support * hvaib...@ti.com hvaib...@ti.com [110920 06:59]: From: Afzal Mohammed af...@ti.com Add support for low level debugging on AM335X EVM (AM33XX family). Currently only support for UART1 console, which is used on AM335X EVM is added. Let's wait a bit on this one as there are other DEBUG_LL patches pending from Nico. Tony, Is there any branch or repo against which I can rebase my patches? I recommend the current fixes branch. 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
[PATCH] omap: id: add chip id recognition for omap4430 es2.3
allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf Signed-off-by: David Anders x0132...@ti.com --- arch/arm/mach-omap2/id.c |6 -- arch/arm/plat-omap/include/plat/cpu.h |1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index d27daf9..6681238 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -386,8 +386,10 @@ static void __init omap4_check_revision(void) omap_revision = OMAP4430_REV_ES2_1; break; case 4: - default: omap_revision = OMAP4430_REV_ES2_2; + case 6: + default: + omap_revision = OMAP4430_REV_ES2_3; } break; case 0xb94e: @@ -400,7 +402,7 @@ static void __init omap4_check_revision(void) break; default: /* Unknown default to latest silicon rev as default */ - omap_revision = OMAP4430_REV_ES2_2; + omap_revision = OMAP4430_REV_ES2_3; } pr_info(OMAP%04x ES%d.%d\n, omap_rev() 16, diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 649b370..a2fc6d3 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -416,6 +416,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define OMAP4430_REV_ES2_0 (OMAP443X_CLASS | (0x20 8)) #define OMAP4430_REV_ES2_1 (OMAP443X_CLASS | (0x21 8)) #define OMAP4430_REV_ES2_2 (OMAP443X_CLASS | (0x22 8)) +#define OMAP4430_REV_ES2_3 (OMAP443X_CLASS | (0x23 8)) #define OMAP446X_CLASS 0x44600044 #define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8)) -- 1.7.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
Re: [PATCH v3 4/4] OMAP3/4: iommu: adapt to runtime pm
Hi, On Fri, Nov 4, 2011 at 6:27 PM, Kevin Hilman khil...@ti.com wrote: @@ -821,9 +820,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!obj-refcount) return IRQ_NONE; - clk_enable(obj-clk); errs = iommu_report_fault(obj, da); - clk_disable(obj-clk); if (errs == 0) return IRQ_HANDLED; I'm not terribly familiar with this IOMMU code, but this one looks suspiciou because you're removing the clock calls but not replacing them with runtime PM get/put calls. I just want to make sure that's intentional. If so, you might want to add a comment about that to the changelog. Yes it is intentional, reason is that in order to get an interrupt, the device should be powered on in advance, right now it is working because the modules share a common clock so the users of the omap-iommu indirectly give power to it. However I made another change to do pm_runtime_get/put on attach/detach so it doesn't rely on others to keep the clocks on. I'll add the comment. Thanks, Omar -- 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/1] mmc: omap_hsmmc: DMA unmap only once in case of MMC error
On Mon, Nov 07, 2011 at 09:55:11PM +0530, Balaji T K wrote:
From: Per Forlin per.for...@linaro.org
Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
WARNING: at lib/dma-debug.c:811 check_unmap
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x80933000] [size=20480 bytes]
In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup()
and then again in omap_hsmmc_post_req(). Resolve this by clearing the
host_cookie to indicate there is no DMA mapped memory to unmap.
Signed-off-by: Per Forlin per.for...@linaro.org
Tested-by: Balaji T K balaj...@ti.com
---
Repost with my Tested-by
Thanks.
Tested-by: Russell King rmk+ker...@arm.linux.org.uk
drivers/mmc/host/omap_hsmmc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 101cd31..d5fe43d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1010,6 +1010,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
host-data-sg_len,
omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(dma_ch);
+ host-data-host_cookie = 0;
}
host-data = NULL;
}
@@ -1575,8 +1576,10 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc,
struct mmc_request *mrq,
struct mmc_data *data = mrq-data;
if (host-use_dma) {
- dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
- omap_hsmmc_get_dma_dir(host, data));
+ if (data-host_cookie)
+ dma_unmap_sg(mmc_dev(host-mmc), data-sg,
+ data-sg_len,
+ omap_hsmmc_get_dma_dir(host, data));
data-host_cookie = 0;
}
}
--
1.7.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
Re: [PATCH] arm: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote: commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has mistakenly added MUSB as a hwmod available only on ES2.0 of OMAP3430. MUSB hwmod has always be available on all OMAP revisions since OMAP2430. This doesn't seem to solve it: dpll3_m2_clk rate change failed: -22 [ cut here ] WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174() usb_musb_init: could not find omap_hwmod for usb_otg_hs Modules linked in: Backtrace: [c0017920] (dump_backtrace+0x0/0x10c) from [c02d9898] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037547b r4:008d [c02d9880] (dump_stack+0x0/0x1c) from [c003ae08] (warn_slowpath_common+0x58/0x70) [c003adb0] (warn_slowpath_common+0x0/0x70) from [c003aec4] (warn_slowpath_fmt+0x38/0x40) r8: r7:0013 r6:c0374b09 r5:c03f06e4 r4:c03741b0 [c003ae8c] (warn_slowpath_fmt+0x0/0x40) from [c03ceb54] (usb_musb_init+0xc0/0x174) r3:c02df894 r2:c03707f9 [c03cea94] (usb_musb_init+0x0/0x174) from [c03ce02c] (omap_ldp_init+0xb0/0x100) r6:c003e7e4 r5:c03f06e4 r4:c04053e4 [c03cdf7c] (omap_ldp_init+0x0/0x100) from [c03c6788] (customize_machine+0x24/0x30) r4:c03f03a8 [c03c6764] (customize_machine+0x0/0x30) from [c0008710] (do_one_initcall+0x9c/0x164) [c0008674] (do_one_initcall+0x0/0x164) from [c03c3284] (kernel_init+0x7c/0x120) [c03c3208] (kernel_init+0x0/0x120) from [c003e7e4] (do_exit+0x0/0x62c) r5:c03c3208 r4: ---[ end trace 1b75b31a2719ed1c ]--- -- 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/1] mmc: omap_hsmmc: DMA unmap only once in case of MMC error
Hi, On Mon, Nov 07 2011, Russell King - ARM Linux wrote: On Mon, Nov 07, 2011 at 09:55:11PM +0530, Balaji T K wrote: From: Per Forlin per.for...@linaro.org Reported by Russell King: mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response 0x900, card status 0xb00 mmcblk0: retrying using single block read WARNING: at lib/dma-debug.c:811 check_unmap omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x80933000] [size=20480 bytes] In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup() and then again in omap_hsmmc_post_req(). Resolve this by clearing the host_cookie to indicate there is no DMA mapped memory to unmap. Signed-off-by: Per Forlin per.for...@linaro.org Tested-by: Balaji T K balaj...@ti.com --- Repost with my Tested-by Thanks. Tested-by: Russell King rmk+ker...@arm.linux.org.uk Thanks, pushed to mmc-next for 3.2. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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/1] OMAP: TWL: set clk32kg regulator on
Mahaveer, Vishal vish...@ti.com writes: omap4_clk32kg regulator is used by connectivity (WLAN/BT/GPS) chip on omap4 platforms. Set always_on flag to true for connectivity chip to operate. The driver/init for the connectivity chip should be using the regulator API to enable/disable the regulator as needed. The connectivity chip is used for BT, WLAN, FM and GPS. So we want it on at all times. No. You want it on only 1) if the connectivity chip is present, *and* 2) BT, WLAN, FM or GPS are being used. The current patch assumes that a connectivity chip is present whenever the TWL is present, which may be true on the platform you're currently working on, but is not true in general. And, even if it were present, for power reasons the regulator should be enabled only when it's needed, not because it might be needed. That means that the device-specific (or board specific) code should be configuring the regulators used for the various modules so the drivers can request the regulators when they're needed. 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: omap2+: hwmod: fix breakage introduced by d6504acd
Hi, On Mon, Nov 07, 2011 at 06:32:08PM +, Russell King - ARM Linux wrote: On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote: commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has mistakenly added MUSB as a hwmod available only on ES2.0 of OMAP3430. MUSB hwmod has always be available on all OMAP revisions since OMAP2430. This doesn't seem to solve it: then i can't help. From all I know the LDP is based on OMAP3430 so that should work. If it doesn't, it's something deeper on hwmod, maybe ? Paul, it's your call. -- balbi signature.asc Description: Digital signature
Re: [PATCH] arm:omap:serial:cleanup: use module rev instead of cpu_is_xxxx
Vaibhav Hiremath hvaib...@ti.com writes: For OMAP3 uarts (module rev = 0x52) and all successor devices (omap4, TI81xx, AM33xx, etc...) empty fifo read errata is applicable, so we can get rid of cpu_is_ check and simply check for module rev here. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- NOTE: This patch has been tested on OMAP3EVM, and I expect to work on all OMAP3 family of devices (including TI816x, TI814x, AM335x, etc...). but I am quite not sure about OMAP2 device, can anybody comment/test? Leaving OMAP2 as it is should be fine. There is a major UART cleanup in progress from Govindraj. I suggest you rework this patch on top of his series from 10/18: [PATCH v7 00/21] OMAP2+: UART: Runtime adaptation + cleanup although it still has a few changes to go through before being ready to merge. 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: OMAP CRAP: The Continuing Story Of Brokenness
Tomi, * Russell King - ARM Linux li...@arm.linux.org.uk [07 09:12]: drivers/video/omap/dispc.c:276: warning: data definition has no type or storage class drivers/video/omap/dispc.c:276: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/video/omap/dispc.c:276: warning: parameter names (without types) in function declaration drivers/video/omap/dispc.c:286: warning: data definition has no type or storage class drivers/video/omap/dispc.c:286: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/video/omap/dispc.c:286: warning: parameter names (without types) in function declaration drivers/video/omap/dispc.c:320: warning: data definition has no type or storage class drivers/video/omap/dispc.c:320: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/video/omap/dispc.c:320: warning: parameter names (without types) in function declaration drivers/video/omap/dispc.c:328: warning: data definition has no type or storage class drivers/video/omap/dispc.c:328: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/video/omap/dispc.c:328: warning: parameter names (without types) in function declaration drivers/video/omap/dispc.c:863: warning: data definition has no type or storage class drivers/video/omap/dispc.c:863: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/video/omap/dispc.c:863: warning: parameter names (without types) in function declaration drivers/video/omap/dispc.c:883: warning: data definition has no type or storage class drivers/video/omap/dispc.c:883: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' drivers/video/omap/dispc.c:883: warning: parameter names (without types) in function declaration Care to queue something for drivers/video/omap warnings above? It might be an idea to do this: grep -rl EXPORT_SYMBOL arch/arm/*omap* | xargs grep -L linux/export.h and for any OMAP drivers as well. This gives: arch/arm/mach-omap1/id.c arch/arm/mach-omap1/lcd_dma.c arch/arm/mach-omap1/io.c arch/arm/mach-omap1/ams-delta-fiq.c arch/arm/mach-omap2/gpmc.c arch/arm/mach-omap2/id.c arch/arm/mach-omap2/io.c arch/arm/plat-omap/ocpi.c arch/arm/plat-omap/mcbsp.c arch/arm/plat-omap/omap_device.c arch/arm/plat-omap/mux.c arch/arm/plat-omap/devices.c arch/arm/plat-omap/io.c arch/arm/plat-omap/dma.c arch/arm/plat-omap/dmtimer.c arch/arm/plat-omap/mailbox.c which probably should all be fixed before any more of these errors spring up. I'll add the following patch to fix the remaining arch/arm/*omap*/ warnings in fixes branch. Tony From: Tony Lindgren t...@atomide.com Date: Mon, 7 Nov 2011 11:58:55 -0800 Subject: [PATCH] ARM: OMAP: Fix export.h or module.h includes Commit 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb (Merge branch 'modsplit-Oct31_2011'...) caused some build errors. Fix these and make sure we always have export.h or module.h included for MODULE_ and EXPORT_SYMBOL users: $ grep -rl ^MODULE_ arch/arm/*omap*/*.c | xargs \ grep -L linux/module.h arch/arm/mach-omap2/dsp.c arch/arm/mach-omap2/mailbox.c arch/arm/mach-omap2/omap-iommu.c arch/arm/mach-omap2/smartreflex.c Also check we either have export.h or module.h included for the files exporting symbols: $ grep -rl EXPORT_SYMBOL arch/arm/*omap*/*.c | xargs \ grep -L linux/export.h | xargs grep -L linux/module.h Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/dsp.c +++ b/arch/arm/mach-omap2/dsp.c @@ -18,6 +18,7 @@ * of the OMAP PM core code. */ +#include linux/module.h #include linux/platform_device.h #include cm2xxx_3xxx.h #include prm2xxx_3xxx.h --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -10,6 +10,7 @@ * for more details. */ +#include linux/module.h #include linux/clk.h #include linux/err.h #include linux/platform_device.h --- a/arch/arm/mach-omap2/omap-iommu.c +++ b/arch/arm/mach-omap2/omap-iommu.c @@ -10,6 +10,7 @@ * published by the Free Software Foundation. */ +#include linux/module.h #include linux/platform_device.h #include plat/iommu.h --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -17,6 +17,7 @@ * published by the Free Software Foundation. */ +#include linux/module.h #include linux/interrupt.h #include linux/clk.h #include linux/io.h -- 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/4] ARM: OMAP3: cm-t35: add regulator supply for ads7846
* Igor Grinberg grinb...@compulab.co.il [06 04:45]: Hi Tony, On 11/05/11 01:57, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [04 16:05]: * Igor Grinberg grinb...@compulab.co.il [111019 02:05]: Applying to board branch for v3.3 merge window. Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those. This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window. Well, actually all them are fixes, although it cannot be understood from the subject. I will adjust the subjects (and may be the commit messages also) to be more specific and resend. Hmm 1 4 are features that never worked type fixes, so they have flame potential. Those have to wait for the next merge window. Patches 2 3 could be justified as fixes during the -rc cycle. Or I can just apply all of them into board branch to wait for the next merge window. 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 RESEND] ARM: OMAP: omap_device: Include linux/export.h
* Axel Lin axel@gmail.com [02 23:26]: Include linux/export.h to fix below build warning: CC arch/arm/plat-omap/omap_device.o arch/arm/plat-omap/omap_device.c:1055: warning: data definition has no type or storage class arch/arm/plat-omap/omap_device.c:1055: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' arch/arm/plat-omap/omap_device.c:1055: warning: parameter names (without types) in function declaration Applying into fixes thanks. 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
[GIT PULL] omap fixes for v3.2 merge window breakage
Hi Arnd, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This contains the pending fixes I've found in my inbox. Some of these I would have sent earlier, but was waiting for the DT branch merge to clear first. This series fixes all the arch/arm/*omap*/ build warnings finally, looks like there's one new one for hwspinlock that already has a fix queued elsewhere. Some patches also remove some dead code, so ideally these should get merged early on during the merge cycle. Overall a negative negative diffstat anyways ;) Also not that I applied two trivial patches today to fix the remaining modsplit related build issues. Regards, Tony The following changes since commit 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb: Linus Torvalds (1): Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/.../paulg/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Abhilash K V (1): ARM: OMAP: AM35x: remove hwmods that aren't generic Archit Taneja (1): ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Axel Lin (3): ARM: OMAP2+: l3-noc: Include linux/module.h ARM: OMAP: dmtimer: Include linux/module.h ARM: OMAP: omap_device: Include linux/export.h Balaji T K (2): ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFF ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly Benoit Cousson (2): ARM: OMAP2+: clock data: Remove redundant timer clkdev ARM: OMAP2+: timer: Remove omap_device_pm_latency Bjarne Steinsbo (1): ARM: OMAP: usb: musb: OMAP: Delete unused function Charulatha V (1): ARM: OMAP3: PM: fix pwrdm_post_transition call sequence Jarkko Nikula (2): MAINTAINERS: Update linux-omap git repository ARM: OMAP1: Remove unused omap-alsa.h Jon Hunter (3): ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK ARM: OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices Laurent Pinchart (1): ARM: OMAP: I2C: Fix omap_register_i2c_bus() return value on success Mike Turquette (3): ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate ARM: OMAP3+: dpll: assign clk rate from rounded rate during rate set Paul Walmsley (4): ARM: OMAP4460: Clock: Adding support for 4460 specific clocks ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Peter Ujfalusi (1): ARM: OMAP2+: devices: Fixes for McPDM Sanjeev Premi (1): ARM: OMAP: Fix errors and warnings when building for one board Thomas Weber (1): ARM: OMAP: Devkit8000: Remove double omap_mux_init_gpio Tomi Valkeinen (1): ARM: OMAP: change get_context_loss_count ret value to int Tony Lindgren (7): Merge branch 'omap_clock_fixes_3.2' of git://git.pwsan.com/linux-2.6 into fixes Merge branch 'prcm_scm_misc_fixes_3.2' of git://git.pwsan.com/linux-2.6 into fixes Merge branch 'for_3.2/pm-cleanup-2' of git://github.com/khilman/linux-omap-pm into fixes ARM: OMAP1: Fix warnings about enabling 32 KiHz timer ARM: OMAP2: Fix H4 matrix keyboard warning ARM: OMAP: Fix export.h or module.h includes Merge branch 'fixes-modulesplit' into fixes MAINTAINERS|2 +- arch/arm/mach-omap1/board-palmz71.c|1 - arch/arm/mach-omap1/pm.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-generic.c|8 ++ arch/arm/mach-omap2/board-h4.c | 122 +++- arch/arm/mach-omap2/clkt_dpll.c| 51 ++--- arch/arm/mach-omap2/clock.h|2 + arch/arm/mach-omap2/clock2420_data.c | 12 -- arch/arm/mach-omap2/clock2430_data.c | 12 -- arch/arm/mach-omap2/clock3xxx_data.c | 12 -- arch/arm/mach-omap2/clock44xx.h|7 + arch/arm/mach-omap2/clock44xx_data.c | 43 --- arch/arm/mach-omap2/devices.c | 17 +--- arch/arm/mach-omap2/dpll3xxx.c |9 +- arch/arm/mach-omap2/dpll44xx.c | 69 +++ arch/arm/mach-omap2/dsp.c |1 + arch/arm/mach-omap2/hsmmc.c| 16 +-- arch/arm/mach-omap2/id.c |5 +- .../include/mach/ctrl_module_pad_core_44xx.h |8 +- arch/arm/mach-omap2/io.c |6 + arch/arm/mach-omap2/mailbox.c |1 +
[PATCH] omap4: i2c: add post idle reset registers flag
omap44xx i2c devices need to have the registers reset post idle
similar to omap3xxx devices. this adds the additional flag for
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE to the omap44xx i2c_dev_attr.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..e93dc40 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2257,7 +2257,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
--
1.7.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
RE: [PATCH 1/1] OMAP: TWL: set clk32kg regulator on
Hilman, Kevin wrote: No. You want it on only 1) if the connectivity chip is present, *and* 2) BT, WLAN, FM or GPS are being used. The current patch assumes that a connectivity chip is present whenever the TWL is present, which may be true on the platform you're currently working on, but is not true in general. And, even if it were present, for power reasons the regulator should be enabled only when it's needed, not because it might be needed. That means that the device-specific (or board specific) code should be configuring the regulators used for the various modules so the drivers can request the regulators when they're needed. Kevin Will it make more sense to move clk32 regulator initialization to board-xxx files of platforms which has the connectivity chip? - Vishal-- 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: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, Nov 07, 2011 at 09:39:09PM +0200, Felipe Balbi wrote:
Hi,
On Mon, Nov 07, 2011 at 06:32:08PM +, Russell King - ARM Linux wrote:
On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote:
commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
mistakenly added MUSB as a hwmod available only on ES2.0
of OMAP3430.
MUSB hwmod has always be available on all OMAP revisions
since OMAP2430.
This doesn't seem to solve it:
then i can't help. From all I know the LDP is based on OMAP3430 so that
should work. If it doesn't, it's something deeper on hwmod, maybe ?
Nothing here is specific to the LDP.
Paul, it's your call.
I think I've found it.
Okay, so. Clearly, *no* one has even tested this stuff on *any* OMAP3
platform:
/* Register hwmods common to all OMAP3 */
r = omap_hwmod_register(omap3xxx_hwmods);
if (!r)
return r;
Hint: it returns ZERO on success. What follows is:
rev = omap_rev();
/*
* Register hwmods common to individual OMAP3 families, all
* silicon revisions (e.g., 34xx, or AM3505/3517, or 36xx)
* All possible revisions should be included in this conditional.
*/
if (rev == OMAP3430_REV_ES1_0 || rev == OMAP3430_REV_ES2_0 ||
rev == OMAP3430_REV_ES2_1 || rev == OMAP3430_REV_ES3_0 ||
rev == OMAP3430_REV_ES3_1 || rev == OMAP3430_REV_ES3_1_2) {
...
which can only ever be reached _iff_ registering omap3xxx_hwmods _fails_.
Not succeeds, but _fails_.
Not surprisingly, the same error is repeated below this group of if
statements:
r = omap_hwmod_register(h);
if (!r)
return r;
So, multiple instances of the same brokenness.
With those both fixed, we come to the next pile of BROKENNESS:
WARNING: at /home/rmk/git/linux-rmk/arch/arm/mach-omap2/omap_hwmod.c:1963
omap_hwmod_register+0x130/0x168()
omap_hwmod: sr1_hwmod: _register returned -22
Modules linked in:
Backtrace:
[c0017920] (dump_backtrace+0x0/0x10c) from [c02d9918]
(dump_stack+0x18/0x1c) r7:c03f3ef0 r6:c03cc318 r5:c0370c9f r4:07ab
[c02d9900] (dump_stack+0x0/0x1c) from [c003ae88]
(warn_slowpath_common+0x58/0x70)
[c003ae30] (warn_slowpath_common+0x0/0x70) from [c003af44]
(warn_slowpath_fmt+0x38/0x40)
r8:c0433e84 r7:0001 r6:c03f9550 r5:c03eb41c r4:c0402f4c
[c003af0c] (warn_slowpath_fmt+0x0/0x40) from [c03cc318]
(omap_hwmod_register+0x130/0x168)
r3:c0374aba r2:c037127b
[c03cc1e8] (omap_hwmod_register+0x0/0x168) from [c03cdc70]
(omap3xxx_hwmod_init+0xd8/0x170)
r8:c0818fb4 r7:c03f7968 r6: r5: r4:34300234
[c03cdb98] (omap3xxx_hwmod_init+0x0/0x170) from [c03c9c70]
(omap3_init_early+0x24/0x30)
r6:c03e6484 r5:c0818fe4 r4:c0932980
[c03c9c4c] (omap3_init_early+0x0/0x30) from [c03c9cc8]
(omap3430_init_early+0x10/0x14)
[c03c6a24] (setup_arch+0x0/0x818) from [c03c3638] (start_kernel+0x80/0x308)
[c03c35b8] (start_kernel+0x0/0x308) from [80008040] (0x80008040)
r8:80004059 r7:c03f789c r6:c03e79c8 r5:c03f4098 r4:10c53c7d
---[ end trace 1b75b31a2719ed1c ]---
[ cut here ]
WARNING: at /home/rmk/git/linux-rmk/arch/arm/mach-omap2/omap_hwmod.c:1963
omap_hwmod_register+0x130/0x168()
omap_hwmod: sr2_hwmod: _register returned -22
Modules linked in:
Backtrace:
[c0017920] (dump_backtrace+0x0/0x10c) from [c02d9918]
(dump_stack+0x18/0x1c) r7:c03f3ef0 r6:c03cc318 r5:c0370c9f r4:07ab
[c02d9900] (dump_stack+0x0/0x1c) from [c003ae88]
(warn_slowpath_common+0x58/0x70)
[c003ae30] (warn_slowpath_common+0x0/0x70) from [c003af44]
(warn_slowpath_fmt+0x38/0x40)
r8:c0433e84 r7:0001 r6:c03f9550 r5:c03eb420 r4:c0402fd0
[c003af0c] (warn_slowpath_fmt+0x0/0x40) from [c03cc318]
(omap_hwmod_register+0x130/0x168)
r3:c0374ac4 r2:c037127b
[c03cc1e8] (omap_hwmod_register+0x0/0x168) from [c03cdc70]
(omap3xxx_hwmod_init+0xd8/0x170)
r8:c0818fb4 r7:c03f7968 r6: r5: r4:34300234
[c03cdb98] (omap3xxx_hwmod_init+0x0/0x170) from [c03c9c70]
(omap3_init_early+0x24/0x30)
r6:c03e6484 r5:c0818fe4 r4:c0932980
[c03c9c4c] (omap3_init_early+0x0/0x30) from [c03c9cc8]
(omap3430_init_early+0x10/0x14)
[c03c9cb8] (omap3430_init_early+0x0/0x14) from [c03c7120]
(setup_arch+0x6fc/0x818)
[c03c6a24] (setup_arch+0x0/0x818) from [c03c3638] (start_kernel+0x80/0x308)
[c03c35b8] (start_kernel+0x0/0x308) from [80008040] (0x80008040)
r8:80004059 r7:c03f789c r6:c03e79c8 r5:c03f4098 r4:10c53c7d
---[ end trace 1b75b31a2719ed1d ]---
Again, this is not specific to the LDP. It's whinging about:
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
btw, this should be:
static struct omap_hwmod *omap3xxx_hwmods[] __initdata = {
...
omap34xx_sr1_hwmod,== XXX
omap34xx_sr2_hwmod,== XXX
...
};
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
omap34xx_sr1_hwmod,== XXX
omap34xx_sr2_hwmod,== XXX
omap3xxx_usbhsotg_hwmod,
NULL
};
Again, can
Re: [GIT PULL] omap fixes for v3.2 merge window breakage
Arnd, Don't pull this - there's yet more crap in OMAP to be fixed before these go to mainline. OMAP3 is severely broken at the moment with, to put it bluntly, totally fucked up OMAP hwmod code, and should be fixed *now* by folk before this pull request. The fixes are damned trivial I expect even Tony can fix it without reference to Paul. On Mon, Nov 07, 2011 at 12:49:29PM -0800, Tony Lindgren wrote: Hi Arnd, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This contains the pending fixes I've found in my inbox. Some of these I would have sent earlier, but was waiting for the DT branch merge to clear first. This series fixes all the arch/arm/*omap*/ build warnings finally, looks like there's one new one for hwspinlock that already has a fix queued elsewhere. Some patches also remove some dead code, so ideally these should get merged early on during the merge cycle. Overall a negative negative diffstat anyways ;) Also not that I applied two trivial patches today to fix the remaining modsplit related build issues. Regards, Tony The following changes since commit 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb: Linus Torvalds (1): Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/.../paulg/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Abhilash K V (1): ARM: OMAP: AM35x: remove hwmods that aren't generic Archit Taneja (1): ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Axel Lin (3): ARM: OMAP2+: l3-noc: Include linux/module.h ARM: OMAP: dmtimer: Include linux/module.h ARM: OMAP: omap_device: Include linux/export.h Balaji T K (2): ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFF ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly Benoit Cousson (2): ARM: OMAP2+: clock data: Remove redundant timer clkdev ARM: OMAP2+: timer: Remove omap_device_pm_latency Bjarne Steinsbo (1): ARM: OMAP: usb: musb: OMAP: Delete unused function Charulatha V (1): ARM: OMAP3: PM: fix pwrdm_post_transition call sequence Jarkko Nikula (2): MAINTAINERS: Update linux-omap git repository ARM: OMAP1: Remove unused omap-alsa.h Jon Hunter (3): ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK ARM: OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices Laurent Pinchart (1): ARM: OMAP: I2C: Fix omap_register_i2c_bus() return value on success Mike Turquette (3): ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate ARM: OMAP3+: dpll: assign clk rate from rounded rate during rate set Paul Walmsley (4): ARM: OMAP4460: Clock: Adding support for 4460 specific clocks ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Peter Ujfalusi (1): ARM: OMAP2+: devices: Fixes for McPDM Sanjeev Premi (1): ARM: OMAP: Fix errors and warnings when building for one board Thomas Weber (1): ARM: OMAP: Devkit8000: Remove double omap_mux_init_gpio Tomi Valkeinen (1): ARM: OMAP: change get_context_loss_count ret value to int Tony Lindgren (7): Merge branch 'omap_clock_fixes_3.2' of git://git.pwsan.com/linux-2.6 into fixes Merge branch 'prcm_scm_misc_fixes_3.2' of git://git.pwsan.com/linux-2.6 into fixes Merge branch 'for_3.2/pm-cleanup-2' of git://github.com/khilman/linux-omap-pm into fixes ARM: OMAP1: Fix warnings about enabling 32 KiHz timer ARM: OMAP2: Fix H4 matrix keyboard warning ARM: OMAP: Fix export.h or module.h includes Merge branch 'fixes-modulesplit' into fixes MAINTAINERS|2 +- arch/arm/mach-omap1/board-palmz71.c|1 - arch/arm/mach-omap1/pm.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-generic.c|8 ++ arch/arm/mach-omap2/board-h4.c | 122 +++- arch/arm/mach-omap2/clkt_dpll.c| 51 ++--- arch/arm/mach-omap2/clock.h|2 + arch/arm/mach-omap2/clock2420_data.c | 12 -- arch/arm/mach-omap2/clock2430_data.c | 12 -- arch/arm/mach-omap2/clock3xxx_data.c | 12 -- arch/arm/mach-omap2/clock44xx.h|7 + arch/arm/mach-omap2/clock44xx_data.c | 43 --- arch/arm/mach-omap2/devices.c
Re: [PATCH] arm: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, 7 Nov 2011, Russell King - ARM Linux wrote: Again, can never have been tested on OMAP3. Does anyone apart from me bother doing any testing what so ever on OMAP3 platforms? Am I the only one? This was fixed by http://www.spinics.net/lists/arm-kernel/msg143549.html which didn't go upstream as part of the v3.2 merge window. - 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
Fix handling of return value in omap3xx_hwmod_init and sr warning.
After this, I got some new warnings during bootup about sr1_hwmod and sr2_hwmod. This is fixed with PATCH2/2. -Jürgen -- 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
[PATCH 1/2] ARM:OMAP:hwmod: Fix handling of return value in omap3xx_hwmod_init.
Because omap_hwmod_register() always return '0', checking the
return value as followed:
r = omap_hwmod_register(omap3xxx_hwmods);
if (!r)
return r;
leads to exiting the omap3xxx_hwmod_init() function right after
adding the omap3xxx_hwmods which are common to all omap3 variants.
Therefore hwmods special to other revisions will not be
registered.
Signed-off-by: Juergen Kilb j.k...@phytec.de
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3008e16..30ec4bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3261,14 +3261,11 @@ static __initdata struct omap_hwmod *am35xx_hwmods[] = {
int __init omap3xxx_hwmod_init(void)
{
- int r;
struct omap_hwmod **h = NULL;
unsigned int rev;
/* Register hwmods common to all OMAP3 */
- r = omap_hwmod_register(omap3xxx_hwmods);
- if (!r)
- return r;
+ omap_hwmod_register(omap3xxx_hwmods);
rev = omap_rev();
@@ -3291,9 +3288,7 @@ int __init omap3xxx_hwmod_init(void)
return -EINVAL;
};
- r = omap_hwmod_register(h);
- if (!r)
- return r;
+ omap_hwmod_register(h);
/*
* Register hwmods specific to certain ES levels of a
@@ -3309,7 +3304,7 @@ int __init omap3xxx_hwmod_init(void)
};
if (h)
- r = omap_hwmod_register(h);
+ omap_hwmod_register(h);
- return r;
+ return 0;
}
--
1.7.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
[PATCH 2/2] ARM:OMAP:hwmod: Fix sr1_hwmod and sr2_hwmod warning.
sr1_hwmod and sr2_hwmod are handled in omap34xx_hwmods,
which is for all omap34xx variants.
But they are also defined in omap3xxx_hwmods.
This leads to:
[0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959
omap_hwmod_register+0x40/0x1ac()
[0.00] omap_hwmod: sr1_hwmod: _register returned -22
[0.00] Modules linked in:
[0.00] [c001b11c] (unwind_backtrace+0x0/0xf4) from [c0051540]
(warn_slowpath_common+0x4c/0x64)
[0.00] [c0051540] (warn_slowpath_common+0x4c/0x64) from [c00515ec]
(warn_slowpath_fmt+0x30/0x40)
[0.00] [c00515ec] (warn_slowpath_fmt+0x30/0x40) from [c0639370]
(omap_hwmod_register+0x40/0x1ac)
[0.00] [c0639370] (omap_hwmod_register+0x40/0x1ac) from [c063c138]
(omap3xxx_hwmod_init+0xb0/0x188)
[0.00] [c063c138] (omap3xxx_hwmod_init+0xb0/0x188) from [c06365b0]
(omap3_init_early+0x20/0x30)
[0.00] [c06365b0] (omap3_init_early+0x20/0x30) from [c063219c]
(setup_arch+0x528/0x9a4)
[0.00] [c063219c] (setup_arch+0x528/0x9a4) from [c062e64c]
(start_kernel+0x7c/0x330)
[0.00] [c062e64c] (start_kernel+0x7c/0x330) from [80008044]
(0x80008044)
[0.00] ---[ end trace 1b75b31a2719ed1c ]---
[0.00] [ cut here ]
[0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959
omap_hwmod_register+0x40/0x1ac()
[0.00] omap_hwmod: sr2_hwmod: _register returned -22
[0.00] Modules linked in:
[0.00] [c001b11c] (unwind_backtrace+0x0/0xf4) from [c0051540]
(warn_slowpath_common+0x4c/0x64)
[0.00] [c0051540] (warn_slowpath_common+0x4c/0x64) from [c00515ec]
(warn_slowpath_fmt+0x30/0x40)
[0.00] [c00515ec] (warn_slowpath_fmt+0x30/0x40) from [c0639370]
(omap_hwmod_register+0x40/0x1ac)
[0.00] [c0639370] (omap_hwmod_register+0x40/0x1ac) from [c063c138]
(omap3xxx_hwmod_init+0xb0/0x188)
[0.00] [c063c138] (omap3xxx_hwmod_init+0xb0/0x188) from [c06365b0]
(omap3_init_early+0x20/0x30)
[0.00] [c06365b0] (omap3_init_early+0x20/0x30) from [c063219c]
(setup_arch+0x528/0x9a4)
[0.00] [c063219c] (setup_arch+0x528/0x9a4) from [c062e64c]
(start_kernel+0x7c/0x330)
[0.00] [c062e64c] (start_kernel+0x7c/0x330) from [80008044]
(0x80008044)
[0.00] ---[ end trace 1b75b31a2719ed1d ]---
So remove them from omap3xxx_hwmod definition.
Signed-off-by: Juergen Kilb j.k...@phytec.de
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 30ec4bd..a49e758 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3188,8 +3188,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_i2c1_hwmod,
omap3xxx_i2c2_hwmod,
omap3xxx_i2c3_hwmod,
- omap34xx_sr1_hwmod,
- omap34xx_sr2_hwmod,
/* gpio class */
omap3xxx_gpio1_hwmod,
--
1.7.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
Re: [PATCH] arm: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, 7 Nov 2011, Felipe Balbi wrote: commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has mistakenly added MUSB as a hwmod available only on ES2.0 of OMAP3430. MUSB hwmod has always be available on all OMAP revisions since OMAP2430. Are you sure about this? I don't see it in my 3430ES1 TRM text. - 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: Fix handling of return value in omap3xx_hwmod_init and sr warning.
On Mon, 7 Nov 2011, Juergen Kilb wrote: After this, I got some new warnings during bootup about sr1_hwmod and sr2_hwmod. This is fixed with PATCH2/2. Thanks for the patches, but these should be already fixed by http://www.spinics.net/lists/arm-kernel/msg143549.html - 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
[PATCH v2] omap4: i2c: add post idle reset registers flag
omap44xx i2c devices need to have the registers reset post idle
similar to omap3xxx devices. this adds the additional flag for
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE to the omap44xx i2c_dev_attr.
Signed-off-by: David Anders x0132...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..e93dc40 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2257,7 +2257,8 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
- .flags = OMAP_I2C_FLAG_BUS_SHIFT_NONE,
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ OMAP_I2C_FLAG_BUS_SHIFT_NONE,
};
/* i2c1 */
--
1.7.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
Re: [GIT PULL] omap fixes for v3.2 merge window breakage
* Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]: Arnd, Don't pull this - there's yet more crap in OMAP to be fixed before these go to mainline. OMAP3 is severely broken at the moment with, to put it bluntly, totally fucked up OMAP hwmod code, and should be fixed *now* by folk before this pull request. The fixes are damned trivial I expect even Tony can fix it without reference to Paul. ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Sounds like the above patch already queued should fix the issues you are seeing with hwmod? Or do you still have other issues you're having? 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] arm: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, Nov 07, 2011 at 02:29:35PM -0700, Paul Walmsley wrote: On Mon, 7 Nov 2011, Russell King - ARM Linux wrote: Again, can never have been tested on OMAP3. Does anyone apart from me bother doing any testing what so ever on OMAP3 platforms? Am I the only one? This was fixed by http://www.spinics.net/lists/arm-kernel/msg143549.html which didn't go upstream as part of the v3.2 merge window. Ah, that patch. Which version of the patch does Tony have? The one you point at which uses IS_ERR_VALUE() and I complained about, or the version that has that fixed? -- 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/1] OMAP: TWL: set clk32kg regulator on
Mahaveer, Vishal vish...@ti.com writes: Hilman, Kevin wrote: No. You want it on only 1) if the connectivity chip is present, *and* 2) BT, WLAN, FM or GPS are being used. The current patch assumes that a connectivity chip is present whenever the TWL is present, which may be true on the platform you're currently working on, but is not true in general. And, even if it were present, for power reasons the regulator should be enabled only when it's needed, not because it might be needed. That means that the device-specific (or board specific) code should be configuring the regulators used for the various modules so the drivers can request the regulators when they're needed. Will it make more sense to move clk32 regulator initialization to board-xxx files of platforms which has the connectivity chip? Yes, initialization should be done only when connectivity chip is present. But more importantly, it's the usage of the regulator API that is important. My primary objection to this patch is the use of 'always on', where the drivers/devices that depend on this regulator are the ones that should be requesting it to be on using the regulator API. 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: omap2+: hwmod: fix breakage introduced by d6504acd
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:06]: On Mon, Nov 07, 2011 at 02:29:35PM -0700, Paul Walmsley wrote: On Mon, 7 Nov 2011, Russell King - ARM Linux wrote: Again, can never have been tested on OMAP3. Does anyone apart from me bother doing any testing what so ever on OMAP3 platforms? Am I the only one? This was fixed by http://www.spinics.net/lists/arm-kernel/msg143549.html which didn't go upstream as part of the v3.2 merge window. Ah, that patch. Which version of the patch does Tony have? The one you point at which uses IS_ERR_VALUE() and I complained about, or the version that has that fixed? Here's what I got. Looks like the removal of the sr[12]_hwmod part is no longer needed, so only the r value check part is needed. From: Paul Walmsley p...@pwsan.com Date: Thu, 6 Oct 2011 14:39:28 -0600 Subject: [PATCH] ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Commit d6504acd2125984c61dce24727dd3842d0144015 (OMAP2+: hwmod: remove OMAP_CHIP*) tests the inverse condition of what it should be testing for the return value from omap_hwmod_register(). This causes several IP blocks to not be registered on several OMAP3 family devices. Fixing that bug also unmasked another bug, originally reported by Chase Maupin chase.mau...@ti.com and then subsequently by Abhilash K V abhilash...@ti.com, which caused SmartReflex IP blocks to be registered on SoCs that don't support them. Thanks to Russell King - ARM Linux li...@arm.linux.org.uk for comments on a previous version of the patch. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Chase Maupin chase.mau...@ti.com Cc: Abhilash K V abhilash...@ti.com Cc: Russell King - ARM Linux li...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -3270,7 +3270,7 @@ int __init omap3xxx_hwmod_init(void) /* Register hwmods common to all OMAP3 */ r = omap_hwmod_register(omap3xxx_hwmods); - if (!r) + if (r 0) return r; rev = omap_rev(); @@ -3295,7 +3295,7 @@ int __init omap3xxx_hwmod_init(void) }; r = omap_hwmod_register(h); - if (!r) + if (r 0) return r; /* -- 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: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote: Here's what I got. Looks like the removal of the sr[12]_hwmod part is no longer needed, so only the r value check part is needed. Err. So do you have anything in your git tree which you're pushing out this evening which removes the sr[12]_hwmod from the omap_3xxx_hwmod list? If not, how does that bug get fixed in mainline? -- 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: omap2+: hwmod: fix breakage introduced by d6504acd
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:20]:
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
Here's what I got. Looks like the removal of the sr[12]_hwmod
part is no longer needed, so only the r value check part is needed.
Err. So do you have anything in your git tree which you're pushing out
this evening which removes the sr[12]_hwmod from the omap_3xxx_hwmod
list?
If not, how does that bug get fixed in mainline?
Ah sorry, there's also the following commit there that deals
with other related issues:
From: Abhilash K V abhilash...@ti.com
Date: Fri, 7 Oct 2011 03:08:56 -0600
Subject: [PATCH] ARM: OMAP: AM35x: remove hwmods that aren't generic
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x. This removes quite a few warnings on boot for AM35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
[p...@pwsan.com: dropped 'mailbox class' comments; updated changelog]
Signed-off-by: Paul Walmsley p...@pwsan.com
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3132,7 +3132,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
omap3xxx_mpu_hwmod,
- omap3xxx_iva_hwmod,
omap3xxx_timer1_hwmod,
omap3xxx_timer2_hwmod,
@@ -3161,8 +3160,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_i2c1_hwmod,
omap3xxx_i2c2_hwmod,
omap3xxx_i2c3_hwmod,
- omap34xx_sr1_hwmod,
- omap34xx_sr2_hwmod,
/* gpio class */
omap3xxx_gpio1_hwmod,
@@ -3184,8 +3181,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_mcbsp2_sidetone_hwmod,
omap3xxx_mcbsp3_sidetone_hwmod,
- /* mailbox class */
- omap3xxx_mailbox_hwmod,
/* mcspi class */
omap34xx_mcspi1,
@@ -3198,31 +3193,39 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[]
= {
/* 3430ES1-only hwmods */
static __initdata struct omap_hwmod *omap3430es1_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3430es1_dss_core_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 3430ES2+-only hwmods */
static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3xxx_dss_core_hwmod,
omap3xxx_usbhsotg_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 34xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap34xx_sr1_hwmod,
omap34xx_sr2_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 36xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap36xx_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3xxx_uart4_hwmod,
omap3xxx_dss_core_hwmod,
omap36xx_sr1_hwmod,
omap36xx_sr2_hwmod,
omap3xxx_usbhsotg_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
--
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: omap2+: hwmod: fix breakage introduced by d6504acd
On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:20]:
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
Here's what I got. Looks like the removal of the sr[12]_hwmod
part is no longer needed, so only the r value check part is needed.
Err. So do you have anything in your git tree which you're pushing out
this evening which removes the sr[12]_hwmod from the omap_3xxx_hwmod
list?
If not, how does that bug get fixed in mainline?
Ah sorry, there's also the following commit there that deals
with other related issues:
Great, so it looks like everything that I've found over the last two days
should be solved completely by what you have queued for Arnd.
One last issue though...
We had this patch:
http://lists.arm.linux.org.uk/lurker/message/20111006.232441.227dfcf6.en.html
which is from Paul, post my complaint about IS_ERR_VALUE being used.
This removed sr1_hwmod and sr2_hwmod, and the commit message explicitly
talks about doing this.
There's also the patch below. Somehow, this resulted in that bit of
Paul's patch being removed (possibly automatically by git) but the commit
comments are retained, which are now stale and no longer reflect what the
patch is doing... That's rather unfortunate, but at this point its
probably too late to do something about it.
From: Abhilash K V abhilash...@ti.com
Date: Fri, 7 Oct 2011 03:08:56 -0600
Subject: [PATCH] ARM: OMAP: AM35x: remove hwmods that aren't generic
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x. This removes quite a few warnings on boot for AM35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
[p...@pwsan.com: dropped 'mailbox class' comments; updated changelog]
Signed-off-by: Paul Walmsley p...@pwsan.com
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3132,7 +3132,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[]
= {
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
omap3xxx_mpu_hwmod,
- omap3xxx_iva_hwmod,
omap3xxx_timer1_hwmod,
omap3xxx_timer2_hwmod,
@@ -3161,8 +3160,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[]
= {
omap3xxx_i2c1_hwmod,
omap3xxx_i2c2_hwmod,
omap3xxx_i2c3_hwmod,
- omap34xx_sr1_hwmod,
- omap34xx_sr2_hwmod,
/* gpio class */
omap3xxx_gpio1_hwmod,
@@ -3184,8 +3181,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[]
= {
omap3xxx_mcbsp2_sidetone_hwmod,
omap3xxx_mcbsp3_sidetone_hwmod,
- /* mailbox class */
- omap3xxx_mailbox_hwmod,
/* mcspi class */
omap34xx_mcspi1,
@@ -3198,31 +3193,39 @@ static __initdata struct omap_hwmod
*omap3xxx_hwmods[] = {
/* 3430ES1-only hwmods */
static __initdata struct omap_hwmod *omap3430es1_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3430es1_dss_core_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 3430ES2+-only hwmods */
static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3xxx_dss_core_hwmod,
omap3xxx_usbhsotg_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 34xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap34xx_sr1_hwmod,
omap34xx_sr2_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 36xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap36xx_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3xxx_uart4_hwmod,
omap3xxx_dss_core_hwmod,
omap36xx_sr1_hwmod,
omap36xx_sr2_hwmod,
omap3xxx_usbhsotg_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
--
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: omap2+: hwmod: fix breakage introduced by d6504acd
* Russell King - ARM Linux li...@arm.linux.org.uk [07 14:41]: On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [07 14:20]: On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote: Here's what I got. Looks like the removal of the sr[12]_hwmod part is no longer needed, so only the r value check part is needed. Err. So do you have anything in your git tree which you're pushing out this evening which removes the sr[12]_hwmod from the omap_3xxx_hwmod list? If not, how does that bug get fixed in mainline? Ah sorry, there's also the following commit there that deals with other related issues: Great, so it looks like everything that I've found over the last two days should be solved completely by what you have queued for Arnd. OK good to hear. One last issue though... We had this patch: http://lists.arm.linux.org.uk/lurker/message/20111006.232441.227dfcf6.en.html which is from Paul, post my complaint about IS_ERR_VALUE being used. This removed sr1_hwmod and sr2_hwmod, and the commit message explicitly talks about doing this. There's also the patch below. Somehow, this resulted in that bit of Paul's patch being removed (possibly automatically by git) but the commit comments are retained, which are now stale and no longer reflect what the patch is doing... That's rather unfortunate, but at this point its probably too late to do something about it. Yeah that's a bit unfortunate. At least the commit message mentions what it fixes, and then mentions the secondary bug related to the sr[12]_hwmod entries. Anyways, I'd rather not start messing with commit unless people think it's worth rebasing about half of the patches in fixes. 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
[PATCH] ARM: OMAP3: CPUidle: include linux/export.h
The CPUidle use THIS_MODULE, so needs linux/export.h Signed-off-by: Kevin Hilman khil...@ti.com --- Tony, one more for omap/fixes. This one applies to Linus' master branch, but also applies to your current omap/fixes. arch/arm/mach-omap2/cpuidle34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 4bf6e6e..2e0fa5a 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include linux/sched.h #include linux/cpuidle.h +#include linux/export.h #include plat/prcm.h #include plat/irqs.h -- 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
Re: [PATCH] ARM: OMAP3: CPUidle: include linux/export.h
* Kevin Hilman khil...@ti.com [07 15:23]: The CPUidle use THIS_MODULE, so needs linux/export.h Signed-off-by: Kevin Hilman khil...@ti.com --- Tony, one more for omap/fixes. This one applies to Linus' master branch, but also applies to your current omap/fixes. Thanks, applying into fixes. Looks like I did not grep for THIS_MODULE.. Tony arch/arm/mach-omap2/cpuidle34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 4bf6e6e..2e0fa5a 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include linux/sched.h #include linux/cpuidle.h +#include linux/export.h #include plat/prcm.h #include plat/irqs.h -- 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: [RFC] omap: mux: add support for selecting mpu_irq for each wakeup pad
Tero Kristo t-kri...@ti.com writes: By default all registered pads will trigger mpu_irqs[0]. Now there is an API for selecting used mpu_irq on pad basis, which can be used to trigger different irq handlers for different pads in the same hwmod. Each pad that requires its interrupt to be re-routed this way must have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq). Signed-off-by: Tero Kristo t-kri...@ti.com FWIW, I like this approach. 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: [GIT PULL] omap fixes for v3.2 merge window breakage
* Tony Lindgren t...@atomide.com [07 13:12]: * Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]: Arnd, Don't pull this - there's yet more crap in OMAP to be fixed before these go to mainline. OMAP3 is severely broken at the moment with, to put it bluntly, totally fucked up OMAP hwmod code, and should be fixed *now* by folk before this pull request. The fixes are damned trivial I expect even Tony can fix it without reference to Paul. ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Sounds like the above patch already queued should fix the issues you are seeing with hwmod? Or do you still have other issues you're having? Sounds like all Russell's issues are all dealt with: http://marc.info/?l=linux-arm-kernelm=132070787220812w=2 Arnd, if you have not pulled yet, Kevin just posted one more export.h fix for THIS_MODULE for cpuidle. I'll add that patch into fixes, and will post a new pull request. 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
[GIT PULL] updated omap fixes for v3.2 merge window breakage
Hi Arnd, If you did not pull yet, please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This is an updated version of an earlier pull request at: http://marc.info/?l=linux-arm-kernelm=132069904817116w=2 With one additional fix for cpuidle export.h include found by Kevin and missed in the earlier greps. Regards, Tony The following changes since commit 32aaeffbd4a7457bf2f7448b33b5946ff2a960eb: Linus Torvalds (1): Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/.../paulg/linux are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Abhilash K V (1): ARM: OMAP: AM35x: remove hwmods that aren't generic Archit Taneja (1): ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields Axel Lin (3): ARM: OMAP2+: l3-noc: Include linux/module.h ARM: OMAP: dmtimer: Include linux/module.h ARM: OMAP: omap_device: Include linux/export.h Balaji T K (2): ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFF ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properly Benoit Cousson (2): ARM: OMAP2+: clock data: Remove redundant timer clkdev ARM: OMAP2+: timer: Remove omap_device_pm_latency Bjarne Steinsbo (1): ARM: OMAP: usb: musb: OMAP: Delete unused function Charulatha V (1): ARM: OMAP3: PM: fix pwrdm_post_transition call sequence Jarkko Nikula (2): MAINTAINERS: Update linux-omap git repository ARM: OMAP1: Remove unused omap-alsa.h Jon Hunter (3): ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK ARM: OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices Kevin Hilman (1): ARM: OMAP3: CPUidle: include linux/export.h Laurent Pinchart (1): ARM: OMAP: I2C: Fix omap_register_i2c_bus() return value on success Mike Turquette (3): ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate ARM: OMAP3+: dpll: assign clk rate from rounded rate during rate set Paul Walmsley (4): ARM: OMAP4460: Clock: Adding support for 4460 specific clocks ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Peter Ujfalusi (1): ARM: OMAP2+: devices: Fixes for McPDM Sanjeev Premi (1): ARM: OMAP: Fix errors and warnings when building for one board Thomas Weber (1): ARM: OMAP: Devkit8000: Remove double omap_mux_init_gpio Tomi Valkeinen (1): ARM: OMAP: change get_context_loss_count ret value to int Tony Lindgren (7): Merge branch 'omap_clock_fixes_3.2' of git://git.pwsan.com/linux-2.6 into fixes Merge branch 'prcm_scm_misc_fixes_3.2' of git://git.pwsan.com/linux-2.6 into fixes Merge branch 'for_3.2/pm-cleanup-2' of git://github.com/khilman/linux-omap-pm into fixes ARM: OMAP1: Fix warnings about enabling 32 KiHz timer ARM: OMAP2: Fix H4 matrix keyboard warning ARM: OMAP: Fix export.h or module.h includes Merge branch 'fixes-modulesplit' into fixes MAINTAINERS|2 +- arch/arm/mach-omap1/board-palmz71.c|1 - arch/arm/mach-omap1/pm.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-generic.c|8 ++ arch/arm/mach-omap2/board-h4.c | 122 +++- arch/arm/mach-omap2/clkt_dpll.c| 51 ++--- arch/arm/mach-omap2/clock.h|2 + arch/arm/mach-omap2/clock2420_data.c | 12 -- arch/arm/mach-omap2/clock2430_data.c | 12 -- arch/arm/mach-omap2/clock3xxx_data.c | 12 -- arch/arm/mach-omap2/clock44xx.h|7 + arch/arm/mach-omap2/clock44xx_data.c | 43 --- arch/arm/mach-omap2/cpuidle34xx.c |1 + arch/arm/mach-omap2/devices.c | 17 +--- arch/arm/mach-omap2/dpll3xxx.c |9 +- arch/arm/mach-omap2/dpll44xx.c | 69 +++ arch/arm/mach-omap2/dsp.c |1 + arch/arm/mach-omap2/hsmmc.c| 16 +-- arch/arm/mach-omap2/id.c |5 +- .../include/mach/ctrl_module_pad_core_44xx.h |8 +- arch/arm/mach-omap2/io.c |6 + arch/arm/mach-omap2/mailbox.c |1 + arch/arm/mach-omap2/omap-iommu.c |1 + arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 ++-
Re: [GIT PULL] omap fixes for v3.2 merge window breakage
On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [07 13:12]: * Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]: Arnd, Don't pull this - there's yet more crap in OMAP to be fixed before these go to mainline. OMAP3 is severely broken at the moment with, to put it bluntly, totally fucked up OMAP hwmod code, and should be fixed *now* by folk before this pull request. The fixes are damned trivial I expect even Tony can fix it without reference to Paul. ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Sounds like the above patch already queued should fix the issues you are seeing with hwmod? Or do you still have other issues you're having? Sounds like all Russell's issues are all dealt with: http://marc.info/?l=linux-arm-kernelm=132070787220812w=2 Arnd, if you have not pulled yet, Kevin just posted one more export.h fix for THIS_MODULE for cpuidle. I'll add that patch into fixes, and will post a new pull request. Arnd isn't around much at the moment. I've forwarded your request to Linus already, so adding to it may not go down too well. -- 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: [GIT PULL] omap fixes for v3.2 merge window breakage
On Tue, Nov 08, 2011 at 12:42:14AM +, Russell King - ARM Linux wrote: On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [07 13:12]: * Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]: Arnd, Don't pull this - there's yet more crap in OMAP to be fixed before these go to mainline. OMAP3 is severely broken at the moment with, to put it bluntly, totally fucked up OMAP hwmod code, and should be fixed *now* by folk before this pull request. The fixes are damned trivial I expect even Tony can fix it without reference to Paul. ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Sounds like the above patch already queued should fix the issues you are seeing with hwmod? Or do you still have other issues you're having? Sounds like all Russell's issues are all dealt with: http://marc.info/?l=linux-arm-kernelm=132070787220812w=2 Arnd, if you have not pulled yet, Kevin just posted one more export.h fix for THIS_MODULE for cpuidle. I'll add that patch into fixes, and will post a new pull request. Arnd isn't around much at the moment. I've forwarded your request to Linus already, so adding to it may not go down too well. For the avoidance of doubt, as you've already updated it leave it as-is. -- 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: Pet Peaves about Platform code, and arch_reset
* Russell King - ARM Linux li...@arm.linux.org.uk [06 05:18]:
Here's a list of my peaves about current platform code - which are
causing me great issue when trying to clean up the arch_reset() stuff:
1. Lack of trailing ',' on structure initializers
This makes it much harder to add additional initializers at the end
of existing initializers, and increases the risks of conflicts being
caused due to more lines having to be modified.
(This won't work directly because the tabs have been converted to space.
The empty-looking [] contain a space plus a tab.)
$ grep '[ ][ ]*\.[[:alnum:]_][[:alnum:]_]*[ ]*=[
]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm -r|wc -l
768
$ grep '[ ][ ]*\.[[:alnum:]_][[:alnum:]_]*[ ]*=[
]*[[:alnum:]_{][[:alnum:]_|()}]*[^,]$' arch/arm/*omap* -r|wc -l
325
Note that this is _far_ too big a problem - and trivial - to fix in
a set of silly churn generating patches - it's a problem to be fixed
as a part of _other_ changes to the files.
But most importantly _stop_ introducing versions of this problem.
Sounds like we need a spatch for this issue?
2. Lack of consistent formatting for structure initializers within a
mach- subdirectory. Some use tabs to align the '=' sign. Others
use one space. This makes a repeated paste of a new initializer
mismatch the rest of the formatting of the structure.
I _really_ don't care to fix the new initializer I'm introducing to
match the random formatting within a subdirectory.
This too could be fixes up using spatch?
3. Files containing one data structure or function are quite an annoyance
when trying to do something like move arch_reset() out of the header
file into the platform .c code; this requires creating yet another
file containing one function, or consolidating the platform code
together first. I've fixed clps711x for that (so I can convert it),
but left others.
4. People who think that include files must be stored under a directory
with 'include' somewhere mentioned in its path. This is a big one
and a *REAL* hate. Include files _private_ to a group of source files
in a directory should live in the same directory as those files.
For instance, this should be zero because the 'map_io' function should
not be exported outside of the arch/arm/mach-* subdirectory:
$ grep -l map_io arch/arm/mach-*/include/mach/*.h | wc -l
21
Let's look at some specific cases:
$ grep omap15xx_map_io arch/arm/mach-omap1 arch/arm/plat-omap/ -r
arch/arm/mach-omap1/board-innovator.c: omap15xx_map_io();
arch/arm/mach-omap1/board-palmte.c: .map_io = omap15xx_map_io,
arch/arm/mach-omap1/board-palmz71.c:.map_io = omap15xx_map_io,
arch/arm/mach-omap1/board-voiceblue.c: .map_io = omap15xx_map_io,
arch/arm/mach-omap1/io.c:void __init omap15xx_map_io(void)
arch/arm/mach-omap1/board-palmtt.c: .map_io = omap15xx_map_io,
arch/arm/mach-omap1/board-fsample.c:omap15xx_map_io();
arch/arm/mach-omap1/board-sx1.c:.map_io = omap15xx_map_io,
arch/arm/mach-omap1/board-ams-delta.c: .map_io = omap15xx_map_io,
arch/arm/plat-omap/include/plat/io.h:void omap15xx_map_io(void);
arch/arm/plat-omap/include/plat/io.h:static inline void omap15xx_map_io(void)
What is the point of the omap15xx_map_io prototype being is a
_completely_ different place to where it is defined?
The problem is where do I put a function prototype for omap1_restart()
amongst these header files for OMAP1 board files to pick up? Better
still, don't tell me, but fix this stuff so that OMAP1 private stuff
is in a 'common.h' or 'board.h' header file in arch/arm/mach-omap1.
Yeah we should add arch/arm/mach-omap1/common.h for this.
$ grep s5pv210_init_irq arch/arm -r
arch/arm/mach-s5pv210/mach-aquila.c:.init_irq =
s5pv210_init_irq,
arch/arm/mach-s5pv210/mach-torbreck.c: .init_irq =
s5pv210_init_irq,
arch/arm/mach-s5pv210/mach-goni.c: .init_irq = s5pv210_init_irq,
arch/arm/mach-s5pv210/cpu.c:void __init s5pv210_init_irq(void)
arch/arm/mach-s5pv210/mach-smdkc110.c: .init_irq =
s5pv210_init_irq,
arch/arm/mach-s5pv210/mach-smdkv210.c: .init_irq =
s5pv210_init_irq,
arch/arm/plat-samsung/include/plat/s5pv210.h:extern void
s5pv210_init_irq(void);
Again, what is the point of this lack of locality? And more-over,
where the hell do I put a prototype for my new s5pv210_restart()
which is in arch/arm/mach-s5pv210/cpu.c ? Again, don't tell me but
fix stuff so that the function prototypes etc are closer to their
definitions and uses.
There is no excuse for this kind of crap, other than people being
sheep and following idiotic and rediculous ideas like include files
must be under a directory called include.
The arch_reset() branch, when published, will end with
Re: [GIT PULL] omap fixes for v3.2 merge window breakage
* Russell King - ARM Linux li...@arm.linux.org.uk [07 16:10]: On Tue, Nov 08, 2011 at 12:42:14AM +, Russell King - ARM Linux wrote: On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [07 13:12]: * Russell King - ARM Linux li...@arm.linux.org.uk [07 12:54]: Arnd, Don't pull this - there's yet more crap in OMAP to be fixed before these go to mainline. OMAP3 is severely broken at the moment with, to put it bluntly, totally fucked up OMAP hwmod code, and should be fixed *now* by folk before this pull request. The fixes are damned trivial I expect even Tony can fix it without reference to Paul. ARM: OMAP3: hwmod: fix variant registration and remove SmartReflex from common list Sounds like the above patch already queued should fix the issues you are seeing with hwmod? Or do you still have other issues you're having? Sounds like all Russell's issues are all dealt with: http://marc.info/?l=linux-arm-kernelm=132070787220812w=2 Arnd, if you have not pulled yet, Kevin just posted one more export.h fix for THIS_MODULE for cpuidle. I'll add that patch into fixes, and will post a new pull request. Arnd isn't around much at the moment. I've forwarded your request to Linus already, so adding to it may not go down too well. OK, well looks like the earlier version got pulled in. For the avoidance of doubt, as you've already updated it leave it as-is. Let's leave that for another series then. 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: [GIT PULL] updated omap fixes for v3.2 merge window breakage
* Tony Lindgren t...@atomide.com [07 15:51]: Hi Arnd, If you did not pull yet, please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This is an updated version of an earlier pull request at: http://marc.info/?l=linux-arm-kernelm=132069904817116w=2 With one additional fix for cpuidle export.h include found by Kevin and missed in the earlier greps. Never mind, looks like the earlier version is already merged. Let's deal with this fix in a separate series. 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 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
Hi Vishwa, Vishwanath BS vishwanath...@ti.com writes: The folowing patch series provides IO Daisychain feature via omap hwmod mux framework. The series looks OK at first glance, but needs a refresh against current mainline. Can you refresh this against Tony's 'fixes' branch and re-test. I tested this on OMAP3430/n900 and noticed that it no longer hit off mode from idle. IOW, If I enable UART timeouts and then enable off mode, I don't actually ever hit off during idle. However, if I do a suspend/resume I see it hits off mode, then subsequent attempts to hit off during idle work. Can you investigate this? 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: Simple GPMC device driver with basic User application
Hi Philip, On Fri, Nov 4, 2011 at 7:48 PM, Philip Balister phi...@balister.org wrote: On 11/03/2011 03:25 PM, Tony Lindgren wrote: * James angweiy...@gmail.com [111023 18:13]: Dear all, I'm learning embedded linux development and need help on my task. I'm trying to communicate with a FPGA via the GPMC bus on my Overo FE board and need assistance with writing a simple device driver test application that uses the GPMC bus to read write a WORD size data and also a BLOCK of WORD data to the FPGA. The FPGA-OMAP3530 will be use synchronous read/write over the 16-bit datapath and CS 6. The GPMC bus is shared with an Ethernet chip and NAND chip as per Gumstix COM + TOBI/Chestnut design and these standard devices must still work as per norm. I've been searching via GMANE for similar questions but some are pointing to non-existence archives. I believe I have to develop a kernel device driver to register the FPGA and from which will expose a device node for the test application. or is there a generic GPMC driver that does it? Can someone share with me similar layout and code so that I can base my learning from a starting point? Many thanks in adv. Please take a look at the various arch/arm/mach-omap2/gpmc-*.c files. The biggest pain is to get the timings right. Also take a look at: https://github.com/balister/linux-omap-philip/commits/e100-2.6.38-2 Philip I've been reading the codes from your e100-2.6.38-2 repo as suggested by your earlier replies to me in Gumstix Mailing List. (^^,) In usrp1_e_init() inside board-overo.c, GPMC_CS_CONFIG7 for both CS4 and CS6 are both written with 0x00. I couldn't understand the background/why behind this line of code as the Use-case in the TRM writes the base address of the device to it. Do you have some timing diagram or documents that explains the data flow / interactions / protocol between the FPGA and Overo as reference to the codes? Many many thanks in adv. -- Regards, James -- 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
[PATCH] arm: omap2: fix build failure
From: Ming Lei tom.leim...@gmail.com The patch fixes the compile failure: CC arch/arm/mach-omap2/cpuidle34xx.o arch/arm/mach-omap2/cpuidle34xx.c:317:12: error: 'THIS_MODULE' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/cpuidle34xx.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 make: *** Waiting for unfinished jobs Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/cpuidle34xx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 1fe35c2..158c17e 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include linux/sched.h #include linux/cpuidle.h +#include linux/module.h #include plat/prcm.h #include plat/irqs.h -- 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
[PATCH] arm: omap2: select ARM_AMBA if OMAP3_EMU is defined
From: Ming Lei tom.leim...@gmail.com This patch selects ARM_AMBA if OMAP3_EMU is defined because OC_ETM depends on ARM_AMBA, so fix the link failure[1]. [1], arch/arm/kernel/built-in.o: In function `etm_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etm_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined reference to `amba_driver_unregister' arch/arm/kernel/built-in.o: In function `etm_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined reference to `amba_release_regions' arch/arm/mach-omap2/built-in.o: In function `emu_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62: undefined reference to `amba_device_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63: undefined reference to `amba_device_register' make: *** [.tmp_vmlinux1] Error 1 making modules Signed-off-by: Ming Lei tom.leim...@gmail.com --- 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 5034147..e1293aa 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -334,6 +334,7 @@ config MACH_OMAP4_PANDA config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 + select ARM_AMBA select OC_ETM help Say Y here to enable debugging hardware of omap3 -- 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
[PATCH] ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support
Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified
to use timer-func_base OCP_CFG should not use this wrapper anymore.
Instead use __raw_writel() directly and use timer-io_base instead
to write to OCP_CFG.
The timer-sys_stat is valid only if timer-revision is 1. In the
context restore function make this correction.
Save the contexts and loss count when timer is stopped.
Also, disable the clock. Else, clock usecount would become imbalanced.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Branch: master
Linux 3.2-rc1
arch/arm/plat-omap/dmtimer.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index af3b92b..f042c82 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -80,9 +80,9 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer
*timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_OFFSET,
- timer-context.tiocp_cfg);
- if (timer-revision 1)
+ __raw_writel(timer-context.tiocp_cfg,
+ timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+ if (timer-revision == 1)
__raw_writel(timer-context.tistat, timer-sys_stat);
__raw_writel(timer-context.tisr, timer-irq_stat);
@@ -357,6 +357,21 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
__omap_dm_timer_stop(timer, timer-posted, rate);
+ if (timer-loses_context) {
+ if (timer-get_context_loss_count)
+ timer-ctx_loss_count =
+ timer-get_context_loss_count(timer-pdev-dev);
+ }
+
+ /*
+* Since the register values are computed and written within
+* __omap_dm_timer_stop, we need to use read to retrieve the
+* context.
+*/
+ timer-context.tclr =
+ omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
+ timer-context.tisr = __raw_readl(timer-irq_stat);
+ omap_dm_timer_disable(timer);
return 0;
}
EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
--
1.7.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
Re: [PATCH] ARM: omap4: prm: Fix up swapped offset macros
/* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL0x #define OMAP4_PM_PWSTST 0x0004 In fact these defines were already defined correctly later (with a slightly different name): /* PRM.DEVICE_PRM register offsets */ [...] #define OMAP4_PRM_RSTST_OFFSET 0x0004 #define OMAP4430_PRM_RSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x0004) #define OMAP4_PRM_RSTTIME_OFFSET0x0008 #define OMAP4430_PRM_RSTTIME OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x0008) I don't know where these defines are used, but we'd better use the existing ones. Yes, it looks like it makes sense to completely get rid of these and instead use the auto-generated ones. I see there are these multiple defines for omap3 too, maybe its best to get rid of them for omap3 too? 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
[PATCH] OMAP2+: Fix Compilation error on current mainline
Patch to fix below compilation error on latest mainline commit b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig. arch/arm/mach-omap2/omap_l3_noc.c:250: error: 'THIS_MODULE' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/omap_l3_noc.o] Error 1 Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/omap_l3_noc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_l3_noc.c b/arch/arm/mach-omap2/omap_l3_noc.c index c8b1bef..c2cc196 100644 --- a/arch/arm/mach-omap2/omap_l3_noc.c +++ b/arch/arm/mach-omap2/omap_l3_noc.c @@ -26,6 +26,7 @@ #include linux/interrupt.h #include linux/kernel.h #include linux/slab.h +#include linux/module.h #include omap_l3_noc.h -- 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
Re: [PATCH] OMAP2+: Fix Compilation error on current mainline
On Tue, Nov 8, 2011 at 11:58 AM, Govindraj.R govindraj.r...@ti.com wrote: Patch to fix below compilation error on latest mainline commit b32fc0a0629bf5894b35f33554c118aacfd0d1e2 with omap2plus_defconfig. arch/arm/mach-omap2/omap_l3_noc.c:250: error: 'THIS_MODULE' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/omap_l3_noc.o] Error 1 Signed-off-by: Govindraj.R govindraj.r...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@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: [PATCH] ARM: omap4: prm: Fix up swapped offset macros
On Tuesday 08 November 2011 11:52 AM, Rajendra Nayak wrote: /* OMAP4 specific register offsets */ #define OMAP4_RM_RSTCTRL 0x -#define OMAP4_RM_RSTTIME 0x0004 -#define OMAP4_RM_RSTST 0x0008 +#define OMAP4_RM_RSTST 0x0004 +#define OMAP4_RM_RSTTIME 0x0008 #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST 0x0004 In fact these defines were already defined correctly later (with a slightly different name): /* PRM.DEVICE_PRM register offsets */ [...] #define OMAP4_PRM_RSTST_OFFSET 0x0004 #define OMAP4430_PRM_RSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x0004) #define OMAP4_PRM_RSTTIME_OFFSET 0x0008 #define OMAP4430_PRM_RSTTIME OMAP44XX_PRM_REGADDR(OMAP4430_PRM_DEVICE_INST, 0x0008) I don't know where these defines are used, but we'd better use the existing ones. Yes, it looks like it makes sense to completely get rid of these and instead use the auto-generated ones. I see there are these multiple defines for omap3 too, maybe its best to get rid of them for omap3 too? Looking at it a little more closely, I now see why some of these are needed. #define OMAP4_PM_PWSTCTRL 0x #define OMAP4_PM_PWSTST 0x0004 These seem to be needed because the autogen output throws out offsets with the individual domain names embedded, which can't be used in generic powerdomain code, and since all of them are the same, the ones with the individual domain names never get used. Maybe a case for the autogen script updates to get rid of all those and just generate something like the above. Should give some good -ve diffstat :) #define OMAP4_RM_RSTCTRL0x #define OMAP4_RM_RSTTIME0x0004 These don't seem to be used at all. #define OMAP4_RM_RSTST 0x0008 The only instance of this being used I see is in omap_prcm_get_reset_sources() and seems completely wrong as its using a omap2/3 api (omap2_prm_read_mod_reg()) on omap4. 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
[GIT PULL] hwspinlock fixes for 3.2
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git fixes
To get two hwspinlock fixes from Axel.
There was a third, module.h split merge-related fix from Axel that I
dropped because I saw Paul picked it up in his pull request.
Thanks,
Ohad.
The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:
Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git fixes
Axel Lin (2):
hwspinlock: Don't return a value in __hwspin_unlock
hwspinlock/u8500: fix build error due to undefined label
drivers/hwspinlock/u8500_hsem.c |6 ++
include/linux/hwspinlock.h |1 -
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 143461a..a120f14 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -108,10 +108,8 @@ static int __devinit u8500_hsem_probe(struct
platform_device *pdev)
return -ENODEV;
io_base = ioremap(res-start, resource_size(res));
- if (!io_base) {
- ret = -ENOMEM;
- goto free_state;
- }
+ if (!io_base)
+ return -ENOMEM;
/* make sure protocol 1 is selected */
val = readl(io_base + HSEM_CTRL_REG);
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 08a2fee..aad6bd4 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -118,7 +118,6 @@ int __hwspin_trylock(struct hwspinlock *hwlock,
int mode, unsigned long *flags)
static inline
void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
{
- return 0;
}
static inline int hwspin_lock_get_id(struct hwspinlock *hwlock)
--
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: [GIT PULL] ARM: OMAP: DSS hwmod/reset fixes for 3.2
On Fri, 4 Nov 2011, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [111006 16:33]: Hi Tony, The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 hwmod_dss_fixes_3.2 Looks like you should take a look at the merge conflicts with this one, maybe rebase it on 994c0e992522c123298b4a91b72f5e67ba2d1123. Do you want this series for 3.2-rc or 3.3 at this point? - 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: [GIT PULL v3] ARM: OMAP: Cortex-A9 PERIPHCLK node for 3.2
On Fri, 4 Nov 2011, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [111010 17:09]: The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 clock_hwmod_devel_3.2 This pull request drops the EHCI/OHCI hwmod data due to some inconsistencies that were just found in the data. Santosh Shilimkar (1): ARM: OMAP4: clock: Add CPU local timer clock node. arch/arm/mach-omap2/clock44xx_data.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) Should this be pulled into fixes for v3.2 -rc cycle? Santosh would be the right person to ask. Santosh, is anything broken in 3.2 if this patch doesn't get merged in -rc? Or is it just a feature which could be added in 3.3? - 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
