Re: [PATCH 2/4] ARM: OMAP: Split plat/hardware.h, introduce local hardware.h and soc.h for omap2+
* Mark Brown [120831 17:28]: > On Fri, Aug 31, 2012 at 05:26:22PM -0700, Tony Lindgren wrote: > > As the plat and mach includes need to disappear for single zImage work, > > we need to remove plat/hardware.h. > > Acked-by: Mark Brown > > There's a topic/omap branch in ASoC which you can pull in to help reduce > conflicts, or I could merge this there if that's sensible. Thanks. Did not see it yet at git://opensource.wolfsonmicro.com/linux-2.6-asoc, maybe it's not yet pushed out? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP: Split plat/hardware.h, introduce local hardware.h and soc.h for omap2+
On Fri, Aug 31, 2012 at 05:26:22PM -0700, Tony Lindgren wrote: > As the plat and mach includes need to disappear for single zImage work, > we need to remove plat/hardware.h. Acked-by: Mark Brown There's a topic/omap branch in ASoC which you can pull in to help reduce conflicts, or I could merge this there if that's sensible. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
There's no need to have these in plat-omap any longer. Note that these
could eventually be made local to mach-omap1 instead of being in mach.
But to do that, at least various driver access using omap7xxx.h registers
needs to be fixed first.
Cc: spi-devel-gene...@lists.sourceforge.net
Cc: Grant Likely
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap1/board-htcherald.c |4 ++--
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap1/include/mach/hardware.h |6 +++---
arch/arm/mach-omap1/include/mach/omap1510.h |3 +--
arch/arm/mach-omap1/include/mach/omap16xx.h |3 +--
arch/arm/mach-omap1/include/mach/omap7xx.h |3 +--
drivers/spi/spi-omap-uwire.c|3 ++-
7 files changed, 11 insertions(+), 13 deletions(-)
rename arch/arm/{plat-omap/include/plat/omap1510.h =>
mach-omap1/include/mach/omap1510.h} (97%)
rename arch/arm/{plat-omap/include/plat/omap16xx.h =>
mach-omap1/include/mach/omap16xx.h} (99%)
rename arch/arm/{plat-omap/include/plat/omap7xx.h =>
mach-omap1/include/mach/omap7xx.h} (98%)
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index bdb94fe..4fe4884 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -37,14 +37,14 @@
#include
#include
#include
+#include
#include
#include
-#include
-#include
#include
+#include
#include
#include
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 1feca35..05fdbd9 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -23,8 +23,8 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/mach-omap1/include/mach/hardware.h
b/arch/arm/mach-omap1/include/mach/hardware.h
index bd3b95e..84248d2 100644
--- a/arch/arm/mach-omap1/include/mach/hardware.h
+++ b/arch/arm/mach-omap1/include/mach/hardware.h
@@ -311,8 +311,8 @@ static inline u32 omap_cs3_phys(void)
* ---
*/
-#include
-#include
-#include
+#include "omap7xx.h"
+#include "omap1510.h"
+#include "omap16xx.h"
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/omap1510.h
b/arch/arm/mach-omap1/include/mach/omap1510.h
similarity index 97%
rename from arch/arm/plat-omap/include/plat/omap1510.h
rename to arch/arm/mach-omap1/include/mach/omap1510.h
index d240046..8fe05d6 100644
--- a/arch/arm/plat-omap/include/plat/omap1510.h
+++ b/arch/arm/mach-omap1/include/mach/omap1510.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap1510.h
- *
+/*
* Hardware definitions for TI OMAP1510 processor.
*
* Cleanup for Linux-2.6 by Dirk Behme
diff --git a/arch/arm/plat-omap/include/plat/omap16xx.h
b/arch/arm/mach-omap1/include/mach/omap16xx.h
similarity index 99%
rename from arch/arm/plat-omap/include/plat/omap16xx.h
rename to arch/arm/mach-omap1/include/mach/omap16xx.h
index e69e1d8..cd1c724 100644
--- a/arch/arm/plat-omap/include/plat/omap16xx.h
+++ b/arch/arm/mach-omap1/include/mach/omap16xx.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap16xx.h
- *
+/*
* Hardware definitions for TI OMAP1610/5912/1710 processors.
*
* Cleanup for Linux-2.6 by Dirk Behme
diff --git a/arch/arm/plat-omap/include/plat/omap7xx.h
b/arch/arm/mach-omap1/include/mach/omap7xx.h
similarity index 98%
rename from arch/arm/plat-omap/include/plat/omap7xx.h
rename to arch/arm/mach-omap1/include/mach/omap7xx.h
index 48e4757..63da994 100644
--- a/arch/arm/plat-omap/include/plat/omap7xx.h
+++ b/arch/arm/mach-omap1/include/mach/omap7xx.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap7xx.h
- *
+/*
* Hardware definitions for TI OMAP7XX processor.
*
* Cleanup for Linux-2.6 by Dirk Behme
diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index 9b0d716..a3996a1 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -53,7 +53,8 @@
#include
#include
-#include /* OMAP7XX_IO_CONF registers */
+
+#include /* OMAP7XX_IO_CONF registers */
/* FIXME address is now a platform device resource,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2
These can now be moved to be local headers in mach-omap2.
Note that this patch removes arch/arm/plat-omap/devices.c as it
will get removed anyways with Paul Walmsley's patch
"ARM: OMAP: split OMAP1, OMAP2+ RNG device registration".
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/am33xx.h |0
arch/arm/mach-omap2/clock33xx_data.c |2 -
arch/arm/mach-omap2/control.h |2 -
arch/arm/mach-omap2/hardware.h | 12 ++--
arch/arm/mach-omap2/omap-mpuss-lowpower.c |3 -
arch/arm/mach-omap2/omap24xx.h |2 -
arch/arm/mach-omap2/omap34xx.h |2 -
arch/arm/mach-omap2/omap44xx.h |0
arch/arm/mach-omap2/omap54xx.h |0
arch/arm/mach-omap2/sleep24xx.S|3 -
arch/arm/mach-omap2/sleep34xx.S|2 -
arch/arm/mach-omap2/sleep44xx.S|2 -
arch/arm/mach-omap2/ti81xx.h |0
arch/arm/plat-omap/Makefile|3 -
arch/arm/plat-omap/devices.c | 91
15 files changed, 13 insertions(+), 111 deletions(-)
rename arch/arm/{plat-omap/include/plat/am33xx.h => mach-omap2/am33xx.h} (100%)
rename arch/arm/{plat-omap/include/plat/omap24xx.h => mach-omap2/omap24xx.h}
(98%)
rename arch/arm/{plat-omap/include/plat/omap34xx.h => mach-omap2/omap34xx.h}
(98%)
rename arch/arm/{plat-omap/include/plat/omap44xx.h => mach-omap2/omap44xx.h}
(100%)
rename arch/arm/{plat-omap/include/plat/omap54xx.h => mach-omap2/omap54xx.h}
(100%)
rename arch/arm/{plat-omap/include/plat/ti81xx.h => mach-omap2/ti81xx.h} (100%)
delete mode 100644 arch/arm/plat-omap/devices.c
diff --git a/arch/arm/plat-omap/include/plat/am33xx.h
b/arch/arm/mach-omap2/am33xx.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/am33xx.h
rename to arch/arm/mach-omap2/am33xx.h
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 25bbcc7..7aa5eca 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -18,8 +18,8 @@
#include
#include
#include
-#include
+#include "am33xx.h"
#include "iomap.h"
#include "control.h"
#include "clock.h"
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b8cdc85..c1a5cab 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -21,7 +21,7 @@
#include
#include
-#include
+#include "am33xx.h"
#ifndef __ASSEMBLY__
#define OMAP242X_CTRL_REGADDR(reg) \
diff --git a/arch/arm/mach-omap2/hardware.h b/arch/arm/mach-omap2/hardware.h
index 3c190f9..78f59ec 100644
--- a/arch/arm/mach-omap2/hardware.h
+++ b/arch/arm/mach-omap2/hardware.h
@@ -1,6 +1,6 @@
-#include
-#include
-#include
-#include
-#include
-#include
+#include "omap24xx.h"
+#include "omap34xx.h"
+#include "omap44xx.h"
+#include "ti81xx.h"
+#include "am33xx.h"
+#include "omap54xx.h"
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 637a1bd..ff4e6a0 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -50,9 +50,8 @@
#include
#include
-#include
-
#include "common.h"
+#include "omap44xx.h"
#include "omap4-sar-layout.h"
#include "pm.h"
#include "prcm_mpu44xx.h"
diff --git a/arch/arm/plat-omap/include/plat/omap24xx.h
b/arch/arm/mach-omap2/omap24xx.h
similarity index 98%
rename from arch/arm/plat-omap/include/plat/omap24xx.h
rename to arch/arm/mach-omap2/omap24xx.h
index 92df9e2..641a2c8 100644
--- a/arch/arm/plat-omap/include/plat/omap24xx.h
+++ b/arch/arm/mach-omap2/omap24xx.h
@@ -1,6 +1,4 @@
/*
- * arch/arm/plat-omap/include/mach/omap24xx.h
- *
* This file contains the processor specific definitions
* of the TI OMAP24XX.
*
diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h
b/arch/arm/mach-omap2/omap34xx.h
similarity index 98%
rename from arch/arm/plat-omap/include/plat/omap34xx.h
rename to arch/arm/mach-omap2/omap34xx.h
index 0d818ac..c0d1b4b 100644
--- a/arch/arm/plat-omap/include/plat/omap34xx.h
+++ b/arch/arm/mach-omap2/omap34xx.h
@@ -1,6 +1,4 @@
/*
- * arch/arm/plat-omap/include/mach/omap34xx.h
- *
* This file contains the processor specific definitions of the TI OMAP34XX.
*
* Copyright (C) 2007 Texas Instruments.
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h
b/arch/arm/mach-omap2/omap44xx.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/omap44xx.h
rename to arch/arm/mach-omap2/omap44xx.h
diff --git a/arch/arm/plat-omap/include/plat/omap54xx.h
b/arch/arm/mach-omap2/omap54xx.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/omap54xx.h
rename to arch/arm/mach-omap2/omap54xx.h
diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
index d4bf904..ce0ccd2 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -
[PATCH 1/4] ARM: OMAP: Remove unused old gpio-switch.h
This is no longer used anywhere.
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/include/plat/gpio-switch.h | 54 -
1 file changed, 54 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/gpio-switch.h
diff --git a/arch/arm/plat-omap/include/plat/gpio-switch.h
b/arch/arm/plat-omap/include/plat/gpio-switch.h
deleted file mode 100644
index 10da0e0..000
--- a/arch/arm/plat-omap/include/plat/gpio-switch.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
- * GPIO switch definitions
- *
- * Copyright (C) 2006 Nokia Corporation
- *
- * 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.
- */
-
-#ifndef __ASM_ARCH_OMAP_GPIO_SWITCH_H
-#define __ASM_ARCH_OMAP_GPIO_SWITCH_H
-
-#include
-
-/* Cover:
- * high -> closed
- * low -> open
- * Connection:
- * high -> connected
- * low -> disconnected
- * Activity:
- * high -> active
- * low -> inactive
- *
- */
-#define OMAP_GPIO_SWITCH_TYPE_COVER0x
-#define OMAP_GPIO_SWITCH_TYPE_CONNECTION 0x0001
-#define OMAP_GPIO_SWITCH_TYPE_ACTIVITY 0x0002
-#define OMAP_GPIO_SWITCH_FLAG_INVERTED 0x0001
-#define OMAP_GPIO_SWITCH_FLAG_OUTPUT 0x0002
-
-struct omap_gpio_switch {
- const char *name;
- s16 gpio;
- unsigned flags:4;
- unsigned type:4;
-
- /* Time in ms to debounce when transitioning from
-* inactive state to active state. */
- u16 debounce_rising;
- /* Same for transition from active to inactive state. */
- u16 debounce_falling;
-
- /* notify board-specific code about state changes */
- void (* notify)(void *data, int state);
- void *notify_data;
-};
-
-/* Call at init time only */
-extern void omap_register_gpio_switches(const struct omap_gpio_switch *tbl,
- int count);
-
-#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Series short description
Hi all, Here are the changes needed to make hardware.h local for mach-omap2. These patches are based on v3.6-rc3 and the following patches: - Arnd's patch "ARM: omap: move platform_data definitions" - Igor's series "ARM: OMAP: cleanup plat/board.h file" - Afzal's series "Prepare for GPMC driver conversion (w.r.t MTD)" - My series "Clean up hardcoded IRQs for mach-omap2, enable SPARSE_IRQ, plaform_data/gpio-omap.h" Regards, Tony --- Tony Lindgren (4): ARM: OMAP: Remove unused old gpio-switch.h ARM: OMAP: Split plat/hardware.h, introduce local hardware.h and soc.h for omap2+ ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2 ARM: OMAP1: Move SoC specific headers from plat to mach for omap1 arch/arm/mach-omap1/board-htcherald.c |4 arch/arm/mach-omap1/devices.c |2 arch/arm/mach-omap1/include/mach/hardware.h| 285 +++ arch/arm/mach-omap1/include/mach/omap1510.h|3 arch/arm/mach-omap1/include/mach/omap16xx.h|3 arch/arm/mach-omap1/include/mach/omap7xx.h |3 arch/arm/mach-omap2/am33xx.h |0 arch/arm/mach-omap2/board-2430sdp.c|2 arch/arm/mach-omap2/board-3430sdp.c|9 - arch/arm/mach-omap2/board-4430sdp.c|9 - arch/arm/mach-omap2/board-am3517crane.c|1 arch/arm/mach-omap2/board-am3517evm.c |1 arch/arm/mach-omap2/board-apollon.c|3 arch/arm/mach-omap2/board-cm-t35.c |2 arch/arm/mach-omap2/board-cm-t3517.c |3 arch/arm/mach-omap2/board-devkit8000.c | 22 +- arch/arm/mach-omap2/board-flash.c |6 arch/arm/mach-omap2/board-generic.c|1 arch/arm/mach-omap2/board-h4.c |3 arch/arm/mach-omap2/board-igep0020.c |1 arch/arm/mach-omap2/board-ldp.c| 10 - arch/arm/mach-omap2/board-n8x0.c | 10 - arch/arm/mach-omap2/board-omap3beagle.c| 12 - arch/arm/mach-omap2/board-omap3evm.c | 11 - arch/arm/mach-omap2/board-omap3logic.c | 16 - arch/arm/mach-omap2/board-omap3pandora.c |9 - arch/arm/mach-omap2/board-omap3stalker.c | 20 +- arch/arm/mach-omap2/board-omap3touchbook.c |9 - arch/arm/mach-omap2/board-omap4panda.c |7 - arch/arm/mach-omap2/board-overo.c | 14 - arch/arm/mach-omap2/board-rm680.c |1 arch/arm/mach-omap2/board-rx51.c |5 arch/arm/mach-omap2/board-ti8168evm.c |2 arch/arm/mach-omap2/board-zoom-debugboard.c|4 arch/arm/mach-omap2/board-zoom-display.c |4 arch/arm/mach-omap2/board-zoom-peripherals.c |1 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2 arch/arm/mach-omap2/clkt_dpll.c|2 arch/arm/mach-omap2/clock.c|8 - arch/arm/mach-omap2/clock2420_data.c |2 arch/arm/mach-omap2/clock2430.c|2 arch/arm/mach-omap2/clock2430_data.c |2 arch/arm/mach-omap2/clock2xxx.c|2 arch/arm/mach-omap2/clock33xx_data.c |2 arch/arm/mach-omap2/clock3xxx.c|2 arch/arm/mach-omap2/clock3xxx_data.c |3 arch/arm/mach-omap2/clock44xx_data.c |3 arch/arm/mach-omap2/cm2xxx_3xxx.c |3 arch/arm/mach-omap2/common.c |2 arch/arm/mach-omap2/common.h |6 arch/arm/mach-omap2/control.c |2 arch/arm/mach-omap2/control.h |2 arch/arm/mach-omap2/devices.c |1 arch/arm/mach-omap2/dpll3xxx.c |2 arch/arm/mach-omap2/dpll44xx.c |2 arch/arm/mach-omap2/emu.c |2 arch/arm/mach-omap2/gpmc-nand.c|5 arch/arm/mach-omap2/gpmc-onenand.c |5 arch/arm/mach-omap2/gpmc-smc91x.c |3 arch/arm/mach-omap2/gpmc.c |4 arch/arm/mach-omap2/hardware.h |6 arch/arm/mach-omap2/hsmmc.c|2 arch/arm/mach-omap2/i2c.c |1 arch/arm/mach-omap2/id.c |2 arch/arm/mach-omap2/include/mach/hardware.h|2 arch/arm/mach-omap2/io.c |3 arch/arm/mach-omap2/irq.c |3 arch/arm/mach-omap2/mailbox.c |3 arch/arm/mach-omap2/mcbsp.c|5 arch/arm/mach-omap2/omap-mpuss-lowpower.c |3 arch/arm/mach-omap2/omap-smp.c |2 arch/arm/mach-omap2/omap-wakeupgen.c |2 arch/arm/mach-omap2/omap24xx.h |2 arch/arm/mach-omap2/omap34xx.h |2 arch/arm/mach-omap2/omap4-common.c |2 arch/arm/mach-
Re: [PATCH 5/9] ARM: OMAP2+: Remove hardcoded twl4030 gpio_base, irq_base and irq_end
* Tony Lindgren [120830 17:53]:
> We can't use hardcoded interrupts for SPARSE_IRQ, and can replace
> the hardcoded gpio_base with twl_gpiochip.base after it's been
> allocated.
...
> --- a/include/linux/mfd/twl6040.h
> +++ b/include/linux/mfd/twl6040.h
> @@ -194,7 +194,6 @@ struct twl6040_vibra_data {
>
> struct twl6040_platform_data {
> int audpwron_gpio; /* audio power-on gpio */
> - unsigned int irq_base;
>
> struct twl6040_codec_data *codec;
> struct twl6040_vibra_data *vibra;
The platform_data irq_base is not being used it seems..
> @@ -222,7 +221,6 @@ struct twl6040 {
> unsigned int mclk;
>
> unsigned int irq;
> - unsigned int irq_base;
> u8 irq_masks_cur;
> u8 irq_masks_cache;
> };
..but irq_base here is still in use as that's where the value from
irq_alloc_descs() is being stored to. So I'll drop the changes to
struct twl6040 from this patch as otherwise twl6040 code won't compile.
Turns out I did not have twl6040 selected in any of the testconfigs
that I ran.
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: [PATCH 6/9] ARM: OMAP: Move gpio.h to include/linux/platform_data
On Fri, Aug 31, 2012 at 2:52 AM, Tony Lindgren wrote: > This way we can remove includes of plat/gpio.h which won't work > with the single zImage support. > > Note that we also remove the cpu_class_is_omap2() check > in gpio-omap.c as the drivers should not call it as we need to > make it local to arch/arm/mach-omap2 for single zImage support. > > While at it, arrange the related includes in the standard way. > > Cc: Grant Likely > Cc: Linus Walleij > Cc: linux-...@lists.infradead.org > Cc: alsa-de...@alsa-project.org > Acked-by: Tony Lindgren Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: OMAP2+: Remove hardcoded twl4030 gpio_base, irq_base and irq_end
On Fri, Aug 31, 2012 at 2:52 AM, Tony Lindgren wrote: > We can't use hardcoded interrupts for SPARSE_IRQ, and can replace > the hardcoded gpio_base with twl_gpiochip.base after it's been > allocated. > > Cc: Grant Likely > Cc: Linus Walleij > Cc: Samuel Ortiz > Cc: Peter Ujfalusi > Signed-off-by: Tony Lindgren Oh, cool. Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] MFD/GPIO: Add twl6040 GPO driver
On Thu, Aug 30, 2012 at 11:16 AM, Peter Ujfalusi wrote: > Hi Samuel, Linus, (...) > Did you had time to look at this series? Do you want me to resend it? I have provided my ACK on the GPIO part assuming you're taking this series through the MFD tree. There is not more I can do... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCH] ASoC: ams-delta: fix card initalization failure
On Wed, Aug 29, 2012 at 07:04:48AM +0200, Janusz Krzysztofik wrote: > On Tue, 28 Aug 2012 11:13:39 Mark Brown wrote: > > The above looks like you already have a platform driver? All I'm > > suggesting is changing the above to use platform rather than driver > > data. > The ams-delta asoc driver doesn't use snd_soc_register_card() so far, > but relays solely on soc_probe() doing this for it, which in turn > expects to find a snc_soc_card structure in drvdata. How is it supposed > to find that structure if I pass it over platform data instead? Am I > missing something? s/drvdata/platdata/ in the code. If you can't do this then just referencing the data directly in the code would be better than this bodge, it'd be much less fragile. -- To unsubscribe from this list: send the line "unsubscribe 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: > On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: > > On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: > > > Hi Russell & Tony, > > > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > > > baseport submission we had aligned that, we won't create separate EVM > > > options, killing the board file all-together. > > > > > > Having said that, the early printk option (DEBUG_LL) is broken, the > > > auto-generated file "./include/generated/mach-types.h" still refers to > > > CONFIG_MACH_AM335XEVM option, > > > > > > #ifdef CONFIG_MACH_AM335XEVM > > > # ifdef machine_arch_type > > > # undef machine_arch_type > > > # define machine_arch_type __machine_arch_type > > > # else > > > # define machine_arch_type MACH_TYPE_AM335XEVM > > > # endif > > > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) > > > #else > > > # define machine_is_am335xevm() (0) > > > #endif > > > > machine types are entirely meaningless for DT based systems. > > > > > Can you comment on this? Based on that I will submit the patch. > > > > Pointless. You can't use machine_is_am335xevm() when you're using DT. > > > > They how do you recommend to resolve early prink issue (required during > decompression)? Right now the best you can do is to have empty stubs that display nothing. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] leds: leds-gpio: adopt pinctrl support
Hi Tony,
Thanks for the review,
On Fri, Aug 31, 2012 at 21:34:04, Tony Lindgren wrote:
> * AnilKumar Ch [120831 02:30]:
> > Adopt pinctrl support to leds-gpio driver, based on the device
> > pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
> > mode.
> >
> > Signed-off-by: AnilKumar Ch
> > ---
> > drivers/leds/leds-gpio.c | 31 ---
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> > index c032b21..d98dfb9 100644
> > --- a/drivers/leds/leds-gpio.c
> > +++ b/drivers/leds/leds-gpio.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > struct gpio_led_data {
> > struct led_classdev cdev;
> > @@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct
> > platform_device *pdev)
> > {
> > struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
> > struct gpio_leds_priv *priv;
> > - int i, ret = 0;
> > + struct pinctrl *pinctrl;
> > + int i = 0;
> > + int ret = 0;
> > +
> > + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> > + if (IS_ERR(pinctrl)) {
> > + return PTR_ERR(pinctrl);
> > + }
>
> I think you need to just print out a warning here as most systems don't
> have the pinctrl implemented. And some people just do static pinmuxing
> in the bootloader.
>
Yes, that is better approach I will fix this in my next version.
I will separate out this patch from the series because these changes are
leds-gpio driver specific which are different from DT data (pinctrl and
d_can).
Thanks
AnilKumar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Makefile.boot: Add am335x evm and bone targets
This adds am335x-evm and am335x-bone dtb targets to 'make dtbs', just like other platforms. Signed-off-by: Vaibhav Hiremath Cc: Tony Lindgren --- arch/arm/mach-omap2/Makefile.boot |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile.boot b/arch/arm/mach-omap2/Makefile.boot index 6cf1c2d..1136072 100644 --- a/arch/arm/mach-omap2/Makefile.boot +++ b/arch/arm/mach-omap2/Makefile.boot @@ -7,3 +7,4 @@ dtb-$(CONFIG_ARCH_OMAP3)+= omap3-beagle.dtb omap3-evm.dtb dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb dtb-$(CONFIG_SOC_OMAP5)+= omap5-evm.dtb +dtb-$(CONFIG_SOC_AM33XX) += am335x-evm.dtb am335x-bone.dtb -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: > On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: > > Hi Russell & Tony, > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > > baseport submission we had aligned that, we won't create separate EVM > > options, killing the board file all-together. > > > > Having said that, the early printk option (DEBUG_LL) is broken, the > > auto-generated file "./include/generated/mach-types.h" still refers to > > CONFIG_MACH_AM335XEVM option, > > > > #ifdef CONFIG_MACH_AM335XEVM > > # ifdef machine_arch_type > > # undef machine_arch_type > > # define machine_arch_type __machine_arch_type > > # else > > # define machine_arch_type MACH_TYPE_AM335XEVM > > # endif > > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) > > #else > > # define machine_is_am335xevm() (0) > > #endif > > machine types are entirely meaningless for DT based systems. > > > Can you comment on this? Based on that I will submit the patch. > > Pointless. You can't use machine_is_am335xevm() when you're using DT. > They how do you recommend to resolve early prink issue (required during decompression)? Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: > Hi Russell & Tony, > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > baseport submission we had aligned that, we won't create separate EVM > options, killing the board file all-together. > > Having said that, the early printk option (DEBUG_LL) is broken, the > auto-generated file "./include/generated/mach-types.h" still refers to > CONFIG_MACH_AM335XEVM option, > > #ifdef CONFIG_MACH_AM335XEVM > # ifdef machine_arch_type > # undef machine_arch_type > # define machine_arch_type __machine_arch_type > # else > # define machine_arch_type MACH_TYPE_AM335XEVM > # endif > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) > #else > # define machine_is_am335xevm() (0) > #endif machine types are entirely meaningless for DT based systems. > Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. -- To unsubscribe from this list: send the line "unsubscribe 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: Without MACH_ option Early printk (DEBUG_LL)
* Hiremath, Vaibhav [120831 09:47]: > > On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote: > > Can you please review below patch? If you think its ok, I will send the > patch - Yeah thanks looks OK to me, at least I can't think of better options for now. Regards, Tony > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index fccbdf0..eccafb4 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -104,6 +104,9 @@ config SOC_AM33XX > select CPU_V7 > select ARM_CPU_SUSPEND if PM > select MULTI_IRQ_HANDLER > + select MACH_AM335XEVM > + select MACH_AM335XIAEVM > + select MACH_TAM335X > > config OMAP_PACKAGE_ZAF > bool > @@ -140,6 +143,15 @@ config MACH_OMAP_GENERIC > Support for generic TI OMAP2+ boards using Flattened Device Tree. > More information at Documentation/devicetree > > +config MACH_AM335XEVM > + bool > + > +config MACH_AM335XIAEVM > + bool > + > +config MACH_TAM335X > + bool > + > config MACH_OMAP2_TUSB6010 > bool > depends on ARCH_OMAP2 && SOC_OMAP2420 > > Thanks, > Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 22:07:37, Hiremath, Vaibhav wrote: > On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote: > > * Hiremath, Vaibhav [120831 09:06]: > > > On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: > > > > * Vaibhav Hiremath [120831 07:55]: > > > > > Hi Russell & Tony, > > > > > > > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > > > > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back > > > > > during > > > > > baseport submission we had aligned that, we won't create separate EVM > > > > > options, killing the board file all-together. > > > > > > > > > > Having said that, the early printk option (DEBUG_LL) is broken, the > > > > > auto-generated file "./include/generated/mach-types.h" still refers to > > > > > CONFIG_MACH_AM335XEVM option, > > > > > > > > The way we're heading is that the DEBUG_LL options will only work for > > > > one hardcoded machine where you need to select the uart type and address > > > > in Kconfig. Or just patch it in. > > > > > > > > > #ifdef CONFIG_MACH_AM335XEVM > > > > > # ifdef machine_arch_type > > > > > # undef machine_arch_type > > > > > # define machine_arch_type __machine_arch_type > > > > > # else > > > > > # define machine_arch_type MACH_TYPE_AM335XEVM > > > > > # endif > > > > > # define machine_is_am335xevm() (machine_arch_type == > > > > > MACH_TYPE_AM335XEVM) > > > > > #else > > > > > # define machine_is_am335xevm() (0) > > > > > #endif > > > > > > > > > > > > > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or > > > > > ARCH_OMAP2PLUS, something like below, > > > > > > > > > > am335xevmSOC_AM33XX AM335XEVM 3589 > > > > > > > > > > OR > > > > > > > > > > am335xevmARCH_OMAP2PLUS AM335XEVM 3589 > > > > > > > > > > > > > > > Can you comment on this? Based on that I will submit the patch. > > > > > > > > I think that would at minimum break things for autogenerated > > > > mach-types.h where if only some other non-am335xevm machine is > > > > selected (like omap-generic) things don't get optimized out any > > > > longer as they currently do. > > > > > > > > > > Agreed. In that case the first option should work here, right? > > > > It gets messy if we start mixing mach and soc defines there.. > > > > How about just add a hidden Kconfig option to mach-omap2/Kconfig > > that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set? > > Great, this is what I had in my mind but since it is hidden option I thought > may not be right thing to do. > I was just thinking in the direction that, it should be logical and fine if > SOC_AM33XX is used for all AM33xx based machines, isn't it? > > Anyway, I think we are on same page here, I will add it and submit the patch > ASAP. > > > Or does that require that MACHINE_START is there as well? > > > > I do not think so, they are not related to each other, this option is > required only during decompression. > I have tested it on BeagleBone and it is working. > Can you please review below patch? If you think its ok, I will send the patch - diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index fccbdf0..eccafb4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -104,6 +104,9 @@ config SOC_AM33XX select CPU_V7 select ARM_CPU_SUSPEND if PM select MULTI_IRQ_HANDLER + select MACH_AM335XEVM + select MACH_AM335XIAEVM + select MACH_TAM335X config OMAP_PACKAGE_ZAF bool @@ -140,6 +143,15 @@ config MACH_OMAP_GENERIC Support for generic TI OMAP2+ boards using Flattened Device Tree. More information at Documentation/devicetree +config MACH_AM335XEVM + bool + +config MACH_AM335XIAEVM + bool + +config MACH_TAM335X + bool + config MACH_OMAP2_TUSB6010 bool depends on ARCH_OMAP2 && SOC_OMAP2420 Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote: > * Hiremath, Vaibhav [120831 09:06]: > > On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: > > > * Vaibhav Hiremath [120831 07:55]: > > > > Hi Russell & Tony, > > > > > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > > > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > > > > baseport submission we had aligned that, we won't create separate EVM > > > > options, killing the board file all-together. > > > > > > > > Having said that, the early printk option (DEBUG_LL) is broken, the > > > > auto-generated file "./include/generated/mach-types.h" still refers to > > > > CONFIG_MACH_AM335XEVM option, > > > > > > The way we're heading is that the DEBUG_LL options will only work for > > > one hardcoded machine where you need to select the uart type and address > > > in Kconfig. Or just patch it in. > > > > > > > #ifdef CONFIG_MACH_AM335XEVM > > > > # ifdef machine_arch_type > > > > # undef machine_arch_type > > > > # define machine_arch_type __machine_arch_type > > > > # else > > > > # define machine_arch_type MACH_TYPE_AM335XEVM > > > > # endif > > > > # define machine_is_am335xevm() (machine_arch_type == > > > > MACH_TYPE_AM335XEVM) > > > > #else > > > > # define machine_is_am335xevm() (0) > > > > #endif > > > > > > > > > > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or > > > > ARCH_OMAP2PLUS, something like below, > > > > > > > > am335xevmSOC_AM33XX AM335XEVM 3589 > > > > > > > > OR > > > > > > > > am335xevmARCH_OMAP2PLUS AM335XEVM 3589 > > > > > > > > > > > > Can you comment on this? Based on that I will submit the patch. > > > > > > I think that would at minimum break things for autogenerated > > > mach-types.h where if only some other non-am335xevm machine is > > > selected (like omap-generic) things don't get optimized out any > > > longer as they currently do. > > > > > > > Agreed. In that case the first option should work here, right? > > It gets messy if we start mixing mach and soc defines there.. > > How about just add a hidden Kconfig option to mach-omap2/Kconfig > that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set? Great, this is what I had in my mind but since it is hidden option I thought may not be right thing to do. I was just thinking in the direction that, it should be logical and fine if SOC_AM33XX is used for all AM33xx based machines, isn't it? Anyway, I think we are on same page here, I will add it and submit the patch ASAP. > Or does that require that MACHINE_START is there as well? > I do not think so, they are not related to each other, this option is required only during decompression. I have tested it on BeagleBone and it is working. Thanks, Vaibhav > Regards, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Without MACH_ option Early printk (DEBUG_LL)
* Hiremath, Vaibhav [120831 09:06]: > On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: > > * Vaibhav Hiremath [120831 07:55]: > > > Hi Russell & Tony, > > > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > > > baseport submission we had aligned that, we won't create separate EVM > > > options, killing the board file all-together. > > > > > > Having said that, the early printk option (DEBUG_LL) is broken, the > > > auto-generated file "./include/generated/mach-types.h" still refers to > > > CONFIG_MACH_AM335XEVM option, > > > > The way we're heading is that the DEBUG_LL options will only work for > > one hardcoded machine where you need to select the uart type and address > > in Kconfig. Or just patch it in. > > > > > #ifdef CONFIG_MACH_AM335XEVM > > > # ifdef machine_arch_type > > > # undef machine_arch_type > > > # define machine_arch_type __machine_arch_type > > > # else > > > # define machine_arch_type MACH_TYPE_AM335XEVM > > > # endif > > > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) > > > #else > > > # define machine_is_am335xevm() (0) > > > #endif > > > > > > > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or > > > ARCH_OMAP2PLUS, something like below, > > > > > > am335xevmSOC_AM33XX AM335XEVM 3589 > > > > > > OR > > > > > > am335xevmARCH_OMAP2PLUS AM335XEVM 3589 > > > > > > > > > Can you comment on this? Based on that I will submit the patch. > > > > I think that would at minimum break things for autogenerated > > mach-types.h where if only some other non-am335xevm machine is > > selected (like omap-generic) things don't get optimized out any > > longer as they currently do. > > > > Agreed. In that case the first option should work here, right? It gets messy if we start mixing mach and soc defines there.. How about just add a hidden Kconfig option to mach-omap2/Kconfig that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set? Or does that require that MACHINE_START is there as well? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: omap/dts: update the documentation
Add the Tobi/Overo board to the list of supported platforms. Signed-off-by: Florian Vaussard --- .../devicetree/bindings/arm/omap/omap.txt |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index ccdd0e5..d0051a7 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -36,6 +36,9 @@ Boards: - OMAP3 BeagleBoard : Low cost community board compatible = "ti,omap3-beagle", "ti,omap3" +- OMAP3 Tobi with Overo : Commercial expansion board with daughter board + compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3" + - OMAP4 SDP : Software Developement Board compatible = "ti,omap4-sdp", "ti,omap4430" -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion board
The Gumstix Overo is a computer on module using an OMAP3 processor.
This module must be plugged into an expansion board.
This patch adds a first device tree support for the Overo, using the
Tobi expansion board. The current support is able to boot and mount
the rootfs from MMC.
This patche also updates the omap3 dtb build target.
Currently working:
- mmc0 (on board microSD)
- i2c0 and i2c2 (i2c1 not used)
- led on GPIO
Signed-off-by: Florian Vaussard
---
arch/arm/boot/dts/omap3-overo.dtsi | 42
arch/arm/boot/dts/omap3-tobi.dts | 35 ++
arch/arm/mach-omap2/Makefile.boot |2 +-
3 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-overo.dtsi
create mode 100644 arch/arm/boot/dts/omap3-tobi.dts
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
new file mode 100644
index 000..d6cc5e2
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
+ *
+ * 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.
+ */
+
+/*
+ * The Gumstix Overo must be combined with an expansion board.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+&i2c1 {
+ clock-frequency = <260>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+/* i2c2 pins are used for gpio */
+&i2c2 {
+ status = "disabled";
+};
+
+/* on board microSD slot */
+&mmc1 {
+ vmmc-supply = <&vmmc1>;
+ bus-width = <4>;
+};
+
+/* optional on board WiFi */
+&mmc2 {
+ bus-width = <4>;
+};
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
new file mode 100644
index 000..a13d12d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
+ *
+ * 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.
+ */
+
+/*
+ * Tobi expansion board is manufactured by Gumstix Inc.
+ */
+
+/include/ "omap3-overo.dtsi"
+
+/ {
+ model = "TI OMAP3 Gumstix Overo on Tobi";
+ compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3";
+
+ leds {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "overo:red:gpio21";
+ gpios = <&gpio1 21 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&i2c3 {
+ clock-frequency = <10>;
+};
+
+&mmc3 {
+ status = "disabled";
+};
diff --git a/arch/arm/mach-omap2/Makefile.boot
b/arch/arm/mach-omap2/Makefile.boot
index 6cf1c2d..18813ab 100644
--- a/arch/arm/mach-omap2/Makefile.boot
+++ b/arch/arm/mach-omap2/Makefile.boot
@@ -3,7 +3,7 @@ params_phys-y := 0x8100
initrd_phys-y := 0x8080
dtb-$(CONFIG_SOC_OMAP2420) += omap2420-h4.dtb
-dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-evm.dtb
+dtb-$(CONFIG_ARCH_OMAP3) += omap3-beagle.dtb omap3-evm.dtb omap3-tobi.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-panda.dtb omap4-pandaES.dtb
dtb-$(CONFIG_ARCH_OMAP4) += omap4-var_som.dtb omap4-sdp.dtb
dtb-$(CONFIG_SOC_OMAP5)+= omap5-evm.dtb
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion
The Gumstix Overo is a computer on module using an OMAP3 processor. This module must be plugged into an expansion board. This patchset adds a first device tree support for the Overo, using the Tobi expansion board. The current support is able to boot and mount the rootfs from MMC, with a few extra features. The first patch creates the device tree for both the Overo and the Tobi expansion board, and updates the dtb build target. The second patch updates the omap/dts documentation. This patchset applies on tony's tree [1], devel-dt branch. Regards, Florian [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary Florian Vaussard (2): ARM: omap/dts: Add support for Gumstix Overo with Tobi expansion board ARM: omap/dts: update the documentation .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/boot/dts/omap3-overo.dtsi | 42 arch/arm/boot/dts/omap3-tobi.dts | 35 arch/arm/mach-omap2/Makefile.boot |2 +- 4 files changed, 81 insertions(+), 1 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-overo.dtsi create mode 100644 arch/arm/boot/dts/omap3-tobi.dts -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: > * Vaibhav Hiremath [120831 07:55]: > > Hi Russell & Tony, > > > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > > baseport submission we had aligned that, we won't create separate EVM > > options, killing the board file all-together. > > > > Having said that, the early printk option (DEBUG_LL) is broken, the > > auto-generated file "./include/generated/mach-types.h" still refers to > > CONFIG_MACH_AM335XEVM option, > > The way we're heading is that the DEBUG_LL options will only work for > one hardcoded machine where you need to select the uart type and address > in Kconfig. Or just patch it in. > > > #ifdef CONFIG_MACH_AM335XEVM > > # ifdef machine_arch_type > > # undef machine_arch_type > > # define machine_arch_type __machine_arch_type > > # else > > # define machine_arch_type MACH_TYPE_AM335XEVM > > # endif > > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) > > #else > > # define machine_is_am335xevm() (0) > > #endif > > > > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or > > ARCH_OMAP2PLUS, something like below, > > > > am335xevmSOC_AM33XX AM335XEVM 3589 > > > > OR > > > > am335xevmARCH_OMAP2PLUS AM335XEVM 3589 > > > > > > Can you comment on this? Based on that I will submit the patch. > > I think that would at minimum break things for autogenerated > mach-types.h where if only some other non-am335xevm machine is > selected (like omap-generic) things don't get optimized out any > longer as they currently do. > Agreed. In that case the first option should work here, right? Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: leds-gpio: adopt pinctrl support
* AnilKumar Ch [120831 02:30]:
> Adopt pinctrl support to leds-gpio driver, based on the device
> pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
> mode.
>
> Signed-off-by: AnilKumar Ch
> ---
> drivers/leds/leds-gpio.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index c032b21..d98dfb9 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> struct gpio_led_data {
> struct led_classdev cdev;
> @@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct
> platform_device *pdev)
> {
> struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
> struct gpio_leds_priv *priv;
> - int i, ret = 0;
> + struct pinctrl *pinctrl;
> + int i = 0;
> + int ret = 0;
> +
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl)) {
> + return PTR_ERR(pinctrl);
> + }
I think you need to just print out a warning here as most systems don't
have the pinctrl implemented. And some people just do static pinmuxing
in the bootloader.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
* Ravi Babu [120831 04:10]: > --- a/arch/arm/plat-omap/include/plat/usb.h > +++ b/arch/arm/plat-omap/include/plat/usb.h > @@ -95,7 +95,6 @@ extern void am35x_musb_reset(void); > extern void am35x_musb_phy_power(u8 on); > extern void am35x_musb_clear_irq(void); > extern void am35x_set_mode(u8 musb_mode); > -extern void ti81xx_musb_phy_power(u8 on); > > /* AM35x */ > /* USB 2.0 PHY Control */ > @@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on); > #define CONF2_DATPOL (1 << 1) > > /* TI81XX specific definitions */ > -#define USBCTRL0 0x620 > -#define USBSTAT0 0x624 > +#define MUSB_USBSS_REV_816X 0x9 > +#define MUSB_USBSS_REV_814X 0xb > > /* TI816X PHY controls bits */ > #define TI816X_USBPHY0_NORMAL_MODE (1 << 0) This file needs to move to include/linux/platform_data/usb-omap.h as it's blocking the ARM single zImage changes so some coordination is required here. Felipe, can you do a minimal immutable branch with just one patch against v3.6-rc3 that move the header so I can pull in too? 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: [PATCH RESEND v4 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Op 30 aug. 2012, om 22:35 heeft Tony Lindgren het volgende
geschreven:
> * AnilKumar Ch [120828 01:11]:
>> Adds GPIO pinctrl nodes to am3358_pinmux master node to control
>> user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
>>
>> Signed-off-by: AnilKumar Ch
>> ---
>> arch/arm/boot/dts/am335x-bone.dts | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>> b/arch/arm/boot/dts/am335x-bone.dts
>> index a7906cb..58f5042 100644
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -18,6 +18,20 @@
>> reg = <0x8000 0x1000>; /* 256 MB */
>> };
>>
>> +am3358_pinmux: pinmux@44E10800 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&userled_pins>;
>> +
>> +userled_pins: pinmux_userled_pins {
>> +pinctrl-single,pins = <
>> +0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
>> MODE7 */
>> +0x58 0x17 /* gpmc_a6.gpio1_22,
>> OUTPUT_PULLUP | MODE7 */
>> +0x5C 0x7/* gpmc_a7.gpio1_23, OUTPUT |
>> MODE7 */
>> +0x60 0x17 /* gpmc_a8.gpio1_24,
>> OUTPUT_PULLUP | MODE7 */
>> +>;
>> +};
>> +};
>> +
>
> Looks like this patch should also claim these pins by the led driver.
> Then the led driver should just do pinctrl_get_select_default(&pdev->dev)
> in it's probe function to set the pins.
FWIW, I've been using this for a while now:
+ leds {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "beaglebone::usr0";
+ gpios = <&gpio2 21 0>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ mmc {
+ label = "beaglebone:usr1";
+ gpios = <&gpio2 22 0>;
+ linux,default-trigger = "mmc0";
+ };--
To unsubscribe from this list: send the line "unsubscribe 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: Without MACH_ option Early printk (DEBUG_LL)
* Vaibhav Hiremath [120831 07:55]: > Hi Russell & Tony, > > AM335X EVM (based on AM33XX device) only supports DT boot mode and > doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during > baseport submission we had aligned that, we won't create separate EVM > options, killing the board file all-together. > > Having said that, the early printk option (DEBUG_LL) is broken, the > auto-generated file "./include/generated/mach-types.h" still refers to > CONFIG_MACH_AM335XEVM option, The way we're heading is that the DEBUG_LL options will only work for one hardcoded machine where you need to select the uart type and address in Kconfig. Or just patch it in. > #ifdef CONFIG_MACH_AM335XEVM > # ifdef machine_arch_type > # undef machine_arch_type > # define machine_arch_type __machine_arch_type > # else > # define machine_arch_type MACH_TYPE_AM335XEVM > # endif > # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) > #else > # define machine_is_am335xevm() (0) > #endif > > > So I am thinking of changing the config_xxx option to SOC_AM33XX or > ARCH_OMAP2PLUS, something like below, > > am335xevmSOC_AM33XX AM335XEVM 3589 > > OR > > am335xevmARCH_OMAP2PLUS AM335XEVM 3589 > > > Can you comment on this? Based on that I will submit the patch. I think that would at minimum break things for autogenerated mach-types.h where if only some other non-am335xevm machine is selected (like omap-generic) things don't get optimized out any longer as they currently do. 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: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
On Fri, Aug 31, 2012 at 6:49 PM, Felipe Balbi wrote: > On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: >> Hi, >> >> On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: >> > Hi, >> > >> > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: >> >> From: Santhapuri, Damodar >> >> >> >> AM335x uses NOP transceiver driver and need to enable builtin PHY >> >> by writing into usb_ctrl register available in system control >> >> module register space. This is being added at musb glue driver >> >> layer untill a separate system control module driver is available. >> >> >> >> Signed-off-by: Ajay Kumar Gupta >> >> Signed-off-by: Santhapuri, Damodar >> >> Signed-off-by: Ravi Babu >> > >> > Kishon, you were adding a real phy driver for OMAP's internal phy logic >> > on one of your patches and I believe this will conflict with your >> > changes, right ? >> >> Indeed. My final patch of that series removes some of the functions >> from omap_phy_internal.c (which was taken care in the phy driver). >> > >> > How does this look to you ? Is this at least correct ? I suppose the >> > correct way would be to actually have the system control module driver >> > which we have been waiting, right ? >> >> Correct. I think once we have the system control module driver in >> place, we'll have everything wrt control module register writes >> implemented in correct way. > > So $SUBJECT will pretty much be thrown away once we have SCM driver, in > that case it's best to wait a bit longer and apply this series once SCM > driver is available and after your series too... you agree ? Yes. That would be better. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
On 08/31/2012 05:36 PM, Hiremath, Vaibhav wrote: > On Fri, Aug 31, 2012 at 20:54:53, Cousson, Benoit wrote: ... > I think you are getting confused between Vaibhav B and Vaibhav H :) > We have two Vaibhav's roaming around here ;-) Oops, sorry, this is the very first time I realized that two different Vaibhav were sending patches on very similar topic... That's why you were so good generating a lot of patches :-) You have a dual channel of patches :-) > I was not there during LPC this time, it was Vaibhav B who attended it. > I will sync up with him and try to get more info on it. Sorry again for the confusion. 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: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
On Fri, Aug 31, 2012 at 20:54:53, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 08/29/2012 11:48 AM, Vaibhav Hiremath wrote:
> > With the new devices (like, AM33XX and OMAP5) we now only support
> > DT boot mode of operation and now it is the time to start killing
> > slowly the dependency on hwmod, so with this patch, we are starting
> > with device resources.
>
> Thanks for working on that.
>
> > The idea here is implemented considering to both boot modes -
> > - DT boot mode
> > OF framework will construct the resource structure (currently
> > does for MEM & IRQ resource) and we should respect/use these
> > resources, killing hwmod dependency.
> > If pdev->num_resources > 0, we assume that MEM & IRQ resources
> > have been allocated by OF layer already (through DTB).
> >
> > Once DMA resource is available from OF layer, we should
> > kill filling any resources from hwmod.
>
> Yeap, I did a similar patch some months ago and decided to drop it
> because I was expected the DMA binding to be there and wanted to avoid
> adding more code that we are going to remove later.
>
> The other potential issue is that when the binding will be there, we
> will have to update all the drivers and DTS first before being able to
> change the hwmod code from hwmod DMA to DTS DMA.
> I was thinking of something smoother that will check if DMA is in DTS
> and fall back to hwmod if not to avoid that.
> But again, I'm not sure it worth the effort.
>
> > - Non-DT boot mode
> > Here, pdev->num_resources = 0, and we should get all the
> > resources from hwmod (following existing steps)
> >
> > Signed-off-by: Vaibhav Hiremath
> > Cc: Benoit Cousson
> > Cc: Tony Lindgren
> > Cc: Paul Walmsley
> > Cc: Kevin Hilman
> > ---
> > This patch is tested on BeagleBone and AM37xEVM.
>
> I'll try to do more testing on Panda next week.
>
Thanks a lot.
> > Why RFC?
> > Still we have function duplication omap_device_fill_resources() and
> > omap_device_fill_dma_resources(), we can actually split the function
> > into 3 resources and avoid duplication -
> > - omap_device_fill_dma_resources()
> > - omap_device_fill_mem_resources()
> > - omap_device_fill_irq_resources()
> >
> > Actually I wanted to clean it further but thought of getting
> > feedback first and then proceed further.
>
> Well, that's anyway temporary code that should be gone in 6 months from
> now (ideally). So that looks pretty good to me.
>
> > arch/arm/mach-omap2/omap_hwmod.c | 27 ++
> > arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> > arch/arm/plat-omap/omap_device.c | 72
> > +
> > 3 files changed, 88 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> > b/arch/arm/mach-omap2/omap_hwmod.c
> > index 31ec283..edabfb3 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -3330,6 +3330,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
> > struct resource *res)
> > }
> >
> > /**
> > + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
> > + * @oh: struct omap_hwmod *
> > + * @res: pointer to the array of struct resource to fill
> > + *
> > + * Fill the struct resource array @res with dma resource data from the
> > + * omap_hwmod @oh. Intended to be called by code that registers
> > + * omap_devices. See also omap_hwmod_count_resources(). Returns the
> > + * number of array elements filled.
> > + */
> > +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> > *res)
> > +{
> > + int i, sdma_reqs_cnt;
> > + int r = 0;
> > +
> > + sdma_reqs_cnt = _count_sdma_reqs(oh);
> > + for (i = 0; i < sdma_reqs_cnt; i++) {
> > + (res + r)->name = (oh->sdma_reqs + i)->name;
> > + (res + r)->start = (oh->sdma_reqs + i)->dma_req;
> > + (res + r)->end = (oh->sdma_reqs + i)->dma_req;
> > + (res + r)->flags = IORESOURCE_DMA;
> > + r++;
> > + }
> > +
> > + return r;
> > +}
> > +
> > +/**
> > * omap_hwmod_get_resource_byname - fetch IP block integration data by name
> > * @oh: struct omap_hwmod * to operate on
> > * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
> > diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > index 9b9646c..0533073 100644
> > --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> > @@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
> >
> > int omap_hwmod_count_resources(struct omap_hwmod *oh);
> > int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
> > +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> > *res);
> > int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int
> > type,
> >const
Re: [PATCH 0/9] Clean up hardcoded IRQs for mach-omap2, enable SPARSE_IRQ, plaform_data/gpio-omap.h
* Rob Herring [120830 22:59]: > On 08/30/2012 07:52 PM, Tony Lindgren wrote: > > Hi all, > > > > Here's the first set of omap header clean-up patches needed for single > > zImage support. This series is based v3.6-rc3 and the following patches > > to avoid merge conflicts with the includes: > > > > - Arnd's patch "ARM: omap: move platform_data definitions" > > - Igor's series "ARM: OMAP: cleanup plat/board.h file" > > - Afzal's series "Prepare for GPMC driver conversion (w.r.t MTD)" > > > > Looks like I can drop my omap gpio changes with this. Do you have a git > tree with this? Yes no need for those changes for omap :) I have not pushed out any branch yet, I'm waiting on the scripted platform data move Arnd announced later on in the "[PATCH 4/4] [RFC] ARM: treewide: manually change more" thread that are now in the arm-soc tree testing/platform-data branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer
Hi Vaibhav,
On 08/29/2012 11:48 AM, Vaibhav Hiremath wrote:
> With the new devices (like, AM33XX and OMAP5) we now only support
> DT boot mode of operation and now it is the time to start killing
> slowly the dependency on hwmod, so with this patch, we are starting
> with device resources.
Thanks for working on that.
> The idea here is implemented considering to both boot modes -
> - DT boot mode
> OF framework will construct the resource structure (currently
> does for MEM & IRQ resource) and we should respect/use these
> resources, killing hwmod dependency.
> If pdev->num_resources > 0, we assume that MEM & IRQ resources
> have been allocated by OF layer already (through DTB).
>
> Once DMA resource is available from OF layer, we should
> kill filling any resources from hwmod.
Yeap, I did a similar patch some months ago and decided to drop it
because I was expected the DMA binding to be there and wanted to avoid
adding more code that we are going to remove later.
The other potential issue is that when the binding will be there, we
will have to update all the drivers and DTS first before being able to
change the hwmod code from hwmod DMA to DTS DMA.
I was thinking of something smoother that will check if DMA is in DTS
and fall back to hwmod if not to avoid that.
But again, I'm not sure it worth the effort.
> - Non-DT boot mode
> Here, pdev->num_resources = 0, and we should get all the
> resources from hwmod (following existing steps)
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Benoit Cousson
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> ---
> This patch is tested on BeagleBone and AM37xEVM.
I'll try to do more testing on Panda next week.
> Why RFC?
> Still we have function duplication omap_device_fill_resources() and
> omap_device_fill_dma_resources(), we can actually split the function
> into 3 resources and avoid duplication -
> - omap_device_fill_dma_resources()
> - omap_device_fill_mem_resources()
> - omap_device_fill_irq_resources()
>
> Actually I wanted to clean it further but thought of getting
> feedback first and then proceed further.
Well, that's anyway temporary code that should be gone in 6 months from
now (ideally). So that looks pretty good to me.
> arch/arm/mach-omap2/omap_hwmod.c | 27 ++
> arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
> arch/arm/plat-omap/omap_device.c | 72 +
> 3 files changed, 88 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 31ec283..edabfb3 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3330,6 +3330,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
> struct resource *res)
> }
>
> /**
> + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
> + * @oh: struct omap_hwmod *
> + * @res: pointer to the array of struct resource to fill
> + *
> + * Fill the struct resource array @res with dma resource data from the
> + * omap_hwmod @oh. Intended to be called by code that registers
> + * omap_devices. See also omap_hwmod_count_resources(). Returns the
> + * number of array elements filled.
> + */
> +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> *res)
> +{
> + int i, sdma_reqs_cnt;
> + int r = 0;
> +
> + sdma_reqs_cnt = _count_sdma_reqs(oh);
> + for (i = 0; i < sdma_reqs_cnt; i++) {
> + (res + r)->name = (oh->sdma_reqs + i)->name;
> + (res + r)->start = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->end = (oh->sdma_reqs + i)->dma_req;
> + (res + r)->flags = IORESOURCE_DMA;
> + r++;
> + }
> +
> + return r;
> +}
> +
> +/**
> * omap_hwmod_get_resource_byname - fetch IP block integration data by name
> * @oh: struct omap_hwmod * to operate on
> * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 9b9646c..0533073 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
>
> int omap_hwmod_count_resources(struct omap_hwmod *oh);
> int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
> +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource
> *res);
> int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
> const char *name, struct resource *res);
>
> diff --git a/arch/arm/plat-omap/omap_device.c
> b/arch/arm/plat-omap/omap_device.c
> index c490240..fd15a3a 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -486,6 +486,33 @@ static int omap_device_fill_resource
Re: [PATCH v2 09/23] OMAPDSS: Create links between managers, outputs and devices
On Fri, 2012-08-31 at 17:45 +0300, Tomi Valkeinen wrote: > So I'm not really against having the enum. It just would've been neat to > have the output type and instance number encoded into this enum, so that > it'd be easy to extract either one. But that kinda ruins the possibility > to use it in a bit mask. Hmm, this is just a non-finished idea (and it's late Friday... =) that came to my mind: I had a brief look at TRMs for different OMAPs (omap4/5/6), and it looks like the maximum output options for one manager is 4 (LCD2 on omap4460). Usually there are just 2 or 3. So, we could trust that the above holds and do this so that we use a u32 field to hold four 8 bit output options. In 8 bits we can combine two values from 0 to 15. 15 should be more than enough for output display types and output instances. Then with helpers like these: /* second DSI instance */ #define DSI1 ((1 << 4) | DISPLAY_TYPE_DSI) /* first DPI instance */ #define DPI0 ((0 << 4) | DISPLAY_TYPE_DPI) an example output options for a manager that can be connected to DSI1 and DPI0 could be: (DSI1 << 8) | (DPI0) This could be parsed with a for loop, going though the 4 bytes of the u32 value. This would allow us to avoid managing a real list, and we could extract the instance and the type from the value. Of course we could also extend the field to u64 to hold 8 outputs if need be. Whether this would be worth it compared to simple bitmask, I'm not sure =). Depends how much we need to extract the ID and type. Tomi signature.asc Description: This is a digitally signed message part
Without MACH_ option Early printk (DEBUG_LL)
Hi Russell & Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file "./include/generated/mach-types.h" still refers to CONFIG_MACH_AM335XEVM option, #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below, am335xevmSOC_AM33XX AM335XEVM 3589 OR am335xevmARCH_OMAP2PLUS AM335XEVM 3589 Can you comment on this? Based on that I will submit the patch. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/23] OMAPDSS: Create links between managers, outputs and devices
On Fri, 2012-08-31 at 19:54 +0530, Archit Taneja wrote:
> On Friday 31 August 2012 07:40 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
> >> Links between DSS entities are made in dss_recheck_connections when a new
> >> panel
> >> is probed. Rewrite the code in dss_recheck_connections to link managers to
> >> outputs, and outputs to devices.
> >>
> >> The fields in omap_dss_device struct gives information on which output and
> >> manager to connect to. The desired manager and output pointers are
> >> retrieved and
> >> prepared(existing outputs/devices unset, if default display)) to form the
> >> desired links. The output is linked to the device, and then the manager to
> >> the
> >> output. If a probed device's required manager isn't free, the required
> >> output
> >> is still connected to the device so that it's easier to use the panel in
> >> the
> >> future.
> >
> > I've been pondering this one, and I can't come to a conclusion. The
> > recheck_connections is just so ugly that I'd like to get rid of it =). I
> > guess this patch doesn't make it any more ugly, so we can include it in
> > the patch series.
> >
> > And as I mentioned earlier, I think we should get rid of the
> > OMAP_DISPLAY_TYPE_* enum, as it's kinda extra now. But doing that would
> > require changing all board files. That's not out of the question, but I
> > think we should first make sure we know what we are doing with the board
> > files so we don't go back and forth there.
>
> Yes, I didn't remove it for the same reason.
>
> >
> > Just gathering my thoughts:
> >
> > When we define a panel in DT/board file, we should also define the
> > output instance, because that's part of the hardware design. But there
>
> It's a part of hardware design if the panel can't be detached. But yes,
> even for detachable panels, we can assume that the panel would
> eventually connect to that output.
>
> > are no hardcoded links between mgrs and outputs, so that doesn't belong
> > to the DT/board file. For example, omap4460's DSI1 can take input from
> > LCD1 or LCD2.
>
> Right, so we don't need an equivalent of the dssdev->channel field in DT
> info. As you said, we need the output instance, is that why you were
What I'm planning for DT is a direct link to the output instance.
Something like this (not correct, just to give the idea):
dss {
dpi {
};
};
i2c {
/* an i2c controlled panel */
my-panel {
video-bus = <&dpi>;
};
};
Then my-panel can get the handle from video-bus, and it'll get the
output device directly, without need for any IDs or such.
> sceptical about it being defined as an enum in previous patches?
> Probably we could define output instances in DT as a pair of instance
> number and instance type {number, type}. It would be sort of hard to
> play around with those within OMAPDSS though.
Well, optimally we wouldn't need to know about display types or output
instances, at least in most of the cases. We'd just have a bunch of
managers, and a bunch of outputs, and rules how these can be connected.
And the panel devices would have a link to the output it's connect in HW
level.
There are probably some cases where we need some kind of ID, so that we
can handle the DSI PLL's and such. And we need to setup the rules above
somewhere, and perhaps that code needs IDs to set it up. I'm not sure.
And, well, if we don't have IDs, the rules above need to be some kind of
lists of pointers. Perhaps having a bit mask is just simpler, as we'll
never have too many output instances.
So I'm not really against having the enum. It just would've been neat to
have the output type and instance number encoded into this enum, so that
it'd be easy to extract either one. But that kinda ruins the possibility
to use it in a bit mask.
> > So who could/should make the decision which mgr to use... Well, I don't
> > know on what basis the decision can be made, but I still think omapdss
> > can't make good decisions on that, so probably the whole "chain" should
> > be configured in the omapfb/omapdrm level.
>
> Which manager to chose could be simply picking up the next free manager
> which can connect to that output. omapfb/drm can take care of that.
That's a good default implementation, but not quite perfect. If there
are two displays, often the other display (well, output) can only be
connected to one particular manager, whereas the other one could use two
managers. And if both try to use the same manager, especially if the one
with two options is selected first, the other one is left without a mgr.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 20/23] OMAPDSS: MANAGER: Update display sysfs store
On Friday 31 August 2012 08:00 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
The display sysfs attribute's store function needs to be changed with the
introduction of outputs.
Providing a manager to the display isn't enough to create a link now, the
manager needs and output to connect to. A manager's display store file only
has the information of the manager and the desired display, it is not aware
of which output should the manager connect to.
Because of this, a new constraint needs to be set up when setting a display via
this sysfs file. The constraint is that the desired display should already be
connected to an output before calling this sysfs function.
This might break some existing user space stuff which uses sysfs directly. But
in most cases dss_recheck_connections will connect displays to floating outputs.
DSS sysfs files are being planned to be remove anyway, so it's not much of a
harm.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/manager.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index fd39f66..d808ce2 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -74,18 +74,33 @@ static ssize_t manager_display_store(struct
omap_overlay_manager *mgr,
if (dssdev)
DSSDBG("display %s found\n", dssdev->name);
- if (mgr->get_device(mgr)) {
- r = mgr->unset_device(mgr);
+ if (mgr->output) {
+ if (mgr->output->device) {
+ r = mgr->output->unset_device(mgr->output);
+ if (r) {
+ goto put_device;
+ DSSERR("failed to unset device from output\n");
+ }
+ }
+
+ r = mgr->unset_output(mgr);
if (r) {
- DSSERR("failed to unset display\n");
+ DSSERR("failed to unset current output\n");
goto put_device;
}
}
if (dssdev) {
- r = mgr->set_device(mgr, dssdev);
+ struct omap_dss_output *out = dssdev->output;
+
+ if (!out) {
+ DSSERR("no output connected to device\n");
+ goto put_device;
+ }
+
+ r = mgr->set_output(mgr, out);
if (r) {
- DSSERR("failed to set manager\n");
+ DSSERR("failed to set manager output\n");
goto put_device;
}
Hmm, I think this is a bit broken. If I read this right, the unlinking
removes both mgr-output link and the output-dssdev link. But the linking
part only sets up the mgr-output link.
So if there's a very simple configuration with one display, if you
unlink it via sysfs you can't link it back again.
Ah, right. You might need to reinsert the display module again to get
the output-display link again. Which is bad. Or have a sysfs file for
setting manager output. Which is something we want to stay away from anyway.
The store function gets the mgr and the dssdev as arguments. I think
this could be changed so that the function would "guess" the needed
output. Well, not so much a guess, because a dssdev can only be
connected to one output, defined by the HW design. That is basically
what the recheck_connections does, we could use the same method here.
Then this sysfs file should work just like before.
That's a good idea, we could reuse the code in recheck_connections a
bit. I wanted to stay away from the guessing. But I think we need to do
it if a simple unlink-link of a display itself fails.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 20/23] OMAPDSS: MANAGER: Update display sysfs store
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
> The display sysfs attribute's store function needs to be changed with the
> introduction of outputs.
>
> Providing a manager to the display isn't enough to create a link now, the
> manager needs and output to connect to. A manager's display store file only
> has the information of the manager and the desired display, it is not aware
> of which output should the manager connect to.
>
> Because of this, a new constraint needs to be set up when setting a display
> via
> this sysfs file. The constraint is that the desired display should already be
> connected to an output before calling this sysfs function.
>
> This might break some existing user space stuff which uses sysfs directly. But
> in most cases dss_recheck_connections will connect displays to floating
> outputs.
> DSS sysfs files are being planned to be remove anyway, so it's not much of a
> harm.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/manager.c | 25 -
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/manager.c
> b/drivers/video/omap2/dss/manager.c
> index fd39f66..d808ce2 100644
> --- a/drivers/video/omap2/dss/manager.c
> +++ b/drivers/video/omap2/dss/manager.c
> @@ -74,18 +74,33 @@ static ssize_t manager_display_store(struct
> omap_overlay_manager *mgr,
> if (dssdev)
> DSSDBG("display %s found\n", dssdev->name);
>
> - if (mgr->get_device(mgr)) {
> - r = mgr->unset_device(mgr);
> + if (mgr->output) {
> + if (mgr->output->device) {
> + r = mgr->output->unset_device(mgr->output);
> + if (r) {
> + goto put_device;
> + DSSERR("failed to unset device from output\n");
> + }
> + }
> +
> + r = mgr->unset_output(mgr);
> if (r) {
> - DSSERR("failed to unset display\n");
> + DSSERR("failed to unset current output\n");
> goto put_device;
> }
> }
>
> if (dssdev) {
> - r = mgr->set_device(mgr, dssdev);
> + struct omap_dss_output *out = dssdev->output;
> +
> + if (!out) {
> + DSSERR("no output connected to device\n");
> + goto put_device;
> + }
> +
> + r = mgr->set_output(mgr, out);
> if (r) {
> - DSSERR("failed to set manager\n");
> + DSSERR("failed to set manager output\n");
> goto put_device;
> }
>
Hmm, I think this is a bit broken. If I read this right, the unlinking
removes both mgr-output link and the output-dssdev link. But the linking
part only sets up the mgr-output link.
So if there's a very simple configuration with one display, if you
unlink it via sysfs you can't link it back again.
The store function gets the mgr and the dssdev as arguments. I think
this could be changed so that the function would "guess" the needed
output. Well, not so much a guess, because a dssdev can only be
connected to one output, defined by the HW design. That is basically
what the recheck_connections does, we could use the same method here.
Then this sysfs file should work just like before.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 15/23] OMAPDSS: RFBI: Add dssdev pointers as arguments to all exported functions
On Friday 31 August 2012 07:50 PM, Tomi Valkeinen wrote: On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: All functions of an interface driver used by a panel driver should have an omap_dss_device pointer as an argument. This may not be needed by some of the interfaces now as driver data is globally visible in them. The correct way to retrieve driver data is to extract the platform device from the output, and then extract the driver data from the platform device. Add dssdev arguments from functions used by panel drivers which currently miss it. This will come to use when the RFBI functions retrieve the driver data in the correct manner. This and the similar patch for HDMI could probably also be left out for now. Again I agree that this is correct direction, but this is not really needed (right?) for output work or writeback. And we'll eventually just change these parameters again. The motivation for this patch was probably to have common format for the output driver's functions, so that you can use func pointers in an ops struct? Yes, or the fact that we need the function to pass something related to the output to configure it. Things work now since we just have one instance of hdmi/rfbi, and that we have a global struct from which we can get the required info. We definitely need to pass something to these functions, whether we should pass the panel, or the output itself isn't clear yet. Let's delay that work until the common panel framework gets a bit more solid. I get your point. We might need to replace the dssdevs with outputs (or something similar) in the future. Hence it would lead to churn. Sorry if I'm saying "leave this patch out" for most of the patches =). I just want to avoid extra churn, going back and forth with the code. The most important things now are to get the output work in a state that WB can be used, and on the other hand to remove the dssdev dependencies so that at some point we can remove dssdev totally. That's okay. If we keep this stuff, it'll be us who have to change it later :) Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/23] OMAPDSS: Create links between managers, outputs and devices
On Friday 31 August 2012 07:40 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Links between DSS entities are made in dss_recheck_connections when a new panel
is probed. Rewrite the code in dss_recheck_connections to link managers to
outputs, and outputs to devices.
The fields in omap_dss_device struct gives information on which output and
manager to connect to. The desired manager and output pointers are retrieved and
prepared(existing outputs/devices unset, if default display)) to form the
desired links. The output is linked to the device, and then the manager to the
output. If a probed device's required manager isn't free, the required output
is still connected to the device so that it's easier to use the panel in the
future.
I've been pondering this one, and I can't come to a conclusion. The
recheck_connections is just so ugly that I'd like to get rid of it =). I
guess this patch doesn't make it any more ugly, so we can include it in
the patch series.
And as I mentioned earlier, I think we should get rid of the
OMAP_DISPLAY_TYPE_* enum, as it's kinda extra now. But doing that would
require changing all board files. That's not out of the question, but I
think we should first make sure we know what we are doing with the board
files so we don't go back and forth there.
Yes, I didn't remove it for the same reason.
Just gathering my thoughts:
When we define a panel in DT/board file, we should also define the
output instance, because that's part of the hardware design. But there
It's a part of hardware design if the panel can't be detached. But yes,
even for detachable panels, we can assume that the panel would
eventually connect to that output.
are no hardcoded links between mgrs and outputs, so that doesn't belong
to the DT/board file. For example, omap4460's DSI1 can take input from
LCD1 or LCD2.
Right, so we don't need an equivalent of the dssdev->channel field in DT
info. As you said, we need the output instance, is that why you were
sceptical about it being defined as an enum in previous patches?
Probably we could define output instances in DT as a pair of instance
number and instance type {number, type}. It would be sort of hard to
play around with those within OMAPDSS though.
So who could/should make the decision which mgr to use... Well, I don't
know on what basis the decision can be made, but I still think omapdss
can't make good decisions on that, so probably the whole "chain" should
be configured in the omapfb/omapdrm level.
Which manager to chose could be simply picking up the next free manager
which can connect to that output. omapfb/drm can take care of that.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 15/23] OMAPDSS: RFBI: Add dssdev pointers as arguments to all exported functions
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: > All functions of an interface driver used by a panel driver should have an > omap_dss_device pointer as an argument. This may not be needed by some of the > interfaces now as driver data is globally visible in them. The correct way > to retrieve driver data is to extract the platform device from the output, > and then extract the driver data from the platform device. > > Add dssdev arguments from functions used by panel drivers which currently miss > it. This will come to use when the RFBI functions retrieve the driver data > in the correct manner. This and the similar patch for HDMI could probably also be left out for now. Again I agree that this is correct direction, but this is not really needed (right?) for output work or writeback. And we'll eventually just change these parameters again. The motivation for this patch was probably to have common format for the output driver's functions, so that you can use func pointers in an ops struct? Let's delay that work until the common panel framework gets a bit more solid. Sorry if I'm saying "leave this patch out" for most of the patches =). I just want to avoid extra churn, going back and forth with the code. The most important things now are to get the output work in a state that WB can be used, and on the other hand to remove the dssdev dependencies so that at some point we can remove dssdev totally. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 09/23] OMAPDSS: Create links between managers, outputs and devices
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: > Links between DSS entities are made in dss_recheck_connections when a new > panel > is probed. Rewrite the code in dss_recheck_connections to link managers to > outputs, and outputs to devices. > > The fields in omap_dss_device struct gives information on which output and > manager to connect to. The desired manager and output pointers are retrieved > and > prepared(existing outputs/devices unset, if default display)) to form the > desired links. The output is linked to the device, and then the manager to the > output. If a probed device's required manager isn't free, the required output > is still connected to the device so that it's easier to use the panel in the > future. I've been pondering this one, and I can't come to a conclusion. The recheck_connections is just so ugly that I'd like to get rid of it =). I guess this patch doesn't make it any more ugly, so we can include it in the patch series. And as I mentioned earlier, I think we should get rid of the OMAP_DISPLAY_TYPE_* enum, as it's kinda extra now. But doing that would require changing all board files. That's not out of the question, but I think we should first make sure we know what we are doing with the board files so we don't go back and forth there. Just gathering my thoughts: When we define a panel in DT/board file, we should also define the output instance, because that's part of the hardware design. But there are no hardcoded links between mgrs and outputs, so that doesn't belong to the DT/board file. For example, omap4460's DSI1 can take input from LCD1 or LCD2. So who could/should make the decision which mgr to use... Well, I don't know on what basis the decision can be made, but I still think omapdss can't make good decisions on that, so probably the whole "chain" should be configured in the omapfb/omapdrm level. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 10/23] OMAPDSS: DPI: Pass omap_dss_output within the driver
On Friday 31 August 2012 07:18 PM, Tomi Valkeinen wrote: On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: When a panel driver calls a DPI function, it passes the omap_dss_device pointer, this pointer currently propagates within the DPI driver to configure the interface. Extract the omap_dss_output pointer from omap_dss_device received from the panel driver, pass the output pointer to DPI functions local to the driver to configure the interface, these functions no longer need omap_dss_device since the driver now maintains a copy of output parameters. Replace dssdev->manager references with out->manager references as only these will be valid later. With the addition of outputs. There is a possibility that an omap_dss_device isn't connected to an output, or a manager isn't connected to an output yet. Ensure that the DPI interface functions proceed only if the output is non NULL. I agree with the direction of this and the similar patches for other outputs, but I think we should leave these out for now, at least most of the code here. So ultimately we'll have the output drivers taking the omap_dss_output as an argument, and we don't need dssdev anymore. But we can't do that yet, and now that you mix both approaches I think the end result makes the code a bit more confusing, and it would be changed again later when dssdev can be removed. What I mean is that, for example, display_enable takes dssdev as an argument. Then you extract output from that, and pass output to some other functions. Then these functions again extract dssdev from the output. This feels like extra churn that doesn't really help anything, and will be changed later when the functions get output as an argument. So I propose to keep passing dssdev around until we've removed the dependencies to dssdev, and we (probably) get the output directly as an argument to the functions. Then we can clean them up properly at one go. The dssdev->manager parts still need to be changed to out->manager, of course, but I think those are minority of the changes here and the following patches. Ok. Yes, I guess if we start from here, we would need to do unnecessary changes once we completely switch to outputs. I'll change these output patches such that, only the dssdev->manager references are fixed to dssdev->output->manager. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/23] OMAPDSS: DPI: Pass omap_dss_output within the driver
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: > When a panel driver calls a DPI function, it passes the omap_dss_device > pointer, this pointer currently propagates within the DPI driver to configure > the interface. > > Extract the omap_dss_output pointer from omap_dss_device received from the > panel > driver, pass the output pointer to DPI functions local to the driver to > configure the interface, these functions no longer need omap_dss_device since > the driver now maintains a copy of output parameters. > > Replace dssdev->manager references with out->manager references as only these > will be valid later. > > With the addition of outputs. There is a possibility that an omap_dss_device > isn't connected to an output, or a manager isn't connected to an output yet. > Ensure that the DPI interface functions proceed only if the output is non > NULL. I agree with the direction of this and the similar patches for other outputs, but I think we should leave these out for now, at least most of the code here. So ultimately we'll have the output drivers taking the omap_dss_output as an argument, and we don't need dssdev anymore. But we can't do that yet, and now that you mix both approaches I think the end result makes the code a bit more confusing, and it would be changed again later when dssdev can be removed. What I mean is that, for example, display_enable takes dssdev as an argument. Then you extract output from that, and pass output to some other functions. Then these functions again extract dssdev from the output. This feels like extra churn that doesn't really help anything, and will be changed later when the functions get output as an argument. So I propose to keep passing dssdev around until we've removed the dependencies to dssdev, and we (probably) get the output directly as an argument to the functions. Then we can clean them up properly at one go. The dssdev->manager parts still need to be changed to out->manager, of course, but I think those are minority of the changes here and the following patches. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > Hi, > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > >> From: Santhapuri, Damodar > >> > >> AM335x uses NOP transceiver driver and need to enable builtin PHY > >> by writing into usb_ctrl register available in system control > >> module register space. This is being added at musb glue driver > >> layer untill a separate system control module driver is available. > >> > >> Signed-off-by: Ajay Kumar Gupta > >> Signed-off-by: Santhapuri, Damodar > >> Signed-off-by: Ravi Babu > > > > Kishon, you were adding a real phy driver for OMAP's internal phy logic > > on one of your patches and I believe this will conflict with your > > changes, right ? > > Indeed. My final patch of that series removes some of the functions > from omap_phy_internal.c (which was taken care in the phy driver). > > > > How does this look to you ? Is this at least correct ? I suppose the > > correct way would be to actually have the system control module driver > > which we have been waiting, right ? > > Correct. I think once we have the system control module driver in > place, we'll have everything wrt control module register writes > implemented in correct way. So $SUBJECT will pretty much be thrown away once we have SCM driver, in that case it's best to wait a bit longer and apply this series once SCM driver is available and after your series too... you agree ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi, On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > Hi, > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: >> From: Santhapuri, Damodar >> >> AM335x uses NOP transceiver driver and need to enable builtin PHY >> by writing into usb_ctrl register available in system control >> module register space. This is being added at musb glue driver >> layer untill a separate system control module driver is available. >> >> Signed-off-by: Ajay Kumar Gupta >> Signed-off-by: Santhapuri, Damodar >> Signed-off-by: Ravi Babu > > Kishon, you were adding a real phy driver for OMAP's internal phy logic > on one of your patches and I believe this will conflict with your > changes, right ? Indeed. My final patch of that series removes some of the functions from omap_phy_internal.c (which was taken care in the phy driver). > > How does this look to you ? Is this at least correct ? I suppose the > correct way would be to actually have the system control module driver > which we have been waiting, right ? Correct. I think once we have the system control module driver in place, we'll have everything wrt control module register writes implemented in correct way. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap-i2c: fix incorrect log message when using a device tree
On 08/31/2012 01:02 PM, Florian Vaussard wrote: > When booting using a device tree, the adapter number is dynamically > assigned after the log message is sent. > This patch modifies the log message to get a correct adapter id. > > Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo). Thanks for the fix. Tested successfully on OMAP4 SDP DT boot as well. [0.00] Linux version 3.6.0-rc3-00030-g491038d (bcousson@lnwes3201) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #6 SMP Fri Aug 31 13:50:48 CEST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 SDP board ... [0.667205] omap_i2c i2c.15: bus 0 rev2.4.0 at 400 kHz ... [0.768341] omap_i2c i2c.16: bus 1 rev2.4.0 at 400 kHz [0.783905] omap_i2c i2c.17: bus 2 rev2.4.0 at 400 kHz [0.799530] omap_i2c i2c.18: bus 3 rev2.4.0 at 400 kHz > Signed-off-by: Florian Vaussard Tested-by: Benoit Cousson and Acked-by: Benoit Cousson Regards, Benoit > --- > drivers/i2c/busses/i2c-omap.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 5d19a49..136b4fe 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1064,9 +1064,6 @@ omap_i2c_probe(struct platform_device *pdev) > goto err_unuse_clocks; > } > > - dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", pdev->id, > - dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); > - > adap = &dev->adapter; > i2c_set_adapdata(adap, dev); > adap->owner = THIS_MODULE; > @@ -1084,6 +1081,9 @@ omap_i2c_probe(struct platform_device *pdev) > goto err_free_irq; > } > > + dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr, > + dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); > + > of_i2c_register_devices(adap); > > pm_runtime_put(dev->dev); > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/23] OMAP_VOUT: Remove manager->device references
On Friday 31 August 2012 05:41 PM, Tomi Valkeinen wrote: On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: With the introduction of output entities, managers will now connect to outputs. Use the helper op for managers named get_device. This will abstract away the information on how to get the device from an overlay manager. Using the helper function will reduce the number of pointer dereferences a user of OMAPDSS needs to do and reduce risk of a NULL dereference. Almost all the uses here seem to be getting the dssdev from an overlay. Would it make sense to implement get_device for an ovl? That would reduce all the ovl->manager ? ovl->manager->get_device(ovl->manager) : NULL; code to ovl->get_device(ovl). That make sense. We would still need mgr->get_device() though, as in some places, dss and drm try to get the display from the manager. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/23] OMAPDSS: output: Add set/unset device ops for omap_dss_output
On Fri, 2012-08-31 at 17:54 +0530, Archit Taneja wrote: > On Friday 31 August 2012 05:33 PM, Tomi Valkeinen wrote: > > I don't think there's need for this indirection. We should use function > > pointers only when the func pointer may lead to different functions. > > Here we'll always have just one function, dss_output_set_device. We can > > as well call the function directly. > > Okay. I understand that. But in general, don't func pointers prevent us > from exporting more symbols? Yes. But I'm not sure if there's any real downside to exporting, as long as the names are prefixed properly so that there are no name clashes. > > I know we have similar func pointers for ovls/mgrs currently, but I > > don't think they are good either. They are a relic from the time we > > supported "virtual" overlays and managers, and thus could have different > > implementations for the operations. > > Oh okay, I guess you mean the L4/sDMA updates for DSI command mode. Yep. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi,
On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote:
> From: Santhapuri, Damodar
>
> AM335x uses NOP transceiver driver and need to enable builtin PHY
> by writing into usb_ctrl register available in system control
> module register space. This is being added at musb glue driver
> layer untill a separate system control module driver is available.
>
> Signed-off-by: Ajay Kumar Gupta
> Signed-off-by: Santhapuri, Damodar
> Signed-off-by: Ravi Babu
Kishon, you were adding a real phy driver for OMAP's internal phy logic
on one of your patches and I believe this will conflict with your
changes, right ?
How does this look to you ? Is this at least correct ? I suppose the
correct way would be to actually have the system control module driver
which we have been waiting, right ?
> ---
> arch/arm/mach-omap2/board-ti8168evm.c |1 -
> arch/arm/mach-omap2/omap_phy_internal.c | 35
> arch/arm/plat-omap/include/plat/usb.h |5 +-
> drivers/usb/musb/musb_dsps.c| 87
> +--
> 4 files changed, 73 insertions(+), 55 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
> b/arch/arm/mach-omap2/board-ti8168evm.c
> index d4c8392..0c7c098 100644
> --- a/arch/arm/mach-omap2/board-ti8168evm.c
> +++ b/arch/arm/mach-omap2/board-ti8168evm.c
> @@ -26,7 +26,6 @@
> #include
>
> static struct omap_musb_board_data musb_board_data = {
> - .set_phy_power = ti81xx_musb_phy_power,
> .interface_type = MUSB_INTERFACE_ULPI,
> .mode = MUSB_OTG,
> .power = 500,
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
> b/arch/arm/mach-omap2/omap_phy_internal.c
> index d52651a..d80bb16 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode)
>
> omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
> }
> -
> -void ti81xx_musb_phy_power(u8 on)
> -{
> - void __iomem *scm_base = NULL;
> - u32 usbphycfg;
> -
> - scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
> - if (!scm_base) {
> - pr_err("system control module ioremap failed\n");
> - return;
> - }
> -
> - usbphycfg = __raw_readl(scm_base + USBCTRL0);
> -
> - if (on) {
> - if (cpu_is_ti816x()) {
> - usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
> - usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC;
> - } else if (cpu_is_ti814x()) {
> - usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
> - | USBPHY_DPINPUT | USBPHY_DMINPUT);
> - usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
> - | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
> - }
> - } else {
> - if (cpu_is_ti816x())
> - usbphycfg &= ~TI816X_USBPHY0_NORMAL_MODE;
> - else if (cpu_is_ti814x())
> - usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
> -
> - }
> - __raw_writel(usbphycfg, scm_base + USBCTRL0);
> -
> - iounmap(scm_base);
> -}
> diff --git a/arch/arm/plat-omap/include/plat/usb.h
> b/arch/arm/plat-omap/include/plat/usb.h
> index 548a4c8..c2aa4ae 100644
> --- a/arch/arm/plat-omap/include/plat/usb.h
> +++ b/arch/arm/plat-omap/include/plat/usb.h
> @@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
> extern void am35x_musb_phy_power(u8 on);
> extern void am35x_musb_clear_irq(void);
> extern void am35x_set_mode(u8 musb_mode);
> -extern void ti81xx_musb_phy_power(u8 on);
>
> /* AM35x */
> /* USB 2.0 PHY Control */
> @@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on);
> #define CONF2_DATPOL (1 << 1)
>
> /* TI81XX specific definitions */
> -#define USBCTRL0 0x620
> -#define USBSTAT0 0x624
> +#define MUSB_USBSS_REV_816X 0x9
> +#define MUSB_USBSS_REV_814X 0xb
>
> /* TI816X PHY controls bits */
> #define TI816X_USBPHY0_NORMAL_MODE (1 << 0)
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 84d8181..960258d 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -116,9 +116,46 @@ struct dsps_glue {
> struct platform_device *musb; /* child musb pdev */
> const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
> struct timer_list timer;/* otg_workaround timer */
> + u32 __iomem *usb_ctrl;
> + u8 usbss_rev;
> };
>
> /**
> + * musb_dsps_phy_control - phy on/off
> + * @glue: struct dsps_glue *
> + * @on: flag for phy to be switched on or off
> + *
> + * This is to enable the PHY using usb_ctrl register in system control
> + * module space.
> + *
> + * XXX: This function will be removed once we have a seperate driver for
> + * control module
> + */
> +static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
> +{
> + u32 usbphycfg;
> +
> + usbphy
Re: [PATCH v2 03/23] OMAPDSS: output: Add set/unset device ops for omap_dss_output
On Friday 31 August 2012 05:33 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
An output entity represented by the struct omap_dss_output connects to a
omap_dss_device entity. Add functions to set or unset an output's device. This
is similar to how managers and devices were connected previously. An output can
connect to a device without being connected to a manager. However, the output
needs to eventually connect to a manager so that the connected panel can be
enabled.
Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent
breaking things. This will be removed later when outputs are supported
completely.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/output.c | 67 ++
include/video/omapdss.h |5 +++
2 files changed, 72 insertions(+)
diff --git a/drivers/video/omap2/dss/output.c b/drivers/video/omap2/dss/output.c
index 7d81be5..abc3aa2 100644
--- a/drivers/video/omap2/dss/output.c
+++ b/drivers/video/omap2/dss/output.c
@@ -24,9 +24,76 @@
#include "dss.h"
static LIST_HEAD(output_list);
+static DEFINE_MUTEX(output_lock);
+
+static int dss_output_set_device(struct omap_dss_output *out,
+ struct omap_dss_device *dssdev)
+{
+ int r;
+
+ mutex_lock(&output_lock);
+
+ if (out->device) {
+ DSSERR("output already has device %s connected to it\n",
+ out->device->name);
+ r = -EINVAL;
+ goto err;
+ }
+
+ if (out->type != dssdev->type) {
+ DSSERR("output type and display type don't match\n");
+ r = -EINVAL;
+ goto err;
+ }
+
+ out->device = dssdev;
+ dssdev->output = out;
+
+ mutex_unlock(&output_lock);
+
+ return 0;
+err:
+ mutex_unlock(&output_lock);
+
+ return r;
+}
+
+static int dss_output_unset_device(struct omap_dss_output *out)
+{
+ int r;
+
+ mutex_lock(&output_lock);
+
+ if (!out->device) {
+ DSSERR("output doesn't have a device connected to it\n");
+ r = -EINVAL;
+ goto err;
+ }
+
+ if (out->device->state != OMAP_DSS_DISPLAY_DISABLED) {
+ DSSERR("device %s is not disabled, cannot unset device\n",
+ out->device->name);
+ r = -EINVAL;
+ goto err;
+ }
+
+ out->device->output = NULL;
+ out->device = NULL;
+
+ mutex_unlock(&output_lock);
+
+ return 0;
+err:
+ mutex_unlock(&output_lock);
+
+ return r;
+}
void dss_register_output(struct omap_dss_output *out)
{
+ out->set_device = &dss_output_set_device;
+ out->unset_device = &dss_output_unset_device;
+
list_add_tail(&out->list, &output_list);
}
I don't think there's need for this indirection. We should use function
pointers only when the func pointer may lead to different functions.
Here we'll always have just one function, dss_output_set_device. We can
as well call the function directly.
Okay. I understand that. But in general, don't func pointers prevent us
from exporting more symbols?
I know we have similar func pointers for ovls/mgrs currently, but I
don't think they are good either. They are a relic from the time we
supported "virtual" overlays and managers, and thus could have different
implementations for the operations.
Oh okay, I guess you mean the L4/sDMA updates for DSI command mode.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/23] OMAP_VOUT: Remove manager->device references
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote: > With the introduction of output entities, managers will now connect to > outputs. > Use the helper op for managers named get_device. This will abstract away the > information on how to get the device from an overlay manager. > > Using the helper function will reduce the number of pointer dereferences a > user > of OMAPDSS needs to do and reduce risk of a NULL dereference. Almost all the uses here seem to be getting the dssdev from an overlay. Would it make sense to implement get_device for an ovl? That would reduce all the ovl->manager ? ovl->manager->get_device(ovl->manager) : NULL; code to ovl->get_device(ovl). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 03/23] OMAPDSS: output: Add set/unset device ops for omap_dss_output
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
> An output entity represented by the struct omap_dss_output connects to a
> omap_dss_device entity. Add functions to set or unset an output's device. This
> is similar to how managers and devices were connected previously. An output
> can
> connect to a device without being connected to a manager. However, the output
> needs to eventually connect to a manager so that the connected panel can be
> enabled.
>
> Keep the omap_overlay_manager pointer in omap_dss_device for now to prevent
> breaking things. This will be removed later when outputs are supported
> completely.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/output.c | 67
> ++
> include/video/omapdss.h |5 +++
> 2 files changed, 72 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/output.c
> b/drivers/video/omap2/dss/output.c
> index 7d81be5..abc3aa2 100644
> --- a/drivers/video/omap2/dss/output.c
> +++ b/drivers/video/omap2/dss/output.c
> @@ -24,9 +24,76 @@
> #include "dss.h"
>
> static LIST_HEAD(output_list);
> +static DEFINE_MUTEX(output_lock);
> +
> +static int dss_output_set_device(struct omap_dss_output *out,
> + struct omap_dss_device *dssdev)
> +{
> + int r;
> +
> + mutex_lock(&output_lock);
> +
> + if (out->device) {
> + DSSERR("output already has device %s connected to it\n",
> + out->device->name);
> + r = -EINVAL;
> + goto err;
> + }
> +
> + if (out->type != dssdev->type) {
> + DSSERR("output type and display type don't match\n");
> + r = -EINVAL;
> + goto err;
> + }
> +
> + out->device = dssdev;
> + dssdev->output = out;
> +
> + mutex_unlock(&output_lock);
> +
> + return 0;
> +err:
> + mutex_unlock(&output_lock);
> +
> + return r;
> +}
> +
> +static int dss_output_unset_device(struct omap_dss_output *out)
> +{
> + int r;
> +
> + mutex_lock(&output_lock);
> +
> + if (!out->device) {
> + DSSERR("output doesn't have a device connected to it\n");
> + r = -EINVAL;
> + goto err;
> + }
> +
> + if (out->device->state != OMAP_DSS_DISPLAY_DISABLED) {
> + DSSERR("device %s is not disabled, cannot unset device\n",
> + out->device->name);
> + r = -EINVAL;
> + goto err;
> + }
> +
> + out->device->output = NULL;
> + out->device = NULL;
> +
> + mutex_unlock(&output_lock);
> +
> + return 0;
> +err:
> + mutex_unlock(&output_lock);
> +
> + return r;
> +}
>
> void dss_register_output(struct omap_dss_output *out)
> {
> + out->set_device = &dss_output_set_device;
> + out->unset_device = &dss_output_unset_device;
> +
> list_add_tail(&out->list, &output_list);
> }
I don't think there's need for this indirection. We should use function
pointers only when the func pointer may lead to different functions.
Here we'll always have just one function, dss_output_set_device. We can
as well call the function directly.
I know we have similar func pointers for ovls/mgrs currently, but I
don't think they are good either. They are a relic from the time we
supported "virtual" overlays and managers, and thus could have different
implementations for the operations.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 02/23] OMAPDSS: outputs: Create and register output instances
On Friday 31 August 2012 05:27 PM, Tomi Valkeinen wrote:
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
Add output structs to output driver's private data. Register output instances by
having an init function in the probes of the platform device drivers for
different outputs. The *_init_output for each output registers the output and
fill up the output's plaform device, type and id fields.
In the probe of each interface driver, the output entities are initialized
before the *_probe_pdata() functions intentionally. This is done to ensure that
the output entity is prepared before the panels connected to the output are
registered. We need the output entities to be ready because OMAPDSS will try
to make connections between overlays, managers, outputs and devices during the
panel's probe.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dpi.c | 15 +++
drivers/video/omap2/dss/dsi.c | 18 ++
drivers/video/omap2/dss/hdmi.c | 15 +++
drivers/video/omap2/dss/rfbi.c | 17 +
drivers/video/omap2/dss/sdi.c | 15 +++
drivers/video/omap2/dss/venc.c | 15 +++
6 files changed, 95 insertions(+)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 25fb895..9a7aee5 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -45,6 +45,8 @@ static struct {
struct omap_video_timings timings;
struct dss_lcd_mgr_config mgr_config;
int data_lines;
+
+ struct omap_dss_output output;
} dpi;
static struct platform_device *dpi_get_dsidev(enum omap_dss_clk_source clk)
@@ -410,10 +412,23 @@ static void __init dpi_probe_pdata(struct platform_device
*pdev)
}
}
+static void __init dpi_init_output(struct platform_device *pdev)
+{
+ struct omap_dss_output *out = &dpi.output;
+
+ dss_register_output(out);
+
+ out->pdev = pdev;
+ out->id = OMAP_DSS_OUTPUT_DPI;
+ out->type = OMAP_DISPLAY_TYPE_DPI;
+}
I think you should first initialize the output, and then register it.
Not the other way around.
Ok.
I believe you need to implement unregister also. Normally unregister
won't be done, but the probe of an output driver can fail after the
output has been registered, and thus the output needs to be unregistered
at cleanup.
Ah, right.
And it doesn't harm to unregister at the driver's remove.
I'll fix these, thanks.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/23] OMAPDSS: outputs: Create and register output instances
On Thu, 2012-08-30 at 17:10 +0530, Archit Taneja wrote:
> Add output structs to output driver's private data. Register output instances
> by
> having an init function in the probes of the platform device drivers for
> different outputs. The *_init_output for each output registers the output and
> fill up the output's plaform device, type and id fields.
>
> In the probe of each interface driver, the output entities are initialized
> before the *_probe_pdata() functions intentionally. This is done to ensure
> that
> the output entity is prepared before the panels connected to the output are
> registered. We need the output entities to be ready because OMAPDSS will try
> to make connections between overlays, managers, outputs and devices during the
> panel's probe.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/dpi.c | 15 +++
> drivers/video/omap2/dss/dsi.c | 18 ++
> drivers/video/omap2/dss/hdmi.c | 15 +++
> drivers/video/omap2/dss/rfbi.c | 17 +
> drivers/video/omap2/dss/sdi.c | 15 +++
> drivers/video/omap2/dss/venc.c | 15 +++
> 6 files changed, 95 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index 25fb895..9a7aee5 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -45,6 +45,8 @@ static struct {
> struct omap_video_timings timings;
> struct dss_lcd_mgr_config mgr_config;
> int data_lines;
> +
> + struct omap_dss_output output;
> } dpi;
>
> static struct platform_device *dpi_get_dsidev(enum omap_dss_clk_source clk)
> @@ -410,10 +412,23 @@ static void __init dpi_probe_pdata(struct
> platform_device *pdev)
> }
> }
>
> +static void __init dpi_init_output(struct platform_device *pdev)
> +{
> + struct omap_dss_output *out = &dpi.output;
> +
> + dss_register_output(out);
> +
> + out->pdev = pdev;
> + out->id = OMAP_DSS_OUTPUT_DPI;
> + out->type = OMAP_DISPLAY_TYPE_DPI;
> +}
I think you should first initialize the output, and then register it.
Not the other way around.
I believe you need to implement unregister also. Normally unregister
won't be done, but the probe of an output driver can fail after the
output has been registered, and thus the output needs to be unregistered
at cleanup.
And it doesn't harm to unregister at the driver's remove.
Tomi
signature.asc
Description: This is a digitally signed message part
[PATCH 0/2] fixes for omap2 nand driver
These two patches fixes the omap_nand_remove function to release all resources properly and be able to re-load the driver later on. Andreas Bießmann (2): mtd/nand/omap2: fix omap_nand_remove segfault mtd/nand/omap2: fix module loading drivers/mtd/nand/omap2.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mtd/nand/omap2: fix omap_nand_remove segfault
Do not kfree() the mtd_info, it is handled in the mtd subsystem and already freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in omap_nand_probe which was not kfree()ed before. This patch fixes following error when unloading the omap2 module: ---8<--- ~ $ rmmod omap2 [ cut here ] kernel BUG at mm/slab.c:3126! Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap2(-) CPU: 0Not tainted (3.6.0-rc3-00230-g155e36d-dirty #3) PC is at cache_free_debugcheck+0x2d4/0x36c LR is at kfree+0xc8/0x2ac pc : []lr : []psr: 200d0193 sp : c521fe08 ip : c0e8ef90 fp : c521fe5c r10: bf0001fc r9 : c521e000 r8 : c0d99c8c r7 : c661ebc0 r6 : c065d5a4 r5 : c65c4060 r4 : c78005c0 r3 : r2 : 1000 r1 : c65c4000 r0 : 0001 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 86694019 DAC: 0015 Process rmmod (pid: 549, stack limit = 0xc521e2f0) Stack: (0xc521fe08 to 0xc522) fe00: c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240 fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc fe40: c780ff40 a00d0113 c521e000 c521fe84 c521fe60 c0112efc c01122d8 fe60: c65c4860 c0673778 c06737ac 00070013 c521fe9c c521fe88 fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8 fec0: c02c8dd8 c02c8250 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8 fee0: c02c804c c02c8d20 bf001924 bf001ca8 c521e000 c521ff1c c521ff08 ff00: c02c950c c02c7fbc bf001d48 c521ff2c c521ff20 c02ca3a4 c02c94b8 ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930 ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 0081 60070010 ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88 ff80: c008e368 0001a004 70616d6f b6fe0032 0081 c0015028 c521ffa8 ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 0880 bec2ab38 0880 ffc0: 0001a004 70616d6f b6fe0032 0081 0319 b6fe1000 ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 Backtrace: [] (cache_free_debugcheck+0x0/0x36c) from [] (kfree+0xc8/0x2ac) [] (kfree+0x0/0x2ac) from [] (omap_nand_remove+0x5c/0x64 [omap2]) [] (omap_nand_remove+0x0/0x64 [omap2]) from [] (platform_drv_remove+0x28/0x2c) r5:bf001ca8 r4:c0673778 [] (platform_drv_remove+0x0/0x2c) from [] (__device_release_driver+0x80/0xdc) [] (__device_release_driver+0x0/0xdc) from [] (driver_detach+0xc4/0xc8) r5:bf001ca8 r4:c0673778 [] (driver_detach+0x0/0xc8) from [] (bus_remove_driver+0x9c/0x104) r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3: [] (bus_remove_driver+0x0/0x104) from [] (driver_unregister+0x60/0x80) r6:c521e000 r5:bf001ca8 r4: r3:bf001924 [] (driver_unregister+0x0/0x80) from [] (platform_driver_unregister+0x1c/0x20) r5: r4:bf001d48 [] (platform_driver_unregister+0x0/0x20) from [] (omap_nand_driver_exit+0x14/0x1c [omap2]) [] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [] (sys_delete_module+0x1f0/0x2ec) [] (sys_delete_module+0x0/0x2ec) from [] (ret_fast_syscall+0x0/0x48) r8:c0015028 r7:0081 r6:b6fe0032 r5:70616d6f r4:0001a004 Code: e1a5 eb0d9172 e7f001f2 e7f001f2 (e7f001f2) ---[ end trace 6a30b24d8c0cc2ee ]--- Segmentation fault --->8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann cc: linux-...@lists.infradead.org --- drivers/mtd/nand/omap2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index ac4fd75..4cd7ac0 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1387,7 +1387,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(&info->mtd); iounmap(info->nand.IO_ADDR_R); - kfree(&info->mtd); + kfree(info); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mtd/nand/omap2: fix module loading
Unloading the omap2 nand driver missed to release the memory region which will result in not being able to request it again if one want to load the driver later on. This patch fixes following error when loading omap2 module after unloading: ---8<--- ~ $ rmmod omap2 ~ $ modprobe omap2 [ 37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16 ~ $ --->8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann cc: linux-...@lists.infradead.org --- drivers/mtd/nand/omap2.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 4cd7ac0..48f1d4e 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1387,6 +1387,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(&info->mtd); iounmap(info->nand.IO_ADDR_R); + release_mem_region(info->phys_base, NAND_IO_SIZE); kfree(info); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mtd/nand/omap2: fix omap_nand_remove segfault
On Fri, 2012-08-31 at 13:35 +0200, Andreas Bießmann wrote: > Do not kfree() the mtd_info, it is handled in the mtd subsystem and already > freed by nand_release(). Instead kfree() the struct omap_nand_info allocated > in > omap_nand_probe which was not kfree()ed before. > > This patch fixes following error when unloading the omap2 module: Added "Cc: sta...@vger.kernel.org" to both patches and pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
On Thu, 2012-08-30 at 10:19 -0700, Tony Lindgren wrote: > Hi, > > * Tomi Valkeinen [120830 00:35]: > > On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: > > > > > > Good to see this, we need this badly to avoid blocking > > > single zImage effort on omaps. Can you also please take > > > > What is the issue with single zImage? How do cpu_is_ check affect it? > > The usage for that should only be limited to arch/arm/mach-omap2 > so we can make cpu.h local as we can't include mach and plat > header files from the drivers with single zImage. Ok. > > $ git grep -E " > drivers/video/omap/lcd_ams_delta.c:#include > > * Needs to be moved > > Yes, that should be either mach/board-ams-delta.h, or separate driver > specific headers in include/linux/platform_data. For omap1 we are not > planning common zImage support, so let's just make sure we're not > breaking anything there as people are still using it. Hmm, so did I understand right, for omap1 stuff we can still include from arch/arm/mach-omap1/include/mach? If so, that makes things easier. I can manage the omap2+ stuff fine, but I have no experience with omap1, nor do I have any omap1 devices. So I'd rather keep the omap1 code as it is, in fear that I'd just break it totally, and I'd rather spend my time on omap2+ code. > > drivers/video/omap2/dss/dss.c:#include > > * Uses cpu_is_* to find out the DSS version. dispc.c also uses cpu_is_* > > functions, but doesn't include plat/cpu.h. I know cpu_is_* checks should > > be removed, but is there some other file to include for the time being > > than plat/cpu.h? > > We could make it mach/cpu.h for omap1, but ideally we would just > pass DSS_VERSION_XYZ type flag in platform data on omap1. Ok. The omap1 fb driver seems to contain a few cpu_is_omap15xx() checks, nothing else. > > drivers/video/omap2/dss/dss_features.c:#include > > * Uses cpu_is_* to find out the DSS version > > Here too. Yep, for omap2+ I'll create a version ID that we'll pass via plat data. > > drivers/video/omap2/omapfb/omapfb-ioctl.c:#include > > drivers/video/omap2/omapfb/omapfb-ioctl.c:#include > > drivers/video/omap2/omapfb/omapfb-main.c:#include > > drivers/video/omap2/omapfb/omapfb-main.c:#include > > drivers/video/omap2/omapfb/omapfb-sysfs.c:#include > > drivers/video/omap2/vram.c:#include > > drivers/video/omap2/vram.c:#include > > drivers/video/omap2/vrfb.c:#include > > drivers/video/omap2/vrfb.c:#include > > > > Of these, I'm not sure how to handle. > > These should eventually be in platform_data as driver specific headers. > > > Grep shows that vram.c is only used by (the newer) omapfb, so it could > > be considered a part of that driver. It still needs to be built-in, as > > it needs to reserve memory early in the boot process (done with a call > > from arch/arm/plat-omap/common.c). > > Hmm it sounds like omap_vram_reserve_sdram_memblock() should be in > plat-omap and just pass the pointer for later use for vram.c. > > > Also board files can use a func call to define the amount of memory to > > allocate, but only rx51 seems to do this in the mainline. > > > > Anyway, I believe vram.c is going away when we start to use CMA. > > OK cool. > > > As for vrfb... I'm not really sure where it belongs. It is used by the > > newer omapfb and OMAP V4L2 driver. VRFB is a part of the OMAP's memory > > controller, so I'm not sure if it's really a normal driver. > > Maybe just split it to platform code for the memblock stuff and pass > the necessary information to the driver in platform_data? I'll try to figure out something for vrfb. Tomi signature.asc Description: This is a digitally signed message part
[PATCH v9 07/13] usb: musb: dsps: add dt support
From: Ajay Kumar Gupta
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 60 +---
2 files changed, 65 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be "ti,musb-am33xx"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+ represents PERIPHERAL.
+ - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
+ represents PERIPHERAL.
+ - power : Should be "250". This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 25e395b..2c104bf 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -46,6 +47,10 @@
#include "musb_core.h"
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -486,6 +491,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue->dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev->platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -552,14 +559,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue->musb[id] = musb;
- pdata->platform_ops = &dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, "failed to add resources\n");
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb platfrom data\n");
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb hdrc config\n");
+ goto err2;
+ }
+
+ of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+ sprintf(res_name, "port%d_mode", id);
+ of_property_read_u32(np, res_name, (u32 *)&pdata->mode);
+ of_property_read_u32(np, "power", (u32 *)&pdata->power);
+ config->multipoint = of_property_read_bool(np, "multipoint");
+
+ pdata->config = config;
+ }
+
+ pdata->platform_ops = &dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
@@ -591,14 +624,22 @@ static void __devexit dsps_delete_musb_pdev(struct
dsps_glue *glue, u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id->driver_data;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+ dev_err(&pdev->dev, "fail to get matching of_match struct\n");
+
[PATCH v9 13/13] usb: otg: nop: add dt support
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 10 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index b0caac3..e2702df 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -14,3 +14,6 @@ AM33XX MUSB GLUE
500mA when operating in host mode.
- usb0-phy : phandle for usb0 NOP PHY
- usb1-phy : phandle for usb1 NOP PHY
+
+NOP USB PHY
+ - compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 7e0dba3..fdbc285 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include
+#include
#include
#include
#include
@@ -194,12 +195,21 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = "nop-xceiv-usb" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = "nop_usb_xceiv",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 09/13] arm/dts: am33xx: add dt data for usb nop phy
From: Ajay Kumar Gupta
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bdde9c9..4b3a2b7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = "i2c3";
};
+ usb0_phy: phy0 {
+ compatible = "nop-xceiv-usb";
+ };
+
+ usb1_phy: phy1 {
+ compatible = "nop-xceiv-usb";
+ };
+
usb_otg_hs: usb_otg_hs {
compatible = "ti,musb-am33xx";
ti,hwmods = "usb_otg_hs";
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 12/13] arm/dts: am33xx: add phy phandle to usbss
From: Ajay Kumar Gupta Added NOP PHY phandle to usbss device node as same will be used to get the phy from otg framework. Signed-off-by: Ajay Kumar Gupta Signed-off-by: Santhapuri, Damodar Signed-off-by: Ravi Babu --- arch/arm/boot/dts/am33xx.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 4b3a2b7..1e77b0b 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -172,6 +172,8 @@ port0-mode = <3>; port1-mode = <3>; power = <250>; + usb0-phy = <&usb0_phy>; + usb1-phy = <&usb1_phy>; }; }; }; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
From: Santhapuri, Damodar
AM335x uses NOP transceiver driver and need to enable builtin PHY
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer untill a separate system control module driver is available.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
arch/arm/mach-omap2/board-ti8168evm.c |1 -
arch/arm/mach-omap2/omap_phy_internal.c | 35
arch/arm/plat-omap/include/plat/usb.h |5 +-
drivers/usb/musb/musb_dsps.c| 87 +--
4 files changed, 73 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index d4c8392..0c7c098 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -26,7 +26,6 @@
#include
static struct omap_musb_board_data musb_board_data = {
- .set_phy_power = ti81xx_musb_phy_power,
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..d80bb16 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -254,38 +254,3 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
-
-void ti81xx_musb_phy_power(u8 on)
-{
- void __iomem *scm_base = NULL;
- u32 usbphycfg;
-
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
- if (!scm_base) {
- pr_err("system control module ioremap failed\n");
- return;
- }
-
- usbphycfg = __raw_readl(scm_base + USBCTRL0);
-
- if (on) {
- if (cpu_is_ti816x()) {
- usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
- usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
- }
- } else {
- if (cpu_is_ti816x())
- usbphycfg &= ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
- usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
-
- }
- __raw_writel(usbphycfg, scm_base + USBCTRL0);
-
- iounmap(scm_base);
-}
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 548a4c8..c2aa4ae 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -95,7 +95,6 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
-extern void ti81xx_musb_phy_power(u8 on);
/* AM35x */
/* USB 2.0 PHY Control */
@@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on);
#define CONF2_DATPOL (1 << 1)
/* TI81XX specific definitions */
-#define USBCTRL0 0x620
-#define USBSTAT0 0x624
+#define MUSB_USBSS_REV_816X0x9
+#define MUSB_USBSS_REV_814X0xb
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 << 0)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 84d8181..960258d 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -116,9 +116,46 @@ struct dsps_glue {
struct platform_device *musb; /* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
+ u32 __iomem *usb_ctrl;
+ u8 usbss_rev;
};
/**
+ * musb_dsps_phy_control - phy on/off
+ * @glue: struct dsps_glue *
+ * @on: flag for phy to be switched on or off
+ *
+ * This is to enable the PHY using usb_ctrl register in system control
+ * module space.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+{
+ u32 usbphycfg;
+
+ usbphycfg = __raw_readl(glue->usb_ctrl);
+
+ if (on) {
+ if (glue->usbss_rev == MUSB_USBSS_REV_816X) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC;
+ } else if (glue->usbss_rev == MUSB_USBSS_REV_814X) {
+ usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
+ | USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
+
[PATCH v9 00/13] usb: musb: adding multi instance support
This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to felipe/master [1] branch + Vaibhav baseport patches on his tree at [4] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [2] + Damodar's recent patch at [3] + Ajay's & Damodar's patches at [5] and [6] included in this series 1. http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=summary 2. http://marc.info/?l=linux-usb&m=134070369306112&w=2 3. http://marc.info/?l=linux-usb&m=134200284230689&w=2 4. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 5. http://marc.info/?l=linux-usb&m=134200285530701&w=2 6. http://marc.info/?l=linux-usb&m=134208820028625&w=2 Changes from v8: - included Sergei's comment, removing underscore in device tree file - removed duplicated signoff from patches Changes from v7: - patches rebased on felipe/master branch & verified - included additional two patches 0001 & 0002 as part of this series which are already submitted [5] & [6] Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb->id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing "id" from phy struct and removing unneeded "#else" part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the "ti" string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] Ajay Kumar Gupta (7): usb: musb: dsps: enable phy control for am335x usb: musb: kill global and static for multi instance usb: musb: dsps: add dt support arm/dts: am33xx: Add dt data for usbss arm/dts: am33xx: add dt data for usb nop phy usb: musb: dsps: remove explicit NOP device creation arm/dts: am33xx: add phy phandle to usbss Ravi Babu (3): usb: musb: add musb_ida for multi instance support usb: musb: am335x: add support for dual instance usb: otg: nop: add dt support Santhapuri, Damodar (3): usb: musb: dsps: add phy control logic to glue usb: otg: nop: add support for multiple tranceiver usb: musb: dsps: get the PHY using phandle api .../devicetree/bindings/usb/am33xx-usb.txt | 19 ++ arch/arm/boot/dts/am33xx.dtsi | 21 ++ arch/arm/mach-omap2/board-ti8168evm.c |1 - arch/arm/mach-omap2/omap_phy_internal.c| 35 --- arch/arm/plat-omap/include/plat/usb.h |6 +- drivers/usb/musb/am35x.c | 44 ++- drivers/usb/musb/blackfin.c| 28 ++- drivers/usb/musb/da8xx.c | 36 ++- drivers/usb/musb/davinci.c | 38 ++- drivers/usb/musb/musb_core.c | 53 +++- drivers/usb/musb/musb_core.h |6 + drivers/usb/musb/musb_debugfs.c|8 +- drivers/usb/musb/musb_dsps.c | 281 +++- drivers/usb/musb/omap2430.c| 26 ++- drivers/usb/musb/tusb6010.c| 30 ++- drivers/usb/musb/ux500.c | 33 ++- drivers/usb/otg/nop-usb-xceiv.c| 64 - include/linux/usb/nop-usb-xceiv.h |4 +- 18 files changed, 523 insertions(+), 210 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt -- To unsubscribe from this list: send the line "unsubscribe 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 v9 06/13] usb: otg: nop: add support for multiple tranceiver
From: Santhapuri, Damodar
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
drivers/usb/musb/am35x.c |2 +-
drivers/usb/musb/blackfin.c |2 +-
drivers/usb/musb/da8xx.c |2 +-
drivers/usb/musb/davinci.c|4 +-
drivers/usb/musb/musb_dsps.c |8 +++---
drivers/usb/musb/tusb6010.c |4 +-
drivers/usb/otg/nop-usb-xceiv.c | 54 -
include/linux/usb/nop-usb-xceiv.h |4 +-
8 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 457f25e..e3099fc 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -399,7 +399,7 @@ static int am35x_musb_exit(struct musb *musb)
data->set_phy_power(0);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index e8cff9b..32b4fe4 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -427,7 +427,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb->config->gpio_vrsel);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index ce11d20..f86a1c7 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -451,7 +451,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 606bfd0..e12d20a 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -437,7 +437,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb->xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return -ENODEV;
}
@@ -485,7 +485,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f883c25..25e395b 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -413,7 +413,7 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb->mregs += wrp->musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
+ /* Register NOP driver */
usb_nop_xceiv_register();
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
@@ -447,7 +447,7 @@ static int dsps_musb_init(struct musb *musb)
return 0;
err0:
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return status;
}
@@ -462,9 +462,9 @@ static int dsps_musb_exit(struct musb *musb)
/* Shutdown the on-chip PHY and its PLL. */
musb_dsps_phy_control(glue, pdev->id, 0);
- /* NOP driver needs change if supporting dual instance */
+ /* Unregister NOP driver */
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index dc4d75e..71c4778 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1117,7 +1117,7 @@ done:
iounmap(sync);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
}
return ret;
}
@@ -1133,7 +1133,7 @@ static int tusb_musb_exit(struct musb *musb)
iounmap(musb->sync_va);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index e52e35e..7e0dba3 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -32,30 +32,69 @@
#include
#include
#include
+#include
struct nop_usb_xceiv {
struct usb_phy phy;
struct device *dev;
+ struct platform_device *pd;
};
-static struct platform_device *pd;
+static DEFINE_ID
[PATCH v9 03/13] usb: musb: add musb_ida for multi instance support
Added musb_ida in musb_core.c to manage the multi core ids.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 210 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 29b1d60..457f25e 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -459,6 +459,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -466,38 +467,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc("musb-hdrc", -1);
+ /* get the musb id */
+ musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
+ if (musbid < 0) {
+ dev_err(&pdev->dev, "failed to allocate musb id\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc("musb-hdrc", musbid);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err1;
+ goto err2;
}
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(&pdev->dev, "ick");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable PHY clock\n");
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
- goto err5;
+ goto err6;
}
+ musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask = &am35x_dmamask;
musb->dev.coherent_dma_mask = am35x_dmamask;
@@ -515,38 +525,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev->num_resources);
if (ret) {
dev_err(&pdev->dev, "failed to add resources\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(&pdev->dev, "failed to add platform_data\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(&pdev->dev, musbid);
+
err1:
kfree(glue);
@@ -558,6 +571,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
clk_disable(glue->clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 2a80dec..e8cff9b 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -455,6 +455,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -462,12 +463,21 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
goto err0;
[PATCH v9 05/13] usb: musb: am335x: add support for dual instance
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
drivers/usb/musb/musb_dsps.c | 112 +-
1 files changed, 66 insertions(+), 46 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 36130ba..f883c25 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -106,6 +106,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -113,16 +115,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -131,11 +135,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue->usb_ctrl);
+ usbphycfg = __raw_readl(glue->usb_ctrl[id]);
if (on) {
if (glue->usbss_rev == MUSB_USBSS_REV_816X) {
@@ -158,7 +162,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue->usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue->usb_ctrl);
+ __raw_writel(usbphycfg, glue->usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -207,8 +211,8 @@ static void otg_timer(unsigned long _musb)
struct musb *musb = (void *)_musb;
void __iomem *mregs = musb->mregs;
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
u8 devctl;
unsigned long flags;
@@ -244,7 +248,7 @@ static void otg_timer(unsigned long _musb)
case OTG_STATE_B_IDLE:
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE)
- mod_timer(&glue->timer,
+ mod_timer(&glue->timer[pdev->id],
jiffies + wrp->poll_seconds * HZ);
else
musb->xceiv->state = OTG_STATE_A_IDLE;
@@ -258,9 +262,8 @@ static void otg_timer(unsigned long _musb)
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
{
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
if (timeout == 0)
timeout = jiffies + msecs_to_jiffies(3);
@@ -270,22 +273,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb->xceiv->state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb->controller, "%s active, deleting timer\n",
otg_state_string(musb->xceiv->state));
- del_timer(&glue->timer);
- last_timer = jiffies;
+ del_timer(&glue->timer[pdev->id]);
+ glue->last_timer[pdev->id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) && timer_pending(&glue->timer)) {
+ if (time_after(glue->last_timer[pdev->id], timeout) &&
+ timer_pending(&glue->timer[pdev->id]))
[PATCH v9 10/13] usb: musb: dsps: remove explicit NOP device creation
From: Ajay Kumar Gupta As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta Signed-off-by: Santhapuri, Damodar Signed-off-by: Ravi Babu --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 32c8d68..eb6bfec 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -418,8 +418,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb->mregs += wrp->musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(); + /* Get the NOP PHY */ musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 04/13] usb: musb: kill global and static for multi instance
From: Ajay Kumar Gupta
Moved global variable "musb_debugfs_root" and static variable
"old_state" to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable "orig_dma_mask" and filled the
dev->dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
drivers/usb/musb/musb_core.c| 22 +++---
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c |8 +++-
3 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 7499fbb..44c8caa 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
@@ -1797,10 +1798,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb->xceiv->state != old_state) {
- old_state = musb->xceiv->state;
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ musb->xceiv_old_state = musb->xceiv->state;
sysfs_notify(&musb->controller->kobj, NULL, "mode");
}
}
@@ -2060,11 +2060,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -2083,10 +2078,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev->dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status < 0)
iounmap(base);
@@ -2096,7 +2087,8 @@ static int __devinit musb_probe(struct platform_device
*pdev)
static int __devexit musb_remove(struct platform_device *pdev)
{
- struct musb *musb = dev_to_musb(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb->ctrl_base;
/* this gets called on rmmod.
@@ -2109,9 +2101,9 @@ static int __devexit musb_remove(struct platform_device
*pdev)
musb_free(musb);
iounmap(ctrl_base);
- device_init_wakeup(&pdev->dev, 0);
+ device_init_wakeup(dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev->dev.dma_mask = orig_dma_mask;
+ dma_set_mask(dev, *dev->parent->dma_mask);
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a69ffd6..c158aac 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -437,6 +437,10 @@ struct musb {
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
#endif
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..1d6e8af 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s->private;
@@ -241,7 +239,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *file;
int ret;
- root = debugfs_create_dir("musb", NULL);
+ root = debugfs_create_dir(dev_name(musb->controller), NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
@@ -261,7 +259,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb->debugfs_root = root;
return 0;
@@ -274,5 +272,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb->debugfs_root);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 02/13] usb: musb: dsps: enable phy control for am335x
From: Ajay Kumar Gupta
Enabled the phy control logic for am335x also based on usbss
revision register.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/usb/musb/musb_dsps.c | 17 +++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index c2aa4ae..6459b10 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -121,6 +121,7 @@ extern void am35x_set_mode(u8 musb_mode);
/* TI81XX specific definitions */
#define MUSB_USBSS_REV_816X0x9
#define MUSB_USBSS_REV_814X0xb
+#define MUSB_USBSS_REV_33XX0xd
/* TI816X PHY controls bits */
#define TI816X_USBPHY0_NORMAL_MODE (1 << 0)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 960258d..e62fa05 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -141,16 +141,21 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
if (glue->usbss_rev == MUSB_USBSS_REV_816X) {
usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
usbphycfg &= ~TI816X_USBPHY_REFCLK_OSC;
- } else if (glue->usbss_rev == MUSB_USBSS_REV_814X) {
- usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
+ } else if (glue->usbss_rev == MUSB_USBSS_REV_814X ||
+ glue->usbss_rev == MUSB_USBSS_REV_33XX) {
+ usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
+ usbphycfg |= USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN;
+ if (glue->usbss_rev == MUSB_USBSS_REV_814X) {
+ usbphycfg &= ~(USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= USBPHY_DPOPBUFCTL
+ | USBPHY_DMOPBUFCTL;
+ }
}
} else {
if (glue->usbss_rev == MUSB_USBSS_REV_816X)
usbphycfg &= ~TI816X_USBPHY0_NORMAL_MODE;
- else if (glue->usbss_rev == MUSB_USBSS_REV_814X)
+ else if (glue->usbss_rev == MUSB_USBSS_REV_814X ||
+ glue->usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
__raw_writel(usbphycfg, glue->usb_ctrl);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 11/13] usb: musb: dsps: get the PHY using phandle api
From: Santhapuri, Damodar
AM33xx has two PHY of same type used by each musb controller so
use phandle of phy nodes to get the phy pointer.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
.../devicetree/bindings/usb/am33xx-usb.txt |2 ++
drivers/usb/musb/musb_dsps.c |5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..b0caac3 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,5 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+ - usb0-phy : phandle for usb0 NOP PHY
+ - usb1-phy : phandle for usb1 NOP PHY
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index eb6bfec..992cd50 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -409,9 +409,11 @@ static int dsps_musb_init(struct musb *musb)
{
struct device *dev = musb->controller;
struct platform_device *pdev = to_platform_device(dev);
+ struct platform_device *parent_pdev = to_platform_device(dev->parent);
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
void __iomem *reg_base = musb->ctrl_base;
+ char name[10];
u32 rev, val;
int status;
@@ -419,7 +421,8 @@ static int dsps_musb_init(struct musb *musb)
musb->mregs += wrp->musb_core_offset;
/* Get the NOP PHY */
- musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ sprintf(name, "usb%d-phy", pdev->id);
+ musb->xceiv = devm_usb_get_phy_by_phandle(&parent_pdev->dev, name);
if (IS_ERR_OR_NULL(musb->xceiv))
return -ENODEV;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 08/13] arm/dts: am33xx: Add dt data for usbss
From: Ajay Kumar Gupta
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
drivers/usb/musb/musb_dsps.c |6 +++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..bdde9c9 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = <0>;
ti,hwmods = "i2c3";
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = "ti,musb-am33xx";
+ ti,hwmods = "usb_otg_hs";
+ multipoint = <1>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ port0-mode = <3>;
+ port1-mode = <3>;
+ power = <250>;
+ };
};
};
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2c104bf..32c8d68 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -581,9 +581,9 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
goto err2;
}
- of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
- of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
- sprintf(res_name, "port%d_mode", id);
+ of_property_read_u32(np, "num-eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram-bits", (u32 *)&config->ram_bits);
+ sprintf(res_name, "port%d-mode", id);
of_property_read_u32(np, res_name, (u32 *)&pdata->mode);
of_property_read_u32(np, "power", (u32 *)&pdata->power);
config->multipoint = of_property_read_bool(np, "multipoint");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap-i2c: fix incorrect log message when using a device tree
When booting using a device tree, the adapter number is dynamically assigned after the log message is sent. This patch modifies the log message to get a correct adapter id. Applies on 3.6-rc3. Tested on OMAP3 (Gumstix Overo). Signed-off-by: Florian Vaussard --- drivers/i2c/busses/i2c-omap.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 5d19a49..136b4fe 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1064,9 +1064,6 @@ omap_i2c_probe(struct platform_device *pdev) goto err_unuse_clocks; } - dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", pdev->id, -dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); - adap = &dev->adapter; i2c_set_adapdata(adap, dev); adap->owner = THIS_MODULE; @@ -1084,6 +1081,9 @@ omap_i2c_probe(struct platform_device *pdev) goto err_free_irq; } + dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr, +dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); + of_i2c_register_devices(adap); pm_runtime_put(dev->dev); -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP HWMOD: Query regarding parent<->child support
On Fri, Aug 24, 2012 at 21:21:45, Hiremath, Vaibhav wrote:
> On Fri, Aug 17, 2012 at 18:00:54, Cousson, Benoit wrote:
> > Hi Vaibhav,
> >
> > On 08/17/2012 12:12 PM, Vaibhav Hiremath wrote:
> > >
> > >
> > > On 7/16/2012 7:41 PM, Vaibhav Hiremath wrote:
> > >> Hi All,
> > >>
> > >
> > > Paul,
> > >
> > > From last couple of days I am almost spending my whole time trying to
> > > get to somewhere on below issue and based on my understanding and
> > > learning so far I started feeling that, probably we might have made
> > > wrong decision to remove all leaf-nodes from the clock-tree. Instead we
> > > should have it removed from hwmod. :)
> > >
> > > Let's take a example of PWM Module (which is the context of my debugging)
> > > -
> > >
> > > As I mentioned before, PWM module present in AM33XX looks something like -
> > >
> > >
> > > --
> > >| |
> > >| | PWMSS | |
> > >| |
> > >| --- - |
> > >| | eCAP | | ePWM | | eQEP | |
> > >| --- - |
> > > --
> > >
> > > PWMSS: This actually controls all PM related signals like idle,
> > >standby, etc...
> > > eCAP/ePWM/eQEP: Technically it is independent module, reused from
> > > Davinci devices and is implemented as independent
> > > drivers in kernel.
> > >
> > > In case of AM33xx, the basic resources like, clock, idle signal and
> > > standby signal are abstracted at PWMSS level.
> > > This means the core IP (eCAP/ePWM/eQEP) have not changed from their
> > > original implementation.
> > >
> > > These core IP's (eCAP/ePWM/eQEP) are being used in Davinci family of
> > > devices, but without encapsulation of PWMSS, unlike AM33XX. This means,
> > > each module has its own clock enable/disable control mechanism and there
> > > is no dependency between them, unlike AM33XX.
> > >
> > > Options to support:
> > >
> > > 1. Use existing Clock Framework infrastructure to handle, which
> > > basically supports clock enable/disable function based on usecount and
> > > parent<->child relation. Driver will simply work, without knowing
> > > anything about underneath platform, which is what expected.
> > > So create a dummy-clocks for submodules, making PWMSS clock as a parent
> > > will solve the issue here.
> > >
> > > And nothing wrong here, we are just treating,
> > >clock-enable = module-enable
> >
> > Yeah, but that looks like a hack to me. That clock hierarchy does not
> > exist for real and the pm_runtime infrastructure can handle that
> > properly. In that case you do have a PM dependency and not necessarily a
> > clock dependency.
> >
>
> In one sense, yes.
>
> > > The only issue here is sysconf register access at hwmod level, if you
> > > leave sysconf idle and standby configuration at smart state, it works
> > > properly. I have validated it at my end.
> > >
> > > 2. MFD Driver: I think it will be miss-use of MFD driver and should be
> > > explored at all.
> >
> > I do think this is the proper use of MFD.
>
> Not certainly, as I said, here we are trying to solve some weird SoC
> integration dependency and will not work across devices, like Davinci.
>
> > In fact with DT, you don't
> > even need an MFD. The DT nodes hierarchy will create the parent-child
> > link automatically.
> >
> > pm_runtime events are taking care of the parent state. It means that if
> > you are enabling a child, the parent will be enabled first automatically
> > by the PM fmwk.
> >
>
> Fortunately before going on vacation last week I attempted this and found
> some issues -
>
> What I did was,
>
> ehrpwmss0: ehrpwmss0@4830 {
> compatible = "ti,ehrpwmss";
> ti,hwmods = "ehrpwmss0";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> ehrpwm0: ehrpwm@48300200 {
> compatible = "ti,ehrpwm";
> ti,hwmods = "ehrpwm0";
> #pwm-cells = <3>;
> has_configspace = <1>;
> };
>
> ecap0: ecap@48300100 {
> compatible = "ti,ecap";
> ti,hwmods = "ecap0";
> #pwm-cells = <3>;
> has_configspace = <1>;
> };
> };
>
> Above DT implementation created device nodes like,
>
> ehrpwmss0 (no Linux driver) ->
> -> ehrpwm0 (driver/pwm/ehrpwm.c)
> -> ecap0 (drivers/pwm/ecap.c)
>
> Please note that, we do not have any driver code available for parent
> device, as it is AM33XX specific and we don't want eCAP and eHRPWM drivers
> should know about it.
>
> The runtime_pm api's implementation is based on "disable_depth", and it
> works something lik
Re: [PATCHv3 0/4] Add device tree data for omap5
Hi Benoit, On Fri, Aug 31, 2012 at 3:02 PM, Benoit Cousson wrote: > Hi Sourav, > > While rebasing your series on top of Tony's lo/devel-dt, I realized that the > keypad nodes are not located at the correct place :-( > > At the moment they are just floating at the top level of the dts while they > belong to the ocp bus and thus should be put there. > My bad, never realised always used it at the top level. Sorry for the inconvenience. > I fixed that since it was trivial and cleaned as well the changelog and the > comments to aligned then properly. I added as well the physical address to > the node name and a label for easy reference at board level. > Thanks for fixing it up. > I did some basic test on my OMAP4 sdp, but that all I can do so far. > > Could you just check if this is still fine for OMAP5 before I ask Tony to > pull that. > I just booted the below mentioned branch and its booting fine on omap5. Did some keypad functionality test also and keypad seems to be working fine on omap5. > I based that on top of Tony's DT patches due to conflict with the existing > MMC patch in it. > > > > The following changes since commit 85d7ff9b907685b646905f1d961b3e8d47ad: > Olof Johansson (1): > ARM: omap: add dtb targets > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git > for_3.7/dts > > Sourav Poddar (6): > arm/dts: omap5-evm: Add I2C support > arm/dts: omap5-evm: Add tmp102 sensor support > arm/dts: omap5-evm: Add keypad data > arm/dts: omap5-evm: Add bmp085 sensor support > arm/dts: omap4-sdp: Add keypad data > Documentation: dt: i2c: trivial-devices: Update for tmp102 > > .../devicetree/bindings/i2c/trivial-devices.txt|1 + > arch/arm/boot/dts/omap4-sdp.dts| 70 > > arch/arm/boot/dts/omap4.dtsi |5 ++ > arch/arm/boot/dts/omap5-evm.dts| 33 + > arch/arm/boot/dts/omap5.dtsi | 40 +++ > 5 files changed, 149 insertions(+), 0 deletions(-) > > Regards, > Benoit > Thanks, Sourav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 08/13] arm/dts: am33xx: Add dt data for usbss
> On Thu, Aug 30, 2012 at 4:20 PM, Ravi Babu wrote: > > From: Ajay Kumar Gupta > > > > Added device tree data for usbss on am33xx. There are two musb > > controllers on am33xx platform so have port0_mode and > port1_mode additional data. > > > > Signed-off-by: Ajay Kumar Gupta > > Signed-off-by: Ravi Babu > > Signed-off-by: Santhapuri, Damodar > > Signed-off-by: Ravi Babu > > One Signed-off-by: Ravi Babu would suffice :-) Yes, by mistake, signoff got added two times. I will check and remove it from all patches if any. > > Thanks > Kishon > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/13] arm/dts: am33xx: Add dt data for usbss
Hi, On Thu, Aug 30, 2012 at 4:20 PM, Ravi Babu wrote: > From: Ajay Kumar Gupta > > Added device tree data for usbss on am33xx. There are two musb controllers > on am33xx platform so have port0_mode and port1_mode additional data. > > Signed-off-by: Ajay Kumar Gupta > Signed-off-by: Ravi Babu > Signed-off-by: Santhapuri, Damodar > Signed-off-by: Ravi Babu One Signed-off-by: Ravi Babu would suffice :-) Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 08/13] arm/dts: am33xx: Add dt data for usbss
> On Thu, Aug 30, 2012 at 03:39:40PM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 30-08-2012 14:50, Ravi Babu wrote:
> >
> > >From: Ajay Kumar Gupta
> >
> > >Added device tree data for usbss on am33xx. There are two musb
> > >controllers on am33xx platform so have port0_mode and
> port1_mode additional data.
> >
> > >Signed-off-by: Ajay Kumar Gupta
> > >Signed-off-by: Ravi Babu
> > >Signed-off-by: Santhapuri, Damodar
> > >Signed-off-by: Ravi Babu
> > >---
> > > arch/arm/boot/dts/am33xx.dtsi | 11 +++
> > > 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > >diff --git a/arch/arm/boot/dts/am33xx.dtsi
> > >b/arch/arm/boot/dts/am33xx.dtsi index 59509c4..778b95e 100644
> > >--- a/arch/arm/boot/dts/am33xx.dtsi
> > >+++ b/arch/arm/boot/dts/am33xx.dtsi
> > >@@ -154,5 +154,16 @@
> > > #size-cells = <0>;
> > > ti,hwmods = "i2c3";
> > > };
> > >+
> > >+ usb_otg_hs: usb_otg_hs {
> > >+ compatible = "ti,musb-am33xx";
> > >+ ti,hwmods = "usb_otg_hs";
> > >+ multipoint = <1>;
> > >+ num_eps = <16>;
> > >+ ram_bits = <12>;
> > >+ port0_mode = <3>;
> > >+ port1_mode = <3>;
> >
> >Hyphen is preferred traditionally to underscore in the
> device tree files...
>
> Are we having a v2 of this patch ??
Felipe, I will send it shortly.
Regards
Ravi B
>
> --
> balbi
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/13] arm/dts: am33xx: Add dt data for usbss
Hi,
On Thu, Aug 30, 2012 at 03:39:40PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 30-08-2012 14:50, Ravi Babu wrote:
>
> >From: Ajay Kumar Gupta
>
> >Added device tree data for usbss on am33xx. There are two musb controllers
> >on am33xx platform so have port0_mode and port1_mode additional data.
>
> >Signed-off-by: Ajay Kumar Gupta
> >Signed-off-by: Ravi Babu
> >Signed-off-by: Santhapuri, Damodar
> >Signed-off-by: Ravi Babu
> >---
> > arch/arm/boot/dts/am33xx.dtsi | 11 +++
> > 1 files changed, 11 insertions(+), 0 deletions(-)
>
> >diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> >index 59509c4..778b95e 100644
> >--- a/arch/arm/boot/dts/am33xx.dtsi
> >+++ b/arch/arm/boot/dts/am33xx.dtsi
> >@@ -154,5 +154,16 @@
> > #size-cells = <0>;
> > ti,hwmods = "i2c3";
> > };
> >+
> >+usb_otg_hs: usb_otg_hs {
> >+compatible = "ti,musb-am33xx";
> >+ti,hwmods = "usb_otg_hs";
> >+multipoint = <1>;
> >+num_eps = <16>;
> >+ram_bits = <12>;
> >+port0_mode = <3>;
> >+port1_mode = <3>;
>
>Hyphen is preferred traditionally to underscore in the device tree files...
Are we having a v2 of this patch ??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] i2c-omap: Fix incorrect adapter id when booting from a device tree
Hi Benoit,
[0.658843] omap_i2c i2c.15: bus -1 rev2.4.0 at 400 kHz
[0.760192] omap_i2c i2c.16: bus -1 rev2.4.0 at 400 kHz
[0.775817] omap_i2c i2c.17: bus -1 rev2.4.0 at 400 kHz
[0.791442] omap_i2c i2c.18: bus -1 rev2.4.0 at 400 kHz
OK, it is true that the current log is not that nice with bus -1, but
maybe we should just remove that.
Or we can potentially retrieve the i2c adapter number assign later, and
delay the log.
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev->dev, "failure adding adapter\n");
I agree, we should defer the log if we want a nice print. I will send a
new patch.
Regards,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP2+: AM33XX: Add clock entries to omap_clk data
Add AM335x cpu0 clock entry to the corresponding clock data
file. This is useful in getting the correct mpu clock pointer
to change the cpu frequency in cpufreq driver.
Signed-off-by: AnilKumar Ch
---
arch/arm/mach-omap2/clock33xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 23251fa..7afefe8 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1013,6 +1013,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, "dpll_core_m5_ck", &dpll_core_m5_ck,
CK_AM33XX),
CLK(NULL, "dpll_core_m6_ck", &dpll_core_m6_ck,
CK_AM33XX),
CLK(NULL, "dpll_mpu_ck", &dpll_mpu_ck, CK_AM33XX),
+ CLK("cpu0", NULL, &dpll_mpu_ck,
CK_AM33XX),
CLK(NULL, "dpll_mpu_m2_ck", &dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL, "dpll_ddr_ck", &dpll_ddr_ck, CK_AM33XX),
CLK(NULL, "dpll_ddr_m2_ck", &dpll_ddr_m2_ck,
CK_AM33XX),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: OMAP2: AM33XX: Add cpufreq support
Add cpufreq support to AM33XX family of devices by adding OPP information, clock entry with cpu0 name and voltage supplies to cpu0. These patches have been tested on AM335x-EVM, AM335x-Bone and these patches are based on cpufreq-cpu0 driver http://marc.info/?l=linux-arm-kernel&m=134457735413293&w=2 AnilKumar Ch (2): ARM: OMAP2+: AM33XX: Add clock entries to omap_clk data arm/dts: AM33XX: Add device tree OPP table arch/arm/boot/dts/am335x-bone.dts|6 ++ arch/arm/boot/dts/am335x-evm.dts |6 ++ arch/arm/boot/dts/am33xx.dtsi| 15 +++ arch/arm/mach-omap2/clock33xx_data.c |1 + 4 files changed, 28 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm/dts: AM33XX: Add device tree OPP table
Add DT OPP table for AM33XX family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
Also adds cpu0 supply name to the corresponding dts files.
cpu0-supply name is used by cpufreq-cpu0 driver to get the
regulator pointer for voltage modifications.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am335x-evm.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi | 15 +++
3 files changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index ce486fc..2767b5f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -13,6 +13,12 @@
model = "TI AM335x BeagleBone";
compatible = "ti,am335x-bone", "ti,am33xx";
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&dcdc2_reg>;
+ };
+ };
+
memory {
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index baa3276..54d972c 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -13,6 +13,12 @@
model = "TI AM335x EVM";
compatible = "ti,am335x-evm", "ti,am33xx";
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vdd1_reg>;
+ };
+ };
+
memory {
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ab744d6..2043b53 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -25,6 +25,21 @@
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
+
+ /*
+* To consider voltage drop between PMIC and SoC,
+* tolerance value is reduced to 2% from 4% and
+* voltage value is increased as a precaution.
+*/
+ operating-points = <
+ /* kHzuV */
+ 72 1285000
+ 60 1225000
+ 50 1125000
+ 275000 1125000
+ >;
+ voltage-tolerance = <2>; /* 2 percentage */
+ clock-latency = <30>; /* From omap-cpufreq driver */
};
};
--
1.7.9.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: [PATCHv3 0/4] Add device tree data for omap5
Hi Sourav, While rebasing your series on top of Tony's lo/devel-dt, I realized that the keypad nodes are not located at the correct place :-( At the moment they are just floating at the top level of the dts while they belong to the ocp bus and thus should be put there. I fixed that since it was trivial and cleaned as well the changelog and the comments to aligned then properly. I added as well the physical address to the node name and a label for easy reference at board level. I did some basic test on my OMAP4 sdp, but that all I can do so far. Could you just check if this is still fine for OMAP5 before I ask Tony to pull that. I based that on top of Tony's DT patches due to conflict with the existing MMC patch in it. The following changes since commit 85d7ff9b907685b646905f1d961b3e8d47ad: Olof Johansson (1): ARM: omap: add dtb targets are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.7/dts Sourav Poddar (6): arm/dts: omap5-evm: Add I2C support arm/dts: omap5-evm: Add tmp102 sensor support arm/dts: omap5-evm: Add keypad data arm/dts: omap5-evm: Add bmp085 sensor support arm/dts: omap4-sdp: Add keypad data Documentation: dt: i2c: trivial-devices: Update for tmp102 .../devicetree/bindings/i2c/trivial-devices.txt|1 + arch/arm/boot/dts/omap4-sdp.dts| 70 arch/arm/boot/dts/omap4.dtsi |5 ++ arch/arm/boot/dts/omap5-evm.dts| 33 + arch/arm/boot/dts/omap5.dtsi | 40 +++ 5 files changed, 149 insertions(+), 0 deletions(-) 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
[PATCH 4/5] leds: leds-gpio: adopt pinctrl support
Adopt pinctrl support to leds-gpio driver, based on the device
pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
mode.
Signed-off-by: AnilKumar Ch
---
drivers/leds/leds-gpio.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index c032b21..d98dfb9 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
struct gpio_led_data {
struct led_classdev cdev;
@@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct
platform_device *pdev)
{
struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
struct gpio_leds_priv *priv;
- int i, ret = 0;
+ struct pinctrl *pinctrl;
+ int i = 0;
+ int ret = 0;
+
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ return PTR_ERR(pinctrl);
+ }
if (pdata && pdata->num_leds) {
priv = devm_kzalloc(&pdev->dev,
sizeof_gpio_leds_priv(pdata->num_leds),
GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
+ if (!priv) {
+ ret = -ENOMEM;
+ goto err_pctrl_put;
+ }
priv->num_leds = pdata->num_leds;
for (i = 0; i < priv->num_leds; i++) {
@@ -254,18 +264,25 @@ static int __devinit gpio_led_probe(struct
platform_device *pdev)
/* On failure: unwind the led creations */
for (i = i - 1; i >= 0; i--)
delete_gpio_led(&priv->leds[i]);
- return ret;
+ goto err_pctrl_put;
}
}
} else {
priv = gpio_leds_create_of(pdev);
- if (!priv)
- return -ENODEV;
+ if (!priv) {
+ ret = -ENODEV;
+ goto err_del_gpio_led;
+ }
}
platform_set_drvdata(pdev, priv);
- return 0;
+err_pctrl_put:
+ pinctrl_put(pinctrl);
+err_del_gpio_led:
+ while (--i >= 0)
+ delete_gpio_led(&priv->leds[i]);
+ return ret;
}
static int __devexit gpio_led_remove(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] of: Modify c_can binding documentation
Modify c_can binding documentation according to recent review comments
on device tree data addition patches.
Signed-off-by: AnilKumar Ch
---
.../devicetree/bindings/net/can/c_can.txt | 25
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index a43f083..90a70be 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -8,6 +8,8 @@ Required properties:
registers map
- interrupts : property with a value describing the interrupt
number
+- status : describes the node status either "disabled" or
+ "okay"
Optional properties:
- interrupt-parent : The parent interrupt controller
@@ -20,18 +22,31 @@ Future plan is to migrate hwmod data base contents into
device tree
blob so that, all the required data will be used from device tree dts
file.
-Examples:
+Example:
- d_can@481D {
+Step1: SoC common .dtsi file
+
+ d_can1: d_can@481d {
compatible = "bosch,d_can";
- reg = <0x481D 0x1000>;
- interrupts = <55 0x4>;
+ reg = <0x481d 0x2000>;
+ interrupts = <55>;
interrupt-parent = <&intc>;
+ status = "disabled";
};
(or)
- d_can@481D {
+ d_can1: d_can@481d {
compatible = "bosch,d_can";
ti,hwmods = "d_can1";
+ reg = <0x481d 0x2000>;
+ interrupts = <55>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
+
+Step 2: board specific .dts file
+
+ &dcan1 {
+ status = "okay";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/5] Add device tree data for AM33XX devices
Add pinctrl and d_can device tree data to AM33XX family of devices. First two patches add support for pinctrl DT data and third one adds dcan DT data. Reason behind combining these patches is to apply cleanly on linux-omap tree, because these are sequential patches. These patches were tested on AM335x-Bone, AM335x-EVM and based on linux-omap:master with this patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74393.html d_can: Changes from v4: - Incorporated Tony's comments on v4 * Converted all hex numbers to lower-case. - Updated C_CAN bindings documentation according to recent changes. Changes from v3: - Removed d_can1 node from am335x-evm.dts file. Instance one of CAN (d_can1) is available on AM335x-EVM only under a specific CPLD mode selection. am335x-evm.dts does not support this mode so remove the d_can1 node. - Dropped d_can pinmux settings patch, above comment applies here as well. Changes from v2: - Incorporated Vaibhav H's comments on v2 * Added dcan0 instances to am33xx.dtsi file Changes from v1: - These two patches separated from c_can DT support patch series. pinctrl: Changes from v4: - Incorporated Tony's comments on v4 * Converted all hex numbers to lower-case. - Added pinctrl api to leds-gpio driver to configure led pins to GPIO mode. Changes from v3: - Updated the reg length based on latest AM335x TRM. Changes from v2: - user led pinmux comments updated according to Tony's comment. Changes from v1: - Rebased the patches based on latest pinctrl-single driver AnilKumar Ch (5): arm/dts: AM33XX: Add basic pinctrl device tree data arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone arm/dts: AM33XX: Add D_CAN device tree data leds: leds-gpio: adopt pinctrl support of: Modify c_can binding documentation .../devicetree/bindings/net/can/c_can.txt | 25 +--- arch/arm/boot/dts/am335x-bone.dts | 41 arch/arm/boot/dts/am33xx.dtsi | 27 + drivers/leds/leds-gpio.c | 31 +++ 4 files changed, 112 insertions(+), 12 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/5] arm/dts: AM33XX: Add basic pinctrl device tree data
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am33xx.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index be43511..bf5f713 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = "pinctrl-single";
+ reg = <0x44e10800 0x0238>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x7f>;
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/5] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..ce486fc 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,11 +18,52 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ userled_pins: pinmux_userled_pins {
+ pinctrl-single,pins = <
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
+ 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = "okay";
};
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&userled_pins>;
+
+ led0 {
+ label = "status:green:user0";
+ gpios = <&gpio2 21 0>;
+ default-state = "off";
+ };
+
+ led1 {
+ label = "status:green:user1";
+ gpios = <&gpio2 22 0>;
+ default-state = "off";
+ };
+
+ led2 {
+ label = "status:green:user2";
+ gpios = <&gpio2 23 0>;
+ default-state = "off";
+ };
+
+ led3 {
+ label = "status:green:user3";
+ gpios = <&gpio2 24 0>;
+ default-state = "off";
+ };
+ };
+
i2c1: i2c@44e0b000 {
status = "okay";
clock-frequency = <40>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/5] arm/dts: AM33XX: Add D_CAN device tree data
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am33xx.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bf5f713..ab744d6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -177,5 +177,23 @@
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};
+
+ dcan0: d_can@481cc000 {
+ compatible = "bosch,d_can";
+ ti,hwmods = "d_can0";
+ reg = <0x481cc000 0x2000>;
+ interrupts = <52>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
+
+ dcan1: d_can@481d {
+ compatible = "bosch,d_can";
+ ti,hwmods = "d_can1";
+ reg = <0x481d 0x2000>;
+ interrupts = <55>;
+ interrupt-parent = <&intc>;
+ status = "disabled";
+ };
};
};
--
1.7.9.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: [PATCH 1/2] i2c-omap: Fix incorrect adapter id when booting from a device tree
Hi Florian,
On 08/31/2012 09:52 AM, Florian Vaussard wrote:
> When booting from a device tree, the omap driver is using pdev->id,
> which is incorrect.
Not really, see below...
> The proposed patch uses aliases, as done in omap-serial.
Mmm, but is it really needed?
In the case of serial the id is important because of the tty number used
as device interface.
In the case of I2C, the id is mostly irrelevant.
In fact, using the pdev->id = -1 was used on purpose to have a dynamic
assignment:
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
...
if (adap->nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
> Signed-off-by: Florian Vaussard
> ---
> drivers/i2c/busses/i2c-omap.c | 19 +++
> 1 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 5d19a49..9445d1f 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1064,9 +1064,6 @@ omap_i2c_probe(struct platform_device *pdev)
> goto err_unuse_clocks;
> }
>
> - dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", pdev->id,
> - dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
> -
[0.658843] omap_i2c i2c.15: bus -1 rev2.4.0 at 400 kHz
[0.760192] omap_i2c i2c.16: bus -1 rev2.4.0 at 400 kHz
[0.775817] omap_i2c i2c.17: bus -1 rev2.4.0 at 400 kHz
[0.791442] omap_i2c i2c.18: bus -1 rev2.4.0 at 400 kHz
OK, it is true that the current log is not that nice with bus -1, but
maybe we should just remove that.
Or we can potentially retrieve the i2c adapter number assign later, and
delay the log.
> r = i2c_add_numbered_adapter(adap);
> if (r) {
> dev_err(dev->dev, "failure adding adapter\n");
Regards,
Benoit
> adap = &dev->adapter;
> i2c_set_adapdata(adap, dev);
> adap->owner = THIS_MODULE;
> @@ -1076,8 +1073,22 @@ omap_i2c_probe(struct platform_device *pdev)
> adap->dev.parent = &pdev->dev;
> adap->dev.of_node = pdev->dev.of_node;
>
> + if (adap->dev.of_node)
> + adap->nr = of_alias_get_id(adap->dev.of_node, "i2c");
> + else
> + adap->nr = pdev->id;
> +
> + if (adap->nr < 0) {
> + dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
> + adap->nr);
> + r = -ENODEV;
> + goto err_free_irq;
> + }
> +
> + dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
> + dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
> +
> /* i2c device drivers may be active on return from add_adapter() */
> - adap->nr = pdev->id;
> r = i2c_add_numbered_adapter(adap);
> if (r) {
> dev_err(dev->dev, "failure adding adapter\n");
>
--
To unsubscribe from this list: send the line "unsubscribe 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] ARM: OMAP2/3: DSS HWMOD fixes
On Wed, 2012-07-04 at 06:11 -0600, Paul Walmsley wrote: > Hi Tomi > > On Wed, 27 Jun 2012, Paul Walmsley wrote: > > > On Thu, 10 May 2012, Tomi Valkeinen wrote: > > > > > These patches fix DSS hwmod data related to sysc flags. I haven't seen any > > > problem produced by these missing bits, but by looking at the TRM it's > > > clear > > > that they should be defined. > > > > > > However, applying these will cause additional warnings to show during > > > boot: > > > > > > omap_hwmod: dss_dispc: softreset failed (waited 1 usec) > > > omap_hwmod: dss_rfbi: softreset failed (waited 1 usec) > > > > > > Most likely the softreset fails even now, but as there's no check to > > > verify it, > > > no warnings are visible. > > > > > > I think the reason for the failing softreset is the same problem as we > > > have on > > > OMAP4: dss_core hwmod should be enabled before other dss hwmods can be > > > enabled > > > (and reset). > > > > Thanks, queued for 3.6. > > > > Not sure what to do about the softreset issues at the moment, due to > > competing priorities. But for sure the data should match the hardware. > > I've dropped these for 3.6 since they cause a PM regression during a > system suspend test: > > [ 39.721282] Powerdomain (dss_pwrdm) didn't enter target state 1 > > Probably before we can pull these in, we need to figure out what's going > on there. Just tested with current mainline (155e36d40cf31c17f2b629fc2f2f5527e4cfc324) on omap3 overo, with DSS, USB, MMC disabled in the kernel config: # echo mem > /sys/power/state [ 14.140472] PM: Syncing filesystems ... done. [ 14.154205] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 14.184173] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 14.234283] PM: suspend of devices complete after 13.977 msecs [ 14.244567] PM: late suspend of devices complete after 4.028 msecs [ 14.257110] PM: noirq suspend of devices complete after 6.011 msecs [ 14.263885] Disabling non-boot CPUs ... [ 15.986541] Powerdomain (iva2_pwrdm) didn't enter target state 1 [ 15.992858] Powerdomain (dss_pwrdm) didn't enter target state 1 [ 15.999084] Powerdomain (per_pwrdm) didn't enter target state 1 [ 16.005310] Powerdomain (core_pwrdm) didn't enter target state 1 [ 16.011627] Powerdomain (usbhost_pwrdm) didn't enter target state 1 [ 16.018188] Could not enter target state in pm_suspend [ 16.026580] PM: noirq resume of devices complete after 2.807 msecs [ 16.037597] PM: early resume of devices complete after 2.655 msecs [ 16.054870] PM: resume of devices complete after 10.620 msecs [ 16.065643] Restarting tasks ... done. So things don't look correct even without my patches. Does the suspend work for you? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote: On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote: On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote: On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote: The only little problem was that during bootup, when hwmods are setup, only the 'parent' hwmod was able to get reset properly, all the other 'child' hwmods don't have modulemode bits tied to them, and hence weren't able to reset. So we got some error prints. Once DSS driver kicks in, the driver ensures the parent is enabled for any child to be enabled, so we don't face the issue again. So, if DSS driver is not built in, and if the bootloader left DSS in a bad state, the DSS clocks might remain messed up all the time since hwmod fwk wasn't able to reset them. I think this is why we didn't proceed with remove "dss_fck" as a slave clock. If this issue is minor, we could go ahead and remove it. I wonder if we could handle this with a custom reset function. We already have a reset func for dss core. If I remember right, the main point for that is the fact that omap4 doesn't have a softreset for dss core, so we manually write the default values to registers. For omap2/3 this would be simple: skip the resets for all other dss submodules, and dss core's reset would enable all the clocks and set the softreset bit. This would reset all the submodules also. Omap4 is more tricky. I guess we'd need to enable all the clocks, clear manually dss core's registers, and then set softreset bits in all the submodules. So in this case dss core would need to have information about the other submodules. The is a good idea. I don't clearly understand your approach though. Are you saying we have a custom reset function for only dss core? And reset the submodules in it manually? Yes. An alternative approach would be to implement custom reset functions for each submodule(or each hwmod), and in the beginning of every reset function, add a hack to enable MODULEMODE bits(since we don't want hwmod fwk to touch MODULEMODE for the DSS submodules), and then set the soft reset bits. I thought about that also. We'd need reset functions for all of them, and for omap2/3 we'd just reset the submodules again as they have already been reset with the dss core reset. The dss submodule resets are a bit linked. For omap2/3 the connection is obvious as dss core reset resets also the submodules, and for omap4 we have this requirement for the modulemode. That's why I though it'd be perhaps cleaner to handle the reset of the DSS block as a whole, in one place. Your approach would ensure that we get a clean reset of DSS, but it would still give the annoying prints when each of the submodule tries to reset itself. The other submodules would not be reset by the hwmod framework at all, so there wouldn't be prints. I think there's a flag for that. Oh, yeah. I didn't think of it that way, we could just 'not reset' the DSS submodule hwmod using this flag. If we do that, then your approach sounds good. Archit -- To unsubscribe from this list: send the line "unsubscribe 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 v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote: > On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote: > > On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote: > > > >> The only little problem was that during bootup, when hwmods are setup, > >> only the 'parent' hwmod was able to get reset properly, all the other > >> 'child' hwmods don't have modulemode bits tied to them, and hence > >> weren't able to reset. So we got some error prints. > >> > >> Once DSS driver kicks in, the driver ensures the parent is enabled for > >> any child to be enabled, so we don't face the issue again. > >> > >> So, if DSS driver is not built in, and if the bootloader left DSS in a > >> bad state, the DSS clocks might remain messed up all the time since > >> hwmod fwk wasn't able to reset them. > >> > >> I think this is why we didn't proceed with remove "dss_fck" as a slave > >> clock. If this issue is minor, we could go ahead and remove it. > > > > I wonder if we could handle this with a custom reset function. We > > already have a reset func for dss core. If I remember right, the main > > point for that is the fact that omap4 doesn't have a softreset for dss > > core, so we manually write the default values to registers. > > > > For omap2/3 this would be simple: skip the resets for all other dss > > submodules, and dss core's reset would enable all the clocks and set the > > softreset bit. This would reset all the submodules also. > > > > Omap4 is more tricky. I guess we'd need to enable all the clocks, clear > > manually dss core's registers, and then set softreset bits in all the > > submodules. So in this case dss core would need to have information > > about the other submodules. > > The is a good idea. I don't clearly understand your approach though. Are > you saying we have a custom reset function for only dss core? And reset > the submodules in it manually? Yes. > An alternative approach would be to implement custom reset functions for > each submodule(or each hwmod), and in the beginning of every reset > function, add a hack to enable MODULEMODE bits(since we don't want hwmod > fwk to touch MODULEMODE for the DSS submodules), and then set the soft > reset bits. I thought about that also. We'd need reset functions for all of them, and for omap2/3 we'd just reset the submodules again as they have already been reset with the dss core reset. The dss submodule resets are a bit linked. For omap2/3 the connection is obvious as dss core reset resets also the submodules, and for omap4 we have this requirement for the modulemode. That's why I though it'd be perhaps cleaner to handle the reset of the DSS block as a whole, in one place. > Your approach would ensure that we get a clean reset of DSS, but it > would still give the annoying prints when each of the submodule tries to > reset itself. The other submodules would not be reset by the hwmod framework at all, so there wouldn't be prints. I think there's a flag for that. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote: On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote: The only little problem was that during bootup, when hwmods are setup, only the 'parent' hwmod was able to get reset properly, all the other 'child' hwmods don't have modulemode bits tied to them, and hence weren't able to reset. So we got some error prints. Once DSS driver kicks in, the driver ensures the parent is enabled for any child to be enabled, so we don't face the issue again. So, if DSS driver is not built in, and if the bootloader left DSS in a bad state, the DSS clocks might remain messed up all the time since hwmod fwk wasn't able to reset them. I think this is why we didn't proceed with remove "dss_fck" as a slave clock. If this issue is minor, we could go ahead and remove it. I wonder if we could handle this with a custom reset function. We already have a reset func for dss core. If I remember right, the main point for that is the fact that omap4 doesn't have a softreset for dss core, so we manually write the default values to registers. For omap2/3 this would be simple: skip the resets for all other dss submodules, and dss core's reset would enable all the clocks and set the softreset bit. This would reset all the submodules also. Omap4 is more tricky. I guess we'd need to enable all the clocks, clear manually dss core's registers, and then set softreset bits in all the submodules. So in this case dss core would need to have information about the other submodules. The is a good idea. I don't clearly understand your approach though. Are you saying we have a custom reset function for only dss core? And reset the submodules in it manually? An alternative approach would be to implement custom reset functions for each submodule(or each hwmod), and in the beginning of every reset function, add a hack to enable MODULEMODE bits(since we don't want hwmod fwk to touch MODULEMODE for the DSS submodules), and then set the soft reset bits. Your approach would ensure that we get a clean reset of DSS, but it would still give the annoying prints when each of the submodule tries to reset itself. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm/dts: Add i2c aliases for OMAP3 and OMAP4/AM33xx
I2C aliases need to be set, for the omap-i2c driver to get a correct adapter id.
Signed-off-by: Florian Vaussard
---
arch/arm/boot/dts/am33xx.dtsi |3 +++
arch/arm/boot/dts/omap3.dtsi |3 +++
arch/arm/boot/dts/omap4.dtsi |4
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..ff2d879 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -20,6 +20,9 @@
serial3 = &uart4;
serial4 = &uart5;
serial5 = &uart6;
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ i2c2 = &i2c3;
};
cpus {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..a7d2f83 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -18,6 +18,9 @@
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ i2c2 = &i2c3;
};
cpus {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..496c7ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,10 @@
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ i2c2 = &i2c3;
+ i2c3 = &i2c4;
};
cpus {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] i2c-omap: Fix incorrect adapter id when booting from a device tree
When booting from a device tree, the omap driver is using pdev->id,
which is incorrect. The proposed patch uses aliases, as done in
omap-serial.
Signed-off-by: Florian Vaussard
---
drivers/i2c/busses/i2c-omap.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5d19a49..9445d1f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1064,9 +1064,6 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_unuse_clocks;
}
- dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", pdev->id,
-dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
-
adap = &dev->adapter;
i2c_set_adapdata(adap, dev);
adap->owner = THIS_MODULE;
@@ -1076,8 +1073,22 @@ omap_i2c_probe(struct platform_device *pdev)
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
+ if (adap->dev.of_node)
+ adap->nr = of_alias_get_id(adap->dev.of_node, "i2c");
+ else
+ adap->nr = pdev->id;
+
+ if (adap->nr < 0) {
+ dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
+ adap->nr);
+ r = -ENODEV;
+ goto err_free_irq;
+ }
+
+ dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
+dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
+
/* i2c device drivers may be active on return from add_adapter() */
- adap->nr = pdev->id;
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev->dev, "failure adding adapter\n");
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] dts for i2c-omap: fix incorrect adapter id
Hello, This patchset fixes the i2c adapter id on OMAP3 and OMAP4/AM33xx when booting from a device tree. Currently, pdev->id is used, regardless of the boot method. The first patch checks for of_node, and get the id from the alias if a device tree is found. The boot message is updated accordingly. The second patch add the necessary aliases for OMAP3, OMAP4 and AM33xx. This patchset applies on 3.6-rc3 and has been tested on OMAP3 (Gumstix Overo). Regards, Florian Florian Vaussard (2): i2c-omap: Fix incorrect adapter id when booting from a device tree arm/dts: Add i2c aliases for OMAP3 and OMAP4/AM33xx arch/arm/boot/dts/am33xx.dtsi |3 +++ arch/arm/boot/dts/omap3.dtsi |3 +++ arch/arm/boot/dts/omap4.dtsi |4 drivers/i2c/busses/i2c-omap.c | 19 +++ 4 files changed, 25 insertions(+), 4 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
