Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support

[Mugunthan V N]

On 6/6/2013 12:53 AM, Mark Brown wrote:

On Wed, Jun 05, 2013 at 10:38:15PM +0530, Mugunthan V N wrote:

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()

Linus Walleij posted some patches which factor the state setting code
out into generic functions earlier on today - it probably makes sense to
pick those up rather than open coding
But this can go in as Linus Walleij's patch is not accepted yet. Once 
that is

accepted and present in net git repo I will submit a separate patch to use
those APIs from pin ctrl core.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Broken DM816x support in Linux 3.10-rc4

[Aida Mynzhasova]

On 06.06.2013 07:54, Paul Walmsley wrote:

здравствуйте,

On Wed, 5 Jun 2013, Aida Mynzhasova wrote:


Not so long ago I tried to boot Linux 3.10-rc4 kernel on DM816x EVM
board. Unfortunately, my attempts were failed by reason of poor
support of DM81xx-based devices in new kernels.


Yeah, TI pretty much gave up on trying to get support for that chip
upstream a few years ago.  Same for DM814x.


So, I suggest you this patch series, which fixes that kernel crush and
adds new functions/structures, required for early initialization on
DM816x (power and clock domains, hwmods). After applying these patches
the kernel is able to successfully continue booting till clock
initialization (will be added later).


OK, it will be great to get my DM8168EVM booting on mainline.  But there
are a few preliminary issues with the patches:

1. All new chip and board support needs to be DT-only.  So, no new board
files.  Also, all the hwmod data shouldn't have IRQ, DMA, etc. data - that
should come from DT.  See for example the recently posted patch [PATCH
13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

2. Looks like patch 2 is missing from the list.  If it's too big for the
list, please break it down into smaller patches.

3. Did you write this code and data, hwmods, etc., or did it come from a
TI kernel?  Please note this clearly in the patch descriptions.


- Paul



Hi!

Thanks for reply!
ok, I'll rewrite code by means of DT and add some additional notes to 
patch description.


Aida.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH v4 3/5] ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone

[Florian Vaussard]

Hello,

On 06/05/2013 07:08 PM, Mugunthan V N wrote:

Add pinmux configurations for MII based CPSW ethernet to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.

Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.

Todo:
- if an idle state is available for pins, add support for it.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
  arch/arm/boot/dts/am335x-bone.dts |   38 +
  1 file changed, 38 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index 4b5a8e0..008a13b 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -36,6 +36,33 @@
0x60 0x17   /* gpmc_a8.gpio1_24, 
OUTPUT_PULLUP | MODE7 */
;
};
+
+   cpsw_default: cpsw_default {
+   pinctrl-single,pins = 
+   /* Slave 1 */
+   0x110 0x20  /* mii1_rxerr.mii1_rxerr, MODE0 
| INPUT */


Here I guess that the comment should be INPUT_PULLDOWN, instead of INPUT.


+   0x114 0x0   /* mii1_txen.mii1_txen, MODE0 | 
OUTPUT */


As bit PULLUDENABLE is 0, the pulldown is enabled according to the TRM, 
right?
Is this a desirable behaviour, as it will consume power when outputting 
a high level?

And consequently, the comment should probably be OUTPUT_PULLDOWN, no?


+   0x118 0x20  /* mii1_rxdv.mii1_rxdv, MODE0 | 
INPUT_PULLDOWN */
+   0x11c 0x0   /* mii1_txd3.mii1_txd3, MODE0 | 
OUTPUT */
+   0x120 0x0   /* mii1_txd2.mii1_txd2, MODE0 | 
OUTPUT */
+   0x124 0x0   /* mii1_txd1.mii1_txd1, MODE0 | 
OUTPUT */
+   0x128 0x0   /* mii1_txd0.mii1_txd0, MODE0 | 
OUTPUT */


Same questions here.


+   0x12c 0x20  /* mii1_txclk.mii1_txclk, MODE0 
| INPUT_PULLDOWN */
+   0x130 0x20  /* mii1_rxclk.mii1_rxclk, MODE0 
| INPUT_PULLDOWN */
+   0x134 0x20  /* mii1_rxd3.mii1_rxd3, MODE0 | 
INPUT_PULLDOWN */
+   0x138 0x20  /* mii1_rxd2.mii1_rxd2, MODE0 | 
INPUT_PULLDOWN */
+   0x13c 0x20  /* mii1_rxd1.mii1_rxd1, MODE0 | 
INPUT_PULLDOWN */
+   0x140 0x20  /* mii1_rxd0.mii1_rxd0, MODE0 | 
INPUT_PULLDOWN */
+   ;
+   };
+
+   davinci_mdio_default: davinci_mdio_default {
+   pinctrl-single,pins = 
+   /* MDIO */
+   0x148 0x30  /* mdio_data.mdio_data, MODE0 | 
INPUT_PULLUP */
+   0x14c 0x10  /* mdio_clk.mdio_clk, MODE0 | 
OUTPUT_PULLUP */
+   ;
+   };
};

ocp {
@@ -138,3 +165,14 @@
phy_id = davinci_mdio, 1;
phy-mode = mii;
  };
+
+mac {
+   pinctrl-names = default;
+   pinctrl-0 = cpsw_default;
+
+};
+
+davinci_mdio {
+   pinctrl-names = default;
+   pinctrl-0 = davinci_mdio_default;
+};



Regards,

Florian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAPDSS: Remove kfree for memory allocated with devm_kzalloc

[Archit Taneja]

Hi,

On Wednesday 05 June 2013 10:59 PM, Emil Goode wrote:

It's not necessary to free memory allocated with devm_kzalloc
in a remove function and using kfree leads to a double free.


Looks fine to me. Tomi, could you take this for 3.11?

Archit



Signed-off-by: Emil Goode emilgo...@gmail.com
---
  drivers/video/omap2/displays/panel-picodlp.c |2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-picodlp.c 
b/drivers/video/omap2/displays/panel-picodlp.c
index 62f2db0..859e111 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -469,8 +469,6 @@ static void picodlp_panel_remove(struct omap_dss_device 
*dssdev)
i2c_unregister_device(picod-picodlp_i2c_client);
dev_set_drvdata(dssdev-dev, NULL);
dev_dbg(dssdev-dev, removing picodlp panel\n);
-
-   kfree(picod);
  }

  static int picodlp_panel_enable(struct omap_dss_device *dssdev)



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH v4 0/5] Adding pinctrl PM support for CPSW and MDIO

[Benoit Cousson]

Hi Mugunthan,

On 06/05/2013 07:08 PM, Mugunthan V N wrote:
 This patch series adds the following features
 * Adding pinctrl PM support for CPSW and MDIO for Power Optimization
 * Adding phy address to the CPSW node for EVMsk board
 
 Changes from initial version
 * Fixed the multiline function call indentation as per David Miller
   recommendation.
 
 Changes from v2
 * Fixed the multi comment style as per net coding style
 * Fixed checkpatch error (more than 80 characters)
 
 Changes from v3
 * Removed below patch as it has already merged to net-next
   ARM: dts: AM33XX: Add CPSW phy_id device tree data to am335x-evmsk
 * Rebased to net-next as there was a merge conflict in DT files

You should try to avoid pushing DTS patches outside the arm-soc tree, it
will generate a bunch a conflict when arm-soc and net trees will be merged.

Could you post separately all the DTS patches and rebase them on the
for_3.11/dts branch that already contains a bunch of AM33xx patches?

Thanks,
Benoit

 
 Hebbar Gururaja (1):
   net: cpsw: enhance pinctrl support
 
 Mugunthan V N (4):
   net: davinci_mdio: enhance pinctrl support
   ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone
   ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk
   ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM
 
  arch/arm/boot/dts/am335x-bone.dts  |   38 
  arch/arm/boot/dts/am335x-evm.dts   |   36 +++
  arch/arm/boot/dts/am335x-evmsk.dts |   50 
 
  drivers/net/ethernet/ti/cpsw.c |   48 ++
  drivers/net/ethernet/ti/davinci_mdio.c |   45 
  5 files changed, 217 insertions(+)
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c

[jean-philippe francois]

2013/6/5 Paul Walmsley p...@pwsan.com:
 Hi

 On Thu, 30 May 2013, Jean-Philippe Francois wrote:

 omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the 
 clock
 to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned 
 clock
 have parent defined as clk_divider. Instead of using container_of to 
 eventually get
 to the register and directly mess with the divider, change freq via 
 clk_set_rate,
 and let the clock framework toggle the divider value.
 Tested with  3.9 on dm3730.

 Signed-off-by: Jean-Philippe Fran??ois jp.franc...@cynove.com

 Tested this patch before applying, and noticed that it causes the
 retention dynamic idle power management test to fail here on the
 3730beaglexm:

 http://www.pwsan.com/omap/testlogs/fixes_b_v3.10-rc/20130605113443/pm/3730beaglexm/3730beaglexm_log.txt

 Not sure at this point if this is caused by the patch, or if the patch is
 just unmasking another bug.

 Jean, Mike, Rajendra, care to take a look at this?


I am booting with nohlt on my board, because I otherwise have memory
corruption error.
I never looked into it because power consumption is currently a non
issue for us, and the board
will always be working anyway.

However I have a beaglexm too, so I can probably help with testing.

Does the first version [1] of the patch, that only touch the MSB of
the divider also trigger the
bug ?

[1]  https://patchwork.kernel.org/patch/2609681/

Jean-Philippe

 - Paul
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags

[Javier Martinez Canillas]

On 06/06/2013 01:26 AM, Grant Likely wrote:
 On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas 
 javier.marti...@collabora.co.uk wrote:
 On 04/09/2013 12:05 AM, Rob Herring wrote:
  On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
  This means that drivers that need the IRQ type/level flags defined in
  the DT won't be able to get it.
  
  But the interrupt controllers that need the information should be able
  to get to it via irqd_get_trigger_type. What problem exactly are you
  trying to fix? What driver would use this?
 
 
 Yes but this is not about the interrupt controller wanting this information 
 but
 a device driver that is using the IORESOURCE_IRQ struct resource that has the
 information about the virtual IRQ associated with a GPIO-IRQ.
 
 The driver doesn't know neither care if its IRQ line is connected to a line 
 of
 an real IRQ controller or to a GPIO controller that allows a GPIO line to be
 used as an IRQ.
 
  My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
  ISA specific and therefore should not be used on non-ISA buses.
  
 
 Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller
 (drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP 
 processor
 through its General-Purpose Memory Controller (GPMC) and this LAN driver 
 obtain
 its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and
 IORESOURCE_MEM respectively, that is filled by the DeviceTree core.
 
 It does this:
 
 irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 irq_flags = irq_res-flags  IRQF_TRIGGER_MASK;
 
 Since of_irq_to_resource() doesn't fill the trigger/level flags on the
 IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the 
 value
 specified on the second cell of the interrupts DT property.
 
 A previous discussion about this can be found here [1].
 
 I can't remember if there was ever a reason for not returning the IRQ
 flags, but I don't have any major objection to doing so if drivers find
 them useful. The one concern I do have however is if it will cause any
 problems with drivers that expect flags == IORESOURCE_IRQ without any
 additional flags. Any users doing that are buggy anyway, but I do want
 to be careful about breakage.
 
 I'll go over your patch and reply with comments.
 
 g.


It turns out that if you don't pass a trigger type to the request_irq() call, it
will use the trigger type set by the irq chip earlier with .xlate

For some reasons it was not getting the right trigger type when I sent this
patch but now it is working correctly so probably there was a bug on the
irq_chip driver I was using (drivers/gpio/gpio-omap.c) and got fixed in the
meantime.

So I don't need this patch anymore to make the LAN chip work on my board and I
don't know if the fact that an empty edge/level flags defaults to what was set
using the .xlate function handler and this function is called in
irq_create_of_mapping() is a reason enough to not return the IRQ flags on the
struct resource.

Having said that, if you still think this patch is useful then I can send a v2
that take into account your comments on the patch.

Best regards,
Javier

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] RTC: rtc-twl: Fix rtc_reg_map initialization

[Peter Ujfalusi]

Initialize the rtc_reg_map in platform_driver's probe function instead at
module_init time. This way we can make sure that the twl-core has been already
probed and initialized (twl_priv-twl_id is valid) since the platform device
for the RTC driver will be created by the twl-core after it finished it's
init.

Reported-by: Christoph Fritz chf.fr...@googlemail.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Grygorii Strashko grygorii.stras...@ti.com
---
Hi,

Changes since v2:
- Acked-by and Tested-by added to patches
- Recreated on top of 3.10-rc4

Regards,
Peter

 drivers/rtc/rtc-twl.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 8751a52..c9060e9 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -469,6 +469,12 @@ static int twl_rtc_probe(struct platform_device *pdev)
