Re: [PATCH 1/3] misc: Add crossbar driver
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote: Since the cross-bar is not limited t0 IRQ lines and applicable for DMA request lines as well, making it IRQ chip doesn't make sense. Its not typical pin control functionality either but at least that framework is much closer to consider as an option. Actually its more of setting up the IRQ and DMA pins maps once at boot for a given SOC based on chosen configuration by the board. So I am leaning towards pinctrl as well. Just haven't thought enough about whether thats the best approach. CC'ing Linus W and Tony L whether we can use pinctrl framework for such an IP and if yes how ;-). If it really muxes signals then using pinctrl seems logical. Especially if the registers are in the SCM block. It might be already possible to handle it already with pinctrl-single,bits for the muxing part. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/15] ARM: OMAP: USB: Add phy binding information
* Kishon Vijay Abraham I kis...@ti.com [130717 23:53]:
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
include/linux/usb/musb.h |3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..6aa7cbf 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
+ if (cpu_is_omap34xx())
+ musb_plat.phy_label = twl4030;
+
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
I don't think there's a USB PHY on non-twl4030 chips, so this should
be OK:
Acked-by: Tony Lindgren t...@atomide.com
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
/* for clk_get() */
const char *clock;
+ /* phy label */
+ const char *phy_label;
+
/* (HOST or OTG) switch VBUS on/off */
int (*set_vbus)(struct device *dev, int is_on);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 05/15] ARM: dts: omap: update usb_otg_hs data
* Kishon Vijay Abraham I kis...@ti.com [130717 23:53]:
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
In general the .dts changes should be separate to avoid pointless
merge conflicts. But sounds like things will stop working for
USB unless we do it like this so:
Acked-by: Tony Lindgren t...@atomide.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
Documentation/devicetree/bindings/usb/usb-phy.txt |6 ++
arch/arm/boot/dts/omap3-beagle-xm.dts |2 ++
arch/arm/boot/dts/omap3-evm.dts|2 ++
arch/arm/boot/dts/omap3-overo.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |3 +++
arch/arm/boot/dts/twl4030.dtsi |1 +
7 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply up to
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num-eps = 16;
ram-bits = 12;
ctrl-module = omap_control_usb;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
};
Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be ti,omap-usb2
- reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7
Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
* Grygorii Strashko grygorii.stras...@ti.com [130717 09:48]: Hi, On 07/17/2013 06:32 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Add dynamic active/idle pin states for uart3/4 which will be applied when uart3/4 state is switched from active to idle and back by Runtime PM or during system suspend. This is good for testing code, but should not be merged because omap4 has the iopad wake-ups available for uarts. So those can be always enabled. In this case, 2 IRQ will be received per each UART RX event - one from PRCM and from UART - and that's not good from PM perspective (It will affect on CPUIdle and CPUFreq at least). Oh I see, that's because I accidentally left the debug code enabled to make it easier to test the wake-up events without having to have working off-idle. The wake flags can be kept on always for sure. The patch below should sort out the issue of getting wake-up interrupts during runtime as long as you don't have DEBUG defined. Regards, Tony --- a/drivers/pinctrl/pinctrl-single-omap.c +++ b/drivers/pinctrl/pinctrl-single-omap.c @@ -140,9 +140,17 @@ static irqreturn_t pcs_omap_handle_irq(int irq, void *data) if ((val OMAP_WAKEUP_EVENT_MASK) == OMAP_WAKEUP_EVENT_MASK) generic_handle_irq(wakeirq); } - +#ifdef DEBUG + /* +* This enables wake-up interrupts during runtime also +* causing duplicate interrupts. But it also makes debugging +* the wake-up events easy as deeper idle states often are +* not working for new devices while the drivers are being +* developed. +*/ if (pcso-reconfigure_io_chain) pcso-reconfigure_io_chain(); +#endif return IRQ_HANDLED; } ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
* Grygorii Strashko grygorii.stras...@ti.com [130717 10:11]: On 07/17/2013 06:38 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod framework. After switching to DT-boot the pinctrl handling was dropped from hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html) But this is not right for OMAP2+ SoC where real IPs state is controlled by omap_device core which enables/disables modules clocks actually. I'm not convinced we should try to handle this in a generic way as only some devices need dynamic remuxing of some pins. For example, if OMAP I2C driver will handle pinctrl state during system wide suspend the following issue may occure: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) And in this example you are assuming that you need separate idle and sleep states, which is not true at least for most cases I've seen. I don't need both states (at least right now) :), but - if any OMAP2+ driver will have two states defined: idle and sleep - and if it will try to manage them from drivers callbacks only using pure calls to pinctrl_pm_select_xx() helpers the idle state will be selected during suspend and *not* sleep. But the drivers have separate calls for runtime PM and suspend/resume? It is possible that am33xx needs separate idle and sleep states, but most likely only for some pins. For omap[345] we can get away with just the default state for most cases. In case, if only default state is defined for device - nothing will be done by OMAP device framework for it (I mean any call to pinctrl_pm_select_xx() will do nothing - it just checks that there is no state and returns 0). If we want to automate something, it should be done at Linux generic level rather than at omap bus level. That sort of relates to drivers needing to know when they've lost context too, which should be implemented in Linux generic way. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
* Grygorii Strashko grygorii.stras...@ti.com [130718 02:01]: On 07/18/2013 11:09 AM, Tony Lindgren wrote: Don't think it's debug code - IO chain need to be rearmed after each PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on OMAP4, OMAP5 requires more complex handling(( ). Nope, only after the mux register changes. I've verified it on am3730 with off-idle for both serial and wl12xx. I didn't pick up your padconf patches yet -seems i need to be in sync :) Well you need those for proper wake-up event support.. Below the diff I used to verify IO wake up (It follows old IO daisy chain hanlding models in hwmod before DT): ..then these changes not needed with the pinctrl-single changes. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] ARM: dts: omap4-sdp: add dynamic pin states for uart3/4
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Add dynamic active/idle pin states for uart3/4 which will be applied when uart3/4 state is switched from active to idle and back by Runtime PM or during system suspend. This is good for testing code, but should not be merged because omap4 has the iopad wake-ups available for uarts. So those can be always enabled. --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -181,18 +181,40 @@ pinctrl-single,pins = 0x100 (PIN_INPUT_PULLUP | MUX_MODE0)/* uart3_cts_rctx.uart3_cts_rctx */ 0x102 (PIN_OUTPUT | MUX_MODE0) /* uart3_rts_sd.uart3_rts_sd */ - 0x104 (PIN_INPUT | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ 0x106 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */ ; }; This just need to become: pinctrl-single,pins = ... 0x104 (WAKEUP_EN | PIN_INPUT_MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ ... ; interrupts = GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH; }; And so on. For am33xx you need to remux things to GPIO for the wake-up events, so you should maybe test on that instead. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: OMAP2+: omap_device: add pinctrl handling
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod framework. After switching to DT-boot the pinctrl handling was dropped from hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated to handle pinctrl states by itself using pinctrl_pm_select_xx() helpers (see http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html) But this is not right for OMAP2+ SoC where real IPs state is controlled by omap_device core which enables/disables modules clocks actually. I'm not convinced we should try to handle this in a generic way as only some devices need dynamic remuxing of some pins. For example, if OMAP I2C driver will handle pinctrl state during system wide suspend the following issue may occure: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) And in this example you are assuming that you need separate idle and sleep states, which is not true at least for most cases I've seen. It is possible that am33xx needs separate idle and sleep states, but most likely only for some pins. For omap[345] we can get away with just the default state for most cases. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] pinctrl: rollback check for !dev-pins in pinctrl_pm_select*() APIs
* Grygorii Strashko grygorii.stras...@ti.com [130717 04:49]: The pinctrl support in Device core assumed to be optional - so, It's valid case, when there are no definition for default device's pinctrl states in DT at all (default, active, idle, sleep). And in this case dev-pins == NULL and pinctrl_pm_select*() API should return 0 always. Now the checks for !dev-pins have been removed from pinctrl_pm_select*() API mistakenly by the patch pinctrl: Remove duplicate code in pinctrl_pm_select_state functions http://www.spinics.net/lists/arm-kernel/msg258829.html Hence, rollback these checks in in pinctrl_pm_select*() APIs. Thanks, it's best that I fold this fix into my patch as it has not been committed yet. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [130715 07:11]: Hi Tony, On 06/18/2013 07:04 PM, Roger Quadros wrote: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Looks like this one got missed out. USB host no longer works on Panda with DT boot. Could you please queue this for next 3.11-rc? Thanks. OK thanks for checking, applying into omap-for-v3.11/fixes. Looks like I also have some pending the .dts changes in omap-for-v3.11/dt branch: 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support Those should get merged as fixes, right? Can you please check and see if they're still OK or if we also need something else? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [130716 06:45]: On 07/16/2013 03:32 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130715 07:11]: Hi Tony, On 06/18/2013 07:04 PM, Roger Quadros wrote: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Looks like this one got missed out. USB host no longer works on Panda with DT boot. Could you please queue this for next 3.11-rc? Thanks. OK thanks for checking, applying into omap-for-v3.11/fixes. Thanks. Looks like I also have some pending the .dts changes in omap-for-v3.11/dt branch: 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB host supprot for Rev. Ax/Bx 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB Host support fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host pin naming consistent Please disregard those. They are old versions. OK, poof that branch is now gone. Benoit had agreed to take the newer version of those for 3.12. Please pick this one to get usb host working on 3.11 with DT. http://www.spinics.net/lists/arm-kernel/msg253612.html 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host support This one is already in through Benoit. It's best that Benoit queue all those to avoid more confusion :) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
* Joel Fernandes jo...@ti.com [130626 20:48]: Build EDMA in by default to avoid fewer people stepping on their toes with broken DMA on drivers needing EDMA. Thanks applying this one into omap-for-v3.11/fixes. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
* Luciano Coelho coe...@ti.com [130702 13:33]: On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote: On 17:55-20130702, Luciano Coelho wrote: Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not. Change all board files to reflect this. Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c |3 +- arch/arm/mach-omap2/board-4430sdp.c |5 ++- ^^ arch/arm/mach-omap2/board-omap3evm.c |3 +- arch/arm/mach-omap2/board-omap4panda.c |3 +- ^^ Please do not add more platform data to platforms that are DT only. Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had been removed in linux-next. I base my tree on wireless-next and it doesn't contain these changes yet. I would only have noticed this when I rebased my tree once the merge window is closed. ;) Thanks for pointing out, I'll make sure these changes will not be there when I send the pull request. Please separate out the minimal pdata and arch/arm/mach-omap2 changes int a immutable branch on v3.11-rc1 that I can also pull in. For v3.12, we're going to be making more boards device tree only, so these changes may otherwise cause pointless merge conflicts. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] leds: Add device tree binding for pca9633
* Bryan Wu coolo...@gmail.com [130701 12:12]: On Thu, Jun 27, 2013 at 7:24 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [130627 00:28]: * Bryan Wu coolo...@gmail.com [130626 16:53]: On Wed, Jun 26, 2013 at 7:17 AM, Tony Lindgren t...@atomide.com wrote: @@ -22,6 +22,7 @@ #include linux/i2c.h #include linux/workqueue.h #include linux/slab.h +#include linux/of.h #include linux/platform_data/leds-pca9633.h /* LED select registers determine the source that drives LED outputs */ @@ -93,6 +94,61 @@ static void pca9633_led_set(struct led_classdev *led_cdev, schedule_work(pca9633-work); } +#ifdef CONFIG_OF Shall we use #if IS_ENABLED(CONFIG_OF), as Grant pointed out recently. Thanks will do, I'll also add the push-pull vs totem pole binding as that can be quite crucial for some hardware configurations. Here's the updated patch. Regards, Tony Thanks, I merged it into my -devel branch. And it targets for 3.12 merge window, since 3.11 merge window opened right now. OK thanks! Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] leds: Add device tree binding for pca9633
* Bryan Wu coolo...@gmail.com [130626 16:53]: On Wed, Jun 26, 2013 at 7:17 AM, Tony Lindgren t...@atomide.com wrote: @@ -22,6 +22,7 @@ #include linux/i2c.h #include linux/workqueue.h #include linux/slab.h +#include linux/of.h #include linux/platform_data/leds-pca9633.h /* LED select registers determine the source that drives LED outputs */ @@ -93,6 +94,61 @@ static void pca9633_led_set(struct led_classdev *led_cdev, schedule_work(pca9633-work); } +#ifdef CONFIG_OF Shall we use #if IS_ENABLED(CONFIG_OF), as Grant pointed out recently. Thanks will do, I'll also add the push-pull vs totem pole binding as that can be quite crucial for some hardware configurations. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] leds: Add device tree binding for pca9633
* Tony Lindgren t...@atomide.com [130627 00:28]:
* Bryan Wu coolo...@gmail.com [130626 16:53]:
On Wed, Jun 26, 2013 at 7:17 AM, Tony Lindgren t...@atomide.com wrote:
@@ -22,6 +22,7 @@
#include linux/i2c.h
#include linux/workqueue.h
#include linux/slab.h
+#include linux/of.h
#include linux/platform_data/leds-pca9633.h
/* LED select registers determine the source that drives LED outputs */
@@ -93,6 +94,61 @@ static void pca9633_led_set(struct led_classdev
*led_cdev,
schedule_work(pca9633-work);
}
+#ifdef CONFIG_OF
Shall we use #if IS_ENABLED(CONFIG_OF), as Grant pointed out recently.
Thanks will do, I'll also add the push-pull vs totem pole binding
as that can be quite crucial for some hardware configurations.
Here's the updated patch.
Regards,
Tony
From: Tony Lindgren tmlind@panda
Date: Wed, 26 Jun 2013 15:52:49 +0300
Subject: [PATCH] leds: Add device tree binding for pca9633
Similar to tca6507, we can just parse the standard LED
properties for pca9633.
Tested on a pca9632, which is compatible with pca9633.
Signed-off-by: Tony Lindgren t...@atomide.com
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/pca9633.txt
@@ -0,0 +1,45 @@
+LEDs connected to pca9633 or pca9632
+
+Required properties:
+- compatible : should be : nxp,pca963x
+
+Optional properties:
+- nxp,totem-pole : use totem pole (push-pull) instead of default open-drain
+
+Each led is represented as a sub-node of the nxp,pca9633 device.
+
+LED sub-node properties:
+- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
+- reg : number of LED line (could be from 0 to 4)
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Examples:
+
+pca9632: pca9632 {
+ compatible = nxp,pca9632, nxp,pca963x;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x62;
+
+ red@0 {
+ label = red;
+ reg = 0;
+ linux,default-trigger = none;
+ };
+ green@1 {
+ label = green;
+ reg = 1;
+ linux,default-trigger = none;
+ };
+ blue@2 {
+ label = blue;
+ reg = 2;
+ linux,default-trigger = none;
+ };
+ unused@3 {
+ label = unused;
+ reg = 3;
+ linux,default-trigger = none;
+ };
+};
--- a/drivers/leds/leds-pca9633.c
+++ b/drivers/leds/leds-pca9633.c
@@ -22,6 +22,7 @@
#include linux/i2c.h
#include linux/workqueue.h
#include linux/slab.h
+#include linux/of.h
#include linux/platform_data/leds-pca9633.h
/* LED select registers determine the source that drives LED outputs */
@@ -93,6 +94,67 @@ static void pca9633_led_set(struct led_classdev *led_cdev,
schedule_work(pca9633-work);
}
+#if IS_ENABLED(CONFIG_OF)
+static struct pca9633_platform_data *
+pca9633_dt_init(struct i2c_client *client)
+{
+ struct device_node *np = client-dev.of_node, *child;
+ struct pca9633_platform_data *pdata;
+ struct led_info *pca9633_leds;
+ int count;
+
+ count = of_get_child_count(np);
+ if (!count || count 4)
+ return ERR_PTR(-ENODEV);
+
+ pca9633_leds = devm_kzalloc(client-dev,
+ sizeof(struct led_info) * count, GFP_KERNEL);
+ if (!pca9633_leds)
+ return ERR_PTR(-ENOMEM);
+
+ for_each_child_of_node(np, child) {
+ struct led_info led;
+ u32 reg;
+ int res;
+
+ led.name =
+ of_get_property(child, label, NULL) ? : child-name;
+ led.default_trigger =
+ of_get_property(child, linux,default-trigger, NULL);
+ res = of_property_read_u32(child, reg, reg);
+ if (res != 0)
+ continue;
+ pca9633_leds[reg] = led;
+ }
+ pdata = devm_kzalloc(client-dev,
+sizeof(struct pca9633_platform_data), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ pdata-leds.leds = pca9633_leds;
+ pdata-leds.num_leds = count;
+
+ /* default to open-drain unless totem pole (push-pull) is specified */
+ if (of_property_read_bool(np, nxp,totem-pole))
+ pdata-outdrv = PCA9633_TOTEM_POLE;
+ else
+ pdata-outdrv = PCA9633_OPEN_DRAIN;
+
+ return pdata;
+}
+
+static const struct of_device_id of_pca9633_match[] = {
+ { .compatible = nxp,pca963x, },
+ {},
+};
+#else
+static struct pca9633_platform_data *
+pca9633_dt_init(struct i2c_client *client)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
static int pca9633_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -102,6 +164,14 @@ static int pca9633_probe(struct i2c_client *client,
pdata = client
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
* Luciano Coelho coe...@ti.com [130625 12:43]: (oh crap, now *really* fixed the ARM mailing list address) On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: Add device tree bindings documentation for the TI WiLink modules. Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 modules is supported. Signed-off-by: Luciano Coelho coe...@ti.com --- I created a new directory under net to contain wireless bindings documentation. The actual implementation in the driver will follow separately. .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file mode 100644 index 000..d8e8bfbb --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt @@ -0,0 +1,46 @@ +TI WiLink Wireless Modules Device Tree Bindings +=== + +The WiLink modules provide wireless connectivity, such as WLAN, +Bluetooth, FM and NFC. + +There are several different modules available, which can be grouped by +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not +currently supported with device tree. + +Currently, only the WLAN portion of the modules is supported with +device tree. + +Required properties: + + +- compatible: should be ti,wilink6, ti,wilink7 or ti,wilink8 +- interrupt-parent: the interrupt controller +- interrupts: out-of-band WLAN interrupt + See the interrupt controller's bindings documentation for + detailed definition. + +Optional properties: + + +- refclock: the internal WLAN reference clock frequency (required for + WiLink6 and WiLink7; not used for WiLink8). Must be one of the + following: + 0 = 19.2 MHz + 1 = 26.0 MHz + 2 = 38.4 MHz + 3 = 52.0 MHz + 4 = 38.4 MHz, XTAL + 5 = 26.0 MHz, XTAL This is just the omap refclock, right? If so, you can just pass the standard clock phandle. I know we don't yet have the DT clocks merged, but Tero just posted another revision of those. +- tcxoclock: the internal WLAN TCXO clock frequency (required for + WiLink7 not used for WiLink6 and WiLink8). Must be one of the + following: + 0 = 19.200 MHz + 1 = 26.000 MHz + 2 = 38.400 MHz + 3 = 52.000 MHz + 4 = 16.368 MHz + 5 = 32.736 MHz + 6 = 16.800 MHz + 7 = 33.600 MHz Where does this clock come from? Maybe this can be set based on the compatible value if it's completely internal? If this is okay for everyone, can I push this via my tree (which goes to linux-wireless-net-linus)? I think it makes more sense to send the documentation together with the patch that actually implements the DT node parsing in the driver. If we can use the standard bindings, it might be worth waiting until we have the DT clocks available as we have the pdata workaround merged anyways. That's because then we don't need to support the custom binding later on ;) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
* Dan Murphy dmur...@ti.com [130625 07:13]: On 06/25/2013 06:32 AM, Ruslan Bilovol wrote: The OMAP4 Blaze Tablet is TI OMAP4 processor-based development platform in a tablet formfactor. The platform contains many of the features found in present-day handsets (such as audio, video, wireless functions and user interfaces) and in addition contains features for software development and test. Why do we want to send this upstream? What is the advantage to having this supported? I don't believe we need to add another community board. We have a SDP and Panda. Why not? Just the .dts file is needed nowadays and it may make it easier to support various other omap4 based tablets that have similar features. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
* Luciano Coelho coe...@ti.com [130626 01:19]: Hi Tony, On Tue, 2013-06-25 at 23:24 -0700, Tony Lindgren wrote: * Luciano Coelho coe...@ti.com [130625 12:43]: On Tue, 2013-06-25 at 11:35 +0300, Luciano Coelho wrote: Add device tree bindings documentation for the TI WiLink modules. Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8 modules is supported. Signed-off-by: Luciano Coelho coe...@ti.com --- [...] +Optional properties: + + +- refclock: the internal WLAN reference clock frequency (required for + WiLink6 and WiLink7; not used for WiLink8). Must be one of the + following: + 0 = 19.2 MHz + 1 = 26.0 MHz + 2 = 38.4 MHz + 3 = 52.0 MHz + 4 = 38.4 MHz, XTAL + 5 = 26.0 MHz, XTAL This is just the omap refclock, right? If so, you can just pass the standard clock phandle. I know we don't yet have the DT clocks merged, but Tero just posted another revision of those. This is an internal clock. This clock is part of the module that contains the WiLink chip. It is not associated with the clocks in the main board (OMAP). +- tcxoclock: the internal WLAN TCXO clock frequency (required for + WiLink7 not used for WiLink6 and WiLink8). Must be one of the + following: + 0 = 19.200 MHz + 1 = 26.000 MHz + 2 = 38.400 MHz + 3 = 52.000 MHz + 4 = 16.368 MHz + 5 = 32.736 MHz + 6 = 16.800 MHz + 7 = 33.600 MHz Where does this clock come from? Maybe this can be set based on the compatible value if it's completely internal? This is also a completely internal clock. My compatible values are based on the WiLink chip itself, not in the module that contains the chip. There are several modules and they are the ones that specify the clock frequencies. This data I'm passing here is just to tell the WiLink chip which frequencies the module uses. My driver is for the WiLink chip itself, not to the module (in theory). So I think having the WiLink values as bindings would be more generic than having to specify values for each available module (eg. lsr-research,tiwi-ble) and mapping those values to specific frequencies in the driver. If this is okay for everyone, can I push this via my tree (which goes to linux-wireless-net-linus)? I think it makes more sense to send the documentation together with the patch that actually implements the DT node parsing in the driver. If we can use the standard bindings, it might be worth waiting until we have the DT clocks available as we have the pdata workaround merged anyways. That's because then we don't need to support the custom binding later on ;) I looked into Tero's patches and I considered using the generic clock bindings, but I think it doesn't make sense in this case. The thing is that the module is not providing the clocks to the main board. Neither is the WiLink chip consuming clocks from the main board. I thought about specifying clock providers and consumers to be used only by the module and WiLink chip, but I think it's overkill. And we would also have to find a way to prevent the main clock framework from trying to handle them. So, my conclusion was that, even though these *are* clocks, from the main board's perspective they're just specifications of what the module looks like. Does this make sense? OK yes, in that case looks fine to me: Acked-by: Tony Lindgren t...@atomide.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] leds: Add device tree binding for pca9633
Similar to tca6507, we can just parse the standard LED
properties for pca9633.
Tested on a pca9632, which is compatible with pca9633.
Signed-off-by: Tony Lindgren t...@atomide.com
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/pca9633.txt
@@ -0,0 +1,42 @@
+LEDs connected to pca9633 or pca9632
+
+Required properties:
+- compatible : should be : nxp,pca963x
+
+Each led is represented as a sub-node of the nxp,pca9633 device.
+
+LED sub-node properties:
+- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
+- reg : number of LED line (could be from 0 to 4)
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Examples:
+
+pca9632: pca9632 {
+ compatible = nxp,pca9632, nxp,pca963x;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x62;
+
+ red@0 {
+ label = red;
+ reg = 0;
+ linux,default-trigger = none;
+ };
+ green@1 {
+ label = green;
+ reg = 1;
+ linux,default-trigger = none;
+ };
+ blue@2 {
+ label = blue;
+ reg = 2;
+ linux,default-trigger = none;
+ };
+ unused@3 {
+ label = unused;
+ reg = 3;
+ linux,default-trigger = none;
+ };
+};
--- a/drivers/leds/leds-pca9633.c
+++ b/drivers/leds/leds-pca9633.c
@@ -22,6 +22,7 @@
#include linux/i2c.h
#include linux/workqueue.h
#include linux/slab.h
+#include linux/of.h
#include linux/platform_data/leds-pca9633.h
/* LED select registers determine the source that drives LED outputs */
@@ -93,6 +94,61 @@ static void pca9633_led_set(struct led_classdev *led_cdev,
schedule_work(pca9633-work);
}
+#ifdef CONFIG_OF
+static struct pca9633_platform_data *
+pca9633_dt_init(struct i2c_client *client)
+{
+ struct device_node *np = client-dev.of_node, *child;
+ struct pca9633_platform_data *pdata;
+ struct led_info *pca9633_leds;
+ int count;
+
+ count = of_get_child_count(np);
+ if (!count || count 4)
+ return ERR_PTR(-ENODEV);
+
+ pca9633_leds = devm_kzalloc(client-dev,
+ sizeof(struct led_info) * count, GFP_KERNEL);
+ if (!pca9633_leds)
+ return ERR_PTR(-ENOMEM);
+
+ for_each_child_of_node(np, child) {
+ struct led_info led;
+ u32 reg;
+ int res;
+
+ led.name =
+ of_get_property(child, label, NULL) ? : child-name;
+ led.default_trigger =
+ of_get_property(child, linux,default-trigger, NULL);
+ res = of_property_read_u32(child, reg, reg);
+ if (res != 0)
+ continue;
+ pca9633_leds[reg] = led;
+ }
+ pdata = devm_kzalloc(client-dev,
+sizeof(struct pca9633_platform_data), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ pdata-leds.leds = pca9633_leds;
+ pdata-leds.num_leds = count;
+
+ return pdata;
+}
+
+static const struct of_device_id of_pca9633_match[] = {
+ { .compatible = nxp,pca963x, },
+ {},
+};
+#else
+static struct pca9633_platform_data *
+pca9633_dt_init(struct i2c_client *client)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
static int pca9633_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -102,6 +158,14 @@ static int pca9633_probe(struct i2c_client *client,
pdata = client-dev.platform_data;
+ if (!pdata) {
+ pdata = pca9633_dt_init(client);
+ if (IS_ERR(pdata)) {
+ dev_warn(client-dev, could not parse
configuration\n);
+ pdata = NULL;
+ }
+ }
+
if (pdata) {
if (pdata-leds.num_leds = 0 || pdata-leds.num_leds 4) {
dev_err(client-dev, board info must claim at most 4
LEDs);
@@ -181,6 +245,7 @@ static struct i2c_driver pca9633_driver = {
.driver = {
.name = leds-pca9633,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_pca9633_match),
},
.probe = pca9633_probe,
.remove = pca9633_remove,
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
* Benoit Cousson b-cous...@ti.com [130624 07:42]: Hi Tony, On 06/24/2013 12:19 PM, Tony Lindgren wrote: Hi, For merging this series, I suggest the following sets: * Joel A Fernandes joelag...@ti.com [130620 14:13]: Joel A Fernandes (3): edma: config: Enable config options for EDMA da8xx: config: Enable MMC and FS options ARM: davinci: Fix compiler warnings in devices-da8xx Matt Porter (8): dmaengine: edma: Add TI EDMA device tree binding ARM: edma: Add DT and runtime PM support to the private EDMA API ARM: edma: Add EDMA crossbar event mux support dmaengine: edma: enable build for AM33XX Sekhar should queue the above patches, I've acked the mach-omap2/Kconfig change. spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support Benoit should queue the .dts changes. I'll do that, but do you consider them for 3.11? Yes right after -rc1 if it makes the DMA work. We almost certainly need to send few branches of fixes after -rc1 once we find out what might have broken by the removal of the hwmod data.. But let's stick to minimal changes for the -rc series naturally. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 11/11] ARM: OMAP4: register DT clocks and remove old data
* Tero Kristo t-kri...@ti.com [130624 00:51]: On 06/21/2013 10:25 AM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [130619 06:25]: Now that the OMAP4 PRCM clock data has been converted to device tree representation, it is no longer needed as static clock data. OMAP4 clock init routine is also changed to register DT clocks first. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 1674 + 1 file changed, 38 insertions(+), 1636 deletions(-) This is nice, thanks for working on this. While at it, can you also keep your eyes open for the register defines in the header files we can also drop? Some of those headers are quite huge.. and should eventually be private to the related drivers if needed at all with DT. Yeah, I can take a look at this after this set is done. It seems like large portion of the headers can be dropped completely once this exercise is done. OK great, thanks. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 04/11] dmaengine: edma: enable build for AM33XX
* Sekhar Nori nsek...@ti.com [130621 03:21]: On 6/21/2013 2:36 AM, Joel A Fernandes wrote: 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 This will have to be taken by Tony. Sekhar, please go ahead and take this one. I'll reply to the header email of this series how it should be queued. For the mach-omap2/Kconfig change: Acked-by: Tony Lindgren t...@atomide.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 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
Hi, For merging this series, I suggest the following sets: * Joel A Fernandes joelag...@ti.com [130620 14:13]: Joel A Fernandes (3): edma: config: Enable config options for EDMA da8xx: config: Enable MMC and FS options ARM: davinci: Fix compiler warnings in devices-da8xx Matt Porter (8): dmaengine: edma: Add TI EDMA device tree binding ARM: edma: Add DT and runtime PM support to the private EDMA API ARM: edma: Add EDMA crossbar event mux support dmaengine: edma: enable build for AM33XX Sekhar should queue the above patches, I've acked the mach-omap2/Kconfig change. spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support Benoit should queue the .dts changes. Documentation/devicetree/bindings/dma/ti-edma.txt | 34 +++ Documentation/devicetree/bindings/spi/omap-spi.txt | 27 ++- arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 22 ++ arch/arm/common/edma.c | 242 ++-- arch/arm/configs/da8xx_omapl_defconfig |3 + arch/arm/mach-davinci/devices-da8xx.c |8 +- arch/arm/mach-omap2/Kconfig|2 + drivers/dma/Kconfig|4 +- drivers/spi/spi-omap2-mcspi.c | 64 -- include/linux/platform_data/edma.h |5 +- 11 files changed, 369 insertions(+), 43 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 11/11] ARM: OMAP4: register DT clocks and remove old data
* Tero Kristo t-kri...@ti.com [130619 06:25]: Now that the OMAP4 PRCM clock data has been converted to device tree representation, it is no longer needed as static clock data. OMAP4 clock init routine is also changed to register DT clocks first. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 1674 + 1 file changed, 38 insertions(+), 1636 deletions(-) This is nice, thanks for working on this. While at it, can you also keep your eyes open for the register defines in the header files we can also drop? Some of those headers are quite huge.. and should eventually be private to the related drivers if needed at all with DT. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 06/11] CLK: omap: move part of the machine specific clock header contents to driver
* Tero Kristo t-kri...@ti.com [130619 06:25]: Some of the clock.h contents are needed by the new OMAP clock driver, including dpll_data and clk_hw_omap. Thus, move these to the generic omap header file which can be accessed by the driver. Do you mean are only needed by the new OMAP clock driver? Otherwise it sounds like this will break things for other omaps that don't yet have clocks configured in DT.. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* 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 couldn't
find a better
way to represent this. It gives us a way to specify not only the GPIO line
but also
the polarity. I know mostly reset is active low but still there is
flexibility as you never
know for sure.
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson b-cous...@ti.com [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson b-cous...@ti.com [130619 05:30]:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
+
+/* 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.
If it's a reset, then yeah it's not a regulator. If the GPIO line is
really used to control the regulator in the external device, then it
makes sense to set it up as a regulator.
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.
Good to hear about the gpio-controlled reset lines :)
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.
We need some solution for v3.11 for omap4 USB on panda so people can
use it with DT.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson b-cous...@ti.com [130619 05:41]: Hi Tony, On 06/19/2013 07:27 AM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. In the case of pbias, the boundary is not that clear, and it is true that writing a complete pinctrl driver is really overkill. I've tried in the past, and gave up due to the complexity of fmwk and the lack of time. I still think, it is a much better fmwk to handle pin configuration than the regulator fmwk. For omaps, these kind of registers can already be handled by pinctrl-single,bits. What's missing is the capability to create a regulator out of the voltage mux + comparator bits. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Well, in that case, this is a reset line, so it does not have anything to do with voltage :-) Anyway, thanks to Florian, we know that there is a real solution to that problem. It is just not merged now :-( Right. Meanwhile, sounds like the transceiver driver needs to deal with the GPIO directly. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: OMAP2+: dts: HACK: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [130618 04:17]:
Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.
Without this, USB Host Ethernet will not be functional with
device tree boots on Panda and uEVM.
Thanks, this looks OK to me to have USB working until we have the
DT defined clock patches ready.
The $Subject needs updating though, just make it ARM: OMAP2+: and
leave out the dts and hack from there.
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..2b2d0de 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/clk.h
#include asm/mach/arch.h
@@ -35,6 +36,21 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * HACK: create alias for USB host PHY clock.
+ * Remove this when clock phandle can be provided via DT
+ */
+static void __init legacy_init_ehci_clk(char *clkname)
+{
+ int ret;
+
+ ret = clk_add_alias(main_clk, NULL, clkname, NULL);
+ if (ret) {
+ pr_err(%s:Failed to add main_clk alias to %s :%d\n,
+ __func__, clkname, ret);
+ }
+}
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
@@ -45,10 +61,15 @@ static void __init omap_generic_init(void)
* HACK: call display setup code for selected boards to enable omapdss.
* This will be removed when omapdss supports DT.
*/
- if (of_machine_is_compatible(ti,omap4-panda))
+ if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
+ legacy_init_ehci_clk(auxclk3_ck);
+
+ }
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+ else if (of_machine_is_compatible(ti,omap5-uevm))
+ legacy_init_ehci_clk(auxclk1_ck);
}
#ifdef CONFIG_SOC_OMAP2420
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
* Felipe Balbi ba...@ti.com [130615 08:12]: fair enough, then let's just add those interrupts to hwmod which will, eventually, let us drop all of that data from hwmod. Nope, we're already dropping the duplicate data from hwmod for am33xx and omap4. See omap-for-v3.11/cleanup branch. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/11] pinctrl: single: adopt pinctrl sleep mode management
* Linus Walleij linus.wall...@linaro.org [130617 04:38]: On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja gururaja.heb...@ti.com wrote: Make pinctrl-single able to handle suspend/resume events and change hogged pins states accordingly. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Linus Walleij linus.wall...@linaro.org Noone said anything about this patch, but it looks very straight-forward to me and seems sound so I have applied it. If Tony or Haojian has strong feelings about it I will dequeue it. I don't like the hogged pins at all as they prevent me from unloading pinctrl-single.. But the patch seems fine to me: Acked-by: Tony Lindgren t...@atomide.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/11] pinctrl: single: adopt pinctrl sleep mode management
* Linus Walleij linus.wall...@linaro.org [130617 09:14]:
On Mon, Jun 17, 2013 at 2:03 PM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [130617 04:38]:
On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
gururaja.heb...@ti.com wrote:
Make pinctrl-single able to handle suspend/resume events and change
hogged pins states accordingly.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Linus Walleij linus.wall...@linaro.org
Noone said anything about this patch, but it looks very straight-forward
to me and seems sound so I have applied it.
If Tony or Haojian has strong feelings about it I will dequeue it.
I don't like the hogged pins at all as they prevent me from unloading
pinctrl-single.. But the patch seems fine to me:
Hm? I think the hogged pins are the *only* pins we can
reliably release when unloading the driver, look:
In most cases all the pins can be released reliably if
the pinctrl driver won't do anything with the pins on
release.
After all that's what bootloaders have been doing for
ages :)
void pinctrl_unregister(struct pinctrl_dev *pctldev)
{
(...)
if (!IS_ERR(pctldev-p))
pinctrl_put(pctldev-p);
That releases all hogged pinctrl handles when unloading
a pinctrl driver.
Hmm maybe I need to try it again. The last time I tried
I had to comment those out, but that was a while back.
And I probably had also some other hack to release pins.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt
* Linus Walleij linus.wall...@linaro.org [130613 02:42]:
On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K balaj...@ti.com wrote:
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit definitions different across
omap[3,4,5], Simplify PBIAS configuration under three different
regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pinctrl states
are defined as pbias_off, pbias_1v8, pbias_3v.
pinctrl state mmc_init is used for configuring speed mode, loopback clock
(in devconf0/devconf1/prog_io1 register for omap3) and pull strength
configuration (in control_mmc1 for omap4)
Signed-off-by: Balaji T K balaj...@ti.com
You *need* Lee Jones and Mark Brown to review this.
Maybe Laurent has something to add too.
Ux500 had the very same thing, and there this was solved using
a GPIO regulator for vqmmc a level-shifter. I vaguely remember
Laurent doing something similar with the SH stuff.
+ /* 100ms delay required for PBIAS configuration */
+ msleep(100);
+ if (!vdd host-pinctrl host-pbias_off) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_off select
error\n);
+ } else if (((1 vdd) = MMC_VDD_165_195) host-pinctrl
+ host-pbias_1v8) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_1v8);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_1v8 select
error\n);
+ } else if (((1 vdd) MMC_VDD_165_195) host-pinctrl
+ host-pbias_3v) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_3v);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_3v select
error\n);
+ }
So why does the pin control API control bias voltage?
I agree, it should be a regulator for the MMC driver and that's what I
already suggested earlier. Having it as a regulator allows us to get
rid of all the non-standard before and after calls in the omap_hsmmc.c.
This way the omap_hsmmc.c code can handle the internal and external
voltages the same way.
This seem so intuitively wrong as it can possibly get, clearly this
is regulator territory.
The PBIAS for MMC1 is a mux + comparator for the MMC pin, so it makes
sense for the regulator driver to access the register via pinctrl API.
I think the reason why we have registers like this and the USB comparators
in the omap SCM (System Control Module) as the all seem to relate to
pin states.
This also looks strange from an MMC point of view.
Yes I agree, it should be a regulator for MMC. Doing it this way just
adds yet more code that's usable for only one of the omap MMC
controllers.
It just seems these bits in these registers should be poked at
by the regulator world, not the pinctrl world. That the bits are
in the middle of pinctrl things does not really matter.
+ usleep_range(350, 400);
And the regulator framework supports power-on delays.
Yes. And it seems that the delays should not be needed, but instead
the comparator bits should be checked.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig
* Mohammed, Afzal af...@ti.com [130613 00:04]: Hi Tony, On Wed, Jun 12, 2013 at 22:42:00, Tony Lindgren wrote: I've updated this patch to remove the default y and depends on ARCH_OMAP2PLUS entries for the usual reasons and applied the first ten patches into omap-for-v3.11/soc. Thanks. Patch 10 ARM: OMAP2+: AM43x: basic dt support is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream. Hmm if that's .dts changes, Benoit needs to queue that. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig
* Mohammed, Afzal af...@ti.com [130613 03:08]: Hi Tony, On Thu, Jun 13, 2013 at 15:24:54, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [130613 00:04]: Patch 10 ARM: OMAP2+: AM43x: basic dt support is missing in omap-for-v3.11/soc branch and omap soc pull request, can you please help patch 10 also to go upstream. Hmm if that's .dts changes, Benoit needs to queue that. It is not dts change. Patch 10 patches board-generic.c for DT boot (Benoit has already picked up dts, that is patch 14). Oops OK sorry I must have miscounted the patches that looked ready to apply. Will apply. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
* Roger Quadros rog...@ti.com [130611 05:57]:
On 06/10/2013 06:21 PM, Tony Lindgren wrote:
* Quadros, Roger rog...@ti.com [130610 03:09]:
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device
creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
Ah here, found your other comment :)
That's not needed, the real fix is to make twl-core.c and friends to
be regular module_init. There are already patches queued for that.
OK. I was testing with USB host driver and it seems to be loaded as
fs_initcall() which
is the root of the problem. I will fix up the usb host driver to be loaded as
module_init()
OK good to hear.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 01/10] ARM: OMAP2+: add needs_vmmc to hsmmc_info
* Balaji T K balaj...@ti.com [130606 12:20]:
Add needs_vmmc and needs_vmmc_aux to indicate whether regulator is
applicable so that omap_hsmmc can handle deferred probe error
properly for regulators.
Remove the assumption that vmmc_aux regulator to be available only if vmmc is
present. Platforms can have fixed-always-ON regulator for vmmc and/or vmmc_aux
in such cases regulator needed not be specified in board file.
Looks good to me, I suggest you resend this again a bit later once the
other changes are merged so we can avoid a dependency between
arch/arm/mach-omap2
and MMC changes.
Regards,
Tony
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |1 +
arch/arm/mach-omap2/board-3430sdp.c |3 +++
arch/arm/mach-omap2/board-cm-t35.c |2 ++
arch/arm/mach-omap2/board-devkit8000.c |1 +
arch/arm/mach-omap2/board-igep0020.c |3 +++
arch/arm/mach-omap2/board-ldp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |2 ++
arch/arm/mach-omap2/board-omap3evm.c |3 +++
arch/arm/mach-omap2/board-omap3logic.c |1 +
arch/arm/mach-omap2/board-omap3pandora.c |3 +++
arch/arm/mach-omap2/board-omap3stalker.c |2 ++
arch/arm/mach-omap2/board-omap3touchbook.c |2 ++
arch/arm/mach-omap2/board-overo.c|1 +
arch/arm/mach-omap2/board-rm680.c|1 +
arch/arm/mach-omap2/board-rx51-peripherals.c |3 +++
arch/arm/mach-omap2/board-zoom-peripherals.c |4
arch/arm/mach-omap2/hsmmc.c |2 ++
arch/arm/mach-omap2/hsmmc.h |2 ++
include/linux/platform_data/mmc-omap.h |2 ++
19 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..eba8593 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -211,6 +211,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ext_clock = 1,
+ .needs_vmmc = 1,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 23b004a..9438c54 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -184,12 +184,15 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 4,
.deferred = true,
+ .needs_vmmc = 1,
+ .needs_vmmc_aux = 1,
},
{
.mmc= 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 7,
.deferred = true,
+ .needs_vmmc = 1,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index ee6218c..207ea13 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -364,6 +364,8 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.deferred = true,
+ .needs_vmmc = 1,
+ .needs_vmmc_aux = 1,
},
{
.mmc= 2,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 5764205..63fd8827 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -99,6 +99,7 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 29,
.deferred = true,
+ .needs_vmmc = 1,
},
{} /* Terminator */
};
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index b54562d..a2a8a80 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -284,6 +284,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.deferred = true,
+ .needs_vmmc = 1,
},
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
{
@@ -291,6 +292,8 @@ static struct omap2_hsmmc_info mmc[] = {
.caps = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .needs_vmmc = 1,
+ .needs_vmmc_aux = 1,
},
#endif
{} /* Terminator */
diff --git a/arch/arm/mach-omap2/board-ldp.c
Re: [PATCH v2 02/10] mmc: omap_hsmmc: make vcc and vcc_aux independent
* Balaji T K balaj...@ti.com [130606 12:20]:
handle vcc and vcc_aux independently
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1865321..bda1a42 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -253,7 +253,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* If we don't see a Vcc regulator, assume it's a fixed
* voltage always-on regulator.
*/
- if (!host-vcc)
+ if (!host-vcc !host-vcc_aux)
return 0;
/*
* With DT, never turn OFF the regulator for MMC1. This is because
Doesn't the above change break MMC for most boards that only pass
one regulator and no aux regulator?
Regards,
Tony
@@ -280,11 +280,12 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
+ if (host-vcc)
+ ret = mmc_regulator_set_ocr(host-mmc, host-vcc, vdd);
/* Enable interface voltage rail, if needed */
if (ret == 0 host-vcc_aux) {
ret = regulator_enable(host-vcc_aux);
- if (ret 0)
+ if (ret 0 host-vcc)
ret = mmc_regulator_set_ocr(host-mmc,
host-vcc, 0);
}
@@ -292,7 +293,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
/* Shut down the rail */
if (host-vcc_aux)
ret = regulator_disable(host-vcc_aux);
- if (!ret) {
+ if (host-vcc) {
/* Then proceed to shut down the local regulator */
ret = mmc_regulator_set_ocr(host-mmc,
host-vcc, 0);
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 09/10] ARM: dts: omap3: add pbias and mmc_init pinctrl states
* Balaji T K balaj...@ti.com [130606 12:20]:
add pbias states for pbias 0, 1.8V, 3V
add omap3 sd/mmc2 loop back clock config for devconf1 in mmc2_init pinctrl
state
add OMAP3430 sd/mmc1 loop back clock config for devconf0 in mmc1_init pinctrl
state
add OMAP3630 sd/mmc1 speed mode config for prog_io1 in mmc1_init pinctrl state
Looks OK to me, except these should be under mmc1 for omap[345].dtsi files.
Regards,
Tony
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 42
+
arch/arm/boot/dts/omap3-beagle.dts| 42
+
arch/arm/boot/dts/omap3.dtsi | 10
3 files changed, 94 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..45d1642 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -59,6 +59,40 @@
};
};
+omap3_pmx_general {
+ pinctrl-names = default;
+ pinctrl-0 = ;
+ pbias_off: pinmux_pbias_off {
+ pinctrl-single,bits =
+ 0x2b0 0x1 0x3 /* pbias */
+ ;
+ };
+
+ pbias_1v8: pinmux_pbias_1v8 {
+ pinctrl-single,bits =
+ 0x2b0 0x2 0x3 /* pbias */
+ ;
+ };
+
+ pbias_3v: pinmux_pbias_3v {
+ pinctrl-single,bits =
+ 0x2b0 0x3 0x3 /* pbias */
+ ;
+ };
+
+ mmc1_init: pinmux_mmc1_init {
+ pinctrl-single,bits =
+ 0x1d8 0x10 0x10 /* prog_io1 */
+ ;
+ };
+
+ mmc2_init: pinmux_mmc2_init {
+ pinctrl-single,bits =
+ 0x68 0x40 0x40 /* devconf1 */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
@@ -95,12 +129,20 @@
};
mmc1 {
+ pinctrl-names = default, mmc_init, pbias_off, pbias_1v8,
pbias_3v;
+ pinctrl-0 = ;
+ pinctrl-1 = mmc1_init;
+ pinctrl-2 = pbias_off;
+ pinctrl-3 = pbias_1v8;
+ pinctrl-4 = pbias_3v;
vmmc-supply = vmmc1;
vmmc_aux-supply = vsim;
bus-width = 8;
};
mmc2 {
+ pinctrl-names = mmc_init;
+ pinctrl-1 = mmc2_init;
status = disabled;
};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 7da9979..14e251f 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -109,6 +109,40 @@
};
};
+omap3_pmx_general {
+ pinctrl-names = default;
+ pinctrl-0 = ;
+ pbias_off: pinmux_pbias_off {
+ pinctrl-single,bits =
+ 0x2b0 0x5 0x7 /* pbias */
+ ;
+ };
+
+ pbias_1v8: pinmux_pbias_1v8 {
+ pinctrl-single,bits =
+ 0x2b0 0x6 0x7 /* pbias */
+ ;
+ };
+
+ pbias_3v: pinmux_pbias_3v {
+ pinctrl-single,bits =
+ 0x2b0 0x7 0x7 /* pbias */
+ ;
+ };
+
+ mmc1_init: pinmux_mmc1_init {
+ pinctrl-single,bits =
+ 0x4 0x0100 0x0100 /* devconf0 */
+ ;
+ };
+
+ mmc2_init: pinmux_mmc2_init {
+ pinctrl-single,bits =
+ 0x68 0x40 0x40 /* devconf1 */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
@@ -122,12 +156,20 @@
/include/ twl4030.dtsi
mmc1 {
+ pinctrl-names = default, mmc_init, pbias_off, pbias_1v8,
pbias_3v;
+ pinctrl-0 = ;
+ pinctrl-1 = mmc1_init;
+ pinctrl-2 = pbias_off;
+ pinctrl-3 = pbias_1v8;
+ pinctrl-4 = pbias_3v;
vmmc-supply = vmmc1;
vmmc_aux-supply = vsim;
bus-width = 8;
};
mmc2 {
+ pinctrl-names = mmc_init;
+ pinctrl-1 = mmc2_init;
status = disabled;
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index caaa708..de2940d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,6 +111,16 @@
pinctrl-single,function-mask = 0x7f1f;
};
+ omap3_pmx_general: pinmux@48002270 {
+ compatible = ti,omap3-padconf, pinctrl-single;
+ reg = 0x48002270 0x2f4;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x;
+ };
+
omap3_pmx_wkup: pinmux@0x48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002a00 0x5c;
--
1.7.5.4
___
devicetree-discuss
Re: [PATCH v2 10/10] ARM: dts: omap4: add pbias and mmc_init pinctrl states
* Balaji T K balaj...@ti.com [130606 12:20]:
add pbias states for pbias 0, 1.8V, 3V
add sd/mmc1 pull strength values for control_mmc1 in mmc_init pinctrl state
This too should be under mmc1 in the omap4.dtsi file.
Tony
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 34
+
arch/arm/boot/dts/omap4-sdp.dts | 34
+
arch/arm/boot/dts/omap4.dtsi | 11 +
3 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..d6ffbb1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -137,6 +137,34 @@
};
};
+omap4_padconf_global {
+ pinctrl-names = default;
+ pinctrl-0 = ;
+ pbias_off: pinmux_pbias_off {
+ pinctrl-single,bits =
+ 0x60 0x 0x07e0 /* pbias */
+ ;
+ };
+
+ pbias_1v8: pinmux_pbias_1v8 {
+ pinctrl-single,bits =
+ 0x60 0x0440 0x07e0 /* pbias */
+ ;
+ };
+
+ pbias_3v: pinmux_pbias_3v {
+ pinctrl-single,bits =
+ 0x60 0x0460 0x07e0 /* pbias */
+ ;
+ };
+
+ mmc1_init: pinmux_mmc1_init {
+ pinctrl-single,bits =
+ 0x88 0xce00 0xfe00 /* control_mmc1 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
@@ -197,6 +225,12 @@
};
mmc1 {
+ pinctrl-names = default, mmc_init, pbias_off, pbias_1v8,
pbias_3v;
+ pinctrl-0 = ;
+ pinctrl-1 = mmc1_init;
+ pinctrl-2 = pbias_off;
+ pinctrl-3 = pbias_1v8;
+ pinctrl-4 = pbias_3v;
vmmc-supply = vmmc;
bus-width = 8;
};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index a35d9cd..b1c0e86 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -142,6 +142,34 @@
};
};
+omap4_padconf_global {
+ pinctrl-names = default;
+ pinctrl-0 = ;
+ pbias_off: pinmux_pbias_off {
+ pinctrl-single,bits =
+ 0x60 0x 0x07e0 /* pbias */
+ ;
+ };
+
+ pbias_1v8: pinmux_pbias_1v8 {
+ pinctrl-single,bits =
+ 0x60 0x0440 0x07e0 /* pbias */
+ ;
+ };
+
+ pbias_3v: pinmux_pbias_3v {
+ pinctrl-single,bits =
+ 0x60 0x0460 0x07e0 /* pbias */
+ ;
+ };
+
+ mmc1_init: pinmux_mmc1_init {
+ pinctrl-single,bits =
+ 0x88 0xce00 0xfe00 /* control_mmc1 */
+ ;
+ };
+};
+
omap4_pmx_core {
pinctrl-names = default;
pinctrl-0 =
@@ -381,6 +409,12 @@
};
mmc1 {
+ pinctrl-names = default, mmc_init, pbias_off, pbias_1v8,
pbias_3v;
+ pinctrl-0 = ;
+ pinctrl-1 = mmc1_init;
+ pinctrl-2 = pbias_off;
+ pinctrl-3 = pbias_1v8;
+ pinctrl-4 = pbias_3v;
vmmc-supply = vmmc;
bus-width = 8;
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..41f575d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -114,6 +114,17 @@
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x7fff;
};
+
+ omap4_padconf_global: pinmux@4a100600 {
+ compatible = ti,omap4-padconf, pinctrl-single;
+ reg = 0x4a1005a0 0x170;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x;
+ };
+
omap4_pmx_wkup: pinmux@4a31e040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a31e040 0x0038;
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt
* Balaji T K balaj...@ti.com [130606 12:20]:
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit definitions different across
omap[3,4,5], Simplify PBIAS configuration under three different
regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pinctrl states
are defined as pbias_off, pbias_1v8, pbias_3v.
pinctrl state mmc_init is used for configuring speed mode, loopback clock
(in devconf0/devconf1/prog_io1 register for omap3) and pull strength
configuration (in control_mmc1 for omap4)
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 83 ++--
1 files changed, 78 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 533ced2..8dd1cd3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -182,6 +182,9 @@ struct omap_hsmmc_host {
int req_in_progress;
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pbias_off, *pbias_1v8, *pbias_3v, *mmc_init;
+
struct omap_mmc_platform_data *pdata;
int needs_vmmc:1;
int needs_vmmc_aux:1;
@@ -267,6 +270,12 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
+ if (host-pinctrl host-pbias_off) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_off select error\n);
+ }
+
/*
* Assume Vcc regulator is used only to power the card ... OMAP
* VDDS is used to power the pins, optionally with a transceiver to
@@ -304,6 +313,25 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).after_set_reg)
mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
+ /* 100ms delay required for PBIAS configuration */
+ msleep(100);
Hmm, why is the delay needed before the configuration? Is this something
you could avoid by reading the pinconf state maybe?
+ if (!vdd host-pinctrl host-pbias_off) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_off);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_off select error\n);
+ } else if (((1 vdd) = MMC_VDD_165_195) host-pinctrl
+ host-pbias_1v8) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_1v8);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_1v8 select error\n);
+ } else if (((1 vdd) MMC_VDD_165_195) host-pinctrl
+ host-pbias_3v) {
+ ret = pinctrl_select_state(host-pinctrl, host-pbias_3v);
+ if (ret 0)
+ dev_err(host-dev, pinctrl pbias_3v select error\n);
+ }
+ usleep_range(350, 400);
+
return ret;
}
Maybe add some macro for doing the if (((1 vdd) = MMC_VDD_165_195)... tests?
@@ -1775,6 +1803,52 @@ static inline struct omap_mmc_platform_data
}
#endif
+static int omap_hsmmc_pinctrl_init(struct omap_hsmmc_host *host)
+{
+ int ret = 0;
+
+ host-pinctrl = devm_pinctrl_get(host-dev);
+ if (IS_ERR(host-pinctrl)) {
+ host-pinctrl = NULL;
+ dev_warn(host-dev,
+ pins are not configured from the driver\n);
+ return 0;
+ }
+
+ host-mmc_init = pinctrl_lookup_state(host-pinctrl, mmc_init);
+ if (IS_ERR(host-mmc_init)) {
+ dev_vdbg(host-dev, optional: mmc_init lookup error);
+ host-mmc_init = NULL;
+ } else {
+ ret = pinctrl_select_state(host-pinctrl, host-mmc_init);
+ if (ret 0) {
+ dev_err(host-dev, pinctrl mmc_init select error\n);
+ goto err_pinctrl;
+ }
+ }
+
+ host-pbias_off = pinctrl_lookup_state(host-pinctrl, pbias_off);
+ if (IS_ERR(host-pbias_off)) {
+ dev_vdbg(host-dev, optional: pbias_off lookup error);
+ host-pbias_off = NULL;
+ }
+
+ host-pbias_1v8 = pinctrl_lookup_state(host-pinctrl, pbias_1v8);
+ if (IS_ERR(host-pbias_1v8)) {
+ dev_vdbg(host-dev, optional: pbias_1v8 lookup error);
+ host-pbias_1v8 = NULL;
+ }
+
+ host-pbias_3v = pinctrl_lookup_state(host-pinctrl, pbias_3v);
+ if (IS_ERR(host-pbias_3v)) {
+ dev_vdbg(host-dev, optional: pbias_3v lookup error);
+ host-pbias_3v = NULL;
+ }
+
+err_pinctrl:
+ return ret;
+}
Linus W may have some comments on this, although this is not the standard
muxing stuff. The
Re: [PATCH v2 02/10] mmc: omap_hsmmc: make vcc and vcc_aux independent
* Balaji T K balaj...@ti.com [130612 07:39]: On Wednesday 12 June 2013 07:55 PM, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [130606 12:20]: handle vcc and vcc_aux independently Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 1865321..bda1a42 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -253,7 +253,7 @@ static int omap_hsmmc_set_power(struct device *dev, int slot, int power_on, * If we don't see a Vcc regulator, assume it's a fixed * voltage always-on regulator. */ - if (!host-vcc) + if (!host-vcc !host-vcc_aux) return 0; /* * With DT, never turn OFF the regulator for MMC1. This is because Doesn't the above change break MMC for most boards that only pass one regulator and no aux regulator? No, I want to skip regulator operation in set_power function iff both regulator are not present. Earlier vcc was assumed/mandatory if vcc_aux is present. Now, regulator operation will be handled if either one of vcc/vcc_aux is present, Ah OK yes sorry I misread your patch. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 08/10] ARM: dts: omap3: split omap3_pmx_core
* Balaji T K balaj...@ti.com [130606 12:20]:
omap3_pmx_core: padconf register are in two banks 0x48003000 to 0x48002268
and 0x480025c0 to 0x480025f8.
split omap3_pmx_core into 2 banks as register between 0x48002270 and
0x48002564
belongs to type pinctrl-single,bit-per-mux with access to certain bit
fields with bit field mask.
Is this the right patch for the description? THe patch seems to deal with
USB pins.
Also, let's not hog any pins under the pinmux controllers, those make
unloading pinctrl-single impossible which is not nice for distros and
development.
Instead, the pins should be under mmc1 in omap[345].dtsi files.
Regards,
Tony
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 28
arch/arm/boot/dts/omap3.dtsi | 11 ++-
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 6eec699..7da9979 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -76,17 +76,11 @@
omap3_pmx_core {
pinctrl-names = default;
pinctrl-0 =
- hsusbb2_pins
+ hsusbb2_pins1
;
- hsusbb2_pins: pinmux_hsusbb2_pins {
+ hsusbb2_pins1: pinmux_hsusbb2_pins1 {
pinctrl-single,pins =
- 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
- 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
- 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
- 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
- 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
- 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
@@ -97,6 +91,24 @@
};
};
+omap3_pmx_core2 {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins2
+ ;
+
+ hsusbb2_pins2: pinmux_hsusbb2_pins2 {
+ pinctrl-single,pins =
+ 0x50 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x52 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x54 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x56 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x58 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5A 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ ;
+ };
+};
+
i2c1 {
clock-frequency = 260;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 82a404d..caaa708 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -95,7 +95,16 @@
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
- reg = 0x48002030 0x05cc;
+ reg = 0x48002030 0x238;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 16;
+ pinctrl-single,function-mask = 0x7f1f;
+ };
+
+ omap3_pmx_core2: pinmux@480025a0 {
+ compatible = ti,omap3-padconf, pinctrl-single;
+ reg = 0x480025a0 0x5c;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 02/14] ARM: OMAP2+: AM43x: Kconfig
* Afzal Mohammed af...@ti.com [130527 07:41]: --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -149,6 +149,16 @@ config SOC_AM33XX select MULTI_IRQ_HANDLER select COMMON_CLK +config SOC_AM43XX + bool TI AM43x + depends on ARCH_OMAP2PLUS + default y + select CPU_V7 + select MULTI_IRQ_HANDLER + select ARM_GIC + select COMMON_CLK + select MACH_OMAP_GENERIC + config OMAP_PACKAGE_ZAF bool I've updated this patch to remove the default y and depends on ARCH_OMAP2PLUS entries for the usual reasons and applied the first ten patches into omap-for-v3.11/soc. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 07/14] ARM: OMAP2+: AM43x: early init
* Afzal Mohammed af...@ti.com [130527 07:42]:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -586,6 +586,20 @@ void __init am33xx_init_early(void)
}
#endif
+#ifdef CONFIG_SOC_AM43XX
+void __init am43xx_init_early(void)
+{
+ omap2_set_globals_tap(AM335X_CLASS,
+ AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE));
+ omap2_set_globals_control(AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+ NULL);
+ omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE));
+ omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM43XX_PRCM_BASE), NULL);
+ omap3xxx_check_revision();
+ am33xx_check_features();
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
void __init omap4430_init_early(void)
{
I've updated this to remove am33xx_check_features() that we don't
seem to have in the mainline yet.
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 08/10] ARM: dts: omap3: split omap3_pmx_core
* Balaji T K balaj...@ti.com [130612 10:14]: On Wednesday 12 June 2013 08:05 PM, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [130606 12:20]: omap3_pmx_core: padconf register are in two banks 0x48003000 to 0x48002268 and 0x480025c0 to 0x480025f8. split omap3_pmx_core into 2 banks as register between 0x48002270 and 0x48002564 belongs to type pinctrl-single,bit-per-mux with access to certain bit fields with bit field mask. Is this the right patch for the description? THe patch seems to deal with USB pins. Also, let's not hog any pins under the pinmux controllers, those make unloading pinctrl-single impossible which is not nice for distros and development. omap3_pmx_core is not continuous, so had to split into two and updated the only user in second bank (omap3_pmx_core2) which happened to be usb, CC Roger for USB dynamic pin mux selection. I see. OK yes we can split it as that saves memory too for the unused registers. While at it, please move remove the hogs from the pmx entries and move the pins to the drivers claiming them. Regards, TOny ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 09/10] ARM: dts: omap3: add pbias and mmc_init pinctrl states
* Balaji T K balaj...@ti.com [130612 10:50]: On Wednesday 12 June 2013 08:05 PM, Tony Lindgren wrote: * Balaji T K balaj...@ti.com [130606 12:20]: add pbias states for pbias 0, 1.8V, 3V add omap3 sd/mmc2 loop back clock config for devconf1 in mmc2_init pinctrl state add OMAP3430 sd/mmc1 loop back clock config for devconf0 in mmc1_init pinctrl state add OMAP3630 sd/mmc1 speed mode config for prog_io1 in mmc1_init pinctrl state Looks OK to me, except these should be under mmc1 for omap[345].dtsi files. I think I can move omap3_pmx_general to omap3.dtsi and override pbias_1v8, pbias_3v in omap36xx.dtsi, but I doubt pinctrl-[0,1,2,3,4] since pull up setting can vary between boards. OK makes sense to me if it's board specific. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
* Quadros, Roger rog...@ti.com [130610 03:09]:
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
Ah here, found your other comment :)
That's not needed, the real fix is to make twl-core.c and friends to
be regular module_init. There are already patches queued for that.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Tony Lindgren t...@atomide.com [130607 13:58]:
* Tony Lindgren t...@atomide.com [130607 13:56]:
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
This patch I should queue separately, the rest should go via
the pinctrl tree.
Here's this one updated to add stubs for the SoC specific
reconfigure_io_chain functions when the SoC is not selected.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 7 Jun 2013 11:39:58 -0700
Subject: [PATCH] ARM: OMAP: Move DT wake-up event handling over to use
pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c018593..9b19b14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -172,6 +172,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = ~ignore_bits;
c++;
+ if (c 10
Re: [PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
* Haojian Zhuang haojian.zhu...@gmail.com [130608 21:51]:
I assume that this patch is used in both v1 v2 version. Since Manjunathappa
changed the logic of distinguishing bits and pins in blew.
if (pcs-bits_per_mux)
mask = vals-mask;
else
mask = pcs-fmask
Would you like to sync with his style?
Thanks for catching that, yes that's how it should be now. Updated
patch below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Sat, 8 Jun 2013 08:40:35 -0700
Subject: [PATCH] pinctrl: single: Add hardware specific hooks for IRQ and GPIO
wake-up events
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware. The wake-up
event can be device specific, or may need to be dynamically
remuxed to GPIO input for wake-up events. When the wake-up
event happens, it's IRQ need to be called so the device won't
lose interrupts.
Allow supporting IRQ and GPIO wake-up events if a hardware
spefific module is registered for the enable and disable
calls.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..b95fa6c 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -69,6 +69,10 @@ Optional properties:
The number of parameters is depend on #pinctrl-single,gpio-range-cells
property.
+- interrrupts : the interrupt that a function may have for a wake-up event
+
+- gpios: the gpio that a function may have for a wake-up event
+
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
@@ -205,6 +209,7 @@ pmx_gpio: pinmux@d401e000 {
0xdc 0x118
0xde 0
;
+ interrupts = 74;
};
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index e3b1f76..72efc8e 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -95,6 +97,8 @@ struct pcs_conf_type {
* @nvals: number of entries in vals array
* @pgnames: array of pingroup names the function uses
* @npgnames: number of pingroup names the function uses
+ * @irq: optional irq associated with the function
+ * @gpio: optional gpio associated with the function
* @node: list node
*/
struct pcs_function {
@@ -105,6 +109,8 @@ struct pcs_function {
int npgnames;
struct pcs_conf_vals *conf;
int nconfs;
+ int irq;
+ int gpio;
struct list_head node;
};
@@ -411,6 +417,18 @@ static int pcs_get_function(struct pinctrl_dev *pctldev,
unsigned pin,
return 0;
}
+static void pcs_reg_init(struct pcs_reg *p, struct pcs_device *pcs,
+struct pcs_function *func,
+void __iomem *reg, unsigned val)
+{
+ p-read = pcs-read;
+ p-write = pcs-write;
+ p-irq = func-irq;
+ p-gpio = func-gpio;
+ p-reg = reg;
+ p-val = val;
+}
+
static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
unsigned group)
{
@@ -444,6 +462,12 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
val = ~mask;
val |= (vals-val mask);
pcs-write(val, vals-reg);
+ if ((func-irq || func-gpio) pcs-soc pcs-soc-enable) {
+ struct pcs_reg pcsr;
+
+ pcs_reg_init(pcsr, pcs, func, vals-reg, val);
+ pcs-soc-enable(pcs-soc, pcsr);
+ }
}
return 0;
@@ -468,18 +492,6 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
return;
}
- /*
-* Ignore disable if function-off is not specified. Some hardware
-* does not have clearly defined disable function. For pin specific
-* off modes, you can use alternate named states as described in
-* pinctrl-bindings.txt.
-*/
- if (pcs-foff == PCS_OFF_DISABLED) {
- dev_dbg(pcs-dev, ignoring disable for %s function%i\n,
- func-name, fselector);
- return
Re: [PATCH 1/4] pinctrl: single: Prepare for supporting SoC specific features
* Haojian Zhuang haojian.zhu...@gmail.com [130608 02:43]:
Manjunathappa's pinctrl-single patch on enhancing bits is already merged.
This patch conflicts with his patch.
Could you rebase your patches?
Sure. Looks like Linus W forgot to push out the branch as I don't see
it yet in the pinctrl tree. Here's a version of this one against current
Linux next + Manjunathappa's patches.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Sat, 8 Jun 2013 08:03:07 -0700
Subject: [PATCH] pinctrl: single: Prepare for supporting SoC specific features
Let's replace is_pinconf with flags and add struct pcs_soc so we
can support also other features like pin wake-up events. Let's
export the probe so the SoC specific modules can pass their
SoC specific data to pinctrl-single if needed.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 2899c86..e3b1f76 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -26,6 +26,7 @@
#include core.h
#include pinconf.h
+#include pinctrl-single.h
#define DRIVER_NAMEpinctrl-single
#define PCS_MUX_PINS_NAME pinctrl-single,pins
@@ -162,7 +163,6 @@ struct pcs_name {
* @fshift:function register shift
* @foff: value to turn mux off
* @fmax: max number of functions in fmask
- * @is_pinconf:whether supports pinconf
* @bits_per_pin:number of bits per pin
* @names: array of register names for pins
* @pins: physical pins on the SoC
@@ -176,6 +176,7 @@ struct pcs_name {
* @desc: pin controller descriptor
* @read: register read function to use
* @write: register write function to use
+ * @soc: SoC glue
*/
struct pcs_device {
struct resource *res;
@@ -190,8 +191,8 @@ struct pcs_device {
unsigned foff;
unsigned fmax;
bool bits_per_mux;
- bool is_pinconf;
unsigned bits_per_pin;
+ unsigned flags;
struct pcs_name *names;
struct pcs_data pins;
struct radix_tree_root pgtree;
@@ -204,6 +205,7 @@ struct pcs_device {
struct pinctrl_desc desc;
unsigned (*read)(void __iomem *reg);
void (*write)(unsigned val, void __iomem *reg);
+ const struct pcs_soc *soc;
};
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
@@ -1049,7 +1051,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
struct device_node *np,
};
/* If pinconf isn't supported, don't parse properties in below. */
- if (!pcs-is_pinconf)
+ if (!(pcs-flags PCS_HAS_PINCONF))
return 0;
/* cacluate how much properties are supported in current node */
@@ -1173,7 +1175,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device
*pcs,
(*map)-data.mux.group = np-name;
(*map)-data.mux.function = np-name;
- if (pcs-is_pinconf) {
+ if (pcs-flags PCS_HAS_PINCONF) {
res = pcs_parse_pinconf(pcs, np, function, map);
if (res)
goto free_pingroups;
@@ -1294,7 +1296,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct
pcs_device *pcs,
(*map)-data.mux.group = np-name;
(*map)-data.mux.function = np-name;
- if (pcs-is_pinconf) {
+ if (pcs-flags PCS_HAS_PINCONF) {
dev_err(pcs-dev, pinconf not supported\n);
goto free_pingroups;
}
@@ -1483,18 +1485,14 @@ static int pcs_add_gpio_func(struct device_node *node,
struct pcs_device *pcs)
return ret;
}
-static int pcs_probe(struct platform_device *pdev)
+int pinctrl_single_probe(struct platform_device *pdev,
+const struct pcs_soc *soc)
{
struct device_node *np = pdev-dev.of_node;
- const struct of_device_id *match;
struct resource *res;
struct pcs_device *pcs;
int ret;
- match = of_match_device(pcs_of_match, pdev-dev);
- if (!match)
- return -EINVAL;
-
pcs = devm_kzalloc(pdev-dev, sizeof(*pcs), GFP_KERNEL);
if (!pcs) {
dev_err(pdev-dev, could not allocate\n);
@@ -1505,7 +1503,8 @@ static int pcs_probe(struct platform_device *pdev)
INIT_LIST_HEAD(pcs-pingroups);
INIT_LIST_HEAD(pcs-functions);
INIT_LIST_HEAD(pcs-gpiofuncs);
- pcs-is_pinconf = match-data;
+ pcs-flags = soc-flags;
+ pcs-soc = soc;
PCS_GET_PROP_U32(pinctrl-single,register-width, pcs-width,
register width not specified\n);
@@ -1574,7 +1573,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs-desc.name = DRIVER_NAME;
pcs-desc.pctlops
Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
Here's a version of against current Linux next to as also the
Makefile entry for sirf had changed.
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 3b26e3c..d4c2214 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -31,7 +31,8 @@ obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o
obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o
obj-$(CONFIG_PINCTRL_DB8500) += pinctrl-nomadik-db8500.o
obj-$(CONFIG_PINCTRL_DB8540) += pinctrl-nomadik-db8540.o
-obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
+pcs-$(CONFIG_ARCH_OMAP2PLUS) += pinctrl-single-omap.o
+obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o $(pcs-y)
obj-$(CONFIG_PINCTRL_SIRF) += sirf/
obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
diff --git a/drivers/pinctrl/pinctrl-single-omap.c
b/drivers/pinctrl/pinctrl-single-omap.c
new file mode 100644
index 000..680cf81
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-single-omap.c
@@ -0,0 +1,287 @@
+/*
+ * pinctrl-single-omap - omap specific wake-up irq handler
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/platform_data/pinctrl-single-omap.h
+#include linux/pm_runtime.h
+
+#include pinctrl-single.h
+
+#define OMAP_WAKEUP_EN (1 14)
+#define OMAP_WAKEUP_EVENT (1 15)
+#define OMAP_WAKEUP_EVENT_MASK (OMAP_WAKEUP_EN | OMAP_WAKEUP_EVENT)
+
+struct pcs_omap {
+ unsigned int irq;
+ struct device *dev;
+ struct list_head wakeirqs;
+ struct pcs_soc soc;
+ void (*reconfigure_io_chain)(void);
+ struct mutex mutex;
+};
+
+static int pcs_omap_reg_init(const struct pcs_soc *soc, struct pcs_reg *r)
+{
+ struct pcs_omap *pcso = container_of(soc, struct pcs_omap, soc);
+ struct list_head *pos;
+ struct pcs_reg *pcsoi;
+ int res = 0;
+
+ if (!(r-val OMAP_WAKEUP_EN))
+ return 0;
+
+ if (r-irq = 0)
+ return 0;
+
+ mutex_lock(pcso-mutex);
+ list_for_each(pos, pcso-wakeirqs) {
+ pcsoi = list_entry(pos, struct pcs_reg, node);
+ if (r-reg == pcsoi-reg) {
+ pcsoi-read = r-read;
+ pcsoi-write = r-write;
+ pcsoi-reg = r-reg;
+ pcsoi-val = r-val;
+ pcsoi-irq = r-irq;
+ pcsoi-gpio = r-gpio;
+ res++;
+ goto out;
+ }
+ }
+ pcsoi = devm_kzalloc(pcso-dev, sizeof(*r), GFP_KERNEL);
+ if (!pcsoi) {
+ mutex_unlock(pcso-mutex);
+ res = -ENOMEM;
+ goto out;
+ }
+ *pcsoi = *r;
+ list_add_tail(pcsoi-node, pcso-wakeirqs);
+
+out:
+ mutex_unlock(pcso-mutex);
+
+ if (res pcso-reconfigure_io_chain)
+ pcso-reconfigure_io_chain();
+
+ return res 0 ? 0 : res;
+}
+
+static int pcs_update_list(const struct pcs_soc *soc, struct pcs_reg *r)
+{
+ struct pcs_omap *pcso = container_of(soc, struct pcs_omap, soc);
+ struct list_head *pos;
+ int changed = 0;
+
+ if (!r-irq)
+ return 0;
+
+ mutex_lock(pcso-mutex);
+ list_for_each(pos, pcso-wakeirqs) {
+ struct pcs_reg *pcsoi;
+
+ pcsoi = list_entry(pos, struct pcs_reg, node);
+ if ((r-reg == pcsoi-reg)
+ (r-val != pcsoi-val)) {
+ pcsoi-val = r-val;
+ changed++;
+ }
+ }
+ mutex_unlock(pcso-mutex);
+
+ if (pcso-reconfigure_io_chain changed)
+ pcso-reconfigure_io_chain();
+
+ return 0;
+}
+
+static int pcs_omap_enable(const struct pcs_soc
[PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware. The wake-up
event can be device specific, or may need to be dynamically
remuxed to GPIO input for wake-up events. When the wake-up
event happens, it's IRQ need to be called so the device won't
lose interrupts.
Allow supporting IRQ and GPIO wake-up events if a hardware
spefific module is registered for the enable and disable
calls.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/pinctrl/pinctrl-single.txt |5 +
drivers/pinctrl/pinctrl-single.c | 104 +---
drivers/pinctrl/pinctrl-single.h | 28 +
3 files changed, 123 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 08f0c3d..5dfd74b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -68,6 +68,10 @@ Optional properties:
The number of parameters is depend on #pinctrl-single,gpio-range-cells
property.
+- interrrupts : the interrupt that a function may have for a wake-up event
+
+- gpios: the gpio that a function may have for a wake-up event
+
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
@@ -204,6 +208,7 @@ pmx_gpio: pinmux@d401e000 {
0xdc 0x118
0xde 0
;
+ interrupts = 74;
};
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 0f178d1..7cb7940 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -95,6 +97,8 @@ struct pcs_conf_type {
* @nvals: number of entries in vals array
* @pgnames: array of pingroup names the function uses
* @npgnames: number of pingroup names the function uses
+ * @irq: optional irq associated with the function
+ * @gpio: optional gpio associated with the function
* @node: list node
*/
struct pcs_function {
@@ -105,6 +109,8 @@ struct pcs_function {
int npgnames;
struct pcs_conf_vals *conf;
int nconfs;
+ int irq;
+ int gpio;
struct list_head node;
};
@@ -410,6 +416,18 @@ static int pcs_get_function(struct pinctrl_dev *pctldev,
unsigned pin,
return 0;
}
+static void pcs_reg_init(struct pcs_reg *p, struct pcs_device *pcs,
+struct pcs_function *func,
+void __iomem *reg, unsigned val)
+{
+ p-read = pcs-read;
+ p-write = pcs-write;
+ p-irq = func-irq;
+ p-gpio = func-gpio;
+ p-reg = reg;
+ p-val = val;
+}
+
static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
unsigned group)
{
@@ -442,6 +460,12 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
val = ~mask;
val |= (vals-val mask);
pcs-write(val, vals-reg);
+ if ((func-irq || func-gpio) pcs-soc pcs-soc-enable) {
+ struct pcs_reg pcsr;
+
+ pcs_reg_init(pcsr, pcs, func, vals-reg, val);
+ pcs-soc-enable(pcs-soc, pcsr);
+ }
}
return 0;
@@ -466,18 +490,6 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
return;
}
- /*
-* Ignore disable if function-off is not specified. Some hardware
-* does not have clearly defined disable function. For pin specific
-* off modes, you can use alternate named states as described in
-* pinctrl-bindings.txt.
-*/
- if (pcs-foff == PCS_OFF_DISABLED) {
- dev_dbg(pcs-dev, ignoring disable for %s function%i\n,
- func-name, fselector);
- return;
- }
-
dev_dbg(pcs-dev, disabling function%i %s\n,
fselector, func-name);
@@ -488,8 +500,28 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
vals = func-vals[i];
val = pcs-read(vals-reg);
val = ~pcs-fmask
[PATCH 1/4] pinctrl: single: Prepare for supporting SoC specific features
Let's replace is_pinconf with flags and add struct pcs_soc so we
can support also other features like pin wake-up events. Let's
export the probe so the SoC specific modules can pass their
SoC specific data to pinctrl-single if needed.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/pinctrl-single.c | 53 +++---
drivers/pinctrl/pinctrl-single.h | 15 +++
2 files changed, 52 insertions(+), 16 deletions(-)
create mode 100644 drivers/pinctrl/pinctrl-single.h
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index b9fa046..0f178d1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -26,6 +26,7 @@
#include core.h
#include pinconf.h
+#include pinctrl-single.h
#define DRIVER_NAMEpinctrl-single
#define PCS_MUX_PINS_NAME pinctrl-single,pins
@@ -162,7 +163,7 @@ struct pcs_name {
* @fshift:function register shift
* @foff: value to turn mux off
* @fmax: max number of functions in fmask
- * @is_pinconf:whether supports pinconf
+ * @flags: supported features
* @names: array of register names for pins
* @pins: physical pins on the SoC
* @pgtree:pingroup index radix tree
@@ -175,6 +176,7 @@ struct pcs_name {
* @desc: pin controller descriptor
* @read: register read function to use
* @write: register write function to use
+ * @soc: SoC glue
*/
struct pcs_device {
struct resource *res;
@@ -189,7 +191,7 @@ struct pcs_device {
unsigned foff;
unsigned fmax;
bool bits_per_mux;
- bool is_pinconf;
+ unsigned flags;
struct pcs_name *names;
struct pcs_data pins;
struct radix_tree_root pgtree;
@@ -202,6 +204,7 @@ struct pcs_device {
struct pinctrl_desc desc;
unsigned (*read)(void __iomem *reg);
void (*write)(unsigned val, void __iomem *reg);
+ const struct pcs_soc *soc;
};
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
@@ -1026,7 +1029,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
struct device_node *np,
};
/* If pinconf isn't supported, don't parse properties in below. */
- if (!pcs-is_pinconf)
+ if (!(pcs-flags PCS_HAS_PINCONF))
return 0;
/* cacluate how much properties are supported in current node */
@@ -1165,7 +1168,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device
*pcs,
(*map)-data.mux.group = np-name;
(*map)-data.mux.function = np-name;
- if (pcs-is_pinconf) {
+ if (pcs-flags PCS_HAS_PINCONF) {
res = pcs_parse_pinconf(pcs, np, function, map);
if (res)
goto free_pingroups;
@@ -1346,18 +1349,14 @@ static int pcs_add_gpio_func(struct device_node *node,
struct pcs_device *pcs)
return ret;
}
-static int pcs_probe(struct platform_device *pdev)
+int pinctrl_single_probe(struct platform_device *pdev,
+const struct pcs_soc *soc)
{
struct device_node *np = pdev-dev.of_node;
- const struct of_device_id *match;
struct resource *res;
struct pcs_device *pcs;
int ret;
- match = of_match_device(pcs_of_match, pdev-dev);
- if (!match)
- return -EINVAL;
-
pcs = devm_kzalloc(pdev-dev, sizeof(*pcs), GFP_KERNEL);
if (!pcs) {
dev_err(pdev-dev, could not allocate\n);
@@ -1368,7 +1367,8 @@ static int pcs_probe(struct platform_device *pdev)
INIT_LIST_HEAD(pcs-pingroups);
INIT_LIST_HEAD(pcs-functions);
INIT_LIST_HEAD(pcs-gpiofuncs);
- pcs-is_pinconf = match-data;
+ pcs-flags = soc-flags;
+ pcs-soc = soc;
PCS_GET_PROP_U32(pinctrl-single,register-width, pcs-width,
register width not specified\n);
@@ -1437,7 +1437,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs-desc.name = DRIVER_NAME;
pcs-desc.pctlops = pcs_pinctrl_ops;
pcs-desc.pmxops = pcs_pinmux_ops;
- if (pcs-is_pinconf)
+ if (pcs-flags PCS_HAS_PINCONF)
pcs-desc.confops = pcs_pinconf_ops;
pcs-desc.owner = THIS_MODULE;
@@ -1466,8 +1466,20 @@ free:
return ret;
}
+EXPORT_SYMBOL_GPL(pinctrl_single_probe);
+
+static int pcs_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+
+ match = of_match_device(pcs_of_match, pdev-dev);
+ if (!match)
+ return -EINVAL;
+
+ return pinctrl_single_probe(pdev, (struct pcs_soc *)match-data);
+}
-static int pcs_remove(struct platform_device *pdev)
+int
[PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/Makefile |3
drivers/pinctrl/pinctrl-single-omap.c | 287 +
include/linux/platform_data/pinctrl-single-omap.h |4
3 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 drivers/pinctrl/pinctrl-single-omap.c
create mode 100644 include/linux/platform_data/pinctrl-single-omap.h
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9bdaeb8..abf7f01 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -30,7 +30,8 @@ obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o
obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o
obj-$(CONFIG_PINCTRL_DB8500) += pinctrl-nomadik-db8500.o
obj-$(CONFIG_PINCTRL_DB8540) += pinctrl-nomadik-db8540.o
-obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
+pcs-$(CONFIG_ARCH_OMAP2PLUS) += pinctrl-single-omap.o
+obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o $(pcs-y)
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
diff --git a/drivers/pinctrl/pinctrl-single-omap.c
b/drivers/pinctrl/pinctrl-single-omap.c
new file mode 100644
index 000..680cf81
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-single-omap.c
@@ -0,0 +1,287 @@
+/*
+ * pinctrl-single-omap - omap specific wake-up irq handler
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/err.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/platform_data/pinctrl-single-omap.h
+#include linux/pm_runtime.h
+
+#include pinctrl-single.h
+
+#define OMAP_WAKEUP_EN (1 14)
+#define OMAP_WAKEUP_EVENT (1 15)
+#define OMAP_WAKEUP_EVENT_MASK (OMAP_WAKEUP_EN | OMAP_WAKEUP_EVENT)
+
+struct pcs_omap {
+ unsigned int irq;
+ struct device *dev;
+ struct list_head wakeirqs;
+ struct pcs_soc soc;
+ void (*reconfigure_io_chain)(void);
+ struct mutex mutex;
+};
+
+static int pcs_omap_reg_init(const struct pcs_soc *soc, struct pcs_reg *r)
+{
+ struct pcs_omap *pcso = container_of(soc, struct pcs_omap, soc);
+ struct list_head *pos;
+ struct pcs_reg *pcsoi;
+ int res = 0;
+
+ if (!(r-val OMAP_WAKEUP_EN))
+ return 0;
+
+ if (r-irq = 0)
+ return 0;
+
+ mutex_lock(pcso-mutex);
+ list_for_each(pos, pcso-wakeirqs) {
+ pcsoi = list_entry(pos, struct pcs_reg, node);
+ if (r-reg == pcsoi-reg) {
+ pcsoi-read = r-read;
+ pcsoi-write = r-write;
+ pcsoi-reg = r-reg;
+ pcsoi-val = r-val;
+ pcsoi-irq = r-irq;
+ pcsoi-gpio = r-gpio;
+ res++;
+ goto out;
+ }
+ }
+ pcsoi = devm_kzalloc(pcso-dev, sizeof(*r), GFP_KERNEL);
+ if (!pcsoi) {
+ mutex_unlock(pcso-mutex);
+ res = -ENOMEM;
+ goto out;
+ }
+ *pcsoi = *r;
+ list_add_tail(pcsoi-node, pcso-wakeirqs);
+
+out:
+ mutex_unlock(pcso-mutex);
+
+ if (res pcso-reconfigure_io_chain)
+ pcso-reconfigure_io_chain();
+
+ return res 0 ? 0 : res;
+}
+
+static int pcs_update_list(const struct pcs_soc *soc, struct pcs_reg *r)
+{
+ struct pcs_omap *pcso = container_of(soc, struct pcs_omap, soc);
+ struct list_head *pos;
+ int changed = 0;
+
+ if (!r-irq)
+ return 0;
+
+ mutex_lock(pcso-mutex);
+ list_for_each(pos, pcso-wakeirqs) {
+ struct pcs_reg *pcsoi;
+
+ pcsoi = list_entry(pos, struct pcs_reg, node);
+ if ((r-reg == pcsoi-reg)
+ (r-val != pcsoi-val
[PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4 ++--
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap5.dtsi |4 ++--
arch/arm/mach-omap2/mux.c|8 ++--
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/prm_common.c | 26 ++
6 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c018593..9b19b14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -172,6 +172,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = ~ignore_bits;
c++;
+ if (c 10)
+ break;
}
omap2_cm_write_mod_reg(iclk, module, iclk_off);
omap2_cm_write_mod_reg(fclk, module, fclk_off);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2
Re: [GIT PULL v2] ARM: dts: OMAP fixes for 3.10-rc5
* Benoit Cousson b-cous...@ti.com [130603 07:42]: Hi Tony, Please pull three DTS fixes for the next -rc. Thanks pulling into omap-for-v3.10/fixes. Regards, Tony The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linus Torvalds (1): Linux 3.10-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git dts-fixes-for-3.10 Kevin Hilman (1): ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line Lars Poeschel (1): ARM: dts: AM33xx: Fix properties on gpmc node Suman Anna (1): ARM: dts: OMAP5: Fix missing PWM capability to timer nodes arch/arm/boot/dts/am33xx.dtsi |4 ++-- arch/arm/boot/dts/omap4-panda-common.dtsi | 20 arch/arm/boot/dts/omap4-sdp.dts | 20 arch/arm/boot/dts/omap5.dtsi |3 +++ 4 files changed, 45 insertions(+), 2 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] serial: omap: fix potential NULL pointer dereference in serial_omap_runtime_suspend()
* Wei Yongjun weiyj...@gmail.com [130604 19:10]: From: Wei Yongjun yongjun_...@trendmicro.com.cn The dereference to 'up' should be moved below the NULL test. Introduced by commit ddd85e225c8885b5e4419b0499ab27100e7c366a (serial: omap: prevent runtime PM for no_console_suspend) Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/tty/serial/omap-serial.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 1aaeca8..156b5aa 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1613,6 +1613,9 @@ static int serial_omap_runtime_suspend(struct device *dev) struct uart_omap_port *up = dev_get_drvdata(dev); struct omap_uart_port_info *pdata = dev-platform_data; + if (!up) + return -EINVAL; + /* * When using 'no_console_suspend', the console UART must not be * suspended. Since driver suspend is managed by runtime suspend, @@ -1623,9 +1626,6 @@ static int serial_omap_runtime_suspend(struct device *dev) uart_console(up-port)) return -EBUSY; - if (!up) - return -EINVAL; - if (!pdata) return 0; ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v3 1/6] net: cpsw: enhance pinctrl support
* Mugunthan V N mugunthan...@ti.com [130530 01:14]:
On 5/28/2013 7:35 PM, Mugunthan V N wrote:
On 5/28/2013 3:06 AM, Tony Lindgren wrote:
* Mugunthan V N mugunthan...@ti.com [130526 11:28]:
From: Hebbar Gururaja gururaja.heb...@ti.com
Amend cpsw controller to optionally take a pin control handle and set
the state of the pins to:
- default on boot, resume
- sleep on suspend()
This should make it possible to optimize energy usage for the pins
for the suspend/resume cycle.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c
b/drivers/net/ethernet/ti/cpsw.c
index 21a5b29..c9ed730 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
+#include linux/pinctrl/consumer.h
#include cpsw_ale.h
#include cpts.h
@@ -351,6 +352,11 @@ struct cpsw_priv {
bool irq_enabled;
struct cpts *cpts;
u32 emac_port;
+
+/* Two optional pin states - default sleep */
+struct pinctrl*pinctrl;
+struct pinctrl_state*pins_def;
+struct pinctrl_state*pins_sleep;
};
Which pins do you need to dynamically remux? If it's not all
the pins, you should have three sets: default, active and idle.
This way the static pins in the default group don't need to be
constantly toggled.
Regards,
Tony
Tony
I am using this for all the pins, in probe all the cpsw pins will
be configured
and i have used the same in suspend/resume callback for power saving.
Tony
Do you have any comments on this, or is it ok with two pinctrl_state nodes?
If you always need to remux all the pins, then yes that's fine with me.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] pinctrl: pinctrl-single: enhance to configure multiple pins of different modules
* Manjunathappa, Prakash prakash...@ti.com [130521 07:13]: Add support to configure multiple pins in each register, existing implementation added by [1] does not support full fledge multiple pin configuration in single register, reports a pin clash when different modules configure different bits of same register. The issue reported and discussed here http://www.spinics.net/lists/arm-kernel/msg235213.html With pinctrl-single,bits-per-mux property specified, use function-mask property to find out number pins to configure. Allocate and register pin control functions based sub mask. Thanks for fixing this! Looks good to me, and things keep working for me just fine with these applied: Acked-by: Tony Lindgren t...@atomide.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support
* Hebbar Gururaja gururaja.heb...@ti.com [130531 03:19]: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. There's a similar patch in the [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode thread. It also makes the SDIO interrupts to work, so we need to consider that too. We can merge the dynamic pinmuxing parts separately, but they should be in a separate function like I posted later on in the thread above. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/3] clk: omap: introduce clock driver
* Mike Turquette mturque...@linaro.org [130603 23:45]: Parses OMAP clock data from DT and registers those clocks with the clock framework. dt_omap_clk_init must be called early during boot for timer initialization so it is exported and called from the existing clock code instead of probing like a real driver. Thanks for doing this, makes sense to me. I have queued up patches to make omap4 DT only, so this is the way to go. --- /dev/null +++ b/include/linux/clk/omap.h @@ -0,0 +1,24 @@ +/* + * Copyright (C) 2010 Broadcom + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __LINUX_CLK_OMAP_H_ +#define __LINUX_CLK_OMAP_H_ + +int __init dt_omap_clk_init(void); + +#endif Maybe leave out the Broadcom copyright from this header? :) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 2/3] ARM: dts: omap4 clock data
* Mike Turquette mturque...@linaro.org [130603 23:45]: This is a first pass at creating a unique node for each clock in the OMAP4 power, reset and clock manager (PRCM). So far I have only converted mux clocks fixed-rate clocks, which coexist with the current clock data in the kernel. The rest needs to be done but better to publish early and often to see what others think of this approach. +/* FIXME need to print the address directly */ +/* +#include ../../mach-omap2/prm44xx.h +#include ../../mach-omap2/cm2_44xx.h +#include ../../mach-omap2/cm1_44xx.h +*/ I don't think you're using the above includes any longer in this file? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 2/3] ARM: dts: omap4 clock data
* Mike Turquette mturque...@linaro.org [130604 11:40]: Quoting Tony Lindgren (2013-06-04 07:55:43) * Mike Turquette mturque...@linaro.org [130603 23:45]: This is a first pass at creating a unique node for each clock in the OMAP4 power, reset and clock manager (PRCM). So far I have only converted mux clocks fixed-rate clocks, which coexist with the current clock data in the kernel. The rest needs to be done but better to publish early and often to see what others think of this approach. +/* FIXME need to print the address directly */ +/* +#include ../../mach-omap2/prm44xx.h +#include ../../mach-omap2/cm2_44xx.h +#include ../../mach-omap2/cm1_44xx.h +*/ I don't think you're using the above includes any longer in this file? Correct. I actually spotted this before emailing the patches out at midnight, but by then I didn't care to fix it. The benefits of marking a patch as RFC ;-) :) I had a mind to use the new preprocessor capabilities of dtc for the PRCM bit masks and shift values, but instead I ended up using the raw hex values. I've actually come to prefer using the raw hex values for DT, which I think makes more sense for a description of the hardware which is not tied to any Linux implementation. Agreed, especially if the value is only used once. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Andreas Fenkart andreas.fenk...@streamunlimited.com [130531 01:05]: Hi, this email adress will soon expire, my alternate email adress is OK, noticed that the SDIO wake behaves in a different way between wl12xx and mwifiex, and there's an issue with the muxing still for legacy non-SDIO booting. So at least one more update coming from me for this patch. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/RFT] ARM: dts: add minimal DT support for Nokia N950 N9
* Aaro Koskinen aaro.koski...@iki.fi [130529 14:02]: Hi, On Thu, May 23, 2013 at 09:22:04AM +0200, Benoit Cousson wrote: On 05/22/2013 09:44 PM, Aaro Koskinen wrote: Add minimal DT support for Nokia N950 N9. The basic boot works. I can connect to both devices with USB networking ssh. dmesg output looks OK. That's great! Tony will like that :-) It is too bad I just have a N900 :-( Functionality compared to the legacy board file: - MMC not detected - reason unknown, any tips welcome On OMAP4 panda I used to have the similar issue due to the pbias not set properly. - OneNAND missing completely The GPMC for OMAP3 support is pretty new, so maybe some tweak are still needed. Is it RFC because you are still working on the missing functionalities? Otherwise the patches are already good to be merged if you want. As soon as you don't break legacy boot, we can merge even half-working DTS. I was hoping to get the MMC working and OneNAND binding added before merging this... If we could do that, we could deprecate the legacy board file as DT would offer the same functionality. Great sounds like a plan. Take a look at the wl12xx patches I posted for setting up the MMC regulators, that might help with the MMC. I doubt that the missing PBIAS support is an issue as the eMMC has it's own fixed regulator. Then the GPMC patches might do the trick with the OneNAND as there have been patches posted for various boards for NAND and smc911x. Anyway, if half-working DTS is also fine, I'll resend this as PATCH in a few days. Yes that's cool. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v3 1/6] net: cpsw: enhance pinctrl support
* Mugunthan V N mugunthan...@ti.com [130526 11:28]:
From: Hebbar Gururaja gururaja.heb...@ti.com
Amend cpsw controller to optionally take a pin control handle and set
the state of the pins to:
- default on boot, resume
- sleep on suspend()
This should make it possible to optimize energy usage for the pins
for the suspend/resume cycle.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 21a5b29..c9ed730 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
#include linux/if_vlan.h
#include linux/platform_data/cpsw.h
+#include linux/pinctrl/consumer.h
#include cpsw_ale.h
#include cpts.h
@@ -351,6 +352,11 @@ struct cpsw_priv {
bool irq_enabled;
struct cpts *cpts;
u32 emac_port;
+
+ /* Two optional pin states - default sleep */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pins_def;
+ struct pinctrl_state*pins_sleep;
};
Which pins do you need to dynamically remux? If it's not all
the pins, you should have three sets: default, active and idle.
This way the static pins in the default group don't need to be
constantly toggled.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/5] ARM: dts: OMAP2+: use pinctrl constants
* Florian Vaussard florian.vauss...@epfl.ch [130523 08:42]:
index f39b237..b3cc896 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -9,6 +9,7 @@
*/
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/pinctrl/omap.h
#include skeleton.dtsi
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 434288f..2518e6a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -81,18 +81,18 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins =
- 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
- 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
- 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
- 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
- 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
- 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
- 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
- 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
- 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
- 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
- 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
- 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ 0x5c0 (OMAP_PIN_OUTPUT | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk */
+ 0x5c2 (OMAP_PIN_OUTPUT | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp */
+ 0x5c4 (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir */
+ 0x5c6 (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt */
+ 0x5c8 (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 */
+ 0x5cA (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 */
+ 0x1a4 (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 */
+ 0x1a6 (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 */
+ 0x1a8 (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 */
+ 0x1aa (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 */
+ 0x1ac (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 */
+ 0x1ae (OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3)
/* USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 */
;
};
};
Nice!
While at it, can you lowercase the USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk
naming to usbb2_ulpittl_clk.usbb1_ulpiphy_clk? You can also leave out _MUXMODE
from these for consistency.
I wonder if we can leave out the OMAP_ prefix from the mux mode defines
here and just assume PIN_OUTPUT etc would not conflict with other SoC's
naming?
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/5] ARM: dts: OMAP2+: use existing constants for GPIOs
* Florian Vaussard florian.vauss...@epfl.ch [130523 08:42]:
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -29,13 +29,13 @@
heartbeat {
label = beagleboard::usr0;
- gpios = gpio5 22 0; /* 150 - D6 LED */
+ gpios = gpio5 22 GPIO_ACTIVE_HIGH; /* 150 - D6 LED
*/
linux,default-trigger = heartbeat;
};
mmc {
label = beagleboard::usr1;
- gpios = gpio5 21 0; /* 149 - D7 LED */
+ gpios = gpio5 21 GPIO_ACTIVE_HIGH; /* 149 - D7 LED
*/
linux,default-trigger = mmc0;
};
};
Great yeah this is the way to go instead of the fixed numbering.
Thanks for doing this.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Tony Lindgren t...@atomide.com [130520 19:55]: * Tony Lindgren t...@atomide.com [130520 14:03]: * Andreas Fenkart andreas.fenk...@streamunlimited.com [130515 01:51]: Without functional clock the omap_hsmmc module can't forward SDIO IRQs to the system. This patch reconfigures dat1 line as a gpio while the fclk is off. When the fclk is present it uses the standard SDIO IRQ detection of the module. The gpio irq is managed via the 'disable_depth' ref counter of the irq subsystem, this driver simply calls enable_irq/disable_irq when needed. sdio irqsdio irq unmasked masked - runtime default |1 | 2 runtime suspend |0 | 1 irq disable depth only when sdio irq is enabled AND the module is idle, the reference count drops to zero and the gpio irq is effectively armed. Patch was tested on AM335x/Stream800. Test setup was two modules with sdio wifi cards. Modules where connected to a dual-band AP, each module using a different band. One of module was running iperf as server the other as client connecting to the server in a while true loop. Test was running for 4+ weeks. There were about 60 Mio. suspend/resume transitions. Test was shut down regularly. Looks like this somehow breaks detecting of eMMC on mmc2 for me at least with the non-dt legacyboot. For a removable mmc1 still keeps working. For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp. Looks like that's because gpio0 is considered valid. But for these pins gpio0 is not valid, so let's cut the dependency to updating the pdata and ignore gpio0. We should also have three pinmux states: default, active and idle to avoid remuxing all the pins unnecessarily. The default pins should contain the fixed pins, active mmc_dat1, and idle the gpio pin. I've attempted to fix up these issues, did not add the wake-up events from Steve Sakoman's patch for the non-muxed case: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453 Based on the patch above, sounds like the wake-up events won't work for deeper idle states though. But we should probably still support those as most people run without the deeper idle states anyways. Actually, let's go with your patch with the pinmuxing changed. Then the active state support can be added later on. And let's not add any pinmuxing callbacks to the legacy booting mode, now there's at least some reason for people to move on to device tree based booting. Can you check if the following changes on top of your patch still work for you? Note that you need to update your .dts file for the new pinctrl states. Here's your original patch updated for the muxing for the default, active and idle states. Regards, Tony From: Andreas Fenkart andreas.fenk...@streamunlimited.com Date: Wed, 15 May 2013 10:45:14 +0200 Subject: [PATCH] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode. Without functional clock the omap_hsmmc module can't forward SDIO IRQs to the system. This patch reconfigures dat1 line as a gpio while the fclk is off. When the fclk is present it uses the standard SDIO IRQ detection of the module. The gpio irq is managed via the 'disable_depth' ref counter of the irq subsystem, this driver simply calls enable_irq/disable_irq when needed. sdio irqsdio irq unmasked masked - runtime default |1 | 2 runtime suspend |0 | 1 irq disable depth only when sdio irq is enabled AND the module is idle, the reference count drops to zero and the gpio irq is effectively armed. Patch was tested on AM335x/Stream800. Test setup was two modules with sdio wifi cards. Modules where connected to a dual-band AP, each module using a different band. One of module was running iperf as server the other as client connecting to the server in a while true loop. Test was running for 4+ weeks. There were about 60 Mio. suspend/resume transitions. Test was shut down regularly. Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com Reviewed-by: Grant Likely grant.lik...@secretlab.ca [t...@atomide.com: updated pin muxing and some comments] Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index ed271fc..5a3df37 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -20,6 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards ti,non-removable: non-removable slot (like eMMC) ti,needs-special-reset: Requires a special softreset sequence ti,needs-special-hs-handling
Re: [PATCH 2/5] ARM: dts: OMAP2+: create a DT header for GPIO
* Stephen Warren swar...@wwwdotorg.org [130522 08:32]: On 05/22/2013 08:27 AM, Florian Vaussard wrote: Define the OMAP_GPIO macro to conveniently use GPIO inside OMAP DT. For example: gpios = gpio6 3 0; /* GPIO 163 */ can be replaced by gpios = OMAP_GPIO(163, 0); diff --git a/include/dt-bindings/gpio/omap-gpio.h b/include/dt-bindings/gpio/omap-gpio.h +#define OMAP_GPIO_0_BANKgpio1 +#define OMAP_GPIO_1_BANKgpio1 +#define OMAP_GPIO_2_BANKgpio1 +#define OMAP_GPIO_3_BANKgpio1 There are a /lot/ of those. Is this really worth it? If the OMAP GPIO HW is already represented as a bunch of separate DT nodes which represent separate GPIO blocks, then I would have thought the syntax gpioN M 0 more directly represents what would be found in the HW manual? If not, surely the DT should have a single node to represent a single GPIO controller, which just happens to internally support a bunch of register arrays. Yes I agree, let's not go back to numbering anything except within the a single instance. If anything, we can put the gpio number into comments. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/5] ARM: dts: OMAP3: fix incorrect notation for musb-hdrc interrupt
* Florian Vaussard florian.vauss...@epfl.ch [130522 07:33]:
On OMAP3, the INTC interrupt controller has only 1 cell.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Thanks a similar fix is already queued up and on it's way to mainline
tree.
Regards,
Tony
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 15049b8..0f3be20 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -518,7 +518,7 @@
usb_otg_hs: usb_otg_hs@480ab000 {
compatible = ti,omap3-musb;
reg = 0x480ab000 0x1000;
- interrupts = 0 92 0x4, 0 93 0x4;
+ interrupts = 92, 93;
interrupt-names = mc, dma;
ti,hwmods = usb_otg_hs;
multipoint = 1;
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] ARM: dts: OMAP2+: use #include for all device trees
* Florian Vaussard florian.vauss...@epfl.ch [130522 07:33]: Replace /include/ by #include for OMAP2+ DT, in order to use the C pre-processor, making use of #define features possible. This is good, but let's use it with case. Probably the best use for this right now is to add defines for the mux modes from mach-omap2/mux.h as that makes the raw values readable without comments. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Andreas Fenkart andreas.fenk...@streamunlimited.com [130515 01:51]:
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of the irq
subsystem, this driver simply calls enable_irq/disable_irq when needed.
sdio irqsdio irq
unmasked masked
-
runtime default |1 | 2
runtime suspend |0 | 1
irq disable depth
only when sdio irq is enabled AND the module is idle, the reference
count drops to zero and the gpio irq is effectively armed.
Patch was tested on AM335x/Stream800. Test setup was two modules
with sdio wifi cards. Modules where connected to a dual-band AP, each
module using a different band. One of module was running iperf as server
the other as client connecting to the server in a while true loop. Test
was running for 4+ weeks. There were about 60 Mio. suspend/resume
transitions. Test was shut down regularly.
Looks like this somehow breaks detecting of eMMC on mmc2 for me at least
with the non-dt legacyboot. For a removable mmc1 still keeps working.
For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp.
Also few comments below.
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
+ host-pinctrl = devm_pinctrl_get(pdev-dev);
+ if (IS_ERR(host-pinctrl)) {
+ ret = PTR_ERR(host-pinctrl);
+ goto err_pinctrl;
+ }
+
+ host-active = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(host-active)) {
+ dev_warn(mmc_dev(host-mmc), Unable to lookup active
pinmux\n);
+ ret = PTR_ERR(host-active);
+ goto err_pinctrl_state;
+ }
This should be checked, we have systems with all muxing done statically
in the bootloader. And we also have systems that provide the default
pinctrl state only as they don't need remuxing. So at most a warning should
be printed.
static int omap_hsmmc_runtime_resume(struct device *dev)
{
struct omap_hsmmc_host *host;
+ unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_restore(host);
dev_dbg(dev, enabled\n);
- return 0;
+ if (mmc_slot(host).sdio_irq host-pinctrl) {
+ disable_irq(mmc_slot(host).sdio_irq);
+
+ ret = pinctrl_select_state(host-pinctrl, host-active);
+ if (ret 0) {
+ dev_warn(mmc_dev(host-mmc), Unable to select active
pinmux\n);
+ return ret;
+ }
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ host-active_pinmux = true;
+
+ if (host-sdio_irq_en) {
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
+ OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+ }
+ return ret;
}
The check for sdio_irq host-pinctrl looks broken too as we may
have not dynamic muxing via pinctrl needed for let's say omap3 based
systems.
Other than that, looks good to me.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.
* Tony Lindgren t...@atomide.com [130520 14:03]:
* Andreas Fenkart andreas.fenk...@streamunlimited.com [130515 01:51]:
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of the irq
subsystem, this driver simply calls enable_irq/disable_irq when needed.
sdio irqsdio irq
unmasked masked
-
runtime default |1 | 2
runtime suspend |0 | 1
irq disable depth
only when sdio irq is enabled AND the module is idle, the reference
count drops to zero and the gpio irq is effectively armed.
Patch was tested on AM335x/Stream800. Test setup was two modules
with sdio wifi cards. Modules where connected to a dual-band AP, each
module using a different band. One of module was running iperf as server
the other as client connecting to the server in a while true loop. Test
was running for 4+ weeks. There were about 60 Mio. suspend/resume
transitions. Test was shut down regularly.
Looks like this somehow breaks detecting of eMMC on mmc2 for me at least
with the non-dt legacyboot. For a removable mmc1 still keeps working.
For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp.
Looks like that's because gpio0 is considered valid. But for these pins
gpio0 is not valid, so let's cut the dependency to updating the pdata
and ignore gpio0.
We should also have three pinmux states: default, active and idle to
avoid remuxing all the pins unnecessarily. The default pins should
contain the fixed pins, active mmc_dat1, and idle the gpio pin.
I've attempted to fix up these issues, did not add the wake-up events
from Steve Sakoman's patch for the non-muxed case:
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
Based on the patch above, sounds like the wake-up events won't work
for deeper idle states though. But we should probably still support
those as most people run without the deeper idle states anyways.
Can you check if the following changes on top of your patch still
work for you? Note that you need to update your .dts file for the
new pinctrl states.
Regards,
Tony
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -186,7 +186,7 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
boolsdio_irq_en;
struct pinctrl *pinctrl;
- struct pinctrl_state*active, *idle;
+ struct pinctrl_state*fixed, *active, *idle;
boolactive_pinmux;
struct omap_mmc_platform_data *pdata;
@@ -434,7 +434,8 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
- if (gpio_is_valid(pdata-slots[0].gpio_cirq)) {
+ if (pdata-slots[0].gpio_cirq 0
+ gpio_is_valid(pdata-slots[0].gpio_cirq)) {
pdata-slots[0].sdio_irq =
gpio_to_irq(pdata-slots[0].gpio_cirq);
@@ -1635,7 +1636,7 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- u32 irq_mask;
+ u32 irq_mask, con;
unsigned long flags;
spin_lock_irqsave(host-irq_lock, flags);
@@ -2116,35 +2117,43 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_disable_irq(host);
+ mmc-caps |= MMC_CAP_SDIO_IRQ;
+
host-pinctrl = devm_pinctrl_get(pdev-dev);
- if (IS_ERR(host-pinctrl)) {
- ret = PTR_ERR(host-pinctrl);
- goto err_pinctrl;
- }
-
- host-active = pinctrl_lookup_state(host-pinctrl,
- PINCTRL_STATE_DEFAULT);
- if (IS_ERR(host-active)) {
- dev_warn(mmc_dev(host-mmc), Unable to lookup active
pinmux\n);
- ret = PTR_ERR(host-active);
- goto err_pinctrl_state;
- }
-
- if (mmc_slot(host).sdio_irq) {
- host-idle = pinctrl_lookup_state(host-pinctrl,
- PINCTRL_STATE_IDLE);
- if (IS_ERR(host-idle)) {
- dev_warn(mmc_dev(host-mmc), Unable to lookup idle
pinmux\n);
- ret = PTR_ERR(host-idle);
- goto err_pinctrl_state;
+ if (!IS_ERR(host-pinctrl)) {
+ host-fixed = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_DEFAULT
Re: [PATCH] ARM: dts: OMAP2+: Simplify NAND support
* Jon Hunter jon-hun...@ti.com [130430 07:16]: Commit 8c8a777 (ARM: OMAP2+: Add function to read GPMC settings from device-tree) added a device-tree property gpmc,device-nand to indicate is the GPMC child device is NAND. This commit should have updated the GPMC NAND documentation (Documentation/devicetree/bindings/mtd/gpmc-nand.txt) to list the property gpmc,device-nand as a required property and also updated the example. However, this property is redundant and not needed because the GPMC child device node for NAND is called nand. Therefore, remove this property. Signed-off-by: Jon Hunter jon-hun...@ti.com Thanks applying into omap-for-v3.11/gpmc. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
* Dan Murphy dmur...@ti.com [130509 11:13]: Can we cleanly append to omap4_pmx_core without overriding the whole node? I don't want to recreate the pmx_core node in the es file. Yes that should work just fine. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] ARM: dts: OMAP36xx/OMAP4460 Fix CPU OPP voltages
* Nishanth Menon n...@ti.com [130426 10:44]: Hi, It seems that I have not been paying close attention to actual voltage value seen on scope to map it back to verify the validity of the voltage value. Even though I did verify[1] that voltage did scale to values in DT entries, the values in the case of 3630 and 4460 were lower than what the spec voltage was as per opp_data files. This series is based off Benoit's tree here: http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts Commit ID's in the patches to indicate regressions are from there as well. Would be good to have this fix merged to 3.10 dts entries. I have cross verified that OMAP3430,3630,4430 and 4460 entries now match that of corresponding opp*_data.c My sincere apologies on the oversight. Nishanth Menon (2): ARM: dts: OMAP36xx: Fix CPU OPP voltages ARM: dts: OMAP4460: Fix CPU OPP voltages arch/arm/boot/dts/omap36xx.dtsi |6 +++--- arch/arm/boot/dts/omap4460.dtsi |6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) [1] http://marc.info/?l=linux-arm-kernelm=136580742724210w=2 Thanks applying both into omap-for-v3.10/dt-fixes. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
* Dan Murphy dmur...@ti.com [130418 11:35]:
On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
(..)
@@ -135,6 +136,25 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins =
+ ;
+ };
+};
Hi,
FYI, there was a recent discussion precisely on this topic, where Tomy
suggested to remove the empty section:
http://marc.info/?l=linux-omapm=136546635409232w=2
Apart from that, I just tested your patch on top of Tomy's
omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
EA3, A4 and ES.
Tested-by: Vincent Stehlé v-ste...@ti.com
Best regards,
V.
Thanks for testing Vincent
Is there a way to append the data to an already existing node?
I do not see a clean way.
If you have something in omap4-panda-common.dtsi and the same entry
in the omap4-panda-es.dts, the entries in omap4-panda-es.dts will
override and append the entries in omap4-panda-common.dtsi.
So I think you can avoid the empty entry that way.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
* Sekhar Nori nsek...@ti.com [130429 22:11]:
On 4/29/2013 1:25 PM, Gupta, Pekon wrote:
From: avinash philip avinashphi...@ti.com
NAND flash connected in am335x-evm on GPMC controller. This patch adds
device tree node in am3355-evm with GPMC contoller timing for NAND flash
interface, NAND partition table, ECC scheme, elm handle id.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Tested-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 98
+-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..1c2fd89 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,8 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0
+ nandflash_pins_s0;
Why add this to the board level fallback (called pinctrl hogs, I think)?
This can be part of nand node you added below so that the pinctrl will
take effect when nand gets probed instead of all the time.
Yes we should have all the pinctrl entries under the related drivers.
This makes it easy remux pins during runtime if needed, and also
allows unloading pinctrl-single.ko for development.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] ARM: OMAP2+: GPMC fixes for v3.10
* Jon Hunter jon-hun...@ti.com [130430 06:59]: The following changes since commit aecb65a34a780cd07fbaa652cc5d640f13f3ed5f: Merge branch 'omap-gpmc-for-v3.10-take2' of git://github.com/jonhunter/linux into omap-for-v3.10/gpmc (2013-04-04 11:22:33 -0700) are available in the git repository at: git://github.com/jonhunter/linux.git omap-gpmc-fixes-for-v3.10 for you to fetch changes up to b327b3627bb428eb7d98f25224532425a673d89e: ARM: OMAP2+: only WARN if a GPMC child probe function fail (2013-04-30 08:43:05 -0500) GPMC fixes for v3.10. Main fix is to only search the GPMC node for GPMC child devices and not the entire device-tree (which was breaking ethernet support on some boards where the GPMC does not interface with the ethernet chip). This branch is based upon Tony's omap-for-v3.10/gpmc branch. Thanks pulling into omap-for-v3.10/fixes. Regards, Tony Javier Martinez Canillas (3): Documentation: dt: update TI GPMC ethernet binding properties ARM: OMAP2+: only search for GPMC DT child nodes on probe ARM: OMAP2+: only WARN if a GPMC child probe function fail Jon Hunter (1): Documentation: dt: update properties in TI GPMC NAND example .../devicetree/bindings/mtd/gpmc-nand.txt | 28 +- Documentation/devicetree/bindings/net/gpmc-eth.txt | 56 ++-- arch/arm/mach-omap2/gpmc.c | 38 + 3 files changed, 54 insertions(+), 68 deletions(-) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3,2/3] ARM: dts: AM33XX: Add GPMC node
* Gupta, Pekon pe...@ti.com [130502 02:49]:
From: Philip, Avinash avinashphi...@ti.com
Add GPMC data node to AM33XX device tree file.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Signed-off-by: Pekon Gupta pe...@ti.com
Thanks adding into omap-for-v3.10/dt-fixes.
Tony
---
Changes in v2:
- Change number of chip select to 7
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 24fc835..1048795 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -407,5 +407,17 @@
ti,hwmods = elm;
status = disabled;
};
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x2000;
+ interrupts = 100;
+ num-cs = 7;
+ num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ status = disabled;
+ };
};
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
* Koen Kooi k...@dominion.thruhere.net [130426 02:39]: Op 26 apr. 2013, om 05:52 heeft Tony Lindgren t...@atomide.com het volgende geschreven: Without WLAN we cannot switch omap4 to use device tree only booting. This patch can be reverted when the binding for wl12xx is added. How much boards am I allowed to add to this? I need to get the wl12xx wifi expansionboards for beagleboard, beagleboard xM and beaglebone working with DT :) As long as it's trivial changes, go for it. It will be gone after we have the binding for wl12xx. But let's not add the bluetooth serial port hack.. And let's not churn the board-*.c files, at this point pretty much the next step is to start dropping the board-*.c files. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for pandaboard
* Luciano Coelho coe...@ti.com [130426 06:29]:
On Thu, 2013-04-25 at 20:52 -0700, Tony Lindgren wrote:
This is needed to get wl12xx working with device tree based
booting.
Note that we claim the various GPIO inputs in the regulator
as the proper muxing is needed to enable and disable the
regulator.
Also, we want to use non-removable instead of ti,non-removable
as the ti,non-removable also sets no_regulator_off_init which
is really not what we want as then wl12xx won't get powered
up and down which is needed for resetting it.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
I tried this now and it seems to work fine too. So:
Tested-by: Luciano Coelho coe...@ti.com
Except that with linux-next I'm getting some problems with the
interrupts when trying to use wl12xx. It's not related to this patch
though, and I'm investigating it right now.
One thing I was worried is the early use of gpio_to_irq()
that's probably not safe always. We could fix that by moving the
gpio_to_irq() call to the driver if that's a problem.
But if the gpio_to_irq() is not the issue, can you please just
add a minimal binding to the wl12xx code so we can get rid of the
pdata init for the DT booting?
We can pass the clock reference the same way as we've discussed
already regarding the USB transceiver patch. Or you might be able
to find it out in the driver probe just by doing clk_get() and
clk_get_rate() on the source clock.
And the GPIO is just a standard resource that already has a
binding.
Also, I found one small whitespace problem in this patch:
[...]
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x38 0x103 /* gpmc_ncs2.gpio_52 INPUT | MODE3 */
+ 0x3a 0x103 /* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+ 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+ 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
+ 0x10c 0x118 /* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP
| MODE0 */
+ 0x10e 0x118 /* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP
| MODE0 */
+ 0x110 0x118 /* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP
| MODE0 */
+ 0x112 0x118 /* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP
| MODE0 */
+ ;
git am reports a space before tab in indent here.
OK thanks, will fix.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/3] ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
Without WLAN we cannot switch omap4 to use device tree
only booting. This patch can be reverted when the
binding for wl12xx is added.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 73762ac..69c520e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/gpio.h
#include linux/slab.h
#include linux/of.h
#include linux/pinctrl/machine.h
@@ -22,6 +23,7 @@
#include linux/platform_data/omap_ocp2scp.h
#include linux/platform_data/mailbox-omap.h
#include linux/usb/omap_control_usb.h
+#include linux/wl12xx.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -640,6 +642,40 @@ static void __init omap_init_ocp2scp(void)
static inline void omap_init_ocp2scp(void) { }
#endif
+#if IS_ENABLED(CONFIG_WL12XX)
+
+static struct wl12xx_platform_data wl12xx __initdata;
+
+void __init omap_init_wl12xx_of(void)
+{
+ int ret;
+
+ if (!of_have_populated_dt())
+ return;
+
+ if (of_machine_is_compatible(ti,omap4-sdp)) {
+ wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
+ wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
+ wl12xx.irq = gpio_to_irq(53);
+ } else if (of_machine_is_compatible(ti,omap4-panda)) {
+ wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
+ wl12xx.irq = gpio_to_irq(53);
+ } else {
+ return;
+ }
+
+ ret = wl12xx_set_platform_data(wl12xx);
+ if (ret) {
+ pr_err(error setting wl12xx data: %d\n, ret);
+ return;
+ }
+}
+#else
+static inline omap_init_wl12xx_of(void)
+{
+}
+#endif
+
/*-*/
static int __init omap2_init_devices(void)
@@ -664,6 +700,9 @@ static int __init omap2_init_devices(void)
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
+ } else {
+ /* These can be removed when bindings are done */
+ omap_init_wl12xx_of();
}
omap_init_sti();
omap_init_rng();
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for pandaboard
This is needed to get wl12xx working with device tree based
booting.
Note that we claim the various GPIO inputs in the regulator
as the proper muxing is needed to enable and disable the
regulator.
Also, we want to use non-removable instead of ti,non-removable
as the ti,non-removable also sets no_regulator_off_init which
is really not what we want as then wl12xx won't get powered
up and down which is needed for resetting it.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 628f744..16b23bf 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -86,6 +86,19 @@
clock-names = main_clk;
clock-frequency = 1920;
};
+
+ /* regulator for wl12xx on sdio5 */
+ wl12xx_vmmc: wl12xx_vmmc {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_gpio;
+ compatible = regulator-fixed;
+ regulator-name = vwl1271;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio2 11 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_core {
@@ -185,6 +198,30 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ /* wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP */
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x26 0x3/* gpmc_a19.gpio_43 OUTPUT | MODE3 */
+ 0x2c 0x3/* gpmc_a22.gpio_46 OUTPUT | MODE3 */
+ 0x30 0xb/* gpmc_a24.gpio_48 OUTPUT | MODE3 */
+ 0x32 0xb/* gpmc_a25.gpio_49 OUTPUT | MODE3 */
+ ;
+ };
+
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x38 0x103 /* gpmc_ncs2.gpio_52 INPUT | MODE3 */
+ 0x3a 0x103 /* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+ 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+ 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
+ 0x10c 0x118 /* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP
| MODE0 */
+ 0x10e 0x118 /* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP
| MODE0 */
+ 0x110 0x118 /* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP
| MODE0 */
+ 0x112 0x118 /* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP
| MODE0 */
+ ;
+ };
};
i2c1 {
@@ -264,8 +301,12 @@
};
mmc5 {
- ti,non-removable;
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_pins;
+ vmmc-supply = wl12xx_vmmc;
+ non-removable;
bus-width = 4;
+ cap-power-off-card;
};
emif1 {
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] ARM: dts: Add muxing for wl12xx on the SDIO bus for blaze
This should work assuming the board-4430sdp.c works, but it seems
that I don't have the 1283 PG 2.21 connectivity device on
my blaze. Anybody got a spare connectivity device for blaze?
Also, if somebody has the schematics, please provide a patch
for the missing GPIO muxes for blaze, see the the panda for
what's currently missing.
Cc: Luciano Coelho coe...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ruslan Bilovol ruslan.bilo...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap4-sdp.dts | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index a35d9cd..c13c483 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,19 @@
DMic, Digital Mic,
Digital Mic, Digital Mic1 Bias;
};
+
+ /* regulator for wl12xx on sdio5 */
+ wl12xx_vmmc: wl12xx_vmmc {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_gpio;
+ compatible = regulator-fixed;
+ regulator-name = vwl1271;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio2 22 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_core {
@@ -275,6 +288,26 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ /* wl12xx GPIO output for WLAN_EN */
+ wl12xx_gpio: pinmux_wl12xx_gpio {
+ pinctrl-single,pins =
+ 0x3c 0x3/* gpmc_nwp.gpio_54 OUTPUT | MODE3 */
+ ;
+ };
+
+ /* wl12xx GPIO inputs and SDIO pins */
+ wl12xx_pins: pinmux_wl12xx_pins {
+ pinctrl-single,pins =
+ 0x3a 0x103 /* gpmc_ncs3.gpio_53 INPUT | MODE3 */
+ 0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+ 0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */
+ 0x10c 0x118 /* sdmmc5_dat0.sdmmc5_dat0 INPUT_PULLUP
| MODE0 */
+ 0x10e 0x118 /* sdmmc5_dat1.sdmmc5_dat1 INPUT_PULLUP
| MODE0 */
+ 0x110 0x118 /* sdmmc5_dat2.sdmmc5_dat2 INPUT_PULLUP
| MODE0 */
+ 0x112 0x118 /* sdmmc5_dat3.sdmmc5_dat3 INPUT_PULLUP
| MODE0 */
+ ;
+ };
};
i2c1 {
@@ -400,8 +433,12 @@
};
mmc5 {
+ pinctrl-names = default;
+ pinctrl-0 = wl12xx_pins;
+ vmmc-supply = wl12xx_vmmc;
+ non-removable;
bus-width = 4;
- ti,non-removable;
+ cap-power-off-card;
};
emif1 {
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Query on pinctrl usage for DT nodes
* Peter Ujfalusi peter.ujfal...@ti.com [130423 00:47]:
On 04/16/2013 11:32 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [130415 01:30]:
On 04/10/2013 10:34 PM, Tony Lindgren wrote:
Yeah how about just change the pintctrl-single,bits register
naming to be register + bit? Something like 0xdeadbeef.0 and
0xdeadbeef.1 and so on.
Something like this might work I think. It is going to be a bit tricky IMHO
since we might need span out new 'register' every time a device requests
for a
new pinctrl-single,bits for already used register in the
pinctrl-single,bit-per-mux area. In this way we still can make sure that
certain bit are only used by a single driver.
OK. If it's one bit per mux type register we should be able to create
the right amount of entries based on the submask in pinctrs-single,bit?
Right now it seams to be true that we have one bit per mux (in DEVCONF0 on
OMAP3 for example). So that would work fine, but There could be different
registers around with more than one bit per mux.
Yes you are right, we should cover that case too. But maybe we
can wait until we have such an example :)
Another way to deal with this is to:
in case of pinctrl-single,bit-per-mux we assume one bit per mux and create
entries based on the pinctrl-single,function-mask's bits.
In case we have more than one bit for the mux in the register we could have
optional property stating the number of different muxes handled by the
register.
Yes that's doable.
One bit per mux type:
control_devconf0: pinmux@48002274 {
compatible = pinctrl-single;
reg = 0x48002274 4; /* Single register */
#address-cells = 1;
#size-cells = 0;
pinctrl-single,bit-per-mux;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x5F;
};
Results six entries.
Yup, I think this is the way to go for now, see below..
control_devconf0: pinmux@48002274 {
compatible = pinctrl-single;
reg = 0x48002274 4; /* Single register */
#address-cells = 1;
#size-cells = 0;
pinctrl-single,bit-per-mux;
pinctrl-single,functions-in-register = 3;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x5F;
};
Will results three entries.
..but let's not add this. The reason why I'd like to postpone adding
pinctrl-single,functions-in-register is because we may be able to
do it automatically.
If it was just the naming is the issue, we could use the submask
for the naming the bits with something like 0x0x48002274-3-1 and
0x0x48002274-1-1.
But I think currently the pinctrl framework expects a static pin
table, so we can't create these entries dynamically when the
consumer driver starts using the bits. So the right fix there
would be to improve the pinctrl framework to allow adding pins
dynamically, see some of the REVISIT comments in pinctrl-single.c.
In both cases we still need to test overlaps in the handled bits.
Yes that's missing too.
So how about we do the following for now:
1. Fix the pinctrl-single,bits naming to use 0x0x48002274-1-1 to
represent the bit range
2. Automatically create entries for each bit and don't yet support
bit ranges except in the naming for future use
3. Add something to check the overlaps in the submasks
4. Assume we have one-bit-per-mux until we have a real example,
then improve the pinctrl framework to allow adding pins
dynamically as the consumer driver probes. Or if there are
other issues, add the pinctrl-single,functions-in-register
property at that point.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap4-panda: Add USB Host support
* Roger Quadros rog...@ti.com [130419 01:23]: On 04/18/2013 11:09 PM, Tony Lindgren wrote: the naming should be mode0name.modename to be consistent. Here's what I dumped out, please check and replace spaces with tabs: 0x82 0x10c /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk gpio84 INPUT_PULLDOWN | MODE4 */ 0x84 0x4/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp gpio85 OUTPUT | MODE4 */ 0x86 0x104 /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir gpio86 INPUT | MODE4 */ 0x88 0x104 /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt gpio87 INPUT | MODE4 */ 0x8a 0x104 /* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */ 0x8c 0x104 /* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 gpio89 INPUT | MODE4 */ 0x8e 0x104 /* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 gpio90 INPUT | MODE4 */ 0x90 0x104 /* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 gpio91 INPUT | MODE4 */ 0x92 0x104 /* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 gpio92 INPUT | MODE4 */ 0x94 0x104 /* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 gpio93 INPUT | MODE4 */ 0x96 0x104 /* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 gpio94 INPUT | MODE4 */ 0x98 0x104 /* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 gpio95 INPUT | MODE4 */ I don't think gpioXX is necessary as we aren't using any of them as GPIOs. Oops sorry yeah please check as that's something I just dumped from the system. The gpio numbering is just data for debugging that you can leave out. Also check please check I dumped the right pins, I just grepped for usbb1. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/4] ARM: dts: Add USB host support for Panda and Beagle-xm
* Roger Quadros rog...@ti.com [130419 03:02]: Hi Benoit/Tony I've consolidated all the USB host device tree patches for Panda and Beagles to one place and addressed Tony's comments. NOTE: patch 1 depends on OMAP clock binding introduced in https://lkml.org/lkml/2013/4/12/407 v3: - updated mux mode to use pulldowns on panda as non-DT boot uses pulldowns. - fixed usb pin naming for panda, beagle and beagle-xm Cool. Sounds like we should be able to make omap4 DT only for v3.11 then. For that we also need USB on 4430-sdp working, but it now does: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-omap 4a064c00.ehci: failed to get phys phandle in /ocp/usbhshost@4a064000/ehci@4a064c00 node ehci-omap 4a064c00.ehci: failed to get phys phandle in /ocp/usbhshost@4a064000/ehci@4a064c00 node ... As I have mine in a rack I don't have anything plugged into the USB port there though, but sounds like the phy is not initialized? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap4-panda: Add USB Host support
* Roger Quadros rog...@ti.com [130415 01:53]:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
The USB PHY needs AUXCLK3 to operate. Provide this information
as well.
Also provide pin multiplexer information for the USB host
pins.
This patch depends on OMAP clock binding introduced in
https://lkml.org/lkml/2013/4/12/407
Cool looks like EHCI works with this on my panda with linux
next booting with DT. One comment below.
Regards,
Tony
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 58
+
arch/arm/boot/dts/omap4.dtsi |5 ++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..628f744 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -54,6 +54,38 @@
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;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ clocks = auxclk3;
+ clock-names = main_clk;
+ clock-frequency = 1920;
+ };
};
omap4_pmx_core {
@@ -64,6 +96,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -108,6 +141,23 @@
;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 0x10C /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+ 0x84 0x4/*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x86 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x88 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x8a 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x8c 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x8e 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x90 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x92 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x94 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x96 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x98 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
Looks like your comments are wrong above, it's not PULLDOWN? Also
the naming should be mode0name.modename to be consistent. Here's
what I dumped out, please check and replace spaces with tabs:
0x82 0x10c /* usbb1_ulpitll_clk.usbb1_ulpiphy_clk
gpio84 INPUT_PULLDOWN | MODE4 */
0x84 0x4/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp
gpio85 OUTPUT | MODE4 */
0x86 0x104 /* usbb1_ulpitll_dir.usbb1_ulpiphy_dir
gpio86 INPUT | MODE4 */
0x88 0x104 /* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt
gpio87 INPUT | MODE4 */
0x8a 0x104 /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 gpio88 INPUT | MODE4 */
0x8c 0x104 /*
usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 gpio89 INPUT | MODE4 */
0x8e 0x104 /*
Re: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
* Igor Grinberg grinb...@compulab.co.il [130417 05:31]:
On 04/17/13 11:38, Roger Quadros wrote:
On 04/17/2013 10:56 AM, Igor Grinberg wrote:
On 04/17/13 04:30, Robert Nelson wrote:
On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren t...@atomide.com wrote:
* Roger Quadros rog...@ti.com [130415 05:44]:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..d394c51 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,60 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ /* 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;
+ enable-active-high; /* FIXME: active-low for Rev. C */
Benoit Tony,
Any ideas how to tackle the reversed logic for Rev. C boards?
Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
Bike-sheding, but we might want to make that omap3-beagle-xmc.dts as
there is the rev c variant of the original beagle...
It's too bad we can't read the 3 gpio pin states in the device tree
and make a decision.
I would recommend to move the detection to the boot loader and
adjust the DT blob at run time (in the boot loader).
This way, we will not need to deal with all the (sub)revision stuff.
Moving the detection to bootloader is fine, but modifying the DT at
runtime would create a debug/maintenance issue. Instead it could just
pick one of the .DTBs and pass it to kernel.
Like this will not create create any debug/maintenance issues ;-)
We have no problem with debug, as all the DT nodes can be seen in
both U-Boot (with fdt commands) and Linux through procfs...
I've just dropped my 2 cents and I don't really insist...
The dynamic configuration from the bootloader can also be done too, I
don't think they are mutually exclusive.
Since most users will be using rev-c, I think we should keep the original
file 'omap3-beagle-xm.dts as it is for rev-c boards.
I can just create a new dts file for Revisions A and B that will be
like so.
+++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
@@ -0,0 +1,6 @@
+/include/ omap3-beagle-xm.dts
+
+/* On Rev A/B USBHOST_PWR_EN is active high */
+hsusb2_power {
+ enable-active-high;
+};
Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
quite many differences, I don't think it is a good idea to create a common
file between the two.
Sounds good to me. But please also add the revision info to the compatible
flags for both .dts files.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [BUG] omap: mfd/regulator: twl/core: init order
* Grygorii Strashko grygorii.stras...@ti.com [130416 01:39]: On 04/16/2013 10:45 AM, Peter Ujfalusi wrote: On 04/15/2013 06:25 PM, Tony Lindgren wrote: This fix should not be needed. It just means the real problem is somewhere else. Pinctrl is already before the i2c in drivers/Makefile. Maybe one of the MFD drivers has a wrong initcall level? FYI; I just sent a patch which I believe is the correct way to fix this issue. Hi Tony, Peter OMAP i2c/pin-control initialization isn't controlled by Makefiles now (: - i2c initialized at subsys_initcall(omap_i2c_init_driver); AFAIK there should be no reason to have this as subsys_initcall any longer. It should be just regular module init. - pinctrl-single at module_platform_driver(pcs_driver) = module_init = device_initcall (if built-in) Yes but still, the deferred probe should handle this case too, I wonder why we're not seeing this issue on omap4 for example? And pls, pay attention on overall BUG description - twl-regulators initialization has been delayed as result all Regulators consumers (drivers which use regulators) will need to defer it's probe correctly too. For now it isn't true for many drivers and, for example, omap_hsmmc driver's probe will just fail if it can't get regulator. (+ problems with DSS - most probably Panel/DSI driver probe can't handle pin configuration) Sounds like there are a few places to fix. Got something available for these? Before, on early kernel versions, the OMAP pinmux was ready to work at arch_initcall time and most of the code has been created with this assumption. Yes. In general we've been moving to initializing things later on rather than earlier so we have a real console available for error messages instead of earlyprintk if something goes wrong. BTW, the legacy omap pinmux code will be going away as soon as we have moved platforms to use DT only booting. I think we can make omap4 DT only after v3.10, omap3 later on. Unfortunately, RTC is just a small part of problem. Can you try just setting the related drivers to be regular module initcalls and see if that solves the problem? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Query on pinctrl usage for DT nodes
* Peter Ujfalusi peter.ujfal...@ti.com [130415 01:30]: On 04/10/2013 10:34 PM, Tony Lindgren wrote: Yeah how about just change the pintctrl-single,bits register naming to be register + bit? Something like 0xdeadbeef.0 and 0xdeadbeef.1 and so on. Something like this might work I think. It is going to be a bit tricky IMHO since we might need span out new 'register' every time a device requests for a new pinctrl-single,bits for already used register in the pinctrl-single,bit-per-mux area. In this way we still can make sure that certain bit are only used by a single driver. OK. If it's one bit per mux type register we should be able to create the right amount of entries based on the submask in pinctrs-single,bit? Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
* Roger Quadros rog...@ti.com [130415 05:44]:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..d394c51 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,60 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ /* 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;
+ enable-active-high; /* FIXME: active-low for Rev. C */
Benoit Tony,
Any ideas how to tackle the reversed logic for Rev. C boards?
Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
common .dtsi.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [BUG] omap: mfd/regulator: twl/core: init order
* Grygorii Strashko grygorii.stras...@ti.com [130415 04:05]:
On 04/15/2013 01:56 PM, Christoph Fritz wrote:
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1014,7 +1014,18 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_driver_drv_init(void)
+{
+ return platform_driver_register(pcs_driver);
+}
+postcore_initcall(pcs_driver_drv_init);
+
+static void __exit pcs_driver_drv_exit(void)
+{
+ platform_driver_unregister(pcs_driver);
+}
+module_exit(pcs_driver_drv_exit);
+
Hi Grygorii,
thanks - indeed it does fix the problem. I checked at least the rtc
which is now configured right and working :-)
Do you consider the patch above as a hack or will it go mainline?
I think, need more opinions on this from community )
I'm just trying to solve my problem and found similar issue.
This fix should not be needed. It just means the real
problem is somewhere else. Pinctrl is already before the i2c
in drivers/Makefile. Maybe one of the MFD drivers has
a wrong initcall level?
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Nishanth Menon n...@ti.com [130412 16:43]:
Thanks for checking up. Fixed all of them below, will post part of
series again, only if I need to address further comments in other
patches..
Thanks it seems that the other ones are ready to go, just one
more comment below.
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,95 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon n...@ti.com
+ * Tony Lindgren t...@atomide.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/string.h
+
+static const struct of_device_id omap_clk_of_match[] = {
+ {.compatible = ti,omap-clock,},
+ {},
+};
+
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec: clkspec argument
+ * @data:unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void
*data)
+{
+ struct clk *clk;
+ char clk_name[32];
+ struct device_node *np = clkspec-np;
+
+ snprintf(clk_name, 32, %s_ck, np-name);
+ clk = clk_get(NULL, clk_name);
+ if (IS_ERR(clk)) {
+ pr_err(%s: could not get clock %s(%ld)\n, __func__,
+clk_name, PTR_ERR(clk));
+ goto out;
+ }
+ clk_put(clk);
It seems that clk_put() is actually wrong here. That's because
of_clk_get() should boild down to just the look up of the clock
and then clk_get() on it, so no double clk_get() is done in this
case. Once the consumer driver is done, it will just call clk_put()
on it.
+out:
+ return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:device node
+ *
+ * NOTE: we look up the clock lazily when the consumer driver does
+ * of_clk_get() and initialize a NULL clock here.
+ */
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ int res;
+ struct device_node *np = pdev-dev.of_node;
+
+ /* This allows the driver to of_clk_get() */
+ res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+ if (res)
+ dev_err(pdev-dev, could not add provider(%d)\n, res);
+
+ return res;
+}
+
+static struct platform_driver omap_clk_driver = {
+ .probe = omap_clk_probe,
+ .driver = {
+.name = omap_clk,
+.of_match_table = of_match_ptr(omap_clk_of_match),
+},
+};
+
+static int __init omap_clk_init(void)
+{
+ return platform_driver_register(omap_clk_driver);
+}
+arch_initcall(omap_clk_init);
+
+MODULE_DESCRIPTION(OMAP Clock driver);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_LICENSE(GPL v2);
Other than that looks OK to me.
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
* Nishanth Menon n...@ti.com [130412 15:59]:
--- /dev/null
+++ b/drivers/clk/omap/clk.c
+/**
+ * omap_clk_src_get() - Get OMAP clock from node name when needed
+ * @clkspec: clkspec argument
+ * @data:unused
+ *
+ * REVISIT: We assume the following:
+ * 1. omap clock names end with _ck
+ * 2. omap clock names are under 32 characters in length
+ */
+static struct clk *omap_clk_src_get(struct of_phandle_args *clkspec, void
*data)
+{
+ struct clk *clk;
+ char clk_name[32];
+ struct device_node *np = clkspec-np;
+
+ /* Set up things so consumer can call clk_get() with name */
I would leave out the comment above, it's a leftover from
the clk_add_alias() version that we don't need because of
of_clk_get().
+ snprintf(clk_name, 32, %s_ck, np-name);
+ clk = clk_get(NULL, clk_name);
+ if (IS_ERR(clk)) {
+ pr_err(%s: could not get clock %s(%ld)\n, __func__,
+clk_name, PTR_ERR(clk));
+ goto out;
+ }
+ clk_put(clk);
+
+out:
+ return clk;
+}
+
+/**
+ * omap_clk_probe() - create link from DT definition to clock data
+ * @pdev:device node
+ *
+ * NOTE: We assume that omap clocks are not removed.
+ */
How about drop the comment on clocks being removed above.
It no longer an issue, so maybe something like this instead:
* Note that we look up the clock lazily when the consumer
* driver does of_clk_get() and initialize a NULL clock here.
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ int res;
+ struct device_node *np = pdev-dev.of_node;
+
+ /* This allows the driver to of_clk_get() */
+ res = of_clk_add_provider(np, omap_clk_src_get, NULL);
+ if (res)
+ dev_err(pdev-dev, could not add provider(%d)\n, res);
+
+ return res;
+}
+
+/* We assume here that OMAP clocks will not be removed */
Then the above comment can be removed too.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
