Re: [alsa-devel] [PATCH 0/4] ASoC: OMAP4: McPDM: Fix legacy support
Hi Tony, On Tuesday 02 August 2011 13:34:13 Ujfalusi, Peter wrote: Hello, The OMAP4 McPDM driver in upstream has been broken for some time... This series fixes that, and enables basic audio playback/capture over the mcpdm interface. Would you have time to look at this series? Specially patch 1 (maybe 2 as well). We are planning to send this series through audio for 3.1. Two patch in this series has been taken from the OMAP4/ASoC: New McPDM driver series (patch 1, and 2) [1]. Since I was on holiday, I did not had time to rewrite the driver rewrite patch, but I feel that fixing the basic audio support for OMAP4 is needed. The aim here is to have working audio in upstream kernel for 3.1, and have the new McPDM driver stack up for the 3.2 release. [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2011-July/041687.html Br, Peter --- Peter Ujfalusi (4): OMAP: McPDM: Convert McPDM device to omap_device OMAP4: hwmod: enable mcpdm hwmod device. ASoC: omap-mcpdm: Fix threshold and dma configuration ASoC: OMAP4: McPDM: Convert to hwmod/omap_device arch/arm/mach-omap2/devices.c | 33 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/plat-omap/devices.c | 36 -- sound/soc/omap/mcpdm.c | 38 +++ sound/soc/omap/mcpdm.h | 1 - sound/soc/omap/omap-mcpdm.c| 19 + sound/soc/omap/sdp4430.c |2 +- 7 files changed, 69 insertions(+), 62 deletions(-) Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Where to start
Hello all, sorry for asking a 'basic' question on this list. If this is indeed the wrong place (and even if it isn't!), please feel free to point me to a better forum for arm/omap specific kernel discussions. My questions are: 1. What is a good place to read up on how to write board files and drivers for OMAP3/4 based boards? The documentation I have found is scarce and often outdated. 2. A specific problem I have is with DSS/FB/LCD panel/the like. We have an old board file for v2.6.32 TI PSP. Despite doing what appears to be equivalent to what the old board file does, there is nothing shown on the LCD (nor DVI, VGA, TV-out, ). What could have changed between TI's 2.6.32 and 3.0-omap that causes, for instance an LCD panel, to stay blank in the latter but not in the former. While an answer would be very appreciated, even better would be to get hints on how to learn to figure out the answer to #2 by myself... feeling that will be a handy skill... :-) Thank you, Arpad -- http://www.fastmail.fm - The professional email service -- To unsubscribe from this list: send the line unsubscribe 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 00/13] Clean up mach/gpio.h headers
This is a preliminary posting of my gpio patch set.
This patch series moves the trivial gpiolib implementations out of
mach/gpio.h and into asm/gpio.h.
As a side effect of that, most of this patch series is about fixing up
direct includes of mach/gpio.h - this is something I've been on at
people over the last year or more about ensuring that they use
linux/gpio.h in preference. While I've blindly converted all arch/arm
to use linux/gpio.h (with the exception of mach/ includes which are
converted to asm/gpio.h), drivers were only converted to asm/gpio.h.
These should be reviewed and changed to linux/gpio.h.
As a result of this patch series, several mach/gpio.h end up being
empty.
Many others just contain platform private GPIO APIs and definitions.
The last thing which mach/gpio.h is used for is to provide a definition
for ARCH_GPIO_NR to asm-generic/gpio.h. I've not attempted to solve
that issue yet.
A small number of platforms optimize the gpio accessors for on-SoC
GPIOs. In the interests of consolidation, these will have to be killed
but this patch set does not do that yet.
Lastly, several {mach,plat}/gpio.h needs to be looked at with a view to
deleting the direct include of asm-generic/gpio.h.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] ARM: gpio: at91: remove redundant include of mach/gpio.h
asm/gpio.h already directly includes mach/gpio.h. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-at91/gpio.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c index 4615528..2225042 100644 --- a/arch/arm/mach-at91/gpio.c +++ b/arch/arm/mach-at91/gpio.c @@ -22,7 +22,6 @@ #include mach/hardware.h #include mach/at91_pio.h -#include mach/gpio.h #include asm/gpio.h -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] ARM: gpio: omap: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/gpio/gpio-omap.c |2 +-
drivers/input/keyboard/omap-keypad.c |2 +-
drivers/mfd/menelaus.c |2 +-
drivers/mmc/host/omap.c |2 +-
drivers/mtd/nand/ams-delta.c |2 +-
drivers/mtd/onenand/omap2.c |2 +-
drivers/video/omap/lcd_apollon.c |2 +-
drivers/video/omap/lcd_h3.c |2 +-
drivers/video/omap/lcd_inn1610.c |2 +-
drivers/video/omap/lcd_ldp.c |2 +-
drivers/video/omap/lcd_osk.c |2 +-
drivers/video/omap/lcd_overo.c |2 +-
drivers/video/omap/lcd_palmtt.c |2 +-
13 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0599854..9c27244 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -25,7 +25,7 @@
#include mach/hardware.h
#include asm/irq.h
#include mach/irqs.h
-#include mach/gpio.h
+#include asm/gpio.h
#include asm/mach/irq.h
struct gpio_bank {
diff --git a/drivers/input/keyboard/omap-keypad.c
b/drivers/input/keyboard/omap-keypad.c
index 33d0bdc..323bcdf 100644
--- a/drivers/input/keyboard/omap-keypad.c
+++ b/drivers/input/keyboard/omap-keypad.c
@@ -35,7 +35,7 @@
#include linux/mutex.h
#include linux/errno.h
#include linux/slab.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/keypad.h
#include plat/menelaus.h
#include asm/irq.h
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9cee8e7..af5d9d0 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -44,7 +44,7 @@
#include asm/mach/irq.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/menelaus.h
#define DRIVER_NAMEmenelaus
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index a6c3290..2dba999 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -33,7 +33,7 @@
#include plat/board.h
#include plat/mmc.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/dma.h
#include plat/mux.h
#include plat/fpga.h
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 78017eb..9e6b498 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -26,7 +26,7 @@
#include asm/io.h
#include mach/hardware.h
#include asm/sizes.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/board-ams-delta.h
/*
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index a916dec..6a1d6d9 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -40,7 +40,7 @@
#include asm/mach/flash.h
#include plat/gpmc.h
#include plat/onenand.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/dma.h
diff --git a/drivers/video/omap/lcd_apollon.c b/drivers/video/omap/lcd_apollon.c
index 10459d8..4b24f54 100644
--- a/drivers/video/omap/lcd_apollon.c
+++ b/drivers/video/omap/lcd_apollon.c
@@ -24,7 +24,7 @@
#include linux/module.h
#include linux/platform_device.h
-#include mach/gpio.h
+#include asm/gpio.h
#include omapfb.h
diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
index 8df6887..622ad83 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -23,7 +23,7 @@
#include linux/platform_device.h
#include linux/i2c/tps65010.h
-#include mach/gpio.h
+#include asm/gpio.h
#include omapfb.h
#define MODULE_NAMEomapfb-lcd_h3
diff --git a/drivers/video/omap/lcd_inn1610.c b/drivers/video/omap/lcd_inn1610.c
index 9fff86f..12cc52a 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -22,7 +22,7 @@
#include linux/module.h
#include linux/platform_device.h
-#include mach/gpio.h
+#include asm/gpio.h
#include omapfb.h
#define MODULE_NAMEomapfb-lcd_h3
diff --git a/drivers/video/omap/lcd_ldp.c b/drivers/video/omap/lcd_ldp.c
index 0f5952c..0624664 100644
--- a/drivers/video/omap/lcd_ldp.c
+++ b/drivers/video/omap/lcd_ldp.c
@@ -26,7 +26,7 @@
#include linux/delay.h
#include linux/i2c/twl.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/mux.h
#include asm/mach-types.h
diff --git a/drivers/video/omap/lcd_osk.c b/drivers/video/omap/lcd_osk.c
index b87e8b8..6f8d13c 100644
--- a/drivers/video/omap/lcd_osk.c
+++ b/drivers/video/omap/lcd_osk.c
@@ -23,7 +23,7 @@
#include linux/module.h
#include linux/platform_device.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/mux.h
#include omapfb.h
diff --git a/drivers/video/omap/lcd_overo.c b/drivers/video/omap/lcd_overo.c
index 564933f..b8fd5b2 100644
--- a/drivers/video/omap/lcd_overo.c
+++ b/drivers/video/omap/lcd_overo.c
@@ -23,7 +23,7 @@
#include linux/platform_device.h
#include linux/i2c/twl.h
-#include mach/gpio.h
+#include asm/gpio.h
#include plat/mux.h
#include asm/mach-types.h
diff --git a/drivers/video/omap/lcd_palmtt.c b/drivers/video/omap/lcd_palmtt.c
index ff0e6d7..b51b332 100644
---
[PATCH 04/13] ARM: gpio: at91: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/ata/pata_at91.c |2 +- drivers/ide/at91_ide.c|2 +- drivers/net/arm/at91_ether.c |2 +- drivers/spi/spi-atmel.c |2 +- drivers/tty/serial/atmel_serial.c |2 +- drivers/video/atmel_lcdfb.c |2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/ata/pata_at91.c b/drivers/ata/pata_at91.c index 960c725..3f4c261 100644 --- a/drivers/ata/pata_at91.c +++ b/drivers/ata/pata_at91.c @@ -30,7 +30,7 @@ #include mach/at91sam9_smc.h #include mach/board.h -#include mach/gpio.h +#include asm/gpio.h #define DRV_NAME pata_at91 #define DRV_VERSION0.3 diff --git a/drivers/ide/at91_ide.c b/drivers/ide/at91_ide.c index 000a78e..6dede8f 100644 --- a/drivers/ide/at91_ide.c +++ b/drivers/ide/at91_ide.c @@ -28,7 +28,7 @@ #include linux/platform_device.h #include mach/board.h -#include mach/gpio.h +#include asm/gpio.h #include mach/at91sam9_smc.h #define DRV_NAME at91_ide diff --git a/drivers/net/arm/at91_ether.c b/drivers/net/arm/at91_ether.c index 29dc435..48b4ec1 100644 --- a/drivers/net/arm/at91_ether.c +++ b/drivers/net/arm/at91_ether.c @@ -35,7 +35,7 @@ #include asm/mach-types.h #include mach/at91rm9200_emac.h -#include mach/gpio.h +#include asm/gpio.h #include mach/board.h #include at91_ether.h diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index 82dee9a..d3bff42 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -22,7 +22,7 @@ #include asm/io.h #include mach/board.h -#include mach/gpio.h +#include asm/gpio.h #include mach/cpu.h /* SPI register offsets */ diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c index af9b781..b8a00ae 100644 --- a/drivers/tty/serial/atmel_serial.c +++ b/drivers/tty/serial/atmel_serial.c @@ -46,7 +46,7 @@ #ifdef CONFIG_ARM #include mach/cpu.h -#include mach/gpio.h +#include asm/gpio.h #endif #define PDC_BUFFER_SIZE512 diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c index 817ab60..dda9206 100644 --- a/drivers/video/atmel_lcdfb.c +++ b/drivers/video/atmel_lcdfb.c @@ -21,7 +21,7 @@ #include mach/board.h #include mach/cpu.h -#include mach/gpio.h +#include asm/gpio.h #include video/atmel_lcdc.h -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] ARM: gpio: nomadik: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/gpio/gpio-nomadik.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c index 2c212c7..f7f0406 100644 --- a/drivers/gpio/gpio-nomadik.c +++ b/drivers/gpio/gpio-nomadik.c @@ -28,7 +28,7 @@ #include plat/pincfg.h #include mach/hardware.h -#include mach/gpio.h +#include asm/gpio.h /* * The GPIO module in the Nomadik family of Systems-on-Chip is an -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] ARM: gpio: davinci: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/usb/musb/davinci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 8bdf25a..f9a3f62 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -35,7 +35,7 @@ #include mach/hardware.h #include mach/memory.h -#include mach/gpio.h +#include asm/gpio.h #include mach/cputype.h #include asm/mach-types.h -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] ARM: gpio: pnx4008: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/usb/host/ohci-pnx4008.c |2 +- drivers/video/pnx4008/sdum.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ohci-pnx4008.c b/drivers/usb/host/ohci-pnx4008.c index 653d6a6..d1b4193 100644 --- a/drivers/usb/host/ohci-pnx4008.c +++ b/drivers/usb/host/ohci-pnx4008.c @@ -26,7 +26,7 @@ #include mach/platform.h #include mach/irqs.h -#include mach/gpio.h +#include asm/gpio.h #define USB_CTRL IO_ADDRESS(PNX4008_PWRMAN_BASE + 0x64) diff --git a/drivers/video/pnx4008/sdum.c b/drivers/video/pnx4008/sdum.c index 5ec4f2d..50e0039 100644 --- a/drivers/video/pnx4008/sdum.c +++ b/drivers/video/pnx4008/sdum.c @@ -30,7 +30,7 @@ #include linux/clk.h #include linux/gfp.h #include asm/uaccess.h -#include mach/gpio.h +#include asm/gpio.h #include sdum.h #include fbcommon.h -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] ARM: gpio: ixp2000: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/i2c/busses/i2c-ixp2000.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ixp2000.c b/drivers/i2c/busses/i2c-ixp2000.c
index 5d8aed5..be9991b 100644
--- a/drivers/i2c/busses/i2c-ixp2000.c
+++ b/drivers/i2c/busses/i2c-ixp2000.c
@@ -35,7 +35,7 @@
#include linux/slab.h
#include mach/hardware.h /* Pick up IXP2000-specific bits */
-#include mach/gpio.h
+#include asm/gpio.h
static inline int ixp2000_scl_pin(void *data)
{
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] ARM: gpio: tegra: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/mmc/host/sdhci-tegra.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c index 18b0bd3..e9094f1 100644 --- a/drivers/mmc/host/sdhci-tegra.c +++ b/drivers/mmc/host/sdhci-tegra.c @@ -21,7 +21,7 @@ #include linux/mmc/card.h #include linux/mmc/host.h -#include mach/gpio.h +#include asm/gpio.h #include mach/sdhci.h #include sdhci-pltfm.h -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] ARM: gpio: pxa: convert drivers to use asm/gpio.h rather than mach/gpio.h
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/pcmcia/pxa2xx_vpac270.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/pcmcia/pxa2xx_vpac270.c b/drivers/pcmcia/pxa2xx_vpac270.c index e956f65..66ab92c 100644 --- a/drivers/pcmcia/pxa2xx_vpac270.c +++ b/drivers/pcmcia/pxa2xx_vpac270.c @@ -17,7 +17,7 @@ #include asm/mach-types.h -#include mach/gpio.h +#include asm/gpio.h #include mach/vpac270.h #include soc_common.h -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
into asm/gpio.h. This is basically the include of asm-generic/gpio.h
and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
as described in Documentation/gpio.txt
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/gpio.h | 10 ++
arch/arm/mach-at91/include/mach/gpio.h |5 +
arch/arm/mach-ep93xx/include/mach/gpio.h|7 +--
arch/arm/mach-exynos4/include/mach/gpio.h |5 +
arch/arm/mach-gemini/include/mach/gpio.h|5 +
arch/arm/mach-ks8695/include/mach/gpio.h| 11 ++-
arch/arm/mach-lpc32xx/include/mach/gpio.h | 17 +
arch/arm/mach-msm/include/mach/gpio.h |5 +
arch/arm/mach-mxs/include/mach/gpio.h |6 +-
arch/arm/mach-realview/include/mach/gpio.h |6 +-
arch/arm/mach-s3c2410/include/mach/gpio.h |5 +
arch/arm/mach-s3c64xx/include/mach/gpio.h |6 +-
arch/arm/mach-s5p64x0/include/mach/gpio.h |6 +-
arch/arm/mach-s5pc100/include/mach/gpio.h |6 +-
arch/arm/mach-s5pv210/include/mach/gpio.h |6 +-
arch/arm/mach-shmobile/include/mach/gpio.h | 15 +--
arch/arm/mach-tegra/include/mach/gpio.h |6 +-
arch/arm/mach-versatile/include/mach/gpio.h |6 +-
arch/arm/mach-vt8500/include/mach/gpio.h|6 +-
arch/arm/mach-w90x900/include/mach/gpio.h |5 +
arch/arm/plat-mxc/include/mach/gpio.h |5 +
arch/arm/plat-nomadik/include/plat/gpio.h | 11 +--
arch/arm/plat-omap/include/plat/gpio.h | 15 +--
arch/arm/plat-orion/include/plat/gpio.h |6 ++
arch/arm/plat-spear/include/plat/gpio.h |6 +-
25 files changed, 36 insertions(+), 151 deletions(-)
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 166a7a3..15e8970 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -4,4 +4,14 @@
/* not all ARM platforms necessarily support this API ... */
#include mach/gpio.h
+#ifdef __ARM_GPIOLIB_TRIVIAL
+/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
+#include asm-generic/gpio.h
+
+/* The trivial gpiolib dispatchers */
+#define gpio_get_value __gpio_get_value
+#define gpio_set_value __gpio_set_value
+#define gpio_cansleep __gpio_cansleep
+#endif
+
#endif /* _ARCH_ARM_GPIO_H */
diff --git a/arch/arm/mach-at91/include/mach/gpio.h
b/arch/arm/mach-at91/include/mach/gpio.h
index 056dc66..6ddc1a6 100644
--- a/arch/arm/mach-at91/include/mach/gpio.h
+++ b/arch/arm/mach-at91/include/mach/gpio.h
@@ -214,11 +214,8 @@ extern void at91_gpio_resume(void);
*/
#include asm/errno.h
-#include asm-generic/gpio.h /* cansleep wrappers */
-#define gpio_get_value __gpio_get_value
-#define gpio_set_value __gpio_set_value
-#define gpio_cansleep __gpio_cansleep
+#define __ARM_GPIOLIB_TRIVIAL
#define gpio_to_irq(gpio) (gpio)
#define irq_to_gpio(irq) (irq)
diff --git a/arch/arm/mach-ep93xx/include/mach/gpio.h
b/arch/arm/mach-ep93xx/include/mach/gpio.h
index c57152c..fbc770e 100644
--- a/arch/arm/mach-ep93xx/include/mach/gpio.h
+++ b/arch/arm/mach-ep93xx/include/mach/gpio.h
@@ -100,12 +100,7 @@
#define EP93XX_GPIO_LINE_MAX_IRQ EP93XX_GPIO_LINE_F(7)
/* new generic GPIO API - see Documentation/gpio.txt */
-
-#include asm-generic/gpio.h
-
-#define gpio_get_value __gpio_get_value
-#define gpio_set_value __gpio_set_value
-#define gpio_cansleep __gpio_cansleep
+#define __ARM_GPIOLIB_TRIVIAL
/*
* Map GPIO A0..A7 (0..7) to irq 64..71,
diff --git a/arch/arm/mach-exynos4/include/mach/gpio.h
b/arch/arm/mach-exynos4/include/mach/gpio.h
index be9266b..b2e3595 100644
--- a/arch/arm/mach-exynos4/include/mach/gpio.h
+++ b/arch/arm/mach-exynos4/include/mach/gpio.h
@@ -13,9 +13,6 @@
#ifndef __ASM_ARCH_GPIO_H
#define __ASM_ARCH_GPIO_H __FILE__
-#define gpio_get_value __gpio_get_value
-#define gpio_set_value __gpio_set_value
-#define gpio_cansleep __gpio_cansleep
#define gpio_to_irq__gpio_to_irq
/* Practically, GPIO banks up to GPZ are the configurable gpio banks */
@@ -151,6 +148,6 @@ enum s5p_gpio_number {
#define ARCH_NR_GPIOS (EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) + \
CONFIG_SAMSUNG_GPIO_EXTRA + 1)
-#include asm-generic/gpio.h
+#define __ARM_GPIOLIB_TRIVIAL
#endif /* __ASM_ARCH_GPIO_H */
diff --git a/arch/arm/mach-gemini/include/mach/gpio.h
b/arch/arm/mach-gemini/include/mach/gpio.h
index 3bc2c70..20c0a36 100644
--- a/arch/arm/mach-gemini/include/mach/gpio.h
+++ b/arch/arm/mach-gemini/include/mach/gpio.h
@@ -13,11 +13,8 @@
#define __MACH_GPIO_H__
#include mach/irqs.h
-#include asm-generic/gpio.h
-#define gpio_get_value __gpio_get_value
-#define gpio_set_value __gpio_set_value
-#define gpio_cansleep __gpio_cansleep
+#define __ARM_GPIOLIB_TRIVIAL
#define gpio_to_irq(x)
[PATCH 12/13] ARM: gpio: consolidate gpio_to_irq
Many of the gpio_to_irq implementations use the gpiolib version of this
function. Provide the standard gpiolib gpio_to_irq() for everyone, but
allow platforms to override it if they wish. Add the neccessary
overrides for those platforms which do not use the standard definition.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/gpio.h |9 +
arch/arm/mach-davinci/include/mach/gpio.h |5 -
arch/arm/mach-exynos4/include/mach/gpio.h |2 --
arch/arm/mach-ixp4xx/include/mach/gpio.h|1 +
arch/arm/mach-ks8695/include/mach/gpio.h|2 --
arch/arm/mach-lpc32xx/include/mach/gpio.h |5 -
arch/arm/mach-msm/include/mach/gpio.h |2 --
arch/arm/mach-mxs/include/mach/gpio.h |1 -
arch/arm/mach-realview/include/mach/gpio.h |1 -
arch/arm/mach-s3c2410/include/mach/gpio.h |1 -
arch/arm/mach-s3c64xx/include/mach/gpio.h |1 -
arch/arm/mach-s5p64x0/include/mach/gpio.h |1 -
arch/arm/mach-s5pc100/include/mach/gpio.h |1 -
arch/arm/mach-s5pv210/include/mach/gpio.h |1 -
arch/arm/mach-shmobile/include/mach/gpio.h |5 -
arch/arm/mach-tegra/include/mach/gpio.h |1 +
arch/arm/mach-u300/include/mach/gpio.h |1 +
arch/arm/mach-versatile/include/mach/gpio.h |1 -
arch/arm/mach-vt8500/include/mach/gpio.h|1 -
arch/arm/mach-w90x900/include/mach/gpio.h |1 +
arch/arm/plat-nomadik/include/plat/gpio.h |1 -
arch/arm/plat-omap/include/plat/gpio.h |5 -
arch/arm/plat-orion/include/plat/gpio.h |5 -
arch/arm/plat-spear/include/plat/gpio.h |1 -
24 files changed, 13 insertions(+), 42 deletions(-)
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 15e8970..5032224 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -14,4 +14,13 @@
#define gpio_cansleep __gpio_cansleep
#endif
+/*
+ * Provide a default gpio_to_irq() which should satisfy every case.
+ * However, some platforms want to do this differently, so allow them
+ * to override it.
+ */
+#ifndef gpio_to_irq
+#define gpio_to_irq__gpio_to_irq
+#endif
+
#endif /* _ARCH_ARM_GPIO_H */
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h
b/arch/arm/mach-davinci/include/mach/gpio.h
index fbece12..73fc7a0 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -147,11 +147,6 @@ static inline int gpio_cansleep(unsigned gpio)
return __gpio_cansleep(gpio);
}
-static inline int gpio_to_irq(unsigned gpio)
-{
- return __gpio_to_irq(gpio);
-}
-
static inline int irq_to_gpio(unsigned irq)
{
/* don't support the reverse mapping */
diff --git a/arch/arm/mach-exynos4/include/mach/gpio.h
b/arch/arm/mach-exynos4/include/mach/gpio.h
index b2e3595..b91e8b2 100644
--- a/arch/arm/mach-exynos4/include/mach/gpio.h
+++ b/arch/arm/mach-exynos4/include/mach/gpio.h
@@ -13,8 +13,6 @@
#ifndef __ASM_ARCH_GPIO_H
#define __ASM_ARCH_GPIO_H __FILE__
-#define gpio_to_irq__gpio_to_irq
-
/* Practically, GPIO banks up to GPZ are the configurable gpio banks */
/* GPIO bank sizes */
diff --git a/arch/arm/mach-ixp4xx/include/mach/gpio.h
b/arch/arm/mach-ixp4xx/include/mach/gpio.h
index a5f87de..19009bf 100644
--- a/arch/arm/mach-ixp4xx/include/mach/gpio.h
+++ b/arch/arm/mach-ixp4xx/include/mach/gpio.h
@@ -70,6 +70,7 @@ static inline void gpio_set_value(unsigned gpio, int value)
#include asm-generic/gpio.h /* cansleep wrappers */
extern int gpio_to_irq(int gpio);
+#define gpio_to_irq gpio_to_irq
extern int irq_to_gpio(unsigned int irq);
#endif
diff --git a/arch/arm/mach-ks8695/include/mach/gpio.h
b/arch/arm/mach-ks8695/include/mach/gpio.h
index c13952c..59d6b53 100644
--- a/arch/arm/mach-ks8695/include/mach/gpio.h
+++ b/arch/arm/mach-ks8695/include/mach/gpio.h
@@ -40,8 +40,6 @@ extern int ks8695_gpio_interrupt(unsigned int pin, unsigned
int type);
*/
extern int irq_to_gpio(unsigned int irq);
-#define gpio_to_irq __gpio_to_irq
-
#define __ARM_GPIOLIB_TRIVIAL
/* Register the GPIOs */
diff --git a/arch/arm/mach-lpc32xx/include/mach/gpio.h
b/arch/arm/mach-lpc32xx/include/mach/gpio.h
index 0ca6c27..b01cd24 100644
--- a/arch/arm/mach-lpc32xx/include/mach/gpio.h
+++ b/arch/arm/mach-lpc32xx/include/mach/gpio.h
@@ -51,9 +51,4 @@
#define __ARM_GPIOLIB_TRIVIAL
-static inline int gpio_to_irq(unsigned gpio)
-{
- return __gpio_to_irq(gpio);
-}
-
#endif
diff --git a/arch/arm/mach-msm/include/mach/gpio.h
b/arch/arm/mach-msm/include/mach/gpio.h
index bc75e20..10197a9 100644
--- a/arch/arm/mach-msm/include/mach/gpio.h
+++ b/arch/arm/mach-msm/include/mach/gpio.h
@@ -18,6 +18,4 @@
#define __ARM_GPIOLIB_TRIVIAL
-#define gpio_to_irq __gpio_to_irq
-
#endif /* __ASM_ARCH_MSM_GPIO_H */
diff --git a/arch/arm/mach-mxs/include/mach/gpio.h
b/arch/arm/mach-mxs/include/mach/gpio.h
index bb44c8d..bf28a1f 100644
[PATCH 13/13] ARM: gpio: make trivial GPIOLIB implementation the default
Rather than marking the mach/gpio.h header files which want to use the
trivial GPIOLIB implementation, mark those which do not want to use it
instead. This means that by default, you get the trivial implementation
and only have to do something extra if you need to. This should
encourage the use of the trivial default implementation.
As an additional bonus, several gpio.h header files become empty.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/gpio.h |2 +-
arch/arm/include/asm/hardware/iop3xx-gpio.h |2 ++
arch/arm/mach-at91/include/mach/gpio.h |2 --
arch/arm/mach-davinci/include/mach/gpio.h |2 ++
arch/arm/mach-ep93xx/include/mach/gpio.h|3 ---
arch/arm/mach-exynos4/include/mach/gpio.h |2 --
arch/arm/mach-gemini/include/mach/gpio.h|2 --
arch/arm/mach-ixp4xx/include/mach/gpio.h|2 ++
arch/arm/mach-ks8695/include/mach/gpio.h|2 --
arch/arm/mach-lpc32xx/include/mach/gpio.h |2 --
arch/arm/mach-msm/include/mach/gpio.h | 22 +-
arch/arm/mach-mxs/include/mach/gpio.h |3 ---
arch/arm/mach-realview/include/mach/gpio.h |2 +-
arch/arm/mach-s3c2410/include/mach/gpio.h |2 --
arch/arm/mach-s3c64xx/include/mach/gpio.h |2 --
arch/arm/mach-s5p64x0/include/mach/gpio.h |2 --
arch/arm/mach-s5pc100/include/mach/gpio.h |2 --
arch/arm/mach-s5pv210/include/mach/gpio.h |2 --
arch/arm/mach-sa1100/include/mach/gpio.h|2 ++
arch/arm/mach-shmobile/include/mach/gpio.h |6 --
arch/arm/mach-tegra/include/mach/gpio.h |2 --
arch/arm/mach-u300/include/mach/gpio.h |2 ++
arch/arm/mach-versatile/include/mach/gpio.h |2 +-
arch/arm/mach-vt8500/include/mach/gpio.h|2 +-
arch/arm/mach-w90x900/include/mach/gpio.h |2 --
arch/arm/plat-mxc/include/mach/gpio.h |3 ---
arch/arm/plat-nomadik/include/plat/gpio.h |2 --
arch/arm/plat-omap/include/plat/gpio.h |2 --
arch/arm/plat-orion/include/plat/gpio.h |2 --
arch/arm/plat-pxa/include/plat/gpio.h |2 ++
arch/arm/plat-spear/include/plat/gpio.h | 20 +---
31 files changed, 22 insertions(+), 85 deletions(-)
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 5032224..11ad0bf 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -4,7 +4,7 @@
/* not all ARM platforms necessarily support this API ... */
#include mach/gpio.h
-#ifdef __ARM_GPIOLIB_TRIVIAL
+#ifndef __ARM_GPIOLIB_COMPLEX
/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
#include asm-generic/gpio.h
diff --git a/arch/arm/include/asm/hardware/iop3xx-gpio.h
b/arch/arm/include/asm/hardware/iop3xx-gpio.h
index b69d972..9eda7dc 100644
--- a/arch/arm/include/asm/hardware/iop3xx-gpio.h
+++ b/arch/arm/include/asm/hardware/iop3xx-gpio.h
@@ -28,6 +28,8 @@
#include mach/hardware.h
#include asm-generic/gpio.h
+#define __ARM_GPIOLIB_COMPLEX
+
#define IOP3XX_N_GPIOS 8
static inline int gpio_get_value(unsigned gpio)
diff --git a/arch/arm/mach-at91/include/mach/gpio.h
b/arch/arm/mach-at91/include/mach/gpio.h
index 6ddc1a6..2b9a1f5 100644
--- a/arch/arm/mach-at91/include/mach/gpio.h
+++ b/arch/arm/mach-at91/include/mach/gpio.h
@@ -215,8 +215,6 @@ extern void at91_gpio_resume(void);
#include asm/errno.h
-#define __ARM_GPIOLIB_TRIVIAL
-
#define gpio_to_irq(gpio) (gpio)
#define irq_to_gpio(irq) (irq)
diff --git a/arch/arm/mach-davinci/include/mach/gpio.h
b/arch/arm/mach-davinci/include/mach/gpio.h
index 73fc7a0..14e7bb20 100644
--- a/arch/arm/mach-davinci/include/mach/gpio.h
+++ b/arch/arm/mach-davinci/include/mach/gpio.h
@@ -21,6 +21,8 @@
#include mach/irqs.h
#include mach/common.h
+#define __ARM_GPIOLIB_COMPLEX
+
#define DAVINCI_GPIO_BASE 0x01C67000
enum davinci_gpio_type {
diff --git a/arch/arm/mach-ep93xx/include/mach/gpio.h
b/arch/arm/mach-ep93xx/include/mach/gpio.h
index fbc770e..071f676 100644
--- a/arch/arm/mach-ep93xx/include/mach/gpio.h
+++ b/arch/arm/mach-ep93xx/include/mach/gpio.h
@@ -99,9 +99,6 @@
/* maximum value for irq capable line identifiers */
#define EP93XX_GPIO_LINE_MAX_IRQ EP93XX_GPIO_LINE_F(7)
-/* new generic GPIO API - see Documentation/gpio.txt */
-#define __ARM_GPIOLIB_TRIVIAL
-
/*
* Map GPIO A0..A7 (0..7) to irq 64..71,
* B0..B7 (7..15) to irq 72..79, and
diff --git a/arch/arm/mach-exynos4/include/mach/gpio.h
b/arch/arm/mach-exynos4/include/mach/gpio.h
index b91e8b2..80523ca 100644
--- a/arch/arm/mach-exynos4/include/mach/gpio.h
+++ b/arch/arm/mach-exynos4/include/mach/gpio.h
@@ -146,6 +146,4 @@ enum s5p_gpio_number {
#define ARCH_NR_GPIOS (EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) + \
CONFIG_SAMSUNG_GPIO_EXTRA + 1)
-#define __ARM_GPIOLIB_TRIVIAL
-
#endif /* __ASM_ARCH_GPIO_H */
diff --git a/arch/arm/mach-gemini/include/mach/gpio.h
How to handle named resources with DT?
Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. Do you have any plan to add that, or do you have any clean way to avoid that without having to use the resource index? Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] Clean up mach/gpio.h headers
Hi Russell, On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote: This is a preliminary posting of my gpio patch set. This patch series moves the trivial gpiolib implementations out of mach/gpio.h and into asm/gpio.h. As a side effect of that, most of this patch series is about fixing up direct includes of mach/gpio.h - this is something I've been on at people over the last year or more about ensuring that they use linux/gpio.h in preference. While I've blindly converted all arch/arm to use linux/gpio.h (with the exception of mach/ includes which are converted to asm/gpio.h), drivers were only converted to asm/gpio.h. These should be reviewed and changed to linux/gpio.h. As a result of this patch series, several mach/gpio.h end up being empty. Nice series! This gives me an empty gpio.h for picoxcell. Tested-by: Jamie Iles ja...@jamieiles.com Jamie -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP: misc. PM-related fixes for v3.1-rc
* Kevin Hilman khil...@ti.com [110804 08:38]: Hi Tony, Here's my current collection of PM-related fixes for the -rc cycle. They are based on the next/board branch of Arnd's arm-soc tree (which has already been merged by Linus) and are also available in the for_3.1/pm-fixes branch of my tree: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Thanks, based on your comment looks like you want to modify at least one of them. I'll pick the ones that should get merged immediately while you're on vacation. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 kernels fail to build
Hi Russel, On Monday 08 August 2011 13:00:56 Russell King - ARM Linux wrote: With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this: arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend' This is probably from twl-common.c, which doesn't really look very common to me (looks like some is specific to OMAP3 and the rest is OMAP4 specific.) As this is always built for all OMAP2+, this will also break OMAP2 as well. Why it's even built on OMAP2, I've no idea. I'm sure if you have it other way around (OMAP4=y, OMAP3=n) will fail as well, but differently... I think the OMAP3 specific bits should be separate from the OMAP4 specific bits, which should be separate from the small amount of common stuff. Is it acceptable if I use #if defined(CONFIG_ARCH_OMAP3), and #if defined(CONFIG_ARCH_OMAP4) to protect the OMAP3 and OMAP4 related code in the twl-common.c? -- Péter -- To unsubscribe from this list: send the line unsubscribe 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: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
Hi, On Mon, 2011-06-06 at 14:05 +0300, Luciano Coelho wrote: On Mon, 2011-06-06 at 14:02 +0300, Felipe Balbi wrote: On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote: looks like this is resulting from the missing hwmod conversion in mainlnie. Check if reverting 7e6502d577106fb5b202bbaac64c5f1b065e6daa helps. I verified off-list with Luca that reverting that commit does make it work. Keshava, care to send a revert patch to Sam until we get all the hwmod stuff in. Yes, I confirm that I'm not getting the oops anymore, after reverting this patch. Thanks a lot for the quick answer, dude! :) I'm again getting a very similar oops with 3.1-rc1 on my pandaboard: [2.054351] usbcore: registered new interface driver cdc_ncm [2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [2.068664] Unhandled fault: imprecise external abort (0x1406) at 0x [2.076110] Internal error: : 1406 [#1] SMP [2.080505] Modules linked in: [2.083709] CPU: 0Not tainted (3.1.0-rc1-wl+ #283) [2.089233] PC is at omap_usbhs_enable+0x148/0x590 [2.094299] LR is at trace_hardirqs_off+0x14/0x18 [2.099243] pc : [c02a8640]lr : [c007fea0]psr: 6093 [2.099243] sp : df871dc8 ip : df871d80 fp : df871dec [2.111328] r10: 8013 r9 : df9ef9e0 r8 : df9ef9ec [2.116821] r7 : dfa32800 r6 : dfa316f8 r5 : c06f5da8 r4 : dfa316a0 [2.123687] r3 : r2 : r1 : 0001 r0 : [2.130584] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [2.138366] Control: 10c53c7d Table: 8000404a DAC: 0015 [2.144409] Process swapper (pid: 1, stack limit = 0xdf8702f8) [2.150543] Stack: (0xdf871dc8 to 0xdf872000) [2.155120] 1dc0: df105400 dfa32808 df105400 dfa32800 df9ef9ec 0003 [2.163726] 1de0: df871e8c df871df0 c0321d60 c02a8504 df871e2c df10a588 df1075a0 df10a588 [2.172363] 1e00: df871e2c df871e10 df10a588 df10a608 dfa28e88 006d fc064c00 [2.180969] 1e20: df871e6c df871e30 c015654c c0155c08 c0082098 c0071f74 0001 dfa32898 [2.189575] 1e40: dfa28e88 dfa32808 dfa32810 73757368 3062 [2.198181] 1e60: df871e7c dfa32808 c0716da8 c0716da8 [2.206787] 1e80: df871e9c df871e90 c0298cfc c0321bb8 df871ec4 df871ea0 c0297650 c0298ce4 [2.215423] 1ea0: df871ec4 dfa32808 dfa3283c dfa32808 dfa3283c c0716da8 df871ee4 df871ec8 [2.224029] 1ec0: c02977ec c0297504 c0716da8 c0297774 df871f0c df871ee8 [2.232635] 1ee0: c0296c00 c0297780 df891658 dfa31670 c023ac60 c0716da8 df1075a0 c070d6f8 [2.241241] 1f00: df871f1c df871f10 c0297334 c0296bb0 df871f4c df871f20 c02963ec c0297318 [2.249847] 1f20: c05b84a8 df871f30 c0716da8 c0c7e4c0 c0014ba0 [2.258483] 1f40: df871f74 df871f50 c0297f00 c0296320 c0298d44 c0c7df14 c0c7e4c0 c0014ba0 [2.267089] 1f60: df871f84 df871f78 c02991e0 c0297e54 df871fa4 df871f88 [2.275695] 1f80: c069904c c0299198 00a0 0060 c06c4e40 c0698fa4 df871fdc df871fa8 [2.284301] 1fa0: c0008854 c0698fb0 c0014ba0 c009960c df871fdc df871fc0 c06c4e40 c06c49dc [2.292907] 1fc0: c0014ba0 0013 df871ff4 df871fe0 c06792d4 c00087b8 [2.301513] 1fe0: c067924c df871ff8 c0014ba0 c0679258 882bf20f 3184000e [2.310150] [c02a8640] (omap_usbhs_enable+0x148/0x590) from [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) [2.320526] [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) from [c0298cfc] (platform_drv_probe+0x24/0x28) [2.330780] [c0298cfc] (platform_drv_probe+0x24/0x28) from [c0297650] (driver_probe_device+0x158/0x27c) [2.341033] [c0297650] (driver_probe_device+0x158/0x27c) from [c02977ec] (__driver_attach+0x78/0x9c) [2.351043] [c02977ec] (__driver_attach+0x78/0x9c) from [c0296c00] (bus_for_each_dev+0x5c/0x8c) [2.360565] [c0296c00] (bus_for_each_dev+0x5c/0x8c) from [c0297334] (driver_attach+0x28/0x30) [2.369903] [c0297334] (driver_attach+0x28/0x30) from [c02963ec] (bus_add_driver+0xd8/0x260) [2.379180] [c02963ec] (bus_add_driver+0xd8/0x260) from [c0297f00] (driver_register+0xb8/0x144) [2.388702] [c0297f00] (driver_register+0xb8/0x144) from [c02991e0] (platform_driver_register+0x54/0x68) [2.399047] [c02991e0] (platform_driver_register+0x54/0x68) from [c069904c] (ehci_hcd_init+0xa8/0xfc) [2.409149] [c069904c] (ehci_hcd_init+0xa8/0xfc) from [c0008854] (do_one_initcall+0xa8/0x17c) [2.418487] [c0008854] (do_one_initcall+0xa8/0x17c) from [c06792d4] (kernel_init+0x88/0x134) [2.427764] [c06792d4] (kernel_init+0x88/0x134) from [c0014ba0] (kernel_thread_exit+0x0/0x8) [2.437011] Code: e59f0414 e1a01005 e59f2424 ebffac8d (e594303c) This seems to be very similar (if not identical) to the oops I was getting before (with 3.0-rc2). I checked the git log and the revert
Re: [PATCH 06/13] ARM: gpio: davinci: convert drivers to use asm/gpio.h rather than mach/gpio.h
Hello. On 09-08-2011 12:06, Russell King - ARM Linux wrote: CCing linux-usb and Felipe... Signed-off-by: Russell Kingrmk+ker...@arm.linux.org.uk --- drivers/usb/musb/davinci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 8bdf25a..f9a3f62 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -35,7 +35,7 @@ #includemach/hardware.h #includemach/memory.h -#includemach/gpio.h +#includeasm/gpio.h Shouldn't this now be moved to the below #include group? #includemach/cputype.h #includeasm/mach-types.h 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
[PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds
Avoid compiling code for OMAP arch which is not selected by the
config.
Fixes issues like:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
`omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to
`omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to
`omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to
`omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to
`omap4430_phy_suspend'
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Hi Russel, Tony,
This patch fixes the linking error caused by the twl-common.c file,
when the kernel is built for OMAP2/3/4 only.
Regards,
Peter
---
arch/arm/mach-omap2/twl-common.c | 78 --
1 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 2543342..daa056e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,14 +48,7 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, pmic_i2c_board_info, 1);
}
-static struct twl4030_usb_data omap4_usb_pdata = {
- .phy_init = omap4430_phy_init,
- .phy_exit = omap4430_phy_exit,
- .phy_power = omap4430_phy_power,
- .phy_set_clock = omap4430_phy_set_clk,
- .phy_suspend= omap4430_phy_suspend,
-};
-
+#if defined(CONFIG_ARCH_OMAP3)
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -122,6 +115,45 @@ static struct regulator_init_data omap3_vpll2_idata = {
.consumer_supplies = omap3_vpll2_supplies,
};
+void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
+ u32 pdata_flags, u32 regulators_flags)
+{
+ if (!pmic_data-irq_base)
+ pmic_data-irq_base = TWL4030_IRQ_BASE;
+ if (!pmic_data-irq_end)
+ pmic_data-irq_end = TWL4030_IRQ_END;
+
+ /* Common platform data configurations */
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ pmic_data-usb = omap3_usb_pdata;
+
+ if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
+ pmic_data-bci = omap3_bci_pdata;
+
+ if (pdata_flags TWL_COMMON_PDATA_MADC !pmic_data-madc)
+ pmic_data-madc = omap3_madc_pdata;
+
+ if (pdata_flags TWL_COMMON_PDATA_AUDIO !pmic_data-audio)
+ pmic_data-audio = omap3_audio_pdata;
+
+ /* Common regulator configurations */
+ if (regulators_flags TWL_COMMON_REGULATOR_VDAC !pmic_data-vdac)
+ pmic_data-vdac = omap3_vdac_idata;
+
+ if (regulators_flags TWL_COMMON_REGULATOR_VPLL2 !pmic_data-vpll2)
+ pmic_data-vpll2 = omap3_vpll2_idata;
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP4)
+static struct twl4030_usb_data omap4_usb_pdata = {
+ .phy_init = omap4430_phy_init,
+ .phy_exit = omap4430_phy_exit,
+ .phy_power = omap4430_phy_power,
+ .phy_set_clock = omap4430_phy_set_clk,
+ .phy_suspend= omap4430_phy_suspend,
+};
+
static struct regulator_init_data omap4_vdac_idata = {
.constraints = {
.min_uV = 180,
@@ -273,32 +305,4 @@ void __init omap4_pmic_get_config(struct
twl4030_platform_data *pmic_data,
!pmic_data-clk32kg)
pmic_data-clk32kg = omap4_clk32kg_idata;
}
-
-void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
- u32 pdata_flags, u32 regulators_flags)
-{
- if (!pmic_data-irq_base)
- pmic_data-irq_base = TWL4030_IRQ_BASE;
- if (!pmic_data-irq_end)
- pmic_data-irq_end = TWL4030_IRQ_END;
-
- /* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
- pmic_data-usb = omap3_usb_pdata;
-
- if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
- pmic_data-bci = omap3_bci_pdata;
-
- if (pdata_flags TWL_COMMON_PDATA_MADC !pmic_data-madc)
- pmic_data-madc = omap3_madc_pdata;
-
- if (pdata_flags TWL_COMMON_PDATA_AUDIO !pmic_data-audio)
- pmic_data-audio = omap3_audio_pdata;
-
- /* Common regulator configurations */
- if (regulators_flags TWL_COMMON_REGULATOR_VDAC !pmic_data-vdac)
- pmic_data-vdac = omap3_vdac_idata;
-
- if (regulators_flags TWL_COMMON_REGULATOR_VPLL2 !pmic_data-vpll2)
- pmic_data-vpll2 = omap3_vpll2_idata;
-}
+#endif /* CONFIG_ARCH_OMAP4 */
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: Re: Build failure: bisected: v3.1-rc1 with config ARCH_OMAP !ARCH_OMAP4 fails with linker error
Hi Tony, Paul, On Tuesday 09 August 2011 15:14:53 Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [110808 13:31]: Hi On Mon, 8 Aug 2011, Daniel Morsing wrote: Building the v3.1-rc1 kernel with ARCH_OMAP !ARCH_OMAP4 support fails on linking with the following error ... LD .tmp_vmlinux1 arch/arm/mach-omap2/built-in.o:(.data+0xf7d8): undefined reference to `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf7dc): undefined reference to `omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0xf7e0): undefined reference to `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf7e4): undefined reference to `omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0xf7e8): undefined reference to `omap4430_phy_suspend' I've bisected the first bad commit to OMAP4: Move common twl6030 configuration to twl-common (commit-id b22f954bae35be115a10c6426dc070f7d652b32e). The problem seems to be unconditionally taking a function pointer to an omap4430 specific function in arch/arm/mach-omap2/twl-common.c. The definition for omap4430_phy_init and friends is in arch/arm/mach-omap2/omap_phy_internal.c, which is only compiled when building with support for one of the omap4430 boards. Thanks for the bisect; this should be fixed by https://patchwork.kernel.org/patch/963462/ Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected: arch/arm/mach-omap2/built-in.o: In function `_enable_module': arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to `omap4_cminst_module_enable' arch/arm/mach-omap2/built-in.o: In function `_disable_module': arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to `omap4_cminst_module_disable' arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable': arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to `omap4_cminst_wait_module_idle' distcc[27594] ERROR: compile (null) on localhost failed make: *** [.tmp_vmlinux1] Error 1 Care to take a look? I just sent a patch fixing this: http://marc.info/?l=linux-omapm=131289342114258w=2 -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support
This is in continuation of patch series posted at: http://lwn.net/Articles/451917/ Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from omap_device. [There is latest version posted which will be rebased later] Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely grant.lik...@secretlab.ca However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call. Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week. git://git.secretlab.ca/git/linux-2.6.git Branch: devicetree/test-3.0 G, Manjunath Kondaiah (6): dt: omap: prepare hwmod to support dt dt: Add pd_size to AUXDATA structure dt: omap3: add soc file for handling i2c controllers dt: omap3: beagle board: set clock freq for i2c devices dt: omap3: add generic board file for dt support dt: omap3: enable dt support for i2c1 controller Kevin Hilman (7): OMAP: omap_device: replace _find_by_pdev() with to_omap_device() OMAP: omap_device: replace debug/warning/error prints with dev_* macros OMAP3: beagle: don't touch omap_device internals OMAP: McBSP: use existing macros for converting between devices OMAP: omap_device: remove internal functions from omap_device.h OMAP: omap_device: when building return platform_device instead of omap_device ARM: platform_device: pdev_archdata: add omap_device pointer Tony Lindgren (1): omap2+: Use Kconfig symbol in Makefile instead of obj-y arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +-- arch/arm/boot/dts/omap3-beagle.dts| 18 +++- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++ arch/arm/include/asm/device.h |5 + arch/arm/mach-omap2/Kconfig | 11 ++ arch/arm/mach-omap2/Makefile | 77 ++--- arch/arm/mach-omap2/board-omap3-dt.c | 93 +++ arch/arm/mach-omap2/board-omap3beagle.c | 40 ++- arch/arm/mach-omap2/devices.c | 44 arch/arm/mach-omap2/display.c |6 +- arch/arm/mach-omap2/dma.c | 16 ++-- arch/arm/mach-omap2/gpio.c|8 +- arch/arm/mach-omap2/hsmmc.c |8 +- arch/arm/mach-omap2/hwspinlock.c |8 +- arch/arm/mach-omap2/mcbsp.c |8 +- arch/arm/mach-omap2/pm.c |8 +- arch/arm/mach-omap2/serial.c | 12 +- arch/arm/plat-omap/i2c.c |8 +- arch/arm/plat-omap/include/plat/omap_device.h | 17 ++- arch/arm/plat-omap/mcbsp.c|6 +- arch/arm/plat-omap/omap_device.c | 150 - drivers/i2c/busses/i2c-omap.c | 23 - drivers/of/platform.c | 41 +++ include/linux/of_platform.h |5 + 24 files changed, 469 insertions(+), 216 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi create mode 100644 arch/arm/mach-omap2/board-omap3-dt.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
[RFC/PATCH 01/14] OMAP: omap_device: replace _find_by_pdev() with to_omap_device()
From: Kevin Hilman khil...@ti.com
The omap_device layer currently has two ways of getting an omap_device
pointer from a platform_device pointer.
Replace current usage of _find_by_pdev() with to_omap_device() since
to_omap_device() is more familiar to the existing to_platform_device()
used when getting a platform_device pointer from a struct device pointer.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/plat-omap/omap_device.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 49fc0df..c8b9cd1 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -236,11 +236,6 @@ static int _omap_device_deactivate(struct omap_device *od,
u8 ignore_lat)
return 0;
}
-static inline struct omap_device *_find_by_pdev(struct platform_device *pdev)
-{
- return container_of(pdev, struct omap_device, pdev);
-}
-
/**
* _add_optional_clock_clkdev - Add clkdev entry for hwmod optional clocks
* @od: struct omap_device *od
@@ -316,7 +311,7 @@ u32 omap_device_get_context_loss_count(struct
platform_device *pdev)
struct omap_device *od;
u32 ret = 0;
- od = _find_by_pdev(pdev);
+ od = to_omap_device(pdev);
if (od-hwmods_cnt)
ret = omap_hwmod_get_context_loss_count(od-hwmods[0]);
@@ -611,7 +606,7 @@ int omap_device_enable(struct platform_device *pdev)
int ret;
struct omap_device *od;
- od = _find_by_pdev(pdev);
+ od = to_omap_device(pdev);
if (od-_state == OMAP_DEVICE_STATE_ENABLED) {
WARN(1, omap_device: %s.%d: %s() called from invalid state
%d\n,
@@ -650,7 +645,7 @@ int omap_device_idle(struct platform_device *pdev)
int ret;
struct omap_device *od;
- od = _find_by_pdev(pdev);
+ od = to_omap_device(pdev);
if (od-_state != OMAP_DEVICE_STATE_ENABLED) {
WARN(1, omap_device: %s.%d: %s() called from invalid state
%d\n,
@@ -681,7 +676,7 @@ int omap_device_shutdown(struct platform_device *pdev)
int ret, i;
struct omap_device *od;
- od = _find_by_pdev(pdev);
+ od = to_omap_device(pdev);
if (od-_state != OMAP_DEVICE_STATE_ENABLED
od-_state != OMAP_DEVICE_STATE_IDLE) {
@@ -722,7 +717,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
int ret = -EINVAL;
struct omap_device *od;
- od = _find_by_pdev(pdev);
+ od = to_omap_device(pdev);
if (new_wakeup_lat_limit == od-dev_wakeup_lat)
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
[RFC/PATCH 02/14] OMAP: omap_device: replace debug/warning/error prints with dev_* macros
From: Kevin Hilman khil...@ti.com
For consistency in kernel printk output for devices, use dev_dbg(),
dev_warn(), dev_err() instead of pr_debug(), pr_warning() and
pr_err(), some of which currently use direct access of name from
platform_device and others of which use dev_name(). Using the dev_*
versions uses the standard device naming from the driver core.
Some pr_* prints were not converted with this patch since they are
used before the platform_device and struct device are created so
neither the dev_* prints or dev_name() is valid.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 70 +++---
1 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c8b9cd1..1d69596 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -114,7 +114,7 @@ static int _omap_device_activate(struct omap_device *od, u8
ignore_lat)
{
struct timespec a, b, c;
- pr_debug(omap_device: %s: activating\n, od-pdev.name);
+ dev_dbg(od-pdev.dev, omap_device: activating\n);
while (od-pm_lat_level 0) {
struct omap_device_pm_latency *odpl;
@@ -138,25 +138,24 @@ static int _omap_device_activate(struct omap_device *od,
u8 ignore_lat)
c = timespec_sub(b, a);
act_lat = timespec_to_ns(c);
- pr_debug(omap_device: %s: pm_lat %d: activate: elapsed time
-%llu nsec\n, od-pdev.name, od-pm_lat_level,
-act_lat);
+ dev_dbg(od-pdev.dev,
+ omap_device: pm_lat %d: activate: elapsed time
+ %llu nsec\n, od-pm_lat_level, act_lat);
if (act_lat odpl-activate_lat) {
odpl-activate_lat_worst = act_lat;
if (odpl-flags OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
odpl-activate_lat = act_lat;
- pr_warning(omap_device: %s.%d: new worst case
- activate latency %d: %llu\n,
- od-pdev.name, od-pdev.id,
- od-pm_lat_level, act_lat);
+ dev_warn(od-pdev.dev,
+new worst case activate latency
+%d: %llu\n,
+od-pm_lat_level, act_lat);
} else
- pr_warning(omap_device: %s.%d: activate
- latency %d higher than exptected.
- (%llu %d)\n,
- od-pdev.name, od-pdev.id,
- od-pm_lat_level, act_lat,
- odpl-activate_lat);
+ dev_warn(od-pdev.dev,
+activate latency %d
+higher than exptected. (%llu %d)\n,
+od-pm_lat_level, act_lat,
+odpl-activate_lat);
}
od-dev_wakeup_lat -= odpl-activate_lat;
@@ -183,7 +182,7 @@ static int _omap_device_deactivate(struct omap_device *od,
u8 ignore_lat)
{
struct timespec a, b, c;
- pr_debug(omap_device: %s: deactivating\n, od-pdev.name);
+ dev_dbg(od-pdev.dev, omap_device: deactivating\n);
while (od-pm_lat_level od-pm_lats_cnt) {
struct omap_device_pm_latency *odpl;
@@ -206,28 +205,26 @@ static int _omap_device_deactivate(struct omap_device
*od, u8 ignore_lat)
c = timespec_sub(b, a);
deact_lat = timespec_to_ns(c);
- pr_debug(omap_device: %s: pm_lat %d: deactivate: elapsed time
-%llu nsec\n, od-pdev.name, od-pm_lat_level,
-deact_lat);
+ dev_dbg(od-pdev.dev,
+ omap_device: pm_lat %d: deactivate: elapsed time
+ %llu nsec\n, od-pm_lat_level, deact_lat);
if (deact_lat odpl-deactivate_lat) {
odpl-deactivate_lat_worst = deact_lat;
if (odpl-flags OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
odpl-deactivate_lat = deact_lat;
- pr_warning(omap_device: %s.%d: new worst case
- deactivate latency %d: %llu\n,
- od-pdev.name, od-pdev.id,
- od-pm_lat_level, deact_lat);
+
[RFC/PATCH 03/14] OMAP3: beagle: don't touch omap_device internals
From: Kevin Hilman khil...@ti.com
Board code should not touch omap_device internals. To get the MPU/IVA devices,
use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 27 ---
1 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 213c4cd..7905c8d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -529,25 +529,24 @@ static void __init beagle_opp_init(void)
return;
}
- /* Custom OPP enabled for XM */
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- struct omap_hwmod *mh = omap_hwmod_lookup(mpu);
- struct omap_hwmod *dh = omap_hwmod_lookup(iva);
- struct device *dev;
+ /* Custom OPP enabled for all xM versions */
+ if (cpu_is_omap3630()) {
+ struct device *mpu_dev, *iva_dev;
+
+ mpu_dev = omap2_get_mpuss_device();
+ iva_dev = omap2_get_iva_device();
- if (!mh || !dh) {
+ if (!mpu_dev || !iva_dev) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
- __func__, mh, dh);
+ __func__, mpu_dev, iva_dev);
return;
}
/* Enable MPU 1GHz and lower opps */
- dev = mh-od-pdev.dev;
- r = opp_enable(dev, 8);
+ r = opp_enable(mpu_dev, 8);
/* TODO: MPU 1GHz needs SR and ABB */
/* Enable IVA 800MHz and lower opps */
- dev = dh-od-pdev.dev;
- r |= opp_enable(dev, 66000);
+ r |= opp_enable(iva_dev, 66000);
/* TODO: DSP 800MHz needs SR and ABB */
if (r) {
pr_err(%s: failed to enable higher opp %d\n,
@@ -556,10 +555,8 @@ static void __init beagle_opp_init(void)
* Cleanup - disable the higher freqs - we dont care
* about the results
*/
- dev = mh-od-pdev.dev;
- opp_disable(dev, 8);
- dev = dh-od-pdev.dev;
- opp_disable(dev, 66000);
+ opp_disable(mpu_dev, 8);
+ opp_disable(iva_dev, 66000);
}
}
return;
--
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
[RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices
From: Kevin Hilman khil...@ti.com
For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros. Use
them instead of manual use of container_of().
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/mcbsp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 5587acf..3f4a45d 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -295,9 +295,9 @@ EXPORT_SYMBOL(omap_mcbsp_dma_reg_params);
#ifdef CONFIG_ARCH_OMAP3
static struct omap_device *find_omap_device_by_dev(struct device *dev)
{
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- return container_of(pdev, struct omap_device, pdev);
+ struct platform_device *pdev = to_platform_device(dev);
+
+ return to_omap_device(pdev);
}
static void omap_st_on(struct omap_mcbsp *mcbsp)
--
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
[RFC/PATCH 05/14] OMAP: omap_device: remove internal functions from omap_device.h
From: Kevin Hilman khil...@ti.com
The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |6 --
arch/arm/plat-omap/omap_device.c | 12
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..0a53a0a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -83,9 +83,6 @@ int omap_device_shutdown(struct platform_device *pdev);
/* Core code interface */
-int omap_device_count_resources(struct omap_device *od);
-int omap_device_fill_resources(struct omap_device *od, struct resource *res);
-
struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
struct omap_hwmod *oh, void *pdata,
int pdata_len,
@@ -98,9 +95,6 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt, int is_early_device);
-int omap_device_register(struct omap_device *od);
-int omap_early_device_register(struct omap_device *od);
-
void __iomem *omap_device_get_rt_va(struct omap_device *od);
/* OMAP PM interface */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 1d69596..4737b60 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -94,6 +94,9 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
+static int omap_device_register(struct omap_device *od);
+static int omap_early_device_register(struct omap_device *od);
+
/* Private functions */
/**
@@ -325,7 +328,7 @@ u32 omap_device_get_context_loss_count(struct
platform_device *pdev)
* much memory to allocate before calling
* omap_device_fill_resources(). Returns the count.
*/
-int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od)
{
int c = 0;
int i;
@@ -356,7 +359,8 @@ int omap_device_count_resources(struct omap_device *od)
* functions to get device resources. Hacking around the existing
* platform_device code wastes memory. Returns 0.
*/
-int omap_device_fill_resources(struct omap_device *od, struct resource *res)
+static int omap_device_fill_resources(struct omap_device *od,
+ struct resource *res)
{
int c = 0;
int i, r;
@@ -520,7 +524,7 @@ odbs_exit1:
* platform_early_add_device() on the underlying platform_device.
* Returns 0 by default.
*/
-int omap_early_device_register(struct omap_device *od)
+static int omap_early_device_register(struct omap_device *od)
{
struct platform_device *devices[1];
@@ -573,7 +577,7 @@ static struct dev_power_domain omap_device_power_domain = {
* platform_device_register() on the underlying platform_device.
* Returns the return value of platform_device_register().
*/
-int omap_device_register(struct omap_device *od)
+static int omap_device_register(struct omap_device *od)
{
pr_debug(omap_device: %s: registering\n, od-pdev.name);
--
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
[RFC/PATCH 06/14] OMAP: omap_device: when building return platform_device instead of omap_device
From: Kevin Hilman khil...@ti.com
All of the device init and device driver interaction with omap_device
is done using platform_device pointers. To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.
All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.
This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/devices.c | 44
arch/arm/mach-omap2/display.c |6 ++--
arch/arm/mach-omap2/dma.c | 16
arch/arm/mach-omap2/gpio.c|8 ++--
arch/arm/mach-omap2/hsmmc.c |8 ++--
arch/arm/mach-omap2/hwspinlock.c |8 ++--
arch/arm/mach-omap2/mcbsp.c |8 ++--
arch/arm/mach-omap2/pm.c |8 ++--
arch/arm/mach-omap2/serial.c | 12 +++---
arch/arm/plat-omap/i2c.c |8 ++--
arch/arm/plat-omap/include/plat/omap_device.h |4 +-
arch/arm/plat-omap/omap_device.c |6 ++--
12 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5b8ca68..458f7be 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -44,7 +44,7 @@ static int __init omap3_l3_init(void)
{
int l;
struct omap_hwmod *oh;
- struct omap_device *od;
+ struct platform_device *pdev;
char oh_name[L3_MODULES_MAX_LEN];
/*
@@ -61,12 +61,12 @@ static int __init omap3_l3_init(void)
if (!oh)
pr_err(could not look up %s\n, oh_name);
- od = omap_device_build(omap_l3_smx, 0, oh, NULL, 0,
+ pdev = omap_device_build(omap_l3_smx, 0, oh, NULL, 0,
NULL, 0, 0);
- WARN(IS_ERR(od), could not build omap_device for %s\n, oh_name);
+ WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
- return IS_ERR(od) ? PTR_ERR(od) : 0;
+ return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
}
postcore_initcall(omap3_l3_init);
@@ -74,7 +74,7 @@ static int __init omap4_l3_init(void)
{
int l, i;
struct omap_hwmod *oh[3];
- struct omap_device *od;
+ struct platform_device *pdev;
char oh_name[L3_MODULES_MAX_LEN];
/*
@@ -92,12 +92,12 @@ static int __init omap4_l3_init(void)
pr_err(could not look up %s\n, oh_name);
}
- od = omap_device_build_ss(omap_l3_noc, 0, oh, 3, NULL,
+ pdev = omap_device_build_ss(omap_l3_noc, 0, oh, 3, NULL,
0, NULL, 0, 0);
- WARN(IS_ERR(od), could not build omap_device for %s\n, oh_name);
+ WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
- return IS_ERR(od) ? PTR_ERR(od) : 0;
+ return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
}
postcore_initcall(omap4_l3_init);
@@ -232,7 +232,7 @@ struct omap_device_pm_latency omap_keyboard_latency[] = {
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data)
{
- struct omap_device *od;
+ struct platform_device *pdev;
struct omap_hwmod *oh;
struct omap4_keypad_platform_data *keypad_data;
unsigned int id = -1;
@@ -247,15 +247,15 @@ int __init omap4_keyboard_init(struct
omap4_keypad_platform_data
keypad_data = sdp4430_keypad_data;
- od = omap_device_build(name, id, oh, keypad_data,
+ pdev = omap_device_build(name, id, oh, keypad_data,
sizeof(struct omap4_keypad_platform_data),
omap_keyboard_latency,
ARRAY_SIZE(omap_keyboard_latency), 0);
- if (IS_ERR(od)) {
+ if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
name, oh-name);
- return PTR_ERR(od);
+ return PTR_ERR(pdev);
}
return 0;
@@ -273,7 +273,7 @@ static struct omap_device_pm_latency mbox_latencies[] = {
static inline void omap_init_mbox(void)
{
struct omap_hwmod *oh;
- struct omap_device *od;
+ struct platform_device *pdev;
oh = omap_hwmod_lookup(mailbox);
if (!oh) {
@@ -281,10 +281,10 @@ static inline void omap_init_mbox(void)
return;
}
- od = omap_device_build(omap-mailbox, -1, oh, NULL, 0,
+ pdev = omap_device_build(omap-mailbox, -1, oh, NULL, 0,
[RFC/PATCH 07/14] ARM: platform_device: pdev_archdata: add omap_device pointer
From: Kevin Hilman khil...@ti.com
Add omap_device pointer to the ARM-specific arch data in the
platform_device. This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/include/asm/device.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..b5c9f5b 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -12,7 +12,12 @@ struct dev_archdata {
#endif
};
+struct omap_device;
+
struct pdev_archdata {
+#ifdef CONFIG_ARCH_OMAP
+ struct omap_device *od;
+#endif
};
#endif
--
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
[RFC/PATCH 08/14] omap2+: Use Kconfig symbol in Makefile instead of obj-y
From: Tony Lindgren t...@atomide.com As noted by Grant Likely grant.lik...@secretlab.ca, omap2+ Makefile unnecessarily repeats entries for common device init code instead of using Kconfig symbol. Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o references can be removed once it has some Kconfig symbol to use. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Makefile | 76 + 1 files changed, 32 insertions(+), 44 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b148077..39e3f61 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -175,78 +175,66 @@ endif # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o -obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ - hsmmc.o +obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o -obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ - hsmmc.o -obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \ - board-flash.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \ - hsmmc.o -obj-$(CONFIG_MACH_OVERO) += board-overo.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ - hsmmc.o -obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ - hsmmc.o \ - board-flash.o +obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o +obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o +obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o +obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o +obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o +obj-$(CONFIG_MACH_OVERO) += board-overo.o +obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o +obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o +obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \ - sdram-nokia.o \ - hsmmc.o + sdram-nokia.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ sdram-nokia.o \ board-rx51-peripherals.o \ - board-rx51-video.o \ - hsmmc.o + board-rx51-video.o obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o \ board-zoom-peripherals.o \ board-zoom-display.o \ - board-flash.o \ - hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom.o \ board-zoom-peripherals.o \ board-zoom-display.o \ - board-flash.o \ - hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \ board-zoom-peripherals.o \ - board-zoom-display.o \ - board-flash.o \ - hsmmc.o -obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \ - hsmmc.o + board-zoom-display.o +obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o -obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \ -
[RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
The omap dt requires new omap hwmod api to be added for in order to support omap dt. The new api is added and new parameter np is added for existing api. The users of hwmod api is changed accrodingly. Build and boot tested on omap3 beagle for both dt and not dt build. Signed-off-by: G, Manjunath Kondaiah manj...@ti.com --- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/mcbsp.c |2 +- arch/arm/plat-omap/include/plat/omap_device.h | 11 +- arch/arm/plat-omap/omap_device.c | 53 ++--- 4 files changed, 59 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 458f7be..d7ff1ae 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -92,7 +92,7 @@ static int __init omap4_l3_init(void) pr_err(could not look up %s\n, oh_name); } - pdev = omap_device_build_ss(omap_l3_noc, 0, oh, 3, NULL, + pdev = omap_device_build_ss(NULL, omap_l3_noc, 0, oh, 3, NULL, 0, NULL, 0, 0); WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name); diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c index 7a42f32..98eb95d 100644 --- a/arch/arm/mach-omap2/mcbsp.c +++ b/arch/arm/mach-omap2/mcbsp.c @@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused) (struct omap_mcbsp_dev_attr *)(oh-dev_attr))-sidetone); count++; } - pdev = omap_device_build_ss(name, id, oh_device, count, pdata, + pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata, sizeof(*pdata), omap2_mcbsp_latency, ARRAY_SIZE(omap2_mcbsp_latency), false); kfree(pdata); diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h index 7a3ec4f..5e2424b 100644 --- a/arch/arm/plat-omap/include/plat/omap_device.h +++ b/arch/arm/plat-omap/include/plat/omap_device.h @@ -33,6 +33,7 @@ #include linux/kernel.h #include linux/platform_device.h +#include linux/of.h #include plat/omap_hwmod.h @@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); -struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(struct device_node *np, +const char *pdev_name, int pdev_id, struct omap_hwmod **oh, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats, int pm_lats_cnt, int is_early_device); +struct platform_device *omap_device_build_dt(struct device_node *np, + const char *pdev_name, int pdev_id, + struct omap_hwmod *oh, void *pdata, + int pdata_len, + struct omap_device_pm_latency *pm_lats, + int pm_lats_cnt, int is_early_device); + void __iomem *omap_device_get_rt_va(struct omap_device *od); /* OMAP PM interface */ diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 7d5e76b..fa49168 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -85,6 +85,7 @@ #include linux/clk.h #include linux/clkdev.h #include linux/pm_runtime.h +#include linux/of_device.h #include plat/omap_device.h #include plat/omap_hwmod.h @@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device *od, /** * omap_device_build - build and register an omap_device with one omap_hwmod * @pdev_name: name of the platform_device driver to use + * @np: device node pointer for attaching it to of_node pointer * @pdev_id: this platform_device's connection ID * @oh: ptr to the single omap_hwmod that backs this omap_device * @pdata: platform_data ptr to associate with the platform_device @@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device *od, * information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_dt(struct device_node *np, + const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int
[RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi | 62 ++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
new file mode 100644
index 000..85de92f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-soc.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ skeleton.dtsi
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ model = ti,omap3;
+
+ aliases {
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ };
+
+ l4-core {
+ compatible = ti,omap3-l4-core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x4800 0x100;
+
+ i2c1: i2c@7 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = ti,omap3-i2c;
+ reg = 0x7 0x100;
+ interrupts = 88 ;
+ };
+
+ i2c2: i2c@72000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = ti,omap3-i2c;
+ reg = 0x72000 0x100;
+ interrupts = 89 ;
+ };
+
+ i2c3: i2c@6 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = ti,omap3-i2c;
+ reg = 0x6 0x100;
+ interrupts = 93 ;
+ };
+ };
+
+ l4-per {
+ compatible = ti,l4-per;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x4900 0x10;
+ };
+};
--
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
[RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices
Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3
soc dts file.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +--
arch/arm/boot/dts/omap3-beagle.dts | 18 +++---
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
index 2607be5..324ff86 100644
--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
@@ -1,16 +1,7 @@
/include/ omap3-beagle.dts
/ {
- i2c@48072000 {
- compatible = ti,omap3-i2c;
- reg = 0x48072000 0x80;
- #address-cells = 1;
- #size-cells = 0;
-
- eeprom@50 {
- compatible = at,at24c01;
- reg = 0x50 ;
- };
+ i2c@2 {
joystick@52 {
compatible = sparkfun,wiichuck;
reg = 0x52 ;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 4439466..49a5ac7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -1,7 +1,19 @@
-/dts-v1/;
-/include/ skeleton.dtsi
+/include/ omap3-soc.dtsi
/ {
model = TI OMAP3 BeagleBoard;
- compatible = ti,omap3-beagle;
+ compatible = ti,omap3-beagle, ti,omap3;
+
+
+ i2c1 {
+ clock-frequency = 260;
+ };
+
+ i2c2 {
+ clock-frequency = 40;
+ };
+
+ i2c3 {
+ clock-frequency = 40;
+ };
};
--
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
[RFC/PATCH 13/14] dt: omap3: add generic board file for dt support
The generic board file is created and derived from beagle board file.
The beagle board file is migrated to boot from flattened device tree and
the cleanup of board specific file will happen in different stages.
The changes here focus on minimal configuration to boot beagle board with
dt enabled which provides basic platform for converting device drivers for
using dt.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/mach-omap2/Kconfig | 11
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3-dt.c| 93 +++
arch/arm/mach-omap2/board-omap3beagle.c | 13
4 files changed, 105 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 19d5891..6e1fe7c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -302,6 +302,17 @@ config MACH_OMAP_3630SDP
default y
select OMAP_PACKAGE_CBP
+config MACH_OMAP3_DT
+ bool Generic OMAP3 board(FDT support)
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+ select USE_OF
+
+ help
+ Support for generic TI OMAP3 boards using Flattened Device Tree.
+ Say Y here to enable OMAP3 device tree support
+ More information at Documentation/devicetree
+
config MACH_TI8168EVM
bool TI8168 Evaluation Module
depends on SOC_OMAPTI816X
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 39e3f61..0e363f2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,7 @@ obj-$(CONFIG_MACH_OVERO)+= board-overo.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
+obj-$(CONFIG_MACH_OMAP3_DT)+= board-omap3-dt.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c
b/arch/arm/mach-omap2/board-omap3-dt.c
new file mode 100644
index 000..4b76e19
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -0,0 +1,93 @@
+/*
+ * TI OMAP3 device tree board support
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/of_platform.h
+#include linux/of_address.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl.h
+
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include plat/omap_device.h
+
+#include mux.h
+#include timer-gp.h
+#include common-board-devices.h
+#include hsmmc.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+static struct twl4030_platform_data beagle_twldata = {
+ .irq_base = TWL4030_IRQ_BASE,
+ .irq_end= TWL4030_IRQ_END,
+
+ /* platform_data for children goes here */
+};
+
+static int __init omap3_beagle_i2c_init(void)
+{
+ omap3_pmic_init(twl4030, beagle_twldata);
+ return 0;
+}
+
+static void __init omap3_init_early(void)
+{
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params);
+}
+
+static void __init omap3_init_irq(void)
+{
+ omap_init_irq();
+#ifdef CONFIG_OMAP_32K_TIMER
+ omap2_gp_clockevent_set_gptimer(12);
+#endif
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+ { .compatible = ti,omap3-l4-core, },
+ {}
+};
+
+static void __init omap3_init(void)
+{
+ omap3_beagle_i2c_init();
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+ ti,omap3,
+ NULL
+};
+
+DT_MACHINE_START(OMAP3_DT, TI OMAP3 (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3_init_early,
+ .init_irq = omap3_init_irq,
+ .init_machine = omap3_init,
+ .timer = omap_timer,
+ .dt_compat = omap3_dt_match,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7905c8d..9ecb65d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -19,7 +19,6 @@
[RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller
Adapt dt for omap i2c1 controller and remove legacy i2c
initilization in omap3 generic board file.
Tested on omap3 beagle board for dt and non-dt builds.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap3-soc.dtsi |6 ++--
arch/arm/mach-omap2/board-omap3-dt.c | 14 +-
drivers/i2c/busses/i2c-omap.c| 23 --
drivers/of/platform.c| 41 +-
4 files changed, 70 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
index 85de92f..bcff63b 100644
--- a/arch/arm/boot/dts/omap3-soc.dtsi
+++ b/arch/arm/boot/dts/omap3-soc.dtsi
@@ -31,7 +31,7 @@
i2c1: i2c@7 {
#address-cells = 1;
#size-cells = 0;
- compatible = ti,omap3-i2c;
+ compatible = ti,omap3-i2c, ti,omap3-device;
reg = 0x7 0x100;
interrupts = 88 ;
};
@@ -39,7 +39,7 @@
i2c2: i2c@72000 {
#address-cells = 1;
#size-cells = 0;
- compatible = ti,omap3-i2c;
+ compatible = ti,omap3-i2c, ti,omap3-device;
reg = 0x72000 0x100;
interrupts = 89 ;
};
@@ -47,7 +47,7 @@
i2c3: i2c@6 {
#address-cells = 1;
#size-cells = 0;
- compatible = ti,omap3-i2c;
+ compatible = ti,omap3-i2c, ti,omap3-device;
reg = 0x6 0x100;
interrupts = 93 ;
};
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c
b/arch/arm/mach-omap2/board-omap3-dt.c
index 4b76e19..16cf283 100644
--- a/arch/arm/mach-omap2/board-omap3-dt.c
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -36,11 +36,11 @@ static struct twl4030_platform_data beagle_twldata = {
/* platform_data for children goes here */
};
-static int __init omap3_beagle_i2c_init(void)
-{
- omap3_pmic_init(twl4030, beagle_twldata);
- return 0;
-}
+struct of_dev_auxdata omap3_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA_ID_PDSIZE(ti,omap3-i2c, 0x4807, i2c1, 1,\
+ beagle_twldata, sizeof(beagle_twldata)),
+ {}
+};
static void __init omap3_init_early(void)
{
@@ -70,11 +70,11 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
static void __init omap3_init(void)
{
- omap3_beagle_i2c_init();
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ of_platform_populate(NULL, omap_dt_match_table, omap3_auxdata_lookup,
+NULL);
}
static const char *omap3_dt_match[] __initdata = {
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ae1545b..5167737 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,6 +38,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/of_i2c.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
@@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_i2c_of_match[] = {
+ {.compatible = ti,omap3-i2c, },
+ {},
+}
+MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+#define omap_i2c_of_match NULL
+#endif
+
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
+ speed = 100;/* Default speed */
if (pdata != NULL) {
speed = pdata-clkrate;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
- } else {
- speed = 100;/* Default speed */
- dev-set_mpu_wkup_lat = NULL;
+#if defined(CONFIG_OF)
+ } else if (pdev-dev.of_node) {
+ u32 prop;
+ if (!of_property_read_u32(pdev-dev.of_node, clock-frequency,
+ prop))
+ speed = prop/100;
+#endif
}
dev-speed = speed;
@@ -1178,6 +1194,7 @@ static struct platform_driver omap_i2c_driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
.pm = OMAP_I2C_PM_OPS,
+ .of_match_table = omap_i2c_of_match,
},
};
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 4b27286..4d8a2fa 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -24,6
[PATCH 1/5 v4] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244
1 files changed, 244 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..d8f08fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,242 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .main_clk = usb_host_hs_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters= omap44xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_class omap44xx_usbhs_ohci_hwmod_class = {
+ .name = usbhs_ohci,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usbhs_ohci_irqs[] = {
+ { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 } /* Terminating IRQ */
+};
+
+static struct omap_hwmod_addr_space omap44xx_usbhs_ohci_addrs[] = {
+ {
+ .name = ohci,
+ .pa_start = 0x4A064800,
+ .pa_end = 0x4A064BFF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usbhs_ohci = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usbhs_ohci_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usbhs_ohci_addrs,
+ .user
[PATCH 0/5 v4] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
From: Keshava Munegowda keshava_mgo...@ti.com The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. these patches are rebased to kevin's pm branch and usbhs latest mainline kernel patches TODO: - Aggressive clock cutting in usb bus suspends - Remote Wakeup implementation using irq-chaing Benoit Cousson (1): arm: omap: usb: ehci and ohci hwmod structures for omap4 Keshava Munegowda (4): arm: omap: usb: ehci and ohci hwmod structures for omap3 arm: omap: usb: register hwmods of usbhs arm: omap: usb: device name change for the clk names of usbhs mfd: omap: usb: Runtime PM support arch/arm/mach-omap2/clock3xxx_data.c | 26 +- arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279 +++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 244 ++ arch/arm/mach-omap2/usb-host.c | 114 ++--- arch/arm/plat-omap/include/plat/usb.h |3 - drivers/mfd/omap-usb-host.c| 724 +++- drivers/usb/host/ehci-omap.c | 19 +- drivers/usb/host/ohci-omap3.c | 14 +- 9 files changed, 877 insertions(+), 556 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5 v4] arm: omap: usb: register hwmods of usbhs
The hwmod structure of uhh, ohci, ehci and tll are
retrived and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 114 +--
1 files changed, 50 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 89ae298..9c37db9 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -28,51 +28,30 @@
#include mach/hardware.h
#include mach/irqs.h
#include plat/usb.h
+#include plat/omap_device.h
#include mux.h
#ifdef CONFIG_MFD_OMAP_USB_HOST
-#define OMAP_USBHS_DEVICE usbhs-omap
-
-static struct resource usbhs_resources[] = {
- {
- .name = uhh,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = tll,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ehci-irq,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = ohci,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = ohci-irq,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device usbhs_device = {
- .name = OMAP_USBHS_DEVICE,
- .id = 0,
- .num_resources = ARRAY_SIZE(usbhs_resources),
- .resource = usbhs_resources,
-};
+#define OMAP_USBHS_DEVICE usbhs_omap
+#defineUSBHS_UHH_HWMODNAME usbhs_uhh
+#defineUSBHS_OHCI_HWMODNAMEusbhs_ohci
+#define USBHS_EHCI_HWMODNAME usbhs_ehci
+#define USBHS_TLL_HWMODNAMEusbhs_tll
static struct usbhs_omap_platform_data usbhs_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
+static struct omap_device_pm_latency omap_uhhtll_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
/* MUX settings for EHCI pins */
/*
* setup_ehci_io_mux - initialize IO pad mux for USBHOST
@@ -508,7 +487,10 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- int i;
+ struct omap_hwmod *oh[4];
+ struct omap_device *od;
+ int bus_id = -1;
+ int i;
for (i = 0; i OMAP3_HS_USB_PORTS; i++) {
usbhs_data.port_mode[i] = pdata-port_mode[i];
@@ -523,44 +505,48 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
- usbhs_resources[0].start = OMAP34XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP34XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP34XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start= OMAP34XX_EHCI_BASE;
- usbhs_resources[2].end = OMAP34XX_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = INT_34XX_EHCI_IRQ;
- usbhs_resources[4].start= OMAP34XX_OHCI_BASE;
- usbhs_resources[4].end = OMAP34XX_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = INT_34XX_OHCI_IRQ;
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
} else if (cpu_is_omap44xx()) {
- usbhs_resources[0].start = OMAP44XX_UHH_CONFIG_BASE;
- usbhs_resources[0].end = OMAP44XX_UHH_CONFIG_BASE + SZ_1K - 1;
- usbhs_resources[1].start = OMAP44XX_USBTLL_BASE;
- usbhs_resources[1].end = OMAP44XX_USBTLL_BASE + SZ_4K - 1;
- usbhs_resources[2].start = OMAP44XX_HSUSB_EHCI_BASE;
- usbhs_resources[2].end = OMAP44XX_HSUSB_EHCI_BASE + SZ_1K - 1;
- usbhs_resources[3].start = OMAP44XX_IRQ_EHCI;
- usbhs_resources[4].start = OMAP44XX_HSUSB_OHCI_BASE;
- usbhs_resources[4].end = OMAP44XX_HSUSB_OHCI_BASE + SZ_1K - 1;
- usbhs_resources[5].start = OMAP44XX_IRQ_OHCI;
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
}
- if (platform_device_add_data(usbhs_device,
- usbhs_data, sizeof(usbhs_data)) 0) {
- printk(KERN_ERR USBHS platform_device_add_data failed\n);
- goto init_end;
+ oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!oh[0]) {
+ pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
+
[PATCH 2/5 v4] arm: omap: usb: ehci and ohci hwmod structures for omap3
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279
1 files changed, 279 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..d7316b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,10 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap34xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3196,6 +3200,276 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = omap34xx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = usbhs_uhh,
+ .sysc = omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk= l4_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk= usbhost_120m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk= usbhost_48m_fck,
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ omap34xx_l4_cfg__usb_host_hs,
+ omap34xx_f128m_cfg__usb_host_hs,
+ omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = usbhs_uhh,
+ .class = omap34xx_usb_host_hs_hwmod_class,
+ .main_clk = usbhost_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters= omap34xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_ocp_if omap34xx_usbhs_ohci__l3_main_2 = {
+ .master = omap34xx_usbhs_ohci_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class omap34xx_usbhs_ohci_hwmod_class = {
+ .name = usbhs_ohci,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usbhs_ohci_masters[] = {
+
[PATCH 5/5 v4] mfd: omap: usb: Runtime PM support
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the intefrace and
fucntional clocks; These clocks are handled by hwmod and runtime pm,
hence insted of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the usbhs core.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/plat-omap/include/plat/usb.h |3 -
drivers/mfd/omap-usb-host.c | 722 +
drivers/usb/host/ehci-omap.c | 19 +-
drivers/usb/host/ohci-omap3.c | 14 +-
4 files changed, 286 insertions(+), 472 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..2b66dc2 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -100,9 +100,6 @@ extern void usb_musb_init(struct omap_musb_board_data
*board_data);
extern void usbhs_init(const struct usbhs_omap_board_data *pdata);
-extern int omap_usbhs_enable(struct device *dev);
-extern void omap_usbhs_disable(struct device *dev);
-
extern int omap4430_phy_power(struct device *dev, int ID, int on);
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 5def51c..39cfae6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -26,6 +26,7 @@
#include linux/spinlock.h
#include linux/gpio.h
#include plat/usb.h
+#include linux/pm_runtime.h
#define USBHS_DRIVER_NAME usbhs_omap
#define OMAP_EHCI_DEVICE ehci-omap
@@ -146,9 +147,6 @@
struct usbhs_hcd_omap {
- struct clk *usbhost_ick;
- struct clk *usbhost_hs_fck;
- struct clk *usbhost_fs_fck;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -158,8 +156,6 @@ struct usbhs_hcd_omap {
struct clk *usbhost_p2_fck;
struct clk *usbtll_p2_fck;
struct clk *init_60m_fclk;
- struct clk *usbtll_fck;
- struct clk *usbtll_ick;
void __iomem*uhh_base;
void __iomem*tll_base;
@@ -168,7 +164,6 @@ struct usbhs_hcd_omap {
u32 usbhs_rev;
spinlock_t lock;
- int count;
};
/*-*/
@@ -318,269 +313,6 @@ err_end:
return ret;
}
-/**
- * usbhs_omap_probe - initialize TI-based HCDs
- *
- * Allocates basic resources for this USB host controller.
- */
-static int __devinit usbhs_omap_probe(struct platform_device *pdev)
-{
- struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- struct usbhs_hcd_omap *omap;
- struct resource *res;
- int ret = 0;
- int i;
-
- if (!pdata) {
- dev_err(dev, Missing platform data\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
- if (!omap) {
- dev_err(dev, Memory allocation failed\n);
- ret = -ENOMEM;
- goto end_probe;
- }
-
- spin_lock_init(omap-lock);
-
- for (i = 0; i OMAP3_HS_USB_PORTS; i++)
- omap-platdata.port_mode[i] = pdata-port_mode[i];
-
- omap-platdata.ehci_data = pdata-ehci_data;
- omap-platdata.ohci_data = pdata-ohci_data;
-
- omap-usbhost_ick = clk_get(dev, usbhost_ick);
- if (IS_ERR(omap-usbhost_ick)) {
- ret = PTR_ERR(omap-usbhost_ick);
- dev_err(dev, usbhost_ick failed error:%d\n, ret);
- goto err_end;
- }
-
- omap-usbhost_hs_fck = clk_get(dev, hs_fck);
- if (IS_ERR(omap-usbhost_hs_fck)) {
- ret = PTR_ERR(omap-usbhost_hs_fck);
- dev_err(dev, usbhost_hs_fck failed error:%d\n, ret);
- goto err_usbhost_ick;
- }
-
- omap-usbhost_fs_fck = clk_get(dev, fs_fck);
- if (IS_ERR(omap-usbhost_fs_fck)) {
- ret = PTR_ERR(omap-usbhost_fs_fck);
- dev_err(dev, usbhost_fs_fck failed error:%d\n, ret);
- goto err_usbhost_hs_fck;
- }
-
- omap-usbtll_fck = clk_get(dev, usbtll_fck);
- if (IS_ERR(omap-usbtll_fck)) {
- ret = PTR_ERR(omap-usbtll_fck);
- dev_err(dev, usbtll_fck failed error:%d\n, ret);
- goto err_usbhost_fs_fck;
- }
-
-
[PATCH 4/5 v4] arm: omap: usb: device name change for the clk names of usbhs
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 26 --
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
drivers/mfd/omap-usb-host.c |2 +-
3 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index ffd55b1..63a822f 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3285,7 +3285,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -3321,7 +3321,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3367,20 +3367,18 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cam_ick, cam_ick, CK_34XX | CK_36XX),
CLK(NULL, csi2_96m_fck, csi2_96m_fck, CK_34XX | CK_36XX),
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, hs_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, fs_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs-omap.0, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs-omap.0, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_omap, utmi_p1_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, utmi_p2_gfclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp1_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..088977a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3281,7 +3281,7 @@ static
Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
Hi, Keshava this one is for you (sorry for the top-post) On Tue, Aug 09, 2011 at 02:26:08PM +0300, Luciano Coelho wrote: Hi, On Mon, 2011-06-06 at 14:05 +0300, Luciano Coelho wrote: On Mon, 2011-06-06 at 14:02 +0300, Felipe Balbi wrote: On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote: looks like this is resulting from the missing hwmod conversion in mainlnie. Check if reverting 7e6502d577106fb5b202bbaac64c5f1b065e6daa helps. I verified off-list with Luca that reverting that commit does make it work. Keshava, care to send a revert patch to Sam until we get all the hwmod stuff in. Yes, I confirm that I'm not getting the oops anymore, after reverting this patch. Thanks a lot for the quick answer, dude! :) I'm again getting a very similar oops with 3.1-rc1 on my pandaboard: [2.054351] usbcore: registered new interface driver cdc_ncm [2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [2.068664] Unhandled fault: imprecise external abort (0x1406) at 0x [2.076110] Internal error: : 1406 [#1] SMP [2.080505] Modules linked in: [2.083709] CPU: 0Not tainted (3.1.0-rc1-wl+ #283) [2.089233] PC is at omap_usbhs_enable+0x148/0x590 [2.094299] LR is at trace_hardirqs_off+0x14/0x18 [2.099243] pc : [c02a8640]lr : [c007fea0]psr: 6093 [2.099243] sp : df871dc8 ip : df871d80 fp : df871dec [2.111328] r10: 8013 r9 : df9ef9e0 r8 : df9ef9ec [2.116821] r7 : dfa32800 r6 : dfa316f8 r5 : c06f5da8 r4 : dfa316a0 [2.123687] r3 : r2 : r1 : 0001 r0 : [2.130584] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [2.138366] Control: 10c53c7d Table: 8000404a DAC: 0015 [2.144409] Process swapper (pid: 1, stack limit = 0xdf8702f8) [2.150543] Stack: (0xdf871dc8 to 0xdf872000) [2.155120] 1dc0: df105400 dfa32808 df105400 dfa32800 df9ef9ec 0003 [2.163726] 1de0: df871e8c df871df0 c0321d60 c02a8504 df871e2c df10a588 df1075a0 df10a588 [2.172363] 1e00: df871e2c df871e10 df10a588 df10a608 dfa28e88 006d fc064c00 [2.180969] 1e20: df871e6c df871e30 c015654c c0155c08 c0082098 c0071f74 0001 dfa32898 [2.189575] 1e40: dfa28e88 dfa32808 dfa32810 73757368 3062 [2.198181] 1e60: df871e7c dfa32808 c0716da8 c0716da8 [2.206787] 1e80: df871e9c df871e90 c0298cfc c0321bb8 df871ec4 df871ea0 c0297650 c0298ce4 [2.215423] 1ea0: df871ec4 dfa32808 dfa3283c dfa32808 dfa3283c c0716da8 df871ee4 df871ec8 [2.224029] 1ec0: c02977ec c0297504 c0716da8 c0297774 df871f0c df871ee8 [2.232635] 1ee0: c0296c00 c0297780 df891658 dfa31670 c023ac60 c0716da8 df1075a0 c070d6f8 [2.241241] 1f00: df871f1c df871f10 c0297334 c0296bb0 df871f4c df871f20 c02963ec c0297318 [2.249847] 1f20: c05b84a8 df871f30 c0716da8 c0c7e4c0 c0014ba0 [2.258483] 1f40: df871f74 df871f50 c0297f00 c0296320 c0298d44 c0c7df14 c0c7e4c0 c0014ba0 [2.267089] 1f60: df871f84 df871f78 c02991e0 c0297e54 df871fa4 df871f88 [2.275695] 1f80: c069904c c0299198 00a0 0060 c06c4e40 c0698fa4 df871fdc df871fa8 [2.284301] 1fa0: c0008854 c0698fb0 c0014ba0 c009960c df871fdc df871fc0 c06c4e40 c06c49dc [2.292907] 1fc0: c0014ba0 0013 df871ff4 df871fe0 c06792d4 c00087b8 [2.301513] 1fe0: c067924c df871ff8 c0014ba0 c0679258 882bf20f 3184000e [2.310150] [c02a8640] (omap_usbhs_enable+0x148/0x590) from [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) [2.320526] [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) from [c0298cfc] (platform_drv_probe+0x24/0x28) [2.330780] [c0298cfc] (platform_drv_probe+0x24/0x28) from [c0297650] (driver_probe_device+0x158/0x27c) [2.341033] [c0297650] (driver_probe_device+0x158/0x27c) from [c02977ec] (__driver_attach+0x78/0x9c) [2.351043] [c02977ec] (__driver_attach+0x78/0x9c) from [c0296c00] (bus_for_each_dev+0x5c/0x8c) [2.360565] [c0296c00] (bus_for_each_dev+0x5c/0x8c) from [c0297334] (driver_attach+0x28/0x30) [2.369903] [c0297334] (driver_attach+0x28/0x30) from [c02963ec] (bus_add_driver+0xd8/0x260) [2.379180] [c02963ec] (bus_add_driver+0xd8/0x260) from [c0297f00] (driver_register+0xb8/0x144) [2.388702] [c0297f00] (driver_register+0xb8/0x144) from [c02991e0] (platform_driver_register+0x54/0x68) [2.399047] [c02991e0] (platform_driver_register+0x54/0x68) from [c069904c] (ehci_hcd_init+0xa8/0xfc) [2.409149] [c069904c] (ehci_hcd_init+0xa8/0xfc) from [c0008854] (do_one_initcall+0xa8/0x17c) [2.418487] [c0008854] (do_one_initcall+0xa8/0x17c) from [c06792d4] (kernel_init+0x88/0x134) [2.427764] [c06792d4] (kernel_init+0x88/0x134) from [c0014ba0]
Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
yes! I have started this. regards keshava On Tue, Aug 9, 2011 at 8:17 PM, Felipe Balbi ba...@ti.com wrote: Hi, Keshava this one is for you (sorry for the top-post) On Tue, Aug 09, 2011 at 02:26:08PM +0300, Luciano Coelho wrote: Hi, On Mon, 2011-06-06 at 14:05 +0300, Luciano Coelho wrote: On Mon, 2011-06-06 at 14:02 +0300, Felipe Balbi wrote: On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote: looks like this is resulting from the missing hwmod conversion in mainlnie. Check if reverting 7e6502d577106fb5b202bbaac64c5f1b065e6daa helps. I verified off-list with Luca that reverting that commit does make it work. Keshava, care to send a revert patch to Sam until we get all the hwmod stuff in. Yes, I confirm that I'm not getting the oops anymore, after reverting this patch. Thanks a lot for the quick answer, dude! :) I'm again getting a very similar oops with 3.1-rc1 on my pandaboard: [ 2.054351] usbcore: registered new interface driver cdc_ncm [ 2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.068664] Unhandled fault: imprecise external abort (0x1406) at 0x [ 2.076110] Internal error: : 1406 [#1] SMP [ 2.080505] Modules linked in: [ 2.083709] CPU: 0 Not tainted (3.1.0-rc1-wl+ #283) [ 2.089233] PC is at omap_usbhs_enable+0x148/0x590 [ 2.094299] LR is at trace_hardirqs_off+0x14/0x18 [ 2.099243] pc : [c02a8640] lr : [c007fea0] psr: 6093 [ 2.099243] sp : df871dc8 ip : df871d80 fp : df871dec [ 2.111328] r10: 8013 r9 : df9ef9e0 r8 : df9ef9ec [ 2.116821] r7 : dfa32800 r6 : dfa316f8 r5 : c06f5da8 r4 : dfa316a0 [ 2.123687] r3 : r2 : r1 : 0001 r0 : [ 2.130584] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.138366] Control: 10c53c7d Table: 8000404a DAC: 0015 [ 2.144409] Process swapper (pid: 1, stack limit = 0xdf8702f8) [ 2.150543] Stack: (0xdf871dc8 to 0xdf872000) [ 2.155120] 1dc0: df105400 dfa32808 df105400 dfa32800 df9ef9ec 0003 [ 2.163726] 1de0: df871e8c df871df0 c0321d60 c02a8504 df871e2c df10a588 df1075a0 df10a588 [ 2.172363] 1e00: df871e2c df871e10 df10a588 df10a608 dfa28e88 006d fc064c00 [ 2.180969] 1e20: df871e6c df871e30 c015654c c0155c08 c0082098 c0071f74 0001 dfa32898 [ 2.189575] 1e40: dfa28e88 dfa32808 dfa32810 73757368 3062 [ 2.198181] 1e60: df871e7c dfa32808 c0716da8 c0716da8 [ 2.206787] 1e80: df871e9c df871e90 c0298cfc c0321bb8 df871ec4 df871ea0 c0297650 c0298ce4 [ 2.215423] 1ea0: df871ec4 dfa32808 dfa3283c dfa32808 dfa3283c c0716da8 df871ee4 df871ec8 [ 2.224029] 1ec0: c02977ec c0297504 c0716da8 c0297774 df871f0c df871ee8 [ 2.232635] 1ee0: c0296c00 c0297780 df891658 dfa31670 c023ac60 c0716da8 df1075a0 c070d6f8 [ 2.241241] 1f00: df871f1c df871f10 c0297334 c0296bb0 df871f4c df871f20 c02963ec c0297318 [ 2.249847] 1f20: c05b84a8 df871f30 c0716da8 c0c7e4c0 c0014ba0 [ 2.258483] 1f40: df871f74 df871f50 c0297f00 c0296320 c0298d44 c0c7df14 c0c7e4c0 c0014ba0 [ 2.267089] 1f60: df871f84 df871f78 c02991e0 c0297e54 df871fa4 df871f88 [ 2.275695] 1f80: c069904c c0299198 00a0 0060 c06c4e40 c0698fa4 df871fdc df871fa8 [ 2.284301] 1fa0: c0008854 c0698fb0 c0014ba0 c009960c df871fdc df871fc0 c06c4e40 c06c49dc [ 2.292907] 1fc0: c0014ba0 0013 df871ff4 df871fe0 c06792d4 c00087b8 [ 2.301513] 1fe0: c067924c df871ff8 c0014ba0 c0679258 882bf20f 3184000e [ 2.310150] [c02a8640] (omap_usbhs_enable+0x148/0x590) from [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) [ 2.320526] [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) from [c0298cfc] (platform_drv_probe+0x24/0x28) [ 2.330780] [c0298cfc] (platform_drv_probe+0x24/0x28) from [c0297650] (driver_probe_device+0x158/0x27c) [ 2.341033] [c0297650] (driver_probe_device+0x158/0x27c) from [c02977ec] (__driver_attach+0x78/0x9c) [ 2.351043] [c02977ec] (__driver_attach+0x78/0x9c) from [c0296c00] (bus_for_each_dev+0x5c/0x8c) [ 2.360565] [c0296c00] (bus_for_each_dev+0x5c/0x8c) from [c0297334] (driver_attach+0x28/0x30) [ 2.369903] [c0297334] (driver_attach+0x28/0x30) from [c02963ec] (bus_add_driver+0xd8/0x260) [ 2.379180] [c02963ec] (bus_add_driver+0xd8/0x260) from [c0297f00] (driver_register+0xb8/0x144) [ 2.388702] [c0297f00] (driver_register+0xb8/0x144) from [c02991e0] (platform_driver_register+0x54/0x68) [ 2.399047] [c02991e0] (platform_driver_register+0x54/0x68) from [c069904c] (ehci_hcd_init+0xa8/0xfc) [ 2.409149] [c069904c] (ehci_hcd_init+0xa8/0xfc) from [c0008854] (do_one_initcall+0xa8/0x17c) [ 2.418487] [c0008854] (do_one_initcall+0xa8/0x17c) from [c06792d4]
Re: [PATCHv2 3/5] OMAP4: HWMOD: fix DSS opt clocks
On 8/8/2011 11:15 AM, Valkeinen, Tomi wrote:
Remove the extra dss_dss_clk from dss_core's opt-clocks. dss_dss_clk is
the fck, and thus not an opt-clock.
Add HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core so that dss_core's
reset can finish.
Remove the opt clocks for dispc, as they are not needed.
Change the main_clk for hdmi and venc to dss_48mhz_clk and dss_tv_clk,
respectively.
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..8b74058 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1257,12 +1257,12 @@ static struct omap_hwmod_ocp_if *omap44xx_dss_slaves[]
= {
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
{ .role = tv_clk, .clk = dss_tv_clk },
- { .role = dss_clk, .clk = dss_dss_clk },
- { .role = video_clk, .clk = dss_48mhz_clk },
+ { .role = hdmi_clk, .clk = dss_48mhz_clk },
};
static struct omap_hwmod omap44xx_dss_hwmod = {
.name = dss_core,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.class =omap44xx_dss_hwmod_class,
.clkdm_name = l3_dss_clkdm,
.main_clk = dss_dss_clk,
@@ -1358,12 +1358,6 @@ static struct omap_hwmod_ocp_if
*omap44xx_dss_dispc_slaves[] = {
omap44xx_l4_per__dss_dispc,
};
-static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = {
- { .role = sys_clk, .clk = dss_sys_clk },
- { .role = tv_clk, .clk = dss_tv_clk },
- { .role = hdmi_clk, .clk = dss_48mhz_clk },
-};
-
static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
.name = dss_dispc,
.class =omap44xx_dispc_hwmod_class,
@@ -1377,8 +1371,6 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
.context_offs = OMAP4_RM_DSS_DSS_CONTEXT_OFFSET,
},
},
- .opt_clks = dss_dispc_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks),
.slaves = omap44xx_dss_dispc_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_dss_dispc_slaves),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -1645,7 +1637,7 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
.clkdm_name = l3_dss_clkdm,
.mpu_irqs = omap44xx_dss_hdmi_irqs,
.sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
- .main_clk = dss_dss_clk,
+ .main_clk = dss_48mhz_clk,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DSS_DSS_CLKCTRL_OFFSET,
@@ -1808,7 +1800,7 @@ static struct omap_hwmod omap44xx_dss_venc_hwmod = {
.name = dss_venc,
.class =omap44xx_venc_hwmod_class,
.clkdm_name = l3_dss_clkdm,
- .main_clk = dss_dss_clk,
+ .main_clk = dss_tv_clk,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DSS_DSS_CLKCTRL_OFFSET,
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3: am3517crane: remove NULL board_mux from board file
Since 7203f8a48bb63015ebe58a6f2a38aec1cb208b9d (arm: mach-omap2: remove
NULL board_mux from board files) NULL board_mux is defined in mux.h.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/mach-omap2/board-am3517crane.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 5f2b55f..933e935 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -45,8 +45,6 @@ static struct omap_board_config_kernel am3517_crane_config[]
__initdata = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
static void __init am3517_crane_init_early(void)
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. BTW, this is not required for omap since dt-hwmod binding will fetch pdev pointer from hwmod database and it will be used as is without any modification which inturn does not break any existing pm functionality. -M Do you have any plan to add that, or do you have any clean way to avoid that without having to use the resource index? Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP2+: pm: fix typos
Fix typos in comment and error message. Signed-off-by: Johan Hovold jhov...@gmail.com --- arch/arm/mach-omap2/pm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 3feb359..fd77cf4 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -163,11 +163,11 @@ err: } /* - * This API is to be called during init to put the various voltage + * This API is to be called during init to set the various voltage * domains to the voltage as per the opp table. Typically we boot up * at the nominal voltage. So this function finds out the rate of * the clock associated with the voltage domain, finds out the correct - * opp entry and puts the voltage domain to the voltage specifies + * opp entry and sets the voltage domain to the voltage specified * in the opp entry */ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, @@ -218,7 +218,7 @@ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, return 0; exit: - printk(KERN_ERR %s: Unable to put vdd_%s to its init voltage\n\n, + printk(KERN_ERR %s: Unable to set vdd_%s to its init voltage\n\n, __func__, vdd_name); return -EINVAL; } -- 1.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP2+: pm: clean up error messages
Replace all printks with pr_err.
Clean up error messages by adding missing whitespace, fixing
capitalisations, removing double newlines, and reducing verbosity.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/mach-omap2/pm.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fd77cf4..3837818 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -137,8 +137,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
ret = pwrdm_set_next_pwrst(pwrdm, state);
if (ret) {
- printk(KERN_ERR Unable to set state of powerdomain: %s\n,
- pwrdm-name);
+ pr_err(%s: unable to set state of powerdomain: %s\n,
+ __func__, pwrdm-name);
goto err;
}
@@ -179,21 +179,20 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
unsigned long freq, bootup_volt;
if (!vdd_name || !clk_name || !dev) {
- printk(KERN_ERR %s: Invalid parameters!\n, __func__);
+ pr_err(%s: invalid parameters\n, __func__);
goto exit;
}
voltdm = omap_voltage_domain_lookup(vdd_name);
if (IS_ERR(voltdm)) {
- printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
+ pr_err(%s: unable to get vdd pointer for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
clk = clk_get(NULL, clk_name);
if (IS_ERR(clk)) {
- printk(KERN_ERR %s: unable to get clk %s\n,
- __func__, clk_name);
+ pr_err(%s: unable to get clk %s\n, __func__, clk_name);
goto exit;
}
@@ -202,14 +201,14 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
opp = opp_find_freq_ceil(dev, freq);
if (IS_ERR(opp)) {
- printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
+ pr_err(%s: unable to find boot up OPP for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
bootup_volt = opp_get_voltage(opp);
if (!bootup_volt) {
- printk(KERN_ERR %s: unable to find voltage corresponding
+ pr_err(%s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
goto exit;
}
@@ -218,8 +217,7 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
return 0;
exit:
- printk(KERN_ERR %s: Unable to set vdd_%s to its init voltage\n\n,
- __func__, vdd_name);
+ pr_err(%s: unable to set vdd_%s\n, __func__, vdd_name);
return -EINVAL;
}
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP2+: voltage: clean up error messages
Clean up error messages by adding missing whitespace, reducing excessive
verbosity, and fixing a few language issues.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/mach-omap2/voltage.c | 51 ++--
1 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 9ef3789..0b460b9 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -104,7 +104,7 @@ static int __init _config_common_vdd_data(struct
omap_vdd_info *vdd)
*/
sys_ck = clk_get(NULL, sys_ck_name);
if (IS_ERR(sys_ck)) {
- pr_warning(%s: Could not get the sys clk to calculate
+ pr_warning(%s: Could not get the sys clk to calculate
various vdd_%s params\n, __func__, vdd-voltdm.name);
return -EINVAL;
}
@@ -143,14 +143,14 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
if (!vdd) {
- pr_warning(Wrong paramater passed\n);
+ pr_warning(Wrong parameter passed\n);
return -EINVAL;
}
vsel = vdd-read_reg(prm_mod_offs, vdd-vp_data-voltage);
if (!vdd-pmic_info-vsel_to_uv) {
- pr_warning(PMIC function to convert vsel to voltage
+ pr_warning(PMIC function to convert vsel to voltage
in uV not registerd\n);
return -EINVAL;
}
@@ -164,7 +164,7 @@ static int nom_volt_debug_get(void *data, u64 *val)
struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
if (!vdd) {
- pr_warning(Wrong paramater passed\n);
+ pr_warning(Wrong parameter passed\n);
return -EINVAL;
}
@@ -312,15 +312,14 @@ static int _pre_volt_scale(struct omap_vdd_info *vdd,
/* Check if suffiecient pmic info is available for this vdd */
if (!vdd-pmic_info) {
- pr_err(%s: Insufficient pmic info to scale the vdd_%s\n,
+ pr_err(%s: No PMIC info for vdd_%s\n,
__func__, vdd-voltdm.name);
return -EINVAL;
}
if (!vdd-pmic_info-uv_to_vsel) {
- pr_err(%s: PMIC function to convert voltage in uV to
- vsel not registered. Hence unable to scale voltage
- for vdd_%s\n, __func__, vdd-voltdm.name);
+ pr_err(%s: No PMIC function to convert voltage in uV to
+ vsel for vdd_%s\n, __func__, vdd-voltdm.name);
return -ENODATA;
}
@@ -452,7 +451,7 @@ static int vp_forceupdate_scale_voltage(struct
omap_vdd_info *vdd,
udelay(1);
}
if (timeout = VP_TRANXDONE_TIMEOUT) {
- pr_warning(%s: vdd_%s TRANXDONE timeout exceeded.
+ pr_warning(%s: vdd_%s TRANXDONE timeout exceeded.
Voltage change aborted, __func__, vdd-voltdm.name);
return -ETIMEDOUT;
}
@@ -483,7 +482,7 @@ static int vp_forceupdate_scale_voltage(struct
omap_vdd_info *vdd,
vdd-vp_data-prm_irqst_data-tranxdone_status),
VP_TRANXDONE_TIMEOUT, timeout);
if (timeout = VP_TRANXDONE_TIMEOUT)
- pr_err(%s: vdd_%s TRANXDONE timeout exceeded.
+ pr_err(%s: vdd_%s TRANXDONE timeout exceeded.
TRANXDONE never got set after the voltage update\n,
__func__, vdd-voltdm.name);
@@ -505,7 +504,7 @@ static int vp_forceupdate_scale_voltage(struct
omap_vdd_info *vdd,
if (timeout = VP_TRANXDONE_TIMEOUT)
pr_warning(%s: vdd_%s TRANXDONE timeout exceeded while trying
- to clear the TRANXDONE status\n,
+to clear the TRANXDONE status\n,
__func__, vdd-voltdm.name);
vpconfig = vdd-read_reg(prm_mod_offs, vdd-vp_data-vpconfig);
@@ -599,8 +598,7 @@ static void __init omap_vc_init(struct omap_vdd_info *vdd)
u32 vc_val;
if (!vdd-pmic_info || !vdd-pmic_info-uv_to_vsel) {
- pr_err(%s: PMIC info requried to configure vc for
- vdd_%s not populated.Hence cannot initialize vc\n,
+ pr_err(%s: No PMIC info for vdd_%s\n,
__func__, vdd-voltdm.name);
return;
}
@@ -645,9 +643,8 @@ static int __init omap_vdd_data_configure(struct
omap_vdd_info *vdd)
int ret = -EINVAL;
if (!vdd-pmic_info) {
- pr_err(%s: PMIC info requried to configure vdd_%s not
- populated.Hence cannot initialize vdd_%s\n,
- __func__, vdd-voltdm.name, vdd-voltdm.name);
+ pr_err(%s: No PMIC info for vdd_%s\n,
+ __func__, vdd-voltdm.name);
goto ovdc_out;
Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda
On Tue, Aug 9, 2011 at 8:30 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: yes! I have started this. regards keshava On Tue, Aug 9, 2011 at 8:17 PM, Felipe Balbi ba...@ti.com wrote: Hi, Keshava this one is for you (sorry for the top-post) On Tue, Aug 09, 2011 at 02:26:08PM +0300, Luciano Coelho wrote: Hi, On Mon, 2011-06-06 at 14:05 +0300, Luciano Coelho wrote: On Mon, 2011-06-06 at 14:02 +0300, Felipe Balbi wrote: On Mon, Jun 06, 2011 at 01:44:18PM +0300, Felipe Balbi wrote: looks like this is resulting from the missing hwmod conversion in mainlnie. Check if reverting 7e6502d577106fb5b202bbaac64c5f1b065e6daa helps. I verified off-list with Luca that reverting that commit does make it work. Keshava, care to send a revert patch to Sam until we get all the hwmod stuff in. Yes, I confirm that I'm not getting the oops anymore, after reverting this patch. Thanks a lot for the quick answer, dude! :) I'm again getting a very similar oops with 3.1-rc1 on my pandaboard: [ 2.054351] usbcore: registered new interface driver cdc_ncm [ 2.061431] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 2.068664] Unhandled fault: imprecise external abort (0x1406) at 0x [ 2.076110] Internal error: : 1406 [#1] SMP [ 2.080505] Modules linked in: [ 2.083709] CPU: 0 Not tainted (3.1.0-rc1-wl+ #283) [ 2.089233] PC is at omap_usbhs_enable+0x148/0x590 [ 2.094299] LR is at trace_hardirqs_off+0x14/0x18 [ 2.099243] pc : [c02a8640] lr : [c007fea0] psr: 6093 [ 2.099243] sp : df871dc8 ip : df871d80 fp : df871dec [ 2.111328] r10: 8013 r9 : df9ef9e0 r8 : df9ef9ec [ 2.116821] r7 : dfa32800 r6 : dfa316f8 r5 : c06f5da8 r4 : dfa316a0 [ 2.123687] r3 : r2 : r1 : 0001 r0 : [ 2.130584] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.138366] Control: 10c53c7d Table: 8000404a DAC: 0015 [ 2.144409] Process swapper (pid: 1, stack limit = 0xdf8702f8) [ 2.150543] Stack: (0xdf871dc8 to 0xdf872000) [ 2.155120] 1dc0: df105400 dfa32808 df105400 dfa32800 df9ef9ec 0003 [ 2.163726] 1de0: df871e8c df871df0 c0321d60 c02a8504 df871e2c df10a588 df1075a0 df10a588 [ 2.172363] 1e00: df871e2c df871e10 df10a588 df10a608 dfa28e88 006d fc064c00 [ 2.180969] 1e20: df871e6c df871e30 c015654c c0155c08 c0082098 c0071f74 0001 dfa32898 [ 2.189575] 1e40: dfa28e88 dfa32808 dfa32810 73757368 3062 [ 2.198181] 1e60: df871e7c dfa32808 c0716da8 c0716da8 [ 2.206787] 1e80: df871e9c df871e90 c0298cfc c0321bb8 df871ec4 df871ea0 c0297650 c0298ce4 [ 2.215423] 1ea0: df871ec4 dfa32808 dfa3283c dfa32808 dfa3283c c0716da8 df871ee4 df871ec8 [ 2.224029] 1ec0: c02977ec c0297504 c0716da8 c0297774 df871f0c df871ee8 [ 2.232635] 1ee0: c0296c00 c0297780 df891658 dfa31670 c023ac60 c0716da8 df1075a0 c070d6f8 [ 2.241241] 1f00: df871f1c df871f10 c0297334 c0296bb0 df871f4c df871f20 c02963ec c0297318 [ 2.249847] 1f20: c05b84a8 df871f30 c0716da8 c0c7e4c0 c0014ba0 [ 2.258483] 1f40: df871f74 df871f50 c0297f00 c0296320 c0298d44 c0c7df14 c0c7e4c0 c0014ba0 [ 2.267089] 1f60: df871f84 df871f78 c02991e0 c0297e54 df871fa4 df871f88 [ 2.275695] 1f80: c069904c c0299198 00a0 0060 c06c4e40 c0698fa4 df871fdc df871fa8 [ 2.284301] 1fa0: c0008854 c0698fb0 c0014ba0 c009960c df871fdc df871fc0 c06c4e40 c06c49dc [ 2.292907] 1fc0: c0014ba0 0013 df871ff4 df871fe0 c06792d4 c00087b8 [ 2.301513] 1fe0: c067924c df871ff8 c0014ba0 c0679258 882bf20f 3184000e [ 2.310150] [c02a8640] (omap_usbhs_enable+0x148/0x590) from [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) [ 2.320526] [c0321d60] (ehci_hcd_omap_probe+0x1b4/0x568) from [c0298cfc] (platform_drv_probe+0x24/0x28) [ 2.330780] [c0298cfc] (platform_drv_probe+0x24/0x28) from [c0297650] (driver_probe_device+0x158/0x27c) [ 2.341033] [c0297650] (driver_probe_device+0x158/0x27c) from [c02977ec] (__driver_attach+0x78/0x9c) [ 2.351043] [c02977ec] (__driver_attach+0x78/0x9c) from [c0296c00] (bus_for_each_dev+0x5c/0x8c) [ 2.360565] [c0296c00] (bus_for_each_dev+0x5c/0x8c) from [c0297334] (driver_attach+0x28/0x30) [ 2.369903] [c0297334] (driver_attach+0x28/0x30) from [c02963ec] (bus_add_driver+0xd8/0x260) [ 2.379180] [c02963ec] (bus_add_driver+0xd8/0x260) from [c0297f00] (driver_register+0xb8/0x144) [ 2.388702] [c0297f00] (driver_register+0xb8/0x144) from [c02991e0] (platform_driver_register+0x54/0x68) [ 2.399047] [c02991e0] (platform_driver_register+0x54/0x68) from [c069904c] (ehci_hcd_init+0xa8/0xfc) [ 2.409149] [c069904c] (ehci_hcd_init+0xa8/0xfc) from [c0008854]
Re: How to handle named resources with DT?
Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas = 12, rx_req, 13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. BTW, it's strange that a default support does not exist for dma request (and not channel). The mechanism is similar to irq line, and quite standard to many SoC AFAIK. Or maybe I missed it. BTW, this is not required for omap since dt-hwmod binding will fetch pdev pointer from hwmod database and it will be used as is without any modification which inturn does not break any existing pm functionality. Well for the moment... but I have some long term plan as well:-) Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
On Tuesday, August 09, 2011 1:08 AM, Russell King wrote: Consolidate 24 trivial gpiolib implementions out of mach/gpio.h into asm/gpio.h. This is basically the include of asm-generic/gpio.h and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep as described in Documentation/gpio.txt Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/include/asm/gpio.h | 10 ++ arch/arm/mach-ep93xx/include/mach/gpio.h|7 +-- diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h index 166a7a3..15e8970 100644 --- a/arch/arm/include/asm/gpio.h +++ b/arch/arm/include/asm/gpio.h @@ -4,4 +4,14 @@ /* not all ARM platforms necessarily support this API ... */ #include mach/gpio.h +#ifdef __ARM_GPIOLIB_TRIVIAL +/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */ +#include asm-generic/gpio.h + +/* The trivial gpiolib dispatchers */ +#define gpio_get_value __gpio_get_value +#define gpio_set_value __gpio_set_value +#define gpio_cansleep __gpio_cansleep +#endif + #endif /* _ARCH_ARM_GPIO_H */ diff --git a/arch/arm/mach-ep93xx/include/mach/gpio.h b/arch/arm/mach-ep93xx/include/mach/gpio.h index c57152c..fbc770e 100644 --- a/arch/arm/mach-ep93xx/include/mach/gpio.h +++ b/arch/arm/mach-ep93xx/include/mach/gpio.h @@ -100,12 +100,7 @@ #define EP93XX_GPIO_LINE_MAX_IRQ EP93XX_GPIO_LINE_F(7) /* new generic GPIO API - see Documentation/gpio.txt */ - -#include asm-generic/gpio.h - -#define gpio_get_value __gpio_get_value -#define gpio_set_value __gpio_set_value -#define gpio_cansleep__gpio_cansleep +#define __ARM_GPIOLIB_TRIVIAL /* * Map GPIO A0..A7 (0..7) to irq 64..71, For ep93xx: Acked-by: H Hartley Sweeten hswee...@visionengravers.com Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/13] ARM: gpio: make trivial GPIOLIB implementation the default
On Tuesday, August 09, 2011 1:09 AM, Russell King wrote: Rather than marking the mach/gpio.h header files which want to use the trivial GPIOLIB implementation, mark those which do not want to use it instead. This means that by default, you get the trivial implementation and only have to do something extra if you need to. This should encourage the use of the trivial default implementation. As an additional bonus, several gpio.h header files become empty. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/include/asm/gpio.h |2 +- arch/arm/include/asm/hardware/iop3xx-gpio.h |2 ++ diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h index 5032224..11ad0bf 100644 --- a/arch/arm/include/asm/gpio.h +++ b/arch/arm/include/asm/gpio.h @@ -4,7 +4,7 @@ /* not all ARM platforms necessarily support this API ... */ #include mach/gpio.h -#ifdef __ARM_GPIOLIB_TRIVIAL +#ifndef __ARM_GPIOLIB_COMPLEX /* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */ #include asm-generic/gpio.h diff --git a/arch/arm/mach-ep93xx/include/mach/gpio.h b/arch/arm/mach-ep93xx/include/mach/gpio.h index fbc770e..071f676 100644 --- a/arch/arm/mach-ep93xx/include/mach/gpio.h +++ b/arch/arm/mach-ep93xx/include/mach/gpio.h @@ -99,9 +99,6 @@ /* maximum value for irq capable line identifiers */ #define EP93XX_GPIO_LINE_MAX_IRQ EP93XX_GPIO_LINE_F(7) -/* new generic GPIO API - see Documentation/gpio.txt */ -#define __ARM_GPIOLIB_TRIVIAL - /* * Map GPIO A0..A7 (0..7) to irq 64..71, * B0..B7 (7..15) to irq 72..79, and For ep93xx: Acked-by: H Hartley Sweeten hswee...@visionengravers.com Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas = 12, rx_req, 13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. DMA channels will never show up in the resource structure anyway. The common code only takes care of translating IRQ and register ranges. For DMA you'll need a binding for the dma channels. You can either make them explicitly ordered, or use different property names for each of the dma channels. BTW, it's strange that a default support does not exist for dma request (and not channel). The mechanism is similar to irq line, and quite standard to many SoC AFAIK. Or maybe I missed it. DMA channels haven't historically had the same global scope that irq numbers have. There hasn't been a pressing need up to now to have common infrastructure, though it is probably a good idea to define a common binding. BTW, this is not required for omap since dt-hwmod binding will fetch pdev pointer from hwmod database and it will be used as is without any modification which inturn does not break any existing pm functionality. Well for the moment... but I have some long term plan as well:-) Thanks, Benoit ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 8/9/2011 7:23 PM, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. That seems to be a small regression for my point of view. Relying on the order is not super safe. This is not very readable either. That's for that exact reason that we changed our drivers to use platform_get_resource_byname. That's probably the reason why that API is there as well. For the same IP, the number of entries can vary depending of the SoC revision. By using the _byname, we can check if the resource is there or not without having to care about the position. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas =12, rx_req,13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. DMA channels will never show up in the resource structure anyway. Can you elaborate on that point? AFAIK, IORESOURCE_DMA is already used today. The common code only takes care of translating IRQ and register ranges. For DMA you'll need a binding for the dma channels. You can either make them explicitly ordered, or use different property names for each of the dma channels. FWIW, DMA channel != DMA request. The DMA request is a physical line that is connected to a DMA controller. It is similar to an IRQ connected to an interrupt controller. It is a HW resource like an IRQ. The DMA channel is a logical entry in the DMA controller that will be used by the driver. BTW, it's strange that a default support does not exist for dma request (and not channel). The mechanism is similar to irq line, and quite standard to many SoC AFAIK. Or maybe I missed it. DMA channels haven't historically had the same global scope that irq numbers have. There hasn't been a pressing need up to now to have common infrastructure, though it is probably a good idea to define a common binding. Cool, I think so as well. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Aug 9, 2011, at 1:47 PM, Cousson, Benoit wrote: On 8/9/2011 7:23 PM, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. That seems to be a small regression for my point of view. Relying on the order is not super safe. This is not very readable either. That's for that exact reason that we changed our drivers to use platform_get_resource_byname. That's probably the reason why that API is there as well. That's exactly what the reasoning was for adding it. http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-12/1944.html -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
On Tue, Aug 09, 2011 at 09:08:01AM +0100, Russell King - ARM Linux wrote: Consolidate 24 trivial gpiolib implementions out of mach/gpio.h into asm/gpio.h. This is basically the include of asm-generic/gpio.h and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep as described in Documentation/gpio.txt Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-msm/include/mach/gpio.h |5 + For msm (msm8660): Tested-by: David Brown dav...@codeaurora.org Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] Add support for TI814X processor series
Hello, Pedanekar, Hemant wrote on Thursday, August 04, 2011 11:14 PM: This patch set adds support for DM814x, C6A814x and AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM [...] Any comments on this patch set? Thanks. Hemant-- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg = 0x2 0x200 0x24000 0x200;
foo-reg = 0;
bar-reg = 1;
};
-Scott
--
To unsubscribe from this list: send the line unsubscribe 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: [beagleboard] EHCI softirq kernel panic
On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes agnel.j...@gmail.com wrote: Anyone seen this before? A lot of the kernel developers don't frequent the beagleboard list. If you think it is a general kernel bug, I suspect you want to copy linux-omap. Trying to boot 3.0.0 with OE patches from an SD Card, and with a network cable connected results in the following traceback. Not connecting a network cable makes the errors go away. [ 83.386779] Process gtk-update-icon (pid: 351, stack limit = 0xdd95c2f0) [ 83.393798] Stack: (0xdd95dfb0 to 0xdd95e000) [ 83.398345] dfa0: 007f9225 007ba664 00bf 2fff [ 83.406890] dfc0: 00ff2f2f 00ff 00ff 00ff 00ff 00ff 00799225 [ 83.415435] dfe0: 00ff be9f8780 00ff 4027e084 2010 [ 83.423980] Code: bad PC value [ 83.427490] ---[ end trace 4ae88755f08e391e ]--- [ 83.434570] S98configure[58]: Segmentation fault [ 83.840148] S98configure[58]: Segmentation fault [ 83.867004] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 89.605407] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File exists [ 89.932525] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/Mist/.icon-theme.cache : File exists [ 89.967773] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 91.477386] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File exists [ 91.788269] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/Mist/.icon-theme.cache : File exists [ 91.822631] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 94.313598] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File exists [ 95.381011] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/Mist/.icon-theme.cache : File exists [ 95.415405] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 99.084899] Unable to handle kernel NULL pointer dereference at virtual address [ 99.093383] pgd = c0004000 [ 99.096191] [] *pgd= [ 99.099945] Internal error: Oops: 17 [#2] [ 99.104125] Modules linked in: ipv6 [ 99.107788] CPU: 0 Tainted: G D (3.0.0+ #1) [ 99.113342] PC is at ehci_quiesce+0xc/0x94 [ 99.117614] LR is at ehci_stop+0x34/0x8c [ 99.121734] pc : [c0325ce4] lr : [c0328bfc] psr: 21d3 [ 99.121734] sp : c064de70 ip : 0108 fp : c06b8624 [ 99.133728] r10: c064dec0 r9 : r8 : dee08504 [ 99.139190] r7 : c0328b94 r6 : 0100 r5 : dee08504 r4 : dee08608 [ 99.145996] r3 : r2 : dee086ec r1 : dee086b8 r0 : dee08608 [ 99.152832] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 99.160644] Control: 10c5387d Table: 9d804019 DAC: 0015 [ 99.166656] Process swapper (pid: 0, stack limit = 0xc064c2f0) [ 99.172760] Stack: (0xc064de70 to 0xc064e000) [ 99.177307] de60: dee08608 dee086b8 dee08608 dee08504 [ 99.185852] de80: 0100 c0328bfc 0001 a153 dee08504 c007a3d4 00200200 6153 [ 99.194396] dea0: dee08504 c007a3d4 00200200 c06b87a0 c064c000 c007a3d4 c064c000 0003 [ 99.202941] dec0: c064dec0 c064dec0 000a 0001 c06b8628 c064c000 0100 c06b8600 [ 99.211517] dee0: 000a c0075ec0 a246 c0677bdc 0001 0003 0025 [ 99.220062] df00: c0654258 0003 0003 413fc082 c0076290 [ 99.228607] df20: 0025 c0040064 6053 fa20 c0044ff8 00051f4d [ 99.237152] df40: 00051f4d c06a662c c0654258 c0654258 0003 0003 413fc082 [ 99.245697] df60: c064df80 c0054dcc c0054dd8 6053 [ 99.254272] df80: 00051f4d 0063 04aae30b 0063 04a5c3be 0001 [ 99.262817] dfa0: c0654248 c0654258 c06d7a6c c0377404 c064c000 c0652254 c06a5d04 c065224c [ 99.271362] dfc0: 80004059 c0045f40 c064e9b4 c003341c c0ae1140 c0008868 c00082c8 060a [ 99.279907] dfe0: 8100 c003341c 10c53c7d c064e060 c0033418 8000803c [ 99.288482] [c0325ce4] (ehci_quiesce+0xc/0x94) from [c0328bfc] (ehci_stop+0x34/0x8c) [ 99.296936] [c0328bfc] (ehci_stop+0x34/0x8c) from [c007a3d4] (run_timer_softirq+0x15c/0x1f8) [ 99.306121] [c007a3d4] (run_timer_softirq+0x15c/0x1f8) from [c064dec0] (0xc064dec0) [ 99.314483] Code: c05d7f9a e92d4073
Re: [PATCH 06/13] ARM: gpio: davinci: convert drivers to use asm/gpio.h rather than mach/gpio.h
On Tue, Aug 09, 2011 at 04:06:14PM +0400, Sergei Shtylyov wrote: Hello. On 09-08-2011 12:06, Russell King - ARM Linux wrote: CCing linux-usb and Felipe... Signed-off-by: Russell Kingrmk+ker...@arm.linux.org.uk --- drivers/usb/musb/davinci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index 8bdf25a..f9a3f62 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -35,7 +35,7 @@ #includemach/hardware.h #includemach/memory.h -#includemach/gpio.h +#includeasm/gpio.h Shouldn't this now be moved to the below #include group? When doing this kind of work with sed -i, that doesn't happen. There's too much of this crap (and I've been telling people about this for at least a year) that I don't think there's that luxury anymore. If maintainers would have paid more attention, then most of these changes would not be necessary. My view is that if maintainers do care about this stuff _they_ should have been the ones to pick up on it long ago. In other words, they've lost the right to complain about petty crap like the ordering of includes through their own inaction on this point. -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. Do you have any plan to add that, or do you have any clean way to avoid that without having to use the resource index? Named resources are evil. You only have to look at /proc/iomem to see why that's the case. Here's an example: b7a01000-b7a01003 : set b7a01000-b7a01003 : set b7a01004-b7a01007 : dat b7a01004-b7a01007 : dat b7a01008-b7a0100b : dirout b7a01008-b7a0100b : dirout b7a01020-b7a01023 : set b7a01020-b7a01023 : set b7a01024-b7a01027 : dat b7a01024-b7a01027 : dat b7a01028-b7a0102b : dirout b7a01028-b7a0102b : dirout b7a01040-b7a01043 : set b7a01040-b7a01043 : set b7a01044-b7a01047 : dat b7a01044-b7a01047 : dat b7a01048-b7a0104b : dirout b7a01048-b7a0104b : dirout b7a01060-b7a01063 : set b7a01060-b7a01063 : set b7a01064-b7a01067 : dat b7a01064-b7a01067 : dat b7a01068-b7a0106b : dirout b7a01068-b7a0106b : dirout b7a01080-b7a01083 : set b7a01080-b7a01083 : set b7a01084-b7a01087 : dat b7a01084-b7a01087 : dat b7a01088-b7a0108b : dirout b7a01088-b7a0108b : dirout How very informative. Not. So what device owns those? Who knows, that's lost by the crappy named resource stuff. -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote: On 8/9/2011 7:23 PM, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. That seems to be a small regression for my point of view. Relying on the order is not super safe. This is not very readable either. That's for that exact reason that we changed our drivers to use platform_get_resource_byname. That's probably the reason why that API is there as well. For the same IP, the number of entries can vary depending of the SoC revision. By using the _byname, we can check if the resource is there or not without having to care about the position. We've done it that way for a very long time with the device tree. If you want to do something by name, then propose a binding that will make it work alongside the existing scheme. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas =12, rx_req,13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. DMA channels will never show up in the resource structure anyway. Can you elaborate on that point? AFAIK, IORESOURCE_DMA is already used today. IORESOURCE_DMA is a Linux construct, as is IORESOURCE_IRQ and IORESOURCE_MEM. However, IRQ and MEM can be directly mapped from the common 'reg' and 'interrupts' bindings used by pretty much all device tree nodes. Therefore common code can be written to translate MEM and IRQ that will always work. There is no such common binding in place for DMA regions, so common setup code cannot do it transparently for the device driver. g. -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg = 0x2 0x200 0x24000 0x200;
foo-reg = 0;
bar-reg = 1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
g.
--
To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 8/9/2011 9:51 PM, Russell King - ARM Linux wrote: On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. Do you have any plan to add that, or do you have any clean way to avoid that without having to use the resource index? Named resources are evil. You only have to look at /proc/iomem to see why that's the case. Here's an example: b7a01000-b7a01003 : set b7a01000-b7a01003 : set So what? That just shows that /proc/iomem outputs sucks, but that does not prove that named resources are evil. [...] How very informative. Not. So what device owns those? Who knows, that's lost by the crappy named resource stuff. Maybe, but this is not lost by the platform_device, and this is what really matters in this case. We need to get the resource local to a device, we do not care about the global view. This is exactly what the platform_get_resource_byname is doing. For my point of view, the need for that is similar to the clkdev / clk_get(dev, name) you did. For sure, in that case, the real global clock name is still relevant, but the important point for the driver is the local device name. Not providing the name of the resource will give you the device name, but how informative is that for the driver? What entry is the good one in the middle of that list? b7a01040-b7a01043 : omap_foo b7a01044-b7a01047 : omap_foo b7a01048-b7a0104b : omap_foo b7a01060-b7a01063 : omap_foo Bottom-line, in both cases, /proc/iomem sucks... But who cares about the internal representation? A platform_driver can still take advantage of that, and this is exactly what we are looking for. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] Clean up mach/gpio.h headers
On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote:
This is a preliminary posting of my gpio patch set.
This patch series moves the trivial gpiolib implementations out of
mach/gpio.h and into asm/gpio.h.
As a side effect of that, most of this patch series is about fixing up
direct includes of mach/gpio.h - this is something I've been on at
people over the last year or more about ensuring that they use
linux/gpio.h in preference. While I've blindly converted all arch/arm
to use linux/gpio.h (with the exception of mach/ includes which are
converted to asm/gpio.h), drivers were only converted to asm/gpio.h.
These should be reviewed and changed to linux/gpio.h.
As a result of this patch series, several mach/gpio.h end up being
empty.
Many others just contain platform private GPIO APIs and definitions.
The last thing which mach/gpio.h is used for is to provide a definition
for ARCH_GPIO_NR to asm-generic/gpio.h. I've not attempted to solve
that issue yet.
A small number of platforms optimize the gpio accessors for on-SoC
GPIOs. In the interests of consolidation, these will have to be killed
but this patch set does not do that yet.
Lastly, several {mach,plat}/gpio.h needs to be looked at with a view to
deleting the direct include of asm-generic/gpio.h.
Looks good to me, though I haven't looked closely. I imagine this
should get merged via a branch in the arm-soc tree?
g.
--
To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 8/9/2011 10:55 PM, Grant Likely wrote: On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote: On 8/9/2011 7:23 PM, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. That seems to be a small regression for my point of view. Relying on the order is not super safe. This is not very readable either. That's for that exact reason that we changed our drivers to use platform_get_resource_byname. That's probably the reason why that API is there as well. For the same IP, the number of entries can vary depending of the SoC revision. By using the _byname, we can check if the resource is there or not without having to care about the position. We've done it that way for a very long time with the device tree. If you want to do something by name, then propose a binding that will make it work alongside the existing scheme. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas =12, rx_req,13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. DMA channels will never show up in the resource structure anyway. Can you elaborate on that point? AFAIK, IORESOURCE_DMA is already used today. IORESOURCE_DMA is a Linux construct, as is IORESOURCE_IRQ and IORESOURCE_MEM. However, IRQ and MEM can be directly mapped from the common 'reg' and 'interrupts' bindings used by pretty much all device tree nodes. Therefore common code can be written to translate MEM and IRQ that will always work. There is no such common binding in place for DMA regions, so common setup code cannot do it transparently for the device driver. OK, sure, I get your point now. I was thinking about a potential dma support from the core DT, since this is very similar to IRQ. Otherwise, we can do it OMAP specific if nobody else care about that. But I still think it should be useful for other platforms. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =0x2 0x200 0x24000 0x200;
foo-reg =0;
bar-reg =1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
Yep, I agree.
And what about something like that?
reg = 0x2 0x200, foo,
0x2 0x200, bar ;
It is doable?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote: On 8/9/2011 10:55 PM, Grant Likely wrote: On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote: On 8/9/2011 7:23 PM, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. That seems to be a small regression for my point of view. Relying on the order is not super safe. This is not very readable either. That's for that exact reason that we changed our drivers to use platform_get_resource_byname. That's probably the reason why that API is there as well. For the same IP, the number of entries can vary depending of the SoC revision. By using the _byname, we can check if the resource is there or not without having to care about the position. We've done it that way for a very long time with the device tree. If you want to do something by name, then propose a binding that will make it work alongside the existing scheme. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas =12, rx_req,13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. DMA channels will never show up in the resource structure anyway. Can you elaborate on that point? AFAIK, IORESOURCE_DMA is already used today. IORESOURCE_DMA is a Linux construct, as is IORESOURCE_IRQ and IORESOURCE_MEM. However, IRQ and MEM can be directly mapped from the common 'reg' and 'interrupts' bindings used by pretty much all device tree nodes. Therefore common code can be written to translate MEM and IRQ that will always work. There is no such common binding in place for DMA regions, so common setup code cannot do it transparently for the device driver. OK, sure, I get your point now. I was thinking about a potential dma support from the core DT, since this is very similar to IRQ. Otherwise, we can do it OMAP specific if nobody else care about that. But I still think it should be useful for other platforms. I think people care, and it will be a net win, but it does mean you need do the work of crafting a binding that will work for a large proportion of SoCs. g. -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =0x2 0x200 0x24000 0x200;
foo-reg =0;
bar-reg =1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
Yep, I agree.
And what about something like that?
reg = 0x2 0x200, foo,
0x2 0x200, bar ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
g.
--
To unsubscribe from this list: send the line unsubscribe 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 00/13] Clean up mach/gpio.h headers
On Tue, Aug 09, 2011 at 03:00:55PM -0600, Grant Likely wrote:
On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote:
This is a preliminary posting of my gpio patch set.
This patch series moves the trivial gpiolib implementations out of
mach/gpio.h and into asm/gpio.h.
As a side effect of that, most of this patch series is about fixing up
direct includes of mach/gpio.h - this is something I've been on at
people over the last year or more about ensuring that they use
linux/gpio.h in preference. While I've blindly converted all arch/arm
to use linux/gpio.h (with the exception of mach/ includes which are
converted to asm/gpio.h), drivers were only converted to asm/gpio.h.
These should be reviewed and changed to linux/gpio.h.
As a result of this patch series, several mach/gpio.h end up being
empty.
Many others just contain platform private GPIO APIs and definitions.
The last thing which mach/gpio.h is used for is to provide a definition
for ARCH_GPIO_NR to asm-generic/gpio.h. I've not attempted to solve
that issue yet.
A small number of platforms optimize the gpio accessors for on-SoC
GPIOs. In the interests of consolidation, these will have to be killed
but this patch set does not do that yet.
Lastly, several {mach,plat}/gpio.h needs to be looked at with a view to
deleting the direct include of asm-generic/gpio.h.
Looks good to me, though I haven't looked closely. I imagine this
should get merged via a branch in the arm-soc tree?
And this is where the existence of the arm-soc tree makes things more
difficult for me. I'd normally just keep it as a separate branch in
my own tree. What I do now, I've no idea.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On 8/9/2011 11:16 PM, Grant Likely wrote: On Tue, Aug 09, 2011 at 11:06:30PM +0200, Cousson, Benoit wrote: On 8/9/2011 10:55 PM, Grant Likely wrote: On Tue, Aug 09, 2011 at 07:47:20PM +0200, Cousson, Benoit wrote: On 8/9/2011 7:23 PM, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoitb-cous...@ti.comwrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. That seems to be a small regression for my point of view. Relying on the order is not super safe. This is not very readable either. That's for that exact reason that we changed our drivers to use platform_get_resource_byname. That's probably the reason why that API is there as well. For the same IP, the number of entries can vary depending of the SoC revision. By using the _byname, we can check if the resource is there or not without having to care about the position. We've done it that way for a very long time with the device tree. If you want to do something by name, then propose a binding that will make it work alongside the existing scheme. For IORESOURCE_DMA, you can have property dma-channel in dtsi file and fetch dma-channel in driver probe through of_property_read_u32() api. That will not be enough to get the name. So maybe something like: dmas =12, rx_req,13, tx_req; will be doable. The issue is that the name is optional so managing the multiple entries might be tricky. DMA channels will never show up in the resource structure anyway. Can you elaborate on that point? AFAIK, IORESOURCE_DMA is already used today. IORESOURCE_DMA is a Linux construct, as is IORESOURCE_IRQ and IORESOURCE_MEM. However, IRQ and MEM can be directly mapped from the common 'reg' and 'interrupts' bindings used by pretty much all device tree nodes. Therefore common code can be written to translate MEM and IRQ that will always work. There is no such common binding in place for DMA regions, so common setup code cannot do it transparently for the device driver. OK, sure, I get your point now. I was thinking about a potential dma support from the core DT, since this is very similar to IRQ. Otherwise, we can do it OMAP specific if nobody else care about that. But I still think it should be useful for other platforms. I think people care, and it will be a net win, but it does mean you need do the work of crafting a binding that will work for a large proportion of SoCs. The devil is in the details, but the way the DMA lines are connected in OMAP is similar to IRQ lines, and maybe a little bit simpler. So starting with a copy/paste of the of_irq file should be a good start. And then the issues will start:-) Benoit g. -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =0x2 0x200 0x24000 0x200;
foo-reg =0;
bar-reg =1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
Yep, I agree.
And what about something like that?
reg =0x2 0x200, foo,
0x2 0x200, bar ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = foo_wrapper;
start = 0x1;
end = 0x200;
}
reg {
name = foo;
start = 0x2;
end = 0x200;
}
}
A little bit more verbose, but at least we can add any attribute we want.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =0x2 0x200 0x24000 0x200;
foo-reg =0;
bar-reg =1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
Yep, I agree.
And what about something like that?
reg =0x2 0x200, foo,
0x2 0x200, bar ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = foo_wrapper;
start = 0x1;
end = 0x200;
}
reg {
name = foo;
start = 0x2;
end = 0x200;
}
}
A little bit more verbose, but at least we can add any attribute we want.
That won't work either because that also breaks the existing 'reg'
binding. Anything you do will need to supplement the existing
binding without changing it in an incompatible way.
g.
--
To unsubscribe from this list: send the line unsubscribe 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 00/13] Clean up mach/gpio.h headers
On Tue, Aug 09, 2011 at 10:32:30PM +0100, Russell King - ARM Linux wrote:
On Tue, Aug 09, 2011 at 03:00:55PM -0600, Grant Likely wrote:
On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote:
This is a preliminary posting of my gpio patch set.
This patch series moves the trivial gpiolib implementations out of
mach/gpio.h and into asm/gpio.h.
As a side effect of that, most of this patch series is about fixing up
direct includes of mach/gpio.h - this is something I've been on at
people over the last year or more about ensuring that they use
linux/gpio.h in preference. While I've blindly converted all arch/arm
to use linux/gpio.h (with the exception of mach/ includes which are
converted to asm/gpio.h), drivers were only converted to asm/gpio.h.
These should be reviewed and changed to linux/gpio.h.
As a result of this patch series, several mach/gpio.h end up being
empty.
Many others just contain platform private GPIO APIs and definitions.
The last thing which mach/gpio.h is used for is to provide a definition
for ARCH_GPIO_NR to asm-generic/gpio.h. I've not attempted to solve
that issue yet.
A small number of platforms optimize the gpio accessors for on-SoC
GPIOs. In the interests of consolidation, these will have to be killed
but this patch set does not do that yet.
Lastly, several {mach,plat}/gpio.h needs to be looked at with a view to
deleting the direct include of asm-generic/gpio.h.
Looks good to me, though I haven't looked closely. I imagine this
should get merged via a branch in the arm-soc tree?
And this is where the existence of the arm-soc tree makes things more
difficult for me. I'd normally just keep it as a separate branch in
my own tree. What I do now, I've no idea.
A separate branch in your tree works too. It could even get pulled
into the arm-soc tree so that it gets picked up by the daily
integration test before going on to linux-next.
g.
--
To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 08/09/2011 04:44 PM, Cousson, Benoit wrote:
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = foo_wrapper;
start = 0x1;
end = 0x200;
}
reg {
name = foo;
start = 0x2;
end = 0x200;
}
}
A little bit more verbose, but at least we can add any attribute we want.
A more standard way to do that would be something like:
dev {
#address-cells = 1;
#size-cells = 1;
ranges;
foo {
reg = 0x1 0x200;
};
bar {
reg = 0x2 0x200;
};
};
...which is OK if you need the expressiveness of a full hierarchy (and
don't have some other meaning for child nodes of dev), but it seems
like it would be overkill for some places where named resources would be
useful.
-Scott
--
To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On 8/9/2011 11:49 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =0x2 0x200 0x24000 0x200;
foo-reg =0;
bar-reg =1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
Yep, I agree.
And what about something like that?
reg =0x2 0x200, foo,
0x2 0x200, bar ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = foo_wrapper;
start =0x1;
end =0x200;
}
reg {
name = foo;
start =0x2;
end =0x200;
}
}
A little bit more verbose, but at least we can add any attribute we want.
That won't work either because that also breaks the existing 'reg'
binding. Anything you do will need to supplement the existing
binding without changing it in an incompatible way.
OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
reg_named...?
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [beagleboard] EHCI softirq kernel panic
Hi,
On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote:
On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes agnel.j...@gmail.com wrote:
Anyone seen this before?
A lot of the kernel developers don't frequent the beagleboard list.
If you think it is a general kernel bug, I suspect you want to copy
linux-omap.
and linux-usb, and Alan Stern as he's the EHCI maintainer and myself for
the OMAP USB part ;-)
Trying to boot 3.0.0 with OE patches from an SD Card, and with a
network cable connected results in the following traceback.
Not connecting a network cable makes the errors go away.
[ 83.386779] Process gtk-update-icon (pid: 351, stack limit = 0xdd95c2f0)
[ 83.393798] Stack: (0xdd95dfb0 to 0xdd95e000)
[ 83.398345] dfa0: 007f9225
007ba664 00bf 2fff
[ 83.406890] dfc0: 00ff2f2f 00ff 00ff 00ff 00ff
00ff 00799225
[ 83.415435] dfe0: 00ff be9f8780 00ff 4027e084 2010
[ 83.423980] Code: bad PC value
[ 83.427490] ---[ end trace 4ae88755f08e391e ]---
[ 83.434570] S98configure[58]: Segmentation fault
[ 83.840148] S98configure[58]: Segmentation fault
[ 83.867004] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/gnome/.icon-theme.cache : File exists
[ 89.605407] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File
exists
[ 89.932525] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/Mist/.icon-theme.cache : File exists
[ 89.967773] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/gnome/.icon-theme.cache : File exists
[ 91.477386] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File
exists
[ 91.788269] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/Mist/.icon-theme.cache : File exists
[ 91.822631] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/gnome/.icon-theme.cache : File exists
[ 94.313598] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File
exists
[ 95.381011] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/Mist/.icon-theme.cache : File exists
[ 95.415405] S98configure[58]: gtk-update-icon-cache: Failed to open
file /usr/share/icons/gnome/.icon-theme.cache : File exists
[ 99.084899] Unable to handle kernel NULL pointer dereference at
virtual address
[ 99.093383] pgd = c0004000
[ 99.096191] [] *pgd=
[ 99.099945] Internal error: Oops: 17 [#2]
[ 99.104125] Modules linked in: ipv6
[ 99.107788] CPU: 0 Tainted: G D (3.0.0+ #1)
[ 99.113342] PC is at ehci_quiesce+0xc/0x94
[ 99.117614] LR is at ehci_stop+0x34/0x8c
[ 99.121734] pc : [c0325ce4] lr : [c0328bfc] psr: 21d3
[ 99.121734] sp : c064de70 ip : 0108 fp : c06b8624
[ 99.133728] r10: c064dec0 r9 : r8 : dee08504
[ 99.139190] r7 : c0328b94 r6 : 0100 r5 : dee08504 r4 : dee08608
[ 99.145996] r3 : r2 : dee086ec r1 : dee086b8 r0 : dee08608
[ 99.152832] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM
Segment kernel
[ 99.160644] Control: 10c5387d Table: 9d804019 DAC: 0015
[ 99.166656] Process swapper (pid: 0, stack limit = 0xc064c2f0)
[ 99.172760] Stack: (0xc064de70 to 0xc064e000)
[ 99.177307] de60: dee08608
dee086b8 dee08608 dee08504
[ 99.185852] de80: 0100 c0328bfc 0001 a153 dee08504
c007a3d4 00200200 6153
[ 99.194396] dea0: dee08504 c007a3d4 00200200 c06b87a0 c064c000
c007a3d4 c064c000 0003
[ 99.202941] dec0: c064dec0 c064dec0 000a 0001 c06b8628
c064c000 0100 c06b8600
[ 99.211517] dee0: 000a c0075ec0 a246 c0677bdc
0001 0003 0025
[ 99.220062] df00: c0654258 0003 0003 413fc082
c0076290
[ 99.228607] df20: 0025 c0040064 6053 fa20
c0044ff8 00051f4d
[ 99.237152] df40: 00051f4d c06a662c c0654258 c0654258
0003 0003 413fc082
[ 99.245697] df60: c064df80 c0054dcc
c0054dd8 6053
[ 99.254272] df80: 00051f4d 0063 04aae30b 0063
04a5c3be 0001
[ 99.262817] dfa0: c0654248 c0654258 c06d7a6c c0377404 c064c000
c0652254 c06a5d04 c065224c
[ 99.271362] dfc0: 80004059 c0045f40 c064e9b4 c003341c c0ae1140
c0008868 c00082c8 060a
[ 99.279907] dfe0: 8100 c003341c 10c53c7d c064e060 c0033418
8000803c
[ 99.288482] [c0325ce4] (ehci_quiesce+0xc/0x94) from [c0328bfc]
Re: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 11:23:45AM -0600, Grant Likely wrote: On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Manju, On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote: Hi Benoit, On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote: Hi Grant, Trying to bind hwmod informations with DT, I'm facing a little limitation. A bunch of drivers are using the platform_get_resource_byname, so the name for the resource is needed. The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and IORESOURCE_DMA types of resources. IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and it will be part of pdev. Yes, but without the proper name in the resource structure. It will be then impossible to use the platform_get_resource_byname function that is currently used by a bunch of drivers. There is no analogous mechanism for _byname in the device tree. The DT binding for a device must explicitly state what order the register ranges are in. The driver will need to be adapted. Well, the driver proper shouldn't need changing. It should be possible to assign the correct names in the glue which translates the DT reg entries into the Linux resource structures. The difficulty with adding th enames to the DT itself is that it exposes the essentially Linux-specific names in what's supposed to be an OS neutral data structure. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- To unsubscribe from this list: send the line unsubscribe 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: How to handle named resources with DT?
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on
the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API
is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =0x2 0x200 0x24000 0x200;
foo-reg =0;
bar-reg =1;
};
That's a little nasty. A reg-names = foo, bar; would probably be
better.
Yep, I agree.
And what about something like that?
reg =0x2 0x200, foo,
0x2 0x200, bar ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = foo_wrapper;
start =0x1;
end =0x200;
}
reg {
name = foo;
start =0x2;
end =0x200;
}
}
A little bit more verbose, but at least we can add any attribute we want.
That won't work either because that also breaks the existing 'reg'
binding. Anything you do will need to supplement the existing
binding without changing it in an incompatible way.
OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
reg_named...?
He already suggested reg-names to be interpreted in parallel with the
existing reg property. The (serious) problem with replacing the reg
property is that it will break all existing OSes (including old Linux
versions) that don't understand the new property.
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
name mapping in the Linux driver.
In short, yes, named reg elements in the DT would be nice in theory,
but I'm not convinced it's worth a DT flag day to accomplish it.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: send the line unsubscribe 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: Build failure: bisected: v3.1-rc1 with config ARCH_OMAP !ARCH_OMAP4 fails with linker error
On Tue, 9 Aug 2011, Tony Lindgren wrote: Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected: arch/arm/mach-omap2/built-in.o: In function `_enable_module': arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to `omap4_cminst_module_enable' arch/arm/mach-omap2/built-in.o: In function `_disable_module': arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to `omap4_cminst_module_disable' arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable': arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to `omap4_cminst_wait_module_idle' distcc[27594] ERROR: compile (null) on localhost failed make: *** [.tmp_vmlinux1] Error 1 Care to take a look? Weird, those don't show up on my n800 config (below) with CodeSourcery 2010.09-50. Looks like something isn't removing the dead code. will post a patch for this. If you post which compiler you're using, I'll add it to my build tests too... - Paul # # Automatically generated make config: don't edit # Linux/arm 3.0.0-rc7 Kernel Configuration # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_SCHED_CLOCK=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_KTIME_SCALAR=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_VECTORS_BASE=0x # CONFIG_ARM_PATCH_PHYS_VIRT is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_FHANDLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y # CONFIG_SPARSE_IRQ is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_PERF_COUNTERS is not set # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set # CONFIG_INLINE_SPIN_UNLOCK is not set # CONFIG_INLINE_SPIN_UNLOCK_BH is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set #
[PATCH] omap: timer: Set dmtimer used as clocksource in autoreload mode
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the timer stops counting once overflow occurs as it was not set in autoreload mode. This results into timekeeping failure: for example, 'sleep 1' at the shell after the timer counter overflow would hang. This patch sets up autoreload when starting the clocksource timer which fixes the above issue. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index e964072..796b935 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -293,7 +293,7 @@ static void __init omap2_gp_clocksource_init(int gptimer_id, pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n, gptimer_id, clksrc.rate); - __omap_dm_timer_load_start(clksrc.io_base, OMAP_TIMER_CTRL_ST, 0, 1); + omap_dm_timer_set_load_start(clksrc, 1, 0); init_sched_clock(cd, dmtimer_update_sched_clock, 32, clksrc.rate); if (clocksource_register_hz(clocksource_gpt, clksrc.rate)) -- 1.7.3.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: OMAP3 kernels fail to build
On Mon, 8 Aug 2011, Russell King - ARM Linux wrote: On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote: On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote: With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this: arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init' arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit' arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power' arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk' arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend' I thought below patch was suppose to fix it. https://patchwork.kernel.org/patch/963462/ So, the problem has been known about for around a month. Yet the broken patch still went upstream. Which known broken patch still went upstream ? The problem commits were 208466dc10083e734a8af71d10f923ee4bff950c (usb: otg: OMAP4430: Powerdown the internal PHY when USB is disabled) and fb91cde49c327ff957c55d91805bc6abda59b311 (usb: musb: OMAP4430: Power down the PHY during board init). The above link makes this clear. vv IF IT IS KNOWN THAT A PATCH IS BROKEN IT MUST NOT BE SUBMITTED TO MAINLINE ^^ This is certainly good advice when it's relevant. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support
On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote: This is in continuation of patch series posted at: http://lwn.net/Articles/451917/ Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from omap_device. [There is latest version posted which will be rebased later] Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely grant.lik...@secretlab.ca However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call. Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week. git://git.secretlab.ca/git/linux-2.6.git Branch: devicetree/test-3.0 Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test? G, Manjunath Kondaiah (6): dt: omap: prepare hwmod to support dt dt: Add pd_size to AUXDATA structure dt: omap3: add soc file for handling i2c controllers dt: omap3: beagle board: set clock freq for i2c devices dt: omap3: add generic board file for dt support dt: omap3: enable dt support for i2c1 controller Kevin Hilman (7): OMAP: omap_device: replace _find_by_pdev() with to_omap_device() OMAP: omap_device: replace debug/warning/error prints with dev_* macros OMAP3: beagle: don't touch omap_device internals OMAP: McBSP: use existing macros for converting between devices OMAP: omap_device: remove internal functions from omap_device.h OMAP: omap_device: when building return platform_device instead of omap_device ARM: platform_device: pdev_archdata: add omap_device pointer Tony Lindgren (1): omap2+: Use Kconfig symbol in Makefile instead of obj-y arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +-- arch/arm/boot/dts/omap3-beagle.dts| 18 +++- arch/arm/boot/dts/omap3-soc.dtsi | 62 ++ arch/arm/include/asm/device.h |5 + arch/arm/mach-omap2/Kconfig | 11 ++ arch/arm/mach-omap2/Makefile | 77 ++--- arch/arm/mach-omap2/board-omap3-dt.c | 93 +++ arch/arm/mach-omap2/board-omap3beagle.c | 40 ++- arch/arm/mach-omap2/devices.c | 44 arch/arm/mach-omap2/display.c |6 +- arch/arm/mach-omap2/dma.c | 16 ++-- arch/arm/mach-omap2/gpio.c|8 +- arch/arm/mach-omap2/hsmmc.c |8 +- arch/arm/mach-omap2/hwspinlock.c |8 +- arch/arm/mach-omap2/mcbsp.c |8 +- arch/arm/mach-omap2/pm.c |8 +- arch/arm/mach-omap2/serial.c | 12 +- arch/arm/plat-omap/i2c.c |8 +- arch/arm/plat-omap/include/plat/omap_device.h | 17 ++- arch/arm/plat-omap/mcbsp.c|6 +- arch/arm/plat-omap/omap_device.c | 150 - drivers/i2c/busses/i2c-omap.c | 23 - drivers/of/platform.c | 41 +++ include/linux/of_platform.h |5 + 24 files changed, 469 insertions(+), 216 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support
On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote: On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote: This is in continuation of patch series posted at: http://lwn.net/Articles/451917/ Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from omap_device. [There is latest version posted which will be rebased later] Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely grant.lik...@secretlab.ca However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call. Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week. git://git.secretlab.ca/git/linux-2.6.git Branch: devicetree/test-3.0 Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test? devicetree/test was broken last week since grant has pulled latest mainline changes hence selected stable version. -M [...] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 00/14] dt: omap hwmod-dt binding and omap3 i2c1 dt support
On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote: On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayakrna...@ti.com wrote: On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote: This is in continuation of patch series posted at: http://lwn.net/Articles/451917/ Patches from Kevin Hilman and others are consolidated along with this series since it will be part of ongoing work of decoupling pdev from omap_device. [There is latest version posted which will be rebased later] Apart from the above, the major feature included in this series is dt-hwmod binding and preparing omap hwmod framework for adapting omap drivers to support omap dt after aligning with Grant Likely grant.lik...@secretlab.ca However, current hwmod-dt binding will be replaced with notifiers in generic board file and hwmod device pointer will be scanned and attached in notifier call. Used 3.0 stable kernel version for this patch series since latest mainline was broken for beagle boot last week. git://git.secretlab.ca/git/linux-2.6.git Branch: devicetree/test-3.0 Is there a reason why these are based on devicetree/test-3.0 and not devicetree/test? devicetree/test was broken last week since grant has pulled latest mainline changes hence selected stable version. Ok, atleast mainline is fixed now. -M [...] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