if (irq = 0)
goto out1;
 
+   /* Initialize the register map */
+   if (twl_class_is_4030())
+   rtc_reg_map = (u8 *)twl4030_rtc_reg_map;
+   else
+   rtc_reg_map = (u8 *)twl6030_rtc_reg_map;
+
ret = twl_rtc_read_u8(rd_reg, REG_RTC_STATUS_REG);
if (ret  0)
goto out1;
@@ -610,11 +616,6 @@ static struct platform_driver twl4030rtc_driver = {
 
 static int __init twl_rtc_init(void)
 {
-   if (twl_class_is_4030())
-   rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
-   else
-   rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
-
return platform_driver_register(twl4030rtc_driver);
 }
 module_init(twl_rtc_init);
-- 
1.8.2.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] RTC: rtc-twl: Cleanup with module_platform_driver() conversion

[Peter Ujfalusi]

Use module_platform_driver() to register the platform driver.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
---
 drivers/rtc/rtc-twl.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index c9060e9..e1776fd 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -614,17 +614,7 @@ static struct platform_driver twl4030rtc_driver = {
},
 };
 
-static int __init twl_rtc_init(void)
-{
-   return platform_driver_register(twl4030rtc_driver);
-}
-module_init(twl_rtc_init);
-
-static void __exit twl_rtc_exit(void)
-{
-   platform_driver_unregister(twl4030rtc_driver);
-}
-module_exit(twl_rtc_exit);
+module_platform_driver(twl4030rtc_driver);
 
 MODULE_AUTHOR(Texas Instruments, MontaVista Software);
 MODULE_LICENSE(GPL);
-- 
1.8.2.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH v4 3/5] ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone

[Mugunthan V N]

On 6/6/2013 12:36 PM, Florian Vaussard wrote:

Hello,

On 06/05/2013 07:08 PM, Mugunthan V N wrote:

Add pinmux configurations for MII based CPSW ethernet to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.

Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.

Todo:
- if an idle state is available for pins, add support for it.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
  arch/arm/boot/dts/am335x-bone.dts |   38 
+

  1 file changed, 38 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts

index 4b5a8e0..008a13b 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -36,6 +36,33 @@
  0x60 0x17/* gpmc_a8.gpio1_24, OUTPUT_PULLUP | 
MODE7 */

  ;
  };
+
+cpsw_default: cpsw_default {
+pinctrl-single,pins = 
+/* Slave 1 */
+0x110 0x20/* mii1_rxerr.mii1_rxerr, MODE0 | 
INPUT */


Here I guess that the comment should be INPUT_PULLDOWN, instead of INPUT.

Good catch, I will modify this and submit next version today.



+0x114 0x0/* mii1_txen.mii1_txen, MODE0 | OUTPUT */


As bit PULLUDENABLE is 0, the pulldown is enabled according to the 
TRM, right?
Is this a desirable behaviour, as it will consume power when 
outputting a high level?

This is the desirable behavior.

And consequently, the comment should probably be OUTPUT_PULLDOWN, no?

Will update this in next version of patch series.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH v4 0/5] Adding pinctrl PM support for CPSW and MDIO

[Mugunthan V N]

On 6/6/2013 1:12 PM, Benoit Cousson wrote:

Hi Mugunthan,

On 06/05/2013 07:08 PM, Mugunthan V N wrote:

This patch series adds the following features
* Adding pinctrl PM support for CPSW and MDIO for Power Optimization
* Adding phy address to the CPSW node for EVMsk board

Changes from initial version
* Fixed the multiline function call indentation as per David Miller
   recommendation.

Changes from v2
* Fixed the multi comment style as per net coding style
* Fixed checkpatch error (more than 80 characters)

Changes from v3
* Removed below patch as it has already merged to net-next
ARM: dts: AM33XX: Add CPSW phy_id device tree data to am335x-evmsk
* Rebased to net-next as there was a merge conflict in DT files

You should try to avoid pushing DTS patches outside the arm-soc tree, it
will generate a bunch a conflict when arm-soc and net trees will be merged.

Could you post separately all the DTS patches and rebase them on the
for_3.11/dts branch that already contains a bunch of AM33xx patches?

Benoit

Will separate out the DT patches and will submit on top of for_3.11/dts 
today as v5.


Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags

[Javier Martinez Canillas]

