Re: [PATCH] omap:usb: fixing ehci phy gpio values for omap3
On Tue, Apr 26, 2011 at 7:10 PM, Menon, Nishanth wrote:
> On Thu, Apr 21, 2011 at 09:22, Keshava Munegowda
> wrote:
>>
>> From: Keshava Munegowda
>>
>> The gpio of EHCI phy should be 0 instead of 1;
>> This fixes the hub enumeration issue in beagle xm board.
>>
>> Signed-off-by: Keshava Munegowda
>
> Dumb q1: Has this been tested on PandaBoard?
No, I have tested this on 4430 sdp . I think sdp validation is sufficient
> Dumb q2: is'nt it better to introduce polarity e.g.
> pdata->ehci_data->reset_gpio_polarity etc? this will allow board files
> to describe polarity of pin information to driver which can then be
> Phy and any board specific mods(e.g. inverter on the line) independent
> completely..
yes, I am thinking of doing it; since it requires modification of all
board files;
I will send this an another separate patch.
keshava munegowda
>
> Regards,
> Nishanth Menon
>
>> ---
>> drivers/mfd/omap-usb-host.c | 8
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index b3bb3ac..a12202e 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -718,14 +718,14 @@ static int usbhs_enable(struct device *dev)
>> gpio_request(pdata->ehci_data->reset_gpio_port[0],
>> "USB1 PHY reset");
>> gpio_direction_output
>> - (pdata->ehci_data->reset_gpio_port[0], 1);
>> + (pdata->ehci_data->reset_gpio_port[0], 0);
>> }
>>
>> if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1])) {
>> gpio_request(pdata->ehci_data->reset_gpio_port[1],
>> "USB2 PHY reset");
>> gpio_direction_output
>> - (pdata->ehci_data->reset_gpio_port[1], 1);
>> + (pdata->ehci_data->reset_gpio_port[1], 0);
>> }
>>
>> /* Hold the PHY in RESET for enough time till DIR is high */
>> @@ -905,11 +905,11 @@ static int usbhs_enable(struct device *dev)
>>
>> if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
>> gpio_set_value
>> - (pdata->ehci_data->reset_gpio_port[0], 0);
>> + (pdata->ehci_data->reset_gpio_port[0], 1);
>>
>> if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1]))
>> gpio_set_value
>> - (pdata->ehci_data->reset_gpio_port[1], 0);
>> + (pdata->ehci_data->reset_gpio_port[1], 1);
>> }
>>
>> end_count:
>> --
>> 1.6.0.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
Hello!
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
> -void __init usb_musb_init(struct omap_musb_board_data *board_data)
> +static struct omap_musb_board_data musb_default_board_data = {
> + .interface_type = MUSB_INTERFACE_ULPI,
> + .mode = MUSB_OTG,
In fact can you make it more generic with ifdefs like this?
(since there are tons of boards taht are client only or would like to be
compiled in some other way):
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
> + .power = 100,
> +};
> +
Thanks!
Bye,
Oleg
--
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] Initial B&N Nook Color (Encore) support
From: Oleg Drokin
Just bare-bones board file that has only serial console working.
---
arch/arm/mach-omap2/Kconfig|5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap3encore.c| 152
arch/arm/plat-omap/include/plat/board-encore.h | 76
arch/arm/plat-omap/include/plat/uncompress.h |1 +
arch/arm/tools/mach-types |2 +-
6 files changed, 236 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3encore.c
create mode 100644 arch/arm/plat-omap/include/plat/board-encore.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..5370561 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO
for full description please see the products webpage at
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
+config MACH_ENCORE
+bool "Barnes & Noble Encore (Nook Color)"
+depends on ARCH_OMAP3
+select OMAP_PACKAGE_CBP
+
config MACH_OVERO
bool "Gumstix Overo board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..207f372 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -189,6 +189,7 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
hsmmc.o
+obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3encore.c
b/arch/arm/mach-omap2/board-omap3encore.c
new file mode 100644
index 000..9a00d6b
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3encore.c
@@ -0,0 +1,152 @@
+/*
+ *
+ * Copyright (C) 2008 Texas Instruments Inc.
+ * Vikram Pandita
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Apri 2011 Oleg Drokin - Port to 2.6.39
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include // For system_serial_high & system_serial_low
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "mux.h"
+#include "prcm-common.h"
+
+#include "sdram-hynix-h8mbx00u0mer-0em.h"
+
+#include
+
+#ifdef CONFIG_ANDROID_RAM_CONSOLE
+#include
+#endif
+
+/* Use address that is most likely unused and untouched by u-boot */
+#define ENCORE_RAM_CONSOLE_START 0x8e00
+#define ENCORE_RAM_CONSOLE_SIZE (0x2)
+
+static struct resource encore_ram_console_resource[] = {
+{
+.start = ENCORE_RAM_CONSOLE_START,
+.end= ENCORE_RAM_CONSOLE_START + ENCORE_RAM_CONSOLE_SIZE - 1,
+.flags = IORESOURCE_MEM,
+}
+};
+
+static struct platform_device encore_ram_console_device = {
+.name = "ram_console",
+.id = 0,
+.num_resources = ARRAY_SIZE(encore_ram_console_resource),
+.resource = encore_ram_console_resource,
+};
+
+static struct platform_device *encore_devices[] __initdata = {
+ &encore_ram_console_device,
+};
+
+static void __init omap_encore_init_early(void)
+{
+printk("in early ini\n");
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+#ifdef CONFIG_ANDROID_RAM_CONSOLE
+ reserve_bootmem(ENCORE_RAM_CONSOLE_START, ENCORE_RAM_CONSOLE_SIZE, 0);
+#endif /* CONFIG_ANDROID_RAM_CONSOLE */
+printk("done early ini\n");
+}
+
+#if defined(CONFIG_USB_ANDROID) || defined(CONFIG_USB_ANDROID_MODULE)
+static struct usb_mass_storage_platform_data mass_storage_pdata = {
+ .vendor = "B&N ",
+ .product = "Ebook Disk ",
+ .release = 0x0100,
+};
+
+static struct platform_device usb_mass_storage_device = {
+ .name = "usb_mass_storage",
+ .id = -1,
+ .dev = {
+ .platform_data = &mass_storage_pdata,
+ },
+};
+#endif
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+{ .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
+static struct omap_board_config_kernel encore_config[] __initdata = {
+};
+
+static void __init
Initial B&N Nook Color support
Hello! I am surprised nobody did it sooner given how popular the Nook Color is and also considering the price. Anyway, here is my initial attempt at adding the support for it to the latest kernel. The two patches included are the bare bones support that brings serial console support, internal MMC + SDCard and also usb client. I hijacked the nookcolor mach-type entry since it's for this device, but in fact the original device nickname was encore, so this is how the arch is named, hopefully this is fine (and hopefully there is a way to update the info at http://www.arm.linux.org.uk/developer/machines ). Encore name is also somewhat significant due to plenty of existing infrastructure depending on it. There are still plenty of stuff to add of course including the device drivers that probably needs to go through respective subsystem maintainers first. In this patchset the only updated bit that is not directly relevant to the board file is twl4030 that did not know anything about 65921 chip. Bye, Oleg -- 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: Fix bad SP address after relocating kernel
On Tue, 26 Apr 2011, Tony Lindgren wrote:
> Otherwise cache_clean_flush can overwrite some of the relocated
> area depending on where the kernel image gets loaded. This fixes
> booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
> (ARM: 6750/1: improvements to compressed/head.S).
Gh. Indeed.
> Thanks to Aaro Koskinen for debugging
> the address of the relocated area that gets corrupted, and to
> Nicolas Pitre for the other uncompress
> related fixes.
>
> Signed-off-by: Tony Lindgren
I think there could be a better fix yet. Could you test this patch:
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index adf583c..8e3c54b 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -838,9 +838,11 @@ __armv3_mmu_cache_off:
* Clean and flush the cache to maintain consistency.
*
* On exit,
- * r1, r2, r3, r9, r10, r11, r12 corrupted
+ * r0, r1, r2, r3, r5, r9, r10, r11, r12, sp corrupted
* This routine must preserve:
* r4, r6, r7, r8
+ *
+ * Yes, sp is destroyed by this call in the armv7 hierarchical case.
*/
.align 5
cache_clean_flush:
@@ -888,7 +890,6 @@ __armv7_mmu_cache_flush:
b iflush
hierarchical:
mcr p15, 0, r10, c7, c10, 5 @ DMB
- stmfd sp!, {r0-r7, r9-r11}
mrc p15, 1, r0, c0, c0, 1 @ read clidr
andsr3, r0, #0x700 @ extract loc from clidr
mov r3, r3, lsr #23 @ left align loc bit field
@@ -905,31 +906,31 @@ loop1:
mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
and r2, r1, #7 @ extract the length of the
cache lines
add r2, r2, #4 @ add 4 (line length offset)
- ldr r4, =0x3ff
- andsr4, r4, r1, lsr #3 @ find maximum number on the
way size
- clz r5, r4 @ find bit position of way size
increment
- ldr r7, =0x7fff
- andsr7, r7, r1, lsr #13 @ extract max number of the
index size
+ ldr r9, =0x3ff
+ andsr9, r9, r1, lsr #3 @ find maximum number on the
way size
+ clz r5, r9 @ find bit position of way size
increment
+ mov sp, r9
+ ldr r9, =0x7fff
+ andsr1, r9, r1, lsr #13 @ extract max number of the
index size
loop2:
- mov r9, r4 @ create working copy of max
way size
+ mov r9, sp @ create working copy of max
way size
loop3:
ARM( orr r11, r10, r9, lsl r5) @ factor way and cache number
into r11
- ARM( orr r11, r11, r7, lsl r2) @ factor index number into r11
- THUMB(lsl r6, r9, r5 )
- THUMB(orr r11, r10, r6) @ factor way and
cache number into r11
- THUMB(lsl r6, r7, r2 )
- THUMB(orr r11, r11, r6) @ factor index number
into r11
+ ARM( orr r11, r11, r1, lsl r2) @ factor index number into r11
+ THUMB(lsl r12, r9, r5 )
+ THUMB(orr r11, r10, r12 ) @ factor way and
cache number into r11
+ THUMB(lsl r12, r1, r2 )
+ THUMB(orr r11, r11, r12 ) @ factor index number
into r11
mcr p15, 0, r11, c7, c14, 2 @ clean & invalidate by set/way
subsr9, r9, #1 @ decrement the way
bge loop3
- subsr7, r7, #1 @ decrement the index
+ subsr1, r1, #1 @ decrement the index
bge loop2
skip:
add r10, r10, #2@ increment cache number
cmp r3, r10
bgt loop1
finished:
- ldmfd sp!, {r0-r7, r9-r11}
mov r10, #0 @ swith back to cache level 0
mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
iflush:
--
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] arm: omap: gpmc-smsc911x: minor style fixes
On Tue, Apr 26, 2011 at 11:25, Igor Grinberg wrote:
>
> replace "printk(KERN_ERR" by "pr_err("
> and fix needlessly multi-lined #ifdef
>
> Signed-off-by: Igor Grinberg
Acked-by: Nishanth Menon
Regards,
Nishanth Menon
> ---
> v2: added pr_fmt so the pr_*() calls would be cleaner (thanks Nishanth)
> Nishanth, this time it does not affect the n-o-l,
> but it is indeed cleaner
>
>
> arch/arm/mach-omap2/gpmc-smsc911x.c | 14 +++---
> arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 3 +--
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
> b/arch/arm/mach-omap2/gpmc-smsc911x.c
> index d30293a..e09374a 100644
> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
> @@ -10,6 +10,7 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> +#define pr_fmt(fmt) "%s: " fmt, __func__
>
> #include
> #include
> @@ -55,7 +56,7 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> gpmc_cfg = board_data;
>
> if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
> - printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
> + pr_err("Failed to request GPMC mem region\n");
> return;
> }
>
> @@ -63,8 +64,7 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
>
> if (gpio_request(gpmc_cfg->gpio_irq, "smsc911x irq") < 0) {
> - printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
> - gpmc_cfg->gpio_irq);
> + pr_err("Failed to request IRQ GPIO%d\n", gpmc_cfg->gpio_irq);
> goto free1;
> }
>
> @@ -74,8 +74,8 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> if (gpio_is_valid(gpmc_cfg->gpio_reset)) {
> ret = gpio_request(gpmc_cfg->gpio_reset, "smsc911x reset");
> if (ret) {
> - printk(KERN_ERR "Failed to request GPIO%d for
> smsc911x reset\n",
> - gpmc_cfg->gpio_reset);
> + pr_err("Failed to request reset GPIO%d\n",
> + gpmc_cfg->gpio_reset);
> goto free2;
> }
>
> @@ -92,7 +92,7 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
> &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
> if (!pdev) {
> - printk(KERN_ERR "Unable to register smsc911x device\n");
> + pr_err("Unable to register platform device\n");
> gpio_free(gpmc_cfg->gpio_reset);
> goto free2;
> }
> @@ -104,5 +104,5 @@ free2:
> free1:
> gpmc_cs_free(gpmc_cfg->cs);
>
> - printk(KERN_ERR "Could not initialize smsc911x\n");
> + pr_err("Could not initialize smsc911x device\n");
> }
> diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> index d3f1579..ea6c9c8 100644
> --- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> @@ -21,8 +21,7 @@ struct omap_smsc911x_platform_data {
> u32 flags;
> };
>
> -#if defined(CONFIG_SMSC911X) || \
> - defined(CONFIG_SMSC911X_MODULE)
> +#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
>
> extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
>
> --
> 1.7.3.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] mfd: Fix usbhs_enable error handling
On 04/26/11 12:34, Felipe Balbi wrote: > > care to reply to this one with your Tested-by so I add to all patches > and queue them to Greg ? > I just checked and these changes were part of the 3 patch set from Keshava, and from the Beagleboard XM perspective it works and you can include my Tested-by: Steve Calfee -- 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: cm-t3517: fix section mismatch warning
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x11014): Section mismatch
in reference from the function cm_t3517_init_usbh() to the (unknown
reference) .init.data:(unknown)
The function cm_t3517_init_usbh() references
the (unknown reference) __initdata (unknown).
This is often because cm_t3517_init_usbh lacks a __initdata
annotation or the annotation of (unknown) is wrong.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index a27e3ee..802cb60 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -178,7 +178,7 @@ static struct usbhs_omap_board_data cm_t3517_ehci_pdata
__initdata = {
.reset_gpio_port[2] = -EINVAL,
};
-static int cm_t3517_init_usbh(void)
+static int __init cm_t3517_init_usbh(void)
{
int err;
--
1.7.3.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] mfd: Fix usbhs_enable error handling
On Tue, Apr 26, 2011 at 08:09:17AM -0700, Steve Calfee wrote: > On Tue, Apr 26, 2011 at 2:04 AM, Felipe Balbi wrote: > > On Tue, Apr 26, 2011 at 02:32:04PM +0530, Keshava Munegowda wrote: > >> > -Original Message- > >> > From: Felipe Balbi [mailto:ba...@ti.com] > >> > Sent: Tuesday, April 26, 2011 2:29 PM > >> > To: Keshava Munegowda > >> > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com; > >> gadi...@ti.com; p- > >> > bas...@ti.com; axel@gmail.com; johns...@us.ibm.com; > >> mpfj-l...@mimc.co.uk > >> > Subject: Re: [PATCH] mfd: Fix usbhs_enable error handling > >> > > >> > Hi, > >> > > >> > On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote: > >> > > From: Axel Lin > >> > > > >> > > In the case of missing platform_data we do not hold a spin_lock, > >> > > thus we should not call spin_unlock_irqrestore in the error path. > >> > > > >> > > Also simplify the error handling by separating the successful path > >> > > from error path. I think this change improves readability. > >> > > > >> > > Signed-off-by: Axel Lin > >> > > >> > Can someone give me a Tested-by so I can take these patches. > >> > > >> > -- > >> > Balbi > >> > >> Hi Balbi > >> > >> I have validated this patch and it works :) > >> > >> Tested-by: Keshava Munegowda > > > > what about the others ? > > > > -- > > balbi > > Hi Felipe, > > I responded on another thread. I tested this on a beagleboardxm on > version 2.6.39-rc4 care to reply to this one with your Tested-by so I add to all patches and queue them to Greg ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] PM / AVR32: Use struct syscore_ops instead of sysdevs for PM
On Tuesday, April 26, 2011, Hans-Christian Egtvedt wrote: > On Sun, 2011-04-17 at 23:13 +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Convert some AVR32 architecture's code to using struct syscore_ops > > objects for power management instead of sysdev classes and sysdevs. > > > > This simplifies the code and reduces the kernel's memory footprint. > > It also is necessary for removing sysdevs from the kernel entirely in > > the future. > > > > Signed-off-by: Rafael J. Wysocki > > Acked-by: Hans-Christian Egtvedt > > Thanks, nice work. Tested and run on hardware. Thanks! Rafael -- 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] arm: omap: gpmc-smsc911x: minor style fixes
replace "printk(KERN_ERR" by "pr_err("
and fix needlessly multi-lined #ifdef
Signed-off-by: Igor Grinberg
---
v2: added pr_fmt so the pr_*() calls would be cleaner (thanks Nishanth)
Nishanth, this time it does not affect the n-o-l,
but it is indeed cleaner
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 +++---
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |3 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index d30293a..e09374a 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -10,6 +10,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#define pr_fmt(fmt) "%s: " fmt, __func__
#include
#include
@@ -55,7 +56,7 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
- printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
+ pr_err("Failed to request GPMC mem region\n");
return;
}
@@ -63,8 +64,7 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
if (gpio_request(gpmc_cfg->gpio_irq, "smsc911x irq") < 0) {
- printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
- gpmc_cfg->gpio_irq);
+ pr_err("Failed to request IRQ GPIO%d\n", gpmc_cfg->gpio_irq);
goto free1;
}
@@ -74,8 +74,8 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
if (gpio_is_valid(gpmc_cfg->gpio_reset)) {
ret = gpio_request(gpmc_cfg->gpio_reset, "smsc911x reset");
if (ret) {
- printk(KERN_ERR "Failed to request GPIO%d for smsc911x
reset\n",
- gpmc_cfg->gpio_reset);
+ pr_err("Failed to request reset GPIO%d\n",
+ gpmc_cfg->gpio_reset);
goto free2;
}
@@ -92,7 +92,7 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
&gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
if (!pdev) {
- printk(KERN_ERR "Unable to register smsc911x device\n");
+ pr_err("Unable to register platform device\n");
gpio_free(gpmc_cfg->gpio_reset);
goto free2;
}
@@ -104,5 +104,5 @@ free2:
free1:
gpmc_cs_free(gpmc_cfg->cs);
- printk(KERN_ERR "Could not initialize smsc911x\n");
+ pr_err("Could not initialize smsc911x device\n");
}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index d3f1579..ea6c9c8 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -21,8 +21,7 @@ struct omap_smsc911x_platform_data {
u32 flags;
};
-#if defined(CONFIG_SMSC911X) || \
- defined(CONFIG_SMSC911X_MODULE)
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
--
1.7.3.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 2/2] arm: omap: gpmc-smsc911x: minor style fixes
On 04/26/11 17:49, Menon, Nishanth wrote:
> On Tue, Apr 26, 2011 at 09:40, Igor Grinberg wrote:
>> Hi Nishanth,
>>
>> On 04/26/11 16:45, Menon, Nishanth wrote:
>>
>>> On Thu, Apr 21, 2011 at 09:50, Igor Grinberg
>>> wrote:
replace "printk(KERN_ERR" by "pr_err("
and fix needlessly multi-lined #ifdef
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 +++---
arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |3 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index d30293a..b45efff 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
>>> minor suggestion: wont using pr_fmt help to reduce the need to add %s,
>>> __func__ for pr_err through out the file?
>> I don't understand of what "need" are you talking about.
>> I don't know of any need to add "%s, __func__" with pr_fmt...
>> I've added "%s, __func__" as a meter of choice.
>> IMO, it makes it easier to parse the dmesg output.
>> If anyone objects it, I can remove them,
>> but I think both pr_fmt and __func__ are nice here and
>> way better then "printk(KERN_*" with embedded "smsc911x".
> Allow me to rephrase.
> I like the change of printk->pr_err - thanks for doing it. just
> suggesting a minor improvement
>
> if you add the following line before the #includes
> #define pr_fmt(fmt) "%s: " fmt, __func__
> then
> - printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
> - gpmc_cfg->gpio_irq);
> + pr_err("%s: Failed to request IRQ GPIO%d\n", __func__,
> + gpmc_cfg->gpio_irq);
> becomes,
> - printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
> - gpmc_cfg->gpio_irq);
> + pr_err("Failed to request IRQ GPIO%d\n", gpmc_cfg->gpio_irq);
>
> Both give you exactly the output you would like to see (which I
> personally prefer as well), but the second could be lesser lines of
> code change ;)
Ahh, now I understand, that can be useful indeed.
I'll send a v2...
Thanks
--
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] mfd: Fix usbhs_enable error handling
On Tue, Apr 26, 2011 at 2:04 AM, Felipe Balbi wrote: > On Tue, Apr 26, 2011 at 02:32:04PM +0530, Keshava Munegowda wrote: >> > -Original Message- >> > From: Felipe Balbi [mailto:ba...@ti.com] >> > Sent: Tuesday, April 26, 2011 2:29 PM >> > To: Keshava Munegowda >> > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com; >> gadi...@ti.com; p- >> > bas...@ti.com; axel@gmail.com; johns...@us.ibm.com; >> mpfj-l...@mimc.co.uk >> > Subject: Re: [PATCH] mfd: Fix usbhs_enable error handling >> > >> > Hi, >> > >> > On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote: >> > > From: Axel Lin >> > > >> > > In the case of missing platform_data we do not hold a spin_lock, >> > > thus we should not call spin_unlock_irqrestore in the error path. >> > > >> > > Also simplify the error handling by separating the successful path >> > > from error path. I think this change improves readability. >> > > >> > > Signed-off-by: Axel Lin >> > >> > Can someone give me a Tested-by so I can take these patches. >> > >> > -- >> > Balbi >> >> Hi Balbi >> >> I have validated this patch and it works :) >> >> Tested-by: Keshava Munegowda > > what about the others ? > > -- > balbi Hi Felipe, I responded on another thread. I tested this on a beagleboardxm on version 2.6.39-rc4 > Hi Keshava, > > I rebuilt my system to boot from flash and now I see what happened. I > even remember it being discussed on this list. Someone renamed my usb > ethernet device from usb0 to eth0 !!! The boot log shows it on this line: > > > [4.596130] smsc95xx 1-2.1:1.0: eth0: register 'smsc95xx' at > > usb-ehci-omap.0d > > > So this broke my init scripts and uboot script... OK, so I can live with > this (I hope the name doesn't change too often though). > > So I can manually configure my system to use eth0 and use the network. I > am sure I will get nfs working shortly. > > I am using the 2.6.39-rc4 with your 3 patches. So from the Beagleboard > XM perspective it works and you can include my > > Tested-by: Steve Calfee -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: gpmc-smsc911x: minor style fixes
On Tue, Apr 26, 2011 at 09:40, Igor Grinberg wrote:
> Hi Nishanth,
>
> On 04/26/11 16:45, Menon, Nishanth wrote:
>
>> On Thu, Apr 21, 2011 at 09:50, Igor Grinberg wrote:
>>> replace "printk(KERN_ERR" by "pr_err("
>>> and fix needlessly multi-lined #ifdef
>>>
>>> Signed-off-by: Igor Grinberg
>>> ---
>>> arch/arm/mach-omap2/gpmc-smsc911x.c | 14 +++---
>>> arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 3 +--
>>> 2 files changed, 8 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
>>> b/arch/arm/mach-omap2/gpmc-smsc911x.c
>>> index d30293a..b45efff 100644
>>> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
>>> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
>> minor suggestion: wont using pr_fmt help to reduce the need to add %s,
>> __func__ for pr_err through out the file?
>
> I don't understand of what "need" are you talking about.
> I don't know of any need to add "%s, __func__" with pr_fmt...
> I've added "%s, __func__" as a meter of choice.
> IMO, it makes it easier to parse the dmesg output.
> If anyone objects it, I can remove them,
> but I think both pr_fmt and __func__ are nice here and
> way better then "printk(KERN_*" with embedded "smsc911x".
Allow me to rephrase.
I like the change of printk->pr_err - thanks for doing it. just
suggesting a minor improvement
if you add the following line before the #includes
#define pr_fmt(fmt) "%s: " fmt, __func__
then
- printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
- gpmc_cfg->gpio_irq);
+ pr_err("%s: Failed to request IRQ GPIO%d\n", __func__,
+ gpmc_cfg->gpio_irq);
becomes,
- printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
- gpmc_cfg->gpio_irq);
+ pr_err("Failed to request IRQ GPIO%d\n", gpmc_cfg->gpio_irq);
Both give you exactly the output you would like to see (which I
personally prefer as well), but the second could be lesser lines of
code change ;)
Regards,
Nishanth Menon
>
>>> @@ -55,7 +55,7 @@ void __init gpmc_smsc911x_init(struct
>>> omap_smsc911x_platform_data *board_data)
>>> gpmc_cfg = board_data;
>>>
>>> if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
>>> - printk(KERN_ERR "Failed to request GPMC mem for
>>> smsc911x\n");
>>> + pr_err("%s: Failed to request GPMC mem region\n", __func__);
>>> return;
>>> }
>>>
>>> @@ -63,8 +63,8 @@ void __init gpmc_smsc911x_init(struct
>>> omap_smsc911x_platform_data *board_data)
>>> gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
>>>
>>> if (gpio_request(gpmc_cfg->gpio_irq, "smsc911x irq") < 0) {
>>> - printk(KERN_ERR "Failed to request GPIO%d for smsc911x
>>> IRQ\n",
>>> - gpmc_cfg->gpio_irq);
>>> + pr_err("%s: Failed to request IRQ GPIO%d\n", __func__,
>>> + gpmc_cfg->gpio_irq);
>>> goto free1;
>>> }
>>>
>>> @@ -74,8 +74,8 @@ void __init gpmc_smsc911x_init(struct
>>> omap_smsc911x_platform_data *board_data)
>>> if (gpio_is_valid(gpmc_cfg->gpio_reset)) {
>>> ret = gpio_request(gpmc_cfg->gpio_reset, "smsc911x reset");
>>> if (ret) {
>>> - printk(KERN_ERR "Failed to request GPIO%d for
>>> smsc911x reset\n",
>>> - gpmc_cfg->gpio_reset);
>>> + pr_err("%s: Failed to request reset GPIO%d\n",
>>> __func__,
>>> + gpmc_cfg->gpio_reset);
>>> goto free2;
>>> }
>>>
>>> @@ -92,7 +92,7 @@ void __init gpmc_smsc911x_init(struct
>>> omap_smsc911x_platform_data *board_data)
>>> gpmc_smsc911x_resources,
>>> ARRAY_SIZE(gpmc_smsc911x_resources),
>>> &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
>>> if (!pdev) {
>>> - printk(KERN_ERR "Unable to register smsc911x device\n");
>>> + pr_err("%s: Unable to register platform device\n",
>>> __func__);
>>> gpio_free(gpmc_cfg->gpio_reset);
>>> goto free2;
>>> }
>>> @@ -104,5 +104,5 @@ free2:
>>> free1:
>>> gpmc_cs_free(gpmc_cfg->cs);
>>>
>>> - printk(KERN_ERR "Could not initialize smsc911x\n");
>>> + pr_err("Could not initialize smsc911x\n");
>>> }
>>> diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>>> b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>>> index d3f1579..ea6c9c8 100644
>>> --- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>>> +++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>>> @@ -21,8 +21,7 @@ struct omap_smsc911x_platform_data {
>>> u32 flags;
>>> };
>>>
>>> -#if defined(CONFIG_SMSC911X) || \
>>> - defined(CONFIG_SMSC911X_MODULE)
>>> +#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MO
Re: [PATCH 13/15] OMAP: GPIO: cleanup _set_gpio_wakeup(), remove ifdefs
On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
> Make _set_gpio_wakeup() generic by removing ifdefs. Code for the
> various SoCs/bank-methods was already the same, except for the
> non-wakeup GPIO checking. But that flag is set on a per-SoC basis, so
> can be used for all SoCs.
>
> While here, use pr_err() and remove GPIO bank calculation assumption
> based on subtracting bank pointers.
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/plat-omap/gpio.c | 49 +---
> 1 files changed, 15 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index a025b7a..82afed8 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -535,42 +535,23 @@ static inline void _set_gpio_irqenable(struct gpio_bank
> *bank, int gpio, int ena
> */
> static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
> {
> - unsigned long uninitialized_var(flags);
> + u32 gpio_bit = GPIO_BIT(bank, gpio);
> + unsigned long flags;
>
> - switch (bank->method) {
> -#ifdef CONFIG_ARCH_OMAP16XX
> - case METHOD_MPUIO:
> - case METHOD_GPIO_1610:
> - spin_lock_irqsave(&bank->lock, flags);
> - if (enable)
> - bank->suspend_wakeup |= (1 << gpio);
> - else
> - bank->suspend_wakeup &= ~(1 << gpio);
> - spin_unlock_irqrestore(&bank->lock, flags);
> - return 0;
> -#endif
> -#ifdef CONFIG_ARCH_OMAP2PLUS
> - case METHOD_GPIO_24XX:
> - case METHOD_GPIO_44XX:
> - if (bank->non_wakeup_gpios & (1 << gpio)) {
> - printk(KERN_ERR "Unable to modify wakeup on "
> - "non-wakeup GPIO%d\n",
> - (bank - gpio_bank) * bank->width + gpio);
> - return -EINVAL;
> - }
> - spin_lock_irqsave(&bank->lock, flags);
> - if (enable)
> - bank->suspend_wakeup |= (1 << gpio);
> - else
> - bank->suspend_wakeup &= ~(1 << gpio);
> - spin_unlock_irqrestore(&bank->lock, flags);
> - return 0;
> -#endif
> - default:
> - printk(KERN_ERR "Can't enable GPIO wakeup for method %i\n",
> - bank->method);
> + if (bank->non_wakeup_gpios & gpio_bit) {
> + pr_err("Unable to modify wakeup on non-wakeup GPIO%d\n",
> gpio);
use dev_err instead.
-V Charulatha
<>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: gpmc-smsc911x: minor style fixes
Hi Nishanth,
On 04/26/11 16:45, Menon, Nishanth wrote:
> On Thu, Apr 21, 2011 at 09:50, Igor Grinberg wrote:
>> replace "printk(KERN_ERR" by "pr_err("
>> and fix needlessly multi-lined #ifdef
>>
>> Signed-off-by: Igor Grinberg
>> ---
>> arch/arm/mach-omap2/gpmc-smsc911x.c | 14 +++---
>> arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |3 +--
>> 2 files changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
>> b/arch/arm/mach-omap2/gpmc-smsc911x.c
>> index d30293a..b45efff 100644
>> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
>> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
> minor suggestion: wont using pr_fmt help to reduce the need to add %s,
> __func__ for pr_err through out the file?
I don't understand of what "need" are you talking about.
I don't know of any need to add "%s, __func__" with pr_fmt...
I've added "%s, __func__" as a meter of choice.
IMO, it makes it easier to parse the dmesg output.
If anyone objects it, I can remove them,
but I think both pr_fmt and __func__ are nice here and
way better then "printk(KERN_*" with embedded "smsc911x".
>> @@ -55,7 +55,7 @@ void __init gpmc_smsc911x_init(struct
>> omap_smsc911x_platform_data *board_data)
>>gpmc_cfg = board_data;
>>
>>if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
>> - printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
>> + pr_err("%s: Failed to request GPMC mem region\n", __func__);
>>return;
>>}
>>
>> @@ -63,8 +63,8 @@ void __init gpmc_smsc911x_init(struct
>> omap_smsc911x_platform_data *board_data)
>>gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
>>
>>if (gpio_request(gpmc_cfg->gpio_irq, "smsc911x irq") < 0) {
>> - printk(KERN_ERR "Failed to request GPIO%d for smsc911x
>> IRQ\n",
>> - gpmc_cfg->gpio_irq);
>> + pr_err("%s: Failed to request IRQ GPIO%d\n", __func__,
>> + gpmc_cfg->gpio_irq);
>>goto free1;
>>}
>>
>> @@ -74,8 +74,8 @@ void __init gpmc_smsc911x_init(struct
>> omap_smsc911x_platform_data *board_data)
>>if (gpio_is_valid(gpmc_cfg->gpio_reset)) {
>>ret = gpio_request(gpmc_cfg->gpio_reset, "smsc911x reset");
>>if (ret) {
>> - printk(KERN_ERR "Failed to request GPIO%d for
>> smsc911x reset\n",
>> - gpmc_cfg->gpio_reset);
>> + pr_err("%s: Failed to request reset GPIO%d\n",
>> __func__,
>> + gpmc_cfg->gpio_reset);
>>goto free2;
>>}
>>
>> @@ -92,7 +92,7 @@ void __init gpmc_smsc911x_init(struct
>> omap_smsc911x_platform_data *board_data)
>> gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
>> &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
>>if (!pdev) {
>> - printk(KERN_ERR "Unable to register smsc911x device\n");
>> + pr_err("%s: Unable to register platform device\n", __func__);
>>gpio_free(gpmc_cfg->gpio_reset);
>>goto free2;
>>}
>> @@ -104,5 +104,5 @@ free2:
>> free1:
>>gpmc_cs_free(gpmc_cfg->cs);
>>
>> - printk(KERN_ERR "Could not initialize smsc911x\n");
>> + pr_err("Could not initialize smsc911x\n");
>> }
>> diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>> b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>> index d3f1579..ea6c9c8 100644
>> --- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>> +++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
>> @@ -21,8 +21,7 @@ struct omap_smsc911x_platform_data {
>>u32 flags;
>> };
>>
>> -#if defined(CONFIG_SMSC911X) || \
>> - defined(CONFIG_SMSC911X_MODULE)
>> +#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
>>
>> extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
>>
>> --
>> 1.7.3.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
>>
--
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 2/2] arm: omap: gpmc-smsc911x: minor style fixes
On Thu, Apr 21, 2011 at 09:50, Igor Grinberg wrote:
> replace "printk(KERN_ERR" by "pr_err("
> and fix needlessly multi-lined #ifdef
>
> Signed-off-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/gpmc-smsc911x.c | 14 +++---
> arch/arm/plat-omap/include/plat/gpmc-smsc911x.h | 3 +--
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
> b/arch/arm/mach-omap2/gpmc-smsc911x.c
> index d30293a..b45efff 100644
> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
minor suggestion: wont using pr_fmt help to reduce the need to add %s,
__func__ for pr_err through out the file?
Regards,
Nishanth Menon
> @@ -55,7 +55,7 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> gpmc_cfg = board_data;
>
> if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
> - printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
> + pr_err("%s: Failed to request GPMC mem region\n", __func__);
> return;
> }
>
> @@ -63,8 +63,8 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> gpmc_smsc911x_resources[0].end = cs_mem_base + 0xff;
>
> if (gpio_request(gpmc_cfg->gpio_irq, "smsc911x irq") < 0) {
> - printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
> - gpmc_cfg->gpio_irq);
> + pr_err("%s: Failed to request IRQ GPIO%d\n", __func__,
> + gpmc_cfg->gpio_irq);
> goto free1;
> }
>
> @@ -74,8 +74,8 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> if (gpio_is_valid(gpmc_cfg->gpio_reset)) {
> ret = gpio_request(gpmc_cfg->gpio_reset, "smsc911x reset");
> if (ret) {
> - printk(KERN_ERR "Failed to request GPIO%d for
> smsc911x reset\n",
> - gpmc_cfg->gpio_reset);
> + pr_err("%s: Failed to request reset GPIO%d\n",
> __func__,
> + gpmc_cfg->gpio_reset);
> goto free2;
> }
>
> @@ -92,7 +92,7 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *board_data)
> gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
> &gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
> if (!pdev) {
> - printk(KERN_ERR "Unable to register smsc911x device\n");
> + pr_err("%s: Unable to register platform device\n", __func__);
> gpio_free(gpmc_cfg->gpio_reset);
> goto free2;
> }
> @@ -104,5 +104,5 @@ free2:
> free1:
> gpmc_cs_free(gpmc_cfg->cs);
>
> - printk(KERN_ERR "Could not initialize smsc911x\n");
> + pr_err("Could not initialize smsc911x\n");
> }
> diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> index d3f1579..ea6c9c8 100644
> --- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
> @@ -21,8 +21,7 @@ struct omap_smsc911x_platform_data {
> u32 flags;
> };
>
> -#if defined(CONFIG_SMSC911X) || \
> - defined(CONFIG_SMSC911X_MODULE)
> +#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
>
> extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
>
> --
> 1.7.3.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:usb: fixing ehci phy gpio values for omap3
On Thu, Apr 21, 2011 at 09:22, Keshava Munegowda wrote:
>
> From: Keshava Munegowda
>
> The gpio of EHCI phy should be 0 instead of 1;
> This fixes the hub enumeration issue in beagle xm board.
>
> Signed-off-by: Keshava Munegowda
Dumb q1: Has this been tested on PandaBoard?
Dumb q2: is'nt it better to introduce polarity e.g.
pdata->ehci_data->reset_gpio_polarity etc? this will allow board files
to describe polarity of pin information to driver which can then be
Phy and any board specific mods(e.g. inverter on the line) independent
completely..
Regards,
Nishanth Menon
> ---
> drivers/mfd/omap-usb-host.c | 8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index b3bb3ac..a12202e 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -718,14 +718,14 @@ static int usbhs_enable(struct device *dev)
> gpio_request(pdata->ehci_data->reset_gpio_port[0],
> "USB1 PHY reset");
> gpio_direction_output
> - (pdata->ehci_data->reset_gpio_port[0], 1);
> + (pdata->ehci_data->reset_gpio_port[0], 0);
> }
>
> if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1])) {
> gpio_request(pdata->ehci_data->reset_gpio_port[1],
> "USB2 PHY reset");
> gpio_direction_output
> - (pdata->ehci_data->reset_gpio_port[1], 1);
> + (pdata->ehci_data->reset_gpio_port[1], 0);
> }
>
> /* Hold the PHY in RESET for enough time till DIR is high */
> @@ -905,11 +905,11 @@ static int usbhs_enable(struct device *dev)
>
> if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
> gpio_set_value
> - (pdata->ehci_data->reset_gpio_port[0], 0);
> + (pdata->ehci_data->reset_gpio_port[0], 1);
>
> if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1]))
> gpio_set_value
> - (pdata->ehci_data->reset_gpio_port[1], 0);
> + (pdata->ehci_data->reset_gpio_port[1], 1);
> }
>
> end_count:
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/15] OMAP: GPIO: consolidate IRQ status handling, remove #ifdefs
Kevin,
On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
> Cleanup IRQ status handling by by passing IRQ status register offsets
> via platform data.
Typo: by by
>
> Cleans up clearing of GPIO IRQ status and GPIO ISR handler.
>
> Signed-off-by: Kevin Hilman
> ---
<>
> diff --git a/arch/arm/plat-omap/include/plat/gpio.h
> b/arch/arm/plat-omap/include/plat/gpio.h
> index 268bccd..aedd732 100644
> --- a/arch/arm/plat-omap/include/plat/gpio.h
> +++ b/arch/arm/plat-omap/include/plat/gpio.h
> @@ -180,6 +180,8 @@ struct omap_gpio_reg_offs {
> u16 dataout;
> u16 set_dataout;
> u16 clr_dataout;
> + u16 irqstatus;
> + u16 irqstatus2;
Would it be appropriate to name them as (irqstatus1 & irqstatus2)
or (irqstatus & irqstatus1)?
-V Charulatha
> };
>
> struct omap_gpio_platform_data {
> --
> 1.7.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: Fix bad SP address after relocating kernel
Otherwise cache_clean_flush can overwrite some of the relocated area depending on where the kernel image gets loaded. This fixes booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S). Thanks to Aaro Koskinen for debugging the address of the relocated area that gets corrupted, and to Nicolas Pitre for the other uncompress related fixes. Signed-off-by: Tony Lindgren --- I think this is the right fix.. And we don't want to mess with the ZBOOT_ROM sp address, right? --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -253,6 +253,15 @@ restart: adr r0, LC0 /* Preserve offset to relocated code. */ sub r6, r9, r6 +#ifndef CONFIG_ZBOOT_ROM + /* +* Fix sp to use the relocated address in case old sp is +* within the relocated area. Otherwise cache_clean_flush +* will trash some of the relocated area. +*/ + add sp, r6 +#endif + bl cache_clean_flush adr r0, BSYM(restart) -- 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 10/15] OMAP: GPIO: conslidate enable/disable of GPIO IRQs, remove ifdefs
Kevin,
On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
> Cleanup GPIO IRQ enable/disable handling by removing SoC-specific
>
> Also split enable/disable IRQ into separate functions for better
> readability and also facilitate potentially moving to generic irq_chip
> in the future.
>
> Signed-off-by: Kevin Hilman
> ---
<>
> static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
> index 35e8b31..880f3cb 100644
> --- a/arch/arm/mach-omap1/gpio7xx.c
> +++ b/arch/arm/mach-omap1/gpio7xx.c
> @@ -44,6 +44,8 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
> .datain = OMAP_MPUIO_INPUT_LATCH / 2,
> .dataout = OMAP_MPUIO_OUTPUT / 2,
> .irqstatus = OMAP_MPUIO_GPIO_INT / 2,
> + .irqenable = OMAP_MPUIO_GPIO_MASKIT / 2,
> + .irqenable_inv = true,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
> @@ -82,6 +84,8 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
> .datain = OMAP7XX_GPIO_DATA_INPUT,
> .dataout = OMAP7XX_GPIO_DATA_OUTPUT,
> .irqstatus = OMAP7XX_GPIO_INT_STATUS,
> + .irqenable = OMAP7XX_GPIO_INT_MASK,
> + .irqenable = true,
irqenable_inv should be true and not irqenable.
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
<>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 4f875cf..17833c8 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
<>
> -static void _enable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask, int
> enable)
> +static void _enable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask)
> {
> void __iomem *reg = bank->base;
> u32 l;
>
> - switch (bank->method) {
> -#ifdef CONFIG_ARCH_OMAP1
> - case METHOD_MPUIO:
> - reg += OMAP_MPUIO_GPIO_MASKIT / bank->stride;
> - l = __raw_readl(reg);
> - if (enable)
> - l &= ~(gpio_mask);
> - else
> - l |= gpio_mask;
> - break;
> -#endif
> -#ifdef CONFIG_ARCH_OMAP15XX
> - case METHOD_GPIO_1510:
> - reg += OMAP1510_GPIO_INT_MASK;
> + if (bank->regs->set_irqenable) {
> + reg += bank->regs->set_irqenable;
> + l = gpio_mask;
> + } else {
> + reg += bank->regs->irqenable;
> l = __raw_readl(reg);
> - if (enable)
> - l &= ~(gpio_mask);
> + if (bank->regs->irqenable_inv)
> + l &= ~gpio_mask;
> else
> l |= gpio_mask;
This else case code is required for _disable_gpio_irqbank() only.
There should be no else part here.
> - break;
> -#endif
> -#ifdef CONFIG_ARCH_OMAP16XX
> - case METHOD_GPIO_1610:
> - if (enable)
> - reg += OMAP1610_GPIO_SET_IRQENABLE1;
> - else
> - reg += OMAP1610_GPIO_CLEAR_IRQENABLE1;
> + }
> +
> + __raw_writel(l, reg);
> +}
> +
> +static void _disable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask)
> +{
> + void __iomem *reg = bank->base;
> + u32 l;
> +
> + if (bank->regs->clr_irqenable) {
> + reg += bank->regs->clr_irqenable;
> l = gpio_mask;
> - break;
> -#endif
> -#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
> - case METHOD_GPIO_7XX:
> - reg += OMAP7XX_GPIO_INT_MASK;
> + } else {
> + reg += bank->regs->irqenable;
> l = __raw_readl(reg);
> - if (enable)
> - l &= ~(gpio_mask);
> - else
> + if (bank->regs->irqenable_inv)
> l |= gpio_mask;
> - break;
> -#endif
> -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> - case METHOD_GPIO_24XX:
> - if (enable)
> - reg += OMAP24XX_GPIO_SETIRQENABLE1;
> - else
> - reg += OMAP24XX_GPIO_CLEARIRQENABLE1;
> - l = gpio_mask;
> - break;
> -#endif
> -#ifdef CONFIG_ARCH_OMAP4
> - case METHOD_GPIO_44XX:
> - if (enable)
> - reg += OMAP4_GPIO_IRQSTATUSSET0;
> else
> - reg += OMAP4_GPIO_IRQSTATUSCLR0;
> - l = gpio_mask;
> - break;
> -#endif
> - default:
> - WARN_ON(1);
> - return;
> + l &= ~gpio_mask;
This else case code is required for _enable_gpio_irqbank() only.
There should be no else part here.
> }
> +
> __raw_writel(l, reg);
> }
>
-V Charulatha
--
To unsubscribe from this list:
Re: [PATCH 11/14] PM / AVR32: Use struct syscore_ops instead of sysdevs for PM
On Sun, 2011-04-17 at 23:13 +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Convert some AVR32 architecture's code to using struct syscore_ops > objects for power management instead of sysdev classes and sysdevs. > > This simplifies the code and reduces the kernel's memory footprint. > It also is necessary for removing sysdevs from the kernel entirely in > the future. > > Signed-off-by: Rafael J. Wysocki Acked-by: Hans-Christian Egtvedt Thanks, nice work. Tested and run on hardware. -- Hans-Christian Egtvedt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] OMAP: GPIO: convert MPUIO IRQ over to generic irq_chip
Kevin, On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote: > Signed-off-by: Kevin Hilman > --- > arch/arm/plat-omap/gpio.c | 74 ++-- > 1 files changed, 30 insertions(+), 44 deletions(-) > Patch description is missing. -V Charulatha <> -- 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 15/15] OMAP: GPIO: cleanup show revision, remove cpu_is checks, display only once
Kevin,
On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
> Remove cpu_is_* checks from gpio_show_revision() by passing in the
> revision address offset from platform data. SoCs with no revision
> register (15xx, 7xx, and all MPUIOs) use -1 to signify no register.
>
> While here, all GPIO banks are assumed to be the same revision, so fix
> show_revision() to only show the revision for the first bank it finds.
> This removes duplicate GPIO revision prints during boot.
>
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap1/gpio15xx.c | 2 ++
> arch/arm/mach-omap1/gpio16xx.c | 2 ++
> arch/arm/mach-omap1/gpio7xx.c | 2 ++
> arch/arm/mach-omap2/gpio.c | 2 ++
> arch/arm/plat-omap/gpio.c | 14 ++
> arch/arm/plat-omap/include/plat/gpio.h | 1 +
> 6 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
> index 9175624..6f77c36 100644
> --- a/arch/arm/mach-omap1/gpio15xx.c
> +++ b/arch/arm/mach-omap1/gpio15xx.c
> @@ -35,6 +35,7 @@ static struct __initdata resource
> omap15xx_mpu_gpio_resources[] = {
> };
>
> static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
> + .revision = -1,
Assigning -1 to u16 type. Instead you may want to use 0x?
> .direction = OMAP_MPUIO_IO_CNTL,
> .datain = OMAP_MPUIO_INPUT_LATCH,
> .dataout = OMAP_MPUIO_OUTPUT,
> @@ -75,6 +76,7 @@ static struct __initdata resource omap15xx_gpio_resources[]
> = {
> };
<>
> diff --git a/arch/arm/plat-omap/include/plat/gpio.h
> b/arch/arm/plat-omap/include/plat/gpio.h
> index 7a3f067..91e8de3 100644
> --- a/arch/arm/plat-omap/include/plat/gpio.h
> +++ b/arch/arm/plat-omap/include/plat/gpio.h
> @@ -175,6 +175,7 @@ struct omap_gpio_dev_attr {
> };
>
> struct omap_gpio_reg_offs {
> + u16 revision;
> u16 direction;
> u16 datain;
> u16 dataout;
-V Charulatha
--
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 5/7] OMAP: DSS: Adding initialization routine to picodlp panel
On Thu, 2011-04-21 at 16:47 +0530, Janorkar, Mayuresh wrote:
>
> > -Original Message-
> > From: Valkeinen, Tomi
> > Sent: Tuesday, April 19, 2011 5:23 PM
> > To: Janorkar, Mayuresh
> > Cc: linux-omap@vger.kernel.org; K, Mythri P
> > Subject: Re: [PATCH 5/7] OMAP: DSS: Adding initialization routine to
> > picodlp panel
> >
> > On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> > > static int picodlp_i2c_probe(struct i2c_client *client,
> > > const struct i2c_device_id *id)
> > > {
> > > @@ -134,6 +446,11 @@ static int picodlp_panel_power_on(struct
> > omap_dss_device *dssdev)
> > > picodlp_i2c_data =
> > > i2c_get_clientdata(picod->picodlp_i2c_client);
> > >
> > > + msleep(700); /* sleep till panel is settled */
> >
> > And another huge sleep. This, unlike the other sleeps, make some sense,
> > as there's an i2c transaction done below.
> >
> > Somehow I get the feeling that you've just put big sleeps here and there
> > until the driver started working... Can you point me to the
> > documentation that describes the delays required?
>
> Except msleep(5) in
> /* transfer control to flash controller */
> r = picodlp_i2c_write(client, PBC_CONTROL, 1);
> msleep(5);
> r = picodlp_i2c_write(client, PBC_CONTROL, 0);
>
> Other delays are not documented. But it is practically observed that we need
> to wait otherwise the i2c_packet does not succeed.
Then we need to contact the HW guys developing picodlp. They are TIers,
aren't they? We can't just put sleeps here and there and be sure it'll
work properly.
What if your sleep of 700ms has, by luck, caused a 900ms sleep in your
tests (sleeps can take considerably longer than the given value), and
the hardware requires 800ms sleep? Your tests show it works, but for
some other user the sleep may cause a 750ms sleep, causing picodlp to
fail to start.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/7] OMAP: DSS: Adding a picodlp panel driver
On Thu, 2011-04-21 at 16:36 +0530, Janorkar, Mayuresh wrote:
>
> > -Original Message-
> > From: Valkeinen, Tomi
> > Sent: Tuesday, April 19, 2011 4:40 PM
> > To: Janorkar, Mayuresh
> > Cc: linux-omap@vger.kernel.org; K, Mythri P
> > Subject: Re: [PATCH 3/7] OMAP: DSS: Adding a picodlp panel driver
> >
> > On Mon, 2011-04-18 at 11:45 +0530, Mayuresh Janorkar wrote:
> > > +static int picodlp_panel_power_on(struct omap_dss_device *dssdev)
> > > +{
> > > + int r;
> > > +
> > > + if (dssdev->platform_enable) {
> > > + r = dssdev->platform_enable(dssdev);
> > > + if (r)
> > > + return r;
> > > + }
> > > +
> > > + r = omapdss_dpi_display_enable(dssdev);
> > > + if (r) {
> > > + dev_err(&dssdev->dev, "failed to enable DPI\n");
> > > + goto err;
> > > + }
> > > + /* after enabling, wait for some initialize sync interrupts */
> > > + msleep(675);
> > > + dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
> > > +
> > > + return 0;
> > > +
> > > +err:
> > > + if (dssdev->platform_disable)
> > > + dssdev->platform_disable(dssdev);
> > > +
> > > + return r;
> > > +}
> >
> > Why is the msleep needed there? It's a huge sleep, and can't find
> > information about it from the documents you gave links to. I think I've
> > asked this three times already.
> >
>
> It is practically observed that without this delay the pico panel does not
> get initialized.
>
> > Also, it's rather strange to sleep at the end of the function. Normally
> > you would sleep between two actions.
>
> Some of the panels in drivers/video/omap2/displays sleep after
> dpi_display_enable.
Yes, but the drivers sleep between dpi_display_enable and
platform_enable. They don't sleep at the end of a function, they sleep
between two actions because the second action requires the first action
to be stabilized. More exactly, the panel needs to get the pixel clock
for a few frames to initialize itself, so that the image is stable when
the panel is taken out of reset.
> I agree here the sleep is huge. But I could not minimize it below this value.
> I can handle it in some other ways:
> See if the i2c_pakcet is sent. If not sent wait for some time ~50ms and then
> resend.
You need to find the documentation describing the power-up times to
understand what is required and where.
Most likely the case here is that picodlp takes rather long to wake up
after it's taken out of reset (i.e. platform_enabl. dpi_display_enable
probably doesn't have anything to do with this), and you need to wait
that time before sending i2c messages.
And if that is the case, you don't need to sleep after platform_enable
or dpi_display_enable, but before sending the first i2c message. And as
the sleep here is such a long sleep, I think it warrants some
optimization. If the sending of the i2c message happens in some other
function, you can store the timestamp at the time when the reset is
removed, and before sending the i2c message use the timestamp to sleep
enough to be sure the picodlp is up and running.
Tomi
--
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 v9 6/9] MFD: TWL4030: workaround changes for TWL4030 Erratum 27
Hi Lesly, On Thu, Apr 14, 2011 at 05:57:54PM +0530, Lesly A M wrote: > Workaround for TWL5030 Silicon Errata 27 & 28: > 27 - VDD1, VDD2, may have glitches when their output value is updated. > 28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock > is switched from internal to external. > > Erratum 27: > If the DCDC regulators is running on their internal oscillator, > negative glitches may occur on VDD1, VDD2 output when voltage is > changed. > The OMAP device may reboot if the VDD1 or VDD2 go below the > core minimum operating voltage. > > WORKAROUND > Set up the TWL5030 DC-DC power supplies to use the HFCLKIN instead of > the internal oscillator. > > Erratum 28: > VDD1/VDD2 clock system may hang during switching the clock source from > internal oscillator to external. VDD1/VDD2 output voltages may collapse > if clock stops. > > WORKAROUND > If HFCLK is disabled in OFFMODE, modify the sleep/wakeup sequence and > setuptimes to make sure the switching will happen only when HFCLKIN is > stable. > Also use the TWL5030 watchdog to safeguard the first switching from > internal oscillator to HFCLKIN during the TWL5030 init. > > IMPACT > power sequence is changed. > sleep/wakeup time values will be changed. > > The workaround changes are called from twl4030_power_init(), since we have to > make some i2c_read calls to check the TWL4030 version & the i2c will not be > initialized in the early stage. > > This workaround is required for TWL5030 Silicon version less than ES1.2 > The power script & setup time changes are recommended by TI HW team. > > http://omapedia.org/wiki/TWL4030_power_scripts > > Changes taken from TWL4030 Erratum 27 workaround patch by Nishanth Menon. This patch and the following one depend on patch#4. Please re-send it once you agreed with Tony about where it should go. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 5/9] OMAP3: PM: TWL5030 version checking
Hi Lesly, On Thu, Apr 14, 2011 at 05:57:53PM +0530, Lesly A M wrote: > Added API to get the TWL5030 Si version from the IDCODE register. > It is used for enabling the workaround for TWL erratum 27. Patch applied to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/9] OMAP3: PM: Modifying the macro name Main_Ref to all caps
Hi Lesly, On Thu, Apr 14, 2011 at 05:57:51PM +0530, Lesly A M wrote: > Modifying the macro name Main_Ref to all caps(MAIN_REF). Patch applied to my for-next branch. Be careful with the patch subject, this one is definitely not OMAP3 related. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 2/9] OMAP3: PM: Correct the warning print during script loading
Hi Lesly, On Thu, Apr 14, 2011 at 05:57:50PM +0530, Lesly A M wrote: > Correcting the if condition check for printing the warning, > if wakeup script is not updated before updating the sleep script. > > Since the flag 'order' is set to '1' while updating the wakeup script for > P1P2, > the condition checking for printing the warning should be if(!order) > (ie: print the warning if wakeup script is not updated before updating the > sleep script) > Patch applied to my for-next branch, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 1/9] OMAP3: PM: Fix for the TWL4030 sleep/wakeup sequence
Hi Lesly, On Thu, Apr 14, 2011 at 05:57:49PM +0530, Lesly A M wrote: > Only configure sleep script when the flag is TWL4030_SLEEP_SCRIPT. > > Adding the missing brackets for fixing the issue. Patch applied to my for-linus branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Fix usbhs_enable error handling
On Tue, Apr 26, 2011 at 02:32:04PM +0530, Keshava Munegowda wrote: > > -Original Message- > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Tuesday, April 26, 2011 2:29 PM > > To: Keshava Munegowda > > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com; > gadi...@ti.com; p- > > bas...@ti.com; axel@gmail.com; johns...@us.ibm.com; > mpfj-l...@mimc.co.uk > > Subject: Re: [PATCH] mfd: Fix usbhs_enable error handling > > > > Hi, > > > > On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote: > > > From: Axel Lin > > > > > > In the case of missing platform_data we do not hold a spin_lock, > > > thus we should not call spin_unlock_irqrestore in the error path. > > > > > > Also simplify the error handling by separating the successful path > > > from error path. I think this change improves readability. > > > > > > Signed-off-by: Axel Lin > > > > Can someone give me a Tested-by so I can take these patches. > > > > -- > > Balbi > > Hi Balbi > > I have validated this patch and it works :) > > Tested-by: Keshava Munegowda what about the others ? -- balbi -- 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] mfd: Fix usbhs_enable error handling
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Tuesday, April 26, 2011 2:29 PM > To: Keshava Munegowda > Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com; gadi...@ti.com; p- > bas...@ti.com; axel@gmail.com; johns...@us.ibm.com; mpfj-l...@mimc.co.uk > Subject: Re: [PATCH] mfd: Fix usbhs_enable error handling > > Hi, > > On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote: > > From: Axel Lin > > > > In the case of missing platform_data we do not hold a spin_lock, > > thus we should not call spin_unlock_irqrestore in the error path. > > > > Also simplify the error handling by separating the successful path > > from error path. I think this change improves readability. > > > > Signed-off-by: Axel Lin > > Can someone give me a Tested-by so I can take these patches. > > -- > Balbi Hi Balbi I have validated this patch and it works :) Tested-by: Keshava Munegowda -- 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] mfd: Fix usbhs_enable error handling
Hi, On Thu, Apr 21, 2011 at 07:52:41PM +0530, Keshava Munegowda wrote: > From: Axel Lin > > In the case of missing platform_data we do not hold a spin_lock, > thus we should not call spin_unlock_irqrestore in the error path. > > Also simplify the error handling by separating the successful path > from error path. I think this change improves readability. > > Signed-off-by: Axel Lin Can someone give me a Tested-by so I can take these patches. -- balbi -- 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: Fix relocation if image end past uncompressed kernel end
* Nicolas Pitre [110422 17:08]: > On Thu, 21 Apr 2011, Tony Lindgren wrote: > > > * Nicolas Pitre [110421 20:20]: > > > I found the bugger. The problem was a bad stack alignment. > > > > .. as this patch won't solve the n900 booting problem with zImage. > > With LZMA I'm still also getting "LZMA data is corrupt". > > Hmmm.. > > Is it possible you have bad RAM? In compressed/head.S, locate this > code: This is happening on all n900 boards AFAIK. > #ifdef CONFIG_AUTO_ZRELADDR > @ determine final kernel image address > mov r4, pc > and r4, r4, #0xf800 > add r4, r4, #TEXT_OFFSET > #else > ldr r4, =zreladdr > #endif > > Right after that, simply override r4 with a physical address towards the > end of the RAM, say 8MB before end of RAM (unless your decompressed > kernel is larger than that). That won't make a booting system, but at > least you will be able to test the decompressor when loaded at various > locations in memory without involving the relocation loop. OK thanks, I'll take a look. I guess it could also be a cache flush issue or borderline memory timings set in the bootloader. 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: Which git repo for OMAP4430 Pandaboard
* Elvis Dowson [110426 11:44]: > Hi, >Which git repo should I consider using for OMAP4430 Pandaboard kernel > development? > > a. mainline linux-2.6 repo You should do all the patches against the mainline kernel where possible to avoid rebasing them later on. Some patches of course may have dependencies to other branches, but in those cases you should question how come those dependencies exist. Usually those dependencies can be sorted out in the mainline kernel. 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
Which git repo for OMAP4430 Pandaboard
Hi, Which git repo should I consider using for OMAP4430 Pandaboard kernel development? a. mainline linux-2.6 repo or b. http://gitorious.org/pandaboard/kernel-omap4 or c. http://git.omapzoom.org/?p=kernel/omap.git;a=summary Elvis Dowson -- 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 v4l2: fix wrong resizer calculation
>From 47473f26bda2ef2e3a5e8f0203fde0c74c412c36 Mon Sep 17 00:00:00 2001
From: Vladimir Pantelic
Date: Tue, 26 Apr 2011 09:28:11 +0200
Subject: [PATCH] omap v4l2: fix wrong resizer calculation
in omap_vout_new_crop(), "crop" is the output parameter and
therefore new_crop/try_crop should be used to calculate the
resizer values
Signed-off-by: Vladimir Pantelic
---
drivers/media/video/omap/omap_voutlib.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_voutlib.c b/drivers/media/video/omap/omap_voutlib.c
index 2aa6a76..8ae7481 100644
--- a/drivers/media/video/omap/omap_voutlib.c
+++ b/drivers/media/video/omap/omap_voutlib.c
@@ -193,7 +193,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
return -EINVAL;
if (cpu_is_omap24xx()) {
- if (crop->height != win->w.height) {
+ if (try_crop.height != win->w.height) {
/* If we're resizing vertically, we can't support a
* crop width wider than 768 pixels.
*/
@@ -202,7 +202,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
}
}
/* vertical resizing */
- vresize = (1024 * crop->height) / win->w.height;
+ vresize = (1024 * try_crop.height) / win->w.height;
if (cpu_is_omap24xx() && (vresize > 2048))
vresize = 2048;
else if (cpu_is_omap34xx() && (vresize > 4096))
@@ -221,7 +221,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
try_crop.height = 2;
}
/* horizontal resizing */
- hresize = (1024 * crop->width) / win->w.width;
+ hresize = (1024 * try_crop.width) / win->w.width;
if (cpu_is_omap24xx() && (hresize > 2048))
hresize = 2048;
else if (cpu_is_omap34xx() && (hresize > 4096))
--
1.6.0.2
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Linus Walleij [110423 01:32]: > 2011/4/21 Tony Lindgren : > > * Kevin Hilman [110421 02:56]: > > >> > - Move it to drivers/gpio > >> > > >> > - Further consolidate with whatever common GPIO code might > >> > be coming up. > >> > >> Is the above order required? > > > > Yes please. Otherwise we'll have more of the "crazy churn" in > > arch/arm/*omap*/ and the runtime PM patches should apply easily > > in drivers/gpio too. > > Since you'll probably be dependent on stuff happening in my patches > to move stuff into drivers/gpio I'll be happy to carry the patches in my > gpio-consolidation branch with Tony's ACKs if need be. Sounds good to me. 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] OMAP: DSS2: DSI: enable interface for omap4
On Wed, 2011-04-20 at 20:31 -0700, Vikram Pandita wrote: > From: Vikram Pandita > > By default, the DSI is not getting enabled for omap4. > OMAP2PLUS does not catch this issue since it has ARCH_OMAP3. > > The issue is only seen when using defconfig with ARCH_OMAP4 only. > > Signed-off-by: Vikram Pandita > Cc: Archit Taneja > Cc: Tomi Valkeinen > --- > drivers/video/omap2/dss/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied. Tomi -- 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 0/4] crypto: omap-sham driver fixes
Thanks. On 26/04/11 09:36, ext Herbert Xu wrote: > On Wed, Apr 20, 2011 at 01:34:54PM +0300, Dmitry Kasatkin wrote: >> Hi, >> >> Here is few patches with couple of important fixes... > All applied. Thanks! -- 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
