Re: [Patch v1] AM35xx: Craneboard: Add USB EHCI support
Hi Srinath,
On 11/19/10 18:07, srin...@mistralsolutions.com wrote:
> From: Srinath
>
> AM3517/05 Craneboard has one EHCI interface on board using port1.
>
> GPIO35 is used as power enable.
> GPIO38 is used as port1 PHY reset.
>
> Signed-off-by: Srinath
> ---
> arch/arm/mach-omap2/board-am3517crane.c | 21 +
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-am3517crane.c
> b/arch/arm/mach-omap2/board-am3517crane.c
> index 13ead33..0e1a806 100644
> --- a/arch/arm/mach-omap2/board-am3517crane.c
> +++ b/arch/arm/mach-omap2/board-am3517crane.c
> @@ -28,8 +28,10 @@
>
> #include
> #include
> +#include
>
> #include "mux.h"
> +#include "control.h"
>
> /* Board initialization */
> static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
> @@ -53,10 +55,29 @@ static void __init am3517_crane_init_irq(void)
> omap_gpio_init();
> }
>
> +static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
> + .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
> + .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
> + .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
> +
> + .phy_reset = true,
> + .reset_gpio_port[0] = 38,
> + .reset_gpio_port[1] = -EINVAL,
> + .reset_gpio_port[2] = -EINVAL
> +};
> +
> static void __init am3517_crane_init(void)
> {
> omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> omap_serial_init();
> +
> + /* Configure GPIO for EHCI port */
> + omap_mux_init_gpio(35, OMAP_PIN_OUTPUT);
> + gpio_request(35, "usb_ehci_enable");
gpio_request() can fail, you should check this
and you should not use this gpio if the request fails.
Also, may be the regulators framework is more appropriate
for power enable line, but I'm not sure...
> + gpio_direction_output(35, 1);
> + gpio_set_value(35, 1);
> + omap_mux_init_gpio(38, OMAP_PIN_OUTPUT);
Shouldn't the omap_mux_init_gpio() be called before you request the gpio?
> + usb_ehci_init(&ehci_pdata);
> }
>
> MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
--
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: omap3: regulator_get() failure in ads7846
Hi, I think, this can help: http://www.spinics.net/lists/arm-kernel/msg94759.html Seems like there were not enough interest and it is still floating. May be a little ping can help ;) On 09/07/10 14:46, Premi, Sanjeev wrote: > Hi all, > > While booting the latest kernel (from linux-omap) on omap3evm, > I came across this error. > > [3.202575] ads7846 spi1.0: unable to get regulator: -19 > [3.208190] [ cut here ] > [3.212890] WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x114/0x140() > [3.219940] Modules linked in: > [3.223083] [] (unwind_backtrace+0x0/0xec) from [] > (warn_slowpath_common+0x4c/0x64) > ... > ... > [3.342529] ---[ end trace 1b75b31a2719ed1f ]--- > > > In drivers/input/touchscreen/ads7846.c, we attempt to get the > regulator as: > > ts->reg = regulator_get(&spi->dev, "vcc"); > > This regulator isn't defined for omap3evm. And I suspect - once > defined - the name will be different than "vcc". > > Looking at pointers on how this should be handled. > > Best regard, > 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 > -- 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
[PATCH 1/5] omap3: Introduce CompuLab CM-T3517 module.
Add basic suppot, enable uart and led.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/Kconfig |7 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-cm-t3517.c | 109 ++
3 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b48bacf..da1c37d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -214,6 +214,13 @@ config MACH_CM_T35
select OMAP_PACKAGE_CUS
select OMAP_MUX
+config MACH_CM_T3517
+ bool "CompuLab CM-T3517 module"
+ depends on ARCH_OMAP3
+ default y
+ select OMAP_PACKAGE_CBB
+ select OMAP_MUX
+
config MACH_IGEP0020
bool "IGEP v2 board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..7d991d0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_MACH_OMAP_3630SDP) +=
board-3630sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
+obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
new file mode 100644
index 000..507d2d5
--- /dev/null
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -0,0 +1,109 @@
+/*
+ * linux/arch/arm/mach-omap2/board-cm-t3517.c
+ *
+ * Support for the CompuLab CM-T3517 modules
+ *
+ * Copyright (C) 2010 CompuLab, Ltd.
+ * Author: Igor Grinberg
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "mux.h"
+
+#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+static struct gpio_led cm_t3517_leds[] = {
+ [0] = {
+ .gpio = 186,
+ .name = "cm-t3517:green",
+ .default_trigger= "heartbeat",
+ .active_low = 0,
+ },
+};
+
+static struct gpio_led_platform_data cm_t3517_led_pdata = {
+ .num_leds = ARRAY_SIZE(cm_t3517_leds),
+ .leds = cm_t3517_leds,
+};
+
+static struct platform_device cm_t3517_led_device = {
+ .name = "leds-gpio",
+ .id = -1,
+ .dev= {
+ .platform_data = &cm_t3517_led_pdata,
+ },
+};
+
+static void __init cm_t3517_init_leds(void)
+{
+ platform_device_register(&cm_t3517_led_device);
+}
+#else
+static inline void cm_t3517_init_leds(void) {}
+#endif
+
+
+static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
+};
+
+static void __init cm_t3517_init_irq(void)
+{
+ omap_board_config = cm_t3517_config;
+ omap_board_config_size = ARRAY_SIZE(cm_t3517_config);
+
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_board_mux board_mux[] __initdata = {
+ /* GPIO186 - Green LED */
+ OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+
+static void __init cm_t3517_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+ cm_t3517_init_leds();
+}
+
+MACHINE_START(CM_T3517, "Compulab CM-T3517")
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xd800) >> 18) & 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = cm_t3517_init_irq,
+ .init_machine = cm_t3517_init,
+ .timer = &omap_timer,
+MACHINE_END
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Support for CompuLab CM-T3517 modules
CompuLab CM-T3517 module is based on AM3517 (Sitara) SoC. CM-T3517 supports on-board 256/128MB DDR2 DRAM, 512/128MB NAND flash, WIFI-BlueTooth combo chip, USB HUB, AC97 Codec, TouchScreen controller, RTC. This patch series add a basic support for CM-T3517 and some of its peripheral devices. Based on: commit da22d713d1149f528a734a10ea264c91a804662a Merge: 8f3ce99 8475b9e Author: Tony Lindgren Date: Mon Sep 13 21:17:04 2010 -0700 Linux-omap rebuilt: Updated to -rc4 Igor Grinberg (5): omap3: Introduce CompuLab CM-T3517 module. omap3: cm-t3517: add support for v3020 rtc. omap3: cm-t3517: add support for usb host. omap3: cm-t3517: add support for NAND flash omap3: cm-t3517: add support for TI HECC arch/arm/mach-omap2/Kconfig |7 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-cm-t3517.c | 295 ++ 3 files changed, 303 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] omap3: cm-t3517: add support for v3020 rtc.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 36 ++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 507d2d5..2b41c6d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -69,6 +70,35 @@ static void __init cm_t3517_init_leds(void)
static inline void cm_t3517_init_leds(void) {}
#endif
+#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
+#define RTC_IO_GPIO(153)
+#define RTC_WR_GPIO(154)
+#define RTC_RD_GPIO(160)
+#define RTC_CS_GPIO(163)
+
+struct v3020_platform_data cm_t3517_v3020_pdata = {
+ .use_gpio = 1,
+ .gpio_cs= RTC_CS_GPIO,
+ .gpio_wr= RTC_WR_GPIO,
+ .gpio_rd= RTC_RD_GPIO,
+ .gpio_io= RTC_IO_GPIO,
+};
+
+static struct platform_device cm_t3517_rtc_device = {
+ .name = "v3020",
+ .id = -1,
+ .dev= {
+ .platform_data = &cm_t3517_v3020_pdata,
+ }
+};
+
+static void __init cm_t3517_init_rtc(void)
+{
+ platform_device_register(&cm_t3517_rtc_device);
+}
+#else
+static inline void cm_t3517_init_rtc(void) {}
+#endif
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -86,6 +116,11 @@ static void __init cm_t3517_init_irq(void)
static struct omap_board_mux board_mux[] __initdata = {
/* GPIO186 - Green LED */
OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* RTC GPIOs: IO, WR#, RD#, CS# */
+ OMAP3_MUX(MCBSP4_DR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -95,6 +130,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+ cm_t3517_init_rtc();
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] omap3: cm-t3517: add support for TI HECC
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 45 ++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index d4399e7..ff927db 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,8 @@
#include
#include
+#include
+
#include "mux.h"
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
@@ -77,6 +80,47 @@ static void __init cm_t3517_init_leds(void)
static inline void cm_t3517_init_leds(void) {}
#endif
+#if defined(CONFIG_CAN_TI_HECC) || defined(CONFIG_CAN_TI_HECC_MODULE)
+static struct resource cm_t3517_hecc_resources[] = {
+ {
+ .start = AM35XX_IPSS_HECC_BASE,
+ .end= AM35XX_IPSS_HECC_BASE + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_HECC0_IRQ,
+ .end= INT_35XX_HECC0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct ti_hecc_platform_data cm_t3517_hecc_pdata = {
+ .scc_hecc_offset= AM35XX_HECC_SCC_HECC_OFFSET,
+ .scc_ram_offset = AM35XX_HECC_SCC_RAM_OFFSET,
+ .hecc_ram_offset= AM35XX_HECC_RAM_OFFSET,
+ .mbx_offset = AM35XX_HECC_MBOX_OFFSET,
+ .int_line = AM35XX_HECC_INT_LINE,
+ .version= AM35XX_HECC_VERSION,
+};
+
+static struct platform_device cm_t3517_hecc_device = {
+ .name = "ti_hecc",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(cm_t3517_hecc_resources),
+ .resource = cm_t3517_hecc_resources,
+ .dev= {
+ .platform_data = &cm_t3517_hecc_pdata,
+ },
+};
+
+static void cm_t3517_init_hecc(void)
+{
+ platform_device_register(&cm_t3517_hecc_device);
+}
+#else
+static inline void cm_t3517_init_hecc(void) {}
+#endif
+
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
@@ -236,6 +280,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
+ cm_t3517_init_hecc();
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] omap3: cm-t3517: add support for NAND flash
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 54 ++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 23cd9a1..d4399e7 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -29,6 +29,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -38,6 +41,8 @@
#include
#include
#include
+#include
+#include
#include "mux.h"
@@ -144,6 +149,54 @@ static inline int cm_t3517_init_usbh(void)
}
#endif
+#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition cm_t3517_nand_partitions[] = {
+ {
+ .name = "xloader",
+ .offset = 0,/* Offset = 0x0 */
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = "uboot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "uboot environment",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 2 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "linux",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "rootfs",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data cm_t3517_nand_data = {
+ .parts = cm_t3517_nand_partitions,
+ .nr_parts = ARRAY_SIZE(cm_t3517_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .cs = 0,
+};
+
+static void __init cm_t3517_init_nand(void)
+{
+ if (gpmc_nand_init(&cm_t3517_nand_data) < 0)
+ pr_err("CM-T3517: NAND initialization failed\n");
+}
+#else
+static inline void cm_t3517_init_nand(void) {}
+#endif
+
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -180,6 +233,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+ cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] omap3: cm-t3517: add support for usb host.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 51 ++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 2b41c6d..23cd9a1 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
#include
#include
#include
+#include
#include "mux.h"
@@ -100,6 +102,48 @@ static void __init cm_t3517_init_rtc(void)
static inline void cm_t3517_init_rtc(void) {}
#endif
+#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
+#define HSUSB1_RESET_GPIO (146)
+#define HSUSB2_RESET_GPIO (147)
+#define USB_HUB_RESET_GPIO (152)
+
+static struct ehci_hcd_omap_platform_data cm_t3517_ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = HSUSB1_RESET_GPIO,
+ .reset_gpio_port[1] = HSUSB2_RESET_GPIO,
+ .reset_gpio_port[2] = -EINVAL,
+};
+
+static int cm_t3517_init_usbh(void)
+{
+ int err;
+
+ err = gpio_request(USB_HUB_RESET_GPIO, "usb hub rst");
+ if (err) {
+ pr_err("CM-T3517: usb hub reset gpio request failed: %d\n",
+ err);
+ } else {
+ gpio_direction_output(USB_HUB_RESET_GPIO, 0);
+ udelay(10);
+ gpio_set_value(USB_HUB_RESET_GPIO, 1);
+ msleep(1);
+ }
+
+ usb_ehci_init(&cm_t3517_ehci_pdata);
+
+ return 0;
+}
+#else
+static inline int cm_t3517_init_usbh(void)
+{
+ return 0;
+}
+#endif
+
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -121,6 +165,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* HSUSB1 RESET */
+ OMAP3_MUX(UART2_TX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* HSUSB2 RESET */
+ OMAP3_MUX(UART2_RX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* CM-T3517 USB HUB nRESET */
+ OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -131,6 +181,7 @@ static void __init cm_t3517_init(void)
omap_serial_init();
cm_t3517_init_leds();
cm_t3517_init_rtc();
+ cm_t3517_init_usbh();
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
Hi,
On 09/16/10 11:00, Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 16, 2010 at 03:54:39AM -0500, Igor Grinberg wrote:
>
> put a description here.
This is a relatively small patch, is the subject not descriptive enough?
>
>> Signed-off-by: Igor Grinberg
>> ---
>
> [snip]
>
>> +static int cm_t3517_init_usbh(void)
>> +{
>> +int err;
>> +
>> +err = gpio_request(USB_HUB_RESET_GPIO, "usb hub rst");
>> +if (err) {
>> +pr_err("CM-T3517: usb hub reset gpio request failed: %d\n",
>> + err);
>> +} else {
>
> if (err) {
> pr_err("...");
> return err;
> }
>
> gpio_direction_output(...);
>
> this will save you on identation level.
Yes it will, but even if the hub reset gpio is for some reason unavailable,
we don't want to disable ehci completely...
There are other ports, that are not wired through the hub.
--
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 1/5] omap3: Introduce CompuLab CM-T3517 module.
On 09/16/10 19:53, Tony Lindgren wrote: > * Igor Grinberg [100916 01:46]: >> Add basic suppot, enable uart and led. >> >> Signed-off-by: Igor Grinberg >> --- >> arch/arm/mach-omap2/Kconfig |7 ++ >> arch/arm/mach-omap2/Makefile |1 + >> arch/arm/mach-omap2/board-cm-t3517.c | 109 >> ++ >> 3 files changed, 117 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c > Looks like you're missing the debug uart entry for > arch/arm/plat-omap/include/plat/uncompress.h? > > You can test this by enabling DEBUG_LL and EARLY_PRINTK > in your .config, then pass earlyprintk in the kernel > cmdline. Might become handy for debugging the early > init process for your board. Indeed can be useful. Thanks. > 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 > -- 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 3/5] omap3: cm-t3517: add support for usb host.
On 09/16/10 19:48, Tony Lindgren wrote: > * Igor Grinberg [100916 02:04]: >> Hi, >> >> On 09/16/10 11:00, Felipe Balbi wrote: >>> Hi, >>> >>> On Thu, Sep 16, 2010 at 03:54:39AM -0500, Igor Grinberg wrote: >>> >>> put a description here. >> This is a relatively small patch, is the subject not descriptive enough? > In that case just copy the subject (without the [PATCH] part) to the > description for all of your patches. Ok, will do and re-spin. Thanks > Regards, > > Tony > -- 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 3/5] omap3: cm-t3517: add support for usb host.
On 09/20/10 08:39, Felipe Balbi wrote: > On Thu, Sep 16, 2010 at 04:12:06AM -0500, Igor Grinberg wrote: >> Yes it will, but even if the hub reset gpio is for some reason unavailable, >> we don't want to disable ehci completely... > > then you should set the gpio to an invalid number, otherwise you might > cause lots of WARN() to appear due to fiddling with unrequested gpio. What gpio should be set to invalid number? It is a reset gpio for usb _hub_ and it has nothing to do with ehci. Can you please, explain the case when I might cause those WARN()'s? -- 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
[PATCH 1/5] omap3: Introduce CompuLab CM-T3517 module.
Add basic suppot, enable uart and led.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/Kconfig |7 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-cm-t3517.c | 109 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
4 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index bb85f24..9ceb72b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -216,6 +216,13 @@ config MACH_CM_T35
select OMAP_PACKAGE_CUS
select OMAP_MUX
+config MACH_CM_T3517
+ bool "CompuLab CM-T3517 module"
+ depends on ARCH_OMAP3
+ default y
+ select OMAP_PACKAGE_CBB
+ select OMAP_MUX
+
config MACH_IGEP0020
bool "IGEP v2 board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..7d991d0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_MACH_OMAP_3630SDP) +=
board-3630sdp.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
hsmmc.o
+obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
new file mode 100644
index 000..507d2d5
--- /dev/null
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -0,0 +1,109 @@
+/*
+ * linux/arch/arm/mach-omap2/board-cm-t3517.c
+ *
+ * Support for the CompuLab CM-T3517 modules
+ *
+ * Copyright (C) 2010 CompuLab, Ltd.
+ * Author: Igor Grinberg
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "mux.h"
+
+#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+static struct gpio_led cm_t3517_leds[] = {
+ [0] = {
+ .gpio = 186,
+ .name = "cm-t3517:green",
+ .default_trigger= "heartbeat",
+ .active_low = 0,
+ },
+};
+
+static struct gpio_led_platform_data cm_t3517_led_pdata = {
+ .num_leds = ARRAY_SIZE(cm_t3517_leds),
+ .leds = cm_t3517_leds,
+};
+
+static struct platform_device cm_t3517_led_device = {
+ .name = "leds-gpio",
+ .id = -1,
+ .dev= {
+ .platform_data = &cm_t3517_led_pdata,
+ },
+};
+
+static void __init cm_t3517_init_leds(void)
+{
+ platform_device_register(&cm_t3517_led_device);
+}
+#else
+static inline void cm_t3517_init_leds(void) {}
+#endif
+
+
+static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
+};
+
+static void __init cm_t3517_init_irq(void)
+{
+ omap_board_config = cm_t3517_config;
+ omap_board_config_size = ARRAY_SIZE(cm_t3517_config);
+
+ omap2_init_common_hw(NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+static struct omap_board_mux board_mux[] __initdata = {
+ /* GPIO186 - Green LED */
+ OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+
+static void __init cm_t3517_init(void)
+{
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+ cm_t3517_init_leds();
+}
+
+MACHINE_START(CM_T3517, "Compulab CM-T3517")
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xd800) >> 18) & 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap3_map_io,
+ .reserve= omap_reserve,
+ .init_irq = cm_t3517_init_irq,
+ .init_machine = cm_t3517_init,
+ .timer = &omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
b/arch/arm/plat-omap/i
[PATCH 0/5] Support for CompuLab CM-T3517 modules
CompuLab CM-T3517 module is based on AM3517 (Sitara) SoC. CM-T3517 supports on-board 256/128MB DDR2 DRAM, 512/128MB NAND flash, WIFI-BlueTooth combo chip, USB HUB, AC97 Codec, TouchScreen controller, RTC. This patch series add a basic support for CM-T3517 and some of its peripheral devices. Based on: commit 44ed8ecfeb1f639c59897de3f551f50e3f0fd52e Merge: 96542e6 0cbe681 Author: Tony Lindgren Date: Mon Sep 20 15:14:25 2010 -0700 Linux-omap rebuilt: Merged in the smp-on-up patches for testing Igor Grinberg (5): omap3: Introduce CompuLab CM-T3517 module. omap3: cm-t3517: add support for v3020 rtc. omap3: cm-t3517: add support for usb host. omap3: cm-t3517: add support for NAND flash omap3: cm-t3517: add support for TI HECC arch/arm/mach-omap2/Kconfig |7 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-cm-t3517.c | 294 ++ arch/arm/plat-omap/include/plat/uncompress.h |1 + 4 files changed, 303 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c -- To unsubscribe from this list: send the line "unsubscribe 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 3/5] omap3: cm-t3517: add support for usb host.
add support for hsusb host ports 1, 2 and on-module usb hub.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 50 ++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 2b41c6d..2c7082d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
#include
#include
#include
+#include
#include "mux.h"
@@ -100,6 +102,47 @@ static void __init cm_t3517_init_rtc(void)
static inline void cm_t3517_init_rtc(void) {}
#endif
+#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
+#define HSUSB1_RESET_GPIO (146)
+#define HSUSB2_RESET_GPIO (147)
+#define USB_HUB_RESET_GPIO (152)
+
+static struct ehci_hcd_omap_platform_data cm_t3517_ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = HSUSB1_RESET_GPIO,
+ .reset_gpio_port[1] = HSUSB2_RESET_GPIO,
+ .reset_gpio_port[2] = -EINVAL,
+};
+
+static int cm_t3517_init_usbh(void)
+{
+ int err;
+
+ err = gpio_request(USB_HUB_RESET_GPIO, "usb hub rst");
+ if (err) {
+ pr_err("CM-T3517: usb hub rst gpio request failed: %d\n", err);
+ } else {
+ gpio_direction_output(USB_HUB_RESET_GPIO, 0);
+ udelay(10);
+ gpio_set_value(USB_HUB_RESET_GPIO, 1);
+ msleep(1);
+ }
+
+ usb_ehci_init(&cm_t3517_ehci_pdata);
+
+ return 0;
+}
+#else
+static inline int cm_t3517_init_usbh(void)
+{
+ return 0;
+}
+#endif
+
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -121,6 +164,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* HSUSB1 RESET */
+ OMAP3_MUX(UART2_TX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* HSUSB2 RESET */
+ OMAP3_MUX(UART2_RX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* CM-T3517 USB HUB nRESET */
+ OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -131,6 +180,7 @@ static void __init cm_t3517_init(void)
omap_serial_init();
cm_t3517_init_leds();
cm_t3517_init_rtc();
+ cm_t3517_init_usbh();
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] omap3: cm-t3517: add support for v3020 rtc.
add support for v3020 rtc.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 36 ++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 507d2d5..2b41c6d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -69,6 +70,35 @@ static void __init cm_t3517_init_leds(void)
static inline void cm_t3517_init_leds(void) {}
#endif
+#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
+#define RTC_IO_GPIO(153)
+#define RTC_WR_GPIO(154)
+#define RTC_RD_GPIO(160)
+#define RTC_CS_GPIO(163)
+
+struct v3020_platform_data cm_t3517_v3020_pdata = {
+ .use_gpio = 1,
+ .gpio_cs= RTC_CS_GPIO,
+ .gpio_wr= RTC_WR_GPIO,
+ .gpio_rd= RTC_RD_GPIO,
+ .gpio_io= RTC_IO_GPIO,
+};
+
+static struct platform_device cm_t3517_rtc_device = {
+ .name = "v3020",
+ .id = -1,
+ .dev= {
+ .platform_data = &cm_t3517_v3020_pdata,
+ }
+};
+
+static void __init cm_t3517_init_rtc(void)
+{
+ platform_device_register(&cm_t3517_rtc_device);
+}
+#else
+static inline void cm_t3517_init_rtc(void) {}
+#endif
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -86,6 +116,11 @@ static void __init cm_t3517_init_irq(void)
static struct omap_board_mux board_mux[] __initdata = {
/* GPIO186 - Green LED */
OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* RTC GPIOs: IO, WR#, RD#, CS# */
+ OMAP3_MUX(MCBSP4_DR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
@@ -95,6 +130,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+ cm_t3517_init_rtc();
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] omap3: cm-t3517: add support for NAND flash
add support for NAND flash.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 54 ++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 2c7082d..4c26cf5 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -29,6 +29,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -38,6 +41,8 @@
#include
#include
#include
+#include
+#include
#include "mux.h"
@@ -143,6 +148,54 @@ static inline int cm_t3517_init_usbh(void)
}
#endif
+#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition cm_t3517_nand_partitions[] = {
+ {
+ .name = "xloader",
+ .offset = 0,/* Offset = 0x0 */
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = "uboot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "uboot environment",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 2 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "linux",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "rootfs",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data cm_t3517_nand_data = {
+ .parts = cm_t3517_nand_partitions,
+ .nr_parts = ARRAY_SIZE(cm_t3517_nand_partitions),
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .cs = 0,
+};
+
+static void __init cm_t3517_init_nand(void)
+{
+ if (gpmc_nand_init(&cm_t3517_nand_data) < 0)
+ pr_err("CM-T3517: NAND initialization failed\n");
+}
+#else
+static inline void cm_t3517_init_nand(void) {}
+#endif
+
static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
};
@@ -179,6 +232,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+ cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] omap3: cm-t3517: add support for TI HECC
add support for TI HECC.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 45 ++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 4c26cf5..1115b8a 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,8 @@
#include
#include
+#include
+
#include "mux.h"
#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
@@ -77,6 +80,47 @@ static void __init cm_t3517_init_leds(void)
static inline void cm_t3517_init_leds(void) {}
#endif
+#if defined(CONFIG_CAN_TI_HECC) || defined(CONFIG_CAN_TI_HECC_MODULE)
+static struct resource cm_t3517_hecc_resources[] = {
+ {
+ .start = AM35XX_IPSS_HECC_BASE,
+ .end= AM35XX_IPSS_HECC_BASE + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_HECC0_IRQ,
+ .end= INT_35XX_HECC0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct ti_hecc_platform_data cm_t3517_hecc_pdata = {
+ .scc_hecc_offset= AM35XX_HECC_SCC_HECC_OFFSET,
+ .scc_ram_offset = AM35XX_HECC_SCC_RAM_OFFSET,
+ .hecc_ram_offset= AM35XX_HECC_RAM_OFFSET,
+ .mbx_offset = AM35XX_HECC_MBOX_OFFSET,
+ .int_line = AM35XX_HECC_INT_LINE,
+ .version= AM35XX_HECC_VERSION,
+};
+
+static struct platform_device cm_t3517_hecc_device = {
+ .name = "ti_hecc",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(cm_t3517_hecc_resources),
+ .resource = cm_t3517_hecc_resources,
+ .dev= {
+ .platform_data = &cm_t3517_hecc_pdata,
+ },
+};
+
+static void cm_t3517_init_hecc(void)
+{
+ platform_device_register(&cm_t3517_hecc_device);
+}
+#else
+static inline void cm_t3517_init_hecc(void) {}
+#endif
+
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
@@ -235,6 +279,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
+ cm_t3517_init_hecc();
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap3: cm-t3517: add support for usb host.
On 09/21/10 18:26, Gadiyar, Anand wrote:
> On Tue, Sep 21, 2010 at 9:33 PM, Igor Grinberg
> wrote:
>> add support for hsusb host ports 1, 2 and on-module usb hub.
>>
>> Signed-off-by: Igor Grinberg
>> ---
>> arch/arm/mach-omap2/board-cm-t3517.c | 50
>> ++
> ...
>
>> @@ -100,6 +102,47 @@ static void __init cm_t3517_init_rtc(void)
>> static inline void cm_t3517_init_rtc(void) {}
>> #endif
>>
>> +#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
> Hi Igor,
Hi
> Do we really need to make these conditional on the driver being built?
This is depends on what are we trying to achieve...
I can think of two things:
[1] Simple, clear and nice code without ifdefs
[2] Smaller kernel, a bit less resources wasted and a bit faster boot time
> The hardware is present on the board at all times, right?
Yes, it is inside the SoC, except for the usb hub.
> It should be okay to execute this code independent of whether
> the driver is built or not. The device registration can be unconditional
> and if there is no driver present, we won't probe anyway.
It is ok, but again it depends on what we are trying to achieve here.
If we want [1], then indeed we need to remove the ifdefs also inside usb-ehci.c,
so pros:
* we'll get nice and clean code,
cons:
* a bit bigger kernel,
* "floating" device without a driver,
* a bit resources wasted for this device,
* a bit slower startup time (device registration, gpio toggling, etc.).
If we want [2], then we'll have the opposite of [1] ;)
Personally, I don't mind either way... ,
but I want the code to be consistent (in this case with usb-ehci.c).
> (I see some similar logic in usb-ehci.c - probably a good idea to remove
> it as well).
...
> - Anand
>
>> +#define HSUSB1_RESET_GPIO (146)
>> +#define HSUSB2_RESET_GPIO (147)
>> +#define USB_HUB_RESET_GPIO (152)
>> +
>> +static struct ehci_hcd_omap_platform_data cm_t3517_ehci_pdata __initdata = {
>> + .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
>> + .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
>> + .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
>> +
>> + .phy_reset = true,
>> + .reset_gpio_port[0] = HSUSB1_RESET_GPIO,
>> + .reset_gpio_port[1] = HSUSB2_RESET_GPIO,
>> + .reset_gpio_port[2] = -EINVAL,
>> +};
>> +
>> +static int cm_t3517_init_usbh(void)
>> +{
>> + int err;
>> +
>> + err = gpio_request(USB_HUB_RESET_GPIO, "usb hub rst");
>> + if (err) {
>> + pr_err("CM-T3517: usb hub rst gpio request failed: %d\n",
>> err);
>> + } else {
>> + gpio_direction_output(USB_HUB_RESET_GPIO, 0);
>> + udelay(10);
>> + gpio_set_value(USB_HUB_RESET_GPIO, 1);
>> + msleep(1);
>> + }
>> +
>> + usb_ehci_init(&cm_t3517_ehci_pdata);
>> +
>> + return 0;
>> +}
>> +#else
>> +static inline int cm_t3517_init_usbh(void)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
> --
> To unsubscribe from this list: send the line "unsubscribe 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/3 v4] musb: add musb support for AM35x
On 09/29/10 14:45, Ajay Kumar Gupta wrote: > AM35x has musb interface and uses CPPI4.1 DMA engine. > Current patch supports only PIO mode. DMA support can be > added later once basic CPPI4.1 DMA patch is accepted. > > Also added USB_MUSB_AM35X which is required to differentiate musb ips > between OMAP3x and AM35x. This config would be used to for below > purposes, > - Select am35x.c instead of omap2430.c for compilation > at drivers/usb/musb directory. Please note there are > significant differneces in these two files as musb ip > in quite different on AM35x. > - Select workaround codes applicable for AM35x musb issues. > one such workaround is for bytewise read issue on AM35x. > > Signed-off-by: Ajay Kumar Gupta > --- > Changes from v3, (Mostly based on Sergei's review comment) > - Cleaned up the clock related coding. > - Removed the setting of musb->a_wait_vcon > - Removed musb->is_active = 1 from isr routine. > - Moved the GPIOMODE and DATA_POLARITY PHY config to board files. > - Didn't add SESSSION bit write in otg_time for OTG_STATE_B_IDLE > case as it always makes Vbus in switched on state. > - Removed waiting loop in musb_platform_exit() function. > > drivers/usb/musb/Kconfig | 13 +- > drivers/usb/musb/Makefile |4 + > drivers/usb/musb/am35x.c | 510 > + > 3 files changed, 526 insertions(+), 1 deletions(-) > create mode 100644 drivers/usb/musb/am35x.c > > diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig > index 1dd21c2..0941a32 100644 > --- a/drivers/usb/musb/Kconfig > +++ b/drivers/usb/musb/Kconfig > @@ -60,6 +60,17 @@ comment "OMAP 44xx high speed USB support" > comment "Blackfin high speed USB Support" > depends on USB_MUSB_HDRC && ((BF54x && !BF544) || (BF52x && !BF522 && > !BF523)) > > +config USB_MUSB_AM35X > + boolean "AM35X MUSB support" > + depends on USB_MUSB_HDRC && MACH_OMAP3517EVM > + select NOP_USB_XCEIV > + default y > + help > + Select this option if your platform is based on AM35x. As > + AM35x has an updated MUSB with CPPI4.1 DMA so this config > + is introduced to differentiate musb ip between OMAP3x and > + AM35x platforms. > + > config USB_TUSB6010 > boolean "TUSB 6010 support" > depends on USB_MUSB_HDRC && !USB_MUSB_SOC > @@ -147,7 +158,7 @@ config USB_MUSB_HDRC_HCD > config MUSB_PIO_ONLY > bool 'Disable DMA (always use PIO)' > depends on USB_MUSB_HDRC > - default USB_TUSB6010 || ARCH_DAVINCI_DA8XX > + default USB_TUSB6010 || ARCH_DAVINCI_DA8XX || USB_MUSB_AM35X > help > All data is copied between memory and FIFO by the CPU. > DMA controllers are ignored. > diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile > index f664ecf..217363d 100644 > --- a/drivers/usb/musb/Makefile > +++ b/drivers/usb/musb/Makefile > @@ -23,7 +23,11 @@ ifeq ($(CONFIG_ARCH_OMAP2430),y) > endif > > ifeq ($(CONFIG_ARCH_OMAP3430),y) > + ifeq ($(CONFIG_USB_MUSB_AM35X),y) > + musb_hdrc-objs += am35x.o > + else > musb_hdrc-objs += omap2430.o > + endif > endif > > ifeq ($(CONFIG_ARCH_OMAP4),y) > diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c > new file mode 100644 > index 000..ee0c104 > --- /dev/null > +++ b/drivers/usb/musb/am35x.c > @@ -0,0 +1,510 @@ > +/* > + * Texas Instruments AM35x "glue layer" > + * > + * Copyright (c) 2010, by Texas Instruments > + * > + * Based on the DA8xx "glue layer" code. > + * Copyright (C) 2005-2006 by Texas Instruments > + * Copyright (c) 2008, MontaVista Software, Inc. > + * > + * This file is part of the Inventra Controller Driver for Linux. > + * > + * The Inventra Controller Driver for Linux 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. > + * > + * The Inventra Controller Driver for Linux is distributed in > + * the hope that it will be useful, but WITHOUT ANY WARRANTY; > + * without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > + * License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with The Inventra Controller Driver for Linux ; if not, > + * write to the Free Software Foundation, Inc., 59 Temple Place, > + * Suite 330, Boston, MA 02111-1307 USA > + * > + */ > + > +#include > +#include > +#include > + > +#include > +#include > + > +#include "musb_core.h" > + > +/* > + * AM35x specific definitions > + */ > +/* USB 2.0 OTG module registers */ > +#define USB_REVISION_REG 0x00 > +#define USB_CTRL_REG 0x04 > +#define USB_STAT_REG 0x08 > +#define USB_EMULATION_REG0x0c > +/* 0x10 Reserved */ > +#define USB_AUTOREQ_REG 0
Re: [PATCH 2/3 v4] musb: add musb support for AM35x
Hi,
On 09/29/10 17:38, Sergei Shtylyov wrote:
> Hello.
>
> Igor Grinberg wrote:
>
>>> AM35x has musb interface and uses CPPI4.1 DMA engine.
>>> Current patch supports only PIO mode. DMA support can be
>>> added later once basic CPPI4.1 DMA patch is accepted.
>
>>> Also added USB_MUSB_AM35X which is required to differentiate musb ips
>>> between OMAP3x and AM35x. This config would be used to for below
>>> purposes,
>>> - Select am35x.c instead of omap2430.c for compilation
>>> at drivers/usb/musb directory. Please note there are
>>> significant differneces in these two files as musb ip
>>> in quite different on AM35x.
>>> - Select workaround codes applicable for AM35x musb issues.
>>> one such workaround is for bytewise read issue on AM35x.
>
>>> Signed-off-by: Ajay Kumar Gupta
>
> [...]
>
>>> diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
>>> new file mode 100644
>>> index 000..ee0c104
>>> --- /dev/null
>>> +++ b/drivers/usb/musb/am35x.c
>>> @@ -0,0 +1,510 @@
> [...]
>>> +int musb_platform_set_mode(struct musb *musb, u8 musb_mode)
>>> +{
>>> +u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
>>> +
>>> +devconf2 &= ~CONF2_OTGMODE;
>>> +switch (musb_mode) {
>>> +#ifdefCONFIG_USB_MUSB_HDRC_HCD
>>> +case MUSB_HOST:/* Force VBUS valid, ID = 0 */
>>> +devconf2 |= CONF2_FORCE_HOST;
>>> +break;
>>> +#endif
>>> +#ifdefCONFIG_USB_GADGET_MUSB_HDRC
>>> +case MUSB_PERIPHERAL:/* Force VBUS valid, ID = 1 */
>>> +devconf2 |= CONF2_FORCE_DEVICE;
>>> +break;
>>> +#endif
>>> +#ifdefCONFIG_USB_MUSB_OTG
>>> +case MUSB_OTG:/* Don't override the VBUS/ID comparators */
>>> +devconf2 |= CONF2_NO_OVERRIDE;
>
>> This does nothing, can be removed...
>
>Well, I think you should let it live -- for completeness...
Well, I actually don't like, how those bits defined in first place,
but I want am35xx musb support badly, so yeah, let it be...
>
>>> +int musb_platform_exit(struct musb *musb)
>>> +{
>>> +struct clk *otg_fck;
>>> +
>>> +if (is_host_enabled(musb))
>>> +del_timer_sync(&otg_workaround);
>>> +
>>> +phy_off();
>>> +
>>> +otg_put_transceiver(musb->xceiv);
>>> +usb_nop_xceiv_unregister();
>>> +
>>> +if (musb->set_clock)
>>> +musb->set_clock(musb->clock, 0);
>>> +else
>>> +clk_disable(musb->clock);
>>> +
>>> +otg_fck = clk_get(musb->controller, "fck");
>>> +if (IS_ERR(otg_fck)) {
>>> +DBG(2, "clk_get() failed for otg_fck.\n");
>>> +} else {
>>> +clk_put(otg_fck);
>>> +clk_put(otg_fck);
>>> +clk_disable(otg_fck);
>
>> I think the order should be:
>> clk_disable(...);
>> clk_put(...);
>
>Right...
>
>> And of course, it should be put only once... ;)
>
>clk_get() is called twice, here and in musb_platform_init(), and so is
> clk_put().
Right, it should be stored in a static variable or a structure
(as you state in your reply), so there won't be any need for putting it twice.
>
> WBR, Sergei
> --
> To unsubscribe from this list: send the line "unsubscribe 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/3 v4] musb: add musb support for AM35x
Hi,
Already replied to Sergei on the comments below,
so please see the answer in my reply to Sergei.
On 09/29/10 17:46, Gupta, Ajay Kumar wrote:
> Hi,
>
> [...]
>>> + devconf2 &= ~CONF2_OTGMODE;
>>> + switch (musb_mode) {
>>> +#ifdef CONFIG_USB_MUSB_OTG
>>> + case MUSB_OTG: /* Don't override the VBUS/ID comparators */
>>> + devconf2 |= CONF2_NO_OVERRIDE;
>> This does nothing, can be removed...
> Yes, but it's good to have it from code readability perspective.
>
> I can remove it but let's get Felipe's opinion on this.
>
> [...]
>>> + if (musb->set_clock)
>>> + musb->set_clock(musb->clock, 0);
>>> + else
>>> + clk_disable(musb->clock);
>>> +
>>> + otg_fck = clk_get(musb->controller, "fck");
>>> + if (IS_ERR(otg_fck)) {
>>> + DBG(2, "clk_get() failed for otg_fck.\n");
>>> + } else {
>>> + clk_put(otg_fck);
>>> + clk_put(otg_fck);
>>> + clk_disable(otg_fck);
>> I think the order should be:
>> clk_disable(...);
>> clk_put(...);
> Again I would wait for Felipe's opinion on this ordering. BTW there
> Are codes on musb_core.c where clk_put is done before clk_disable().
>
>>> And of course, it should be put only once... ;)
> No. clk_put() needs to be done twice as clk_get() is called two times;
> one in musb_platform_init() and other in current function musb_platform_exit.
>
> Other solution could be to save otg_fck in some static variable as
> Sergei suggested.
>
> Thanks,
> Ajay
> [...]
>
> --
> To unsubscribe from this list: send the line "unsubscribe 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
[PATCH 0/2] cm-t3517 fixes
This little patch serie is based on Tony's devel-board branch. It fixes the rtc and some comments on cm-t3517. Igor Grinberg (2): arm: omap3: cm-t3517: rtc fix arm: omap3: cm-t3517: minor comment fix arch/arm/mach-omap2/board-cm-t3517.c | 29 - 1 files changed, 24 insertions(+), 5 deletions(-) -- 1.7.2.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
[PATCH 1/2] arm: omap3: cm-t3517: rtc fix
Fix rtc gpios and mux
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 5b0c777..1706df0 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -124,8 +124,9 @@ static inline void cm_t3517_init_hecc(void) {}
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
-#define RTC_RD_GPIO(160)
+#define RTC_RD_GPIO(53)
#define RTC_CS_GPIO(163)
+#define RTC_CS_EN_GPIO (160)
struct v3020_platform_data cm_t3517_v3020_pdata = {
.use_gpio = 1,
@@ -145,6 +146,16 @@ static struct platform_device cm_t3517_rtc_device = {
static void __init cm_t3517_init_rtc(void)
{
+ int err;
+
+ err = gpio_request(RTC_CS_EN_GPIO, "rtc cs en");
+ if (err) {
+ pr_err("CM-T3517: rtc cs en gpio request failed: %d\n", err);
+ return;
+ }
+
+ gpio_direction_output(RTC_CS_EN_GPIO, 1);
+
platform_device_register(&cm_t3517_rtc_device);
}
#else
@@ -256,11 +267,19 @@ static void __init cm_t3517_init_irq(void)
static struct omap_board_mux board_mux[] __initdata = {
/* GPIO186 - Green LED */
OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
- /* RTC GPIOs: IO, WR#, RD#, CS# */
+
+ /* RTC GPIOs: */
+ /* IO - GPIO153 */
OMAP3_MUX(MCBSP4_DR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* WR# - GPIO154 */
OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
- OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* RD# - GPIO53 */
+ OMAP3_MUX(GPMC_NCS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* CS# - GPIO163 */
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+ /* CS EN - GPIO160 */
+ OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
/* HSUSB1 RESET */
OMAP3_MUX(UART2_TX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
/* HSUSB2 RESET */
--
1.7.2.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
[PATCH 2/2] arm: omap3: cm-t3517: minor comment fix
offsets in the comment were wrong - fix this.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 1706df0..8f9a64d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -225,12 +225,12 @@ static struct mtd_partition cm_t3517_nand_partitions[] = {
},
{
.name = "linux",
- .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x2A */
.size = 32 * NAND_BLOCK_SIZE,
},
{
.name = "rootfs",
- .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x6A */
.size = MTDPART_SIZ_FULL,
},
};
--
1.7.2.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
Re: [PATCHv2 1/2] ads7846: OMAP3: Removal of warnings backtrace in bootup
Hi,
On 02/03/11 11:48, Sourav Poddar wrote:
> gpio_pendown in ads7846_probe is not getting initalized (defaulted to 0)
> resulting in gpio_free to be called without a gpio_request. This
> results in the following backtrace in bootup.
>
> [ cut here ]
> WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x100/0x12c()
> Modules linked in:
> [] (unwind_backtrace+0x0/0xe4) from []
> (warn_slowpath_common+0x4c/0x64)
> [] (warn_slowpath_common+0x4c/0x64) from []
> (warn_slowpath_null+0x18/0x1c)
> [] (warn_slowpath_null+0x18/0x1c) from []
> (gpio_free+0x100/0x12c)
> [] (gpio_free+0x100/0x12c) from []
> (ads7846_probe+0xa38/0xc5c)
> [] (ads7846_probe+0xa38/0xc5c) from []
> (spi_drv_probe+0x18/0x1c)
> [] (spi_drv_probe+0x18/0x1c) from []
> (driver_probe_device+0xc8/0x184)
> [] (driver_probe_device+0xc8/0x184) from []
> (__driver_attach+0x68/0x8c)
> [] (__driver_attach+0x68/0x8c) from []
> (bus_for_each_dev+0x48/0x74)
> [] (bus_for_each_dev+0x48/0x74) from []
> (bus_add_driver+0xa0/0x220)
> [] (bus_add_driver+0xa0/0x220) from []
> (driver_register+0xa8/0x134)
> [] (driver_register+0xa8/0x134) from []
> (do_one_initcall+0xcc/0x1a4)
> [] (do_one_initcall+0xcc/0x1a4) from []
> (kernel_init+0x14c/0x214)
> [] (kernel_init+0x14c/0x214) from []
> (kernel_thread_exit+0x0/0x8)
> ---[ end trace 4053287f8a5ec18f ]---
>
> Initializing gpio_pendown in ads7846_probe to -1 before
> ads7846_setup_pendown function removes the above backtrace
> warning.
>
> Signed-off-by: Sourav Poddar
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/input/touchscreen/ads7846.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> index 14ea54b..036f245 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -1221,6 +1221,7 @@ static int __devinit ads7846_probe(struct spi_device
> *spi)
> ts->input = input_dev;
> ts->vref_mv = pdata->vref_mv;
> ts->swap_xy = pdata->swap_xy;
> + ts->gpio_pendown = -1;
Wouldn't it be better putting this into ads7846_setup_pendown() function?
This will keep the whole gpio_pendown initialization code close together.
Something like:
if (pdata->get_pendown_state) {
ts->get_pendown_state = pdata->get_pendown_state;
ts->gpio_pendown = -1;
return 0;
}
Also, why don't we use -EINVAL for the invalid gpio number instead of -1
constant?
>
> mutex_init(&ts->lock);
> init_waitqueue_head(&ts->wait);
--
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: [PATCHv2 1/2] ads7846: OMAP3: Removal of warnings backtrace in bootup
Hi again,
On 02/03/11 12:10, Igor Grinberg wrote:
> Hi,
>
> On 02/03/11 11:48, Sourav Poddar wrote:
>
>> gpio_pendown in ads7846_probe is not getting initalized (defaulted to 0)
>> resulting in gpio_free to be called without a gpio_request. This
>> results in the following backtrace in bootup.
>>
>> [ cut here ]
>> WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x100/0x12c()
>> Modules linked in:
>> [] (unwind_backtrace+0x0/0xe4) from []
>> (warn_slowpath_common+0x4c/0x64)
>> [] (warn_slowpath_common+0x4c/0x64) from []
>> (warn_slowpath_null+0x18/0x1c)
>> [] (warn_slowpath_null+0x18/0x1c) from []
>> (gpio_free+0x100/0x12c)
>> [] (gpio_free+0x100/0x12c) from []
>> (ads7846_probe+0xa38/0xc5c)
>> [] (ads7846_probe+0xa38/0xc5c) from []
>> (spi_drv_probe+0x18/0x1c)
>> [] (spi_drv_probe+0x18/0x1c) from []
>> (driver_probe_device+0xc8/0x184)
>> [] (driver_probe_device+0xc8/0x184) from []
>> (__driver_attach+0x68/0x8c)
>> [] (__driver_attach+0x68/0x8c) from []
>> (bus_for_each_dev+0x48/0x74)
>> [] (bus_for_each_dev+0x48/0x74) from []
>> (bus_add_driver+0xa0/0x220)
>> [] (bus_add_driver+0xa0/0x220) from []
>> (driver_register+0xa8/0x134)
>> [] (driver_register+0xa8/0x134) from []
>> (do_one_initcall+0xcc/0x1a4)
>> [] (do_one_initcall+0xcc/0x1a4) from []
>> (kernel_init+0x14c/0x214)
>> [] (kernel_init+0x14c/0x214) from []
>> (kernel_thread_exit+0x0/0x8)
>> ---[ end trace 4053287f8a5ec18f ]---
>>
>> Initializing gpio_pendown in ads7846_probe to -1 before
>> ads7846_setup_pendown function removes the above backtrace
>> warning.
>>
>> Signed-off-by: Sourav Poddar
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> drivers/input/touchscreen/ads7846.c |1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/ads7846.c
>> b/drivers/input/touchscreen/ads7846.c
>> index 14ea54b..036f245 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -1221,6 +1221,7 @@ static int __devinit ads7846_probe(struct spi_device
>> *spi)
>> ts->input = input_dev;
>> ts->vref_mv = pdata->vref_mv;
>> ts->swap_xy = pdata->swap_xy;
>> +ts->gpio_pendown = -1;
> Wouldn't it be better putting this into ads7846_setup_pendown() function?
> This will keep the whole gpio_pendown initialization code close together.
> Something like:
>
> if (pdata->get_pendown_state) {
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/touchscreen/ads7846.c;h=14ea54b78e4648b0ac8a3403440f6f5d120dfdd9;hb=HEAD#l954>
> ts->get_pendown_state = pdata->get_pendown_state;
> ts->gpio_pendown = -1;
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/touchscreen/ads7846.c;h=14ea54b78e4648b0ac8a3403440f6f5d120dfdd9;hb=HEAD#l955>
> return 0;
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/touchscreen/ads7846.c;h=14ea54b78e4648b0ac8a3403440f6f5d120dfdd9;hb=HEAD#l956>}
Sorry for the above links (this is embarrassing, but I've got played by my
email client),
I meant of course:
if (pdata->get_pendown_state) {
ts->get_pendown_state = pdata->get_pendown_state;
ts->gpio_pendown = -1;
return 0;
}
>
> Also, why don't we use -EINVAL for the invalid gpio number instead of -1
> constant?
>
>>
>> mutex_init(&ts->lock);
>> init_waitqueue_head(&ts->wait);
--
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: [PATCHv2 1/2] ads7846: OMAP3: Removal of warnings backtrace in bootup
On 02/03/11 13:00, Poddar, Sourav wrote:
> On Thu, Feb 3, 2011 at 3:47 PM, Igor Grinberg wrote:
>> if (pdata->get_pendown_state) {
>>ts->get_pendown_state = pdata->get_pendown_state;
>>ts->gpio_pendown = -1;
>>return 0;
>> }
> Yes we can do so .I initialise it at a place where other variables
> where initialised.
>
>>> Also, why don't we use -EINVAL for the invalid gpio number instead of -1
>>> constant?
>>>
> I used -1 because conditional check done in probe ads7846_probe function
> used this value.
>
> err_free_gpio:
> if (ts->gpio_pendown != -1)
> gpio_free(ts->gpio_pendown);
>
Well I understand that and that's why in my proposal I used -1 also, but
I thought we can make it even better if we switch to -EINVAL
(though wanted to check if there are any reasonable objections)
and while you are at this, may be you are willing also to submit a patch for
this?
--
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: [PATCHv2 1/2] ads7846: OMAP3: Removal of warnings backtrace in bootup
Hi,
On 02/03/11 13:28, ABRAHAM, KISHON VIJAY wrote:
> On Thu, Feb 3, 2011 at 4:42 PM, Igor Grinberg wrote:
>>
>> On 02/03/11 13:00, Poddar, Sourav wrote:
>>
>>> On Thu, Feb 3, 2011 at 3:47 PM, Igor Grinberg
>>> wrote:
>>>> if (pdata->get_pendown_state) {
>>>>ts->get_pendown_state = pdata->get_pendown_state;
>>>>ts->gpio_pendown = -1;
>>>>return 0;
>>>> }
>>> Yes we can do so .I initialise it at a place where other variables
>>> where initialised.
>>>
>>>>> Also, why don't we use -EINVAL for the invalid gpio number instead of -1
>>>>> constant?
>>>>>
>>> I used -1 because conditional check done in probe ads7846_probe function
>>> used this value.
>>>
>>> err_free_gpio:
>>> if (ts->gpio_pendown != -1)
>>> gpio_free(ts->gpio_pendown);
>>>
>> Well I understand that and that's why in my proposal I used -1 also, but
>> I thought we can make it even better if we switch to -EINVAL
>> (though wanted to check if there are any reasonable objections)
>> and while you are at this, may be you are willing also to submit a patch for
>> this?
> I guess instead of -EINVAL, -EIO should be initialized to
> ts->gpio_pendown since that
> would be more appropriate for gpio
Well, the common practice is to use -EINVAL for gpio _numbers_,
I have not seen anyone using -EIO for this.
> and as Balbi suggested it would
> be better to use
> gpio_is_valid() for checking this error condition.
Of course gpio_is_valid() should be used for testing the gpio.
The -EINVAL in turn should be used for _setting_ the invalid value for that
gpio.
My suggestion for -EINVAL is related to the initialization:
if (pdata->get_pendown_state) {
ts->get_pendown_state = pdata->get_pendown_state;
ts->gpio_pendown = -EINVAL;
return 0;
}
--
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 v3 1/2] ads7846: fix gpio free without requesting
Hi,
On 02/03/11 17:47, Wolfram Sang wrote:
> On Thu, Feb 03, 2011 at 08:51:26PM +0530, Sourav Poddar wrote:
>> gpio_pendown in ads7846_probe is not getting initalized (defaulted to 0)
>> resulting in gpio_free being called without a gpio_request. This
>> results in the following backtrace in bootup (at least on an OMAP3430 SDP).
> I wonder if it makes sense to merge both patches under the name of "fix
> gpio-handling" or similar. Not sure, though...
I'd rather not do that, because this patch fixes the request/free problem
and the second is changing the functionality (e.g. configures the gpio as input)
>> diff --git a/drivers/input/touchscreen/ads7846.c
>> b/drivers/input/touchscreen/ads7846.c
>> index 14ea54b..ce5baee 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -952,6 +952,7 @@ static int __devinit ads7846_setup_pendown(struct
>> spi_device *spi, struct ads784
>>
>> if (pdata->get_pendown_state) {
>> ts->get_pendown_state = pdata->get_pendown_state;
>> +ts->gpio_pendown = -EINVAL;
>> return 0;
>> }
> Will probably work, but maybe it is better to reorganize the code to
> just have one success-exit-point. That would be mean adding an else
> branch to this if-block.
This is something that can be done, though I fear the code readability
will suffer. Is it worth?
>>
>> @@ -1353,7 +1354,7 @@ static int __devinit ads7846_probe(struct spi_device
>> *spi)
>> err_put_regulator:
>> regulator_put(ts->reg);
>> err_free_gpio:
>> -if (ts->gpio_pendown != -1)
>> +if (gpio_is_valid(ts->gpio_pendown))
> You could do the same in the remove-path.
You mean, _should_... ;)
Otherwise, the patch is not complete.
--
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 v3 2/2] Input: ads7846: use gpio_request_one to configure pendown_gpio
On 02/04/11 16:16, G, Manjunath Kondaiah wrote: > On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote: >> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote: >>> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote: On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote: > On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote: >> The ads7846 driver requests a gpio but does not currently >> configure it explicitly as an input. Use gpio_request_one >> to request and configure it at one shot. >> >> Signed-off-by: Sourav Poddar >> Cc: Dmitry Torokhov > Will apply this one, the other one is a bit messy IMO, will have to > think about it. > Something like below should do I think. >>> Patch looks good but it applies only on top of previous patch: >>> https://patchwork.kernel.org/patch/529941/ >>> >>> Why to have two patches for this fix? >> http://www.spinics.net/lists/linux-omap/msg45167.html > My point here is: > 1. The first patch only replaces gpio_request with gpio_request_one > 2. Rest of the things are handled in 2nd patch posted by dmitry > > What is harm in merging both the patches? I don't think it affects > readability. Because the changes introduced by the patches are from different nature. As stated in the link above, one is a functional change (gpio setup change) and second is fixing the imbalance in request - free calls. The impact is not readability, but bad bisect-ability. -- 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 v3 2/2] Input: ads7846: use gpio_request_one to configure pendown_gpio
Hi Dmitry,
On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote:
>> On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote:
>>> The ads7846 driver requests a gpio but does not currently
>>> configure it explicitly as an input. Use gpio_request_one
>>> to request and configure it at one shot.
>>>
>>> Signed-off-by: Sourav Poddar
>>> Cc: Dmitry Torokhov
>> Will apply this one, the other one is a bit messy IMO, will have to
>> think about it.
>>
> Something like below should do I think.
Personally, I don't like the "if{}else if{}else{}" stuff and prefer spartan
programming techniques instead, but the "if-else" below still looks ok,
having a single success exit point is important and everybody is fine
with that approach - then I'm fine with it too.
Thanks for hopping in :)
>
> Dmitry
>
>
> Input: ads7846 - check proper condition when freeing gpio
>
> From: Dmitry Torokhov
>
> When driver uses custom pendown detection method gpio_pendown is not
> set up and so we should not try to free it, otherwise we are presented
> with:
>
> [ cut here ]
> WARNING: at drivers/gpio/gpiolib.c:1258 gpio_free+0x100/0x12c()
> Modules linked in:
> [] (unwind_backtrace+0x0/0xe4) from
> [](warn_slowpath_common+0x4c/0x64)
> [] (warn_slowpath_common+0x4c/0x64) from
> [](warn_slowpath_null+0x18/0x1c)
> [] (warn_slowpath_null+0x18/0x1c) from
> [](gpio_free+0x100/0x12c)
> [] (gpio_free+0x100/0x12c) from
> [](ads7846_probe+0xa38/0xc5c)
> [] (ads7846_probe+0xa38/0xc5c) from
> [](spi_drv_probe+0x18/0x1c)
> [] (spi_drv_probe+0x18/0x1c) from
> [](driver_probe_device+0xc8/0x184)
> [] (driver_probe_device+0xc8/0x184) from
> [](__driver_attach+0x68/0x8c)
> [] (__driver_attach+0x68/0x8c) from
> [](bus_for_each_dev+0x48/0x74)
> [] (bus_for_each_dev+0x48/0x74) from
> [](bus_add_driver+0xa0/0x220)
> [] (bus_add_driver+0xa0/0x220) from
> [](driver_register+0xa8/0x134)
> [] (driver_register+0xa8/0x134) from
> [](do_one_initcall+0xcc/0x1a4)
> [] (do_one_initcall+0xcc/0x1a4) from
> [](kernel_init+0x14c/0x214)
> [] (kernel_init+0x14c/0x214) from
> [](kernel_thread_exit+0x0/0x8)
> ---[ end trace 4053287f8a5ec18f ]---
>
> Also rearrange ads7846_setup_pendown() to have only one exit point
> returning success.
>
> Reported-by: Sourav Poddar
> Signed-off-by: Dmitry Torokhov
> ---
>
> drivers/input/touchscreen/ads7846.c | 39
> ---
> 1 files changed, 22 insertions(+), 17 deletions(-)
>
>
> diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> index 0e9492d..b1217e1 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -946,30 +946,30 @@ static int __devinit ads7846_setup_pendown(struct
> spi_device *spi, struct ads784
> struct ads7846_platform_data *pdata = spi->dev.platform_data;
> int err;
>
> - /* REVISIT when the irq can be triggered active-low, or if for some
> + /*
> + * REVISIT when the irq can be triggered active-low, or if for some
>* reason the touchscreen isn't hooked up, we don't need to access
>* the pendown state.
>*/
> - if (!pdata->get_pendown_state && !gpio_is_valid(pdata->gpio_pendown)) {
> - dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> - return -EINVAL;
> - }
>
> if (pdata->get_pendown_state) {
> ts->get_pendown_state = pdata->get_pendown_state;
> - return 0;
> - }
> + } else if (gpio_is_valid(pdata->gpio_pendown)) {
> +
> + err = gpio_request_one(pdata->gpio_pendown, GPIOF_DIR_IN,
> + "ads7846_pendown");
> + if (err) {
> + dev_err(&spi->dev, "failed to request pendown GPIO%d\n",
> + pdata->gpio_pendown);
> + return err;
> + }
>
> - err = gpio_request_one(pdata->gpio_pendown, GPIOF_DIR_IN,
> - "ads7846_pendown");
> - if (err) {
> - dev_err(&spi->dev, "failed to request pendown GPIO%d\n",
> - pdata->gpio_pendown);
> - return err;
> + ts->gpio_pendown = pdata->gpio_pendown;
> + } else {
> + dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> + return -EINVAL;
> }
>
> - ts->gpio_pendown = pdata->gpio_pendown;
> -
> return 0;
> }
>
> @@ -1359,7 +1359,7 @@ static int __devinit ads7846_probe(struct spi_device
> *spi)
> err_put_regulator:
> regulator_put(ts->reg);
> err_free_gpio:
> - if (ts->gpio_pendown != -1)
> + if (!ts->get_pendown_state)
> gpio_free(ts->gpio_pendown);
> err_cleanup_filter:
> if (ts->filter_cleanup)
> @@ -1389,8 +1389,13 @@ static int __devexit ads7846_remove(struct spi_device
> *spi)
> regulator_disable(ts->reg);
> regulator_
Re: [PATCH v3 2/2] Input: ads7846: use gpio_request_one to configure pendown_gpio
On 02/04/11 17:11, Poddar, Sourav wrote: > On Fri, Feb 4, 2011 at 8:17 PM, Igor Grinberg wrote: >> >> On 02/04/11 16:16, G, Manjunath Kondaiah wrote: >> >>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote: >>>> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote: >>>>> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote: >>>>>> On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote: >>>>>>> On Thu, Feb 03, 2011 at 08:51:46PM +0530, Sourav Poddar wrote: >>>>>>>> The ads7846 driver requests a gpio but does not currently >>>>>>>> configure it explicitly as an input. Use gpio_request_one >>>>>>>> to request and configure it at one shot. >>>>>>>> >>>>>>>> Signed-off-by: Sourav Poddar >>>>>>>> Cc: Dmitry Torokhov >>>>>>> Will apply this one, the other one is a bit messy IMO, will have to >>>>>>> think about it. >>>>>>> >>>>>> Something like below should do I think. >>>>> Patch looks good but it applies only on top of previous patch: >>>>> https://patchwork.kernel.org/patch/529941/ >>>>> >>>>> Why to have two patches for this fix? >>>> http://www.spinics.net/lists/linux-omap/msg45167.html >>> My point here is: >>> 1. The first patch only replaces gpio_request with gpio_request_one >>> 2. Rest of the things are handled in 2nd patch posted by dmitry >>> >>> What is harm in merging both the patches? I don't think it affects >>> readability. >> Because the changes introduced by the patches are from different nature. >> As stated in the link above, one is a functional change (gpio setup change) >> and second is fixing the imbalance in request - free calls. >> The impact is not readability, but bad bisect-ability. > Dmitry's patch fixes both the problems(request/free and direction) > in a single patch itself.Now there is no need of merging any patches. > Just that Dmitry's patch need to be rebased over the top of HEAD. > (Currently, > its on top of my patch series). Well, here you have missed the point of direction: ... + err = gpio_request_one(pdata->gpio_pendown, GPIOF_DIR_IN, + "ads7846_pendown"); ... - err = gpio_request_one(pdata->gpio_pendown, GPIOF_DIR_IN, - "ads7846_pendown"); ... It does not deal with direction, but only with request - free balance. The gpio direction is fixed by your patch. -- 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 v3 2/2] Input: ads7846: use gpio_request_one to configure pendown_gpio
Hi, On 02/04/11 17:15, G, Manjunath Kondaiah wrote: > On Fri, Feb 04, 2011 at 04:47:09PM +0200, Igor Grinberg wrote: >> On 02/04/11 16:16, G, Manjunath Kondaiah wrote: >>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote: >>>> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote: >>>>> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote: >>>>>> Something like below should do I think. >>>>> Patch looks good but it applies only on top of previous patch: >>>>> https://patchwork.kernel.org/patch/529941/ >>>>> >>>>> Why to have two patches for this fix? >>>> http://www.spinics.net/lists/linux-omap/msg45167.html >>> My point here is: >>> 1. The first patch only replaces gpio_request with gpio_request_one >>> 2. Rest of the things are handled in 2nd patch posted by dmitry >>> >>> What is harm in merging both the patches? I don't think it affects >>> readability. >> Because the changes introduced by the patches are from different nature. >> As stated in the link above, one is a functional change (gpio setup change) >> and second is fixing the imbalance in request - free calls. >> The impact is not readability, but bad bisect-ability. > ok. But the patch2(dmitry's patch) is doing more than what it is mentioned in > patch description. It checks for validity of gpio, comment correction > etc which needs to be updated in the patch description. gpio validity is a part of request - free balance fix, comment change is just a coding style fix - really minor. Personally, I think Dmitry's description of the patch is just fine, but if you insist on making it somehow better, then suggest it to Dmitry. -- 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 v3 2/2] Input: ads7846: use gpio_request_one to configure pendown_gpio
> On Fri, Feb 4, 2011 at 9:00 PM, Igor Grinberg wrote: >> >> On 02/04/11 17:11, Poddar, Sourav wrote: >> >>> On Fri, Feb 4, 2011 at 8:17 PM, Igor Grinberg >>> wrote: >>>> On 02/04/11 16:16, G, Manjunath Kondaiah wrote: >>>> >>>>> On Fri, Feb 04, 2011 at 03:08:47PM +0100, Wolfram Sang wrote: >>>>>> On Fri, Feb 04, 2011 at 07:02:50PM +0530, G, Manjunath Kondaiah wrote: >>>>>>> On Thu, Feb 03, 2011 at 09:19:53AM -0800, Dmitry Torokhov wrote: >>>>>>>> On Thu, Feb 03, 2011 at 08:54:05AM -0800, Dmitry Torokhov wrote: >>>>>>>>> Something like below should do I think. >>>>>>> Patch looks good but it applies only on top of previous patch: >>>>>>> https://patchwork.kernel.org/patch/529941/ >>>>>>> >>>>>>> Why to have two patches for this fix? >>>>>> http://www.spinics.net/lists/linux-omap/msg45167.html >>>>> My point here is: >>>>> 1. The first patch only replaces gpio_request with gpio_request_one >>>>> 2. Rest of the things are handled in 2nd patch posted by dmitry >>>>> >>>>> What is harm in merging both the patches? I don't think it affects >>>>> readability. >>>> Because the changes introduced by the patches are from different nature. >>>> As stated in the link above, one is a functional change (gpio setup change) >>>> and second is fixing the imbalance in request - free calls. >>>> The impact is not readability, but bad bisect-ability. >>> Dmitry's patch fixes both the problems(request/free and direction) >>> in a single patch itself.Now there is no need of merging any patches. >>> Just that Dmitry's patch need to be rebased over the top of HEAD. >>> (Currently, >>> its on top of my patch series). >> Well, here you have missed the point of direction: >> ... >> >> + err = gpio_request_one(pdata->gpio_pendown, GPIOF_DIR_IN, >> + "ads7846_pendown"); >> >> ... >> >> - err = gpio_request_one(pdata->gpio_pendown, GPIOF_DIR_IN, >> - "ads7846_pendown"); >> ... >> >> >> It does not deal with direction, but only with request - free balance. >> The gpio direction is fixed by your patch. >> > gpio_request_one is a different API which calls gpio_direction_input > for configuring the direction. That is exactly the point :) Your patch has added the gpio_request_one() and thus changed the gpio direction. This patch only moves it around. -- 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
[PATCH] [ARM] video/omap2/tdo35s: fix visual artefacts
TDO35S samples the data on the falling adge of the pixel clock,
therefore the data strobe should be on the raising edge.
Signed-off-by: Igor Grinberg
Signed-off-by: Mike Rapoport
---
.../video/omap2/displays/panel-toppoly-tdo35s.c|8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
index fa434ca..e320e67 100644
--- a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -73,8 +73,12 @@ static void toppoly_tdo_panel_power_off(struct
omap_dss_device *dssdev)
static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
{
- dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
- OMAP_DSS_LCD_IHS;
+ dssdev->panel.config = OMAP_DSS_LCD_TFT |
+ OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS |
+ OMAP_DSS_LCD_IPC |
+ OMAP_DSS_LCD_ONOFF;
+
dssdev->panel.timings = toppoly_tdo_panel_timings;
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [ARM] omap/board-cm-t35: fix visual artefacts
CM-T35 DVI transmitter sampling the data on the raising edge of the pixel clock, therefore the data strobe should happen on the falling edge. Signed-off-by: Igor Grinberg Signed-off-by: Mike Rapoport --- arch/arm/mach-omap2/board-cm-t35.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index e679a2c..015ebf8 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -349,6 +349,8 @@ static int cm_t35_panel_enable_dvi(struct omap_dss_device *dssdev) return -EINVAL; } + dssdev->panel.config |= OMAP_DSS_LCD_IPC | OMAP_DSS_LCD_ONOFF; + gpio_set_value(dvi_en_gpio, 0); dvi_enabled = 1; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [ARM] video/omap2/tdo35s: fix visual artefacts
Tomi,
Any comments?
> TDO35S samples the data on the falling adge of the pixel clock,
> therefore the data strobe should be on the raising edge.
>
> Signed-off-by: Igor Grinberg
> Signed-off-by: Mike Rapoport
> ---
> .../video/omap2/displays/panel-toppoly-tdo35s.c|8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> index fa434ca..e320e67 100644
> --- a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> +++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> @@ -73,8 +73,12 @@ static void toppoly_tdo_panel_power_off(struct
> omap_dss_device *dssdev)
>
> static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
> {
> - dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> - OMAP_DSS_LCD_IHS;
> + dssdev->panel.config = OMAP_DSS_LCD_TFT |
> +OMAP_DSS_LCD_IVS |
> +OMAP_DSS_LCD_IHS |
> +OMAP_DSS_LCD_IPC |
> +OMAP_DSS_LCD_ONOFF;
> +
> dssdev->panel.timings = toppoly_tdo_panel_timings;
>
> return 0;
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [ARM] video/omap2/tdo35s: fix visual artefacts
ping!
> TDO35S samples the data on the falling adge of the pixel clock,
> therefore the data strobe should be on the raising edge.
>
> Signed-off-by: Igor Grinberg
> Signed-off-by: Mike Rapoport
> ---
> .../video/omap2/displays/panel-toppoly-tdo35s.c|8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> index fa434ca..e320e67 100644
> --- a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> +++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
> @@ -73,8 +73,12 @@ static void toppoly_tdo_panel_power_off(struct
> omap_dss_device *dssdev)
>
> static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
> {
> - dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> - OMAP_DSS_LCD_IHS;
> + dssdev->panel.config = OMAP_DSS_LCD_TFT |
> +OMAP_DSS_LCD_IVS |
> +OMAP_DSS_LCD_IHS |
> +OMAP_DSS_LCD_IPC |
> +OMAP_DSS_LCD_ONOFF;
> +
> dssdev->panel.timings = toppoly_tdo_panel_timings;
>
> return 0;
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [ARM] video/omap2/tdo35s: fix visual artefacts
> > On Wed, 2010-07-21 at 16:36 +0200, ext Igor Grinberg wrote: > >> ping! >> > Man has to have his vacation! > > Well, sorry for that... I had no idea you are on vacation, but I hope you had a good one :) >>> TDO35S samples the data on the falling adge of the pixel clock, >>> therefore the data strobe should be on the raising edge. >>> > Looks fine to me, except I'd like the patch subject to be in line with > the other patches (ie. prefixed by OMAP: DSS2: ...), and I think it > should describe the change more precisely, perhaps something like "fix > the video signal". > > I'm still new to omap and mostly worked on pxa's till now, so I brought the subject from there... > I can make those changes as I apply it to my tree, if it's ok to you. > It is completely fine with me :) > 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 > > -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [ARM] omap/board-cm-t35: fix visual artefacts
> > CM-T35 DVI transmitter sampling the data on the raising edge of the > pixel clock, therefore the data strobe should happen on the falling > edge. > > Signed-off-by: Igor Grinberg > Signed-off-by: Mike Rapoport > NAK, this only fixes the pixel clock sampling on the second call to the platform enable function, because the dss configuration is done before the first call. I will send another patch for this. Sorry for misleading. > --- > arch/arm/mach-omap2/board-cm-t35.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-cm-t35.c > b/arch/arm/mach-omap2/board-cm-t35.c > index e679a2c..015ebf8 100644 > --- a/arch/arm/mach-omap2/board-cm-t35.c > +++ b/arch/arm/mach-omap2/board-cm-t35.c > @@ -349,6 +349,8 @@ static int cm_t35_panel_enable_dvi(struct omap_dss_device > *dssdev) > return -EINVAL; > } > > + dssdev->panel.config |= OMAP_DSS_LCD_IPC | OMAP_DSS_LCD_ONOFF; > + > gpio_set_value(dvi_en_gpio, 0); > dvi_enabled = 1; > > -- 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
[PATCH 1/2] OMAP: DSS2: enable generic panel configuration modification
This patch enables platforms to modify the dss device configuration
of the generic panel.
Signed-off-by: Igor Grinberg
Signed-off-by: Mike Rapoport
---
drivers/video/omap2/displays/panel-generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
index 300eff5..ad80dd0 100644
--- a/drivers/video/omap2/displays/panel-generic.c
+++ b/drivers/video/omap2/displays/panel-generic.c
@@ -66,7 +66,7 @@ static void generic_panel_power_off(struct omap_dss_device
*dssdev)
static int generic_panel_probe(struct omap_dss_device *dssdev)
{
- dssdev->panel.config = OMAP_DSS_LCD_TFT;
+ dssdev->panel.config |= OMAP_DSS_LCD_TFT;
dssdev->panel.timings = generic_panel_timings;
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [ARM] omap: cm-t35: fix video signal on DVI panels
CM-T35 DVI transmitter sampling the data on the raising edge of the
pixel clock, therefore the data strobe should happen on the falling
edge.
Signed-off-by: Igor Grinberg
Signed-off-by: Mike Rapoport
---
arch/arm/mach-omap2/board-cm-t35.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e679a2c..1b636f8 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -384,6 +384,7 @@ static struct omap_dss_device cm_t35_dvi_device = {
.driver_name= "generic_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
+ .panel.config = OMAP_DSS_LCD_IPC | OMAP_DSS_LCD_ONOFF,
.platform_enable= cm_t35_panel_enable_dvi,
.platform_disable = cm_t35_panel_disable_dvi,
};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: DSS2: enable generic panel configuration modification
On 07/27/10 11:00, Tomi Valkeinen wrote:
> On Mon, 2010-07-26 at 12:34 +0200, ext Igor Grinberg wrote:
>
>> This patch enables platforms to modify the dss device configuration
>> of the generic panel.
>>
>> Signed-off-by: Igor Grinberg
>> Signed-off-by: Mike Rapoport
>> ---
>> drivers/video/omap2/displays/panel-generic.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/omap2/displays/panel-generic.c
>> b/drivers/video/omap2/displays/panel-generic.c
>> index 300eff5..ad80dd0 100644
>> --- a/drivers/video/omap2/displays/panel-generic.c
>> +++ b/drivers/video/omap2/displays/panel-generic.c
>> @@ -66,7 +66,7 @@ static void generic_panel_power_off(struct omap_dss_device
>> *dssdev)
>>
>> static int generic_panel_probe(struct omap_dss_device *dssdev)
>> {
>> -dssdev->panel.config = OMAP_DSS_LCD_TFT;
>> +dssdev->panel.config |= OMAP_DSS_LCD_TFT;
>> dssdev->panel.timings = generic_panel_timings;
>>
>> return 0;
>>
>
> I don't like this. Panel driver should be the one which decides the
> config.
>
I agree with this in most cases, but not always.
There are certain transmitters (like TI TFP410 dvi transmitter found
on cm-t35 and other boards) that can have some of their parameters
defined by hardware (strapped), so only the platform knows the correct
values for them.
One of such parameters is the edge of the clock sampling.
> I think a better solution is to make panel-generic configurable, which
> has been discussed a bit some time ago on l-o.
>
No doubt about that :)
> Briefly:
>
> - Add a struct for the configuration variables (a bit like
> arch/arm/plat-omap/include/plat/nokia-dsi-panel.h).
>
> - Fill the struct in the board file, and pass it to the panel driver via
> omap_dss_device->data pointer.
>
> - The panel driver get the struct and uses it to do whatever
> configuration it needs.
>
This is more or less what I've been thinking of, but with slight addition:
the panel driver should have a defaults for all the parameters,
so there will be no need to provide the whole parameters list,
just the ones that are different.
> I think there are two ways to implement this:
>
> 1) Have lots of fields in the struct, including video timings and video
> signaling information, and the driver uses these directly.
>
This seems like a good choice for better flexibility and
provides an easy way of dealing with the issues, I've described above.
> 2) Have a panel name in the struct, and the panel driver contains a
> static list of panels, including configurations for those panels, and
> the driver selects the configuration based on the panel name given from
> the board file. (like drivers/video/omap2/displays/panel-taal.c does,
> except there's currently only one panel defined).
>
This approach does not deal with the dvi transmitters issue above,
unless there will be possibility to define some kind of platform data.
Also, if we have a static list of panels with their configurations,
there could be panels with (almost) the same parameters defined
for a couple of times.
> While 1. gives perhaps slightly easier configuration, as you just edit
> the board file, I'd go for 2. because the required configuration is
> really defined by the panel/chip being used, and so the board file
> should just state which panel/chip we have, and the driver handles the
> rest.
Well, unfortunately, it is not :(
> And 2. makes it also easier to use the same panel/chip on multiple
> boards.
>
> Implementing this would allow us to remove some panel drivers which
> currently are 99% copies of each other.
>
> Tomi
>
>
My idea is:
generic driver will have built-in defaults, that can
(but not necessarily will) be overridden by platform (or other) code
on a parameter basis.
This will allow other panels (like tdo35s) reuse the generic driver
without the need for their special driver.
What do you think of it?
--
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 1/2] OMAP: DSS2: enable generic panel configuration modification
Tomi,
Any thoughts?
On 07/27/10 16:59, Igor Grinberg wrote:
> On 07/27/10 11:00, Tomi Valkeinen wrote:
>
>> On Mon, 2010-07-26 at 12:34 +0200, ext Igor Grinberg wrote:
>>
>>
>>> This patch enables platforms to modify the dss device configuration
>>> of the generic panel.
>>>
>>> Signed-off-by: Igor Grinberg
>>> Signed-off-by: Mike Rapoport
>>> ---
>>> drivers/video/omap2/displays/panel-generic.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/displays/panel-generic.c
>>> b/drivers/video/omap2/displays/panel-generic.c
>>> index 300eff5..ad80dd0 100644
>>> --- a/drivers/video/omap2/displays/panel-generic.c
>>> +++ b/drivers/video/omap2/displays/panel-generic.c
>>> @@ -66,7 +66,7 @@ static void generic_panel_power_off(struct
>>> omap_dss_device *dssdev)
>>>
>>> static int generic_panel_probe(struct omap_dss_device *dssdev)
>>> {
>>> - dssdev->panel.config = OMAP_DSS_LCD_TFT;
>>> + dssdev->panel.config |= OMAP_DSS_LCD_TFT;
>>> dssdev->panel.timings = generic_panel_timings;
>>>
>>> return 0;
>>>
>>>
>> I don't like this. Panel driver should be the one which decides the
>> config.
>>
>>
> I agree with this in most cases, but not always.
> There are certain transmitters (like TI TFP410 dvi transmitter found
> on cm-t35 and other boards) that can have some of their parameters
> defined by hardware (strapped), so only the platform knows the correct
> values for them.
> One of such parameters is the edge of the clock sampling.
>
>
>> I think a better solution is to make panel-generic configurable, which
>> has been discussed a bit some time ago on l-o.
>>
>>
> No doubt about that :)
>
>
>> Briefly:
>>
>> - Add a struct for the configuration variables (a bit like
>> arch/arm/plat-omap/include/plat/nokia-dsi-panel.h).
>>
>> - Fill the struct in the board file, and pass it to the panel driver via
>> omap_dss_device->data pointer.
>>
>> - The panel driver get the struct and uses it to do whatever
>> configuration it needs.
>>
>>
> This is more or less what I've been thinking of, but with slight addition:
> the panel driver should have a defaults for all the parameters,
> so there will be no need to provide the whole parameters list,
> just the ones that are different.
>
>
>> I think there are two ways to implement this:
>>
>> 1) Have lots of fields in the struct, including video timings and video
>> signaling information, and the driver uses these directly.
>>
>>
> This seems like a good choice for better flexibility and
> provides an easy way of dealing with the issues, I've described above.
>
>
>> 2) Have a panel name in the struct, and the panel driver contains a
>> static list of panels, including configurations for those panels, and
>> the driver selects the configuration based on the panel name given from
>> the board file. (like drivers/video/omap2/displays/panel-taal.c does,
>> except there's currently only one panel defined).
>>
>>
> This approach does not deal with the dvi transmitters issue above,
> unless there will be possibility to define some kind of platform data.
> Also, if we have a static list of panels with their configurations,
> there could be panels with (almost) the same parameters defined
> for a couple of times.
>
>
>> While 1. gives perhaps slightly easier configuration, as you just edit
>> the board file, I'd go for 2. because the required configuration is
>> really defined by the panel/chip being used, and so the board file
>> should just state which panel/chip we have, and the driver handles the
>> rest.
>>
> Well, unfortunately, it is not :(
>
>
>> And 2. makes it also easier to use the same panel/chip on multiple
>> boards.
>>
>> Implementing this would allow us to remove some panel drivers which
>> currently are 99% copies of each other.
>>
>> Tomi
>>
>>
>>
> My idea is:
> generic driver will have built-in defaults, that can
> (but not necessarily will) be overridden by platform (or other) code
> on a parameter basis.
> This will allow other panels (like tdo35s) reuse the generic driver
> without the need for their special driver.
>
> What do you think of it?
>
>
--
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/8] davinci: add mdio platform devices
On 08/03/10 16:31, Cyril Chemparathy wrote: > This patch adds mdio platform devices on SoCs that have the necessary > hardware. Clock lookup entries (aliases) have also been added, so that the > MDIO and EMAC drivers can independently enable/disable a shared underlying > clock. Further, the EMAC MMR region has been split down into separate MDIO > and EMAC regions. > > Signed-off-by: Cyril Chemparathy > --- > arch/arm/mach-davinci/devices-da8xx.c | 29 +- > arch/arm/mach-davinci/dm365.c | 22 +++- > arch/arm/mach-davinci/dm644x.c | 22 +++- > arch/arm/mach-davinci/dm646x.c | 22 +++- > arch/arm/mach-davinci/include/mach/dm365.h |1 + > arch/arm/mach-davinci/include/mach/dm644x.h |1 + > arch/arm/mach-davinci/include/mach/dm646x.h |1 + > 7 files changed, 93 insertions(+), 5 deletions(-) > Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list? I think it should, or else it will be broken by: [PATCH 5/8] netdev: cleanup unused davinci mdio emac code -- 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/8] davinci: add mdio platform devices
On 08/03/10 17:32, Cyril Chemparathy wrote: > Hi Igor, > > >> Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list? >> I think it should, or else it will be broken by: >> [PATCH 5/8] netdev: cleanup unused davinci mdio emac code >> > Correct. As stated in the series summary: > > >> Additional omap tree patches will be required for am35xx as well >> (not included here). >> Sorry for missing that, my laziness and long cover letter made me miss it :) Do you plan on bringing those patches? Wouldn't it be better for those patches to be included in the series? Because, merging code that breaks other platform(s) is not so nice... > Regards > Cyril. > > -- 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] OMAP2: Fix a cpu type check problem.
On 08/10/10 15:36, Stanley.Miao wrote:
> cpu_is_omap3517() and cpu_is_omap3505() are the subgroups of
> cpu_is_omap34xx(),
> so we should check cpu_is_omap3517() and cpu_is_omap3505() first, then check
> cpu_is_omap34xx().
>
> Signed-off-by: Stanley.Miao
>
Tested-by: Igor Grinberg
I've just ran into this yesterday evening.
Having a patch for this on the next day made me :)
Tested on AM3517.
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index 138646d..dfdce2d 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3417,7 +3417,13 @@ int __init omap3xxx_clk_init(void)
> struct omap_clk *c;
> u32 cpu_clkflg = CK_3XXX;
>
> - if (cpu_is_omap34xx()) {
> + if (cpu_is_omap3517()) {
> + cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
> + cpu_clkflg |= CK_3517;
> + } else if (cpu_is_omap3505()) {
> + cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
> + cpu_clkflg |= CK_3505;
> + } else if (cpu_is_omap34xx()) {
> cpu_mask = RATE_IN_3XXX;
> cpu_clkflg |= CK_343X;
>
> @@ -3432,12 +3438,6 @@ int __init omap3xxx_clk_init(void)
> cpu_mask |= RATE_IN_3430ES2PLUS;
> cpu_clkflg |= CK_3430ES2;
> }
> - } else if (cpu_is_omap3517()) {
> - cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
> - cpu_clkflg |= CK_3517;
> - } else if (cpu_is_omap3505()) {
> - cpu_mask = RATE_IN_3XXX | RATE_IN_3430ES2PLUS;
> - cpu_clkflg |= CK_3505;
> }
>
> if (omap3_has_192mhz_clk())
>
--
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] OMAP2: Fix a cpu type check problem.
On 08/11/10 13:27, Tony Lindgren wrote: > * Premi, Sanjeev [100811 12:45]: > >>> -Original Message- >>> From: linux-omap-ow...@vger.kernel.org >>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren >>> Sent: Wednesday, August 11, 2010 2:50 PM >>> To: Igor Grinberg >>> Cc: Stanley.Miao; linux-omap@vger.kernel.org >>> Subject: Re: [PATCH] OMAP2: Fix a cpu type check problem. >>> >>> * Igor Grinberg [100810 17:25]: >>> >>>> On 08/10/10 15:36, Stanley.Miao wrote: >>>> >>>>> cpu_is_omap3517() and cpu_is_omap3505() are the subgroups >>>>> >>> of cpu_is_omap34xx(), >>> >>>>> so we should check cpu_is_omap3517() and >>>>> >>> cpu_is_omap3505() first, then check >>> >>>>> cpu_is_omap34xx(). >>>>> >>>>> Signed-off-by: Stanley.Miao >>>>> >>>>> >>>> Tested-by: Igor Grinberg >>>> >>>> I've just ran into this yesterday evening. >>>> Having a patch for this on the next day made me :) >>>> Tested on AM3517. >>>> >>> Can you please describe what breaks so we can merge this as a fix? >>> >>> >> cpu_is_34xx() will be true for all OMAP3 based devices including >> AM3517. So, if we want to perform operations specific to AM3517, the >> check for AM3517 should be done first else you match for 34xx would >> return true; and you wouldn't go far enough to check for am3517. >> > Understood, but we need some concrete error like "otherwise booting > xyz board fails with non-working USB" or similar. > Otherwise, All AM35XX (Sitara) clocks do not get registered and device drivers (ti_hecc, etc...) that depend on those clocks are failing to get the clock and end up with non working device. > Tony > > -- 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: [PATCHv2 0/13] OMAP: dmtimer: hwmod
On 08/14/10 18:39, Tarun Kanti DebBarma wrote: > This patch series contains: > (*) most of the comments provided in v1 implemented and > (*) OMAP4 timers support > > The comment details are availabe in respective patch series. > > The comment regarding usage of "dmtimer" name will be resolved > after final round of consultation with members. > > Baseline: "origin/pm-wip/hwmods-omap4" > Test info: Tested on OMAP4430SDP, OMAP3630SDP > > Tarun Kanti DebBarma (13): > dmtimer: hwmod: OMAP4: add device names to flck nodes > dmtimer: hwmod: add omap3xxx database > dmtimer: hwmod: OMAP: rev field to identify timer version > dmtimer: hwmod: OMAP: api to read omap_hwmod _clk > dmtimer: hwmod: OMAP: conversion to platform driver > dmtimer: OMAP: multi-platform register map definitions > dmtimer: hwmod: OMAP2PLUS: device registration > dmtimer: OMAP: multi-platform register access support > dmtimer: hwmod: OMAP3: add device names to flck nodes > dmtimer: hwmod: add omap2430 database > dmtimer: hwmod: add omap2420 database > dmtimer: hwmod: OMAP2: add device names to flck nodes > dmtimer: hwmod: OMAP1: device registration > > arch/arm/mach-omap1/Makefile |2 +- > arch/arm/mach-omap1/dmtimer.c| 146 + > arch/arm/mach-omap1/timer32k.c |3 - > arch/arm/mach-omap2/Makefile |2 +- > arch/arm/mach-omap2/clock2420_data.c | 12 + > arch/arm/mach-omap2/clock2430_data.c | 12 + > arch/arm/mach-omap2/clock3xxx_data.c | 24 +- > arch/arm/mach-omap2/clock44xx_data.c | 22 +- > arch/arm/mach-omap2/dmtimer.c| 403 + > arch/arm/mach-omap2/dmtimer.h| 19 + > arch/arm/mach-omap2/io.c |2 + > arch/arm/mach-omap2/omap_hwmod.c | 21 + > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 597 > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 595 > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 674 ++ > arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 + > arch/arm/mach-omap2/timer-gp.c |1 - > arch/arm/plat-omap/dmtimer.c | 781 > -- > arch/arm/plat-omap/include/plat/dmtimer.h| 15 +- > arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + > 20 files changed, 2894 insertions(+), 441 deletions(-) > mode change 100644 => 100755 arch/arm/mach-omap1/Makefile > create mode 100755 arch/arm/mach-omap1/dmtimer.c > mode change 100644 => 100755 arch/arm/mach-omap1/timer32k.c > mode change 100644 => 100755 arch/arm/mach-omap2/clock2420_data.c > mode change 100644 => 100755 arch/arm/mach-omap2/clock2430_data.c > mode change 100644 => 100755 arch/arm/mach-omap2/clock3xxx_data.c > mode change 100644 => 100755 arch/arm/mach-omap2/clock44xx_data.c > create mode 100755 arch/arm/mach-omap2/dmtimer.c > create mode 100755 arch/arm/mach-omap2/dmtimer.h > mode change 100644 => 100755 arch/arm/mach-omap2/io.c > mode change 100644 => 100755 arch/arm/mach-omap2/omap_hwmod.c > mode change 100644 => 100755 arch/arm/mach-omap2/omap_hwmod_2420_data.c > mode change 100644 => 100755 arch/arm/mach-omap2/omap_hwmod_2430_data.c > mode change 100644 => 100755 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > mode change 100644 => 100755 arch/arm/mach-omap2/omap_hwmod_44xx_data.c > mode change 100644 => 100755 arch/arm/plat-omap/dmtimer.c > mode change 100644 => 100755 arch/arm/plat-omap/include/plat/dmtimer.h > mode change 100644 => 100755 arch/arm/plat-omap/include/plat/omap_hwmod.h > What the point of all this mode changes? What's wrong with 644? > -- > To unsubscribe from this list: send the line "unsubscribe 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
AM3517 (Sitara) MMC2 help
Hi, I have am3517 based board and Libertas sdio (4 wires) wifi connected directly (no transceiver / level shifter) on mmc2 (which is named mmc1 in s/w). am3517 is configured (h/w) for 3.3V and so is Libertas wifi. dmesg | grep mmc1 shows: --cut-- mux: Setting signal sdmmc1_clk.sdmmc1_clk 0x -> 0x0118 mux: Setting signal sdmmc1_cmd.sdmmc1_cmd 0x -> 0x0118 mux: Setting signal sdmmc1_dat0.sdmmc1_dat0 0x0100 -> 0x0118 mux: Setting signal sdmmc1_dat1.sdmmc1_dat1 0x0100 -> 0x0118 mux: Setting signal sdmmc1_dat2.sdmmc1_dat2 0x0100 -> 0x0118 mux: Setting signal sdmmc1_dat3.sdmmc1_dat3 0x0100 -> 0x0118 mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0 mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 mmc1: starting CMD52 arg 0c00 flags 0195 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x0c00 mmc1: req done (CMD52): -110: mmc1: starting CMD52 arg 8c08 flags 0195 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x8c08 mmc1: req done (CMD52): -110: mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0 mmc1: starting CMD0 arg flags 00c0 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x mmc1: req done (CMD0): 0: mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 mmc1: starting CMD8 arg 01aa flags 02f5 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x01aa mmc1: req done (CMD8): -110: mmc1: starting CMD5 arg flags 02e1 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x mmc1: req failed (CMD5): -110, retrying... mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x mmc1: req failed (CMD5): -110, retrying... mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x mmc1: req failed (CMD5): -110, retrying... mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x mmc1: req done (CMD5): -110: mmc1: starting CMD55 arg flags 00f5 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x mmc1: req done (CMD55): -110: mmc1: starting CMD55 arg flags 00f5 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x mmc1: req done (CMD55): -110: mmc1: starting CMD55 arg flags 00f5 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x mmc1: req done (CMD55): -110: mmc1: starting CMD55 arg flags 00f5 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x mmc1: req done (CMD55): -110: mmc1: starting CMD1 arg flags 00e1 mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x mmc1: req done (CMD1): -110: mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 ---cut- Libertas is powered up and gets reseted properly. On the oscilloscope, I see some communication going on the CMD line and stops after some time. am3517 PSP from TI, does not even registers/enables the wifi combo found on am3517evm. Have anybody got the mmc2 working on am3517? May be with transceiver? Any help will be appreciated. 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: AM3517 (Sitara) MMC2 help
On 08/25/10 03:36, Laine Walker-Avina wrote: > On Tue, Aug 24, 2010 at 5:29 PM, Laine Walker-Avina wrote: >> On Tue, Aug 24, 2010 at 5:42 AM, Igor Grinberg >> wrote: >>> Hi, >>> >>> I have am3517 based board and Libertas sdio (4 wires) >>> wifi connected directly (no transceiver / level shifter) on mmc2 >>> (which is named mmc1 in s/w). >>> >>> am3517 is configured (h/w) for 3.3V and so is Libertas wifi. >>> >>> dmesg | grep mmc1 shows: >>> >>> --cut-- >>> mux: Setting signal sdmmc1_clk.sdmmc1_clk 0x -> 0x0118 >>> mux: Setting signal sdmmc1_cmd.sdmmc1_cmd 0x -> 0x0118 >>> mux: Setting signal sdmmc1_dat0.sdmmc1_dat0 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat1.sdmmc1_dat1 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat2.sdmmc1_dat2 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat3.sdmmc1_dat3 0x0100 -> 0x0118 > Also, shouldn't you setting the mux values for sdmmc2_* not sdmmc1_* > if your chip is on MMC2? Well, this is left unintentionally, I think I can remove this. omap2_mmc_mux() in arch/arm/mach-omap2/devices.c does the proper muxing of the lines according to .wires field of the platform data. I think, I don't need to do any muxing for the mmc (4 wires) at all in the board file. Am I right? >>> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >>> mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD52 arg 0c00 flags 0195 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x0c00 >>> mmc1: req done (CMD52): -110: >>> mmc1: starting CMD52 arg 8c08 flags 0195 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x8c08 >>> mmc1: req done (CMD52): -110: >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD0 arg flags 00c0 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x >>> mmc1: req done (CMD0): 0: >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD8 arg 01aa flags 02f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x01aa >>> mmc1: req done (CMD8): -110: >>> mmc1: starting CMD5 arg flags 02e1 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req done (CMD5): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD1 arg flags 00e1 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x >>> mmc1: req done (CMD1): -110: >>> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >>> ---cut- >>> >>> Libertas is powered up and gets reseted properly. >>> On the oscilloscope, I see some communication going >>> on the CMD line and stops after some time. >>> >>> am3517 PSP from TI, does not even registers/enables >>> the wifi combo found on am3517evm. >>> >>> Have anybody got the mmc2 working on am3517? >>> May be with transceiver? >&g
Re: AM3517 (Sitara) MMC2 help
On 08/25/10 03:29, Laine Walker-Avina wrote: > On Tue, Aug 24, 2010 at 5:42 AM, Igor Grinberg > wrote: >> Hi, >> >> I have am3517 based board and Libertas sdio (4 wires) >> wifi connected directly (no transceiver / level shifter) on mmc2 >> (which is named mmc1 in s/w). >> >> am3517 is configured (h/w) for 3.3V and so is Libertas wifi. >> >> dmesg | grep mmc1 shows: >> >> --cut-- >> mux: Setting signal sdmmc1_clk.sdmmc1_clk 0x -> 0x0118 >> mux: Setting signal sdmmc1_cmd.sdmmc1_cmd 0x -> 0x0118 >> mux: Setting signal sdmmc1_dat0.sdmmc1_dat0 0x0100 -> 0x0118 >> mux: Setting signal sdmmc1_dat1.sdmmc1_dat1 0x0100 -> 0x0118 >> mux: Setting signal sdmmc1_dat2.sdmmc1_dat2 0x0100 -> 0x0118 >> mux: Setting signal sdmmc1_dat3.sdmmc1_dat3 0x0100 -> 0x0118 >> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >> mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0 >> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >> mmc1: starting CMD52 arg 0c00 flags 0195 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x0c00 >> mmc1: req done (CMD52): -110: >> mmc1: starting CMD52 arg 8c08 flags 0195 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x8c08 >> mmc1: req done (CMD52): -110: >> mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0 >> mmc1: starting CMD0 arg flags 00c0 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x >> mmc1: req done (CMD0): 0: >> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >> mmc1: starting CMD8 arg 01aa flags 02f5 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x01aa >> mmc1: req done (CMD8): -110: >> mmc1: starting CMD5 arg flags 02e1 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >> mmc1: req failed (CMD5): -110, retrying... >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >> mmc1: req failed (CMD5): -110, retrying... >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >> mmc1: req failed (CMD5): -110, retrying... >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >> mmc1: req done (CMD5): -110: >> mmc1: starting CMD55 arg flags 00f5 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >> mmc1: req done (CMD55): -110: >> mmc1: starting CMD55 arg flags 00f5 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >> mmc1: req done (CMD55): -110: >> mmc1: starting CMD55 arg flags 00f5 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >> mmc1: req done (CMD55): -110: >> mmc1: starting CMD55 arg flags 00f5 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >> mmc1: req done (CMD55): -110: >> mmc1: starting CMD1 arg flags 00e1 >> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x >> mmc1: req done (CMD1): -110: >> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >> ---cut- >> >> Libertas is powered up and gets reseted properly. >> On the oscilloscope, I see some communication going >> on the CMD line and stops after some time. >> >> am3517 PSP from TI, does not even registers/enables >> the wifi combo found on am3517evm. >> >> Have anybody got the mmc2 working on am3517? >> May be with transceiver? >> >> Any help will be appreciated. >> >> 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 >> > Make sure the MMC2_CLK pin is muxed as an input so the clock can > feedback to the module. omap2_mmc_mux() in arch/arm/mach-omap2/devices.c is handling this and I think properly or else any omap will fail using the mmc2. > Also, you may need to set > CONTROL_DEVCONF1.MMCSDIO2ADPCLKISEL=1 if that exists on the Sitara. I > had the same problem on the OMAP3x. I will try that. 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: AM3517 (Sitara) MMC2 help
On 08/25/10 11:12, Igor Grinberg wrote: > On 08/25/10 03:29, Laine Walker-Avina wrote: >> On Tue, Aug 24, 2010 at 5:42 AM, Igor Grinberg >> wrote: >>> Hi, >>> >>> I have am3517 based board and Libertas sdio (4 wires) >>> wifi connected directly (no transceiver / level shifter) on mmc2 >>> (which is named mmc1 in s/w). >>> >>> am3517 is configured (h/w) for 3.3V and so is Libertas wifi. >>> >>> dmesg | grep mmc1 shows: >>> >>> --cut-- >>> mux: Setting signal sdmmc1_clk.sdmmc1_clk 0x -> 0x0118 >>> mux: Setting signal sdmmc1_cmd.sdmmc1_cmd 0x -> 0x0118 >>> mux: Setting signal sdmmc1_dat0.sdmmc1_dat0 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat1.sdmmc1_dat1 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat2.sdmmc1_dat2 0x0100 -> 0x0118 >>> mux: Setting signal sdmmc1_dat3.sdmmc1_dat3 0x0100 -> 0x0118 >>> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >>> mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD52 arg 0c00 flags 0195 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x0c00 >>> mmc1: req done (CMD52): -110: >>> mmc1: starting CMD52 arg 8c08 flags 0195 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x8c08 >>> mmc1: req done (CMD52): -110: >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD0 arg flags 00c0 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x >>> mmc1: req done (CMD0): 0: >>> mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0 >>> mmc1: starting CMD8 arg 01aa flags 02f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x01aa >>> mmc1: req done (CMD8): -110: >>> mmc1: starting CMD5 arg flags 02e1 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req failed (CMD5): -110, retrying... >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x >>> mmc1: req done (CMD5): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD55 arg flags 00f5 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x >>> mmc1: req done (CMD55): -110: >>> mmc1: starting CMD1 arg flags 00e1 >>> mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x >>> mmc1: req done (CMD1): -110: >>> mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 >>> ---cut- >>> >>> Libertas is powered up and gets reseted properly. >>> On the oscilloscope, I see some communication going >>> on the CMD line and stops after some time. >>> >>> am3517 PSP from TI, does not even registers/enables >>> the wifi combo found on am3517evm. >>> >>> Have anybody got the mmc2 working on am3517? >>> May be with transceiver? >>> >>> Any help will be appreciated. >>> >>> 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 >>> >> Make sure the MMC2_CLK pin is muxed as an input so the clock can >> feedback to the module. > omap2_mmc_mux() in arch/arm/mach-omap2/devices.c is handling this > and I think properly or else any omap will fail using the mmc2. > >> Also, you may need to set >> CONTROL_DEVCONF1.MMCSDIO2ADPCLKISEL=1 if that exists on the Sitara. I >> had the same problem on the OMAP3x. Nope... this does not help. Also, Stanley has restricted the above setting to non-am3517 cpus in commit 03e7e170d6fdc5b6f75d1ab2cc1a6cb4f2b6b8c4 Any other suggestions? Stanley, can you help us with this? -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix the ads7846 init code
Hi Kevin,
On 07/12/12 02:00, Kevin Hilman wrote:
> Hi Igor,
>
> Igor Grinberg writes:
>
>> In case a board provides the gpio_pendown and not board_pdata,
>> the GPIO debounce is not taken care of.
>> Fix this by taking care of GPIO debounce in any case.
>>
>> Signed-off-by: Igor Grinberg
>
> I just notice this this patch causing some faults in current l-o master
> branch.
This was not the case by the time I did the patch...
>
>> ---
>> arch/arm/mach-omap2/common-board-devices.c | 22 --
>> 1 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/common-board-devices.c
>> b/arch/arm/mach-omap2/common-board-devices.c
>> index 1706ebc..c187586 100644
>> --- a/arch/arm/mach-omap2/common-board-devices.c
>> +++ b/arch/arm/mach-omap2/common-board-devices.c
>> @@ -63,28 +63,30 @@ void __init omap_ads7846_init(int bus_num, int
>> gpio_pendown, int gpio_debounce,
>> struct spi_board_info *spi_bi = &ads7846_spi_board_info;
>> int err;
>>
>> -if (board_pdata && board_pdata->get_pendown_state) {
>> -err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>> -if (err) {
>> -pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>> -return;
>> -}
>> -gpio_export(gpio_pendown, 0);
>> -
>> -if (gpio_debounce)
>> -gpio_set_debounce(gpio_pendown, gpio_debounce);
>> +err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>> +if (err) {
>> +pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>> +return;
>> }
>>
>> +if (gpio_debounce)
>> +gpio_set_debounce(gpio_pendown, gpio_debounce);
>> +
>> spi_bi->bus_num = bus_num;
>> spi_bi->irq = gpio_to_irq(gpio_pendown);
>>
>> if (board_pdata) {
>> board_pdata->gpio_pendown = gpio_pendown;
>> spi_bi->platform_data = board_pdata;
>> +if (board_pdata->get_pendown_state)
>> +gpio_export(gpio_pendown, 0);
>> } else {
>> ads7846_config.gpio_pendown = gpio_pendown;
>> }
>>
>> +if (!board_pdata || (board_pdata && !board_pdata->get_pendown_state))
>> +gpio_free(gpio_pendown);
>
> The logic here for freeing the GPIO doesn't make any sense to me.
> IIUC, the gpio_pendown is always used, so should not be freed.
The gpio_pendown is requested by the ads7846 driver and
of course you can't request the GPIO second time, so the driver failed.
>
> Moreover, if this GPIO is freed, that allows that GPIO bank to runtime
> suspend if there are no other GPIOs in use in that bank. So the first
> attempt to use the GPIO will fault.
The ads7846 driver requests the GPIO prior to using it.
>
> For example, on my Overo board(s), I noticed this failing as soon as teh
> ads7846 driver probes, requests the IRQ and the GPIO triggering is set.
Prior to requesting the IRQ, the ads7846_setup_pendown(spi, ts) method
is called, which requests the GPIO.
>
> Getting rid of this free fixes the problem.
But then don't you have double requesting?
>
> The changelog doesn't describe why the GPIO is freed here so I'm not
> sure I follow, but it seems to me that once this GPIO is requesed, it
> should not be freed as long as it's used, otherwise PM faults can occur.
It is not used until the ads7846 driver probes.
>
> Kevin
>
>>From bb87c3b5586950e480d0699504997a9ad587fd85 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman
> Date: Wed, 11 Jul 2012 15:47:29 -0700
> Subject: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing
> pen-down GPIO
>
> commit 97ee9f01d6 (ARM: OMAP: fix the ads7846 init code) mistakenly
> frees the pen-down GPIO even though it will be used by the ads7846
> driver.
>
> Freeing a GPIO means that the GPIO bank containing that GPIO can be
> runtime suspended if its the last/only GPIO being used in that bank.
> If the GPIO bank is runtime suspended, any accesses to that bank will
> cause faults.
>
> Because the current code frees the GPIO, the ads7846 driver probe will
> fault when it requests its IRQ line. Because the IRQ is a GPIO line,
> the request IRQ will trickle down into the OMAP GPIO layer:
> gpio_irq_type() --> _set_gpio_triggering() which can fault if the
> bank has been runtime suspended.
>
> This
Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO
On 07/12/12 02:18, Kevin Hilman wrote: > commit 97ee9f01d6 (ARM: OMAP: fix the ads7846 init code) mistakenly > frees the pen-down GPIO even though it will be used by the ads7846 > driver. But the driver requests the GPIO in ads7846_setup_pendown() method... > > Freeing a GPIO means that the GPIO bank containing that GPIO can be > runtime suspended if its the last/only GPIO being used in that bank. > If the GPIO bank is runtime suspended, any accesses to that bank will > cause faults. Unless, it is requested again, or am I missing something? > > Because the current code frees the GPIO, the ads7846 driver probe will > fault when it requests its IRQ line. But it requests that GPIO... in ads7846_setup_pendown() prior to requesting the IRQ... > Because the IRQ is a GPIO line, > the request IRQ will trickle down into the OMAP GPIO layer: > gpio_irq_type() --> _set_gpio_triggering() which can fault if the > bank has been runtime suspended. > > This is exctly what happens on Overo platforms (3530 Water, 3730 Overo > FireSTORM) since this is the only GPIO used in the bank. > > To fix, don't free the GPIO at all since it is always in use. > > Cc: Igor Grinberg > Signed-off-by: Kevin Hilman > --- > Tony, this applies on top of your current fixes-non-critical branch and > should probably go in to v3.5-rc since the patch which introduced the > problem did as well. > > arch/arm/mach-omap2/common-board-devices.c |3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/arm/mach-omap2/common-board-devices.c > b/arch/arm/mach-omap2/common-board-devices.c > index c187586..1ae6fd6 100644 > --- a/arch/arm/mach-omap2/common-board-devices.c > +++ b/arch/arm/mach-omap2/common-board-devices.c > @@ -84,9 +84,6 @@ void __init omap_ads7846_init(int bus_num, int > gpio_pendown, int gpio_debounce, > ads7846_config.gpio_pendown = gpio_pendown; > } > > - if (!board_pdata || (board_pdata && !board_pdata->get_pendown_state)) > - gpio_free(gpio_pendown); > - > spi_register_board_info(&ads7846_spi_board_info, 1); > } > #else -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO
Hi Kevin, I've just noticed that the patch has been modified by Arnd in a way that of course will trigger GPIO use without being requested. I'm sorry, I was not available by that time Arnd changed the patch. So that is not my original patch that is triggering the issue, but it does not meter already... And currently, I think that the proper solution would be to remove the gpio_free() call as your patch does, but... Tony, please pay attention to which branch it gets applied It should only apply to the branches that have the patch modified by Arnd and not to those with unmodified patch (e.g. fixes-non-critical should not receive the patch). Kevin, thanks for the patch. On 07/23/12 15:53, Igor Grinberg wrote: > On 07/12/12 02:18, Kevin Hilman wrote: >> commit 97ee9f01d6 (ARM: OMAP: fix the ads7846 init code) mistakenly >> frees the pen-down GPIO even though it will be used by the ads7846 >> driver. > > But the driver requests the GPIO in ads7846_setup_pendown() method... > >> >> Freeing a GPIO means that the GPIO bank containing that GPIO can be >> runtime suspended if its the last/only GPIO being used in that bank. >> If the GPIO bank is runtime suspended, any accesses to that bank will >> cause faults. > > Unless, it is requested again, or am I missing something? > >> >> Because the current code frees the GPIO, the ads7846 driver probe will >> fault when it requests its IRQ line. > > But it requests that GPIO... in ads7846_setup_pendown() > prior to requesting the IRQ... > >> Because the IRQ is a GPIO line, >> the request IRQ will trickle down into the OMAP GPIO layer: >> gpio_irq_type() --> _set_gpio_triggering() which can fault if the >> bank has been runtime suspended. >> >> This is exctly what happens on Overo platforms (3530 Water, 3730 Overo >> FireSTORM) since this is the only GPIO used in the bank. >> >> To fix, don't free the GPIO at all since it is always in use. >> >> Cc: Igor Grinberg >> Signed-off-by: Kevin Hilman Acked-by: Igor Grinberg >> --- >> Tony, this applies on top of your current fixes-non-critical branch and >> should probably go in to v3.5-rc since the patch which introduced the >> problem did as well. No, this patch is not good for fixes-non-critical, as fixes-non-critical has unmodified version and will result in double requesting. It should be applied to master or derivatives that have the modified patch version. >> >> arch/arm/mach-omap2/common-board-devices.c |3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/common-board-devices.c >> b/arch/arm/mach-omap2/common-board-devices.c >> index c187586..1ae6fd6 100644 >> --- a/arch/arm/mach-omap2/common-board-devices.c >> +++ b/arch/arm/mach-omap2/common-board-devices.c >> @@ -84,9 +84,6 @@ void __init omap_ads7846_init(int bus_num, int >> gpio_pendown, int gpio_debounce, >> ads7846_config.gpio_pendown = gpio_pendown; >> } >> >> -if (!board_pdata || (board_pdata && !board_pdata->get_pendown_state)) >> -gpio_free(gpio_pendown); >> - >> spi_register_board_info(&ads7846_spi_board_info, 1); >> } >> #else > -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO
On 07/26/12 22:30, Kevin Hilman wrote:
> + Zumeng Chen
>
> Igor Grinberg writes:
>
>> Hi Kevin,
>>
>> I've just noticed that the patch has been modified by Arnd in a way
>> that of course will trigger GPIO use without being requested.
>> I'm sorry, I was not available by that time Arnd changed the patch.
>
> Your right, your original patch isn't the problem. I found the root
> cause.
>
> The real problem is actually introduced by the merge of your patch from
> the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
> 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
> ads7846) from the arm-soc/boards branch.
>
> However, looking closer at the one from Zumeng, that one is clearly not
> right. It unconditionally adds a *board-specific* ->get_pendown_state
> function to the pdata that is common to *all* boards. That's just wrong
> and has the side-effect of making ->get_pendown_state() wrong on every
> board except the OMAP3EVM. Oops.
Argh... that should not be applied in first place...
I double sorry, I was not available when that conflict was resolved...
The right resolution would be just to revert the 16aced80f6
(ARM: OMAP3530evm: set pendown_state and debounce time for ads7846),
but who cares now...
>
> So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
> GPIO working on non OMAP3EVM boards, we also need something like this as
> well.
>
> Igor, Zumeng, could you try this out on your boards anc confirm if it's
> working? I currently don't have a board setup with a touchscreen in my
> board farm.
Since you have already dig into this, which branch would be good for testing?
>
> Kevin
>
>>From 85516c6a3354967caf4cff434d28c3001cd411eb Mon Sep 17 00:00:00 2001
> From: Kevin Hilman
> Date: Thu, 26 Jul 2012 12:15:38 -0700
> Subject: [PATCH 2/2] ARM: OMAP2+: ads7846: fix ->get_pendown_state() to work
> on all boards
>
> commit 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce
> time for ads7846) introduced a common ->get_pendown_state() function
> into the generic code, but that function was board-specific for the
> OMAP3EVM.
>
> Fix this up to work for all boards that pass in a pendown GPIO.
>
> Cc: Zumeng Chen
> Cc: Igor Grinberg
> Signed-off-by: Kevin Hilman
> ---
> arch/arm/mach-omap2/board-omap3evm.c |1 +
> arch/arm/mach-omap2/common-board-devices.c |4 +++-
> arch/arm/mach-omap2/common-board-devices.h |1 -
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index ef230a0..0d362e9 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -58,6 +58,7 @@
> #include "hsmmc.h"
> #include "common-board-devices.h"
>
> +#define OMAP3_EVM_TS_GPIO175
> #define OMAP3_EVM_EHCI_VBUS 22
> #define OMAP3_EVM_EHCI_SELECT61
>
> diff --git a/arch/arm/mach-omap2/common-board-devices.c
> b/arch/arm/mach-omap2/common-board-devices.c
> index 0fee95f..06f176f 100644
> --- a/arch/arm/mach-omap2/common-board-devices.c
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -40,9 +40,10 @@ static struct omap2_mcspi_device_config
> ads7846_mcspi_config = {
> * of pdata->get_pendown_state, but we have done this. So set
> * get_pendown_state to avoid twice gpio requesting.
> */
> +static int omap3_gpio_pendown;
> static int omap3_get_pendown_state(void)
> {
> - return !gpio_get_value(OMAP3_EVM_TS_GPIO);
> + return !gpio_get_value(omap3_gpio_pendown);
> }
>
> static struct ads7846_platform_data ads7846_config = {
> @@ -74,6 +75,7 @@ void __init omap_ads7846_init(int bus_num, int
> gpio_pendown, int gpio_debounce,
> struct spi_board_info *spi_bi = &ads7846_spi_board_info;
> int err;
>
> + omap3_gpio_pendown = gpio_pendown;
> err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
> if (err) {
> pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
> diff --git a/arch/arm/mach-omap2/common-board-devices.h
> b/arch/arm/mach-omap2/common-board-devices.h
> index 4c4ef6a..a0b4a428 100644
> --- a/arch/arm/mach-omap2/common-board-devices.h
> +++ b/arch/arm/mach-omap2/common-board-devices.h
> @@ -4,7 +4,6 @@
> #include "twl-common.h"
>
> #define NAND_BLOCK_SIZE SZ_128K
> -#define OMAP3_EVM_TS_GPIO175
>
> struct mtd_partition;
> struct ads7846_platform_data;
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO
On 07/26/12 22:30, Kevin Hilman wrote:
> + Zumeng Chen
>
> Igor Grinberg writes:
>
>> Hi Kevin,
>>
>> I've just noticed that the patch has been modified by Arnd in a way
>> that of course will trigger GPIO use without being requested.
>> I'm sorry, I was not available by that time Arnd changed the patch.
>
> Your right, your original patch isn't the problem. I found the root
> cause.
>
> The real problem is actually introduced by the merge of your patch from
> the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
> 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
> ads7846) from the arm-soc/boards branch.
>
> However, looking closer at the one from Zumeng, that one is clearly not
> right. It unconditionally adds a *board-specific* ->get_pendown_state
> function to the pdata that is common to *all* boards. That's just wrong
> and has the side-effect of making ->get_pendown_state() wrong on every
> board except the OMAP3EVM. Oops.
>
> So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
> GPIO working on non OMAP3EVM boards, we also need something like this as
> well.
>
> Igor, Zumeng, could you try this out on your boards anc confirm if it's
> working? I currently don't have a board setup with a touchscreen in my
> board farm.
>
> Kevin
>
>>From 85516c6a3354967caf4cff434d28c3001cd411eb Mon Sep 17 00:00:00 2001
> From: Kevin Hilman
> Date: Thu, 26 Jul 2012 12:15:38 -0700
> Subject: [PATCH 2/2] ARM: OMAP2+: ads7846: fix ->get_pendown_state() to work
> on all boards
>
> commit 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce
> time for ads7846) introduced a common ->get_pendown_state() function
> into the generic code, but that function was board-specific for the
> OMAP3EVM.
>
> Fix this up to work for all boards that pass in a pendown GPIO.
>
> Cc: Zumeng Chen
> Cc: Igor Grinberg
> Signed-off-by: Kevin Hilman
Tested-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/board-omap3evm.c |1 +
> arch/arm/mach-omap2/common-board-devices.c |4 +++-
> arch/arm/mach-omap2/common-board-devices.h |1 -
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index ef230a0..0d362e9 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -58,6 +58,7 @@
> #include "hsmmc.h"
> #include "common-board-devices.h"
>
> +#define OMAP3_EVM_TS_GPIO175
> #define OMAP3_EVM_EHCI_VBUS 22
> #define OMAP3_EVM_EHCI_SELECT61
>
> diff --git a/arch/arm/mach-omap2/common-board-devices.c
> b/arch/arm/mach-omap2/common-board-devices.c
> index 0fee95f..06f176f 100644
> --- a/arch/arm/mach-omap2/common-board-devices.c
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -40,9 +40,10 @@ static struct omap2_mcspi_device_config
> ads7846_mcspi_config = {
> * of pdata->get_pendown_state, but we have done this. So set
> * get_pendown_state to avoid twice gpio requesting.
> */
> +static int omap3_gpio_pendown;
> static int omap3_get_pendown_state(void)
> {
> - return !gpio_get_value(OMAP3_EVM_TS_GPIO);
> + return !gpio_get_value(omap3_gpio_pendown);
> }
>
> static struct ads7846_platform_data ads7846_config = {
> @@ -74,6 +75,7 @@ void __init omap_ads7846_init(int bus_num, int
> gpio_pendown, int gpio_debounce,
> struct spi_board_info *spi_bi = &ads7846_spi_board_info;
> int err;
>
> + omap3_gpio_pendown = gpio_pendown;
> err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
> if (err) {
> pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
> diff --git a/arch/arm/mach-omap2/common-board-devices.h
> b/arch/arm/mach-omap2/common-board-devices.h
> index 4c4ef6a..a0b4a428 100644
> --- a/arch/arm/mach-omap2/common-board-devices.h
> +++ b/arch/arm/mach-omap2/common-board-devices.h
> @@ -4,7 +4,6 @@
> #include "twl-common.h"
>
> #define NAND_BLOCK_SIZE SZ_128K
> -#define OMAP3_EVM_TS_GPIO175
>
> struct mtd_partition;
> struct ads7846_platform_data;
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO
On 07/27/12 20:46, Kevin Hilman wrote: > Igor Grinberg writes: > >> On 07/26/12 22:30, Kevin Hilman wrote: >>> + Zumeng Chen >>> >>> Igor Grinberg writes: >>> >>>> Hi Kevin, >>>> >>>> I've just noticed that the patch has been modified by Arnd in a way >>>> that of course will trigger GPIO use without being requested. >>>> I'm sorry, I was not available by that time Arnd changed the patch. >>> >>> Your right, your original patch isn't the problem. I found the root >>> cause. >>> >>> The real problem is actually introduced by the merge of your patch from >>> the arm-soc/cleanup branch, and this one from Zumeng Chen: commit >>> 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for >>> ads7846) from the arm-soc/boards branch. >>> >>> However, looking closer at the one from Zumeng, that one is clearly not >>> right. It unconditionally adds a *board-specific* ->get_pendown_state >>> function to the pdata that is common to *all* boards. That's just wrong >>> and has the side-effect of making ->get_pendown_state() wrong on every >>> board except the OMAP3EVM. Oops. >> >> Argh... that should not be applied in first place... > > Agreed, but it's already in mainline. > >> I double sorry, I was not available when that conflict was resolved... >> The right resolution would be just to revert the 16aced80f6 >> (ARM: OMAP3530evm: set pendown_state and debounce time for ads7846), >> but who cares now... > > >> >>> >>> So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen >>> GPIO working on non OMAP3EVM boards, we also need something like this as >>> well. >>> >>> Igor, Zumeng, could you try this out on your boards anc confirm if it's >>> working? I currently don't have a board setup with a touchscreen in my >>> board farm. >> >> Since you have already dig into this, which branch would be good for testing? > > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.6/fixes/ads7846 > > I just pushed this out, so it might take a bit to propagate to all the > mirrors. Thanks, Kevin, I've just sent the tested-by. I would also like to see only one patch instead of current two patches, can you please, amend them into one, write a correct message and resend? -- 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 v1 1/1] ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503
On 07/31/12 02:50, Juha Kuikka wrote: > Similarly to am3703, it seems that omap3503 has an IVA control > registers even though the subsystem is non-functional. > > This patch sets the OMAP3_HAS_IVA_REGS feature to force > initialization of there registers. > > Based in Mark A. Greer's patch > "ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature". > > Signed-off-by: Juha Kuikka > --- > arch/arm/mach-omap2/id.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > index 4072fbd..45d3eb4 100644 > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void) > if (cpu_is_omap3630()) > omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS; If you add the flag below, then you probably want to remove it from here, right? > if (cpu_is_omap3430() || cpu_is_omap3630()) > - omap_features |= OMAP3_HAS_IO_WAKEUP; > + omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS; > if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 || > omap_rev() == OMAP3430_REV_ES3_1_2) > omap_features |= OMAP3_HAS_IO_CHAIN_CTRL; -- 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] OMAPDSS: OMAPFB: fix framebuffer console colors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/12 09:00, Tomi Valkeinen wrote: > On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote: >> omapfb does not currently set pseudo palette correctly for color depths >> above 16bpp, making red text invisible, command like >> echo -e '\e[0;31mRED' > /dev/tty1 >> will display nothing on framebuffer console in 24bpp mode. >> This is because temporary variable is declared incorrectly, fix it. > > Thanks, applied to OMAP DSS tree. Is it also applicable to stable? If yes, Tomi, can you please add the Cc tag? Thanks - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQH5lGAAoJEBDE8YO64Efak/YP/3APyqQ3d4TLB8sG7oHSF/Vn zmwMl8kH2B70WIPWU1iIExodfrDd3Gms8UeGqjhj04kLHvqYUs3/lepTA6gkEnH0 U4vyO6WTMYtWBHUGXJhZk5GpOByn4aLdk4UGV22NNMmUI/xWqcVGSnntLjmRcUyu Y1JRQqhlrXrYXH5A866J7yrwSwhhZ/sZXs4k1N5keCNaT8ieqn0HXvu02ma7bjF7 SvhWDPNOOWUuEOGsope8F2A8Mot4ToManqRHDTUSnq/cpWziGiy6/7I7ngVIMUgD /nmiLISgU72wkoNDl0AxGQDVQ8HFUspzGe2e12VliG+ErmFkGfKr9XdI6fx7gKh2 ks7qL+uMBau9MpWYcRPhPvYrVn7tg6V9seN2/bG5gp2IgMFbu1wmibVMNyCGhQeX 1OhshGEKeR58s+R8KZ7+UzbjspDuSnlnFH2wVbbb3wr30Swc6VZA/rWlwNg3Bgz5 /h63a5SOwTF9nmV+3/O/ky4gyMORbbJyOBK/xWVmQkZ4lNNW02RnMaa6KP8fKlbb Cc7x1P07jcMH83LKGyyhsvZrK/4JCloYEDTvuYHprf9Wb+WsXNCLsRiYMngUIwPc eLrBVOlELQvS237eGAwMIfo4Lm3tI3WMyr8cjGy2aRqn8voDJW+qEN2NUNwkNDqS kGYrOE0t5VRNx5egrv+J =kydA -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe 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] OMAPDSS: OMAPFB: fix framebuffer console colors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/12 14:22, Tomi Valkeinen wrote: > On Mon, 2012-08-06 at 13:15 +0300, Igor Grinberg wrote: >> On 08/06/12 09:00, Tomi Valkeinen wrote: >>> On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote: >>>> omapfb does not currently set pseudo palette correctly for color depths >>>> above 16bpp, making red text invisible, command like >>>> echo -e '\e[0;31mRED' > /dev/tty1 >>>> will display nothing on framebuffer console in 24bpp mode. >>>> This is because temporary variable is declared incorrectly, fix it. >>> >>> Thanks, applied to OMAP DSS tree. >> >> Is it also applicable to stable? >> If yes, Tomi, can you please add the Cc tag? > > Yes, the bug has been there from the beginning. > > I can add the Cc tag. But I wonder is it enough just to have the tag, or > should I also send the patch forward? And does it only get applied to > the latest stable tree, not the earlier ones? Well, the Documentation/stable_kernel_rules.txt says: - To have the patch automatically included in the stable tree, add the tag Cc: sta...@vger.kernel.org in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. So I guess, you don't need to resend it. Also, IIUC, if you can identify all the stable kernels it applies to, you can specify them like: Cc: # 3.x, 2.6.x This can save some work for those responsible for adding the patch to stable. Now, if you say, it is applicable to all kernels since the omapfb support was merged, I think, the above example it the right choice. Anyway, Greg, please correct me if I've got anything wrong. Thanks - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQH7gRAAoJEBDE8YO64EfakCAP/izNPA/HcFhxE3cRJJhlh5xw Caf4h6gXjdTNekSfLEppyo+uf6F2ef8ojZFoim1x59phjC9N9TQWyqTgV6qTGWul o8YtCo3CMXPTVnxgoYtIFNDIngiuZFVATEWdoHlxlpWwBXWcr6K101Rg+x0hlvzl CAqquuwjO+GFmPn+6hLns3sFJcnD02e2Rb0tX29Yg/SdFCMPDIRA3NUANVqILcxN do6mWpZ3tKOmPzobUDr1tswJxK94oc0pIjKMjxy71qAxpLMtY2bVNKavKuGsgaRr Nl7Bml5e1vCvAJNtYTpiMKvjomTvS1gktBoAa43u81THDrvwzJNO/mUq88CuMOg0 D0k8ohKrv0/WyKr+LZe9W4l4I9lIvbutvF5oxcU+1gC01pMlr9qghO8J3Oz5/UTi /Swd7Q5I6X29TtudIuAsZ8g5didNBTLYgih+DODviTRzaca7msF+VfNkcg2IeOuA MvkMwiZSZX15ggriH07dEr+Z2XF7mMYVMgn492RokMzeXx31VXeHYv9pNGXcF+xn xV55Z03RT2jcnIPJVSfnzXAXIhTdkM2MVBaS/iNKckPW1Q1quiY/7IeWJaX59LBl bWUIFC02HJ+n8S2Tyqbr+7+0ue6v3xVocw/fcwx0PCLx0HltxhrAJJzTB+o4SDya DpSx1+W2seaVbd7AgkmN =qbs/ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe 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] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
1) The above commit introduced a common ->get_pendown_state() function
into the generic code, but that function was board-specific for the
OMAP3EVM and thus broke most other boards using this code.
2) The above commit was mis-merged introducing another bug which
prevents the ads7846 driver probe function to succeed.
The omap_ads7846_init() function frees the pendown GPIO in case there is
no ->get_pendown_state() function set by the caller (board specific
code), so it can be requested later by the ads7846 driver.
The above commit add a common ->get_pendown_state() function without
removing the gpio_free() call and thus once the ads7846 driver tries
to use the pendown GPIO, it crashes as the pendown GPIO has not been
requested.
3) The above commit introduces NO new functionality as
get_pendown_state() function is already implemented in a suitable way by
the ads7846 driver and the debounce time handling has already been
fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code).
This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8.
Conflicts:
arch/arm/mach-omap2/common-board-devices.c
Solved by taking the working version prior to the above commit.
Cc: Zumeng Chen
Cc: Arnd Bergmann
Signed-off-by: Igor Grinberg
---
Kevin, sorry for the late reply.
How about the above commit message and the below patch?
The patch applies cleanly to Tony's master branch (6 Aug 2012)
or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846
after resetting two top most commits.
This patch has been tested on both above branches on cm-t3730.
Any other board tested will be greately appreciated.
Also, if after all said in the commit message, you still don't
want to revert the original patch, feel free to post your thoughts.
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/common-board-devices.c | 11 ---
arch/arm/mach-omap2/common-board-devices.h |1 -
3 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..0d362e9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -58,6 +58,7 @@
#include "hsmmc.h"
#include "common-board-devices.h"
+#define OMAP3_EVM_TS_GPIO 175
#define OMAP3_EVM_EHCI_VBUS22
#define OMAP3_EVM_EHCI_SELECT 61
diff --git a/arch/arm/mach-omap2/common-board-devices.c
b/arch/arm/mach-omap2/common-board-devices.c
index 1473474..c187586 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config ads7846_mcspi_config
= {
.turbo_mode = 0,
};
-/*
- * ADS7846 driver maybe request a gpio according to the value
- * of pdata->get_pendown_state, but we have done this. So set
- * get_pendown_state to avoid twice gpio requesting.
- */
-static int omap3_get_pendown_state(void)
-{
- return !gpio_get_value(OMAP3_EVM_TS_GPIO);
-}
-
static struct ads7846_platform_data ads7846_config = {
.x_max = 0x0fff,
.y_max = 0x0fff,
@@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = {
.debounce_rep = 1,
.gpio_pendown = -EINVAL,
.keep_vref_on = 1,
- .get_pendown_state = &omap3_get_pendown_state,
};
static struct spi_board_info ads7846_spi_board_info __initdata = {
diff --git a/arch/arm/mach-omap2/common-board-devices.h
b/arch/arm/mach-omap2/common-board-devices.h
index 4c4ef6a..a0b4a428 100644
--- a/arch/arm/mach-omap2/common-board-devices.h
+++ b/arch/arm/mach-omap2/common-board-devices.h
@@ -4,7 +4,6 @@
#include "twl-common.h"
#define NAND_BLOCK_SIZESZ_128K
-#define OMAP3_EVM_TS_GPIO 175
struct mtd_partition;
struct ads7846_platform_data;
--
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] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
On 08/06/12 23:52, Kevin Hilman wrote: > Igor Grinberg writes: > >> 1) The above commit introduced a common ->get_pendown_state() function >> into the generic code, but that function was board-specific for the >> OMAP3EVM and thus broke most other boards using this code. >> >> 2) The above commit was mis-merged introducing another bug which >> prevents the ads7846 driver probe function to succeed. >> The omap_ads7846_init() function frees the pendown GPIO in case there is >> no ->get_pendown_state() function set by the caller (board specific >> code), so it can be requested later by the ads7846 driver. >> The above commit add a common ->get_pendown_state() function without >> removing the gpio_free() call and thus once the ads7846 driver tries >> to use the pendown GPIO, it crashes as the pendown GPIO has not been >> requested. >> >> 3) The above commit introduces NO new functionality as >> get_pendown_state() function is already implemented in a suitable way by >> the ads7846 driver and the debounce time handling has already been >> fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code). >> >> This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8. >> >> Conflicts: >> arch/arm/mach-omap2/common-board-devices.c >> >> Solved by taking the working version prior to the above commit. >> >> Cc: Zumeng Chen >> Cc: Arnd Bergmann >> Signed-off-by: Igor Grinberg >> --- >> Kevin, sorry for the late reply. >> How about the above commit message and the below patch? >> >> The patch applies cleanly to Tony's master branch (6 Aug 2012) >> or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846 >> after resetting two top most commits. > > Now that v3.6-rc1 is out, it should probalby be applied on top of -rc1. > I've taken care of that and tested as well. > >> This patch has been tested on both above branches on cm-t3730. >> Any other board tested will be greately appreciated. >> >> Also, if after all said in the commit message, you still don't >> want to revert the original patch, feel free to post your thoughts. > > After all the digging I did, I agree that the revert is the best > solution. > > While it's a slightly different problem/bug, I think the gpio_free() in > common-board-devices.c should still be unconditonal since the > gpio_request() is now unconditional. That can be a separate patch though. Well, the logic behind the conditional gpio_free() is: if a board specific code provides a board specific get_pendown_state() function (which is different from the one in the ads7846 driver), that board will not need to re-request the pendown GPIO (duplicate code). If we free the pendown GPIO unconditionally, then the board specific code will have to re-request it. So, I think, no - it should be conditional. > > Acked-by: Kevin Hilman > Tested-by: Kevin Hilman > > Tested on 3430/n900, 3530/Overo, 3730/Overo STORM, 3730/BB-xM. 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] Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"
On 08/07/12 04:42, Zumeng Chen wrote:
> 于 2012年08月07日 04:22, Igor Grinberg 写道:
>> 1) The above commit introduced a common ->get_pendown_state() function
>> into the generic code, but that function was board-specific for the
>> OMAP3EVM and thus broke most other boards using this code.
>>
>> 2) The above commit was mis-merged introducing another bug which
>> prevents the ads7846 driver probe function to succeed.
>> The omap_ads7846_init() function frees the pendown GPIO in case there is
>> no ->get_pendown_state() function set by the caller (board specific
>> code), so it can be requested later by the ads7846 driver.
>> The above commit add a common ->get_pendown_state() function without
>> removing the gpio_free() call and thus once the ads7846 driver tries
>> to use the pendown GPIO, it crashes as the pendown GPIO has not been
>> requested.
>>
>> 3) The above commit introduces NO new functionality as
>> get_pendown_state() function is already implemented in a suitable way by
>> the ads7846 driver and the debounce time handling has already been
>> fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code).
> Igor,
>
> I suspect these two patches(this and 97ee9f01) works well, and there
> is something new introduced in ads7846.c, I'll try to look at that new
> stuff in this weekend.
>
> Please refer to in-line comments:
>
> Regards,
> Zumeng
>>
>> This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8.
>>
>> Conflicts:
>> arch/arm/mach-omap2/common-board-devices.c
>>
>> Solved by taking the working version prior to the above commit.
>>
>> Cc: Zumeng Chen
>> Cc: Arnd Bergmann
>> Signed-off-by: Igor Grinberg
>> ---
>> Kevin, sorry for the late reply.
>> How about the above commit message and the below patch?
>>
>> The patch applies cleanly to Tony's master branch (6 Aug 2012)
>> or Kevin's kevin-omap-pm/for_3.6/fixes/ads7846
>> after resetting two top most commits.
>>
>> This patch has been tested on both above branches on cm-t3730.
>> Any other board tested will be greately appreciated.
>>
>> Also, if after all said in the commit message, you still don't
>> want to revert the original patch, feel free to post your thoughts.
>>
>> arch/arm/mach-omap2/board-omap3evm.c |1 +
>> arch/arm/mach-omap2/common-board-devices.c | 11 ---
>> arch/arm/mach-omap2/common-board-devices.h |1 -
>> 3 files changed, 1 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
>> b/arch/arm/mach-omap2/board-omap3evm.c
>> index ef230a0..0d362e9 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -58,6 +58,7 @@
>> #include "hsmmc.h"
>> #include "common-board-devices.h"
>>
>> +#define OMAP3_EVM_TS_GPIO 175
>> #define OMAP3_EVM_EHCI_VBUS 22
>> #define OMAP3_EVM_EHCI_SELECT 61
>>
>> diff --git a/arch/arm/mach-omap2/common-board-devices.c
>> b/arch/arm/mach-omap2/common-board-devices.c
>> index 1473474..c187586 100644
>> --- a/arch/arm/mach-omap2/common-board-devices.c
>> +++ b/arch/arm/mach-omap2/common-board-devices.c
>> @@ -35,16 +35,6 @@ static struct omap2_mcspi_device_config
>> ads7846_mcspi_config = {
>> .turbo_mode = 0,
>> };
>>
>> -/*
>> - * ADS7846 driver maybe request a gpio according to the value
>> - * of pdata->get_pendown_state, but we have done this. So set
>> - * get_pendown_state to avoid twice gpio requesting.
>> - */
>> -static int omap3_get_pendown_state(void)
>> -{
>> -return !gpio_get_value(OMAP3_EVM_TS_GPIO);
>> -}
>> -
>> static struct ads7846_platform_data ads7846_config = {
>> .x_max = 0x0fff,
>> .y_max = 0x0fff,
>> @@ -55,7 +45,6 @@ static struct ads7846_platform_data ads7846_config = {
>> .debounce_rep = 1,
>> .gpio_pendown = -EINVAL,
>> .keep_vref_on = 1,
>> -.get_pendown_state = &omap3_get_pendown_state,
> You remove this, then please look at the following codes:
>
> drivers/input/touchscreen/ads7846.c
>
> 969 if (pdata->get_pendown_state) {
> 970 ts->get_pendown_state = pdata->get_pendown_state;
> 971 } else if (gpio_is_valid(pdata->gpio_pendown)) {
> 972
> 973 err = gpio_request_one(pdata->gpio_pendown, GPIOF_IN,
> ^^^, the driver will want to request again, then it should
> be erro
Re: [PATCH 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
Hi Peter,
Thank you very much for the patch series.
I probably will have some time to look into it more deeply on the next week.
Currently, only a small comment, please see below.
On 08/08/12 12:54, Peter Ujfalusi wrote:
> These boards have similar audio setup and they can all use the same driver
> for audio support if it is enabled in the kernel config.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/mach-omap2/board-cm-t35.c |1 +
> arch/arm/mach-omap2/board-devkit8000.c |1 +
> arch/arm/mach-omap2/board-igep0020.c|1 +
> arch/arm/mach-omap2/board-omap3beagle.c |1 +
> arch/arm/mach-omap2/board-omap3evm.c|1 +
> arch/arm/mach-omap2/board-overo.c |1 +
> 6 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
> b/arch/arm/mach-omap2/board-cm-t35.c
> index 97d7190..b73fa5c 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -731,6 +731,7 @@ static void __init cm_t3x_common_init(void)
> cm_t35_init_ethernet();
> cm_t35_init_led();
> cm_t35_init_display();
> + omap_twl4030_audio_init("overo", 2600);
Can the card_name here be "cm-t3x" ?
[...]
--
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 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
On 08/08/12 15:29, Peter Ujfalusi wrote:
> Hi Igor,
>
> On 08/08/2012 03:24 PM, Igor Grinberg wrote:
>>> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
>>> b/arch/arm/mach-omap2/board-cm-t35.c
>>> index 97d7190..b73fa5c 100644
>>> --- a/arch/arm/mach-omap2/board-cm-t35.c
>>> +++ b/arch/arm/mach-omap2/board-cm-t35.c
>>> @@ -731,6 +731,7 @@ static void __init cm_t3x_common_init(void)
>>> cm_t35_init_ethernet();
>>> cm_t35_init_led();
>>> cm_t35_init_display();
>>> + omap_twl4030_audio_init("overo", 2600);
>>
>> Can the card_name here be "cm-t3x" ?
>
> I have used the "overo" as card name here since what I gathered is that cm-t35
> used the sound/soc/omap/overo.c machine driver for audio support.
> If the card name is changing your existing user space might get confused by
> the card name change.
> But sure, I can change the card name to "cm-t3x" if it is better for you.
Well, yes I know we will need to adjust the user space.
I wanted to change that for a long time and did not get to it...
Now, with your patches, it seems like the best time for doing this.
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 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
On 08/09/12 13:21, Peter Ujfalusi wrote: > On 08/08/2012 04:06 PM, Igor Grinberg wrote: >> Well, yes I know we will need to adjust the user space. >> I wanted to change that for a long time and did not get to it... >> Now, with your patches, it seems like the best time for doing this. > > Done for the v2. You will have card named "cm-t3x". 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 2/2] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
Hi Timo,
On 08/09/12 15:41, Timo Kokkonen wrote:
> The IR diode on the RX51 is connected to the GPT9. This data is needed
> for the IR driver to function.
>
> Signed-off-by: Timo Kokkonen
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 30
> ++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index df2534d..4a5a71b 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -46,6 +47,10 @@
> #include <../drivers/staging/iio/light/tsl2563.h>
> #include
>
> +#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
> +#include "../../../drivers/media/rc/ir-rx51.h"
> +#endif
That is not really nice...
You should place the struct lirc_rx51_platform_data and
other stuff used outside of the driver in: include/media/
so you will not have to add that long and ugly relative path.
> +
> #include "mux.h"
> #include "hsmmc.h"
> #include "common-board-devices.h"
> @@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
> gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
> }
>
> +#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
> +static struct lirc_rx51_platform_data rx51_lirc_data = {
> + .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
> + .pwm_timer = 9, /* Use GPT 9 for CIR */
> +};
> +
> +static struct platform_device rx51_lirc_device = {
> + .name = "lirc_rx51",
> + .id = -1,
> + .dev= {
> + .platform_data = &rx51_lirc_data,
> + },
> +};
> +
> +static void __init rx51_init_lirc(void)
> +{
> + platform_device_register(&rx51_lirc_device);
> +}
> +#else
> +static void __init rx51_init_lirc(void)
> +{
> +}
> +#endif
> +
> void __init rx51_peripherals_init(void)
> {
> rx51_i2c_init();
> @@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
> rx51_init_wl1251();
> rx51_init_tsc2005();
> rx51_init_si4713();
> + rx51_init_lirc();
> spi_register_board_info(rx51_peripherals_spi_board_info,
> ARRAY_SIZE(rx51_peripherals_spi_board_info));
>
--
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 1/2] media: rc: Introduce RX51 IR transmitter driver
On 08/09/12 15:41, Timo Kokkonen wrote:
> This is the driver for the IR transmitter diode found on the Nokia
> N900 (also known as RX51) device. The driver is mostly the same as
> found in the original 2.6.28 based kernel that comes with the device.
>
> The following modifications have been made compared to the original
> driver version:
>
> - Adopt to the changes that has happen in the kernel during the past
> five years, such as the change in the include paths
>
> - The OMAP DM-timers require much more care nowadays. The timers need
> to be enabled and disabled or otherwise many actions fail. Timers
> must not be freed without first stopping them or otherwise the timer
> cannot be requested again.
>
> The code has been tested with sending IR codes with N900 device
> running Debian userland. The device receiving the codes was Anysee
> DVB-C USB receiver.
>
> Signed-off-by: Timo Kokkonen
> ---
> drivers/media/rc/Kconfig | 10 +
> drivers/media/rc/Makefile |1 +
> drivers/media/rc/ir-rx51.c | 496
>
> drivers/media/rc/ir-rx51.h | 10 +
I think the file ir-rx51.h should be placed in include/media instead.
[...]
> 4 files changed, 517 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/rc/ir-rx51.c
> create mode 100644 drivers/media/rc/ir-rx51.h
[...]
> diff --git a/drivers/media/rc/ir-rx51.h b/drivers/media/rc/ir-rx51.h
> new file mode 100644
> index 000..104aa89
> --- /dev/null
> +++ b/drivers/media/rc/ir-rx51.h
> @@ -0,0 +1,10 @@
> +#ifndef _LIRC_RX51_H
> +#define _LIRC_RX51_H
> +
> +struct lirc_rx51_platform_data {
> + int pwm_timer;
> +
> + int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
> +};
> +
> +#endif
--
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 v2 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
On 08/14/12 12:07, Peter Ujfalusi wrote: > These boards have similar audio setup and they can all use the same driver > for audio support if it is enabled in the kernel config. > > Signed-off-by: Peter Ujfalusi > Cc: Igor Grinberg > Acked-by: Tony Lindgren Acked-by: Igor Grinberg Thanks Peter! -- 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 v6 01/10] ARM: OMAP2+: nand: unify init functions
Hi Afzal, Thanks for the patches! On 08/21/12 13:45, Afzal Mohammed wrote: > Helper function for updating nand platform data has been > added the capability to take timing structure arguement. > Usage of omap_nand_flash_init() has been replaced by modifed > one, omap_nand_flash_init was doing things similar to > board_nand_init except that NAND CS# were being acquired > based on bootloader setting. As CS# is hardwired for a given > board, acquiring gpmc CS# has been removed, and updated with > the value on board. > > NAND CS# used in beagle board & omap3evm was found to be CS0. > Thomas Weber reported > that value of devkit8000 to be CS0. Overo board was found > to be using CS0 based on u-boot, while google grep says > omap3touchbook too has CS0. > > Signed-off-by: Afzal Mohammed > Reviewed-by: Jon Hunter Acked-by: Igor Grinberg -- 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
[PATCH] ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMER
Currently, omap2_sync32k_clocksource_init() function initializes the 32K
timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER
setting.
Fix this by providing a default implementation for
!CONFIG_OMAP_32K_TIMER case.
Signed-off-by: Igor Grinberg
Reviewed-by: Paul Walmsley
---
arch/arm/mach-omap2/timer.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..2cdbcc7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -263,6 +263,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
+#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
static int __init omap2_sync32k_clocksource_init(void)
{
@@ -302,6 +303,12 @@ static int __init omap2_sync32k_clocksource_init(void)
return ret;
}
+#else
+static inline int omap2_sync32k_clocksource_init(void)
+{
+ return -ENODEV;
+}
+#endif
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
--
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
[PATCH 0/9] ARM: OMAP: cleanup plat/board.h file
This patch series cleans up the plat/board.h and related files. Remove confusingly empty struct omap_board_config_kernel structures and unused omap_get_nr_config() macro along with unused omap_get_var_config() function. Those apparently were never used in upstream kernels. Move OMAP3EVM revision bits to the board file as those are not used (and never have been used) outside of the board file in upstream kernels. Remove the tags part of the sti console workaround on OMAP2. Also remove the crystal type tag parsing code on OMAP1. Since the tags were never used upstream, the sti console workaround and the crystal type tag parsing code have never fired. OMAP custom tags code is not used - remove it. Finally, move all leftovers from the plat/board.h to include/linux/* and delete the plat/board.h file. The series are based on Linus' v3.6-rc3, checkpatch clean, and have been compile tested with omap1|2plus_defconfig(s). Igor Grinberg (9): ARM: OMAP: cleanup struct omap_board_config_kernel ARM: OMAP: omap3evm: cleanup revision bits ARM: OMAP: remove the sti console workaround ARM: OMAP1: remove the crystal type tag parsing ARM: OMAP: remove the omap custom tags ARM: OMAP1: move omap1_bl pdata out of arch/arm/* ARM: OMAP1: move lcd pdata out of arch/arm/* ARM: OMAP: move debug_card_init() function ARM: OMAP: remove plat/board.h file arch/arm/mach-omap1/board-ams-delta.c |1 - arch/arm/mach-omap1/board-fsample.c |1 - arch/arm/mach-omap1/board-generic.c |6 - arch/arm/mach-omap1/board-htcherald.c |1 - arch/arm/mach-omap1/board-nokia770.c|1 - arch/arm/mach-omap1/board-osk.c |1 + arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c |2 +- arch/arm/mach-omap1/board-perseus2.c|1 - arch/arm/mach-omap1/board-sx1.c |1 - arch/arm/mach-omap1/board-voiceblue.c |6 - arch/arm/mach-omap1/clock_data.c|8 -- arch/arm/mach-omap1/devices.c |1 - arch/arm/mach-omap1/serial.c|1 - arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-3430sdp.c |6 - arch/arm/mach-omap2/board-3630sdp.c |6 - arch/arm/mach-omap2/board-4430sdp.c |1 - arch/arm/mach-omap2/board-am3517crane.c |9 -- arch/arm/mach-omap2/board-am3517evm.c |6 - arch/arm/mach-omap2/board-apollon.c |1 - arch/arm/mach-omap2/board-cm-t35.c |6 - arch/arm/mach-omap2/board-cm-t3517.c|6 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-generic.c |1 - arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c|1 - arch/arm/mach-omap2/board-ldp.c |1 - arch/arm/mach-omap2/board-n8x0.c|1 - arch/arm/mach-omap2/board-omap3beagle.c |1 - arch/arm/mach-omap2/board-omap3evm.c| 19 ++- arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3pandora.c|1 - arch/arm/mach-omap2/board-omap3stalker.c|6 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-omap4panda.c |1 - arch/arm/mach-omap2/board-overo.c |1 - arch/arm/mach-omap2/board-rx51-peripherals.c|1 - arch/arm/mach-omap2/board-rx51.c|1 - arch/arm/mach-omap2/board-ti8168evm.c |6 - arch/arm/mach-omap2/board-zoom.c|1 - arch/arm/mach-omap2/common.c|1 - arch/arm/mach-omap2/devices.c |1 - arch/arm/mach-omap2/gpmc-nand.c |1 - arch/arm/mach-omap2/gpmc-onenand.c |1 - arch/arm/mach-omap2/gpmc-smc91x.c |1 - arch/arm/mach-omap2/gpmc-smsc911x.c |1 - arch/arm/mach-omap2/pm-debug.c |1 - arch/arm/mach-omap2/pm24xx.c| 11 -- arch/arm/mach-omap2/serial.c|1 - arch/arm/plat-omap/common.c | 40 --- arch/arm/plat-omap/counter_32k.c|1 - arch/arm/plat-omap/debug-devices.c |3 - arch/arm/plat-omap/devices.c|1 - arch/arm/plat-omap/fb.c |2 - arch/arm/plat-omap/include/plat/board.h | 138 --- arch/arm/plat-omap/include/plat/debug-devices.h |9 ++ arch/arm/plat-omap/include/plat/mmc.h |1 - arch/arm/plat-omap/include/plat/usb.h |1 - arch/arm/plat-omap/sram.c |1 - drivers/mmc/host/o
[PATCH 3/9] ARM: OMAP: remove the sti console workaround
The sti console workaround uses the OMAP custom tags.
Those tags are not used in upstream kernel and therefore the workaround
never fires on upstream kernels.
Remove the sti console workaround tags part.
This leaves the workaround functional part intact so can be reused if
needed.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/pm24xx.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 2edeffc..9e54dc9 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -352,16 +352,6 @@ int __init omap2_pm_init(void)
prcm_setup_regs();
- /* Hack to prevent MPU retention when STI console is enabled. */
- {
- const struct omap_sti_console_config *sti;
-
- sti = omap_get_config(OMAP_TAG_STI_CONSOLE,
- struct omap_sti_console_config);
- if (sti != NULL && sti->enable)
- sti_console_enabled = 1;
- }
-
/*
* We copy the assembler sleep/wakeup routines to SRAM.
* These routines need to be in SRAM as that's the only
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] ARM: OMAP1: move omap1_bl pdata out of arch/arm/*
omap1 backlight platform data resides inside plat/board.h while it
should be inside include/linux/...
Move the omap1 backlight platform data to
include/linux/platform_data/.
Cc: Richard Purdie
Cc: Florian Tobias Schandinat
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap1/board-osk.c |1 +
arch/arm/mach-omap1/board-palmte.c |1 +
arch/arm/mach-omap1/board-palmtt.c |1 +
arch/arm/mach-omap1/board-palmz71.c |1 +
arch/arm/plat-omap/include/plat/board.h |7 ---
drivers/video/backlight/omap1_bl.c |2 +-
include/linux/platform_data/omap1_bl.h | 11 +++
7 files changed, 16 insertions(+), 8 deletions(-)
create mode 100644 include/linux/platform_data/omap1_bl.h
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 8784705..569b687 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmte.c
b/arch/arm/mach-omap1/board-palmte.c
index 26bcb9d..7bf00ba 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmtt.c
b/arch/arm/mach-omap1/board-palmtt.c
index 4d09944..2cce505 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmz71.c
b/arch/arm/mach-omap1/board-palmz71.c
index 3559803..45ab9f0 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index 5938c72..d0bc46e 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -19,13 +19,6 @@ struct omap_lcd_config {
u8 data_lines;
};
-struct device;
-struct fb_info;
-struct omap_backlight_config {
- int default_intensity;
- int (*set_power)(struct device *dev, int state);
-};
-
/* for TI reference platforms sharing the same debug card */
extern int debug_card_init(u32 addr, unsigned gpio);
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index bfdc5fb..92257ef 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -27,9 +27,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#define OMAPBL_MAX_INTENSITY 0xff
diff --git a/include/linux/platform_data/omap1_bl.h
b/include/linux/platform_data/omap1_bl.h
new file mode 100644
index 000..881a8e9
--- /dev/null
+++ b/include/linux/platform_data/omap1_bl.h
@@ -0,0 +1,11 @@
+#ifndef __OMAP1_BL_H__
+#define __OMAP1_BL_H__
+
+#include
+
+struct omap_backlight_config {
+ int default_intensity;
+ int (*set_power)(struct device *dev, int state);
+};
+
+#endif
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] ARM: OMAP: cleanup struct omap_board_config_kernel
struct omap_board_config_kernel defined in the board files
is always empty and does not bring any added value.
Remove the struct omap_board_config_kernel instances from the board
files.
Also remove the omap_get_nr_config() macro and the omap_get_var_config()
function as both are not used for quite a long time (if ever).
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap1/board-generic.c |5 -
arch/arm/mach-omap1/board-voiceblue.c|5 -
arch/arm/mach-omap2/board-3430sdp.c |6 --
arch/arm/mach-omap2/board-3630sdp.c |6 --
arch/arm/mach-omap2/board-am3517crane.c |9 -
arch/arm/mach-omap2/board-am3517evm.c|6 --
arch/arm/mach-omap2/board-cm-t35.c |6 --
arch/arm/mach-omap2/board-cm-t3517.c |6 --
arch/arm/mach-omap2/board-omap3evm.c |7 ---
arch/arm/mach-omap2/board-omap3stalker.c |6 --
arch/arm/mach-omap2/board-ti8168evm.c|6 --
arch/arm/plat-omap/common.c |5 -
arch/arm/plat-omap/include/plat/board.h |4
13 files changed, 0 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap1/board-generic.c
b/arch/arm/mach-omap1/board-generic.c
index 6ec385e..d032734 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -52,9 +52,6 @@ static struct omap_usb_config generic1610_usb_config
__initdata = {
};
#endif
-static struct omap_board_config_kernel generic_config[] __initdata = {
-};
-
static void __init omap_generic_init(void)
{
#ifdef CONFIG_ARCH_OMAP15XX
@@ -76,8 +73,6 @@ static void __init omap_generic_init(void)
}
#endif
- omap_board_config = generic_config;
- omap_board_config_size = ARRAY_SIZE(generic_config);
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
}
diff --git a/arch/arm/mach-omap1/board-voiceblue.c
b/arch/arm/mach-omap1/board-voiceblue.c
index 3497769..11e1ff3 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -155,9 +155,6 @@ static struct omap_usb_config voiceblue_usb_config
__initdata = {
.pins[2]= 6,
};
-static struct omap_board_config_kernel voiceblue_config[] = {
-};
-
#define MACHINE_PANICED1
#define MACHINE_REBOOTING 2
#define MACHINE_REBOOT 4
@@ -275,8 +272,6 @@ static void __init voiceblue_init(void)
voiceblue_smc91x_resources[1].start = gpio_to_irq(8);
voiceblue_smc91x_resources[1].end = gpio_to_irq(8);
platform_add_devices(voiceblue_devices, ARRAY_SIZE(voiceblue_devices));
- omap_board_config = voiceblue_config;
- omap_board_config_size = ARRAY_SIZE(voiceblue_config);
omap_serial_init();
omap1_usb_init(&voiceblue_usb_config);
omap_register_i2c_bus(1, 100, NULL, 0);
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index a98c688..0f78cdb 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -31,7 +31,6 @@
#include
#include
-#include
#include
#include "common.h"
#include
@@ -191,9 +190,6 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = &sdp3430_lcd_device,
};
-static struct omap_board_config_kernel sdp3430_config[] __initdata = {
-};
-
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -576,8 +572,6 @@ static void __init omap_3430sdp_init(void)
int gpio_pendown;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
- omap_board_config = sdp3430_config;
- omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap_hsmmc_init(mmc);
omap3430_i2c_init();
omap_display_init(&sdp3430_dss_data);
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 2dc9ba5..8518b13 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -17,7 +17,6 @@
#include
#include "common.h"
-#include
#include
#include
@@ -67,9 +66,6 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
.reset_gpio_port[2] = -EINVAL
};
-static struct omap_board_config_kernel sdp_config[] __initdata = {
-};
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -197,8 +193,6 @@ static struct flash_partitions sdp_flash_partitions[] = {
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- omap_board_config = sdp_config;
- omap_board_config_size = ARRAY_SIZE(sdp_config);
zoom_peripherals_init();
omap_sdrc_init(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params);
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 92432c
[PATCH 2/9] ARM: OMAP: omap3evm: cleanup revision bits
The omap3evm has its revision information bits inside the plat/board.h
file. Those bits are not used anywhere in the upstream tree besides the
board-omap3evm.c file.
Move the OMAP3EVM_BOARD_GEN_* bits to the board file and remove the
get_omap3_evm_rev() function declaration.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-omap3evm.c| 12
arch/arm/plat-omap/include/plat/board.h | 18 --
2 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 5be082b..8477137 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -73,6 +73,18 @@
#define OMAP3EVM_GEN1_ETHR_GPIO_RST64
#define OMAP3EVM_GEN2_ETHR_GPIO_RST7
+/*
+ * OMAP35x EVM revision
+ * Run time detection of EVM revision is done by reading Ethernet
+ * PHY ID -
+ * GEN_1 = 0x0115
+ * GEN_2 = 0x9220
+ */
+enum {
+ OMAP3EVM_BOARD_GEN_1 = 0, /* EVM Rev between A - D */
+ OMAP3EVM_BOARD_GEN_2, /* EVM Rev >= Rev E */
+};
+
static u8 omap3_evm_version;
u8 get_omap3_evm_rev(void)
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index e6a8d79..db3bdc1 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -14,18 +14,6 @@
#include
-/*
- * OMAP35x EVM revision
- * Run time detection of EVM revision is done by reading Ethernet
- * PHY ID -
- * GEN_1 = 0x0115
- * GEN_2 = 0x9220
- */
-enum {
- OMAP3EVM_BOARD_GEN_1 = 0, /* EVM Rev between A - D */
- OMAP3EVM_BOARD_GEN_2, /* EVM Rev >= Rev E */
-};
-
/* Different peripheral ids */
#define OMAP_TAG_CLOCK 0x4f01
#define OMAP_TAG_GPIO_SWITCH 0x4f06
@@ -125,10 +113,4 @@ extern int omap_board_config_size;
/* for TI reference platforms sharing the same debug card */
extern int debug_card_init(u32 addr, unsigned gpio);
-/* OMAP3EVM revision */
-#if defined(CONFIG_MACH_OMAP3EVM)
-u8 get_omap3_evm_rev(void);
-#else
-#define get_omap3_evm_rev() (-EINVAL)
-#endif
#endif
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: OMAP1: remove the crystal type tag parsing
The omap1 crystal setting uses the OMAP custom tags.
Those tags are not used in upstream kernel and therefore the crystal
type is never set by the tag parsing code on upstream kernels.
Remove the crystal tag parsing code.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap1/clock_data.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index c007d80..6a32b9b 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include /* for omap_sram_reprogram_clock() */
#include
@@ -788,7 +787,6 @@ u32 cpu_mask;
int __init omap1_clk_init(void)
{
struct omap_clk *c;
- const struct omap_clock_config *info;
int crystal_type = 0; /* Default 12 MHz */
u32 reg;
@@ -837,12 +835,6 @@ int __init omap1_clk_init(void)
ck_dpll1_p = clk_get(NULL, "ck_dpll1");
ck_ref_p = clk_get(NULL, "ck_ref");
- info = omap_get_config(OMAP_TAG_CLOCK, struct omap_clock_config);
- if (info != NULL) {
- if (!cpu_is_omap15xx())
- crystal_type = info->system_clock_type;
- }
-
if (cpu_is_omap7xx())
ck_ref.rate = 1300;
if (cpu_is_omap16xx() && crystal_type == 2)
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] ARM: OMAP1: move lcd pdata out of arch/arm/*
omap1 lcd platform data resides inside plat/board.h while it
should be inside include/linux/...
Move the omap1 lcd platform data to include/linux/omapfb.h.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c |1 -
arch/arm/mach-omap1/board-htcherald.c |1 -
arch/arm/mach-omap1/board-nokia770.c|1 -
arch/arm/mach-omap1/board-palmte.c |1 -
arch/arm/mach-omap1/board-palmtt.c |1 -
arch/arm/mach-omap1/board-palmz71.c |1 -
arch/arm/mach-omap1/board-perseus2.c|1 -
arch/arm/mach-omap1/board-sx1.c |1 -
arch/arm/plat-omap/fb.c |2 --
arch/arm/plat-omap/include/plat/board.h |7 ---
include/linux/omapfb.h |7 ++-
12 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index c534698..c162369 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 6872f3f..6d98552 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index b3f6e94..b9771b5 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -42,7 +42,6 @@
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 2c0ca8f..ec01f03 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -26,7 +26,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmte.c
b/arch/arm/mach-omap1/board-palmte.c
index 7bf00ba..49f8d74 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmtt.c
b/arch/arm/mach-omap1/board-palmtt.c
index 2cce505..01523cd 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-palmz71.c
b/arch/arm/mach-omap1/board-palmz71.c
index 45ab9f0..a7abce6 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -40,7 +40,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-omap1/board-perseus2.c
b/arch/arm/mach-omap1/board-perseus2.c
index 703d55e..277e0bc 100644
--- a/arch/arm/mach-omap1/board-perseus2.c
+++ b/arch/arm/mach-omap1/board-perseus2.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
diff --git a/arch/arm/mach-omap1/board-sx1.c b/arch/arm/mach-omap1/board-sx1.c
index 8c665bd..2e1fff2 100644
--- a/arch/arm/mach-omap1/board-sx1.c
+++ b/arch/arm/mach-omap1/board-sx1.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index dd6f92c..bcbb9d5 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -33,8 +33,6 @@
#include
#include
-#include
-
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
static bool omapfb_lcd_configured;
diff --git a/arch/arm/plat-omap/include/plat/board.h
b/arch/arm/plat-omap/include/plat/board.h
index d0bc46e..2ddc198 100644
--- a/arch/arm/plat-omap/include/plat/board.h
+++ b/arch/arm/plat-omap/include/plat/board.h
@@ -12,13 +12,6 @@
#include
-struct omap_lcd_config {
- char panel_name[16];
- char ctrl_name[16];
- s16 nreset_gpio;
- u8 data_lines;
-};
-
/* for TI reference platforms sharing the same debug card */
extern int debug_card_init(u32 addr, unsigned gpio);
diff --git a/include/linux/omapfb.h b/include/linux/omapfb.h
index 4ff57e8..85af818 100644
--- a/include/linux/omapfb.h
+++ b/include/linux/omapfb.h
@@ -220,7 +220,12 @@ struct omapfb_display_info {
#ifdef __KERNEL__
-#include
+struct omap_lcd_config {
+ char panel_name[16];
+ char ctrl_name[16];
+ s16 nreset_gpio;
+ u8 data_lines;
+};
struct omapfb_platform_data {
struct omap_lcd_config lcd;
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levels
Hi Paul,
This patch does not apply, after the v2 of 1_6, see below:
On 09/14/11 00:28, Paul Walmsley wrote:
> Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
> of the OMAP2+ SoCs do in mach-omap2/cpu.c.
>
> Signed-off-by: Paul Walmsley
> Cc: Sanjeev Premi
> ---
> arch/arm/mach-omap2/id.c | 10 +-
> arch/arm/plat-omap/include/plat/cpu.h |3 ++-
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 46bc2f9..6810c52 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -312,7 +312,15 @@ static void __init omap3_check_revision(void)
>*
>* REVISIT: AM3505/AM3517 should have their own CHIP_IS
>*/
> - omap_revision = OMAP3517_REV(rev);
> + switch (rev) {
> + case 0:
> + omap_revision = OMAP3517_REV_ES1_0;
> + break;
> + case 1:
> + /* FALLTHROUGH */
> + default:
> + omap_revision = OMAP3517_REV_ES1_1;
> + }
> omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
> break;
> case 0xb891:
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h
> b/arch/arm/plat-omap/include/plat/cpu.h
> index b6bd8f7..566975c 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -398,7 +398,8 @@ IS_OMAP_TYPE(3517, 0x3517)
> #define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
>
> #define OMAP3517_CLASS 0x3517
After applying the v2 of 1_6, the above value should be 0x35170034
> -#define OMAP3517_REV(v) (OMAP3517_CLASS | (v << 8))
> +#define OMAP3517_REV_ES1_0 OMAP3517_CLASS
> +#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (OMAP_REVBITS_01 << 8))
>
> #define TI816X_CLASS 0x81600034
> #define TI8168_REV_ES1_0 TI816X_CLASS
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe 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 6/6] OMAP2+: id: remove OMAP_REVBITS_* macros
Hi Paul,
Same problem (as with 3_6) here...
On 09/14/11 00:28, Paul Walmsley wrote:
> The OMAP_REVBITS_* macros are just used as otherwise meaningless
> aliases for the numbers zero through five, so remove these macros.
>
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/plat-omap/include/plat/cpu.h | 33
> ++---
> 1 files changed, 10 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h
> b/arch/arm/plat-omap/include/plat/cpu.h
> index 566975c..0ec90cf 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -60,19 +60,6 @@ struct omap_chip_id {
> unsigned int omap_rev(void);
>
> /*
> - * Define CPU revision bits
> - *
> - * Verbose meaning of the revision bits may be different for a silicon
> - * family. This difference can be handled separately.
> - */
> -#define OMAP_REVBITS_00 0x00
> -#define OMAP_REVBITS_01 0x01
> -#define OMAP_REVBITS_02 0x02
> -#define OMAP_REVBITS_03 0x03
> -#define OMAP_REVBITS_04 0x04
> -#define OMAP_REVBITS_05 0x05
> -
> -/*
> * Get the CPU revision for OMAP devices
> */
> #define GET_OMAP_REVISION() ((omap_rev() >> 8) & 0xff)
> @@ -379,31 +366,31 @@ IS_OMAP_TYPE(3517, 0x3517)
> /* Various silicon revisions for omap2 */
> #define OMAP242X_CLASS 0x24200024
> #define OMAP2420_REV_ES1_0 OMAP242X_CLASS
> -#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (OMAP_REVBITS_01 << 8))
> +#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (0x1 << 8))
>
> #define OMAP243X_CLASS 0x24300024
> #define OMAP2430_REV_ES1_0 OMAP243X_CLASS
>
> #define OMAP343X_CLASS 0x34300034
> #define OMAP3430_REV_ES1_0 OMAP343X_CLASS
> -#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (OMAP_REVBITS_01 << 8))
> -#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (OMAP_REVBITS_02 << 8))
> -#define OMAP3430_REV_ES3_0 (OMAP343X_CLASS | (OMAP_REVBITS_03 << 8))
> -#define OMAP3430_REV_ES3_1 (OMAP343X_CLASS | (OMAP_REVBITS_04 << 8))
> -#define OMAP3430_REV_ES3_1_2 (OMAP343X_CLASS | (OMAP_REVBITS_05 << 8))
> +#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (0x1 << 8))
> +#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (0x2 << 8))
> +#define OMAP3430_REV_ES3_0 (OMAP343X_CLASS | (0x3 << 8))
> +#define OMAP3430_REV_ES3_1 (OMAP343X_CLASS | (0x4 << 8))
> +#define OMAP3430_REV_ES3_1_2 (OMAP343X_CLASS | (0x5 << 8))
>
> #define OMAP363X_CLASS 0x36300034
> #define OMAP3630_REV_ES1_0 OMAP363X_CLASS
> -#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (OMAP_REVBITS_01 << 8))
> -#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
> +#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (0x1 << 8))
> +#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (0x2 << 8))
>
> #define OMAP3517_CLASS 0x3517
> #define OMAP3517_REV_ES1_0 OMAP3517_CLASS
> -#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (OMAP_REVBITS_01 << 8))
> +#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (0x1 << 8))
>
> #define TI816X_CLASS 0x81600034
> #define TI8168_REV_ES1_0 TI816X_CLASS
> -#define TI8168_REV_ES1_1 (TI816X_CLASS | (OMAP_REVBITS_01 << 8))
> +#define TI8168_REV_ES1_1 (TI816X_CLASS | (0x1 << 8))
>
> #define OMAP443X_CLASS 0x44300044
> #define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8))
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe 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 6/6] OMAP2+: id: remove OMAP_REVBITS_* macros
On 09/14/11 15:29, Paul Walmsley wrote: > On Wed, 14 Sep 2011, Igor Grinberg wrote: > >> Hi Paul, >> >> Same problem (as with 3_6) here... > > Thanks, I'll repost those. In the meantime, maybe try pulling the branch > 'id_3517_cleanup_3.2' from git://git.pwsan.com/linux-2.6 ? I've applied those manually on top of v3.1-rc3: --cut [0.00] Linux version 3.1.0-rc3-6-ga942f6de (grinberg@grinberg-linux) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP Wed Sep 14 15:35:32 IDT 2011 [0.00] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Compulab CM-T3517 [0.00] Reserving 8388608 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES1.0 (l2cache iva sgx neon isp ) --cut ^^^ While U-Boot says: cut- U-Boot 2009.11-cm-t3517-1 (Dec 10 2010 - 23:25:02) AM35xx-GP ES1.0, L3-165MHz cut- Do I miss something, that should be in your tree? Pulling it in right now, should be available shortly... -- 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 6/6] OMAP2+: id: remove OMAP_REVBITS_* macros
On 09/14/11 16:10, Paul Walmsley wrote: > Hi Igor, > > Could you try this patch on top of the ones that you are testing? After applying the patch to your id_3517_cleanup_3.2 branch: --cut--- [0.00] Linux version 3.1.0-rc4-00014-gbe89163 (grinberg@grinberg-linux) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #2 SMP Wed Sep 14 16:21:47 IDT 2011 [0.00] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Compulab CM-T3517 [0.00] Reserving 8388608 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM3517 ES1.0 (l2cache iva sgx neon isp ) -cut The SoC is really AM3517. I have no AM3505 available right now, sorry... Feel free to add: Tested-by: Igor Grinberg > > thanks for the testing help, No problem ;) -- 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 v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
Hi Hemant,
On 09/29/11 04:09, Hemant Pedanekar wrote:
> This patch adds minimal support and build configuration for TI8148 EVM. Also
> adds support for low level debugging on UART1 console on the EVM.
>
> Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine
> info for TI8148 EVM and renamed as board-ti81xxevm.c.
Should we really rename the existing file?
Shouldn't we just stick to the name of the file submitted first?
(e.g. board-ti8168evm.c) and just add the support for the new
TI8148 EVM in to the existing file?
Because, I don't see any real necessity in renaming that file.
Also, it will spare the changes in Makefile.
>
> Signed-off-by: Hemant Pedanekar
> ---
> arch/arm/mach-omap2/Kconfig|5
> arch/arm/mach-omap2/Makefile |3 +-
> .../{board-ti8168evm.c => board-ti81xxevm.c} | 22 ++-
> arch/arm/plat-omap/include/plat/uncompress.h |3 ++
> 4 files changed, 26 insertions(+), 7 deletions(-)
> rename arch/arm/mach-omap2/{board-ti8168evm.c => board-ti81xxevm.c} (66%)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index a3b9227..cc4f213 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -316,6 +316,11 @@ config MACH_TI8168EVM
> depends on SOC_OMAPTI81XX
> default y
>
> +config MACH_TI8148EVM
> + bool "TI8148 Evaluation Module"
> + depends on SOC_OMAPTI81XX
> + default y
> +
> config MACH_OMAP_4430SDP
> bool "OMAP 4430 SDP board"
> default y
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 5ee4cd6..1dc2c6b 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -239,7 +239,8 @@ obj-$(CONFIG_MACH_OMAP3517EVM)+=
> board-am3517evm.o \
> obj-$(CONFIG_MACH_CRANEBOARD)+= board-am3517crane.o
>
> obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
> -obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
> +obj-$(CONFIG_MACH_TI8168EVM) += board-ti81xxevm.o
> +obj-$(CONFIG_MACH_TI8148EVM) += board-ti81xxevm.o
>
> # Platform specific device init code
>
> diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
> b/arch/arm/mach-omap2/board-ti81xxevm.c
> similarity index 66%
> rename from arch/arm/mach-omap2/board-ti8168evm.c
> rename to arch/arm/mach-omap2/board-ti81xxevm.c
> index 7935fc9..b858921 100644
> --- a/arch/arm/mach-omap2/board-ti8168evm.c
> +++ b/arch/arm/mach-omap2/board-ti81xxevm.c
> @@ -1,5 +1,5 @@
> /*
> - * Code for TI8168 EVM.
> + * Code for TI8168/TI8148 EVM.
> *
> * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
> *
> @@ -24,15 +24,15 @@
> #include
> #include
>
> -static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
> +static struct omap_board_config_kernel ti81xx_evm_config[] __initdata = {
> };
>
> -static void __init ti8168_evm_init(void)
> +static void __init ti81xx_evm_init(void)
> {
> omap_serial_init();
> omap_sdrc_init(NULL, NULL);
> - omap_board_config = ti8168_evm_config;
> - omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
> + omap_board_config = ti81xx_evm_config;
> + omap_board_config_size = ARRAY_SIZE(ti81xx_evm_config);
> }
>
> MACHINE_START(TI8168EVM, "ti8168evm")
> @@ -42,5 +42,15 @@ MACHINE_START(TI8168EVM, "ti8168evm")
> .init_early = ti81xx_init_early,
> .init_irq = ti81xx_init_irq,
> .timer = &omap3_timer,
> - .init_machine = ti8168_evm_init,
> + .init_machine = ti81xx_evm_init,
> +MACHINE_END
> +
> +MACHINE_START(TI8148EVM, "ti8148evm")
> + /* Maintainer: Texas Instruments */
> + .atag_offset= 0x100,
> + .map_io = ti81xx_map_io,
> + .init_early = ti81xx_init_early,
> + .init_irq = ti81xx_init_irq,
> + .timer = &omap3_timer,
> + .init_machine = ti81xx_evm_init,
> MACHINE_END
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
> b/arch/arm/plat-omap/include/plat/uncompress.h
> index 40336ad..8d052e7 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -175,6 +175,9 @@ static inline void __arch_decomp_setup(unsigned long
> arch_id)
> /* TI8168 base boards using UART3 */
> DEBUG_LL_TI81XX(3, ti8168evm);
>
> + /* TI8148 base boards using UART1 */
> + DEBUG_LL_TI81XX(1, ti8148evm);
> +
> } while (0);
> }
>
--
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 v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
On 10/03/11 18:45, Pedanekar, Hemant wrote: > Hi Igor, > > Igor Grinberg wrote on Sunday, October 02, 2011 5:38 PM: > >> Hi Hemant, >> >> On 09/29/11 04:09, Hemant Pedanekar wrote: >>> This patch adds minimal support and build configuration for TI8148 EVM. >>> Also adds support for low level debugging on UART1 console on the EVM. >>> >>> Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with >>> machine info for TI8148 EVM and renamed as board-ti81xxevm.c. >> >> Should we really rename the existing file? >> Shouldn't we just stick to the name of the file submitted first? >> (e.g. board-ti8168evm.c) and just add the support for the new >> TI8148 EVM in to the existing file? > > But won't this be misleading? Misleading? For whom? Actually, I don't really care how you call that file. What I care (and I think not just me) is uniformity, so if we decide to rename all those files that have multiple boards supported in them, I'm fine with it. So pros for my proposed approach would be: 1) Currently, there are already board files with multiple boards supported in them that follow the approach and renaming them is really unnecessary. 2) git log will not break. 3) boards that cannot be named after the convention like 81xx but can be added to the same file will not require further renaming (like 82x8 - I don't really know if that will exist, just wondering). 4) This renaming is really what Linus likes ;) cons: 1) Misleading? Currently, I don't think this renaming is good for anything, especially that majority of the board stuff should be transformed to the DT descriptors. -- 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: DSS testing help?
On 10/04/11 10:06, Tomi Valkeinen wrote: > Hi Paul, > > On Mon, 2011-10-03 at 14:48 -0600, Paul Walmsley wrote: >> Hello Sricharan, >> >> It looks like Archit is out of the office. Would it be possible for you >> to test the updated DSS reset patch, below? >> >> thanks >> >> - Paul >> >> -- Forwarded message -- >> Date: Mon, 3 Oct 2011 13:30:06 -0600 (MDT) >> From: Paul Walmsley >> To: Archit Taneja >> Cc: "Valkeinen, Tomi" , >> "Shilimkar, Santosh" , >> "R, Sricharan" , "t...@atomide.com" >> , >> "linux-omap@vger.kernel.org" , >> "linux-arm-ker...@lists.infradead.org" >> >> Subject: Re: [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if >> display is >> enabled in bootloader > > For what it's worth, I took your dss hwmod patches from > hwmod_dss_fixes_3.2 branch, and tested them with my latest dss tree. > Works fine on Blaze. However, I don't have a bootloader which would > enable the DSS, so that part I cannot test. I think the latest U-Boot for BeagleBoard supports enabling the DSS, but I'm not sure and I don't have BeagleBoard. -- 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
git.kernel.org is back
Hi Tony, (git.)kernel.org is back online recently, but there is no tmlind/* project(s) on it? What are your intentions on this? Should we just wait for while, or will it stay on the github? -- 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 4/8] ti814evm: Add support for musb interface
Hi Ajay, On 10/11/11 13:26, Ajay Kumar Gupta wrote: > From: Ravi Babu > > Adding musb support in ti814 EVM board file. > > Signed-off-by: Ajay Kumar Gupta > Signed-off-by: Ravi Babu > Acked-by: Felipe Balbi > --- > arch/arm/mach-omap2/board-ti8148evm.c |9 + This file does not exist and probably will not exist in the future, see [1] and [2]. So this patch can be dropped. Your 3/8 patch provides the support for both boards. [1] - http://www.spinics.net/lists/linux-omap/msg58348.html [2] - http://www.spinics.net/lists/arm-kernel/msg143915.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 3/8] ti816evm: Add support for musb interface
Hi Ajay,
On 10/11/11 13:26, Ajay Kumar Gupta wrote:
> From: Ravi Babu
>
> Adding musb support in ti816 EVM board file.
>
> Signed-off-by: Ajay Kumar Gupta
> Signed-off-by: Ravi Babu
> Acked-by: Felipe Balbi
This patch can result in a merge conflict, therefore I think
this one should be taken through Tony's tree.
Also you should work together with Hemant Pedanekar and
someone of you should rebase on top of the other otherwise
one of the patches (yours or Hemant's) possibly will not apply.
> ---
> arch/arm/mach-omap2/board-ti8168evm.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
> b/arch/arm/mach-omap2/board-ti8168evm.c
> index 2c243df..1f3d423 100644
> --- a/arch/arm/mach-omap2/board-ti8168evm.c
> +++ b/arch/arm/mach-omap2/board-ti8168evm.c
> @@ -23,6 +23,14 @@
> #include
> #include
> #include
> +#include
> +
> +static struct omap_musb_board_data musb_board_data = {
> + .set_phy_power = ti81xx_musb_phy_power,
> + .interface_type = MUSB_INTERFACE_ULPI,
> + .mode = MUSB_OTG,
> + .power = 500,
> +};
>
> static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
> };
> @@ -33,6 +41,7 @@ static void __init ti8168_evm_init(void)
> omap_sdrc_init(NULL, NULL);
> omap_board_config = ti8168_evm_config;
> omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
> + usb_musb_init(&musb_board_data);
> }
>
> static void __init ti8168_evm_map_io(void)
--
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
[PATCH 0/4] ARM: OMAP3: cm-t35/cm-t3730 fixes
This patch series fixes several issues on boards in subj. It is based on Tony's board branch at [1]. [1] git://github.com/tmlind/linux.git Igor Grinberg (4): ARM: OMAP3: cm-t35: add regulator supply for ads7846 ARM: OMAP3: cm-t35: fix DSS regulator supply ARM: OMAP3: cm-t35: fix audio arm: omap3: cm-t35: add reset for sb-t35 usb hub arch/arm/mach-omap2/board-cm-t35.c | 50 --- 1 files changed, 40 insertions(+), 10 deletions(-) -- 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
[PATCH 1/4] ARM: OMAP3: cm-t35: add regulator supply for ads7846
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index e15d39b..6d93db0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -343,6 +343,10 @@ static struct regulator_consumer_supply
cm_t35_vdvi_supply[] = {
REGULATOR_SUPPLY("vdvi", "omapdss"),
};
+static struct regulator_consumer_supply cm_t35_vio_supplies[] = {
+ REGULATOR_SUPPLY("vcc", "spi1.0"),
+};
+
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data cm_t35_vmmc1 = {
.constraints = {
@@ -373,6 +377,19 @@ static struct regulator_init_data cm_t35_vsim = {
.consumer_supplies = cm_t35_vsim_supply,
};
+static struct regulator_init_data cm_t35_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(cm_t35_vio_supplies),
+ .consumer_supplies = cm_t35_vio_supplies,
+};
+
static uint32_t cm_t35_keymap[] = {
KEY(0, 0, KEY_A), KEY(0, 1, KEY_B), KEY(0, 2, KEY_LEFT),
KEY(1, 0, KEY_UP), KEY(1, 1, KEY_ENTER), KEY(1, 2, KEY_DOWN),
@@ -456,6 +473,7 @@ static struct twl4030_platform_data cm_t35_twldata = {
.gpio = &cm_t35_gpio_data,
.vmmc1 = &cm_t35_vmmc1,
.vsim = &cm_t35_vsim,
+ .vio= &cm_t35_vio,
};
static void __init cm_t35_init_i2c(void)
--
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
[PATCH 3/4] ARM: OMAP3: cm-t35: fix audio
TWL4030 audio codec is not being registered if no platform data is
supplied. Plovide platform data for the TWL4030 audio codec.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1ee056f5..18cd50c 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -477,7 +477,8 @@ static struct twl4030_platform_data cm_t35_twldata = {
static void __init cm_t35_init_i2c(void)
{
omap3_pmic_get_config(&cm_t35_twldata, TWL_COMMON_PDATA_USB,
- TWL_COMMON_REGULATOR_VDAC);
+ TWL_COMMON_REGULATOR_VDAC |
+ TWL_COMMON_PDATA_AUDIO);
omap3_pmic_init("tps65930", &cm_t35_twldata);
}
--
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
[PATCH 2/4] ARM: OMAP3: cm-t35: fix DSS regulator supply
cm-t35 DSS suplies are connected to VIO.
In fact, TPS65930 does not have VPLL2.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 6d93db0..1ee056f5 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -339,12 +339,10 @@ static struct regulator_consumer_supply
cm_t35_vsim_supply[] = {
REGULATOR_SUPPLY("vmmc_aux", "omap_hsmmc.0"),
};
-static struct regulator_consumer_supply cm_t35_vdvi_supply[] = {
- REGULATOR_SUPPLY("vdvi", "omapdss"),
-};
-
static struct regulator_consumer_supply cm_t35_vio_supplies[] = {
REGULATOR_SUPPLY("vcc", "spi1.0"),
+ REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
+ REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"),
};
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
@@ -479,12 +477,7 @@ static struct twl4030_platform_data cm_t35_twldata = {
static void __init cm_t35_init_i2c(void)
{
omap3_pmic_get_config(&cm_t35_twldata, TWL_COMMON_PDATA_USB,
- TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
-
- cm_t35_twldata.vpll2->constraints.name = "VDVI";
- cm_t35_twldata.vpll2->num_consumer_supplies =
- ARRAY_SIZE(cm_t35_vdvi_supply);
- cm_t35_twldata.vpll2->consumer_supplies = cm_t35_vdvi_supply;
+ TWL_COMMON_REGULATOR_VDAC);
omap3_pmic_init("tps65930", &cm_t35_twldata);
}
--
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
[PATCH 4/4] arm: omap3: cm-t35: add reset for sb-t35 usb hub
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 18cd50c..3201c9e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -52,7 +52,8 @@
#include "hsmmc.h"
#include "common-board-devices.h"
-#define CM_T35_GPIO_PENDOWN57
+#define CM_T35_GPIO_PENDOWN57
+#define SB_T35_USB_HUB_RESET_GPIO 167
#define CM_T35_SMSC911X_CS 5
#define CM_T35_SMSC911X_GPIO 163
@@ -436,6 +437,23 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata
= {
.reset_gpio_port[2] = -EINVAL
};
+static void cm_t35_init_usbh(void)
+{
+ int err;
+
+ err = gpio_request_one(SB_T35_USB_HUB_RESET_GPIO,
+ GPIOF_OUT_INIT_LOW, "usb hub rst");
+ if (err) {
+ pr_err("SB-T35: usb hub rst gpio request failed: %d\n", err);
+ } else {
+ udelay(10);
+ gpio_set_value(SB_T35_USB_HUB_RESET_GPIO, 1);
+ msleep(1);
+ }
+
+ usbhs_init(&usbhs_bdata);
+}
+
static int cm_t35_twl_gpio_setup(struct device *dev, unsigned gpio,
unsigned ngpio)
{
@@ -624,7 +642,7 @@ static void __init cm_t3x_common_init(void)
cm_t35_init_display();
usb_musb_init(NULL);
- usbhs_init(&usbhs_bdata);
+ cm_t35_init_usbh();
}
static void __init cm_t35_init(void)
--
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
[PATCH 4/4 v2] ARM: OMAP3: cm-t35: add reset for sb-t35 usb hub
Signed-off-by: Igor Grinberg
---
v2: fixed subject, no change functional changes
arch/arm/mach-omap2/board-cm-t35.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 18cd50c..3201c9e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -52,7 +52,8 @@
#include "hsmmc.h"
#include "common-board-devices.h"
-#define CM_T35_GPIO_PENDOWN57
+#define CM_T35_GPIO_PENDOWN57
+#define SB_T35_USB_HUB_RESET_GPIO 167
#define CM_T35_SMSC911X_CS 5
#define CM_T35_SMSC911X_GPIO 163
@@ -436,6 +437,23 @@ static struct usbhs_omap_board_data usbhs_bdata __initdata
= {
.reset_gpio_port[2] = -EINVAL
};
+static void cm_t35_init_usbh(void)
+{
+ int err;
+
+ err = gpio_request_one(SB_T35_USB_HUB_RESET_GPIO,
+ GPIOF_OUT_INIT_LOW, "usb hub rst");
+ if (err) {
+ pr_err("SB-T35: usb hub rst gpio request failed: %d\n", err);
+ } else {
+ udelay(10);
+ gpio_set_value(SB_T35_USB_HUB_RESET_GPIO, 1);
+ msleep(1);
+ }
+
+ usbhs_init(&usbhs_bdata);
+}
+
static int cm_t35_twl_gpio_setup(struct device *dev, unsigned gpio,
unsigned ngpio)
{
@@ -624,7 +642,7 @@ static void __init cm_t3x_common_init(void)
cm_t35_init_display();
usb_musb_init(NULL);
- usbhs_init(&usbhs_bdata);
+ cm_t35_init_usbh();
}
static void __init cm_t35_init(void)
--
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 3/4] ARM: OMAP3: cm-t35: fix audio
Hi Sergei, On 10/19/11 13:03, Sergei Shtylyov wrote: > Hello. > > On 19-10-2011 13:39, Igor Grinberg wrote: > >> TWL4030 audio codec is not being registered if no platform data is >> supplied. Plovide platform data for the TWL4030 audio codec. > >s/Plovide/Provide/. Perhaps a committer can fix this typo. This one is really nice ;) 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
[PATCH 3/4 v2] ARM: OMAP3: cm-t35: fix audio
TWL4030 audio codec is not being registered if no platform data is
supplied. Provide platform data for the TWL4030 audio codec.
Signed-off-by: Igor Grinberg
---
v2: fix the commit message (10x to Sergei)
arch/arm/mach-omap2/board-cm-t35.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1ee056f5..18cd50c 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -477,7 +477,8 @@ static struct twl4030_platform_data cm_t35_twldata = {
static void __init cm_t35_init_i2c(void)
{
omap3_pmic_get_config(&cm_t35_twldata, TWL_COMMON_PDATA_USB,
- TWL_COMMON_REGULATOR_VDAC);
+ TWL_COMMON_REGULATOR_VDAC |
+ TWL_COMMON_PDATA_AUDIO);
omap3_pmic_init("tps65930", &cm_t35_twldata);
}
--
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
[PATCH] ARM: OMAP3: cm-t35: fix mux mode for DSS pins
OMAP pin mux configuration API has been used incorrectly resulting
in wrong mux mode set for several DSS pins.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 32 ++--
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 3201c9e..023b768 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -600,24 +600,28 @@ static void __init cm_t3x_common_dss_mux_init(int
mux_mode)
static void __init cm_t35_init_mux(void)
{
- omap_mux_init_signal("gpio_70", OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("gpio_71", OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("gpio_72", OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("gpio_73", OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("gpio_74", OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("gpio_75", OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
- cm_t3x_common_dss_mux_init(OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT);
+ int mux_mode = OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT;
+
+ omap_mux_init_signal("dss_data0.dss_data0", mux_mode);
+ omap_mux_init_signal("dss_data1.dss_data1", mux_mode);
+ omap_mux_init_signal("dss_data2.dss_data2", mux_mode);
+ omap_mux_init_signal("dss_data3.dss_data3", mux_mode);
+ omap_mux_init_signal("dss_data4.dss_data4", mux_mode);
+ omap_mux_init_signal("dss_data5.dss_data5", mux_mode);
+ cm_t3x_common_dss_mux_init(mux_mode);
}
static void __init cm_t3730_init_mux(void)
{
- omap_mux_init_signal("sys_boot0", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("sys_boot1", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("sys_boot3", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("sys_boot4", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("sys_boot5", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
- omap_mux_init_signal("sys_boot6", OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
- cm_t3x_common_dss_mux_init(OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT);
+ int mux_mode = OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT;
+
+ omap_mux_init_signal("sys_boot0", mux_mode);
+ omap_mux_init_signal("sys_boot1", mux_mode);
+ omap_mux_init_signal("sys_boot3", mux_mode);
+ omap_mux_init_signal("sys_boot4", mux_mode);
+ omap_mux_init_signal("sys_boot5", mux_mode);
+ omap_mux_init_signal("sys_boot6", mux_mode);
+ cm_t3x_common_dss_mux_init(mux_mode);
}
#else
static inline void cm_t35_init_mux(void) {}
--
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