On 06/06/2013 01:34 AM, Grant Likely wrote:
 On Fri,  5 Apr 2013 09:48:08 +0200, Javier Martinez Canillas 
 javier.marti...@collabora.co.uk wrote:
 [...]
 irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
 the correct xlate function handler according to #interrupt-cells
 (irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
 irq_set_irq_type() to set the IRQ type.
 
 But the type is never returned so it can't be saved on the IRQ struct
 resource flags member.
 
 This means that drivers that need the IRQ type/level flags defined in
 the DT won't be able to get it.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 [...]
 diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
 index 535cecf..98aec57 100644
 --- a/include/linux/of_irq.h
 +++ b/include/linux/of_irq.h
 @@ -66,6 +66,10 @@ extern int of_irq_map_one(struct device_node *device, int 
 index,
  extern unsigned int irq_create_of_mapping(struct device_node *controller,
const u32 *intspec,
unsigned int intsize);
 +extern unsigned int irq_create_of_mapping_type(struct device_node 
 *controller,
 +   const u32 *intspec,
 +   unsigned int intsize,
 +   unsigned int *otype);

Hi Grant, thanks a lot for your feedback.

 
 I count 11 users of irq_create_of_mapping(). That's a managable number
 to update.

Yes, but since of_irq_to_resource() doesn't call irq_create_of_mapping()
directly but it does though irq_of_parse_and_map(), then this function signature
has to be modified too.

I'm counting 223 users of irq_of_parse_and_map() so the change is not that small
anymore. Another approach is to call of_irq_map_one() and
irq_create_of_mapping() directly from of_irq_to_resource() instead of using
irq_of_parse_and_map() but I don't like that...

 Instead of creating a new function, please modify the
 existing one and split it off into a separate patch.

But that won't break git bisect-ability? or do you mean to first just change the
functions signatures by adding an argument and update its users and then in a
separate patch do the actual change to the functions to store the IRQ?

 Otherwise the patch looks fine to me.
 
 g.
 

Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support

[Mark Brown]

On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote:
 On 6/6/2013 12:53 AM, Mark Brown wrote:

 Linus Walleij posted some patches which factor the state setting code
 out into generic functions earlier on today - it probably makes sense to
 pick those up rather than open coding

 But this can go in as Linus Walleij's patch is not accepted yet.
 Once that is
 accepted and present in net git repo I will submit a separate patch to use
 those APIs from pin ctrl core.

Linus' change has pretty much gone in already but in any case what would
be sensible here would be to write this in turns of Linus' changes and
then send the patch to him to add to his series so it can go in via the
same route.  One of the major reasons for the patch was that lots of
people were querying the amount of noise caused by this sort of change.


signature.asc
Description: Digital signature

Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags

[Javier Martinez Canillas]

On Thu, Jun 6, 2013 at 10:50 AM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
 On 00:26 Thu 06 Jun , Grant Likely wrote:
 On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas 
 javier.marti...@collabora.co.uk wrote:
  On 04/09/2013 12:05 AM, Rob Herring wrote:
   On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
   This means that drivers that need the IRQ type/level flags defined in
   the DT won't be able to get it.
  
   But the interrupt controllers that need the information should be able
   to get to it via irqd_get_trigger_type. What problem exactly are you
   trying to fix? What driver would use this?
  
 
  Yes but this is not about the interrupt controller wanting this 
  information but
  a device driver that is using the IORESOURCE_IRQ struct resource that has 
  the
  information about the virtual IRQ associated with a GPIO-IRQ.
 
  The driver doesn't know neither care if its IRQ line is connected to a 
  line of
  an real IRQ controller or to a GPIO controller that allows a GPIO line to 
  be
  used as an IRQ.
 
   My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
   ISA specific and therefore should not be used on non-ISA buses.
  
 
  Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller
  (drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP 
  processor
  through its General-Purpose Memory Controller (GPMC) and this LAN driver 
  obtain
  its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and
  IORESOURCE_MEM respectively, that is filled by the DeviceTree core.
 
  It does this:
 
  irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
  irq_flags = irq_res-flags  IRQF_TRIGGER_MASK;
 
  Since of_irq_to_resource() doesn't fill the trigger/level flags on the
  IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the 
  value
  specified on the second cell of the interrupts DT property.

 why do you need to known this in you driver this need to be handle in the irq
 chip

 I does use irq gpio without at all

 Best Regards,
 J.


Yes, in fact as I said on an earlier email on this thread if you don't
pass a trigger type to the request_irq() call, it will use the trigger
type set by the irq chip earlier with .xlate.

A few months ago when I was testing DT on my OMAP3 board, for some
reasons it was not getting the right trigger type. That's why I sent
this patch but it seems it was a bug on the GPIO omap irq_chip driver
since now is working correctly without this. It is taking the trigger
type that was set on the .xlate function handler.

So, I don't need this patch anymore to make the LAN chip work on my
board and I don't know if the fact that an empty edge/level flags
means that is going to be used whatever was set on the .xlate function
handler is a reason enough to not return the IRQ flags on the struct
resource or if someone else is still interested on this patch and
filling this information on the struct resource.

Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags

[Jean-Christophe PLAGNIOL-VILLARD]

On 00:26 Thu 06 Jun , Grant Likely wrote:
 On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas 
 javier.marti...@collabora.co.uk wrote:
  On 04/09/2013 12:05 AM, Rob Herring wrote:
   On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
   This means that drivers that need the IRQ type/level flags defined in
   the DT won't be able to get it.
   
   But the interrupt controllers that need the information should be able
   to get to it via irqd_get_trigger_type. What problem exactly are you
   trying to fix? What driver would use this?
  
  
  Yes but this is not about the interrupt controller wanting this information 
  but
  a device driver that is using the IORESOURCE_IRQ struct resource that has 
  the
  information about the virtual IRQ associated with a GPIO-IRQ.
  
  The driver doesn't know neither care if its IRQ line is connected to a line 
  of
  an real IRQ controller or to a GPIO controller that allows a GPIO line to be
  used as an IRQ.
  
   My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are
   ISA specific and therefore should not be used on non-ISA buses.
   
  
  Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller
  (drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP 
  processor
  through its General-Purpose Memory Controller (GPMC) and this LAN driver 
  obtain
  its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and
  IORESOURCE_MEM respectively, that is filled by the DeviceTree core.
  
  It does this:
  
  irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
  irq_flags = irq_res-flags  IRQF_TRIGGER_MASK;
  
  Since of_irq_to_resource() doesn't fill the trigger/level flags on the
  IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the 
  value
  specified on the second cell of the interrupts DT property.

why do you need to known this in you driver this need to be handle in the irq
chip

I does use irq gpio without at all

Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags

[Tomasz Figa]

On Thursday 06 of June 2013 10:50:39 Jean-Christophe PLAGNIOL-VILLARD 
wrote:
 On 00:26 Thu 06 Jun , Grant Likely wrote:
  On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas 
javier.marti...@collabora.co.uk wrote:
   On 04/09/2013 12:05 AM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
This means that drivers that need the IRQ type/level flags
defined in
the DT won't be able to get it.

But the interrupt controllers that need the information should be
able
to get to it via irqd_get_trigger_type. What problem exactly are
you
trying to fix? What driver would use this?
   
   Yes but this is not about the interrupt controller wanting this
   information but a device driver that is using the IORESOURCE_IRQ
   struct resource that has the information about the virtual IRQ
   associated with a GPIO-IRQ.
   
   The driver doesn't know neither care if its IRQ line is connected to
   a line of an real IRQ controller or to a GPIO controller that
   allows a GPIO line to be used as an IRQ.
   
My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they
are
ISA specific and therefore should not be used on non-ISA buses.
   
   Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller
   (drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP
   processor through its General-Purpose Memory Controller (GPMC) and
   this LAN driver obtain its IRQ and I/O address space from a struct
   resource IORESOURCE_IRQ and IORESOURCE_MEM respectively, that is
   filled by the DeviceTree core.
   
   It does this:
   
   irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
   irq_flags = irq_res-flags  IRQF_TRIGGER_MASK;
   
   Since of_irq_to_resource() doesn't fill the trigger/level flags on
   the
   IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding
   the value specified on the second cell of the interrupts DT
   property.
 
 why do you need to known this in you driver this need to be handle in
 the irq chip

There are devices that support multiple interrupt trigger types, like 
Broadcom WLAN chips, and drivers must configure them properly for 
requested trigger type, obtaining the information from flags field of the 
IRQ resource.

Best regards,
Tomasz

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Request for OMAPDSS testing

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tomi,

On 06/04/13 10:40, Tomi Valkeinen wrote:
 Hi guys,
 
 I've made some big changes on the omapdss device model, which involves
 converting all the panel drivers. I've got only a bunch of boards, so I
 hope some of you can perhaps do some minimal tests on some other boards.
 
 I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
 
 The code can be found from the below git branch. It's based on 3.10-rc1.
 
 git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
 
 All you need to do to get things working is to enable the new panel
 drivers from kernel config, under Device drivers/Graphics support/OMAP2+
 Display Subsystem support/OMAP Display Device Drivers/

Thanks for the patches.
I still had no chance to look into them.
Hopefully, I will be able to do some tests on the next week.


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRsHK8AAoJEBDE8YO64EfaSj8P/ilqGfiSYkZG/ZM4hwv+MFt+
0DllzT8zyHIPZVW7vzP2kCeBymZztpjrEYLkqnnXnv255EcYkAoDEPViHqv0L1h6
dQXSmMOsz9pgYANeDVhNG+PoP0DaBKWihZ7GVZ5MCROW+vSWLRpCIp8fIl7N+EGu
XzFkMSCApuKxFMDOcLppSXAQLdFDcjAeUIiMsYOdnjeNtOy1iXb4metqZ/Ckm7lM
KGP7H5eoHacrDwFZtmy7Glo4L+JEKzCkMfBr1tnMR5uTBDOzQAHDx0EP9mJ7Pjug
gSADHCMa63cCFkXaLKtptBOF8Lgb165XBhs3yRVY/WKm15l815tHQ8rOpWoiaSkx
LR65zuNsYTjMlaLNjJjVtpTb38+v/+IgMZzb7ALJJxsnSYDIXIx2qJkpVy7DVawK
G0Z1xO6xzaxjua0PFv0QWcH7ayI9HKsFr346e2Wk5gNvHTJzQfXN8P/CuMmgeU3o
KNCl+zMQ45bq4U9DfxlNjaswnWiY2GHaN3N8zjgVJCBXEHK7TJ4PSGhzpC262BwL
jKFxebzIPEMJDq1fBu5OQiHx8lyUw+fu0Z64O0x/O2fwYep2/bP3pWUcloLKVK1y
WmUcsl2P7lScchhqNHPYABEDiQDzT+ghp4nX5/WCRdy7qXskO1WPkrZjQaIKBFsX
zwx9ysTRKOYxn0ESCsPw
=QlvU
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm/omap: use const char properly

[Sebastian Andrzej Siewior]

The itention was probably to make both pointers const but as it is now,
it is just const used twice.

Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 arch/arm/mach-omap2/id.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 1272c41..54e4c16 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -601,7 +601,7 @@ void __init omap2_set_globals_tap(u32 class, void __iomem 
*tap)
 
 #ifdef CONFIG_SOC_BUS
 
-static const char const *omap_types[] = {
+static const char * const omap_types[] = {
[OMAP2_DEVICE_TYPE_TEST]= TST,
[OMAP2_DEVICE_TYPE_EMU] = EMU,
[OMAP2_DEVICE_TYPE_SEC] = HS,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm/omap: use const char properly

[Ruslan Bilovol]

Hi Sebastian,

On Thu, Jun 6, 2013 at 4:24 PM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
 The itention was probably to make both pointers const but as it is now,
 it is just const used twice.

Yes, it's a typo I did accidentally. Good catch!

Regards,
Ruslan


 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  arch/arm/mach-omap2/id.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index 1272c41..54e4c16 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -601,7 +601,7 @@ void __init omap2_set_globals_tap(u32 class, void __iomem 
 *tap)

  #ifdef CONFIG_SOC_BUS

 -static const char const *omap_types[] = {
 +static const char * const omap_types[] = {
 [OMAP2_DEVICE_TYPE_TEST]= TST,
 [OMAP2_DEVICE_TYPE_EMU] = EMU,
 [OMAP2_DEVICE_TYPE_SEC] = HS,
 --
 1.7.10.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk

[Sebastian Andrzej Siewior]

From: Philip Avinash avinashphi...@ti.com

PWM output from ecap2 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales with
inverse polarity.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 arch/arm/boot/dts/am335x-evmsk.dts |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index f67c360..c21fdaf 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -51,6 +51,12 @@
0x9c 0x27   /* gpmc_ben0_cle.gpio2_5, INPUT 
| MODE7 */
;
};
+
+   ecap2_pins: backlight_pins {
+   pinctrl-single,pins = 
+   0x19c 0x4   /* 
mcasp0_ahclkr.ecap2_in_pwm2_out MODE4 */
+   ;
+   };
};
 
ocp {
@@ -94,6 +100,16 @@
st,max-limit-z = 750;
};
};
+
+   epwmss2: epwmss@48304000 {
+   status = okay;
+
+   ecap2: ecap@48304100 {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = ecap2_pins;
+   };
+   };
};
 
vbat: fixedregulator@0 {
@@ -170,6 +186,13 @@
gpios = gpio2 5 0;
};
};
+
+   backlight {
+   compatible = pwm-backlight;
+   pwms = ecap2 0 5 1;
+   brightness-levels = 0 58 61 66 75 90 125 170 255;
+   default-brightness-level = 8;
+   };
 };
 
 /include/ tps65910.dtsi
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm

[Sebastian Andrzej Siewior]

From: Philip Avinash avinashphi...@ti.com

PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 arch/arm/boot/dts/am335x-evm.dts |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..35b2f77 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,12 @@
0x154 0x27  /* spi0_d0.gpio0_3, INPUT | 
MODE7 */
;
};
+
+   ecap0_pins: backlight_pins {
+   pinctrl-single,pins = 
+   0x164 0x0   /* 
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+   ;
+   };
};
 
ocp {
@@ -102,6 +108,16 @@
reg = 0x48;
};
};
+
+   epwmss0: epwmss@4830 {
+   status = okay;
+
+   ecap0: ecap@48300100 {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = ecap0_pins;
+   };
+   };
};
 
vbat: fixedregulator@0 {
@@ -158,6 +174,13 @@
gpio-key,wakeup;
};
};
+
+   backlight {
+   compatible = pwm-backlight;
+   pwms = ecap0 0 5 0;
+   brightness-levels = 0 51 53 56 62 75 101 152 255;
+   default-brightness-level = 8;
+   };
 };
 
 /include/ tps65910.dtsi
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] ARM: dts: AM33XX: Add PWMSS device tree nodes

[Sebastian Andrzej Siewior]

From: Philip Avinash avinashphi...@ti.com

Add PWMSS device tree nodes in relation with ECAP  EHRPWM DT nodes to
AM33XX SoC family. Also populates device tree nodes for ECAP  EHRPWM by
adding necessary properties like pwm-cells, base reg  set disabled as
status.

Signed-off-by: Philip Avinash avinashphi...@ti.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 arch/arm/boot/dts/am33xx.dtsi |   84 +
 1 file changed, 84 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..7fa9c5f 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -343,6 +343,90 @@
ti,hwmods = usb_otg_hs;
};
 
+   epwmss0: epwmss@4830 {
+   compatible = ti,am33xx-pwmss;
+   reg = 0x4830 0x10;
+   ti,hwmods = epwmss0;
+   #address-cells = 1;
+   #size-cells = 1;
+   status = disabled;
+   ranges = 0x48300100 0x48300100 0x80   /* ECAP */
+ 0x48300180 0x48300180 0x80   /* EQEP */
+ 0x48300200 0x48300200 0x80; /* EHRPWM */
+
+   ecap0: ecap@48300100 {
+   compatible = ti,am33xx-ecap;
+   #pwm-cells = 3;
+   reg = 0x48300100 0x80;
+   ti,hwmods = ecap0;
+   status = disabled;
+   };
+
+   ehrpwm0: ehrpwm@48300200 {
+   compatible = ti,am33xx-ehrpwm;
+   #pwm-cells = 3;
+   reg = 0x48300200 0x80;
+   ti,hwmods = ehrpwm0;
+   status = disabled;
+   };
+   };
+
+   epwmss1: epwmss@48302000 {
+   compatible = ti,am33xx-pwmss;
+   reg = 0x48302000 0x10;
+   ti,hwmods = epwmss1;
+   #address-cells = 1;
+   #size-cells = 1;
+   status = disabled;
+   ranges = 0x48302100 0x48302100 0x80   /* ECAP */
+ 0x48302180 0x48302180 0x80   /* EQEP */
+ 0x48302200 0x48302200 0x80; /* EHRPWM */
+
+   ecap1: ecap@48302100 {
+   compatible = ti,am33xx-ecap;
+   #pwm-cells = 3;
+   reg = 0x48302100 0x80;
+   ti,hwmods = ecap1;
+   status = disabled;
+   };
+
+   ehrpwm1: ehrpwm@48302200 {
+   compatible = ti,am33xx-ehrpwm;
+   #pwm-cells = 3;
+   reg = 0x48302200 0x80;
+   ti,hwmods = ehrpwm1;
+   status = disabled;
+   };
+   };
+
+   epwmss2: epwmss@48304000 {
+   compatible = ti,am33xx-pwmss;
+   reg = 0x48304000 0x10;
+   ti,hwmods = epwmss2;
+   #address-cells = 1;
+   #size-cells = 1;
+   status = disabled;
+   ranges = 0x48304100 0x48304100 0x80   /* ECAP */
+ 0x48304180 0x48304180 0x80   /* EQEP */
+ 0x48304200 0x48304200 0x80; /* EHRPWM */
+
+   ecap2: ecap@48304100 {
+   compatible = ti,am33xx-ecap;
+   #pwm-cells = 3;
+   reg = 0x48304100 0x80;
+   ti,hwmods = ecap2;
+   status = disabled;
+   };
+
+   ehrpwm2: ehrpwm@48304200 {
+   compatible = ti,am33xx-ehrpwm;
+   #pwm-cells = 3;
+   reg = 0x48304200 0x80;
+   ti,hwmods = ehrpwm2;
+   status = disabled;
+   };
+   };
+
mac: ethernet@4a10 {
compatible = ti,cpsw;
ti,hwmods = cpgmac0;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Missing pieces for AM335x PWM / backlight support

[Sebastian Andrzej Siewior]

The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:

  Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)

are available in the git repository at:

  git://git.breakpoint.cc/bigeasy/linux.git tags/am335x-pwm

for you to fetch changes up to 6b319b16a27463c93ec36e59458448aae3ab94cd:

  ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk (2013-06-06 
14:59:18 +0200)


Collected patches from Philip Avinash to get PWM working on AM335x-evm.
The series includes the TBCLK and device tree entries.


Philip Avinash (4):
  ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
  ARM: dts: AM33XX: Add PWMSS device tree nodes
  ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
  ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk

 arch/arm/boot/dts/am335x-evm.dts  |   23 +
 arch/arm/boot/dts/am335x-evmsk.dts|   23 +
 arch/arm/boot/dts/am33xx.dtsi |   84 +
 arch/arm/mach-omap2/cclock33xx_data.c |   30 
 arch/arm/mach-omap2/control.h |8 
 5 files changed, 168 insertions(+)

Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK

[Sebastian Andrzej Siewior]

From: Philip Avinash avinashphi...@ti.com

EHRPWM module requires explicit clock gating of TBCLK from control
module. Hence add TBCLK clock node in clock tree for EHRPWM modules.

Signed-off-by: Philip Avinash avinashphi...@ti.com
[bigeasy: remove CK_AM33XX]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
 arch/arm/mach-omap2/cclock33xx_data.c |   30 ++
 arch/arm/mach-omap2/control.h |8 
 2 files changed, 38 insertions(+)

diff --git a/arch/arm/mach-omap2/cclock33xx_data.c 
b/arch/arm/mach-omap2/cclock33xx_data.c
index af3544c..0346de5 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -862,6 +862,33 @@ static struct clk_hw_omap wdt1_fck_hw = {
 
 DEFINE_STRUCT_CLK(wdt1_fck, wdt_ck_parents, gpio_fck_ops);
 
+static const char *pwmss_clk_parents[] = {
+   dpll_per_m2_ck,
+};
+
+static const struct clk_ops ehrpwm_tbclk_ops = {
+   .enable = omap2_dflt_clk_enable,
+   .disable= omap2_dflt_clk_disable,
+};
+
+DEFINE_CLK_OMAP_MUX_GATE(ehrpwm0_tbclk, l4ls_clkdm,
+NULL, NULL, 0,
+AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+AM33XX_PWMSS0_TBCLKEN_SHIFT,
+NULL, pwmss_clk_parents, ehrpwm_tbclk_ops);
+
+DEFINE_CLK_OMAP_MUX_GATE(ehrpwm1_tbclk, l4ls_clkdm,
+NULL, NULL, 0,
+AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+AM33XX_PWMSS1_TBCLKEN_SHIFT,
+NULL, pwmss_clk_parents, ehrpwm_tbclk_ops);
+
+DEFINE_CLK_OMAP_MUX_GATE(ehrpwm2_tbclk, l4ls_clkdm,
+NULL, NULL, 0,
+AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+AM33XX_PWMSS2_TBCLKEN_SHIFT,
+NULL, pwmss_clk_parents, ehrpwm_tbclk_ops);
+
 /*
  * clkdev
  */
@@ -942,6 +969,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   clkout2_div_ck,   clkout2_div_ck),
CLK(NULL,   timer_32k_ck, clkdiv32k_ick),
CLK(NULL,   timer_sys_ck, sys_clkin_ck),
+   CLK(48300200.ehrpwm,  tbclk,ehrpwm0_tbclk),
+   CLK(48302200.ehrpwm,  tbclk,ehrpwm1_tbclk),
+   CLK(48304200.ehrpwm,  tbclk,ehrpwm2_tbclk),
 };
 
 
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..35d17a6 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -358,6 +358,14 @@
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH   0x2
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3  22)
 
