RE: [PATCH] ARM: OMAP2: reboot: Include common.h to fix build error
Hi,
On Wed, Jun 19, 2013 at 23:16:41, Axel Lin wrote:
Include common.h which will include linux/reboot.h to fix below build error.
CC arch/arm/mach-omap2/omap4-restart.o
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: 'enum reboot_mode'
declared inside parameter list [enabled by default]
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 ('mode') has
incomplete type
arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration isn't
a prototype [-Wstrict-prototypes]
make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Axel Lin axel@ingics.com
---
Seems this build error is introduced by commit 7507d035f3cf40c
reboot: arm: change reboot_mode to use enum reboot_mode
This patch is against linux-next 20130619.
diff --git a/arch/arm/mach-omap2/omap4-restart.c
b/arch/arm/mach-omap2/omap4-restart.c
index 652adde..7306d9b 100644
--- a/arch/arm/mach-omap2/omap4-restart.c
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -9,6 +9,7 @@
#include linux/types.h
#include prminst44xx.h
+#include common.h
Arnd has posted a patch [1] that includes reboot.h directly for
multiple platforms including this one.
Regards
Afzal
[1] https://lkml.org/lkml/2013/6/19/498
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH v5, 0/3] DT support for NAND on OMAP2
Hi, In the following series, 1 got merged, while other 2 are awaiting. Request you to please look into these. [PATCH 1/3] ARM: dts: AM33XX: Add ELM node -- awaiting -- [PATCH 2/3a] ARM: dts: AM33XX: Add GPMC node -- accepted by Tony [PATCH 2/3b] ARM: dts: AM33xx: Fix properties on gpmc node -- accepted by Benoit (follow-up) [PATCH 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm --awaiting -- with regards, pekon -Original Message- From: Gupta, Pekon Sent: Friday, May 31, 2013 1:19 PM To: Tony Lindgren; linux-omap@vger.kernel.org Cc: Gupta, Pekon; Philip, Avinash; Nori, Sekhar; Balbi, Felipe; Hiremath, Vaibhav; Cousson, Benoit; jac...@sunsite.dk; zon...@gmail.com; Jon Hunter Subject: [PATCH v5, 0/3] DT support for NAND on OMAP2 From: Gupta, Pekon pe...@ti.com Changes v4-v5 - updated commit descriptions. - included patch by Lars Poeschel instead of [Patch 2/3] Changes v3-v4 - rebased to linux-3.10-rc3 - updated newly supported DT properties based on following commits [d36b4cd] jon-hun...@ti.com ARM: OMAP2+: Add additional GPMC timing ... [8c8a777] jon-hun...@ti.com ARM: OMAP2+: Add function to read GPMC ... [9f83315] jon-hun...@ti.com ARM: OMAP2+: Add variable to store number Changes v2-v3 - rebased to linux-3.9-rc8 - AM335x-evm.dts: moved GPMC pin-mux config to nand node Changes v1-v2 - Change number of chip select to 7 - Replace xx literals to 52 - remove tab Lars Poeschel (1): dts: am33xx: Correct properties on gpmc node Philip Avinash (1): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm Philip, Avinash (1): ARM: dts: AM33XX: Add ELM node arch/arm/boot/dts/am335x-evm.dts | 105 +++ arch/arm/boot/dts/am33xx.dtsi| 12 - 2 files changed, 115 insertions(+), 2 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.11
Arnd Olof, * Benoit Cousson b-cous...@ti.com [130619 16:10]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.11. It does contains as well 2 clock data patches, I hope it will not generate any conflict with Paul's tree. Special thanks to Florian for his nice cleanup using the C preprocessor. It's best that Arnd and Olof take this pull request directly as we're getting so close to the merge window. These patches should be pretty much independent of the other branches I've sent, and are needed to keep omap4 booting now that we've flipped the switch for omap4 to be DT only. Regards, Tony The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts for you to fetch changes up to 153030c22defea2f96546d0f1a74fe954551c4cd: ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency (2013-06-19 16:59:28 -0500) Afzal Mohammed (2): ARM: dts: AM43x: Initial support ARM: dts: AM43x EPOS EVM support Dan Murphy (3): ARM: dts: omap4-panda: Update the LED support for the panda ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Eduardo Valentin (3): ARM: dts: OMAP443x: Add bandgap entry for OMAP443x devices ARM: dts: OMAP4460: Add bandgap entry for OMAP4460 devices ARM: dts: OMAP5: Add bandgap DT entry Florian Vaussard (15): ARM: dts: OMAP2+: Use #include for all device trees ARM: dts: OMAP2+: Use existing constants for GPIOs ARM: dts: OMAP4/5: Use existing constants for IRQs ARM: dts: OMAP2+: Header file for pinctrl constants ARM: dts: OMAP2+: Use pinctrl constants ARM: dts: AM3XXX: Use #include for all device trees ARM: dts: AM33XX: Use existing constants for GPIOs ARM: dts: AM33XX: Specific pinctrl header ARM: dts: AM33XX: Use pinctrl constants ARM: dts: OMAP4/AM35xx: Add missing dtb in the dtbs target ARM: dts: Protect pinctrl headers against multiple inclusions ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED J Keerthy (1): ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes Javier Martinez Canillas (3): ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support ARM: dts: omap3-igep0020: Add NAND flash support ARM: dts: omap3-igep0030: Add NAND flash support Kevin Hilman (3): ARM: dts: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: dts: OMAP3: beagle: enable user button via gpio_keys, enable wakeup ARM: dts: TWL4030: fix mux and wakeup for SYS_NIRQ line Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM Philip Avinash (4): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk Philip, Avinash (1): ARM: dts: AM33XX: Add ELM node Roger Quadros (4): ARM: dts: omap5-uevm: Add USB Host support ARM: dts: omap4-panda: Add USB Host support ARM: dts: omap4-panda: Fix DVI EDID reads ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support Suman Anna (1): ARM: dts: OMAP4+: Remove multimedia carveouts Vaibhav Hiremath (7): ARM: dts: AM33XX: Add default pinctrl binding for I2C device ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM ARM: dts: AM33XX: Add default pinctrl binding for UART0 device ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output ARM: AM33XX: clock: Add debugSS clock nodes ARM: AM33XX: clock data: Enable clkout2 as part of init .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/boot/dts/Makefile |8 +- arch/arm/boot/dts/am335x-bone.dts | 118 - arch/arm/boot/dts/am335x-evm.dts | 264 ++- arch/arm/boot/dts/am335x-evmsk.dts | 184 +++- arch/arm/boot/dts/am33xx.dtsi | 121
Re: [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
* Kevin Hilman khil...@linaro.org [130619 10:30]: Hi Roger, Roger Quadros rog...@ti.com writes: In order to support wake up from suspend use the pinctrl framework to put the USB host pins in IDLE state during suspend. CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com You should use helpers for this now in the pinctrl core: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html Also see the thread [PATCH] pinctrl: document the pinctrl PM states as we're still discussing how to deal with the various dynamic pinctrl needs in a generic way. Meanwile, just make sure the other patches work and don't break anything without this patch to remove the dependency. 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 2/4] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode
* Ulf Hansson ulf.hans...@linaro.org [130614 04:55]:
On 7 June 2013 23:49, Tony Lindgren t...@atomide.com wrote:
From: Andreas Fenkart andreas.fenk...@streamunlimited.com
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 irq_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+
+ if (host-sdio_irq_en == enable) {
+ dev_dbg(host-dev, en/disable:%d already set, enable);
+ spin_unlock_irqrestore(host-irq_lock, flags);
+ return;
+ }
+
Hi Tony/Andreas,
I belive a pm_runtime_get_sync would be needed here, outside the
spinlock ofcourse. Before returning from this function, obviusly
return the references by a pm_runtime_put* in some form.
Then you will be able to remove the active_pinmux variable entirely,
since you know the runtime callbacks is the only place were you need
to handle the gpio irq enable|disable.
Thanks for the review, that's a good point. I'll check this as
soon as I have a chance.
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 2/6] ARM: OMAP2+: Remove board-omap4panda.c
Tony Lindgren t...@atomide.com writes: Hi, * Arnaud Patard arnaud.pat...@rtp-net.org [130619 02:52]: Tony Lindgren t...@atomide.com writes: Hi, * Tony Lindgren t...@atomide.com [130617 03:32]: * Arnaud Patard arnaud.pat...@rtp-net.org [130617 02:52]: Tony Lindgren t...@atomide.com writes: I understand your concerns but, please, cope with reality: the clock work is not in -next so this tends to make me think it won't reach 3.11. We're at -rc6 after all. Telling users that their system doesn't have any network because it was easier to maintain, is not something they will understand imho. Right, like I said: the idea is to have it usable with DT. And USB and Ethernet certainly are part of what I call usable. So is MMC, WLAN and DSS. I've certainly spent quite a bit of time on making sure panda works with DT, and I can assure you that fixing the USB extclock is easier than supporting the legacy boot with DT :) This issue can also be fixed with a clock alias if we don't have DT defined clocks ready for v3.11. It may take a few days for us to have the solution. But get getting a clock to a driver certainly is not a showstopper here. After all, that's what all drivers already do. Care to test the last patch just posted by Roger in thread [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix? I tried to test them but they don't apply on linux-next due to some pinctrl changes probably missing: Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error which corresponds to : 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Oops, right, that's in Benoit's branch too for the .dts preprocessing. Until it is merged, maybe try with Roger's earlier version of that patch that did not yet use the macros? Right. I've changed the missing macros with their values and now, it compiles and I can even ping the board, so works for me. Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] ARM: dts: Add initial support for IGEP AQUILA
Hi all, These two patches introduces initial support for the IGEP AM335x-based platforms. The first patch add support for IGEP COM AQUILA products, and the second patch add support for the development board. These patches apply on top of bcousson/for_3.11/dts repository. Changes since v1: * Use node to reference the nodes already defined in dtsi files. (Javier) Best regards, Enric Balletbo i Serra (2): ARM: dts: AM33XX: Add support for IGEP COM AQUILA ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board. arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/am335x-base0033.dts | 17 +++ arch/arm/boot/dts/am335x-igep0033.dtsi | 269 + 3 files changed, 288 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/am335x-base0033.dts create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
The IGEP COM AQUILA is industrial processors SODIMM module with
following highlights:
o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 265 +
1 file changed, 265 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
new file mode 100644
index 000..06eba07
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -0,0 +1,265 @@
+/*
+ * am335x-igep0033.dtsi - Device Tree file for IGEP COM AQUILA AM335x
+ *
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ leds {
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins;
+
+ compatible = gpio-leds;
+
+ led@0 {
+ label = com:green:user;
+ gpios = gpio1 23 GPIO_ACTIVE_HIGH;
+ default-state = on;
+ };
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vbat;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-boot-on;
+ };
+};
+
+am33xx_pinmux {
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ nandflash_pins: pinmux_nandflash_pins {
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_wpn.gpio0_30 */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
+ ;
+ };
+
+ leds_pins: pinmux_leds_pins {
+ pinctrl-single,pins =
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ ;
+ };
+};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 0;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 1;
+};
+
+elm {
+ status = okay;
+};
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nandflash_pins;
+
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 8;
+ ti,nand-ecc-opt = bch8;
+ gpmc,device-nand = true;
+ gpmc,device-width = 1;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
[PATCHv2 2/2] ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board.
The IGEP AQUILA EXPANSION board is a development platform for the IGEP COM
AQUILA AM335x boards.
The board adds the following connectivity:
o USB OTG
o USB HOST
o HDMI
o Ethernet
o Serial Debug (3.3V)
o 2x46 pin headers
o EEPROM
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-base0033.dts | 16
2 files changed, 17 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-base0033.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..cb675d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -154,6 +154,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+ am335x-base0033.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
diff --git a/arch/arm/boot/dts/am335x-base0033.dts
b/arch/arm/boot/dts/am335x-base0033.dts
new file mode 100644
index 000..d6bb791
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -0,0 +1,16 @@
+/*
+ * am335x-base0033.dtsi - Device Tree file for IGEP AQUILA EXPANSION
+ *
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include am335x-igep0033.dtsi
+
+/ {
+ model = IGEP COM AM335x on AQUILA Expansion;
+ compatible = ti,am335x-base0033, ti,am335x-igep0033, ti,am33xx;
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: Change TWL6025 references to TWL6032
Hi Oleksandr, On Wed, Jun 19, 2013 at 03:24:02PM +0300, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there are no users of TWL6025 in the code. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com Acked-by: Lee Jones lee.jo...@linaro.org --- There are non-mainline branches that use twl6032 by its name (for example git://git.omapzoom.org/kernel/omap.git). There is intention to add support of twl6032 device in mainline, but we'd like to know if we can use twl6032 instead of twl6025 in our new patches, that we are going to provide. Related discussion: https://patchwork.kernel.org/patch/2686331/ .../bindings/regulator/twl-regulator.txt | 26 +++ .../devicetree/bindings/usb/twl-usb.txt|2 +- drivers/mfd/twl-core.c | 46 ++-- drivers/regulator/twl-regulator.c | 76 ++-- drivers/usb/phy/phy-twl6030-usb.c |2 +- include/linux/i2c/twl.h| 30 6 files changed, 91 insertions(+), 91 deletions(-) Applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
Hi, On Wed, Jun 19, 2013 at 11:27:46AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html V3: Implements Interrupts check using i2c-irq variable instead of DT interrupts property. Cleans ups in assiging the features variable in patch 2. V2: Implements Interrupts checking via DT instead of creating flags and checking based on chip ID. J Keerthy (4): MFD: Palmas: Check if irq is valid MFD: Palmas: Add SMPS10_BOOST feature mfd: Palmas: Add TPS659038 PMIC support regulator: Palmas: Add TPS659038 support I took the first 2 patches, but patch #3 does not apply. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] mfd: Palmas: Add TPS659038 PMIC support
Hi, On Wed, Jun 19, 2013 at 11:27:49AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com The Patch adds TPS659038 PMIC support in the palmas mfd driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. Signed-off-by: J Keerthy j-keer...@ti.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ drivers/mfd/palmas.c |5 + 2 files changed, 7 insertions(+), 0 deletions(-) This one does not apply against mfd-next as I don't have the palmas.txt. For Grant to take this one: Acked-by: Samuel Ortiz sa...@linux.intel.com If that creates conflicts (I already have a few palmas.c changes) then we'll have to find a way to fix them (Me taking the bindings file ?). Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
Hi Samuel, -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Thursday, June 20, 2013 2:09 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas Hi, On Wed, Jun 19, 2013 at 11:27:46AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html V3: Implements Interrupts check using i2c-irq variable instead of DT interrupts property. Cleans ups in assiging the features variable in patch 2. V2: Implements Interrupts checking via DT instead of creating flags and checking based on chip ID. J Keerthy (4): MFD: Palmas: Check if irq is valid MFD: Palmas: Add SMPS10_BOOST feature mfd: Palmas: Add TPS659038 PMIC support regulator: Palmas: Add TPS659038 support I took the first 2 patches, but patch #3 does not apply. Thanks. I will split 3 and 4 separating Documentation files. The Documentation was taken by Grant. So I will split the Patches 3 and 4 and send a separate series. Thanks again for pulling 1 and 2. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe 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] usb: dwc3: use extcon fwrk to receive connect/disconnect
Hi,
On Monday 17 June 2013 09:39 AM, Chanwoo Choi wrote:
On 06/14/2013 10:10 PM, Kishon Vijay Abraham I wrote:
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
This patch depends on
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git commit:f7ae906
It should also be applied on top of
usb: dwc3: omap: improve error handling of dwc3_omap_probe patch which is
merged in Felipe's tree.
So I'm not sure on whose tree this patch should go in.
Changes from v3:
* did #include of of_extcon.h after Chanwoo resent the patch separating
extcon-class.c from of_extcon.c
Changes from v2:
* updated the Documentation with dwc3 dt binding information.
* used of_extcon_get_extcon_dev to get extcon device from device tree data.
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some users
of palmas-usb wont need regulator.
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
drivers/usb/dwc3/dwc3-omap.c | 119
include/linux/usb/dwc3-omap.h | 30 -
3 files changed, 105 insertions(+), 49 deletions(-)
delete mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..f1c15f3 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE
It should be set to 1 for HW mode and 2 for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address
space
+Optional Properties:
+ - extcon : phandle for the extcon device omap dwc3 uses to detect
+ connect/disconnect events.
+ - vbus-supply : phandle to the regulator device tree node if needed.
+
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f8f76e6..14c1f1b 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,13 +43,15 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
-#include linux/usb/dwc3-omap.h
#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
#include linux/io.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/extcon.h
+#include linux/extcon/of_extcon.h
+#include linux/regulator/consumer.h
#include linux/usb/otg.h
@@ -124,9 +126,21 @@ struct dwc3_omap {
u32 utmi_otg_status;
u32 dma_status:1;
+
+ struct extcon_specific_cable_nb extcon_vbus_dev;
+ struct extcon_specific_cable_nb extcon_id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+
+ struct regulator*vbus_reg;
};
-static struct dwc3_omap*_omap;
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_VBUS_OFF,
+ OMAP_DWC3_VBUS_VALID,
+};
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
@@ -138,18 +152,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
-int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
+ enum omap_dwc3_vbus_id_status status)
{
- u32 val;
- struct dwc3_omap*omap = _omap;
-
- if (!omap)
- return -EPROBE_DEFER;
+ int ret;
+ u32 val;
switch (status) {
case OMAP_DWC3_ID_GROUND:
dev_dbg(omap-dev, ID GND\n);
+ if (omap-vbus_reg) {
+ ret = regulator_enable(omap-vbus_reg);
+ if (ret) {
+ dev_dbg(omap-dev, regulator enable failed\n);
+ return;
+ }
+ }
val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
val = ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
| USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
@@ -172,6 +191,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
case OMAP_DWC3_ID_FLOAT:
+ if (omap-vbus_reg)
+ regulator_disable(omap-vbus_reg);
+
case OMAP_DWC3_VBUS_OFF:
dev_dbg(omap-dev, VBUS Disconnect\n);
@@ -185,12 +207,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
default:
- dev_dbg(omap-dev, ID float\n);
+
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.11
On Thursday 20 June 2013, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 16:10]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.11. It does contains as well 2 clock data patches, I hope it will not generate any conflict with Paul's tree. Special thanks to Florian for his nice cleanup using the C preprocessor. It's best that Arnd and Olof take this pull request directly as we're getting so close to the merge window. These patches should be pretty much independent of the other branches I've sent, and are needed to keep omap4 booting now that we've flipped the switch for omap4 to be DT only. Ok, I've put it in my queue. About 60 pull requests to take care of at the moment, so it might take a few days. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hi, On Thu, Jun 20, 2013 at 04:34:42AM +, J, KEERTHY wrote: -Original Message- From: J, KEERTHY Sent: Wednesday, June 19, 2013 11:28 AM To: linux-omap@vger.kernel.org Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature From: J Keerthy j-keer...@ti.com The SMPS10 regulator is not presesnt in all the variants of the PALMAS PMIC family. Hence adding a feature to distingush between them. Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hi Samuel, -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Thursday, June 20, 2013 2:38 PM To: J, KEERTHY Cc: broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux- o...@vger.kernel.org Subject: Re: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature Hi, On Thu, Jun 20, 2013 at 04:34:42AM +, J, KEERTHY wrote: -Original Message- From: J, KEERTHY Sent: Wednesday, June 19, 2013 11:28 AM To: linux-omap@vger.kernel.org Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature From: J Keerthy j-keer...@ti.com The SMPS10 regulator is not presesnt in all the variants of the PALMAS PMIC family. Hence adding a feature to distingush between them. Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. So the of_match_device parts can come under #ifdef CONFIG_OF? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
On Thu, Jun 20, 2013 at 09:13:06AM +, J, KEERTHY wrote: Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. So the of_match_device parts can come under #ifdef CONFIG_OF? Nevermind, you were just missing an of_device.h inclusion. I fixed that up and applied your patch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
-Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Thursday, June 20, 2013 2:57 PM To: J, KEERTHY Cc: broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux- o...@vger.kernel.org Subject: Re: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature On Thu, Jun 20, 2013 at 09:13:06AM +, J, KEERTHY wrote: Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. So the of_match_device parts can come under #ifdef CONFIG_OF? Nevermind, you were just missing an of_device.h inclusion. I fixed that up and applied your patch. Oops..I get it. Thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Mark Brown broo...@linaro.org
---
drivers/regulator/palmas-regulator.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
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/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: https://lkml.org/lkml/2013/6/20/156 J Keerthy (4): MFD: Add TPS659038 documentation under Palmas MFD: Palmas: Add TPS659038 PMIC support regulators: Add TPS659038 documentation under Palmas regulator: Palmas: Add TPS659038 support Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c |5 + drivers/regulator/palmas-regulator.c |1 + 4 files changed, 9 insertions(+), 0 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
[PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 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 2/4] MFD: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/palmas.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index ad2edd6..8b20055 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -233,12 +233,17 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
}
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+static unsigned int tps659038_features;
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
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 3/4] regulators: Add TPS659038 documentation under Palmas
Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Mark Brown broo...@linaro.org --- .../devicetree/bindings/regulator/palmas-pmic.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a3086..5115cd7 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps659038-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. -- 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: Unable to find JFFS2 partition ... but I know it's there !!
On 20/06/13 10:31, Mark Jackson wrote: I'm struggling to debug an issue where the kernel is unable to find a JFFS2 partition held in NOR flash (on CS0) Fixed ... I finally worked out I needed to add:- CONFIG_MTD_BLOCK CONFIG_MTD_BLOCK2MTD Sorry for the noise. Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/20/2013 01:40 AM, Benoit Cousson wrote:
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was
not the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it
should to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one, adding
that a new solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, I've just done it myself while applying your series.
Great !! Thanks.
There is a similar patch for beagle-xm. But I will resend it to you with the
disclaimer.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
On 06/19/2013 09:42 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
This one doesn't apply...
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
-pinctrl-names = default;
-pinctrl-0 =
-hsusbb2_pins
-;
-
-hsusbb2_pins: pinmux_hsusbb2_pins {
This omap3_pmx_core section doesn't exist upstream in the xM DTS file
(but does in omap3-beagle.dts.)
Is there a dependency patch missing?
Sorry for not mentioning it earlier. This is based on Benoit's tree [1]
and you need these patches
http://thread.gmane.org/gmane.linux.drivers.devicetree/38383
[1]
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
/for_3.11/dts
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
On 06/20/2013 02:55 PM, Roger Quadros wrote:
On 06/19/2013 09:42 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
This one doesn't apply...
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
This omap3_pmx_core section doesn't exist upstream in the xM DTS file
(but does in omap3-beagle.dts.)
Is there a dependency patch missing?
Sorry for not mentioning it earlier. This is based on Benoit's tree [1]
and you need these patches
http://thread.gmane.org/gmane.linux.drivers.devicetree/38383
Just noticed that this no longer applies today. I'll send a revision soon.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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 1/6] mfd: omap-usb-host: move initialization to module_init()
Hi,
On Wed, Jun 19, 2013 at 05:05:48PM +0300, Roger Quadros wrote:
We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 10 +-
drivers/mfd/omap-usb-tll.c |8 +---
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..6601a49 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
{
return platform_driver_probe(usbhs_omap_driver, usbhs_omap_probe);
}
-
-/*
- * init before ehci and ohci drivers;
- * The usbhs core driver should be initialized much before
- * the omap ehci and ohci probe functions are called.
- * This usbhs core driver should be initialized after
- * usb tll driver
- */
-fs_initcall_sync(omap_usbhs_drvinit);
+module_init(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..fb7c73e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
{
return platform_driver_register(usbtll_omap_driver);
}
-
-/*
- * init before usbhs core driver;
- * The usbtll driver should be initialized before
- * the usbhs core driver probe function is called.
- */
-fs_initcall(omap_usbtll_drvinit);
+module_init(omap_usbtll_drvinit);
since you're doing that, could just move to module_platform_driver.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Hi,
On Wed, Jun 19, 2013 at 05:05:51PM +0300, Roger Quadros wrote:
Runtime suspend the controller during bus suspend and resume it
during bus resume. This will ensure that the USB Host power domain
enters lower power state and does not prevent the SoC from
endering deeper sleep states.
Remote wakeup will come up as an interrupt while the controller
is suspended, so tackle it carefully using a workqueue.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 82
++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 16d7150..91f14f1 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -44,6 +44,8 @@
#include linux/usb/hcd.h
#include linux/of.h
#include linux/dma-mapping.h
+#include linux/workqueue.h
+#include linux/spinlock.h
#include ehci.h
@@ -69,6 +71,7 @@ static const char hcd_name[] = ehci-omap;
struct omap_hcd {
struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
int nports;
+ struct work_struct work;
};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
+static void omap_ehci_work(struct work_struct *work)
+{
+ struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
+ struct ehci_hcd *ehci = container_of((void *) omap,
+ struct ehci_hcd, priv);
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ struct device *dev = hcd-self.controller;
+
+ pm_runtime_get_sync(dev);
+ enable_irq(hcd-irq);
+ /*
+ * enable_irq() should preempt us with a pending IRQ
+ * so we can be sure that IRQ handler completes before
+ * we call pm_runtime_put_sync()
+ */
+ pm_runtime_put_sync(dev);
+}
+
+static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
+{
+ struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
+ struct device *dev = hcd-self.controller;
+ irqreturn_t ret;
+
+ if (pm_runtime_suspended(dev)) {
+ schedule_work(omap-work);
+ disable_irq_nosync(hcd-irq);
+ ret = IRQ_HANDLED;
looks like this could be done as:
if (pm_runtime_suspended(dev)) {
pm_runtime_get(dev);
omap-flags |= OMAP_EHCI_IRQ_PENDING;
disable_irq_nosync(hcd-irq);
ret = IRQ_HANDLED;
}
then on your -runtime_resume():
runtime_resume(dev)
{
...
if (omap-flags OMAP_EHCI_IRQ_PENDING) {
process_pending_irqs(omap);
omap-flags = ~OMAP_EHCI_IRQ_PENDING;
}
return 0;
}
or something similar
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init()
On 06/20/2013 03:07 PM, Felipe Balbi wrote:
Hi,
On Wed, Jun 19, 2013 at 05:05:48PM +0300, Roger Quadros wrote:
We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 10 +-
drivers/mfd/omap-usb-tll.c |8 +---
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..6601a49 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
{
return platform_driver_probe(usbhs_omap_driver, usbhs_omap_probe);
}
-
-/*
- * init before ehci and ohci drivers;
- * The usbhs core driver should be initialized much before
- * the omap ehci and ohci probe functions are called.
- * This usbhs core driver should be initialized after
- * usb tll driver
- */
-fs_initcall_sync(omap_usbhs_drvinit);
+module_init(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..fb7c73e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
{
return platform_driver_register(usbtll_omap_driver);
}
-
-/*
- * init before usbhs core driver;
- * The usbtll driver should be initialized before
- * the usbhs core driver probe function is called.
- */
-fs_initcall(omap_usbtll_drvinit);
+module_init(omap_usbtll_drvinit);
since you're doing that, could just move to module_platform_driver.
sounds good.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
On 06/19/2013 08:23 PM, Kevin Hilman wrote: Hi Roger, Roger Quadros rog...@ti.com writes: In order to support wake up from suspend use the pinctrl framework to put the USB host pins in IDLE state during suspend. CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com You should use helpers for this now in the pinctrl core: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html Right. thanks. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe 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 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 06/19/2013 08:39 PM, Kevin Hilman wrote: Hi Roger, Roger Quadros rog...@ti.com writes: Runtime suspend the controller during bus suspend and resume it during bus resume. This will ensure that the USB Host power domain enters lower power state and does not prevent the SoC from endering deeper sleep states. Remote wakeup will come up as an interrupt while the controller is suspended, so tackle it carefully using a workqueue. I don't think you need a special workqueue here. The workqueue of the PM core (pm_wq) will be used if you just use an asynchronous 'get' in the ISR. Then, the driver's own runtime PM callbacks can be used instead of an additional workqueue. Another thing to worry about here when using runtime PM to implement suspend/resume is that runtime PM can be disabled from userspace (e.g. echo disabled /sys/devices/.../power/control.) If that's the case, all the pm_runtime_suspended() checks will always fail becuase that call also checks if runtime PM is disabled. You'll likely want to use the pm_runtime_status_suspended() check instead, which checks only the status, and doesn't matter if runtime PM is currently disabled. Because of the corner issues here, please test system suspend/resume when runtime PM has been disabled. Good points. Thanks. I'll need to think about it some more. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe 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 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 06/20/2013 03:11 PM, Felipe Balbi wrote:
Hi,
On Wed, Jun 19, 2013 at 05:05:51PM +0300, Roger Quadros wrote:
Runtime suspend the controller during bus suspend and resume it
during bus resume. This will ensure that the USB Host power domain
enters lower power state and does not prevent the SoC from
endering deeper sleep states.
Remote wakeup will come up as an interrupt while the controller
is suspended, so tackle it carefully using a workqueue.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 82
++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 16d7150..91f14f1 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -44,6 +44,8 @@
#include linux/usb/hcd.h
#include linux/of.h
#include linux/dma-mapping.h
+#include linux/workqueue.h
+#include linux/spinlock.h
#include ehci.h
@@ -69,6 +71,7 @@ static const char hcd_name[] = ehci-omap;
struct omap_hcd {
struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
int nports;
+struct work_struct work;
};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
+static void omap_ehci_work(struct work_struct *work)
+{
+struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
+struct ehci_hcd *ehci = container_of((void *) omap,
+struct ehci_hcd, priv);
+struct usb_hcd *hcd = ehci_to_hcd(ehci);
+struct device *dev = hcd-self.controller;
+
+pm_runtime_get_sync(dev);
+enable_irq(hcd-irq);
+/*
+ * enable_irq() should preempt us with a pending IRQ
+ * so we can be sure that IRQ handler completes before
+ * we call pm_runtime_put_sync()
+ */
+pm_runtime_put_sync(dev);
+}
+
+static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
+{
+struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
+struct device *dev = hcd-self.controller;
+irqreturn_t ret;
+
+if (pm_runtime_suspended(dev)) {
+schedule_work(omap-work);
+disable_irq_nosync(hcd-irq);
+ret = IRQ_HANDLED;
looks like this could be done as:
if (pm_runtime_suspended(dev)) {
pm_runtime_get(dev);
omap-flags |= OMAP_EHCI_IRQ_PENDING;
disable_irq_nosync(hcd-irq);
ret = IRQ_HANDLED;
}
then on your -runtime_resume():
runtime_resume(dev)
{
...
if (omap-flags OMAP_EHCI_IRQ_PENDING) {
process_pending_irqs(omap);
OK, thanks.
But I'm not sure if the generic ehci_irq handler is able to
run in a process context. Maybe if we replace spin_lock(ehci-lock);
with spin_lock_irqsave() there, it will work.
Alan is this a doable option?
omap-flags = ~OMAP_EHCI_IRQ_PENDING;
}
return 0;
}
or something similar
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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 0/6] Suspend USB Host controller on bus suspend
On 06/19/2013 06:23 PM, Alan Stern wrote: On Wed, 19 Jun 2013, Roger Quadros wrote: Hi, This series attempts to suspend the OMAP EHCI host controller on USB Bus suspend. Why do you want to suspend the host controller during bus suspend? They are two different operations and should be carried out at two different times. The controller should be suspended during controller suspend, not during bus suspend. Good point. I didn't think it that way. I think it should work. As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Do you still need to override these things if you do the controller suspend at the right time? At least not for bus_suspend and bus_resume. We will still need to override the irq handler though. But, if we can take care of this generically in the ehci_irq handler (i.e. make sure controller is not suspended while accessing it) then we don't need such override for irq. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe 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 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
On 06/19/2013 08:30 PM, Sergei Shtylyov wrote:
Hello.
On 06/19/2013 06:05 PM, Roger Quadros wrote:
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs = OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
-/*
- * REVISIT: Enabling usb host save and restore mechanism seems to
- * leave the usb host domain permanently in ACTIVE mode after
- * changing the usb host power domain state from OFF to active once.
- * Disabling for now.
- */
-/*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+.flags = PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
Looks like you're not indenting = right, in accordance to the other
fields...
Will fix. Thanks.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe 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] regulator: core: allow consumers to request to closes step voltage
On 23:38-20130619, Mark Brown wrote: On Wed, Jun 19, 2013 at 02:17:54PM -0500, Nishanth Menon wrote: Account for step size accuracy when exact voltage requests are send for step based regulators. If the consumer can tolerate a different voltage why not just request the range that can be tolerated? Your problem here is specifying an exact voltage. I think you mean using regulator_get_linear_step The specific example I faced was using cpufreq-cpu0 driver with voltages for OPPs for MPU rail and attempting the common definitions against voltages that are non-exact multiples of stepsize of PMIC. The alternative would be implement custom set_voltage (as againsta simpler set_voltage_sel and using linear map/list functions) for the regulator which will account for the same. Yet another alternative might be to introduce yet another custom function similar to regulator_set_voltage_tol which accounts for this. something like: regulator_set_voltage_floor(regulator, voltage, tol) or something to that effect. Or as I keep telling you guys the consumer can just do that directly using the existing API; the whole point in specifying the voltage as a range is to allow the consumer to cope with arbatrary regulators by giving a range of voltages that it can accept. The API is deliberately very conservative in these matters since there is a danger of physical damage if things really go wrong in some applications, it makes sure that both the drivers and the system integration are involved. I agree. The intent of this series was to start a conversation to see if we can make it simpler. Searching for the users of regulator_get_linear_step in 3.10-rc6 shows none. For a generic driver which needs to handle platforms which have tolerance, they'd use regulator_set_voltage_tol. But the implementation would allow for uV - tol to uV + tol as range, which in the case I mentioned(min voltage =uV) wont work. If the consumer wants to be aware of linear step regulator, they'd have to do: step_uV = regulator_get_linear_step(...); regulator_set_voltage(uV, uV + step_uV); Then this wont handle tolerance. So the solution seems to be (for the consumer): step_uV = regulator_get_linear_step(...); .. if (tol) regulator_set_voltage_tol(uV, tol); else regulator_set_voltage(uV, uV + step_uV); (with the required error checks for regulator being a linear regulator etc..). At least to me, there is no sane manner to handle tolerance and linear step accuracy for a defined voltage (Should tolerance be rounded off to step_uV? what about the border cases etc.) Would you agree? -- Regards, Nishanth Menon PS: Since I just looped in cpufreq list, discussion thread: http://marc.info/?t=13716695495r=1w=2 -- To unsubscribe from this list: send the line unsubscribe 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/2] ARM: dts: Add USB host support for Beagle-xm
Hi Benoit, Patch 1 adds USB host support for beagle-XM. Patch 2 cleans up pin comments for USB host pins. Changes in v4: - Rebased to todays for_3.11/dts branch - added disclaimer about temporary usage of regulator framework for GPIO RESET lines. cheers, -roger Roger Quadros (2): ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Make USB host pin naming consistent arch/arm/boot/dts/omap3-beagle-xm.dts | 81 + arch/arm/boot/dts/omap3-beagle.dts| 29 +++- 2 files changed, 89 insertions(+), 21 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/2] ARM: dts: omap3-beagle: Make USB host pin naming consistent
Use a common naming scheme mode0name.modename flags for the
USB host pins to be consistent.
Also add a disclaimer stating that use of regulator framework
for GPIO RESET line is temporary.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..587781a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,6 +44,11 @@
};
};
+ /*
+* Temp hack: Need to be replaced with the proper gpio-controlled
+* reset driver as soon it will be merged.
+* http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
+*/
/* HS USB Port 2 RESET */
hsusb2_reset: hsusb2_reset_reg {
compatible = regulator-fixed;
@@ -101,18 +106,18 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins =
- 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_clk */
- 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_stp */
- 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dir */
- 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_nxt */
- 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat0 */
- 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat1 */
- 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat2 */
- 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat3 */
- 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat4 */
- 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat5 */
- 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat6 */
- 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
usbb2_ulpitll_clk.usbb1_ulpiphy_dat7 */
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] ARM: dts: omap3-beagle-xm: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device. Provide
pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
NOTE: The reset control will be replaced with the proper
gpio-controlled reset driver as soon it will be merged [1].
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 81 +
1 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..371b1e2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,39 @@
};
};
+
+ /*
+* Temp hack: Need to be replaced with the proper gpio-controlled
+* reset driver as soon it will be merged.
+* http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
+*/
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
};
omap3_pmx_wkup {
@@ -79,6 +112,37 @@
};
};
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+ 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+ ;
+ };
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
@@ -148,15 +212,6 @@
power = 50;
};
-omap3_pmx_core {
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins =
- 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
- 0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
- ;
- };
-};
-
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
@@ -166,3 +221,11 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
On 06/20/2013 03:02 PM, Roger Quadros wrote:
On 06/20/2013 02:55 PM, Roger Quadros wrote:
On 06/19/2013 09:42 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
This one doesn't apply...
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
This omap3_pmx_core section doesn't exist upstream in the xM DTS file
(but does in omap3-beagle.dts.)
Is there a dependency patch missing?
Sorry for not mentioning it earlier. This is based on Benoit's tree [1]
and you need these patches
http://thread.gmane.org/gmane.linux.drivers.devicetree/38383
Just noticed that this no longer applies today. I'll send a revision soon.
OK. In case you are eager to test, please use the series [1] on l-o on top of
Benoit's
for_3.11/_dts branch and then the $subject series with the updated patch 5
below [2].
[1] - [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
[2] - Updated Patch 5
From b712a1fb936f65fa05f21fcd2c62fff5628d0628 Mon Sep 17 00:00:00 2001
From: Roger Quadros rog...@ti.com
Date: Wed, 19 Jun 2013 11:14:35 +0300
Subject: [PATCH] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 371b1e2..91d19fa 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -113,11 +113,6 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
@@ -125,7 +120,7 @@
;
};
- hsusbb2_pins: pinmux_hsusbb2_pins {
+ hsusb2_pins: pinmux_hsusb2_pins {
pinctrl-single,pins =
0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
@@ -141,6 +136,25 @@
0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
+
+ /* WAKEUP enabled on DIR, DAT0-3 */
+ hsusb2_idle_pins: pinmux_hsusb2_idle_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)
/* etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* mcspi2_cs1.hsusb2_data3 */
+ ;
+ interrupts = 77; /* route padconf wakeup to EHCI IRQ */
+ };
};
i2c1 {
@@ -223,6 +237,9 @@
};
usbhshost {
+ pinctrl-names = default, idle;
+ pinctrl-0 = hsusb2_pins;
+ pinctrl-1 =
RE: [PATCH v5, 0/3] DT support for NAND on OMAP2
Hi Pekon, Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 12.654.784 -Original Message- From: Gupta, Pekon Sent: Thursday, June 20, 2013 1:34 AM To: Tony Lindgren; Cousson, Benoit Cc: Philip, Avinash; Nori, Sekhar; Balbi, Felipe; Hiremath, Vaibhav; jac...@sunsite.dk; zon...@gmail.com; Jon Hunter; linux- o...@vger.kernel.org Subject: RE: [PATCH v5, 0/3] DT support for NAND on OMAP2 Hi, In the following series, 1 got merged, while other 2 are awaiting. Request you to please look into these. [PATCH 1/3] ARM: dts: AM33XX: Add ELM node -- awaiting -- [PATCH 2/3a] ARM: dts: AM33XX: Add GPMC node -- accepted by Tony [PATCH 2/3b] ARM: dts: AM33xx: Fix properties on gpmc node -- accepted by Benoit (follow-up) [PATCH 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x- evm --awaiting -- I think that all of them are in the branch I've just asked Tony to pull. Could you check in my for_3.11/dts branch? Thanks, Benoit with regards, pekon -Original Message- From: Gupta, Pekon Sent: Friday, May 31, 2013 1:19 PM To: Tony Lindgren; linux-omap@vger.kernel.org Cc: Gupta, Pekon; Philip, Avinash; Nori, Sekhar; Balbi, Felipe; Hiremath, Vaibhav; Cousson, Benoit; jac...@sunsite.dk; zon...@gmail.com; Jon Hunter Subject: [PATCH v5, 0/3] DT support for NAND on OMAP2 From: Gupta, Pekon pe...@ti.com Changes v4-v5 - updated commit descriptions. - included patch by Lars Poeschel instead of [Patch 2/3] Changes v3-v4 - rebased to linux-3.10-rc3 - updated newly supported DT properties based on following commits [d36b4cd] jon-hun...@ti.com ARM: OMAP2+: Add additional GPMC timing ... [8c8a777] jon-hun...@ti.com ARM: OMAP2+: Add function to read GPMC ... [9f83315] jon-hun...@ti.com ARM: OMAP2+: Add variable to store number Changes v2-v3 - rebased to linux-3.9-rc8 - AM335x-evm.dts: moved GPMC pin-mux config to nand node Changes v1-v2 - Change number of chip select to 7 - Replace xx literals to 52 - remove tab Lars Poeschel (1): dts: am33xx: Correct properties on gpmc node Philip Avinash (1): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm Philip, Avinash (1): ARM: dts: AM33XX: Add ELM node arch/arm/boot/dts/am335x-evm.dts | 105 +++ arch/arm/boot/dts/am33xx.dtsi| 12 - 2 files changed, 115 insertions(+), 2 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
Thanks Roger, I'll take them for 3.12. I was already late for my 3.11 pull request. Regards, Benoit Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 12.654.784 -Original Message- From: Quadros, Roger Sent: Thursday, June 20, 2013 7:46 AM To: Cousson, Benoit Cc: t...@atomide.com; linux-omap@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; Quadros, Roger Subject: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm Hi Benoit, Patch 1 adds USB host support for beagle-XM. Patch 2 cleans up pin comments for USB host pins. Changes in v4: - Rebased to todays for_3.11/dts branch - added disclaimer about temporary usage of regulator framework for GPIO RESET lines. cheers, -roger Roger Quadros (2): ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Make USB host pin naming consistent arch/arm/boot/dts/omap3-beagle-xm.dts | 81 + arch/arm/boot/dts/omap3-beagle.dts| 29 +++- 2 files changed, 89 insertions(+), 21 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
Hi Javier,
On 6/19/2013 8:32 AM, Javier Martinez Canillas wrote:
Hi,
On Wed, Jun 19, 2013 at 12:46 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Enric,
On 06/19/2013 03:27 AM, Enric Balletbo i Serra wrote:
The IGEP COM AQUILA is industrial processors SODIMM module with
following highlights:
o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 269
+
1 file changed, 269 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
new file mode 100644
index 000..1d70141
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
That node should be inside the ocp one since the control module is a regular
IP connected to the OCP interconnect.
In fact, I don't think that there should be a definition of the On
Chip Peripherals interconnect or any child node of the ocp in a DTS
file.
These should be defined in the included dtsi file since it will be
common to all boards based on this SoC.
Well there is nothing wrong with that in the DTS theory, but I do agree
that keeping these internal SoC details outside the board file is indeed
much better.
DTS files that describe a board can reference these nodes defined in
the dtsi and add their custom peripherals as childs of them.
So, instead defining in the DTS:
am33xx_pinmux: pinmux@44e10800 {
...
};
gpmc: gpmc@5000 {
...
};
i2c0: i2c@44e0b000 {
...
};
uart0: serial@44e09000 {
..
};
It has to be defined as:
am33xx_pinmux {
...
};
gpmc {
...
};
i2c0 {
...
}
I'm looking at other am33xx dts such as am335x-bone.dts and
am335x-evm.dts and I see that these define device nodes already
defined in the included .dtsi which is wrong in my opinion.
The OMAP{3,4,5} dtsi and dts do correctly and can be used as a
reference on how the device nodes have to be defined and referenced.
Good point, we should potentially clean the am33xx files to make then
consistent with other OMAP stuff.
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration
IGEP boards have a number of LED connected to OMAP or TWL GPIO
lines. The actual wiring is different on each board so each board
DT has need to configure the mux correctly.
Even though it works with the current DT, the kernel complains with:
[2.305023] leds-gpio leds.18: pins are not configured from the driver
Add an empty pinmux_leds_pins pinctrl child node so boards can
override with the correct mux configuration and not depend on
default values for the GPIO LEDs to work.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index bc48b11..55f9f61 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -68,6 +68,8 @@
0x1a2 (PIN_INPUT | MUX_MODE4) /*
mcspi1_cs2.gpio_176 */
;
};
+
+ leds_pins: pinmux_leds_pins { };
};
i2c1 {
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs
The IGEPv2 has a number of GPIO LED connected to OMAP
pins. Configure these pins as output GPIO.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0020.dts | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..51c084e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -16,7 +16,10 @@
compatible = isee,omap3-igep0020, ti,omap3;
leds {
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins;
compatible = gpio-leds;
+
boot {
label = omap3:green:boot;
gpios = gpio1 26 GPIO_ACTIVE_HIGH;
@@ -54,6 +57,14 @@
};
};
+leds_pins {
+ pinctrl-single,pins =
+ 0x5c4 (PIN_OUTPUT | MUX_MODE4) /* etk_d12.gpio_26 */
+ 0x5c6 (PIN_OUTPUT | MUX_MODE4) /* etk_d13.gpio_27 */
+ 0x5c8 (PIN_OUTPUT | MUX_MODE4) /* etk_d14.gpio_28 */
+ ;
+};
+
i2c3 {
clock-frequency = 10;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: omap3-igep0030: add mux conf for GPIO LED
The IGEP COM MOdule has a GPIO LED connected to OMAP
pins. Configure this pin as output GPIO.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep0030.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d053..eee3c63 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -16,7 +16,10 @@
compatible = isee,omap3-igep0030, ti,omap3;
leds {
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins;
compatible = gpio-leds;
+
boot {
label = omap3:green:boot;
gpios = twl_gpio 13 GPIO_ACTIVE_LOW;
@@ -43,6 +46,12 @@
};
};
+leds_pins {
+ pinctrl-single,pins =
+ 0x5b0 (PIN_OUTPUT | MUX_MODE4) /* etk_d2.gpio_16 */
+ ;
+};
+
gpmc {
ranges = 0 0 0x 0x2000;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/7] omap soc fixes for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 4f288f081bb67813d35c10d1b2fa68e863c4b188: ARM: OMAP2+: AM43x: SRAM base and size (2013-06-12 08:07:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/soc-part2-signed for you to fetch changes up to 7bcad170154f1302aeeced4f236588091a261fbf: ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature (2013-06-18 03:04:07 -0700) Fix am43x minimal booting as I accidentally left out one patch from the already merged omap-for-v3.11/soc-signed branch. Also fixes for ti81x booting and revision check updates. These are based on omap-for-v3.11/soc-signed because of the am43x dependency to earlier patches. Pulled into next/soc, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL 2/7] omap serial pm cleanup for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/pm-serial-signed for you to fetch changes up to 1e383d7bdd988b1453a3a86f5e14b012700f7dff: Merge tag 'omap-pm-v3.11/cleanup/pm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-v3.11/pm-serial (2013-06-17 04:03:14 -0700) Serial driver platform init code clean-up via Kevin Hilman khil...@linaro.org: OMAP: PM: the serial core + driver can no handle no_console_suspend support without any SoC specific handlding or SoC-specific DT bindings. Remove the now unused SoC specifics for OMAP. Pulled into next/cleanup, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL 4/7] omap dma clean-up for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/dma-signed for you to fetch changes up to e2081f96ba1be3aa22a44daec82af9b226a6d7d6: ARM: OMAP1: Remove dma.h (2013-06-18 00:12:34 -0700) Non-critical omap DMA fixes and removal of unused legacy code. Pulled into next/cleanup, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL 3/7] omap voltdomain clean-up for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/pm-voltdomain-signed for you to fetch changes up to 8bfdfc87dc3d00eb2f33e972b4177c36ca0e3d54: Merge tag 'omap-pm-v3.11/voltdm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-v3.11/pm-voltdomain (2013-06-18 01:08:39 -0700) PM voltage domain clean-up via Kevin Hilman khil...@linaro.org: OMAP: PM: remove requirement for voltage domain data; remove dummy data Pulled into next/cleanup, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe 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 0/6] Suspend USB Host controller on bus suspend
On Thu, 20 Jun 2013, Roger Quadros wrote: As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Do you still need to override these things if you do the controller suspend at the right time? At least not for bus_suspend and bus_resume. We will still need to override the irq handler though. But, if we can take care of this generically in the ehci_irq handler (i.e. make sure controller is not suspended while accessing it) then we don't need such override for irq. I don't think you need to override anything. The high-level interrupt handler usb_hcd_irq() will avoid calling ehci_irq() when the HCD_HW_ACCESSIBLE flag isn't set. All you will need to do in ehci-omap.c is call synchronize_irq() after ehci_suspend() returns and before turning off the clocks. Alan Stern -- To unsubscribe from this list: send the line unsubscribe 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 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On Thu, 20 Jun 2013, Roger Quadros wrote:
runtime_resume(dev)
{
...
if (omap-flags OMAP_EHCI_IRQ_PENDING) {
process_pending_irqs(omap);
OK, thanks.
But I'm not sure if the generic ehci_irq handler is able to
run in a process context. Maybe if we replace spin_lock(ehci-lock);
with spin_lock_irqsave() there, it will work.
Alan is this a doable option?
ehci_irq() will work okay in process context, provided the caller
disables interrupts.
But maybe none of this will be needed after Roger redesigns the
controller suspend to work at the right time. Or if it is, we could
adopt a simpler alternative: the controller's resume routine could
always call usb_hcd_resume_root_hub(). After all, about the only
reason for doing a runtime resume of the controller is because the root
hub needs to do something.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: add deprecation warning for class based instantiation
Hi, Sorry, for delayed reply - I've had problems with my e-mail. You still have. This message has unwanted linebreaks. I've tested this patch on our TI K3.4 product kernel with additional change below: Thanks. [0.662567] (null): This adapter will soon drop class based instantiation of slaves ^ invalid adapter device name here Good point, thanks! Will send an updated patch in a minute. In addition, I've found the following users of *i2c-gpio* (just FYI): Ehrm, okay, and why exactly did you post it? :) Regards, Wolfram signature.asc Description: Digital signature
Re: [GIT PULL 6/7] omap gpmc reworked suspend patch for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit b3f5525c55ce5cb67af06f04dbbf28358da23a2c: ARM: OMAP2+: gpmc: Converts GPMC driver to pm_runtime capable (2013-06-12 09:56:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/gpmc-part2-signed for you to fetch changes up to b536dd412b4364df2f9495c6550ee38f6ad3b0fe: ARM: OMAP2+: gpmc: Low power transition support (2013-06-18 03:46:39 -0700) GPMC suspend patch that was left out of the earlier omap-for-v3.11/gpmc-signed branch because of a compile error it caused. The compile error is fixed in this version. Pulled into next/drivers, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL 5/7] omap board changes for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/board-signed for you to fetch changes up to 45853507c9362b0bd606b37e8c7c7e7551caa78b: ARM: omap2plus_defconfig: enable USB_PHY and NOP_USB_XCEIV (2013-06-18 03:19:07 -0700) Minor board changes for v3.11 merge window. These are tapering down finally as we're getting closer to making omap2+ DT only. Aaro Koskinen (1): ARM: OMAP1: nokia770: enable Tahvo Adrien Verg (1): ARM: omap2plus_defconfig: enable USB_PHY and NOP_USB_XCEIV Florian Vaussard (1): arm: omap: board-overo: reset GPIO for SMSC911x Lokesh Vutla (1): ARM: OMAP3EVM: Marking omap3_evm_display_init() with CONFIG_BROKEN arch/arm/configs/omap2plus_defconfig | 2 ++ arch/arm/mach-omap1/board-nokia770.c | 10 ++ arch/arm/mach-omap2/board-omap3evm.c | 4 arch/arm/mach-omap2/board-overo.c| 3 ++- 4 files changed, 18 insertions(+), 1 deletion(-) Pulled into next/boards, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL 7/7] omap mailbox move to drivers for v3.11 merge window
On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/mailbox-signed for you to fetch changes up to d2e993289cc5f1780ce74188e3a8d2b404748397: Merge tag 'omap-mailbox-for-v3.11' of git://github.com/sumananna/mailbox into omap-for-v3.11/mailbox (2013-06-17 03:51:54 -0700) Move OMAP Mailbox framework to drivers via Suman Anna s-a...@ti.com The OMAP Mailbox driver framework is moved out of arch/arm folder into drivers/mailbox folder, to re-enable building it and also serve as a baseline for adapting to the new mailbox driver framework. The changes mainly contain: - a minor bug fix and cleanup of mach-specific mailbox code - remove any header dependencies from plat-omap for multi-platform support - represent mailbox device data through platform data/hwmod attrs - move the omap mailbox code out of plat-omap/mach-omapX to drivers/mailbox folder I've pulled this into next/drivers as well, rather than a separate branch that we had for 3.10 (and dropped). I am a bit puzzled about this series though. Is it right that for 3.10 we had plans for a generic subsystem, and now it's just the omap drivers? Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL] ARM: OMAP: Device Tree for 3.11
On Thursday 20 June 2013, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 16:10]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.11. It does contains as well 2 clock data patches, I hope it will not generate any conflict with Paul's tree. Special thanks to Florian for his nice cleanup using the C preprocessor. It's best that Arnd and Olof take this pull request directly as we're getting so close to the merge window. These patches should be pretty much independent of the other branches I've sent, and are needed to keep omap4 booting now that we've flipped the switch for omap4 to be DT only. Would someone provide a merge description for this? I just noticed that it's not a signed tag, and there are lots of patches in it, so I'd rather not have to come up with something myself. Arnd -- To unsubscribe from this list: send the line unsubscribe 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: [GIT PULL] ARM: OMAP: Device Tree for 3.11
Hi Tony, On 6/20/2013 1:45 AM, Tony Lindgren wrote: Arnd Olof, * Benoit Cousson b-cous...@ti.com [130619 16:10]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.11. It does contains as well 2 clock data patches, I hope it will not generate any conflict with Paul's tree. Special thanks to Florian for his nice cleanup using the C preprocessor. It's best that Arnd and Olof take this pull request directly as we're getting so close to the merge window. These patches should be pretty much independent of the other branches I've sent, and are needed to keep omap4 booting now that we've flipped the switch for omap4 to be DT only. Thanks and sorry for that. I was not expecting all these last minutes series :-( I'll stop accepting at -rc5 next time. Regards, Benoit The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts for you to fetch changes up to 153030c22defea2f96546d0f1a74fe954551c4cd: ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency (2013-06-19 16:59:28 -0500) Afzal Mohammed (2): ARM: dts: AM43x: Initial support ARM: dts: AM43x EPOS EVM support Dan Murphy (3): ARM: dts: omap4-panda: Update the LED support for the panda ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition ARM: dts: omap5-uevm: Add LED support for uEVM blue LED Eduardo Valentin (3): ARM: dts: OMAP443x: Add bandgap entry for OMAP443x devices ARM: dts: OMAP4460: Add bandgap entry for OMAP4460 devices ARM: dts: OMAP5: Add bandgap DT entry Florian Vaussard (15): ARM: dts: OMAP2+: Use #include for all device trees ARM: dts: OMAP2+: Use existing constants for GPIOs ARM: dts: OMAP4/5: Use existing constants for IRQs ARM: dts: OMAP2+: Header file for pinctrl constants ARM: dts: OMAP2+: Use pinctrl constants ARM: dts: AM3XXX: Use #include for all device trees ARM: dts: AM33XX: Use existing constants for GPIOs ARM: dts: AM33XX: Specific pinctrl header ARM: dts: AM33XX: Use pinctrl constants ARM: dts: OMAP4/AM35xx: Add missing dtb in the dtbs target ARM: dts: Protect pinctrl headers against multiple inclusions ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED J Keerthy (1): ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes Javier Martinez Canillas (3): ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support ARM: dts: omap3-igep0020: Add NAND flash support ARM: dts: omap3-igep0030: Add NAND flash support Kevin Hilman (3): ARM: dts: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: dts: OMAP3: beagle: enable user button via gpio_keys, enable wakeup ARM: dts: TWL4030: fix mux and wakeup for SYS_NIRQ line Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM Philip Avinash (4): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk Philip, Avinash (1): ARM: dts: AM33XX: Add ELM node Roger Quadros (4): ARM: dts: omap5-uevm: Add USB Host support ARM: dts: omap4-panda: Add USB Host support ARM: dts: omap4-panda: Fix DVI EDID reads ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency Sourav Poddar (1): ARM: dts: omap5-uevm: Add uart pinctrl data Sricharan R (1): ARM: dts: omap5: Make uevm as the official board and deprecate sevm support Suman Anna (1): ARM: dts: OMAP4+: Remove multimedia carveouts Vaibhav Hiremath (7): ARM: dts: AM33XX: Add default pinctrl binding for I2C device ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM ARM: dts: AM33XX: Add default pinctrl binding for UART0 device ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output ARM: AM33XX: clock: Add debugSS clock nodes ARM: AM33XX: clock data: Enable clkout2 as part of init .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/boot/dts/Makefile |8 +- arch/arm/boot/dts/am335x-bone.dts | 118 - arch/arm/boot/dts/am335x-evm.dts | 264 ++-
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.11
On 6/20/2013 2:48 PM, Arnd Bergmann wrote: On Thursday 20 June 2013, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 16:10]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.11. It does contains as well 2 clock data patches, I hope it will not generate any conflict with Paul's tree. Special thanks to Florian for his nice cleanup using the C preprocessor. It's best that Arnd and Olof take this pull request directly as we're getting so close to the merge window. These patches should be pretty much independent of the other branches I've sent, and are needed to keep omap4 booting now that we've flipped the switch for omap4 to be DT only. Would someone provide a merge description for this? I just noticed that it's not a signed tag, and there are lots of patches in it, so I'd rather not have to come up with something myself. What about omap devicetree changes for v3.11 merge window Add mandatory DT support for missing IPs, like USB host, bandgap, LED, NAND, LAN, CPSW, PWM for OMAP and AMXX devices. Introduce new AM43x silicon. Regards, Benoit Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Device Tree for 3.11
On Thursday 20 June 2013, Cousson, Benoit wrote: What about omap devicetree changes for v3.11 merge window Add mandatory DT support for missing IPs, like USB host, bandgap, LED, NAND, LAN, CPSW, PWM for OMAP and AMXX devices. Introduce new AM43x silicon. Thanks, pulled into next/dt now with Tony's Ack. Arnd -- To unsubscribe from this list: send the line unsubscribe 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 v12 04/11] dmaengine: edma: enable build for AM33XX
From: Matt Porter mpor...@ti.com Enable TI EDMA option on OMAP and TI_PRIV_EDMA Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + drivers/dma/Kconfig |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..f91b07f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS select PROC_DEVICETREE if PROC_FS select SOC_BUS select SPARSE_IRQ + select TI_PRIV_EDMA select USE_OF help Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e992489..3215a3c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -213,7 +213,7 @@ config SIRF_DMA config TI_EDMA tristate TI EDMA support - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 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 v12 10/11] ARM: dts: add AM33XX EDMA support
From: Matt Porter m...@ti.com
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d9cad72..3d59bb3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -89,6 +89,18 @@
reg = 0x4820 0x1000;
};
+ edma: edma@4900 {
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ reg = 0x4900 0x1,
+ 0x44e10f90 0x10;
+ interrupts = 12 13 14;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ };
+
gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
--
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 v12 02/11] ARM: edma: Add DT and runtime PM support to the private EDMA API
From: Matt Porter mpor...@ti.com
Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.
Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in [1].
* Split out xbar stuff to separate patch. [1]
* Dropped unused DT helper to convert to array
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
arch/arm/common/edma.c | 180 +---
include/linux/platform_data/edma.h |4 +-
2 files changed, 169 insertions(+), 15 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 7658874..407e01e 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -25,6 +25,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -1369,13 +1376,102 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
-/*---*/
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0, i;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, dma-channels, value);
+ if (ret 0)
+ return ret;
+ pdata-n_channel = value;
+
+ ret = of_property_read_u32(node, ti,edma-regions, value);
+ if (ret 0)
+ return ret;
+ pdata-n_region = value;
+
+ ret = of_property_read_u32(node, ti,edma-slots, value);
+ if (ret 0)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+ pdata-n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata-rsv = rsv_info;
+
+ queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i 3; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i 3; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+
+ pdata-default_queue = 0;
+
+ return ret;
+}
+
+static struct of_dma_filter_info edma_filter_info = {
+ .filter_fn = edma_filter_fn,
+};
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev-dev.platform_data;
- const s8(*queue_priority_mapping)[2];
- const s8(*queue_tc_mapping)[2];
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL};
+ struct edma_soc_infotmpinfo;
+ s8 (*queue_priority_mapping)[2];
+ s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
@@ -1383,17 +1479,56 @@ static int __init edma_probe(struct platform_device
*pdev)
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL};
+ struct resource res[EDMA_MAX_CC];
charres_name[10];
charirq_name[10];
+ struct device_node
[PATCH v12 00/11] DMA Engine support for AM33XX
From: Joel A Fernandes agnel.j...@gmail.com This series is remaining of Matt Porter's EDMA patches for AM33XX EDMA support with changes for few pending review comments on v11 series. Also included are EDMA config and build options for OMAP2PLUS and Davinci by selecting DMADEVICES, and options to enable MMCSD on Davinci (da8xx_omapl). Currently this is required for AM33XX (Beaglebone or EVM) to access MMC and be able mount to rootfs and boot till command prompt over MMC. Unless there are other pending review comments, I hope this series can make it into 3.11 merge window, the dependent series has been posted at [1] and completed review. Tested EDMA on AM1808 EVM and AM33XX Beaglebone with MMC. Sekhar Nori has posted a GIT PULL [1] which has 2 patches this series depends on: [1] http://www.spinics.net/lists/arm-kernel/msg251503.html Changes since v11: - Fixed several style issues and warnings - Broke up the build option patch into smaller ones - Various miscellaneous fixups addressed from v10 feedback Changes since v10: - Reworked documentation based on Arnd's feedback - Moved EDMA bindings documentation earlier in series - Dropped mention on am33xx on 2/8 and 3/8 in the series Changes since v9: - Droped reserved and queue DT entries from Documentation for now from the original patch series. - Drop DT entries that are non-hardware-description - Split EDMA xbar support out of original EDMA DT parsing patch to keep it easier for review. - Rewrite shift and offset calculation xbar event mapping. - Setup default one-to-one mapping for queue_priority and queue_tc mapping as discussed in. - Split out xbar stuff to separate patch. Reference discussion: https://patchwork.kernel.org/patch/2226761/ Changes since v8: - Removed edma node interrupt-parent property, it is inherited Changes since v7: - Dropped dmaengine compat() patch. It is upstream. - Submitted edma_alloc_slot() error checking bug fix separately, now a dependency - Fixed bisect issues due to 3/10 hunks that went into 1/10 - Fixed incorrect IS_ERRVALUE() use in 3/10 Changes since v6: - Converted edma_of_read_*() to wrappers around of_property_read_*() - Fixed wording on the omap-spi generic DMA properties - Added comment/check to clarify that the driver only supports a single EDMA instance when booting from DT Changes since v5: - Dropped mmc portion and moved it to a separate series - Incorporate corrected version of dma_request_slave_channel_compat() - Fix #defines and enablement of TI_PRIV_EDMA option Changes since v4: - Fixed debug section mismatch in private edma api [01/14] - Respun format-patch to catch the platform_data/edma.h rename [01/14] - Removed address/size-cells from the EDMA binding [05/14] Changes since v3: - Rebased on 3.8-rc3 - No longer an RFC - Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia - Restored all the Davinci pdata to const - Removed max_segs hack in favor of using dma_get_channel_caps() - Fixed extra parens, __raw_* accessors and, ioremap error checks in xbar handling - Removed excess license info in platform_data/edma.h - Removed unneeded reserved channels data for AM33xx - Removed test-specific pinmuxing from dts files - Adjusted mmc1 node to be disabled by default in the dtsi Changes since v2: - Rebased on 3.7-rc1 - Fixed bug in DT/pdata parsing first found by Gururaja that turned out to be masked by some toolchains - Dropped unused mach-omap2/devices.c hsmmc patch - Added AM33XX crossbar DMA event mux support - Added am335x-evm support Changes since v1: - Rebased on top of mainline from 12250d8 - Dropped the feature removal schedule patch - Implemented dma_request_slave_channel_compat() and converted the mmc and spi drivers to use it - Dropped unneeded #address-cells and #size-cells from EDMA DT support - Moved private EDMA header to linux/platform_data/ and removed some unneeded definitions - Fixed parsing of optional properties This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.10-rc4. The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so the
[PATCH v12 08/11] spi: omap2-mcspi: add generic DMA request support to the DT binding
From: Matt Porter mpor...@ti.com
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas. The string naming
+ is to be rxN and txN for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = 1;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = 4;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = ti,omap4-mcspi;
+ti,hwmods = mcspi1;
+ti,spi-num-cs = 2;
+dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+dma-names = tx0, rx0, tx1, rx1;
+};
--
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 v12 09/11] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
From: Matt Porter mpor...@ti.com
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 64 -
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 86d2158..ca4ab78 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -830,12 +833,20 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma-dma_rx_sync_dev;
- mcspi_dma-dma_rx = dma_request_channel(mask, omap_dma_filter_fn, sig);
+
+ mcspi_dma-dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+sig, master-dev,
+mcspi_dma-dma_rx_ch_name);
if (!mcspi_dma-dma_rx)
goto no_dma;
sig = mcspi_dma-dma_tx_sync_dev;
- mcspi_dma-dma_tx = dma_request_channel(mask, omap_dma_filter_fn, sig);
+ mcspi_dma-dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+sig, master-dev,
+mcspi_dma-dma_tx_ch_name);
+
if (!mcspi_dma-dma_tx) {
dma_release_channel(mcspi_dma-dma_rx);
mcspi_dma-dma_rx = NULL;
@@ -1256,29 +1267,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i master-num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi-dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi-dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, rx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA RX channel\n);
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, rx%d, i);
+ if (!pdev-dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev,
+ cannot get DMA RX channel\n);
+ status = -ENODEV;
+ break;
+ }
- mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
- sprintf(dma_ch_name, tx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA TX channel\n);
- status = -ENODEV;
- break;
+ mcspi-dma_channels[i].dma_rx_sync_dev =
+ dma_res-start;
}
+ sprintf(dma_tx_ch_name, tx%d, i);
+ if (!pdev-dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev,
+ cannot get DMA TX channel\n);
+ status = -ENODEV;
+ break;
+ }
- mcspi-dma_channels[i].dma_tx_sync_dev = dma_res-start;
+ mcspi-dma_channels[i].dma_tx_sync_dev =
+ dma_res-start;
+ }
}
if (status 0)
--
1.7.9.5
--
To unsubscribe
[PATCH v12 11/11] ARM: dts: add AM33XX SPI DMA support
From: Matt Porter mpor...@ti.com Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 3d59bb3..fb17103 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -361,6 +361,11 @@ interrupts = 65; ti,spi-num-cs = 2; ti,hwmods = spi0; + dmas = edma 16 + edma 17 + edma 18 + edma 19; + dma-names = tx0, rx0, tx1, rx1; status = disabled; }; @@ -372,6 +377,11 @@ interrupts = 125; ti,spi-num-cs = 2; ti,hwmods = spi1; + dmas = edma 42 + edma 43 + edma 44 + edma 45; + dma-names = tx0, rx0, tx1, rx1; 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
[PATCH v12 05/11] edma: config: Enable config options for EDMA
From: Joel A Fernandes agnel.j...@gmail.com Build TI_EDMA by default for ARCH_DAVINCI and ARCH_OMAP2PLUS Signed-off-by: Joel A Fernandes joelag...@ti.com --- arch/arm/Kconfig|1 + arch/arm/mach-omap2/Kconfig |1 + drivers/dma/Kconfig |2 +- 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b1c66a4..7d58cd9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -841,6 +841,7 @@ config ARCH_DAVINCI select HAVE_IDE select NEED_MACH_GPIO_H select TI_PRIV_EDMA + select DMADEVICES select USE_OF select ZONE_DMA help diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f91b07f..c02f083 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS select PROC_DEVICETREE if PROC_FS select SOC_BUS select SPARSE_IRQ + select DMADEVICES select TI_PRIV_EDMA select USE_OF help diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 3215a3c..b2d6f15 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -216,7 +216,7 @@ config TI_EDMA depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS - default n + default y help Enable support for the TI EDMA controller. This DMA engine is found on TI DaVinci and AM33xx parts. -- 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 v12 07/11] ARM: davinci: Fix compiler warnings in devices-da8xx
From: Joel A Fernandes agnel.j...@gmail.com
queue_priority_mapping and queue_tc_mapping are no longer
const anymore generating a bunch of warnings in devices-da8xx.
Fix them by not doing constant assignments.
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..eb254fe 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -105,27 +105,27 @@ struct platform_device da8xx_serial_device = {
},
};
-static const s8 da8xx_queue_tc_mapping[][2] = {
+static s8 da8xx_queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
{0, 0},
{1, 1},
{-1, -1}
};
-static const s8 da8xx_queue_priority_mapping[][2] = {
+static s8 da8xx_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
{1, 7},
{-1, -1}
};
-static const s8 da850_queue_tc_mapping[][2] = {
+static s8 da850_queue_tc_mapping[][2] = {
/* {event queue no, TC no} */
{0, 0},
{-1, -1}
};
-static const s8 da850_queue_priority_mapping[][2] = {
+static s8 da850_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
{-1, -1}
--
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 v12 01/11] dmaengine: edma: Add TI EDMA device tree binding
From: Matt Porter m...@ti.com
The binding definition is based on the generic DMA controller
binding.
Joel:
* Droped reserved and queue DT entries from Documentation
for now from the original patch series (v10)
* Included properties in Documentation and clarified DMA properties (V11)
* Made ti,hwmod option
* Clarified DMA entries
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Matt Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 34 +
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..9fbbdb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,34 @@
+TI EDMA
+
+Required properties:
+- compatible : ti,edma3
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- #dma-cells: Should be set to 1
+ Clients should use a single channel number per DMA request.
+- dma-channels: Specify total DMA channels per CC
+- reg: Memory map for accessing module
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Exactly 3 interrupts need to be specified in the order:
+ 1. Transfer completion interrupt.
+ 2. Memory protection interrupt.
+ 3. Error interrupt.
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = 0x4900 0x1;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ ti,edma-xbar-event-map = 1 12
+ 2 13;
+};
--
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 v12 03/11] ARM: edma: Add EDMA crossbar event mux support
From: Matt Porter mpor...@ti.com
Changes by Joel:
* Split EDMA xbar support out of original EDMA DT parsing patch
to keep it easier for review.
* Rewrite shift and offset calculation.
Suggested-by: Sekhar Nori nsek...@ti.com
Suggested by: Andy Shevchenko andy.shevche...@gmail.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Reference:
[1] https://patchwork.kernel.org/patch/2226991/
---
arch/arm/common/edma.c | 62 +++-
include/linux/platform_data/edma.h |1 +
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 407e01e..a03d4f0 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -568,7 +568,7 @@ static int prepare_unused_channel_list(struct device *dev,
void *data)
(int)pdev-resource[i].start = 0) {
ctlr = EDMA_CTLR(pdev-resource[i].start);
clear_bit(EDMA_CHAN_SLOT(pdev-resource[i].start),
- edma_cc[ctlr]-edma_unused);
+ edma_cc[ctlr]-edma_unused);
}
}
@@ -1393,6 +1393,52 @@ static int edma_of_read_u32_to_s16_array(const struct
device_node *np,
return 0;
}
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void __iomem *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, res);
+ if (ret)
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ ti,edma-xbar-event-map,
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (ret)
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] 0x03) 3;
+ offset = xbar_chans[i][1] 0xfffc;
+ mux = readl(xbar + offset);
+ mux = ~(0xff shift);
+ mux |= xbar_chans[i][0] shift;
+ writel(mux, (xbar + offset));
+ }
+
+ pdata-xbar_chans = xbar_chans;
+
+ return 0;
+}
+
static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
@@ -1458,6 +1504,10 @@ static int edma_of_parse_dt(struct device *dev,
pdata-default_queue = 0;
+ prop = of_find_property(node, ti,edma-xbar-event-map, sz);
+ if (prop)
+ ret = edma_xbar_event_map(dev, node, pdata, sz);
+
return ret;
}
@@ -1476,6 +1526,7 @@ static int edma_probe(struct platform_device *pdev)
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL};
@@ -1591,6 +1642,15 @@ static int edma_probe(struct platform_device *pdev)
}
}
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]-xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]-edma_unused);
+ }
+ }
if (node) {
irq[j] = irq_of_parse_and_map(node, 0);
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 317f2be..57300fd 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -177,6 +177,7 @@ struct edma_soc_info {
s8 (*queue_tc_mapping)[2];
s8 (*queue_priority_mapping)[2];
+ const s16 (*xbar_chans)[2];
};
#endif
--
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 v12 06/11] da8xx: config: Enable MMC and FS options
From: Joel A Fernandes agnel.j...@gmail.com Required to get OMAP-L1 EVM access MMC and mount rootfs Signed-off-by: Joel A Fernandes joelag...@ti.com --- arch/arm/configs/da8xx_omapl_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig index 7c86813..35919ca 100644 --- a/arch/arm/configs/da8xx_omapl_defconfig +++ b/arch/arm/configs/da8xx_omapl_defconfig @@ -104,6 +104,7 @@ CONFIG_SND_DAVINCI_SOC=m # CONFIG_USB_SUPPORT is not set CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y +CONFIG_EXT4_FS=y CONFIG_XFS_FS=m CONFIG_INOTIFY=y CONFIG_AUTOFS4_FS=m @@ -135,3 +136,5 @@ CONFIG_DEBUG_ERRORS=y # CONFIG_CRYPTO_HW is not set CONFIG_CRC_CCITT=m CONFIG_CRC_T10DIF=m +CONFIG_MMC=y +CONFIG_MMC_DAVINCI=y -- 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: [RFC PATCH] regulator: core: allow consumers to request to closes step voltage
On 07:45-20130620, Nishanth Menon wrote:
On 23:38-20130619, Mark Brown wrote:
On Wed, Jun 19, 2013 at 02:17:54PM -0500, Nishanth Menon wrote:
Account for step size accuracy when exact voltage requests are send for
step based regulators.
If the consumer can tolerate a different voltage why not just request
the range that can be tolerated? Your problem here is specifying an
exact voltage.
I think you mean using regulator_get_linear_step
The specific example I faced was using cpufreq-cpu0 driver with voltages
for OPPs for MPU rail and attempting the common definitions against
voltages
that are non-exact multiples of stepsize of PMIC.
The alternative would be implement custom set_voltage (as againsta simpler
set_voltage_sel and using linear map/list functions) for the regulator
which
will account for the same.
Yet another alternative might be to introduce yet another custom function
similar
to regulator_set_voltage_tol which accounts for this. something like:
regulator_set_voltage_floor(regulator, voltage, tol) or something to that
effect.
Or as I keep telling you guys the consumer can just do that directly
using the existing API; the whole point in specifying the voltage as a
range is to allow the consumer to cope with arbatrary regulators by
giving a range of voltages that it can accept.
The API is deliberately very conservative in these matters since there
is a danger of physical damage if things really go wrong in some
applications, it makes sure that both the drivers and the system
integration are involved.
I agree. The intent of this series was to start a conversation to see if
we can make it simpler.
Searching for the users of regulator_get_linear_step in 3.10-rc6
shows none.
For a generic driver which needs to handle platforms which
have tolerance, they'd use regulator_set_voltage_tol. But the
implementation would allow for uV - tol to uV + tol as range, which in
the case I mentioned(min voltage =uV) wont work.
If the consumer wants to be aware of linear step regulator, they'd have to do:
step_uV = regulator_get_linear_step(...);
regulator_set_voltage(uV, uV + step_uV);
Then this wont handle tolerance. So the solution seems to be (for the
consumer):
step_uV = regulator_get_linear_step(...);
..
if (tol)
regulator_set_voltage_tol(uV, tol);
else
regulator_set_voltage(uV, uV + step_uV);
(with the required error checks for regulator being a linear regulator
etc..).
At least to me, there is no sane manner to handle tolerance and linear step
accuracy for a defined voltage (Should tolerance be rounded off to
step_uV? what about the border cases etc.)
Would you agree?
Here is an RFC for the same. My hope was to see if something simpler
could be done.
From cb9830191cb9b8021e50bcda25d110b4b9a7dbd3 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Thu, 20 Jun 2013 16:37:30 -0500
Subject: [RFC PATCH] cpufreq: cpufreq-cpu0: account for regulator step size
accuracy
Generic regulator consumers such as cpufreq-cpu0 are not aware
of the characteristics of regulator used to supply. For example:
consumerX requests for voltage min_uV = 500mV, max_uV = 500mV
On a regulator which has a step size of 10mV, this can be exactly
achieved.
However, on a regulator which is non-exact divider step size (example
12.66mV step size), the closest achievable would be 506.4.
regulator_set_voltage_tol does not work out either as 500mV is not an
acceptable operational voltage.
Account for step size accuracy when exact voltage requests are send for
step based regulators.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/cpufreq/cpufreq-cpu0.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..707565c 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -28,6 +28,7 @@ static struct device *cpu_dev;
static struct clk *cpu_clk;
static struct regulator *cpu_reg;
static struct cpufreq_frequency_table *freq_table;
+static int cpu_reg_step_size;
static int cpu0_verify_speed(struct cpufreq_policy *policy)
{
@@ -91,7 +92,12 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
/* scaling up? scale voltage before frequency */
if (cpu_reg freqs.new freqs.old) {
- ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ if (tol)
+ ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ else
+ ret = regulator_set_voltage(cpu_reg, volt,
+ volt + cpu_reg_step_size);
+
if (ret) {
pr_err(failed to scale voltage up: %d\n, ret);
freqs.new = freqs.old;
@@ -102,15 +108,28 @@ static int cpu0_set_target(struct
Re: [PATCH 2/3] mailbox/omap: add support for parsing dt devices
Hi Suman,
On 6/18/2013 5:34 PM, Suman Anna wrote:
Logic has been added to the OMAP2+ mailbox code to
parse the mailbox dt nodes and construct the different
mailboxes associated with the instance. The design is
based on gathering the same information that was being
passed previously through the platform data, except for
the interrupt type configuration information.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 46 +++
drivers/mailbox/mailbox-omap2.c| 141 ++---
2 files changed, 172 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 000..913bc13
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,46 @@
+OMAP2+ Mailbox Driver
+
+Required properties:
+- compatible: Should be one of the following,
+ ti,omap2-mailbox for
+ OMAP2420, OMAP2430, OMAP3430, OMAP3630 SoCs
+ ti,omap4-mailbox for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the mailbox register address range (base
address
+ and length)
+- interrupts: Contains the interrupt information for the mailbox
+ device. The format is dependent on which interrupt
+ controller the OMAP device uses
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device
+ can interrupt
+- ti,mbox-num-fifos: Number of h/w fifos within the mailbox device
+- #ti,mbox-data-cells: Cell size for describing a mailbox
+ (currently should be 4)
+- ti,mbox-names: Array of the names of the mailboxes
+- ti,mbox-data:Mailbox descriptor data private to each
mailbox. The 4
+ cells represent the following data,
+ Cell #1 (tx_id) - mailbox fifo id used for
+ transmitting messages
+ Cell #2 (rx_id) - mailbox fifo id on which messages
+ are received
+ Cell #3 (irq_id) - irq identifier index number to use
+ from the interrupts data
+ Cell #4 (usr_id) - mailbox user id for identifying the
+ interrupt into the MPU interrupt
+ controller.
+
+Example:
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 3;
+ ti,mbox-num-fifos = 8;
+ #ti,mbox-data-cells = 4
+ ti,mbox-names = mbox-ipu, mbox-dsp;
+ ti,mbox-data = 0 1 0 0, 3 2 0 0;
That seems to contain a bunch of low level IP internal information.
Cannot you figure out that from the MAILBOX_REVISION information?
mbox-names belong here because it does describe the connection outside
the IP, but I'm not sure all the other data should be there.
You should put in DT the minimal amount of data that are needed be the
driver to figure out the rest.
Please note that I did not check carefully every OMAP specs to see if
this is possible or not, but most of the time we can reduce the amount
of information thanks to some HW info already there.
Regards,
Benoit
+};
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 6c0687c..3fe08de 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -14,6 +14,7 @@
#include linux/slab.h
#include linux/clk.h
#include linux/err.h
+#include linux/of_device.h
#include linux/platform_device.h
#include linux/io.h
#include linux/pm_runtime.h
@@ -222,6 +223,21 @@ static struct omap_mbox_ops omap2_mbox_ops = {
.restore_ctx= omap2_mbox_restore_ctx,
};
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = ti,omap2-mailbox,
+ .data = (void *) MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap4-mailbox,
+ .data = (void *) MBOX_INTR_CFG_TYPE2,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -229,47 +245,138 @@ static int omap2_mbox_probe(struct platform_device
Re: [PATCH 3/3] ARM: dts: OMAP2+: Add mailbox nodes
On 6/18/2013 5:35 PM, Suman Anna wrote:
The mailbox DT node data has been added for OMAP2420,
OMAP2430, OMAP3430/OMAP3630, OMAP44xx devices. Data for
OMAP5 is skipped for now since the corresponding hwmod
entry is not present.
The mailbox static device initialization logic is also
adjusted for a DT boot.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 13 +
arch/arm/boot/dts/omap2430.dtsi | 12
arch/arm/boot/dts/omap3.dtsi| 12
arch/arm/boot/dts/omap4.dtsi| 12
arch/arm/mach-omap2/devices.c | 2 +-
5 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index c8f9c55..e0f4e47 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -114,6 +114,19 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26, /* DSP Interrupt */
+34; /* IVA Interrupt */
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 6;
+ #ti,mbox-data-cells = 4;
If this is always 4, why do you want to expose that?
BTW, I guess that most of these attribute are generic enough to avoid
the ti, prefix.
Benoit
+ ti,mbox-names = dsp, iva;
+ ti,mbox-data = 0 1 0 0, 2 3 1 3;
+ };
+
timer1: timer@48028000 {
compatible = ti,omap2420-timer;
reg = 0x48028000 0x400;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c535a5a..b413423 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -175,6 +175,18 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 6;
+ #ti,mbox-data-cells = 4;
+ ti,mbox-names = dsp;
+ ti,mbox-data = 0 1 0 0;
+ };
+
timer1: timer@49018000 {
compatible = ti,omap2420-timer;
reg = 0x49018000 0x400;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6d05ee0..3cc7c28 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -380,6 +380,18 @@
dma-names = tx, rx;
};
+ mailbox: mailbox@48094000 {
+ compatible = ti,omap2-mailbox;
+ reg = 0x48094000 0x200;
+ interrupts = 26;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 2;
+ ti,mbox-num-fifos = 2;
+ #ti,mbox-data-cells = 4;
+ ti,mbox-names = dsp;
+ ti,mbox-data = 0 1 0 0;
+ };
+
timer1: timer@48318000 {
compatible = ti,omap3430-timer;
reg = 0x48318000 0x400;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 463b97d..0155182 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -516,6 +516,18 @@
};
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 3;
+ ti,mbox-num-fifos = 8;
+ #ti,mbox-data-cells = 4;
+ ti,mbox-names = mbox-ipu, mbox-dsp;
+ ti,mbox-data = 0 1 0 0, 3 2 0 0;
+ };
+
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 73762ac..2058f24 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -655,11 +655,11 @@ static int __init omap2_init_devices(void)
omap_init_audio();
omap_init_camera();
omap_init_hdmi_audio();
- omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt())
Re: [PATCH 2/3] mailbox/omap: add support for parsing dt devices
Hi Benoit,
On 06/20/2013 04:45 PM, Cousson, Benoit wrote:
Hi Suman,
On 6/18/2013 5:34 PM, Suman Anna wrote:
Logic has been added to the OMAP2+ mailbox code to
parse the mailbox dt nodes and construct the different
mailboxes associated with the instance. The design is
based on gathering the same information that was being
passed previously through the platform data, except for
the interrupt type configuration information.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 46 +++
drivers/mailbox/mailbox-omap2.c| 141
++---
2 files changed, 172 insertions(+), 15 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
diff --git
a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
new file mode 100644
index 000..913bc13
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -0,0 +1,46 @@
+OMAP2+ Mailbox Driver
+
+Required properties:
+- compatible:Should be one of the following,
+ti,omap2-mailbox for
+OMAP2420, OMAP2430, OMAP3430, OMAP3630 SoCs
+ti,omap4-mailbox for
+OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg:Contains the mailbox register address range (base
address
+and length)
+- interrupts: Contains the interrupt information for the mailbox
+device. The format is dependent on which interrupt
+controller the OMAP device uses
+- ti,hwmods:Name of the hwmod associated with the mailbox
+- ti,mbox-num-users:Number of targets (processor devices) that
the mailbox device
+can interrupt
+- ti,mbox-num-fifos:Number of h/w fifos within the mailbox device
+- #ti,mbox-data-cells:Cell size for describing a mailbox
+(currently should be 4)
+- ti,mbox-names:Array of the names of the mailboxes
+- ti,mbox-data:Mailbox descriptor data private to each
mailbox. The 4
+cells represent the following data,
+ Cell #1 (tx_id) - mailbox fifo id used for
+transmitting messages
+ Cell #2 (rx_id) - mailbox fifo id on which messages
+are received
+ Cell #3 (irq_id) - irq identifier index number to use
+from the interrupts data
+ Cell #4 (usr_id) - mailbox user id for identifying the
+interrupt into the MPU interrupt
+controller.
+
+Example:
+
+/* OMAP4 */
+mailbox: mailbox@4a0f4000 {
+compatible = ti,omap4-mailbox;
+reg = 0x4a0f4000 0x200;
+interrupts = GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH;
+ti,hwmods = mailbox;
+ti,mbox-num-users = 3;
+ti,mbox-num-fifos = 8;
+#ti,mbox-data-cells = 4
+ti,mbox-names = mbox-ipu, mbox-dsp;
+ti,mbox-data = 0 1 0 0, 3 2 0 0;
That seems to contain a bunch of low level IP internal information.
Cannot you figure out that from the MAILBOX_REVISION information?
Nope, unfortunately the MAILBOX_REVISION [1] is not enough. It was only
tracking the IP revision, but the number of users and fifos for example
are parameters of the IP, so there are no separate registers from which
this info can be gleaned. I could probably move the ti,mbox-num-users
and ti,mbox-num-fifos into the driver and add it as part of match data
like the intr_type configuration value, but that would mean I would have
to make more compatible strings (possibly one per generation). That
approach however would not scale well for DRA7xx where there is mixture
of different instances with different users and fifos. Since these are
h/w configuration values, I chose to put them in DT.
regards
Suman
[1] http://marc.info/?l=linux-omapm=137097093615538w=2
mbox-names belong here because it does describe the connection outside
the IP, but I'm not sure all the other data should be there.
You should put in DT the minimal amount of data that are needed be the
driver to figure out the rest.
Please note that I did not check carefully every OMAP specs to see if
this is possible or not, but most of the time we can reduce the amount
of information thanks to some HW info already there.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: OMAP2+: Add mailbox nodes
Hi Benoit,
On 06/20/2013 04:57 PM, Cousson, Benoit wrote:
On 6/18/2013 5:35 PM, Suman Anna wrote:
The mailbox DT node data has been added for OMAP2420,
OMAP2430, OMAP3430/OMAP3630, OMAP44xx devices. Data for
OMAP5 is skipped for now since the corresponding hwmod
entry is not present.
The mailbox static device initialization logic is also
adjusted for a DT boot.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 13 +
arch/arm/boot/dts/omap2430.dtsi | 12
arch/arm/boot/dts/omap3.dtsi| 12
arch/arm/boot/dts/omap4.dtsi| 12
arch/arm/mach-omap2/devices.c | 2 +-
5 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap2420.dtsi
b/arch/arm/boot/dts/omap2420.dtsi
index c8f9c55..e0f4e47 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -114,6 +114,19 @@
dma-names = tx, rx;
};
+mailbox: mailbox@48094000 {
+compatible = ti,omap2-mailbox;
+reg = 0x48094000 0x200;
+interrupts = 26, /* DSP Interrupt */
+ 34; /* IVA Interrupt */
+ti,hwmods = mailbox;
+ti,mbox-num-users = 4;
+ti,mbox-num-fifos = 6;
+#ti,mbox-data-cells = 4;
If this is always 4, why do you want to expose that?
I have followed the example of interrupt-cells here, as it indicates the
length that each mbox-data should have. If you do think that it doesn't
belong here, I can remove this and do the check directly in the driver,
and update the DT binding accordingly.
BTW, I guess that most of these attribute are generic enough to avoid
the ti, prefix.
Since these are specific attributes needed for describing the data for
TI mailboxes, I used the ti,' prefix so that it won't clash with other
SoCs.
regards
Suman
Benoit
+ti,mbox-names = dsp, iva;
+ti,mbox-data = 0 1 0 0, 2 3 1 3;
+};
+
timer1: timer@48028000 {
compatible = ti,omap2420-timer;
reg = 0x48028000 0x400;
diff --git a/arch/arm/boot/dts/omap2430.dtsi
b/arch/arm/boot/dts/omap2430.dtsi
index c535a5a..b413423 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -175,6 +175,18 @@
dma-names = tx, rx;
};
+mailbox: mailbox@48094000 {
+compatible = ti,omap2-mailbox;
+reg = 0x48094000 0x200;
+interrupts = 26;
+ti,hwmods = mailbox;
+ti,mbox-num-users = 4;
+ti,mbox-num-fifos = 6;
+#ti,mbox-data-cells = 4;
+ti,mbox-names = dsp;
+ti,mbox-data = 0 1 0 0;
+};
+
timer1: timer@49018000 {
compatible = ti,omap2420-timer;
reg = 0x49018000 0x400;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6d05ee0..3cc7c28 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -380,6 +380,18 @@
dma-names = tx, rx;
};
+mailbox: mailbox@48094000 {
+compatible = ti,omap2-mailbox;
+reg = 0x48094000 0x200;
+interrupts = 26;
+ti,hwmods = mailbox;
+ti,mbox-num-users = 2;
+ti,mbox-num-fifos = 2;
+#ti,mbox-data-cells = 4;
+ti,mbox-names = dsp;
+ti,mbox-data = 0 1 0 0;
+};
+
timer1: timer@48318000 {
compatible = ti,omap3430-timer;
reg = 0x48318000 0x400;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 463b97d..0155182 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -516,6 +516,18 @@
};
};
+mailbox: mailbox@4a0f4000 {
+compatible = ti,omap4-mailbox;
+reg = 0x4a0f4000 0x200;
+interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
+ti,hwmods = mailbox;
+ti,mbox-num-users = 3;
+ti,mbox-num-fifos = 8;
+#ti,mbox-data-cells = 4;
+ti,mbox-names = mbox-ipu, mbox-dsp;
+ti,mbox-data = 0 1 0 0, 3 2 0 0;
+};
+
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 73762ac..2058f24 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -655,11 +655,11 @@ static int __init omap2_init_devices(void)
omap_init_audio();
omap_init_camera();
omap_init_hdmi_audio();
-omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
omap_init_control_usb();
RE: [GIT PULL 7/7] omap mailbox move to drivers for v3.11 merge window
Arnd, On Tuesday 18 June 2013, Tony Lindgren wrote: The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap- for-v3.11/mailbox-signed for you to fetch changes up to d2e993289cc5f1780ce74188e3a8d2b404748397: Merge tag 'omap-mailbox-for-v3.11' of git://github.com/sumananna/mailbox into omap-for-v3.11/mailbox (2013-06-17 03:51:54 -0700) Move OMAP Mailbox framework to drivers via Suman Anna s-a...@ti.com The OMAP Mailbox driver framework is moved out of arch/arm folder into drivers/mailbox folder, to re-enable building it and also serve as a baseline for adapting to the new mailbox driver framework. The changes mainly contain: - a minor bug fix and cleanup of mach-specific mailbox code - remove any header dependencies from plat-omap for multi-platform support - represent mailbox device data through platform data/hwmod attrs - move the omap mailbox code out of plat-omap/mach-omapX to drivers/mailbox folder I've pulled this into next/drivers as well, rather than a separate branch that we had for 3.10 (and dropped). I am a bit puzzled about this series though. Is it right that for 3.10 we had plans for a generic subsystem, and now it's just the omap drivers? Yes, we still have a plan for a generic subsystem, and these would form the the base patches of OMAP adaptation towards that. OMAP mailbox was disabled since couple of releases now because of the multi-platform enablement. There were couple of different work-items needed on OMAP mailbox like fixing the multi-platform, converting to DT and adapting to the new framework. The previous subsystem was derived of the OMAP mailbox, so the first and last items were kinda automatic. The newest one based on Jassi's work is not gonna reuse any OMAP stuff, so this series handles the first one to avoid a huge pending patchset for OMAP on the generic framework finalization. Regards Suman
Re: [PATCHv2 02/11] CLK: use of_property_read_u32 instead of read_u8
On Wed, Jun 19, 2013 at 6:18 AM, Tero Kristo t-kri...@ti.com wrote:
of_property_read_u8 does not work properly because of endianess problem
with its current implementation, and this causes it to always return
0 with little endian architectures. Instead, use property_read_u32
until this is fixed.
Tero,
Thanks for the fix. Heiko Stubner pointed out to me that in order to
read a u8 value the DT node needs to specify /bits/ 8 before the
values. From the of_property_read_u8_array kerneldoc:
/**
...
* dts entry of array should be like:
* property = /bits/ 8 0x50 0x60 0x70;
*
* The out_value is modified only if a valid u8 value can be decoded.
*/
Still I think it is a bit silly to have to do this in all of the
bindings, so I'm going to roll this patch into my next version of the
series if only for the sake of readability. Not only that but it is
slightly more future proof for the binding to use a u32 value. The
fact that the implementation in Linux uses a u8 is of little
consequence to the binding. I'll also add a cast like the following
to your patch:
clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, (u8) bit_idx,
clk_gate_flags, NULL);
Thanks,
Mike
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c |4 ++--
drivers/clk/clk-gate.c|4 ++--
drivers/clk/clk-mux.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 17ea475..3413602 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -361,7 +361,7 @@ void of_divider_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_divider_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
struct clk_div_table *table;
of_property_read_string(node, clock-output-names, clk_name);
@@ -375,7 +375,7 @@ void of_divider_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 72cf99d..61b4dc1 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -162,7 +162,7 @@ void of_gate_clk_setup(struct device_node *node)
void __iomem *reg;
const char *parent_name;
u8 clk_gate_flags = 0;
- u8 bit_idx = 0;
+ u32 bit_idx = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -170,7 +170,7 @@ void of_gate_clk_setup(struct device_node *node)
reg = of_iomap(node, 0);
- if (of_property_read_u8(node, bit-shift, bit_idx)) {
+ if (of_property_read_u32(node, bit-shift, bit_idx)) {
pr_err(%s: missing bit-shift property for %s\n,
__func__, node-name);
return;
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c9f9f32..e63dd1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -170,7 +170,7 @@ void of_mux_clk_setup(struct device_node *node)
int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -194,7 +194,7 @@ void of_mux_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
--
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: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 06/19/13 06:19, Tero Kristo wrote:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..70608db 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -106,6 +106,8 @@
ti,hwmods = counter_32k;
};
+ /include/ omap4-clocks.dtsi
+
Doesn't this cause one platform device to be allocated for each clock
node defined in omap4-clocks.dtsi? Are you concerned about wasting
memory on things that aren't really devices and that will never be probed?
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe 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/1] gpio/omap: auto request GPIO as input if used as IRQ via DT
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drives should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just request the IRQ and this has to
be handled by the irq_chip driver.
With the current OMAP GPIO DT binding, if we define:
gpio6: gpio@49058000 {
compatible = ti,omap3-gpio;
reg = 0x49058000 0x200;
interrupts = 34;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
};
interrupt-parent = gpio6;
interrupts = 16 8;
The GPIO is correctly mapped as an IRQ but a call to gpio_request()
is never made. So, let's add a custom .map function handler that
setups and configures the GPIO as input automatically.
Many thanks to Jon Hunter and Grant Likely for their feedback and
suggestions on how to solve this.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
NOTE: Ideally this has to be handled by the IRQ core instead
each irq_chip driver implementing a custom .map or .xlate
function handler. There are some work-in-progress to add this
logic to the core but until this general solution gets into
mainline let's add this temporary solution that can be later
reverted when is not needed anymore.
Tested on a OMAP3 DM3735 board (IGEPv2) to make its smsc911x
LAN chip to work with DeviceTree booting.
drivers/gpio/gpio-omap.c | 29 -
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d3f7d2d..b3e5f75 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1086,6 +1086,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
static const struct of_device_id omap_gpio_match[];
+static int omap_gpio_irq_map(struct irq_domain *d, unsigned int virq,
+irq_hw_number_t hwirq)
+{
+ struct gpio_bank *bank = d-host_data;
+ int gpio;
+ int ret;
+
+ if (!bank)
+ return -EINVAL;
+
+ gpio = irq_to_gpio(bank, hwirq);
+
+ ret = gpio_request_one(gpio, GPIOF_IN, NULL);
+
+ if (ret) {
+ dev_err(bank-dev, Could not request GPIO%d\n, gpio);
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct irq_domain_ops omap_gpio_irq_ops = {
+ .xlate = irq_domain_xlate_onetwocell,
+ .map= omap_gpio_irq_map,
+};
+
static int omap_gpio_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -1137,7 +1164,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-domain = irq_domain_add_linear(node, bank-width,
-irq_domain_simple_ops, NULL);
+omap_gpio_irq_ops, bank);
if (!bank-domain)
return -ENODEV;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
