Re: [PATCH] [ARM] omap: resource: Make resource_refresh() thread safe.
On Fri, Sep 11, 2009 at 2:10 PM, Kevin
Hilman wrote:
> Mike Turquette writes:
>
>> Kevin Hilman wrote:
>>> Mike Chan writes:
>>>
Need to lock the res_mutex when traversing the res_list.
Signed-off-by: Mike Chan
>>>
>>> Looks good, thanks.
>>
>> This patch causes a hang for me when transitioning to OFF mode. This
>> was tested on the Android 2.6.29 tree and is 100% reproducible. The
>> moment a user runs 'echo 1 > /sys/power/enable_off_mode' the board
>> hangs without any further output.
>>
>> Reverting the patch allows me to hit OFF mode again. I haven't yet
>> tested this on vanilla 2.6.29 or latest L-O.
>>
>
> OK, reverting this in both PM branches. Looks like a deadlock to me,
> as update_resource_level() must cause a call to something else that
> takes the mutex.
>
Good catch, I see the deadlock are in the change_level function
pointers. Where set_xxx will call resource_request() or
resource_release() => resource_lookup() which grabs the list mutex we
grabbed in resource_refresh().
Thoughts on changing the mutex to a RW semaphore?
-- Mike
> Kevin
>
>>
>>> Pushed to PM branch and pm-2.6.29.
>>>
>>> Kevin
>>>
---
arch/arm/plat-omap/resource.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
index 25072cd..4631912 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -234,11 +234,13 @@ int resource_refresh(void)
struct shared_resource *resp = NULL;
int ret = 0;
+ down(&res_mutex);
list_for_each_entry(resp, &res_list, node) {
ret = update_resource_level(resp);
if (ret)
break;
}
+ up(&res_mutex);
return ret;
}
--
1.5.4.5
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] OMAP1/2/3/4: DEBUG_LL run time detection
Vikram Pandita writes:
> This patch cleans up the DEBUG_LL infrastructure for omap boards.
>
> The decision of finding the physical address of debug uart is done
> at runtime now, making possible to use a single defconfig for
> multiple boards.
Yes! I've been wishing for this feature for some time. Thanks for
getting the ball rolling here. This will be huge maintenacne and test
win in being able to have a single kernel for all the OMAP3 boards.
> This patch gets rid of menuconfig options of choosing low level debug uarts.
>
> Changes are:
> 1) Implement get_uart_[virt_]base in arch/arm/boot/compressed/misc.c
> These functions do a run time detection of debug uart address
>
> 2) arch/arm/boot/compressed/head.S
> calls get_uart_base to get the phy address and stores in r13^ user mode ARM
> reg
> calls get_uart_virt_base to get the virtual address and stores in r14^ user
> mode ARM reg
Hmm, we'll need to run this new register calling convention exention
past RMK. Not sure what he'll think about it.
You should also update comments in 'Kernel startup entry point.'
secion of arch/arm/kernel/head.S describing the additional registers
being used.
Also, why did you pick user-mode regs? Using normal regs would
simplify the code.
What about just using r3= r4=bphys-base r4=virt-base, r5=shift,
where indicates that the UART values are valid.
Then first thing in arch/arm/kernel/head.S, copy these to global
variables.
Then the debug-macros.S for OMAP just uses the global variables.
In any case, more comments inlined below...
> 3) arch/arm/plat-omap/include/mach/debug-macro.S: addruart
> This function gets the debug uart phy/virtual address from r13^ and r14^
> respectively
> Stores them in a variables, __phy_uart_addr and __virt_uart_addr
> so that subsiquent access get the address from variables
>
> Changes have been tested on:
> SDP3430: UART1
> Zoom1: UART3
> Beagle: UART3
> Zoom2: External Uart
>
> Signed-off-by: Vikram Pandita
> ---
> arch/arm/boot/compressed/head.S | 17
> arch/arm/boot/compressed/misc.c | 108
> -
Note that you're adding OMAP specific stuff to files that are used on
every ARM platform. Care must be taken to not affect other platforms.
The early asm stuff can probably be done in head-omap.S.
You may even consider doing all of it with just a table in the asm
code and avoid touching common C code. Otherwise, it should be
#ifdef'd for OMAP and called from OMAP specific code.
> arch/arm/plat-omap/Kconfig| 16
> arch/arm/plat-omap/include/mach/debug-macro.S | 74 +
> arch/arm/plat-omap/include/mach/uncompress.h | 22 +++---
> 5 files changed, 176 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 4515728..7fcc21a 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -277,6 +277,20 @@ not_relocated: mov r0, #0
> blo 1b
> add sp, r1, #128@ relocate the stack
>
> + mov r9, r0
> +
> + bl get_uart_base @ get uart phy address
> + adr r2, __dummy
> + str r0, [r2]@save uart phy adder in memory
> + ldm r2, {r13}^ @save phyadder in usermode reg
> +
> + bl get_uart_virt_base @ get uart virtual address
> + adr r2, __dummy
> + str r0, [r2]@save uart phy adder in memory
> + ldm r2, {r14}^ @save phyadder in usermode reg
> +
> + mov r0, r9
> +
> bl cache_clean_flush
> add pc, r5, r0 @ call relocation code
>
> @@ -303,6 +317,9 @@ LC0: .word LC0 @ r1
> LC1: .word reloc_end - reloc_start
> .size LC0, . - LC0
>
> + .type __dummy, #object
> +__dummy: .word __dummy
> +
> #ifdef CONFIG_ARCH_RPC
> .globl params
> params: ldr r0, =params_phys
> diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
> index 17153b5..0758656 100644
> --- a/arch/arm/boot/compressed/misc.c
> +++ b/arch/arm/boot/compressed/misc.c
> @@ -22,6 +22,15 @@ unsigned int __machine_arch_type;
> #include /* for size_t */
> #include /* for NULL */
> #include
> +#include
> +/* TODO:
> + * Include of this header is not working.
> + * Gives Error: undefined reference to `omap_rev'
> + * This header is needed for constant:
> + * ZOOM2_EXT_QUART_VIRT = 0xFB00
> + * ZOOM2_EXT_QUART_PHYS = 0x1000
> + */
> +/* #include */
>
> #ifdef STANDALONE_DEBUG
> #define putstr printf
> @@ -316,6 +325,103 @@ static void error(char *x)
>
> #ifndef STANDALONE_DEBUG
>
> +u32 *omap_uart_debug
Re: [PATCH v2 1/2] OMAP: Zoom2: Add DEBUG_LL interface using Quart
Pandita, Vikram wrote:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
This patch adds DEBUG_LL interface for Zoom2 board.
The low level debug uart now points corrctly to External Quad uart
controller on detachable debug board.
The Quad uart is available over GPMC chip select with physical address
0x1000.
This physical address has been mapped to virtual address 0xFB00
as per static mapping.
I see you dropped the UPF_IOREMAP flag. Why do we need a static
mapping here? The early access will be taken care of by the .phys_io
field of the mach_desc, no?
Step 1:
The first early mapping happens with phys_io. Just for debug uart access.
Step 2:
This is over-written by mapping done by omap2_map_common_io -> iotable_init
I removed the flag UPF_IOREMAP for the serial 8250 driver.
If UPF_IOREMAP flag is given, then serial driver will do yet one more mapping,
which is already done by step 2.
Hence the flag is no longer needed for serial port mapping.
OK, thanks for clarifying. After reviewing your DEBUG_LL rework, I also
notice that it requires a static mapping too.
Kevin
Kevin
This patch is adapted from a version by Erik Gilling:
http://android.git.kernel.org/?p=kernel/omap.git;
a=commit;h=e9d72efdd88877d2d6ea74a08983ace0dcc771d3
Signed-off-by: Vikram Pandita
Cc: Erik Gilling
---
arch/arm/mach-omap2/board-zoom-debugboard.c |5 +++--
arch/arm/mach-omap2/board-zoom2.c | 19 +--
arch/arm/plat-omap/include/mach/io.h|6 ++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-
debugboard.c
index 1f13e2a..70a4bba 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -82,9 +82,10 @@ static inline void __init zoom2_init_smsc911x(void)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase= 0x1000,
+ .membase= IOMEM(ZOOM2_EXT_QUART_VIRT),
+ .mapbase= ZOOM2_EXT_QUART_PHYS,
.irq= OMAP_GPIO_IRQ(102),
- .flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+ .flags = UPF_BOOT_AUTOCONF|UPF_SHARE_IRQ,
.irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
.iotype = UPIO_MEM,
.regshift = 1,
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 324009e..467e961 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -19,10 +19,12 @@
#include
#include
+#include
#include
#include
#include
+#include
#include "mmc-twl4030.h"
@@ -269,15 +271,28 @@ static void __init omap_zoom2_init(void)
usb_musb_init();
}
+static struct map_desc zoom2_io_desc[] __initdata = {
+ {
+ .virtual= ZOOM2_EXT_QUART_VIRT,
+ .pfn= __phys_to_pfn(ZOOM2_EXT_QUART_PHYS),
+ .length = ZOOM2_EXT_QUART_SIZE,
+ .type = MT_DEVICE
+ }
+};
+
static void __init omap_zoom2_map_io(void)
{
omap2_set_globals_343x();
+
+ /* Map external quad UART virt to phy mapping */
+ iotable_init(zoom2_io_desc, ARRAY_SIZE(zoom2_io_desc));
+
omap2_map_common_io();
}
MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
- .phys_io= 0x4800,
- .io_pg_offst= ((0xd800) >> 18) & 0xfffc,
+ .phys_io= ZOOM2_EXT_QUART_PHYS,
+ .io_pg_offst= ((ZOOM2_EXT_QUART_VIRT) >> 18) & 0xfffc,
.boot_params= 0x8100,
.map_io = omap_zoom2_map_io,
.init_irq = omap_zoom2_init_irq,
diff --git a/arch/arm/plat-omap/include/mach/io.h
b/arch/arm/plat-omap/include/mach/io.h
index 8d32df3..d67f06c 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -169,6 +169,12 @@
#define DSP_MMU_34XX_VIRT 0xe200
#define DSP_MMU_34XX_SIZE SZ_4K
+/* Map External Quad UART for Zoom2 board */
+#define ZOOM2_EXT_QUART_PHYS 0x1000 /* PHY address if fixed */
+#define ZOOM2_EXT_QUART_PHY_TO_VIRT_OFF0xEB00
+#define ZOOM2_EXT_QUART_VIRT 0xFB00
+#define ZOOM2_EXT_QUART_SIZE SZ_16
+
/*
*
* Omap4 specific IO mapping
--
1.6.3.3.334.g916e1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag
>-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin >Hilman >Sent: Friday, September 11, 2009 4:09 PM >To: Pandita, Vikram >Cc: linux-omap@vger.kernel.org; Tony Lindgren >Subject: Re: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag > >"Pandita, Vikram" writes: > >> Tony/Kevin >> Any feedback on this patch for removal of SYSFS_DEPRECATED flag? >> >> Reference: >> http://marc.info/?l=linux-omap&m=125011227920673&q=raw > >I already ack'd: > > http://marc.info/?l=linux-omap&m=125011754929777&w=2 What is the next step? Who will be lining this patch for upstream? >... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] OMAP: Zoom2: Add DEBUG_LL interface using Quart
>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>
>> This patch adds DEBUG_LL interface for Zoom2 board.
>> The low level debug uart now points corrctly to External Quad uart
>> controller on detachable debug board.
>>
>> The Quad uart is available over GPMC chip select with physical address
>> 0x1000.
>>
>> This physical address has been mapped to virtual address 0xFB00
>> as per static mapping.
>
>I see you dropped the UPF_IOREMAP flag. Why do we need a static
>mapping here? The early access will be taken care of by the .phys_io
>field of the mach_desc, no?
Step 1:
The first early mapping happens with phys_io. Just for debug uart access.
Step 2:
This is over-written by mapping done by omap2_map_common_io -> iotable_init
I removed the flag UPF_IOREMAP for the serial 8250 driver.
If UPF_IOREMAP flag is given, then serial driver will do yet one more mapping,
which is already done by step 2.
Hence the flag is no longer needed for serial port mapping.
>
>Kevin
>
>> This patch is adapted from a version by Erik Gilling:
>> http://android.git.kernel.org/?p=kernel/omap.git;
>> a=commit;h=e9d72efdd88877d2d6ea74a08983ace0dcc771d3
>>
>> Signed-off-by: Vikram Pandita
>> Cc: Erik Gilling
>> ---
>> arch/arm/mach-omap2/board-zoom-debugboard.c |5 +++--
>> arch/arm/mach-omap2/board-zoom2.c | 19 +--
>> arch/arm/plat-omap/include/mach/io.h|6 ++
>> 3 files changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
>> b/arch/arm/mach-omap2/board-zoom-
>debugboard.c
>> index 1f13e2a..70a4bba 100644
>> --- a/arch/arm/mach-omap2/board-zoom-debugboard.c
>> +++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
>> @@ -82,9 +82,10 @@ static inline void __init zoom2_init_smsc911x(void)
>>
>> static struct plat_serial8250_port serial_platform_data[] = {
>> {
>> -.mapbase= 0x1000,
>> +.membase= IOMEM(ZOOM2_EXT_QUART_VIRT),
>> +.mapbase= ZOOM2_EXT_QUART_PHYS,
>> .irq= OMAP_GPIO_IRQ(102),
>> -.flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
>> +.flags = UPF_BOOT_AUTOCONF|UPF_SHARE_IRQ,
>> .irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
>> .iotype = UPIO_MEM,
>> .regshift = 1,
>> diff --git a/arch/arm/mach-omap2/board-zoom2.c
>> b/arch/arm/mach-omap2/board-zoom2.c
>> index 324009e..467e961 100644
>> --- a/arch/arm/mach-omap2/board-zoom2.c
>> +++ b/arch/arm/mach-omap2/board-zoom2.c
>> @@ -19,10 +19,12 @@
>>
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "mmc-twl4030.h"
>>
>> @@ -269,15 +271,28 @@ static void __init omap_zoom2_init(void)
>> usb_musb_init();
>> }
>>
>> +static struct map_desc zoom2_io_desc[] __initdata = {
>> +{
>> +.virtual= ZOOM2_EXT_QUART_VIRT,
>> +.pfn= __phys_to_pfn(ZOOM2_EXT_QUART_PHYS),
>> +.length = ZOOM2_EXT_QUART_SIZE,
>> +.type = MT_DEVICE
>> +}
>> +};
>> +
>> static void __init omap_zoom2_map_io(void)
>> {
>> omap2_set_globals_343x();
>> +
>> +/* Map external quad UART virt to phy mapping */
>> +iotable_init(zoom2_io_desc, ARRAY_SIZE(zoom2_io_desc));
>> +
>> omap2_map_common_io();
>> }
>>
>> MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
>> -.phys_io= 0x4800,
>> -.io_pg_offst= ((0xd800) >> 18) & 0xfffc,
>> +.phys_io= ZOOM2_EXT_QUART_PHYS,
>> +.io_pg_offst= ((ZOOM2_EXT_QUART_VIRT) >> 18) & 0xfffc,
>> .boot_params= 0x8100,
>> .map_io = omap_zoom2_map_io,
>> .init_irq = omap_zoom2_init_irq,
>> diff --git a/arch/arm/plat-omap/include/mach/io.h
>> b/arch/arm/plat-omap/include/mach/io.h
>> index 8d32df3..d67f06c 100644
>> --- a/arch/arm/plat-omap/include/mach/io.h
>> +++ b/arch/arm/plat-omap/include/mach/io.h
>> @@ -169,6 +169,12 @@
>> #define DSP_MMU_34XX_VIRT 0xe200
>> #define DSP_MMU_34XX_SIZE SZ_4K
>>
>> +/* Map External Quad UART for Zoom2 board */
>> +#define ZOOM2_EXT_QUART_PHYS0x1000 /* PHY address if
>> fixed */
>> +#define ZOOM2_EXT_QUART_PHY_TO_VIRT_OFF 0xEB00
>> +#define ZOOM2_EXT_QUART_VIRT0xFB00
>> +#define ZOOM2_EXT_QUART_SIZESZ_16
>> +
>> /*
>> *
>>
>> * Omap4 specific IO mapping
>> --
>> 1.6.3.3.334.g916e1
>>
>> --
>> 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.kerne
Re: [PATCH v2 1/2] OMAP: Zoom2: Add DEBUG_LL interface using Quart
Vikram Pandita writes:
> This patch adds DEBUG_LL interface for Zoom2 board.
> The low level debug uart now points corrctly to External Quad uart
> controller on detachable debug board.
>
> The Quad uart is available over GPMC chip select with physical address
> 0x1000.
>
> This physical address has been mapped to virtual address 0xFB00
> as per static mapping.
I see you dropped the UPF_IOREMAP flag. Why do we need a static
mapping here? The early access will be taken care of by the .phys_io
field of the mach_desc, no?
Kevin
> This patch is adapted from a version by Erik Gilling:
> http://android.git.kernel.org/?p=kernel/omap.git;
> a=commit;h=e9d72efdd88877d2d6ea74a08983ace0dcc771d3
>
> Signed-off-by: Vikram Pandita
> Cc: Erik Gilling
> ---
> arch/arm/mach-omap2/board-zoom-debugboard.c |5 +++--
> arch/arm/mach-omap2/board-zoom2.c | 19 +--
> arch/arm/plat-omap/include/mach/io.h|6 ++
> 3 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
> b/arch/arm/mach-omap2/board-zoom-debugboard.c
> index 1f13e2a..70a4bba 100644
> --- a/arch/arm/mach-omap2/board-zoom-debugboard.c
> +++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
> @@ -82,9 +82,10 @@ static inline void __init zoom2_init_smsc911x(void)
>
> static struct plat_serial8250_port serial_platform_data[] = {
> {
> - .mapbase= 0x1000,
> + .membase= IOMEM(ZOOM2_EXT_QUART_VIRT),
> + .mapbase= ZOOM2_EXT_QUART_PHYS,
> .irq= OMAP_GPIO_IRQ(102),
> - .flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
> + .flags = UPF_BOOT_AUTOCONF|UPF_SHARE_IRQ,
> .irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
> .iotype = UPIO_MEM,
> .regshift = 1,
> diff --git a/arch/arm/mach-omap2/board-zoom2.c
> b/arch/arm/mach-omap2/board-zoom2.c
> index 324009e..467e961 100644
> --- a/arch/arm/mach-omap2/board-zoom2.c
> +++ b/arch/arm/mach-omap2/board-zoom2.c
> @@ -19,10 +19,12 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> #include
> +#include
>
> #include "mmc-twl4030.h"
>
> @@ -269,15 +271,28 @@ static void __init omap_zoom2_init(void)
> usb_musb_init();
> }
>
> +static struct map_desc zoom2_io_desc[] __initdata = {
> + {
> + .virtual= ZOOM2_EXT_QUART_VIRT,
> + .pfn= __phys_to_pfn(ZOOM2_EXT_QUART_PHYS),
> + .length = ZOOM2_EXT_QUART_SIZE,
> + .type = MT_DEVICE
> + }
> +};
> +
> static void __init omap_zoom2_map_io(void)
> {
> omap2_set_globals_343x();
> +
> + /* Map external quad UART virt to phy mapping */
> + iotable_init(zoom2_io_desc, ARRAY_SIZE(zoom2_io_desc));
> +
> omap2_map_common_io();
> }
>
> MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
> - .phys_io= 0x4800,
> - .io_pg_offst= ((0xd800) >> 18) & 0xfffc,
> + .phys_io= ZOOM2_EXT_QUART_PHYS,
> + .io_pg_offst= ((ZOOM2_EXT_QUART_VIRT) >> 18) & 0xfffc,
> .boot_params= 0x8100,
> .map_io = omap_zoom2_map_io,
> .init_irq = omap_zoom2_init_irq,
> diff --git a/arch/arm/plat-omap/include/mach/io.h
> b/arch/arm/plat-omap/include/mach/io.h
> index 8d32df3..d67f06c 100644
> --- a/arch/arm/plat-omap/include/mach/io.h
> +++ b/arch/arm/plat-omap/include/mach/io.h
> @@ -169,6 +169,12 @@
> #define DSP_MMU_34XX_VIRT0xe200
> #define DSP_MMU_34XX_SIZESZ_4K
>
> +/* Map External Quad UART for Zoom2 board */
> +#define ZOOM2_EXT_QUART_PHYS 0x1000 /* PHY address if fixed */
> +#define ZOOM2_EXT_QUART_PHY_TO_VIRT_OFF 0xEB00
> +#define ZOOM2_EXT_QUART_VIRT 0xFB00
> +#define ZOOM2_EXT_QUART_SIZE SZ_16
> +
> /*
> *
>
> * Omap4 specific IO mapping
> --
> 1.6.3.3.334.g916e1
>
> --
> 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: FW: [RFC][PATCH]: Adding support for omap-serail driver
Govindraj writes: > Hi, > >> >> FWIW, as the author of much of the PM hacker in mach-omap2/serial.c, I >> agree with Tao. >> >> The only reason for the PM hackery in mach-omap2/serial.c is because >> of the limitations of the 8250 driver. >> > > I have an query, > > We have following functionality in serial.c: > 1.) Enabling and disabling uart clocks. > 2.) Adding rx wakeup capabilities. > 3.) Preparing UARTs for idle mode. > 4.) Context save and restore. > > What functionality should be retained in serial.c file? > > AFAIK currently no serial driver has incorporated their platform > specific PM functionality like context_save and restore into their > serial driver, shouldn't these things be retained into > */mach-omap2/serial.c ? Only SoC and/or board-specific settings should be done in serial.c (setup of base addresses, IRQs, DMA channels, etc.) The driver is an OMAP specific driver, but should be general enough to independent of any board/SoC specifics. IMO, all of 1-4 above above belong in the driver. Evenutally the enabling/disabling of clocks will be handled by the runtime PM layer, but the driver will have a similar enable/disable 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: [RFC] OMAP3 : PM : Handle variable length OPP tables
"Premi, Sanjeev" writes:
>> -Original Message-
>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>> Sent: Friday, September 11, 2009 12:00 AM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: [RFC] OMAP3 : PM : Handle variable length OPP tables
>>
>> "Premi, Sanjeev" writes:
>>
>> > Hi all,
>> >
>> > There is no generic function to translate an OPP to FREQ
>> and vice versa.
>> > Came across the problem while trying to submit a follow-up
>> to earlier
>> > patch for change in mpurate via bootargs.
>> >
>> > The function get_opp in resource34xx.c, but it is always
>> called with an
>> > explicit addition of MAX_VDDn_OPP e.g.
>> >
>> > opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk->rate);
>> > opp = get_opp(l3_opps + MAX_VDD2_OPP, clk->rate);
>> >
>> > This is 'addition' is required as there is no encapsulation of the
>> > MIN and MAX VDDs associated to the table.
>> >
>> > The patch below fixes this issue; buy creating a 'table' object with
>> > necessary information. It can also help in getting rid of the
>> > empty {0, 0, 0} at index 0 of each OPP table.
>> >
>> > At the moment, it does not break any functionality in
>> resource34xx.c;
>> > migration to this encapsulation can be taken as next step.
>> >
>> > This code is bare 'git-diff' for early comments. Formal
>> patch to follow...
>> >
>> > Best regards,
>> > Sanjeev
>>
>> Is the goal of the min and max fields so you could have some OPPs
>> in the table that aren't valid for some SoCs? IOW, the 'max' value
>> might be higher on newer SoCs with higher OPPs.
>
> The goal is to have get_*() functions where caller shouldn't be aware
> of the MAX_ for the table. Considering table as an object, it should
> be able to provide its own length.
>
> Reason to use min and max was to maintain current functionality as is.
> Else, simple 'length' should be sufficient.
>
>>
>> What if you want a list of OPPs, but want to remove one from the
>> middle of the list? The min/max approach doesn't work here.
>>
>> What about a also extending the struct omap_opp to have some sort of
>> valid field.
>
> This doesn't help in eliminating the addition of MAX value for each
> function call.
No it doesn't. I'm just thinking about the next step of having a more flexible
list of OPPs.
Kevin
>>
>> >
>> > diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h
>> b/arch/arm/plat-omap/include/mach/omap-pm.h
>> > index 583e540..2357784 100644
>> > --- a/arch/arm/plat-omap/include/mach/omap-pm.h
>> > +++ b/arch/arm/plat-omap/include/mach/omap-pm.h
>> > @@ -33,6 +33,20 @@ struct omap_opp {
>> > u16 vsel;
>> > };
>> >
>> > +/* struct omap_opp_table - View OPP table as an object
>> > + * @min: Minimum OPP id
>> > + * @max: Maximim OPP id
>> > + * @opps: Pointer to array defining the OPPs.
>> > + *
>> > + * An OPP table has varied length. Knowing minimum and maximum
>> > + * OPP ids allow easy traversal.
>> > + */
>> > +struct omap_opp_table {
>> > + u8 min;
>> > + u8 max;
>> > + struct omap_opp* opps;
>> > +};
>> > +
>> > extern struct omap_opp *mpu_opps;
>> > extern struct omap_opp *dsp_opps;
>> > extern struct omap_opp *l3_opps;
>> > diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
>> > index fec7d00..c90b1af 100644
>> > --- a/arch/arm/mach-omap2/pm.c
>> > +++ b/arch/arm/mach-omap2/pm.c
>> > @@ -33,6 +33,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include "prm-regbits-34xx.h"
>> > #include "pm.h"
>> > @@ -281,3 +282,50 @@ static int __init omap_pm_init(void)
>> > return error;
>> > }
>> > late_initcall(omap_pm_init);
>> > +
>> > +/*
>> > + * Get frequency corresponding to an OPP
>> > + */
>> > +int opp_to_freq(unsigned int* freq, struct omap_opp_table*
>> table, u8 opp)
>> > +{
>> > +int i, found=0;
>> > +
>> > +if (table && table->opps) {
>> > +for (i=table->min; table->opps[i].opp_id
>> <= table->max; i++)
>> > +if (table->opps[i].opp_id == opp) {
>> > +found = 1;
>> > +break;
>> > +}
>> > +
>> > +if (found) {
>> > +*freq = table->opps[i].rate;
>> > +return 1;
>> > +}
>> > +}
>> > +
>> > +return 0;
>> > +}
>> > +
>> > +/*
>> > + * Get OPP corresponding to a frequency
>> > + */
>> > +int freq_to_opp(u8* opp, struct omap_opp_table* table,
>> unsigned long freq)
>> > +{
>> > +int i, found=0;
>> > +
>> > +if (table && table->opps) {
>> > +for (i=table->min; table->opps[i].opp_id
>> <= table->max; i++)
>> > +if (table->opps[i].rate == freq) {
>> > +found = 1;
>> > +break;
>> > +}
>> > +
>> > +if (found) {
>> > +
Re: [PATCH] [ARM] omap: resource: Make resource_refresh() thread safe.
Mike Turquette writes:
> Kevin Hilman wrote:
>> Mike Chan writes:
>>
>>> Need to lock the res_mutex when traversing the res_list.
>>>
>>> Signed-off-by: Mike Chan
>>
>> Looks good, thanks.
>
> This patch causes a hang for me when transitioning to OFF mode. This
> was tested on the Android 2.6.29 tree and is 100% reproducible. The
> moment a user runs 'echo 1 > /sys/power/enable_off_mode' the board
> hangs without any further output.
>
> Reverting the patch allows me to hit OFF mode again. I haven't yet
> tested this on vanilla 2.6.29 or latest L-O.
>
OK, reverting this in both PM branches. Looks like a deadlock to me,
as update_resource_level() must cause a call to something else that
takes the mutex.
Kevin
>
>> Pushed to PM branch and pm-2.6.29.
>>
>> Kevin
>>
>>> ---
>>> arch/arm/plat-omap/resource.c |2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/plat-omap/resource.c b/arch/arm/plat-omap/resource.c
>>> index 25072cd..4631912 100644
>>> --- a/arch/arm/plat-omap/resource.c
>>> +++ b/arch/arm/plat-omap/resource.c
>>> @@ -234,11 +234,13 @@ int resource_refresh(void)
>>> struct shared_resource *resp = NULL;
>>> int ret = 0;
>>> + down(&res_mutex);
>>> list_for_each_entry(resp, &res_list, node) {
>>> ret = update_resource_level(resp);
>>> if (ret)
>>> break;
>>> }
>>> + up(&res_mutex);
>>> return ret;
>>> }
>>> --
>>> 1.5.4.5
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag
"Pandita, Vikram" writes: > Tony/Kevin > Any feedback on this patch for removal of SYSFS_DEPRECATED flag? > > Reference: > http://marc.info/?l=linux-omap&m=125011227920673&q=raw I already ack'd: http://marc.info/?l=linux-omap&m=125011754929777&w=2 > >>-Original Message- >>From: Pandita, Vikram >>Sent: Wednesday, August 12, 2009 4:24 PM >>To: linux-omap@vger.kernel.org >>Cc: khil...@deeprootsystems.com; Pandita, Vikram >>Subject: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag >> >>Remove the SYSFS_DEPRECATED flag from OMAP3 board defconfigs >>This is a deprecated feature no longer needed. >> >>Signed-off-by: Vikram Pandita >>--- >>[Note: Did not change omap2/1 boards as they may still be using >>old filesysterms requiring this flag] >> >> arch/arm/configs/omap3_beagle_defconfig |4 ++-- >> arch/arm/configs/omap3_evm_defconfig |4 ++-- >> arch/arm/configs/omap3_pandora_defconfig |5 +++-- >> arch/arm/configs/omap_3430sdp_defconfig |4 ++-- >> arch/arm/configs/omap_4430sdp_defconfig |4 ++-- >> arch/arm/configs/omap_ldp_defconfig |4 ++-- >> arch/arm/configs/omap_zoom2_defconfig|4 ++-- >> arch/arm/configs/overo_defconfig |4 ++-- >> 8 files changed, 17 insertions(+), 16 deletions(-) >> >>diff --git a/arch/arm/configs/omap3_beagle_defconfig >>b/arch/arm/configs/omap3_beagle_defconfig >>index fe38a83..0c48a7c 100644 >>--- a/arch/arm/configs/omap3_beagle_defconfig >>+++ b/arch/arm/configs/omap3_beagle_defconfig >>@@ -52,8 +52,8 @@ CONFIG_FAIR_GROUP_SCHED=y >> # CONFIG_RT_GROUP_SCHED is not set >> CONFIG_USER_SCHED=y >> # CONFIG_CGROUP_SCHED is not set >>-CONFIG_SYSFS_DEPRECATED=y >>-CONFIG_SYSFS_DEPRECATED_V2=y >>+# CONFIG_SYSFS_DEPRECATED=y is not set >>+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >> # CONFIG_RELAY is not set >> # CONFIG_NAMESPACES is not set >> CONFIG_BLK_DEV_INITRD=y >>diff --git a/arch/arm/configs/omap3_evm_defconfig >>b/arch/arm/configs/omap3_evm_defconfig >>index 28be17f..9273dcc 100644 >>--- a/arch/arm/configs/omap3_evm_defconfig >>+++ b/arch/arm/configs/omap3_evm_defconfig >>@@ -59,8 +59,8 @@ CONFIG_FAIR_GROUP_SCHED=y >> CONFIG_USER_SCHED=y >> # CONFIG_CGROUP_SCHED is not set >> # CONFIG_CGROUPS is not set >>-CONFIG_SYSFS_DEPRECATED=y >>-CONFIG_SYSFS_DEPRECATED_V2=y >>+# CONFIG_SYSFS_DEPRECATED=y is not set >>+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >> # CONFIG_RELAY is not set >> # CONFIG_NAMESPACES is not set >> CONFIG_BLK_DEV_INITRD=y >>diff --git a/arch/arm/configs/omap3_pandora_defconfig >>b/arch/arm/configs/omap3_pandora_defconfig >>index b54ad2e..de0e659 100644 >>--- a/arch/arm/configs/omap3_pandora_defconfig >>+++ b/arch/arm/configs/omap3_pandora_defconfig >>@@ -51,8 +51,9 @@ CONFIG_FAIR_GROUP_SCHED=y >> # CONFIG_RT_GROUP_SCHED is not set >> CONFIG_USER_SCHED=y >> # CONFIG_CGROUP_SCHED is not set >>-CONFIG_SYSFS_DEPRECATED=y >>-CONFIG_SYSFS_DEPRECATED_V2=y >>+# CONFIG_SYSFS_DEPRECATED=y is not set >>+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >>+ >> # CONFIG_RELAY is not set >> # CONFIG_NAMESPACES is not set >> CONFIG_BLK_DEV_INITRD=y >>diff --git a/arch/arm/configs/omap_3430sdp_defconfig >>b/arch/arm/configs/omap_3430sdp_defconfig >>index 8a4a7e2..5c9a686 100644 >>--- a/arch/arm/configs/omap_3430sdp_defconfig >>+++ b/arch/arm/configs/omap_3430sdp_defconfig >>@@ -61,8 +61,8 @@ CONFIG_FAIR_GROUP_SCHED=y >> CONFIG_USER_SCHED=y >> # CONFIG_CGROUP_SCHED is not set >> # CONFIG_CGROUPS is not set >>-CONFIG_SYSFS_DEPRECATED=y >>-CONFIG_SYSFS_DEPRECATED_V2=y >>+# CONFIG_SYSFS_DEPRECATED=y is not set >>+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >> # CONFIG_RELAY is not set >> # CONFIG_NAMESPACES is not set >> CONFIG_BLK_DEV_INITRD=y >>diff --git a/arch/arm/configs/omap_4430sdp_defconfig >>b/arch/arm/configs/omap_4430sdp_defconfig >>index 23e43ea..a464ca3 100644 >>--- a/arch/arm/configs/omap_4430sdp_defconfig >>+++ b/arch/arm/configs/omap_4430sdp_defconfig >>@@ -52,8 +52,8 @@ CONFIG_FAIR_GROUP_SCHED=y >> CONFIG_USER_SCHED=y >> # CONFIG_CGROUP_SCHED is not set >> # CONFIG_CGROUPS is not set >>-CONFIG_SYSFS_DEPRECATED=y >>-CONFIG_SYSFS_DEPRECATED_V2=y >>+# CONFIG_SYSFS_DEPRECATED=y is not set >>+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >> # CONFIG_RELAY is not set >> # CONFIG_NAMESPACES is not set >> CONFIG_BLK_DEV_INITRD=y >>diff --git a/arch/arm/configs/omap_ldp_defconfig >>b/arch/arm/configs/omap_ldp_defconfig >>index b9c4891..9139532 100644 >>--- a/arch/arm/configs/omap_ldp_defconfig >>+++ b/arch/arm/configs/omap_ldp_defconfig >>@@ -49,8 +49,8 @@ CONFIG_FAIR_GROUP_SCHED=y >> # CONFIG_RT_GROUP_SCHED is not set >> CONFIG_USER_SCHED=y >> # CONFIG_CGROUP_SCHED is not set >>-CONFIG_SYSFS_DEPRECATED=y >>-CONFIG_SYSFS_DEPRECATED_V2=y >>+# CONFIG_SYSFS_DEPRECATED=y is not set >>+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >> # CONFIG_RELAY is not set >> # CONFIG_NAMESPACES is not set >> CONFIG_BLK_DEV_INITRD=y >>diff --git a/arch/arm/configs/omap_zoom2_defconfig >>b/arch/arm/configs/omap_zoom2_defconfig >>index f1739
RE: [PATCH 2/3] USB: musb: omap: Fix wrong xceivr passing to twl4030
Ajay >-Original Message- >From: Gupta, Ajay Kumar >> Subject: [PATCH 2/3] USB: musb: omap: Fix wrong xceivr passing to twl4030 >> >> Wrong pointer was getting passed to twl4030 transceiver. >> >> Call path is: >> otg_set_suspend -> twl4030_set_suspend >> >> drivers/usb/otg/twl4030-usb.c: twl4030_set_suspend() uses: >> struct twl4030_usb *twl = xceiv_to_twl(x); >> >> and xceiv_to_twl is container_of() >> >> So the same pointer needs to be passed to otg_set_suspend() as has >> been used for otg_set_transceiver. >> >> A crash is seen without this patch, as twl pointer access is worng >> > >musb->xceiv is also taken from otg_get_transceiver() in musb_platform_init(). >So this patch is not >required. Thanks for pointing this out. I will repost a set of 2 patches with this patch removed. Patches on their way. > >-Ajay > >> Signed-off-by: Vikram Pandita >> --- >> drivers/usb/musb/omap2430.c |4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c >> index b957575..ea7a798 100644 >> --- a/drivers/usb/musb/omap2430.c >> +++ b/drivers/usb/musb/omap2430.c >> @@ -269,7 +269,7 @@ int musb_platform_suspend(struct musb *musb) >> l |= ENABLEWAKEUP; /* enable wakeup */ >> omap_writel(l, OTG_SYSCONFIG); >> >> -otg_set_suspend(musb->xceiv, 1); >> +otg_set_suspend(otg_get_transceiver(), 1); >> >> if (musb->set_clock) >> musb->set_clock(musb->clock, 0); >> @@ -286,7 +286,7 @@ int musb_platform_resume(struct musb *musb) >> if (!musb->clock) >> return 0; >> >> -otg_set_suspend(musb->xceiv, 0); >> +otg_set_suspend(otg_get_transceiver(), 0); >> >> if (musb->set_clock) >> musb->set_clock(musb->clock, 1); >> -- >> 1.6.3.3.334.g916e1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag
Tony/Kevin Any feedback on this patch for removal of SYSFS_DEPRECATED flag? Reference: http://marc.info/?l=linux-omap&m=125011227920673&q=raw >-Original Message- >From: Pandita, Vikram >Sent: Wednesday, August 12, 2009 4:24 PM >To: linux-omap@vger.kernel.org >Cc: khil...@deeprootsystems.com; Pandita, Vikram >Subject: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag > >Remove the SYSFS_DEPRECATED flag from OMAP3 board defconfigs >This is a deprecated feature no longer needed. > >Signed-off-by: Vikram Pandita >--- >[Note: Did not change omap2/1 boards as they may still be using >old filesysterms requiring this flag] > > arch/arm/configs/omap3_beagle_defconfig |4 ++-- > arch/arm/configs/omap3_evm_defconfig |4 ++-- > arch/arm/configs/omap3_pandora_defconfig |5 +++-- > arch/arm/configs/omap_3430sdp_defconfig |4 ++-- > arch/arm/configs/omap_4430sdp_defconfig |4 ++-- > arch/arm/configs/omap_ldp_defconfig |4 ++-- > arch/arm/configs/omap_zoom2_defconfig|4 ++-- > arch/arm/configs/overo_defconfig |4 ++-- > 8 files changed, 17 insertions(+), 16 deletions(-) > >diff --git a/arch/arm/configs/omap3_beagle_defconfig >b/arch/arm/configs/omap3_beagle_defconfig >index fe38a83..0c48a7c 100644 >--- a/arch/arm/configs/omap3_beagle_defconfig >+++ b/arch/arm/configs/omap3_beagle_defconfig >@@ -52,8 +52,8 @@ CONFIG_FAIR_GROUP_SCHED=y > # CONFIG_RT_GROUP_SCHED is not set > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set >-CONFIG_SYSFS_DEPRECATED=y >-CONFIG_SYSFS_DEPRECATED_V2=y >+# CONFIG_SYSFS_DEPRECATED=y is not set >+# CONFIG_SYSFS_DEPRECATED_V2=y is not set > # CONFIG_RELAY is not set > # CONFIG_NAMESPACES is not set > CONFIG_BLK_DEV_INITRD=y >diff --git a/arch/arm/configs/omap3_evm_defconfig >b/arch/arm/configs/omap3_evm_defconfig >index 28be17f..9273dcc 100644 >--- a/arch/arm/configs/omap3_evm_defconfig >+++ b/arch/arm/configs/omap3_evm_defconfig >@@ -59,8 +59,8 @@ CONFIG_FAIR_GROUP_SCHED=y > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set > # CONFIG_CGROUPS is not set >-CONFIG_SYSFS_DEPRECATED=y >-CONFIG_SYSFS_DEPRECATED_V2=y >+# CONFIG_SYSFS_DEPRECATED=y is not set >+# CONFIG_SYSFS_DEPRECATED_V2=y is not set > # CONFIG_RELAY is not set > # CONFIG_NAMESPACES is not set > CONFIG_BLK_DEV_INITRD=y >diff --git a/arch/arm/configs/omap3_pandora_defconfig >b/arch/arm/configs/omap3_pandora_defconfig >index b54ad2e..de0e659 100644 >--- a/arch/arm/configs/omap3_pandora_defconfig >+++ b/arch/arm/configs/omap3_pandora_defconfig >@@ -51,8 +51,9 @@ CONFIG_FAIR_GROUP_SCHED=y > # CONFIG_RT_GROUP_SCHED is not set > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set >-CONFIG_SYSFS_DEPRECATED=y >-CONFIG_SYSFS_DEPRECATED_V2=y >+# CONFIG_SYSFS_DEPRECATED=y is not set >+# CONFIG_SYSFS_DEPRECATED_V2=y is not set >+ > # CONFIG_RELAY is not set > # CONFIG_NAMESPACES is not set > CONFIG_BLK_DEV_INITRD=y >diff --git a/arch/arm/configs/omap_3430sdp_defconfig >b/arch/arm/configs/omap_3430sdp_defconfig >index 8a4a7e2..5c9a686 100644 >--- a/arch/arm/configs/omap_3430sdp_defconfig >+++ b/arch/arm/configs/omap_3430sdp_defconfig >@@ -61,8 +61,8 @@ CONFIG_FAIR_GROUP_SCHED=y > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set > # CONFIG_CGROUPS is not set >-CONFIG_SYSFS_DEPRECATED=y >-CONFIG_SYSFS_DEPRECATED_V2=y >+# CONFIG_SYSFS_DEPRECATED=y is not set >+# CONFIG_SYSFS_DEPRECATED_V2=y is not set > # CONFIG_RELAY is not set > # CONFIG_NAMESPACES is not set > CONFIG_BLK_DEV_INITRD=y >diff --git a/arch/arm/configs/omap_4430sdp_defconfig >b/arch/arm/configs/omap_4430sdp_defconfig >index 23e43ea..a464ca3 100644 >--- a/arch/arm/configs/omap_4430sdp_defconfig >+++ b/arch/arm/configs/omap_4430sdp_defconfig >@@ -52,8 +52,8 @@ CONFIG_FAIR_GROUP_SCHED=y > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set > # CONFIG_CGROUPS is not set >-CONFIG_SYSFS_DEPRECATED=y >-CONFIG_SYSFS_DEPRECATED_V2=y >+# CONFIG_SYSFS_DEPRECATED=y is not set >+# CONFIG_SYSFS_DEPRECATED_V2=y is not set > # CONFIG_RELAY is not set > # CONFIG_NAMESPACES is not set > CONFIG_BLK_DEV_INITRD=y >diff --git a/arch/arm/configs/omap_ldp_defconfig >b/arch/arm/configs/omap_ldp_defconfig >index b9c4891..9139532 100644 >--- a/arch/arm/configs/omap_ldp_defconfig >+++ b/arch/arm/configs/omap_ldp_defconfig >@@ -49,8 +49,8 @@ CONFIG_FAIR_GROUP_SCHED=y > # CONFIG_RT_GROUP_SCHED is not set > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set >-CONFIG_SYSFS_DEPRECATED=y >-CONFIG_SYSFS_DEPRECATED_V2=y >+# CONFIG_SYSFS_DEPRECATED=y is not set >+# CONFIG_SYSFS_DEPRECATED_V2=y is not set > # CONFIG_RELAY is not set > # CONFIG_NAMESPACES is not set > CONFIG_BLK_DEV_INITRD=y >diff --git a/arch/arm/configs/omap_zoom2_defconfig >b/arch/arm/configs/omap_zoom2_defconfig >index f1739fa..a32d126 100644 >--- a/arch/arm/configs/omap_zoom2_defconfig >+++ b/arch/arm/configs/omap_zoom2_defconfig >@@ -59,8 +59,8 @@ CONFIG_FAIR_GROUP_SCHED=y > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set > # CONFIG_CGROUPS is not
N810 not booting on 2.6.31
Hi folks, I'm trying to boot a kernel image using the default n8x0_deconfig file, using the most up-to-dated linux-omap tree (commit 52a962f09ab2306a2ac6e22c2d3bac1a76ac8993). Unfortunately, this image is not booting on my N810 device. With the 'kernel low-level debugging' option enabled, I got the following messages: Uncompressing Linux done, booting the kernel. <5>Linux version 2.6.31-omap1-05923-g52a962f (car...@einstein) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #50 Fri Sep 11 11:08:50 AMT 209 CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387f CPU: VIPT aliasing data cache, VIPT aliasing instruction cache Machine: Nokia N810 <4>Ignoring unrecognised tag 0x414f4d50 Memory policy: ECC disabled, Data cache writeback <7>On node 0 totalpages: 32768 <7>free_area_init_node: node 0, pgdat c024e4e0, node_mem_map c0261000 <7> Normal zone: 256 pages used for memmap <7> Normal zone: 0 pages reserved <7> Normal zone: 32512 pages, LIFO batch:7 <6>OMAP2420<6> <6>SRAM: Mapped pa 0x4020 to va 0xe300 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 <5>Kernel command line: root=1f03 rootfstype=jffs2 console=ttyS0,115200n8 PID hash table entries: 512 (order: 9, 2048 bytes) <6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) <6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) <6>Memory: 64MB 64MB = 128MB total <5>Memory: 127344KB available (2028K code, 188K data, 100K init, 0K highmem) <6>SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 <6>Hierarchical RCU implementation. <6>NR_IRQS:368 <6>Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz <1>Unable to handle kernel NULL pointer dereference at virtual address 0004 <1>pgd = c0004000 <1>[0004] *pgd= Internal error: Oops: 5 [#1] Modules linked in: CPU: 0Not tainted (2.6.31-omap1-05923-g52a962f #50) PC is at _add_initiator_dep+0x18/0x2c LR is at _enable+0x48/0x198 pc : []lr : []psr: a1d3 sp : c0231f80 ip : c0235408 fp : r10: 8001e398 r9 : 4107b362 r8 : 8001e400 r7 : c0234318 r6 : c002c690 r5 : r4 : c02349b4 r3 : r2 : r1 : c02349b4 r0 : c02349b4 Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004000 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc0230268) Stack: (0xc0231f80 to 0xc0232000) 1f80: c02349b4 c02349b4 c02349b4 c002c704 c02349b4 c002c690 c002bccc 1fa0: c001fe14 c002c9a0 c000d678 c001fe18 c024eae0 1fc0: c001fe14 c000e0b4 c001fe18 c000b130 c001fe18 c0008a10 c00084e8 1fe0: c001fe18 00c5387d c024ee20 80008034 [] (_add_initiator_dep+0x18/0x2c) from [] (_enable+0x48/0x198) [] (_enable+0x48/0x198) from [] (_setup+0x74/0xa8) [] (_setup+0x74/0xa8) from [] (omap_hwmod_for_each+0x28/0x6c) [] (omap_hwmod_for_each+0x28/0x6c) from [] (omap_hwmod_late_init+0x58/0x84) [] (omap_hwmod_late_init+0x58/0x84) from [] (omap2_init_common_hw+0x68/0x9c) [] (omap2_init_common_hw+0x68/0x9c) from [] (n8x0_init_irq+0x10/0x1c) [] (n8x0_init_irq+0x10/0x1c) from [] (init_IRQ+0x30/0x40) [] (init_IRQ+0x30/0x40) from [] (start_kernel+0x130/0x298) [] (start_kernel+0x130/0x298) from [<80008034>] (0x80008034) Code: 0a05 e5913020 e592205c e593305c (e5920004) <4>---[ end trace 1b75b31a2719ed1c ]--- <0>Kernel panic - not syncing: Attempted to kill the idle task! [] (unwind_backtrace+0x0/0xe0) from [] (panic+0x40/0x108) [] (panic+0x40/0x108) from [] (do_exit+0x5c/0x568) [] (do_exit+0x5c/0x568) from [] (die+0x12c/0x14c) [] (die+0x12c/0x14c) from [] (__do_kernel_fault+0x64/0x74) [] (__do_kernel_fault+0x64/0x74) from [] (do_page_fault+0x20c/0x22c) [] (do_page_fault+0x20c/0x22c) from [] (do_DataAbort+0x34/0x98) [] (do_DataAbort+0x34/0x98) from [] (__dabt_svc+0x4c/0x60) Exception stack(0xc0231f38 to 0xc0231f80) 1f20: c02349b4 c02349b4 1f40: c02349b4 c002c690 c0234318 8001e400 4107b362 1f60: 8001e398 c0235408 c0231f80 c002c1b4 c002bf24 a1d3 [] (__dabt_svc+0x4c/0x60) from [] (_add_initiator_dep+0x18/0x2c) [] (_add_initiator_dep+0x18/0x2c) from [] (_enable+0x48/0x198) [] (_enable+0x48/0x198) from [] (_setup+0x74/0xa8) [] (_setup+0x74/0xa8) from [] (omap_hwmod_for_each+0x28/0x6c) [] (omap_hwmod_for_each+0x28/0x6c) from [] (omap_hwmod_late_init+0x58/0x84) [] (omap_hwmod_late_init+0x58/0x84) from [] (omap2_init_common_hw+0x68/0x9c) [] (omap2_init_common_hw+0x68/0x9c) from [] (n8x0_init_irq+0x10/0x1c) [] (n8x0_init_irq+0x10/0x1c) from [] (init_IRQ+0x30/0x40) [] (init_IRQ+0x30/0x40) from [] (start_kernel+0x130/0x298) [] (start_kernel+0x130/0x298) from [<80008034>] (0x80008034) Any hint on how to solve it? BR, Carlos. -- Carlos Eduardo Aguiar Software Developer Mobile Linux
[PATCH v2 2/2] OMAP1/2/3/4: DEBUG_LL run time detection
This patch cleans up the DEBUG_LL infrastructure for omap boards.
The decision of finding the physical address of debug uart is done
at runtime now, making possible to use a single defconfig for multiple boards.
This patch gets rid of menuconfig options of choosing low level debug uarts.
Changes are:
1) Implement get_uart_[virt_]base in arch/arm/boot/compressed/misc.c
These functions do a run time detection of debug uart address
2) arch/arm/boot/compressed/head.S
calls get_uart_base to get the phy address and stores in r13^ user mode ARM reg
calls get_uart_virt_base to get the virtual address and stores in r14^ user
mode ARM reg
3) arch/arm/plat-omap/include/mach/debug-macro.S: addruart
This function gets the debug uart phy/virtual address from r13^ and r14^
respectively
Stores them in a variables, __phy_uart_addr and __virt_uart_addr
so that subsiquent access get the address from variables
Changes have been tested on:
SDP3430: UART1
Zoom1: UART3
Beagle: UART3
Zoom2: External Uart
Signed-off-by: Vikram Pandita
---
arch/arm/boot/compressed/head.S | 17
arch/arm/boot/compressed/misc.c | 108 -
arch/arm/plat-omap/Kconfig| 16
arch/arm/plat-omap/include/mach/debug-macro.S | 74 +
arch/arm/plat-omap/include/mach/uncompress.h | 22 +++---
5 files changed, 176 insertions(+), 61 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4515728..7fcc21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -277,6 +277,20 @@ not_relocated: mov r0, #0
blo 1b
add sp, r1, #128@ relocate the stack
+ mov r9, r0
+
+ bl get_uart_base @ get uart phy address
+ adr r2, __dummy
+ str r0, [r2]@save uart phy adder in memory
+ ldm r2, {r13}^ @save phyadder in usermode reg
+
+ bl get_uart_virt_base @ get uart virtual address
+ adr r2, __dummy
+ str r0, [r2]@save uart phy adder in memory
+ ldm r2, {r14}^ @save phyadder in usermode reg
+
+ mov r0, r9
+
bl cache_clean_flush
add pc, r5, r0 @ call relocation code
@@ -303,6 +317,9 @@ LC0:.word LC0 @ r1
LC1: .word reloc_end - reloc_start
.size LC0, . - LC0
+ .type __dummy, #object
+__dummy: .word __dummy
+
#ifdef CONFIG_ARCH_RPC
.globl params
params:ldr r0, =params_phys
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 17153b5..0758656 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -22,6 +22,15 @@ unsigned int __machine_arch_type;
#include/* for size_t */
#include /* for NULL */
#include
+#include
+/* TODO:
+ * Include of this header is not working.
+ * Gives Error: undefined reference to `omap_rev'
+ * This header is needed for constant:
+ * ZOOM2_EXT_QUART_VIRT = 0xFB00
+ * ZOOM2_EXT_QUART_PHYS = 0x1000
+ */
+/* #include */
#ifdef STANDALONE_DEBUG
#define putstr printf
@@ -316,6 +325,103 @@ static void error(char *x)
#ifndef STANDALONE_DEBUG
+u32 *omap_uart_debug_ll_phy_addr;
+
+static void find_debug_ll_uart_port(unsigned int arch_type)
+{
+ omap_uart_debug_ll_phy_addr = 0;
+
+ /* Add logic here for new platforms, using __macine_arch_type */
+
+ /* TODO: REVISIT -- Check Completeness
+* DEFINE PHY ADDRESS for EACH BOARD HERE: omap1/2/3/4 */
+#if defined(CONFIG_ARCH_OMAP1)
+ switch (arch_type) {
+ case MACH_TYPE_OMAP_PALMTT:
+ case MACH_TYPE_SX1:
+ /* UART2 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0xfffb0800;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0xfffb;
+ break;
+ }
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2)
+ switch (arch_type) {
+ case MACH_TYPE_NOKIA_N800:
+ case MACH_TYPE_NOKIA_N810:
+ case MACH_TYPE_NOKIA_N810_WIMAX:
+ /* UART3 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806e000;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+ break;
+ }
+#endif
+
+#if defined(CONFIG_ARCH_OMAP3)
+ switch (arch_type) {
+ case MACH_TYPE_OMAP_LDP:
+ case MACH_TYPE_OVERO:
+ case MACH_TYPE_OMAP3_PANDORA:
+ case MACH_TYPE_NOKIA_RX51:
+ case MACH_TYPE_OMAP3_BEAGLE:
+ /* UART3 */
+ omap
[PATCH v2 1/2] OMAP: Zoom2: Add DEBUG_LL interface using Quart
This patch adds DEBUG_LL interface for Zoom2 board.
The low level debug uart now points corrctly to External Quad uart
controller on detachable debug board.
The Quad uart is available over GPMC chip select with physical address
0x1000.
This physical address has been mapped to virtual address 0xFB00
as per static mapping.
This patch is adapted from a version by Erik Gilling:
http://android.git.kernel.org/?p=kernel/omap.git;
a=commit;h=e9d72efdd88877d2d6ea74a08983ace0dcc771d3
Signed-off-by: Vikram Pandita
Cc: Erik Gilling
---
arch/arm/mach-omap2/board-zoom-debugboard.c |5 +++--
arch/arm/mach-omap2/board-zoom2.c | 19 +--
arch/arm/plat-omap/include/mach/io.h|6 ++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-debugboard.c
index 1f13e2a..70a4bba 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -82,9 +82,10 @@ static inline void __init zoom2_init_smsc911x(void)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase= 0x1000,
+ .membase= IOMEM(ZOOM2_EXT_QUART_VIRT),
+ .mapbase= ZOOM2_EXT_QUART_PHYS,
.irq= OMAP_GPIO_IRQ(102),
- .flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+ .flags = UPF_BOOT_AUTOCONF|UPF_SHARE_IRQ,
.irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
.iotype = UPIO_MEM,
.regshift = 1,
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 324009e..467e961 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -19,10 +19,12 @@
#include
#include
+#include
#include
#include
#include
+#include
#include "mmc-twl4030.h"
@@ -269,15 +271,28 @@ static void __init omap_zoom2_init(void)
usb_musb_init();
}
+static struct map_desc zoom2_io_desc[] __initdata = {
+ {
+ .virtual= ZOOM2_EXT_QUART_VIRT,
+ .pfn= __phys_to_pfn(ZOOM2_EXT_QUART_PHYS),
+ .length = ZOOM2_EXT_QUART_SIZE,
+ .type = MT_DEVICE
+ }
+};
+
static void __init omap_zoom2_map_io(void)
{
omap2_set_globals_343x();
+
+ /* Map external quad UART virt to phy mapping */
+ iotable_init(zoom2_io_desc, ARRAY_SIZE(zoom2_io_desc));
+
omap2_map_common_io();
}
MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
- .phys_io= 0x4800,
- .io_pg_offst= ((0xd800) >> 18) & 0xfffc,
+ .phys_io= ZOOM2_EXT_QUART_PHYS,
+ .io_pg_offst= ((ZOOM2_EXT_QUART_VIRT) >> 18) & 0xfffc,
.boot_params= 0x8100,
.map_io = omap_zoom2_map_io,
.init_irq = omap_zoom2_init_irq,
diff --git a/arch/arm/plat-omap/include/mach/io.h
b/arch/arm/plat-omap/include/mach/io.h
index 8d32df3..d67f06c 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -169,6 +169,12 @@
#define DSP_MMU_34XX_VIRT 0xe200
#define DSP_MMU_34XX_SIZE SZ_4K
+/* Map External Quad UART for Zoom2 board */
+#define ZOOM2_EXT_QUART_PHYS 0x1000 /* PHY address if fixed */
+#define ZOOM2_EXT_QUART_PHY_TO_VIRT_OFF0xEB00
+#define ZOOM2_EXT_QUART_VIRT 0xFB00
+#define ZOOM2_EXT_QUART_SIZE SZ_16
+
/*
*
* Omap4 specific IO mapping
--
1.6.3.3.334.g916e1
--
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 0/2] Cleanup DEBUG_LL infrastructure
Patch1: add DEBUG_LL support for Zoom2 board that has external UART Patch2: clean up the DEBUG_LL infrastructure for run time detection Patchs are also hosted at: git://dev.omapzoom.org/pub/scm/vikram/omap3.git runtime-debug-ll Tested on OMAP3: SDP3430/Zoom2/Zoom1/Beagleboard Will appreciate if some can verify for OMAP2 and OMAP1 boards Vikram Pandita (2): OMAP: Zoom2: Add DEBUG_LL interface using Quart OMAP1/2/3/4: DEBUG_LL run time detection arch/arm/boot/compressed/head.S | 17 arch/arm/boot/compressed/misc.c | 108 - arch/arm/mach-omap2/board-zoom-debugboard.c |5 +- arch/arm/mach-omap2/board-zoom2.c | 19 - arch/arm/plat-omap/Kconfig| 16 arch/arm/plat-omap/include/mach/debug-macro.S | 74 + arch/arm/plat-omap/include/mach/io.h |6 ++ arch/arm/plat-omap/include/mach/uncompress.h | 22 +++--- 8 files changed, 202 insertions(+), 65 deletions(-) -- 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] Common mechanism to identify Si revision
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, September 10, 2009 11:25 PM > To: Olof Johansson > Cc: Premi, Sanjeev; linux-omap@vger.kernel.org > Subject: Re: [RFC] Common mechanism to identify Si revision > -- > > > > There's two major benefits to this: > > > > 1) Readability. No need to sit and look up in a manual why there's a > > check for version X here. > > (and/or no need to add a specific comment about it). > > > > 2) Keeping changes centralized. If there's a new revision or chip, > > there's just one header file to update, not 20 different > source files. > > > > For example, a bunch of the checks in pm34xx.c would be > nicer to have as: > > > > if (OMAP_HAS_USBHOST()) > > > > I tend to agree with Olaf here and am in favor of the new 'features' > patch that Sanjeev has already proposed. > > That doesn't mean that I'm opposed to this change in principle, but > would rather see most of the omap_rev() and cpu_is_* checks disappear > in favor of more generic omap_has_feature() checks. > > Kevin > > Tony, I am planning to submit another patch for "speed - enhanced" part for OMAP3530. I see enhanced speed as a feature; and would like to build upon the last submission. BTW, there is no change in ES revision for new part. Just additional set of control bits in TAP area. Do you see any issues with the patch: [1] http://marc.info/?l=linux-omap&m=125050987112798&w=2 Best regards, Sanjeev -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Labrador OMAP 3430 problem
i solve the problem...thanks a lot On 9/11/09, Lesly AM wrote: > Seems like you were using nand boot, and you erased the loader & U-Boot on > NAND. > > Can you try to boot from MMC card. (copy X-loader and U-Boot to MMC card) > > Regards, > Lesly AM > > - Original Message - > From: "Tar Gz" > To: "linux-omap" > Sent: Friday, September 11, 2009 7:24 PM > Subject: Labrador OMAP 3430 problem > > >>i have problem with my labrador board, after i using nand erase and >> i'm restart my board..my board can't show anything in hyperterminal >> nad the BT indicator(blue led) still onany idea? >> -- >> 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: Labrador OMAP 3430 problem
Seems like you were using nand boot, and you erased the loader & U-Boot on NAND. Can you try to boot from MMC card. (copy X-loader and U-Boot to MMC card) Regards, Lesly AM - Original Message - From: "Tar Gz" To: "linux-omap" Sent: Friday, September 11, 2009 7:24 PM Subject: Labrador OMAP 3430 problem i have problem with my labrador board, after i using nand erase and i'm restart my board..my board can't show anything in hyperterminal nad the BT indicator(blue led) still onany idea? -- 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: USB charging over TPS65950 BCI
hi gregoire, i did not mention about charge current. the sysfs entry charge_current always returns 360. -- Best Regards Pramod On Fri, Sep 11, 2009 at 7:21 PM, pramod gurav wrote: > Hello gregoire, > > Really sorry I could not reply to your mail as I was busy with some other > work. > I applied your above patch tested. The sysfs entries return correct > values for status, charger device(online), voltage_now. But the > current across the battery is reported wrong. I compared the values > returned by current_now sysfs entry with multimeter values across the > battery. The values were varying whenever I remove AC and plug it > back. But what I could see was the current_now value was approximately > double the actual current across the battery. > Without your patch the twl4030_bci gives wrong values for current_now, > voltage_now, capacity etc. > But your patch fixes this issue. > > But the USB charging did not work. Is USB charging functional with > TWL4030 on any of the OMAP boards? > > > Don't mind for the late reply. Thanks for your help. > > -- > Thanks and Best Regards > Pramod > > On Wed, Aug 5, 2009 at 9:48 PM, Gregoire Gentil wrote: >> Hello, >> >> Any feed-back on the patch I sent? Have you tried it? Have you fixed >> your problem? >> >> Grégoire >> >> >> On Fri, 2009-07-31 at 23:41 -0700, Gregoire Gentil wrote: >>> On Fri, 2009-07-31 at 19:19 +0530, pramod gurav wrote: >>> > Hi All, >>> > I was trying to get the USB battery charging working over TPS65950 BCI >>> > on the OMAP3430 custom board. I am working with linux-omap-2.6 >>> > v2.6.28-omap1 tag. I enabled the TWL4030 MADC and TWL4030 BCI drivers. >>> > I passed interrupt details to these drivers from platform_device >>> > structure from my board file. I could get the AC charging working. The >>> > AC and USB detection worked. However the USB charging is not >>> > happening. >>> > I read through the TPS TRM and took the dumps of the registers from >>> > BCI and some from TWL USB module and BOOT_BCI whenever I plug in the >>> > USB charger between host and the board. The register settings seem to >>> > be fine. But the battery is not charging. I am using BQ27000 chip for >>> > battery monitoring and I can see the battery voltage is decreasing. >>> > >>> > Following are the register dumps of TWL with and without USB plugged in: >>> > >>> > These are the register contents when USB charger is plugged in: >>> > BCIMDEN = 0x11 >>> > REG_BOOT_BCI = 0x37 >>> > REG_POWER_CTRL = 0x20 >>> > REG_BCIMFSTS4 = 0xf4 >>> > REG_BCIMFSTS1 = 0x13 >>> > REG_BCIIREF1 = 0x68 >>> > REG_BCIIREF2 = 0x3 >>> > REG_BCIMFEN4 = 0x6f >>> > REG_BCIMFSTS2 = 0x0 >>> > REG_BCIMSTATEC = 0x12 >>> > REG_STS_HW_CONDITIONS= 0x90 >>> > >>> > >>> > These are the register contents when USB charger is plugged out: >>> > BCIMDEN = 0x0 >>> > REG_BOOT_BCI = 0x35 >>> > REG_POWER_CTRL = 0x20 >>> > REG_BCIMFSTS4 = 0xf0 >>> > REG_BCIMFSTS1 = 0xaa >>> > REG_BCIIREF1 = 0x68 >>> > REG_BCIIREF2 = 0x3 >>> > REG_BCIMFEN4 = 0x68 >>> > REG_BCIMFSTS2 = 0x0 >>> > REG_BCIMSTATEC =0x0 >>> > REG_STS_HW_CONDITIONS= 0x10 >>> > >>> > Is there anything more I need to support to get BCI USB charging >>> > working? Need I follow any USB Communication protocol between Host and >>> > the board. >>> > I have pasted the kernel boot logs for reference at the end. >>> > Can any one please guide me to some pointers? >>> > >>> > -- >>> > Best Regards >>> > Pramod >>> I'm experiencing some problems with TWL4030 DC charging and I'm >>> interested by this kind of problem. Basically, the values reported by >>> our patch is different from the current going to the battery. We wrote >>> the attached enhanced patch so as to edit at run-time the charging mode >>> and various values including charge_current. It's against 2.6.29 but I >>> think that it should work again 2.6.28. Unfortunately, starting 2.6.30, >>> Tony has removed all the BCI battery code and has asked for updated code >>> against mainline but I've not seen anything so far. >>> >>> Pramod, can you try the attached patch (perhaps, it will help you) and >>> can you tell if you see the exact current going to the battery reported >>> by the driver? >>> >>> Grégoire >>> >>> >>> >>> >>> >>> --- a/drivers/power/twl4030_bci_battery.c 2009-07-22 18:27:16.0 >>> -0700 >>> +++ b/drivers/power/twl4030_bci_battery.c 2009-07-22 18:30:22.0 >>> -0700 >>> @@ -15,6 +15,9 @@ >>> * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. >>> */ >>> >>> +/* Boot with automatic charge */ >>> +#define CHARGE_MODE 1 >>> + >>> #include >>> #include >>> #include >>> @@ -50,6 +53,7 @@ >>> /* Boot BCI flag bits */ >>> #define BCIAUTOWEN 0x020 >>> #define CONFIG_DONE 0x010 >>> +#define CVENAC 0x004 >>> #define BCIAUTOUSB 0x002 >>> #define BCIAUTOAC 0x001 >>> #define BCIMSTAT_MASK 0x03F >>> @@ -81,6 +85,11 @@
Labrador OMAP 3430 problem
i have problem with my labrador board, after i using nand erase and i'm restart my board..my board can't show anything in hyperterminal nad the BT indicator(blue led) still onany idea? -- 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] Common mechanism to identify Si revision
Hi Kevin, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Kevin Hilman > Sent: Thursday, September 10, 2009 7:55 PM > To: Olof Johansson > Cc: Premi, Sanjeev; linux-omap@vger.kernel.org > Subject: Re: [RFC] Common mechanism to identify Si revision > > Olof Johansson writes: > > > On Thu, Sep 03, 2009 at 04:14:28PM +0530, Premi, Sanjeev wrote: > >> Hi, > >> > >> Currently there are multiple mechanisms for identifying the si > revisions. > >> > >> Most places the comparison is against omap_rev() as a whole number. > Example: > >> > >> arch/arm/mach-omap2/board-3430sdp.c:695:if (omap_rev() > > OMAP3430_REV_ES1_0) > >> arch/arm/mach-omap2/board-3430sdp.c:728:if (omap_rev() > > OMAP3430_REV_ES1_0) > >> > >> Then, there are custom macros. Example (cpu.h): > >> > >> #define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1) > >> #define CHIP_GE_OMAP3430ES3(CHIP_IS_OMAP3430ES3_0 | \ > >> CHIP_GE_OMAP3430ES3_1) > >> #define CHIP_GE_OMAP3430ES2(CHIP_IS_OMAP3430ES2 | \ > >> CHIP_GE_OMAP3430ES3) > >> > >> The problem with comparing against a whole number is that comparison is > invalid > >> for another processor series. E.g. OMAP3430 and OMAP3517. > >> > >> Here, I am proposing a common mechanism to identify the si revision; > that focuses > >> on the revision bits alone. (See code below) > >> > >> The usage would then be (example): > >> > >>if (omap_rev() > OMAP3430_REV_ES1_0) > >> > >> To > >> > >>if (cpu_is_omap34xx() && OMAP_REV_GT(OMAP_ES_1_0) > > > > What's the purpose of most of these checks in the first place? I can > > see two immediate needs: > > > > 1) To check for various errata and do appropriate workarounds > > > > 2) To check if the current chip has a certain feature > > > > Both of these could just as well be abstracted away such that you use > > tests on the form: > > > > if (OMAP_HAS_ERRATA_FOO) ... > > > > or: > > if (OMAP_FEATURE_FOO) ... > > > > And then move the actual checking of a feature into the header file > > where the errata/feature setups are defined. > > > > > > There's two major benefits to this: > > > > 1) Readability. No need to sit and look up in a manual why there's a > > check for version X here. > > (and/or no need to add a specific comment about it). > > > > 2) Keeping changes centralized. If there's a new revision or chip, > > there's just one header file to update, not 20 different source files. > > > > For example, a bunch of the checks in pm34xx.c would be nicer to have > as: > > > > if (OMAP_HAS_USBHOST()) > > > > I tend to agree with Olaf here and am in favor of the new 'features' > patch that Sanjeev has already proposed. I agree as well, most of the differences between several ES and OMAP variant are related to changes in IPs and not really to the chip version. > That doesn't mean that I'm opposed to this change in principle, but > would rather see most of the omap_rev() and cpu_is_* checks disappear > in favor of more generic omap_has_feature() checks. In that case taking into account the feature version might be useful in order to get rid of most of the omap_rev(). Most of the time new ES are due to new feature or bug fix in an IP that will increase the IP version. 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: [RFC] Common mechanism to identify Si revision
> -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, September 10, 2009 2:59 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org > Subject: Re: [RFC] Common mechanism to identify Si revision > > Hello Sanjeev, > > On Thu, 3 Sep 2009, Premi, Sanjeev wrote: > > > Here, I am proposing a common mechanism to identify the si > revision; that focuses > > on the revision bits alone. (See code below) > > > > The usage would then be (example): > > > >if (omap_rev() > OMAP3430_REV_ES1_0) > > > > To > > > >if (cpu_is_omap34xx() && OMAP_REV_GT(OMAP_ES_1_0) > > For use in structures like clock34xx.h and > powerdomains34xx.h, would you > propose that we use two different fields then - one for OMAP > type, the > other for revision restrictions? Or a different scheme? > > - Paul > Paul, First answer: We could use two fields e.g. omap_type and omap_rev. For example: .omap_type= CHIP_IS_OMAP3430, .omap_rev = OMAP_ES_2_1, Instead of : .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430), .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 | CHIP_IS_OMAP3430ES2 | CHIP_IS_OMAP3430ES3_0), .omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1), Second answer: >From the snippets above, it appears that we need to: 1) identify which chip is in use 2) which si rev (if any) does the clock/powerdomain definition applies to. Actually, we are checking for: a) Does definition depend upon a si rev b) if so, which rev? - usually LE and GE should be sufficient. Which chip in use? - can either be a run-time check OR mapped to an boot-time setting of "valid" field for the si being used. e.g. (translating the snippet above): .valid= (cpu_is_omap34xx()) .valid= (cpu_is_omap34xx() && (OMAP_REV_EQ(OMAP_ES_1_0) || OMAP_REV_EQ(OMAP_ES_2_1) || OMAP_REV_EQ(OMAP_ES_3_0))) .valid= (cpu_is_omap34xx() && (OMAP_REV_GE(OMAP_ES_3_1)) Now decision at runtime can be made based on the just this flag. I haven't really done any prototyping on this, so there may be holes in explanation above; but I hope general idea is coming clear. Best regards, Sanjeev -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 3430SDP: Crash on first UART keypress after boot
> > > > > Current linux-omap kernel boots up fine on 3430 SDP after > > > adding Sergio's patch [1], but then I get the following crash > > > on the first UART keypress. > > > > > > This is new, it used to work okay a little while ago. > > > > > > Regards, > > > Anand > > > > The crash still exists with current linux-omap kernel. > > > > Disabling CONFIG_FB_OMAP makes the issue go away. > > > > (Only disabled this one option - see diff between .config.old > > and .config below) > > > > I don't see this issue on my SDP even with OMAP_FB enabled. > May be we have different ES versions Thanks for testing - switching to a different filesystem, the crash goes away. But I'm still not sure what caused the crash to disappear with the old filesystem but with CONFIG_FB_OMAP removed. Confused, Anand -- 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: 3430SDP: Crash on first UART keypress after boot
Anand, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand > Sent: Friday, September 11, 2009 2:55 PM > To: Gadiyar, Anand; linux-omap@vger.kernel.org > Subject: RE: 3430SDP: Crash on first UART keypress after boot > > > Current linux-omap kernel boots up fine on 3430 SDP after > > adding Sergio's patch [1], but then I get the following crash > > on the first UART keypress. > > > > This is new, it used to work okay a little while ago. > > > > Regards, > > Anand > > The crash still exists with current linux-omap kernel. > > Disabling CONFIG_FB_OMAP makes the issue go away. > > (Only disabled this one option - see diff between .config.old > and .config below) > I don't see this issue on my SDP even with OMAP_FB enabled. May be we have different ES versions -- 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: 3430SDP: Crash on first UART keypress after boot
> Current linux-omap kernel boots up fine on 3430 SDP after > adding Sergio's patch [1], but then I get the following crash > on the first UART keypress. > > This is new, it used to work okay a little while ago. > > Regards, > Anand The crash still exists with current linux-omap kernel. Disabling CONFIG_FB_OMAP makes the issue go away. (Only disabled this one option - see diff between .config.old and .config below) - Anand CUT HERE --- .config.old 2009-09-11 14:54:57.0 +0530 +++ .config 2009-09-11 14:55:08.0 +0530 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.31-rc9-omap1 -# Fri Sep 11 14:54:57 2009 +# Fri Sep 11 14:55:08 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -1154,9 +1154,9 @@ CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set -CONFIG_FB_CFB_FILLRECT=y -CONFIG_FB_CFB_COPYAREA=y -CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_FILLRECT is not set +# CONFIG_FB_CFB_COPYAREA is not set +# CONFIG_FB_CFB_IMAGEBLIT is not set # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set @@ -1177,12 +1177,8 @@ CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set -CONFIG_FB_OMAP=y +# CONFIG_FB_OMAP is not set # CONFIG_FB_OMAP_LCD_VGA is not set -# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set -# CONFIG_FB_OMAP_LCD_MIPID is not set -# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set -CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # -- 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 28/30] omap_hsmmc: ensure all clock enables and disables are paired
Andrew Morton wrote: On Wed, 09 Sep 2009 15:00:03 +0300 Adrian Hunter wrote: >From baf6574a1b5e7c4fdc4a66d9e038efeee75ea1a0 Mon Sep 17 00:00:00 2001 From: Adrian Hunter Date: Sun, 31 May 2009 19:27:36 +0300 Subject: [PATCH] omap_hsmmc: ensure all clock enables and disables are paired This patch hasn't been updated with omap_hsmmc-ensure-all-clock-enables-and-disables-are-paired-fix-for-the-db-clock-failure-message.patch, and omap_hsmmc-ensure-all-clock-enables-and-disables-are-paired-fix-for-the-db-clock-failure-message.patch is not present in the v3 patchset. What's up with that? I am not sure what you want here. madhu's patch should apply cleanly on top of the ones I sent. I went through the patchset seeing what you'd done. mmc-add-host-capabilities-for-sd-only-and-mmc-only.patch and omap_hsmmc-pass-host-capabilities-for-sd-only-and-mmc-only.patch were dropped. arm-omap-rx51-set-mmc-capabilities-and-power-saving-flag.patch was significantly altered (I queued a delta for that). omap_hsmmc-make-use-of-new-mmc_cap_nonremovable-host-capability.patch was changed a bit to fix rejects (I think). Yes that is right. -- 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: dspbridge rfc: get rid of services/list.c (v3)
From: Andy Shevchenko Subject: dspbridge rfc: get rid of services/list.c (v3) Date: Tue, 8 Sep 2009 14:12:13 +0200 > > Hello. > > Here are a few patches which change driver's own circular linked list > implementation to native one in linux kernel. The initial idea was come from > Hiroshi Doyu. > > This version includes corrections which I got from Imre, Artem and Felipe. > > All patches are rebased against android-bridge-2.6.29 kernel branch of the > kernel-dspbridge repository. Any comment on those patches from TI? > > Please, review them. Thank you. > > -- > With Best Regards, > Andy Shevchenko > -- 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: V3 - mmc and omap_hsmmc patches
Madhusudhan wrote: Hi Adrian, [PATCH V3 0/30] mmc and omap_hsmmc patches What is the reason for V3? What is the difference between V2 and V3 series? The reason for V3 is that the SD-only and MMC-only host capability patches were not wanted. The difference is that patches originally numbered 0007 and 0027 were dropped and the rest re-rolled. i.e. Subject: [PATCH V2 7/32] mmc: add host capabilities for SD only and MMC only File: 0007-mmc-add-host-capabilities-for-SD-only-and-MMC-only.patch Subject: [PATCH V2 27/32] omap_hsmmc: pass host capabilities for SD only and MMC only File: 0027-omap_hsmmc-pass-host-capabilities-for-SD-only-and-M.patch were removed. -- 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