+/* AM33XX PWMSS Control register */
+#define AM33XX_PWMSS_TBCLK_CLKCTRL 0x664
+
+/* AM33XX  PWMSS Control bitfields */
+#define AM33XX_PWMSS0_TBCLKEN_SHIFT0
+#define AM33XX_PWMSS1_TBCLKEN_SHIFT1
+#define AM33XX_PWMSS2_TBCLKEN_SHIFT2
+
 /* CONTROL OMAP STATUS register to identify OMAP3 features */
 #define OMAP3_CONTROL_OMAP_STATUS  0x044c
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] gpio: Enable pcf857x GPIO expander for Device Tree

[Archit Taneja]

Add code to parse the GPIO expander Device Tree node and extract platform data
out of it, and populate the struct 'pcf857x_platform_data' maintained by the
driver. This enables devices to reference the gpio expander from Device Tree.

Add DT binding info in Documentation.

CC: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Archit Taneja arc...@ti.com
---
 .../devicetree/bindings/gpio/gpio-pcf857x.txt  | 44 +
 drivers/gpio/gpio-pcf857x.c| 57 --
 2 files changed, 97 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt 
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000..0556512
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,44 @@
+PCF857x I2C based GPIO controller bindings
+
+Required properties:
+- compatible:
+  - nxp,pca9670 for NXP PCA9670 8 bit I/O expander
+  - nxp,pca9672 for NXP PCA9672 8 bit I/O expander with interrupt
+  - nxp,pca9674 for NXP PCA9672 8 bit I/O expander with interrupt
+  - nxp,pca8574 for NXP PCA8574 8 bit I/O expander with interrupt
+  - nxp,pca8575 for NXP PCA8575 16 bit I/O expander with interrupt
+  - nxp,pca9671 for NXP PCA9671 16 bit I/O expander
+  - nxp,pca9673 for NXP PCA9673 16 bit I/O expander with interrupt
+  - nxp,pca9675 for NXP PCA9675 16 bit I/O expander with interrupt
+  - ti,pcf8574  for TI PCF8574 8 bit I/O expander with interrupt
+  - ti,pcf8574a for TI PCF8574A 8 bit I/O expander with interrupt
+  - ti,pcf8575  for TI PCF8575 16 bit I/O expander with interrupt
+  - ti,tca9554  for TI TCA9554 8 bit I/O expander with interrupt
+  - maxim,max7328 for MAXIM MAX7328 8 bit I/O expander with interrupt
+  - maxim,max7329 for MAXIM MAX7329 8 bit I/O expander with interrupt
+- gpio-controller : Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+  - first cell is the pin number.
+  - second cell is unused.
+- interrupt-controller: Mark the device node as an interrupt controller.
+- #interrupt-cells : Should be two.
+  - first cell is the GPIO number.
+  - second cell is unused.
+- reg: I2C address of the chip.
+
+Device speific properties:
+- n_latch: optional bit-inverse of initial register value; if
+   you leave this initialized to zero the driver will act
+   like the chip was just reset.
+
+Example:
+
+pcf8575: pcf8575 {
+   compatible = ti,pcf8575;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   reg = 0x20;
+   n_latch = 0x0;
+};
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index e8faf53..3435790 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -21,6 +21,7 @@
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/gpio.h
+#include linux/of.h
 #include linux/i2c.h
 #include linux/i2c/pcf857x.h
 #include linux/interrupt.h
@@ -255,17 +256,42 @@ fail:
 
 /*-*/
 
+static struct pcf857x_platform_data *of_gpio_pcf857x(struct device *dev)
+{
+   struct pcf857x_platform_data *pdata;
+   int r;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-gpio_base = -1;
+
+   r = of_property_read_u32(dev-of_node, n_latch, pdata-n_latch);
+   if (r) {
+   dev_dbg(dev, couldn't find n-latch, use default\n);
+   pdata-n_latch = 0;
+   }
+
+   return pdata;
+}
+
 static int pcf857x_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
struct pcf857x_platform_data*pdata;
+   struct device_node  *node;
struct pcf857x  *gpio;
int status;
 
pdata = client-dev.platform_data;
-   if (!pdata) {
+   node = client-dev.of_node;
+
+   if (!pdata  node)
+   pdata = of_gpio_pcf857x(client-dev);
+
+   if (!pdata)
dev_dbg(client-dev, no platform data\n);
-   }
 
/* Allocate, initialize, and register this gpio_chip. */
gpio = devm_kzalloc(client-dev, sizeof(*gpio), GFP_KERNEL);
@@ -420,10 +446,33 @@ static int pcf857x_remove(struct i2c_client *client)
return status;
 }
 
+static const struct of_device_id pcf857x_dt_ids[] = {
+   { .compatible = nxp,pca9670, },
+   { .compatible = nxp,pca9672, },
+   { .compatible = nxp,pca9674, },
+   { .compatible = nxp,pca8574, },
+   { .compatible = nxp,pca8575, },
+   { .compatible = nxp,pca9671, },
+   { .compatible = nxp,pca9673, },
+   { .compatible = nxp,pca9675, },
+
+   { .compatible = ti,pcf8574, },
+   { .compatible = ti,pcf8574a, },
+  

Re: [PATCH 1/2] i2c: omap: convert to module_platform_driver()

[Grygorii Strashko]

On 06/05/2013 04:50 PM, Wolfram Sang wrote:

The similar patch already exists:
https://patchwork.kernel.org/patch/2448251/ - [v2,1/2] RTC: rtc-twl:
Fix rtc_reg_map initialization
from Peter Ujfalusi

So, I think it is best if you resend this patch after all the fixes it
needs are applied or you resend the series with all patches it depends
on. Which should then probably go via arm-soc. Or?


It can wait - I'll track and resend after twl-rtc patches.

-grygorii

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c

[Paul Walmsley]

On Thu, 6 Jun 2013, jean-philippe francois wrote:

 Does the first version [1] of the patch, that only touch the MSB of
 the divider also trigger the
 bug ?
 
 [1]  https://patchwork.kernel.org/patch/2609681/

That one passes the PM test here.  Will take this one for v3.10-rc fixes 
instead, since it fixes a known DSS problem and the original code wasn't 
correct.

Jean, could you work with Mike to come up with a better approach for 
v3.11 or v3.12?


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression

[Tony Lindgren]

* Grant Likely grant.lik...@secretlab.ca [130605 15:39]:
 On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren t...@atomide.com wrote:
  * Tony Lindgren t...@atomide.com [130516 14:50]:
   * Aaro Koskinen aaro.koski...@iki.fi [130516 14:05]:
On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote:
 * Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]:
  I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is 
  broken:
  
  [2.264221] retu-mfd 2-0001: Retu v3.2 found
  [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12
  [2.300140] retu-mfd: probe of 2-0001 failed with error -12
  
  The error is coming from regmap code. According to git bisect, it is
  caused by:
  
  commit ede4d7a5b9835510fd1f724367f68d2fa4128453
  Author: Jon Hunter jon-hun...@ti.com
  Date:   Fri Mar 1 11:22:47 2013 -0600
  
  gpio/omap: convert gpio irq domain to linear mapping
  
  The commit does not anymore revert cleanly, and I haven't yet tried
  crafting a manual revert, so any fix proposals/ideas are welcome...
 
 Hmm this might be a bit trickier to fix. Obviously the real solution
 is to convert omap1 to SPARSE_IRQ like we did for omap2+.
 
 For the -rc cycle, it might be possible to fix this by adding a
 different irq_to_gpio() and gpio_to_irq() functions for omap1.

The commit reverts cleanly if we also revert
3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt
service routine), which seems to be just some minor optimization. The
result is below, and with it 770 works again.
   
   Hmm in this case it seems that we should just fix it rather than go back
   to the old code, so let's take a look at that first.
  
  Does the following fix it for you or do we need to fix something else
  there too?
  
 
 Hi Tony,
 
 Do you want me to apply this fix? It sounds like it solves the symptoms,
 but I'd like to know more about what the root cause is.
 
 Send me your s-o-b line and I'll apply the patch

Yes sorry was meaning to send it as a proper patch, but got distracted.
Please go ahead and apply it thanks:

Signed-off-by: Tony Lindgren t...@atomide.com

 
  --- a/drivers/gpio/gpio-omap.c
  +++ b/drivers/gpio/gpio-omap.c
  @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device 
  *pdev)
  const struct omap_gpio_platform_data *pdata;
  struct resource *res;
  struct gpio_bank *bank;
  +   int irq_base;
   
  match = of_match_device(of_match_ptr(omap_gpio_match), dev);
   
  @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device 
  *pdev)
  pdata-get_context_loss_count;
  }
   
  -
  -   bank-domain = irq_domain_add_linear(node, bank-width,
  -irq_domain_simple_ops, NULL);
  -   if (!bank-domain)
  +   /*
  +* REVISIT: Once we have omap1 supporting  SPARSE_IRQ, we can drop
  +* irq_alloc_descs() and irq_domain_add_legacy() and just do:
  +*
  +* bank-domain = irq_domain_add_linear(node, bank-width,
  +*   irq_domain_simple_ops, NULL);
  +* if (!bank-domain)
  +*  return -ENODEV;
  +*/
  +   irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
  +   if (irq_base  0) {
  +   dev_err(dev, Couldn't allocate IRQ numbers\n);
  return -ENODEV;
  +   }
  +
  +   bank-domain = irq_domain_add_legacy(node, bank-width, irq_base,
  +0, irq_domain_simple_ops, NULL);
   
  if (bank-regs-set_dataout  bank-regs-clr_dataout)
  bank-set_dataout = _set_gpio_dataout_reg;
 
 -- 
 Grant Likely, B.Sc, P.Eng.
 Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Broken DM816x support in Linux 3.10-rc4

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [130605 21:22]:
 Hi,
 
 also,
 
 On Wed, 5 Jun 2013, Aida Mynzhasova wrote:
 
  Aida Mynzhasova (5):
ARM: OMAP: AM33xx: multiple renames for early initialization
 
 If this patch is what's responsible for all the file renaming, please drop 
 it.  Looks from the change summary that it's just useless churn (although 
 I haven't seen the patch here since it never made it to the lists)

Yes no reason for all the renaming, marketing names can be
whatever. For example, we have am/dm37xx too which is really
omap36xx.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED

[Sricharan R]

From: Dan Murphy dmur...@ti.com

Add support for blue LED 1 off of GPIO 153.
Make the LED a heartbeat LED
Configure the MUX for GPIO output.

Cc: Dan Murphy dmur...@ti.com
Signed-off-by: Dan Murphy dmur...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
 [V2] Removed the redundant comments

 arch/arm/boot/dts/omap5-uevm.dts |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index a31e42f..6e8bb86 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -59,6 +59,15 @@
reset-supply = hsusb3_reset;
};
 
+   leds {
+   compatible = gpio-leds;
+   led@1 {
+   label = omap5:blue:usr1;
+   gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1 
LED */
+   linux,default-trigger = heartbeat;
+   default-state = off;
+   };
+   };
 };
 
 omap5_pmx_core {
@@ -70,6 +79,7 @@
mcbsp1_pins
mcbsp2_pins
usbhost_pins
+   led_gpio_pins
;
 
twl6040_pins: pinmux_twl6040_pins {
@@ -168,6 +178,12 @@
0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
;
};
+
+   led_gpio_pins: pinmux_led_gpio_pins {
+   pinctrl-single,pins = 
+   0x196 (PIN_OUTPUT | MUX_MODE6) /* 
uart3_cts_rctx.gpio5_153 */
+   ;
+   };
 };
 
 omap5_pmx_wkup {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 4/4] ARM: dts: omap5-uevm: Add uart pinctrl data

[Sricharan R]

From: Sourav Poddar sourav.pod...@ti.com

Booting omap5 uevm results in the following error
did not get pins for uart error: -19

This happens because omap5 uevm dts file is not adapted to use uart through 
pinctrl
framework. Populating uart pinctrl data to get rid of the error.

Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
 [V2] Removed the redundant comments

 arch/arm/boot/dts/omap5-uevm.dts |   41 ++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 6e8bb86..927db1e 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -184,6 +184,32 @@
0x196 (PIN_OUTPUT | MUX_MODE6) /* 
uart3_cts_rctx.gpio5_153 */
;
};
+
+   uart1_pins: pinmux_uart1_pins {
+   pinctrl-single,pins = 
+   0x60 (PIN_OUTPUT | MUX_MODE0) /* uart1_tx.uart1_cts */
+   0x62 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
uart1_tx.uart1_cts */
+   0x64 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
uart1_rx.uart1_rts */
+   0x66 (PIN_OUTPUT | MUX_MODE0) /* uart1_rx.uart1_rts */
+   ;
+   };
+
+   uart3_pins: pinmux_uart3_pins {
+   pinctrl-single,pins = 
+   0x19a (PIN_OUTPUT | MUX_MODE0) /* 
uart3_rts_irsd.uart3_tx_irtx */
+   0x19c (PIN_INPUT_PULLUP | MUX_MODE0) /* 
uart3_rx_irrx.uart3_usbb3_hsic */
+   ;
+   };
+
+   uart5_pins: pinmux_uart5_pins {
+   pinctrl-single,pins = 
+   0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
uart5_rx.uart5_rx */
+   0x172 (PIN_OUTPUT | MUX_MODE0) /* uart5_tx.uart5_tx */
+   0x174 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
uart5_cts.uart5_rts */
+   0x176 (PIN_OUTPUT | MUX_MODE0) /* uart5_cts.uart5_rts */
+   ;
+   };
+
 };
 
 omap5_pmx_wkup {
@@ -268,3 +294,18 @@
pinctrl-names = default;
pinctrl-0 = mcspi4_pins;
 };
+
+uart1 {
+pinctrl-names = default;
+pinctrl-0 = uart1_pins;
+};
+
+uart3 {
+pinctrl-names = default;
+pinctrl-0 = uart3_pins;
+};
+
+uart5 {
+pinctrl-names = default;
+pinctrl-0 = uart5_pins;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 0/4] ARM: dts: omap5: Cleanup and updates for DT files

[Sricharan R]

uevm is the official board supported for OMAP5 soc in the mainline.
This series renames the board dts file for OMAP5 accordingly and cleans
up the same. Also a few additional device DT entry updates are done.

This is on top of the below branch
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts

Boot tested on omap5-uevm after pulling in the data from below place
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git
HWMOD DATA: for_3.11/omap5_data_files
CLOCK DATA: out_of_tree/omap5_clk_data

Dan Murphy (1):
  ARM: dts: omap5-uevm: Add LED support for uEVM blue LED

Roger Quadros (1):
  ARM: dts: omap5-uevm: Add USB Host support

Sourav Poddar (1):
  ARM: dts: omap5-uevm: Add uart pinctrl data

Sricharan R (1):
  ARM: dts: omap5: Rename omap5-evm to omap5-uevm

 arch/arm/boot/dts/Makefile   |2 +-
 arch/arm/boot/dts/omap5-evm.dts  |  261 
 arch/arm/boot/dts/omap5-uevm.dts |  311 ++
 arch/arm/boot/dts/omap5.dtsi |   30 
 4 files changed, 342 insertions(+), 262 deletions(-)
 delete mode 100644 arch/arm/boot/dts/omap5-evm.dts
 create mode 100644 arch/arm/boot/dts/omap5-uevm.dts

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 1/4] ARM: dts: omap5: Rename omap5-evm to omap5-uevm

[Sricharan R]

The uevm is the official board supported for the OMAP5 soc
in mainline. The uevm has an OMAP5432 with a DDR3 memory.
Renaming the board dts file and adding the following cleanups.

 * There are no devices connected on I2C 2,3,4 buses. So remove
   the pinmux data for the same.

 * DDR3 memory is used in the uevm. Neither DVFS or temperature
   polling is supported with DDR3. So remove the DDR3 device and
   emif nodes.

 * Keypad is not supported on uevm. So remove the device node.

Signed-off-by: Sricharan R r.sricha...@ti.com
---
 arch/arm/boot/dts/Makefile |2 +-
 .../arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} |   83 +---
 2 files changed, 4 insertions(+), 81 deletions(-)
 rename arch/arm/boot/dts/{omap5-evm.dts = omap5-uevm.dts} (73%)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..13b86bf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -149,7 +149,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-panda-es.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
-   omap5-evm.dtb \
+   omap5-uevm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-uevm.dts
similarity index 73%
rename from arch/arm/boot/dts/omap5-evm.dts
rename to arch/arm/boot/dts/omap5-uevm.dts
index 22e9ee8..843a001 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ * 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 version 2 as
@@ -8,11 +8,10 @@
 /dts-v1/;
 
 #include omap5.dtsi
-#include samsung_k3pe0e000b.dtsi
 
 / {
-   model = TI OMAP5 EVM board;
-   compatible = ti,omap5-evm, ti,omap5;
+   model = TI OMAP5 uEVM board;
+   compatible = ti,omap5-uevm, ti,omap5;
 
memory {
device_type = memory;
@@ -88,27 +87,6 @@
;
};
 
-   i2c2_pins: pinmux_i2c2_pins {
-   pinctrl-single,pins = 
-   0x178 (PIN_INPUT | MUX_MODE0)   /* i2c2_scl */
-   0x17a (PIN_INPUT | MUX_MODE0)   /* i2c2_sda */
-   ;
-   };
-
-   i2c3_pins: pinmux_i2c3_pins {
-   pinctrl-single,pins = 
-   0x13a (PIN_INPUT | MUX_MODE0)   /* i2c3_scl */
-   0x13c (PIN_INPUT | MUX_MODE0)   /* i2c3_sda */
-   ;
-   };
-
-   i2c4_pins: pinmux_i2c4_pins {
-   pinctrl-single,pins = 
-   0xb8 (PIN_INPUT | MUX_MODE0)/* i2c4_scl */
-   0xba (PIN_INPUT | MUX_MODE0)/* i2c4_sda */
-   ;
-   };
-
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins = 
0x184 (PIN_INPUT | MUX_MODE0)   /* i2c5_scl */
@@ -175,39 +153,6 @@
clock-frequency = 40;
 };
 
-i2c2 {
-   pinctrl-names = default;
-   pinctrl-0 = i2c2_pins;
-
-   clock-frequency = 40;
-
-   /* Pressure Sensor */
-   bmp085@77 {
-   compatible = bosch,bmp085;
-   reg = 0x77;
-   };
-};
-
-i2c3 {
-   pinctrl-names = default;
-   pinctrl-0 = i2c3_pins;
-
-   clock-frequency = 40;
-};
-
-i2c4 {
-   pinctrl-names = default;
-   pinctrl-0 = i2c4_pins;
-
-   clock-frequency = 40;
-
-   /* Temperature Sensor */
-   tmp102@48{
-   compatible = ti,tmp102;
-   reg = 0x48;
-   };
-};
-
 i2c5 {
pinctrl-names = default;
pinctrl-0 = i2c5_pins;
@@ -215,32 +160,10 @@
clock-frequency = 40;
 };
 
-keypad {
-   keypad,num-rows = 8;
-   keypad,num-columns = 8;
-   linux,keymap = 0x02020073  /* VOLUP */
-   0x02030072  /* VOLDOWM */
-   0x020400e7  /* SEND */
-   0x02050066  /* HOME */
-   0x0206006b  /* END */
-   0x020700d9;/* SEARCH */
-   linux,input-no-autorepeat;
-};
-
 mcbsp3 {
status = disabled;
 };
 
-emif1 {
-   cs1-used;
-   device-handle = samsung_K3PE0E000B;
-};
-
-emif2 {
-   cs1-used;
-   device-handle = samsung_K3PE0E000B;
-};
-
 mcspi1 {
 
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] ARM: OMAP: hwmod/clock: more fixes for v3.10-rc

[Paul Walmsley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony

The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:

  Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/omap-fixes-b-for-3.10-rc

for you to fetch changes up to a93d8a1cea0899982993e9a93404c6f78b123697:

  ARM: omap3: clock: fix wrong container_of in clock36xx.c (2013-06-06 08:48:07 
-0600)

- 
More OMAP hwmod and clock fixes for v3.10-rc.  Fixes the AM33xx UART2.
Also fixes some CCF-related breakage on OMAP36xx/37xx, affecting DSS
at the very least.

Basic test logs for this branch are here:

http://www.pwsan.com/omap/testlogs/fixes_b_v3.10-rc/20130606093449/

- 
Jean-Philippe Francois (1):
  ARM: omap3: clock: fix wrong container_of in clock36xx.c

Thomas Petazzoni (1):
  arm: omap2: fix AM33xx hwmod infos for UART2

 arch/arm/mach-omap2/clock36xx.c|   18 +-
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
 2 files changed, 17 insertions(+), 10 deletions(-)

vmlinux object size
(delta in bytes from test_v3.10-rc4 (d683b96b072dc4680fc74964eca77e6a23d1fa6e)):
   text data  bsstotal  kernel
  0  +640  +64  am33xx_only
  0000  n800_multi_omap2xxx
  0000  n800_only_a
  0000  omap1_defconfig
  0000  omap1_defconfig_1510innovator_only
  0000  omap1_defconfig_5912osk_only
  0  +640  +64  omap2plus_defconfig
  0000  omap2plus_defconfig_2430sdp_only
  0  +640  +64  omap2plus_defconfig_cpupm
  0000  omap2plus_defconfig_no_pm
  0000  omap2plus_defconfig_omap2_4_only
-64  +6400  omap2plus_defconfig_omap3_4_only
  0000  rmk_omap3430_ldp_allnoconfig
  0000  rmk_omap3430_ldp_oldconfig
  0000  rmk_omap4430_sdp_allnoconfig
  0  +640  +64  rmk_omap4430_sdp_oldconfig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRsMs0AAoJEMePsQ0LvSpLSkEQAJDav8PjK8w1P604lTMlxS9l
CopkUktCtXKu+E/LRZ0H8Cd2h2hhPemqJPdTGLfd0QH2B5fF5HwBVDqJ7FYCyf6h
6wg4HFJ2LkplzRHydlL7hylESRefZM5SmDH7fuwAD3BGa7LcYsX4q3GBpnRQJyH4
0LXa1GuWNs5PqL1ZVKGjZE3ycMmB751yMsiTMkE2XocuXfyJnNFdf8mnfCGsjoPM
BIzkOJCQc9cHxBPS1zhDU8iiiKILdaKtniL0iQ/22HKR+KFo/XvOaRQi1VbkmJM/
amWbNnrgjyPoNUuGld54564vrmc7KvgXNRibX20R3dkJa2IsLTJNLUkJEKPIZKMi
lALYNpm1raL1Wnq6xf/3xTAiK3IBqK+Gztsdf3Ya61uDrsNeCPrS+LJ9NRAtfVNQ
G07FVoo2Il5CgJ94MLSS8DQVRAnG7Xofwfb7iN/J0tn0iFwPcrqV485F2TNitHKS
H7vh5DhX/zXhTqt0gB94R1nIHY7c4hNuhqK368K42aPBAbhwWxrwWS0SS0mNZW79
FEeoz/VwnxA+zviZbZOwSUbibpkp4XI6PdP6J7PYzsOdfdjsYyUbW7Nss1DCIyYz
vcCvh8+8xEpRkujwOTOePOmhmj9vqIUJirA+1DOcfGF9MYzKSB0XIpcbieAp7pUp
qG2KLm+gDfiJkxRH3IZX
=qUET
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 2/4] ARM: dts: omap5-uevm: Add USB Host support

[Sricharan R]

From: Roger Quadros rog...@ti.com

Provide the RESET regulators for the USB PHYs, the USB Host
port modes and the PHY devices.

Also provide pin multiplexer information for the USB host
pins.

Cc: Roger Quadros rog...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
[Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor macros]
Signed-off-by: Sricharan R r.sricha...@ti.com
---
 [v2] Removed the clk_alias node and removed the redundant comments

 arch/arm/boot/dts/omap5-uevm.dts |   70 ++
 arch/arm/boot/dts/omap5.dtsi |   30 
 2 files changed, 100 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 843a001..a31e42f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -25,6 +25,40 @@
regulator-max-microvolt = 300;
};
 
+   /* 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 = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80 HUB_NRESET */
+   startup-delay-us = 7;
+   enable-active-high;
+   };
+
+   /* HS USB Host PHY on PORT 2 */
+   hsusb2_phy: hsusb2_phy {
+   compatible = usb-nop-xceiv;
+   reset-supply = hsusb2_reset;
+   };
+
+   /* HS USB Port 3 RESET */
+   hsusb3_reset: hsusb3_reset_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb3_reset;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = gpio3 15 GPIO_ACTIVE_HIGH; /* gpio3_79 ETH_NRESET */
+   startup-delay-us = 7;
+   enable-active-high;
+   };
+
+   /* HS USB Host PHY on PORT 3 */
+   hsusb3_phy: hsusb3_phy {
+   compatible = usb-nop-xceiv;
+   reset-supply = hsusb3_reset;
+   };
+
 };
 
 omap5_pmx_core {
@@ -35,6 +69,7 @@
dmic_pins
mcbsp1_pins
mcbsp2_pins
+   usbhost_pins
;
 
twl6040_pins: pinmux_twl6040_pins {
@@ -120,6 +155,32 @@
0x16c (PIN_INPUT | MUX_MODE1)   /*  mcspi2_cs */
;
};
+
+   usbhost_pins: pinmux_usbhost_pins {
+   pinctrl-single,pins = 
+   0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
+   0x86 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_data */
+
+   0x19e (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_strobe */
+   0x1a0 (PIN_INPUT | MUX_MODE0) /* usbb3_hsic_data */
+
+   0x70 (PIN_OUTPUT | MUX_MODE6) /* gpio3_80 HUB_NRESET */
+   0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 ETH_NRESET */
+   ;
+   };
+};
+
+omap5_pmx_wkup {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   usbhost_wkup_pins
+   ;
+
+   usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
+   pinctrl-single,pins = 
+   0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub 
clk */
+   ;
+   };
 };
 
 mmc1 {
@@ -164,6 +225,15 @@
status = disabled;
 };
 
+usbhshost {
+   port2-mode = ehci-hsic;
+   port3-mode = ehci-hsic;
+};
+
+usbhsehci {
+   phys = 0 hsusb2_phy hsusb3_phy;
+};
+
 mcspi1 {
 
 };
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1e84db8..accab62 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -666,5 +666,35 @@
ctrl-module = omap_control_usb;
};
};
+
+   usbhstll: usbhstll@4a062000 {
+   compatible = ti,usbhs-tll;
+   reg = 0x4a062000 0x1000;
+   interrupts = GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH;
+   ti,hwmods = usb_tll_hs;
+   };
+
+   usbhshost: usbhshost@4a064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x4a064000 0x800;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@4a064800 {
+   compatible = ti,ohci-omap3, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;
+   interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
+   };
+
+   usbhsehci: ehci@4a064c00 {
+   compatible 

Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support

[Sricharan R]

Hi,
On Wednesday 05 June 2013 07:27 PM, Nishanth Menon wrote:
 On 12:16-20130605, Sricharan R wrote:
 From: Roger Quadros rog...@ti.com
 [...]
 diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
 b/arch/arm/boot/dts/omap5-uevm.dts
 index 843a001..cf862df 100644
 --- a/arch/arm/boot/dts/omap5-uevm.dts
 +++ b/arch/arm/boot/dts/omap5-uevm.dts
 snip
 +/* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
 +clock_alias {
 +clock-name = auxclk1_ck;
 +clock-alias = main_clk;
 is'nt this better to use with clock node?
Roger was suggesting to remove this for now. Posted
V2 following that.
Are you suggesting to go with your clock-binding patch ?

Regards,
 Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] ARM: dts: omap5-uevm: Add LED support for uEVM blue LED

[Sricharan R]

Hi,
On Wednesday 05 June 2013 10:34 PM, Dan Murphy wrote:
 Sricharan

 Thanks for sending this up in the series.

 On 06/05/2013 01:46 AM, Sricharan R wrote:
 From: Dan Murphy dmur...@ti.com

 Add support for blue LED 1 off of GPIO 153.
 Make the LED a heartbeat LED
 Configure the MUX for GPIO output.

 Cc: Dan Murphy dmur...@ti.com
 Signed-off-by: Dan Murphy dmur...@ti.com
 [Sricharan R r.sricha...@ti.com: Replaced constants with preprocessor 
 macros]
 Signed-off-by: Sricharan R r.sricha...@ti.com
 ---
  arch/arm/boot/dts/omap5-uevm.dts |   17 +
  1 file changed, 17 insertions(+)

 diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
 b/arch/arm/boot/dts/omap5-uevm.dts
 index cf862df..a2aed5b 100644
 --- a/arch/arm/boot/dts/omap5-uevm.dts
 +++ b/arch/arm/boot/dts/omap5-uevm.dts
 @@ -66,6 +66,16 @@
  device = hsusb2_phy;
  clock-frequency = 1920; /* 19.2 MHz */
  };
 +
 +leds {
 +compatible = gpio-leds;
 +led@1 {
 +label = omap5:blue:usr1;
 +gpios = gpio5 25 GPIO_ACTIVE_HIGH; /* gpio5_153 D1 
 LED */
 +linux,default-trigger = heartbeat;
 +default-state = off;
 +};
 +};
  };
  
  omap5_pmx_core {
 @@ -77,6 +87,7 @@
  mcbsp1_pins
  mcbsp2_pins
  usbhost_pins
 +led_gpio_pins
  ;
  
  twl6040_pins: pinmux_twl6040_pins {
 @@ -175,6 +186,12 @@
  0x6e (PIN_OUTPUT | MUX_MODE6) /* gpio3_79 OUTPUT | MODE 
 6 ETH_NRESET */
  ;
  };
 +
 +led_gpio_pins: pinmux_led_gpio_pins {
 +pinctrl-single,pins = 
 +0x196 (PIN_OUTPUT | MUX_MODE6) /* 
 uart3_cts_rctx.gpio5_153 OUTPUT | MODE6 */
 Same comment from Florian.  We can drop the OUTPUT | MODE6 in the comment.
   Ok thanks, Corrected in V2.

Regards,
 Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file

[Paul Walmsley]

On Wed, 29 May 2013, Santosh Shilimkar wrote:

 From: Sricharan R r.sricha...@ti.com
 
 - The IO resource information like dma request lines, irq number and
   ocp address space can be populated via dt blob. So such data is stripped
   from OMAP4 SOC hwmod data file.
 
 - The devices which are still missing the device tree bindings,
   address space entries are not removed yet. When such devices add
   the dt bindings, respective address space data can be deleted.
 
 - Also other unnessecary hwmods like firewalls are removed as a part of this.
 
 The above update, results in reduction of about ~1650 lines of code.
 
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com

I assume that you're not autogenerating this data any more, based on
your change list above.  If that's correct, please also remove
the paragraph at the top of the file:

 * This file is automatically generated from the OMAP hardware databases.
 * We respectfully ask that any modifications to this file be coordinated
 * with the public linux-omap@vger.kernel.org mailing list and the
 * authors above to ensure that the autogeneration scripts are kept
 * up-to-date with the file contents.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] drivers: net: davinci_mdio: use pinctrl PM helpers

[Mugunthan V N]

This utilize the new pinctrl core PM helpers to transition
the driver to default and sleep states.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/davinci_mdio.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/ti/davinci_mdio.c 
b/drivers/net/ethernet/ti/davinci_mdio.c
index 12aec17..5e361f4 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -38,6 +38,7 @@
 #include linux/davinci_emac.h
 #include linux/of.h
 #include linux/of_device.h
+#include linux/pinctrl/consumer.h
 
 /*
  * This timeout definition is a worst-case ultra defensive measure against
@@ -347,6 +348,9 @@ static int davinci_mdio_probe(struct platform_device *pdev)
data-bus-parent   = dev;
data-bus-priv = data;
 
+   /* Select default pin state */
+   pinctrl_pm_select_default_state(pdev-dev);
+
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);
data-clk = clk_get(pdev-dev, fck);
@@ -454,6 +458,9 @@ static int davinci_mdio_suspend(struct device *dev)
data-suspended = true;
spin_unlock(data-lock);
 
+   /* Select sleep pin state */
+   pinctrl_pm_select_sleep_state(dev);
+
return 0;
 }
 
@@ -462,6 +469,9 @@ static int davinci_mdio_resume(struct device *dev)
struct davinci_mdio_data *data = dev_get_drvdata(dev);
u32 ctrl;
 
+   /* Select default pin state */
+   pinctrl_pm_select_default_state(dev);
+
spin_lock(data-lock);
pm_runtime_get_sync(data-dev);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] Adding pinctrl PM support for CPSW and Davinci MDIO

[Mugunthan V N]

* Adding pinctrl PM support for CPSW and MDIO for Power Optimization
* Adopted to the new pinctrl core PM helpers added by Linus Walleij in 
  http://marc.info/?l=linux-arm-kernelm=137044113914184w=2. This change
  was suggested by Mark Brown in my another patch series posted for CPSW
  and MDIO pinctrl.

David Miller:
  As this patch is based on the patch from Linus Walleij's patch
  drivers: pinctrl sleep and idle states in the core, can you ACK this
  patch series so that Linus Walleij can take this patch via pinctrl tree.

Mugunthan V N (2):
  drivers: net: cpsw: use pinctrl PM helpers
  drivers: net: davinci_mdio: use pinctrl PM helpers

 drivers/net/ethernet/ti/cpsw.c |   11 +++
 drivers/net/ethernet/ti/davinci_mdio.c |   10 ++
 2 files changed, 21 insertions(+)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] drivers: net: cpsw: use pinctrl PM helpers

[Mugunthan V N]

This utilize the new pinctrl core PM helpers to transition
the driver to default and sleep states.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 drivers/net/ethernet/ti/cpsw.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a45f64e..5143552 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
@@ -1691,6 +1692,9 @@ static int cpsw_probe(struct platform_device *pdev)
 */
pm_runtime_enable(pdev-dev);
 
+   /* Select default pin state */
+   pinctrl_pm_select_default_state(pdev-dev);
+
if (cpsw_probe_dt(priv-data, pdev)) {
pr_err(cpsw: platform data missing\n);
ret = -ENODEV;
@@ -1979,6 +1983,9 @@ static int cpsw_suspend(struct device *dev)
cpsw_ndo_stop(ndev);
pm_runtime_put_sync(pdev-dev);
 
+   /* Select sleep pin state */
+   pinctrl_pm_select_sleep_state(pdev-dev);
+
return 0;
 }
 
@@ -1988,6 +1995,10 @@ static int cpsw_resume(struct device *dev)
struct net_device   *ndev = platform_get_drvdata(pdev);
 
pm_runtime_get_sync(pdev-dev);
+
+   /* Select default pin state */
+   pinctrl_pm_select_default_state(pdev-dev);
+
if (netif_running(ndev))
cpsw_ndo_open(ndev);
return 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file

[Santosh Shilimkar]

On Thursday 06 June 2013 01:57 PM, Paul Walmsley wrote:
 On Wed, 29 May 2013, Santosh Shilimkar wrote:
 
 From: Sricharan R r.sricha...@ti.com

 - The IO resource information like dma request lines, irq number and
   ocp address space can be populated via dt blob. So such data is stripped
   from OMAP4 SOC hwmod data file.

 - The devices which are still missing the device tree bindings,
   address space entries are not removed yet. When such devices add
   the dt bindings, respective address space data can be deleted.

 - Also other unnessecary hwmods like firewalls are removed as a part of this.

 The above update, results in reduction of about ~1650 lines of code.

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 
 I assume that you're not autogenerating this data any more, based on
 your change list above.  If that's correct, please also remove
 the paragraph at the top of the file:
 
The data is auto-generated. I let Sricharan comment if it is otherwise
in the final version of the patch. 

Sricharan ?

Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] ARM: dts: omap5-uevm: Add USB Host support

[Nishanth Menon]

On 23:21-20130606, Sricharan R wrote:
 Hi,
 On Wednesday 05 June 2013 07:27 PM, Nishanth Menon wrote:
  On 12:16-20130605, Sricharan R wrote:
  From: Roger Quadros rog...@ti.com
  [...]
  diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
  b/arch/arm/boot/dts/omap5-uevm.dts
  index 843a001..cf862df 100644
  --- a/arch/arm/boot/dts/omap5-uevm.dts
  +++ b/arch/arm/boot/dts/omap5-uevm.dts
  snip
  +  /* hsusb2_phy is clocked by FREF_CLK1 i.e. auxclk1 */
  +  clock_alias {
  +  clock-name = auxclk1_ck;
  +  clock-alias = main_clk;
  is'nt this better to use with clock node?
 Roger was suggesting to remove this for now. Posted
 V2 following that.
 Are you suggesting to go with your clock-binding patch ?
you cannot. Mike has already rejected that approach and I have dropped
that series and wont be following up.
See discussion https://patchwork.kernel.org/patch/2541331/

instead the new approach being discussed
https://patchwork.kernel.org/patch/2657351/ and related discussions is
the way to go.

That said, it practically blocks introduction of all code that depend on
dts nodes :(, no matter how I dont like being blocked and my many series
delayed, I believe Mike, Tero, Rajendra are doing the right architecture
and we should wait for it's upstream introduction.

That is just my 2 cents.

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 02/10] mmc: omap_hsmmc: make vcc and vcc_aux independent

[Balaji T K]

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
@@ -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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 00/10] mmc: omap_hsmmc: dt pbias and regulator voltage switch

[Balaji T K]

This patch series adds support for configuring pbias register needed for
switching (ON/OFF, voltage scaling 3V, 1.8V) vmmc regulator suppling
OMAP mmc/sd1 i/o pads for device tree boot.
The control module registers are needed for mmc pbias i/o, speed mode
configuration of mmc1 and loopback clock configuration of mmc2.

With voltage switch support (pbias i/o) added for dt, enhance regulator
deferred probe handling by adding needs_vmmc and needs_vmmc_aux to indicate
whether regulator is applicable so that omap_hsmmc can handle regulator
deferred probe error properly.

Remove the assumption that vmmc_aux regulator to be present only if vmmc is
available. Platforms can have fixed-always-ON regulator for vmmc and/or vmmc_aux
in such cases vmmc regulator needed not be specified in board file.

Balaji T K (10):
  ARM: OMAP2+: add needs_vmmc to hsmmc_info
  mmc: omap_hsmmc: make vcc and vcc_aux independent
  mmc: omap_hsmmc: use needs_vmmc
  mmc: omap_hsmmc: update needs_vmmc for dt
  mmc: omap_hsmmc: remove use_reg
  mmc: omap_hsmmc: add support for pbias configuration in dt
  mmc: omap_hsmmc: remove dt pbias workaround
  ARM: dts: omap3: split omap3_pmx_core
  ARM: dts: omap3: add pbias and mmc_init pinctrl states
  ARM: dts: omap4: add pbias and mmc_init pinctrl states

 arch/arm/boot/dts/omap3-beagle-xm.dts|   42 ++
 arch/arm/boot/dts/omap3-beagle.dts   |   70 +-
 arch/arm/boot/dts/omap3.dtsi |   21 +++-
 arch/arm/boot/dts/omap4-panda-common.dtsi|   34 +
 arch/arm/boot/dts/omap4-sdp.dts  |   34 +
 arch/arm/boot/dts/omap4.dtsi |   11 ++
 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 +
 drivers/mmc/host/omap_hsmmc.c|  188 +-
 include/linux/platform_data/mmc-omap.h   |2 +
 26 files changed, 367 insertions(+), 72 deletions(-)

-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 09/10] ARM: dts: omap3: add pbias and mmc_init pinctrl states

[Balaji T K]

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

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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 06/10] mmc: omap_hsmmc: add support for pbias configuration in dt

[Balaji T K]

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);
+   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;
 }
 
@@ -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;
+}
+
 static int omap_hsmmc_probe(struct platform_device *pdev)
 {
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1785,7 +1859,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
-   

[PATCH v2 10/10] ARM: dts: omap4: add pbias and mmc_init pinctrl states

[Balaji T K]

add pbias states for pbias 0, 1.8V, 3V
add sd/mmc1 pull strength values for control_mmc1 in mmc_init pinctrl state

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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 01/10] ARM: OMAP2+: add needs_vmmc to hsmmc_info

[Balaji T K]

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.

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 b/arch/arm/mach-omap2/board-ldp.c
index d0d17bc..62c1a2d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -315,6 +315,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.caps   = 

[PATCH v2 03/10] mmc: omap_hsmmc: use needs_vmmc

[Balaji T K]

Update needs_vmmc with info passed from board file via platform
data pdata-needs_vmmc.
Use needs_vmmc/needs_vmmc_aux to check whether
regulator is mandatory and handle regulator errors
like EPROBE_DEFER properly

Signed-off-by: Balaji T K balaj...@ti.com
---
 drivers/mmc/host/omap_hsmmc.c |   65 ++--
 1 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bda1a42..21fc152 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -184,6 +184,8 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next  next_data;
 
struct  omap_mmc_platform_data  *pdata;
+   int needs_vmmc:1;
+   int needs_vmmc_aux:1;
 };
 
 static int omap_hsmmc_card_detect(struct device *dev, int slot)
@@ -312,11 +314,13 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
*host)
int ocr_value = 0;
 
reg = regulator_get(host-dev, vmmc);
-   if (IS_ERR(reg)) {
-   dev_err(host-dev, vmmc regulator missing\n);
+   if (IS_ERR(reg)  host-needs_vmmc) {
+   dev_err(host-dev, unable to get vmmc regulator %ld\n,
+   PTR_ERR(reg));
return PTR_ERR(reg);
-   } else {
-   mmc_slot(host).set_power = omap_hsmmc_set_power;
+   }
+   mmc_slot(host).set_power = omap_hsmmc_set_power;
+   if (!IS_ERR(reg)) {
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
@@ -329,31 +333,33 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
*host)
return -EINVAL;
}
}
+   }
 
-   /* Allow an aux regulator */
-   reg = regulator_get(host-dev, vmmc_aux);
-   host-vcc_aux = IS_ERR(reg) ? NULL : reg;
-
-   /* For eMMC do not power off when not in sleep state */
-   if (mmc_slot(host).no_regulator_off_init)
-   return 0;
-   /*
-   * UGLY HACK:  workaround regulator framework bugs.
-   * When the bootloader leaves a supply active, it's
-   * initialized with zero usecount ... and we can't
-   * disable it without first enabling it.  Until the
-   * framework is fixed, we need a workaround like this
-   * (which is safe for MMC, but not in general).
-   */
-   if (regulator_is_enabled(host-vcc)  0 ||
-   (host-vcc_aux  regulator_is_enabled(host-vcc_aux))) {
-   int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
+   /* Allow an aux regulator */
+   reg = regulator_get(host-dev, vmmc_aux);
+   host-vcc_aux = IS_ERR(reg) ? NULL : reg;
+   if (IS_ERR(reg)  host-needs_vmmc_aux) {
+   dev_err(host-dev, unable to get vmmc_aux regulator %ld\n,
+   PTR_ERR(reg));
+   return PTR_ERR(reg);
+   }
 
-   mmc_slot(host).set_power(host-dev, host-slot_id,
-1, vdd);
-   mmc_slot(host).set_power(host-dev, host-slot_id,
-0, 0);
-   }
+   /* For eMMC do not power off when not in sleep state */
+   if (mmc_slot(host).no_regulator_off_init ||
+   (!host-needs_vmmc  !host-needs_vmmc_aux))
+   return 0;
+   /*
+* To disable boot_on regulator, enable regulator
+* to increase usecount and then disable it.
+*/
+   if ((host-vcc  regulator_is_enabled(host-vcc)  0) ||
+   (host-vcc_aux  regulator_is_enabled(host-vcc_aux))) {
+   int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
+
+   mmc_slot(host).set_power(host-dev, host-slot_id,
+1, vdd);
+   mmc_slot(host).set_power(host-dev, host-slot_id,
+0, 0);
}
 
return 0;
@@ -1833,6 +1839,8 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host-base  = ioremap(host-mapbase, SZ_4K);
host-power_mode = MMC_POWER_OFF;
host-next_data.cookie = 1;
+   host-needs_vmmc = pdata-needs_vmmc;
+   host-needs_vmmc_aux = pdata-needs_vmmc_aux;
 
platform_set_drvdata(pdev, host);
 
@@ -1972,7 +1980,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (omap_hsmmc_have_reg()  !mmc_slot(host).set_power) {
ret = omap_hsmmc_reg_get(host);
if (ret)
-   goto err_reg;
+   goto err_irq_cd;
host-use_reg = 1;
}
 
@@ -2029,7 +2037,6 @@ err_slot_name:
 err_irq_cd:
if (host-use_reg)
omap_hsmmc_reg_put(host);
-err_reg:
if (host-pdata-cleanup)
   

[PATCH v2 08/10] ARM: dts: omap3: split omap3_pmx_core

[Balaji T K]

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.

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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 07/10] mmc: omap_hsmmc: remove dt pbias workaround

[Balaji T K]

With pbias support in place remove dt workaround for pbias

Signed-off-by: Balaji T K balaj...@ti.com
---
 drivers/mmc/host/omap_hsmmc.c |   20 +---
 1 files changed, 1 insertions(+), 19 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8dd1cd3..f2e3d1a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -161,7 +161,6 @@ struct omap_hsmmc_host {
 */
struct  regulator   *vcc;
struct  regulator   *vcc_aux;
-   int pbias_disable;
void__iomem *base;
resource_size_t mapbase;
spinlock_t  irq_lock; /* Prevent races with irq handler */
@@ -259,13 +258,6 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
 */
if (!host-vcc  !host-vcc_aux)
return 0;
-   /*
-* With DT, never turn OFF the regulator for MMC1. This is because
-* the pbias cell programming support is still missing when
-* booting with Device tree
-*/
-   if (host-pbias_disable  !vdd)
-   return 0;
 
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -1552,13 +1544,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 * of external transceiver; but they all handle 1.8V.
 */
if ((OMAP_HSMMC_READ(host-base, HCTL)  SDVSDET) 
-   (ios-vdd == DUAL_VOLT_OCR_BIT) 
-   /*
-* With pbias cell programming missing, this
-* can't be allowed on MMC1 when booting with device
-* tree.
-*/
-   !host-pbias_disable) {
+   (ios-vdd == DUAL_VOLT_OCR_BIT)) {
/*
 * The mmc_select_voltage fn of the core does
 * not seem to set the power_mode to
@@ -1956,10 +1942,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 
omap_hsmmc_context_save(host);
 
-   /* This can be removed once we support PBIAS with DT */
-   if (host-dev-of_node  host-mapbase == 0x4809c000)
-   host-pbias_disable = 1;
-
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
/*
 * MMC can still work without debounce clock.
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 04/10] mmc: omap_hsmmc: update needs_vmmc for dt

[Balaji T K]

update needs_vmmc, needs_vmmc_aux for dt boot

Signed-off-by: Balaji T K balaj...@ti.com
---
 drivers/mmc/host/omap_hsmmc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21fc152..08f4ca7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1763,6 +1763,9 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-hs-handling, NULL))
pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
+   pdata-needs_vmmc = of_property_read_bool(np, vmmc-supply);
+   pdata-needs_vmmc_aux = of_property_read_bool(np, vmmc_aux-supply);
+
return pdata;
 }
 #else
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 05/10] mmc: omap_hsmmc: remove use_reg

[Balaji T K]

Since regulator_put can handle NULL / IS_ERR(regulator)
use_reg can be removed, so that regulator_put in omap_hsmmc_reg_put
can be reused for vmmc_aux regulator error scenario.

Signed-off-by: Balaji T K balaj...@ti.com
---
 drivers/mmc/host/omap_hsmmc.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 08f4ca7..533ced2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -179,7 +179,6 @@ struct omap_hsmmc_host {
int context_loss;
int protect_card;
int reqs_blocked;
-   int use_reg;
int req_in_progress;
struct omap_hsmmc_next  next_data;
 
@@ -1984,7 +1983,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
ret = omap_hsmmc_reg_get(host);
if (ret)
goto err_irq_cd;
-   host-use_reg = 1;
}
 
mmc-ocr_avail = mmc_slot(host).ocr_mask;
@@ -2038,8 +2036,7 @@ err_slot_name:
mmc_remove_host(mmc);
free_irq(mmc_slot(host).card_detect_irq, host);
 err_irq_cd:
-   if (host-use_reg)
-   omap_hsmmc_reg_put(host);
+   omap_hsmmc_reg_put(host);
if (host-pdata-cleanup)
host-pdata-cleanup(pdev-dev);
 err_irq_cd_init:
@@ -2075,8 +2072,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 
pm_runtime_get_sync(host-dev);
mmc_remove_host(host-mmc);
-   if (host-use_reg)
-   omap_hsmmc_reg_put(host);
+   omap_hsmmc_reg_put(host);
if (host-pdata-cleanup)
host-pdata-cleanup(pdev-dev);
free_irq(host-irq, host);
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Request for OMAPDSS testing

[Aaro Koskinen]

Hi,

On Tue, Jun 04, 2013 at 10:40:37AM +0300, Tomi Valkeinen wrote:
 I've made some big changes on the omapdss device model, which involves
 converting all the panel drivers. I've got only a bunch of boards, so I
 hope some of you can perhaps do some minimal tests on some other boards.
 
 I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43.
 
 The code can be found from the below git branch. It's based on 3.10-rc1.
 
 git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model
 
 All you need to do to get things working is to enable the new panel
 drivers from kernel config, under Device drivers/Graphics support/OMAP2+
 Display Subsystem support/OMAP Display Device Drivers/

I tested Nokia N900 by pulling your tree and doing the following .config
changes:

# CONFIG_PANEL_ACX565AKM is not set

CONFIG_PANEL_SONY_ACX565AKM=y

The frame buffer console seems to work OK.

A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr info clean up

[Kevin Hilman]

Paul Walmsley p...@pwsan.com writes:

 On Wed, 29 May 2013, Santosh Shilimkar wrote:

 From: Vaibhav Hiremath hvaib...@ti.com
 
 AM33XX only supports DT boot mode and with addition of
 extracting module resources like, irq, dma and address space
 from DT block, so now we can remove duplicate information from
 hwmod data file.

 OK, guess I'll take your word for it that it all works.  The
 BeagleBone-white with appended DTB hasn't booted here since v3.7.
 And the BeagleBone-black with discrete DTB doesn't boot at all with
 current mainline, only with the TI vendor kernel  DTB...

Anyone care to shed light on what's missing for BeagleBone boot with
mainline currently?  

I've also not been able to boot a mainline kernel on the BeagleBone for
some time.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line

[Kevin Hilman]

On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP.  Add another DTS include file
(twl4030_omap3_mux.dtsi) for boards that hook up the twl4030 this way
to include.

This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030.  Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.

Special thanks to Florian Vaussard for suggesting use of preprocessor
feature.

Cc: Florian Vaussard florian.vauss...@epfl.ch
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v2: Updated to change board files instead of twl4030 file.

 arch/arm/boot/dts/omap3-beagle-xm.dts|  1 +
 arch/arm/boot/dts/omap3-beagle.dts   |  1 +
 arch/arm/boot/dts/omap3-devkit8000.dts   |  1 +
 arch/arm/boot/dts/omap3-evm.dts  |  1 +
 arch/arm/boot/dts/omap3-igep.dtsi|  1 +
 arch/arm/boot/dts/omap3-overo.dtsi   |  1 +
 arch/arm/boot/dts/omap3430-sdp.dts   |  1 +
 arch/arm/boot/dts/twl4030_omap3_mux.dtsi | 17 +
 8 files changed, 24 insertions(+)
 create mode 100644 arch/arm/boot/dts/twl4030_omap3_mux.dtsi

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index ad17b6b..1afb563 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -96,6 +96,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index eb7e02a..d5810d7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -135,6 +135,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..166b90c 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -81,6 +81,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index baa24bb..ad7ab86 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -45,6 +45,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 5224c29..3107dc3 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -87,6 +87,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 i2c2 {
clock-frequency = 40;
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 144a5a2..bb55907 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -50,6 +50,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 /* i2c2 pins are used for gpio */
 i2c2 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts 
b/arch/arm/boot/dts/omap3430-sdp.dts
index 2a725a0..df3b918 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -29,6 +29,7 @@
 };
 
 #include twl4030.dtsi
+#include twl4030_omap3_mux.dtsi
 
 mmc1 {
vmmc-supply = vmmc1;
diff --git a/arch/arm/boot/dts/twl4030_omap3_mux.dtsi 
b/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
new file mode 100644
index 000..1bd0f9f
--- /dev/null
+++ b/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
@@ -0,0 +1,17 @@
+twl {
+   pinctrl-names = default;
+   pinctrl-0 = twl4030_pins;
+};
+
+omap3_pmx_core {
+   /*
+* On most OMAP3 platforms, the twl4030 IRQ line is connected
+ * to the SYS_NIRQ line on OMAP.  Therefore, configure the
+ * defaults for the SYS_NIRQ pin here.
+*/
+   twl4030_pins: pinmux_twl4030_pins {
+   pinctrl-single,pins = 
+   0x1b0 (PIN_INPUT_PULLUP | PIN_OFF_WAKEUPENABLE | 
MUX_MODE0) /* sys_nirq.sys_nirq */
+   ;
+   };
+};
-- 
1.8.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line

[Nishanth Menon]

On 16:27-20130606, Kevin Hilman wrote:
 On most OMAP3 platforms, the twl4030 IRQ line is connected to the
 SYS_NIRQ line on OMAP.  Add another DTS include file
 (twl4030_omap3_mux.dtsi) for boards that hook up the twl4030 this way
 to include.
 
 This allows RTC wake from off-mode to work again on OMAP3-based
 platforms with twl4030.  Tested on 3530/Beagle, 3730/Beagle-xM,
 3530/Overo, 3730/Overo-STORM.
 
 Special thanks to Florian Vaussard for suggesting use of preprocessor
 feature.
 
 Cc: Florian Vaussard florian.vauss...@epfl.ch
 Cc: Benoit Cousson b-cous...@ti.com
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 v2: Updated to change board files instead of twl4030 file.
 
  arch/arm/boot/dts/omap3-beagle-xm.dts|  1 +
  arch/arm/boot/dts/omap3-beagle.dts   |  1 +
  arch/arm/boot/dts/omap3-devkit8000.dts   |  1 +
  arch/arm/boot/dts/omap3-evm.dts  |  1 +
  arch/arm/boot/dts/omap3-igep.dtsi|  1 +
  arch/arm/boot/dts/omap3-overo.dtsi   |  1 +
  arch/arm/boot/dts/omap3430-sdp.dts   |  1 +
  arch/arm/boot/dts/twl4030_omap3_mux.dtsi | 17 +
minor comment:
can we do twl4030_omap3 instead? That way, I can add in twl4030 VP
specific parameters which are OMAP3 specific?
one additional minor comment below:

  8 files changed, 24 insertions(+)
  create mode 100644 arch/arm/boot/dts/twl4030_omap3_mux.dtsi
 
 diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
 b/arch/arm/boot/dts/omap3-beagle-xm.dts
 index ad17b6b..1afb563 100644
 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
 +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
 @@ -96,6 +96,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  i2c2 {
   clock-frequency = 40;
 diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
 b/arch/arm/boot/dts/omap3-beagle.dts
 index eb7e02a..d5810d7 100644
 --- a/arch/arm/boot/dts/omap3-beagle.dts
 +++ b/arch/arm/boot/dts/omap3-beagle.dts
 @@ -135,6 +135,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  mmc1 {
   vmmc-supply = vmmc1;
 diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
 b/arch/arm/boot/dts/omap3-devkit8000.dts
 index 5be71b1..166b90c 100644
 --- a/arch/arm/boot/dts/omap3-devkit8000.dts
 +++ b/arch/arm/boot/dts/omap3-devkit8000.dts
 @@ -81,6 +81,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  mmc1 {
   vmmc-supply = vmmc1;
 diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
 index baa24bb..ad7ab86 100644
 --- a/arch/arm/boot/dts/omap3-evm.dts
 +++ b/arch/arm/boot/dts/omap3-evm.dts
 @@ -45,6 +45,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  i2c2 {
   clock-frequency = 40;
 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
 b/arch/arm/boot/dts/omap3-igep.dtsi
 index 5224c29..3107dc3 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -87,6 +87,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  i2c2 {
   clock-frequency = 40;
 diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
 b/arch/arm/boot/dts/omap3-overo.dtsi
 index 144a5a2..bb55907 100644
 --- a/arch/arm/boot/dts/omap3-overo.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo.dtsi
 @@ -50,6 +50,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  /* i2c2 pins are used for gpio */
  i2c2 {
 diff --git a/arch/arm/boot/dts/omap3430-sdp.dts 
 b/arch/arm/boot/dts/omap3430-sdp.dts
 index 2a725a0..df3b918 100644
 --- a/arch/arm/boot/dts/omap3430-sdp.dts
 +++ b/arch/arm/boot/dts/omap3430-sdp.dts
 @@ -29,6 +29,7 @@
  };
  
  #include twl4030.dtsi
 +#include twl4030_omap3_mux.dtsi
  
  mmc1 {
   vmmc-supply = vmmc1;
 diff --git a/arch/arm/boot/dts/twl4030_omap3_mux.dtsi 
 b/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
 new file mode 100644
 index 000..1bd0f9f
 --- /dev/null
 +++ b/arch/arm/boot/dts/twl4030_omap3_mux.dtsi
 @@ -0,0 +1,17 @@
some license text?
 +twl {
 + pinctrl-names = default;
 + pinctrl-0 = twl4030_pins;
 +};
 +
 +omap3_pmx_core {
 + /*
 +  * On most OMAP3 platforms, the twl4030 IRQ line is connected
 + * to the SYS_NIRQ line on OMAP.  Therefore, configure the
 + * defaults for the SYS_NIRQ pin here.
^^^ tab?

 +  */
 + twl4030_pins: pinmux_twl4030_pins {
 + pinctrl-single,pins = 
 + 0x1b0 (PIN_INPUT_PULLUP | PIN_OFF_WAKEUPENABLE | 
 MUX_MODE0) /* sys_nirq.sys_nirq */
 + ;
 + };
 +};

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/14] ARM: OMAP4: hwmod data: Clean up the data file

[Sricharan R]

On Friday 07 June 2013 12:00 AM, Santosh Shilimkar wrote:
 On Thursday 06 June 2013 01:57 PM, Paul Walmsley wrote:
 On Wed, 29 May 2013, Santosh Shilimkar wrote:

 From: Sricharan R r.sricha...@ti.com

 - The IO resource information like dma request lines, irq number and
   ocp address space can be populated via dt blob. So such data is stripped
   from OMAP4 SOC hwmod data file.

 - The devices which are still missing the device tree bindings,
   address space entries are not removed yet. When such devices add
   the dt bindings, respective address space data can be deleted.

 - Also other unnessecary hwmods like firewalls are removed as a part of 
 this.

 The above update, results in reduction of about ~1650 lines of code.

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Sricharan R r.sricha...@ti.com
 I assume that you're not autogenerating this data any more, based on
 your change list above.  If that's correct, please also remove
 the paragraph at the top of the file:

 The data is auto-generated. I let Sricharan comment if it is otherwise
 in the final version of the patch. 

 Sricharan ?
I used autogen to remove the data, but some of the data were not in sync
with the mainline .(like abe, dss, aess, context register offsets etc..).
So i have to sync them manually.

Regards,
 Sricharan

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/32] OMAPDSS: DPI: fix regulators for DT

[Archit Taneja]

On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:

On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.

Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/dpi.c | 21 ++---
  1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index ef8fca2..43f6b26 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -37,7 +37,10 @@
  #include dss_features.h

  static struct {
+   struct platform_device *pdev;


We don't really need to add a new member here for getting the output's 
device pointer. It's already there in dpi.output.dev.


Archit


+
struct regulator *vdds_dsi_reg;
+   bool vdds_dsi_from_core;
struct platform_device *dsidev;

struct mutex lock;
@@ -583,10 +586,15 @@ static int dpi_init_display(struct omap_dss_device 
*dssdev)
struct regulator *vdds_dsi;

vdds_dsi = dss_get_vdds_dsi();
-
if (IS_ERR(vdds_dsi)) {
-   DSSERR(can't get VDDS_DSI regulator\n);
-   return PTR_ERR(vdds_dsi);
+   vdds_dsi = regulator_get(dpi.pdev-dev, vdds_dsi);
+   if (IS_ERR(vdds_dsi)) {
+   DSSERR(can't get VDDS_DSI regulator\n);
+   return PTR_ERR(vdds_dsi);
+   }
+   dpi.vdds_dsi_from_core = false;
+   } else {
+   dpi.vdds_dsi_from_core = true;
}

dpi.vdds_dsi_reg = vdds_dsi;
@@ -702,6 +710,8 @@ static int omap_dpi_probe(struct platform_device *pdev)
  {
int r;

+   dpi.pdev = pdev;
+
mutex_init(dpi.lock);

dpi_init_output(pdev);
@@ -725,6 +735,11 @@ static int __exit omap_dpi_remove(struct platform_device 
*pdev)

dpi_uninit_output(pdev);

+   if (dpi.vdds_dsi_reg != NULL  dpi.vdds_dsi_from_core == false) {
+   regulator_put(dpi.vdds_dsi_reg);
+   dpi.vdds_dsi_reg = NULL;
+   }
+
return 0;
  }




--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html