Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data

2013-04-25 Thread Rajendra Nayak
On Wednesday 24 April 2013 09:58 PM, Mike Turquette wrote:
> Quoting Nishanth Menon (2013-04-14 14:19:17)
>> Overall strategy introduced here is simple: a clock node described in
>> device tree blob is used to identify the exact clock provided in the
>> SoC specific data. This is then linked back using of_clk_add_provider
>> to the device node to be accessible by of_clk_get.
>>
>> Based on discussion contributions from Roger Quadros, Grygorii Strashko
>> and others.
>>
>> Cc: Kevin Hilman 
>> Cc: Mike Turquette 
>> Cc: Paul Walmsley 
>> [t...@atomide.com: co-developed]
>> Signed-off-by: Tony Lindgren 
>> Signed-off-by: Nishanth Menon 
> 
> I can take this into clk-next after the merge window.  Please refresh it
> for -rc1 as we discussed on irc.
> 
> As an aside, will Tero's series for migrating to drivers/clk/omap[1] and
> Rajendra's patch for registering clocks late[2] be refreshed after the

[2] is already in mainline.

> merge window?  It would be nice to combine these efforts.
> 
> Thanks,
> Mike
> 
> [1] http://article.gmane.org/gmane.linux.ports.arm.omap/95948
> [2] http://www.spinics.net/lists/arm-kernel/msg231288.html
> ___
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

2013-04-03 Thread Rajendra Nayak
Hi Tony,

On Thursday 04 April 2013 05:12 AM, Tony Lindgren wrote:
> Hi,
> 
[]..

>> @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
>>  CLK(NULL,   "cpufreq_ck",   &dpll_mpu_ck,   CK_443X),
>>  };
>>  
>> +static struct clk *scrm_clks[] = {
>> +&auxclk0_ck,
>> +&auxclk1_ck,
>> +&auxclk2_ck,
>> +&auxclk3_ck,
>> +&auxclk4_ck,
>> +&auxclk5_ck,
>> +};
> 
> Hmm I don't like the idea of specifying the auxclk both in the
> cclock44xx_data.c and in DT..
> 
>> +static struct clk_onecell_data scrm_data;
>> +
>> +#ifdef CONFIG_OF
>> +int __init omap4_clk_init_dt(void)
>> +{
>> +struct device_node *np;
>> +
>> +np = of_find_compatible_node(NULL, NULL, "ti,omap4-scrm");
>> +if (np) {
>> +scrm_data.clks = scrm_clks;
>> +scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
>> +of_clk_add_provider(np, of_clk_src_onecell_get, &scrm_data);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +#else
>> +
>> +int __init omap4_clk_init_dt(void)
>> +{
>> +return 0;
>> +}
>> +#endif /* CONFIG_OF */
>> +
>>  int __init omap4xxx_clk_init(void)
>>  {
>>  u32 cpu_clkflg;
> 
> .. and I'm not too keen on adding driver specific stuff to this file.
> 
> How about just add a minimal drivers/clk/omap/clk-xyz.c that takes
> the configuration from DT and is based on the binding we already have in
> Documentation/devicetree/bindings/clock/clock-bindings.txt?
> 
> Then as we add new bindings there we can drop them from current
> cclock44xx_data.c, no? That is after omap4 is DT only..

The patch just provides an alternative for clkdev mapping in case of DT.
Are you suggesting we move all *clock data* related to auxclks (and eventually
all clocks) into DT?
We have discussed this multiple times in the past, and moving 250 clock nodes
with each needing multiple register offsets, masks, shifts etc into DT makes it
completely un-readable. For me, having a way for devices to reference a clock 
that they
use for a device using DT makes sense, but not moving all clock data into dts 
files.

regards,
Rajendra

> 
> Regards,
> 
> Tony
> 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

2013-03-21 Thread Rajendra Nayak
On Thursday 21 March 2013 07:24 PM, Roger Quadros wrote:
> On 03/21/2013 03:08 PM, Rajendra Nayak wrote:
>> []..
>>
>>> diff --git a/arch/arm/mach-omap2/board-generic.c 
>>> b/arch/arm/mach-omap2/board-generic.c
>>> index 0274ff7..23f2064 100644
>>> --- a/arch/arm/mach-omap2/board-generic.c
>>> +++ b/arch/arm/mach-omap2/board-generic.c
>>> @@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened 
>>> Device Tree)")
>>> .init_irq   = omap_gic_of_init,
>>> .init_machine   = omap_generic_init,
>>> .init_late  = omap4430_init_late,
>>> -   .init_time  = omap4_local_timer_init,
>>> +   .init_time  = omap4_init_time,
>>> .dt_compat  = omap4_boards_compat,
>>> .restart= omap44xx_restart,
>>>  MACHINE_END
>>
>> []..
>>> +#ifdef CONFIG_OF
>>> +int __init omap4_clk_init_dt(void)
>>> +{
>>> +   struct device_node *np;
>>> +
>>> +   np = of_find_compatible_node(NULL, NULL, "ti,omap4-scrm");
>>> +   if (np) {
>>> +   scrm_data.clks = scrm_clks;
>>> +   scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
>>> +   of_clk_add_provider(np, of_clk_src_onecell_get, &scrm_data);
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>
>> []..
>>> +
>>> +void __init omap4_init_time(void)
>>> +{
>>> +   omap4_clk_init_dt();
>>> +   omap4_local_timer_init();
>>> +}
>>
>> I guess you did all this because of_clk_add_provider() needs
>> slab to be initialized. With the below patch[1], now clk inits
>> happen within .init_timer already, so none of this would
>> be needed.
>>
>> [1] http://www.spinics.net/lists/arm-kernel/msg231288.html
>>
> 
> Right. I can then call omap4_clk_init_dt() from within omap4xxx_clk_init().
> 
> Any comments about the main subject? Does the approach look fine?

It looks fine, except for the fact that I was wondering if the clock
provider needs to restrict itself to SCRM.
Nishant Menon brought up a need for specifying the mpu clock source
from within DT, to be able to use a generic cpufreq driver.
It could be a provider (not specific to scrm, but having only scrm
clocks for now) which we could add clocks as and when we see a need for
them to be specified from DT.

Btw, you need to copy Paul Walmsley for any clock related patches as
he is the OMAP clock maintainer.

> 
> cheers,
> -roger
> 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

2013-03-21 Thread Rajendra Nayak
[]..

> diff --git a/arch/arm/mach-omap2/board-generic.c 
> b/arch/arm/mach-omap2/board-generic.c
> index 0274ff7..23f2064 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened 
> Device Tree)")
>   .init_irq   = omap_gic_of_init,
>   .init_machine   = omap_generic_init,
>   .init_late  = omap4430_init_late,
> - .init_time  = omap4_local_timer_init,
> + .init_time  = omap4_init_time,
>   .dt_compat  = omap4_boards_compat,
>   .restart= omap44xx_restart,
>  MACHINE_END

[]..
> +#ifdef CONFIG_OF
> +int __init omap4_clk_init_dt(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "ti,omap4-scrm");
> + if (np) {
> + scrm_data.clks = scrm_clks;
> + scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
> + of_clk_add_provider(np, of_clk_src_onecell_get, &scrm_data);
> + }
> +
> + return 0;
> +}

[]..
> +
> +void __init omap4_init_time(void)
> +{
> + omap4_clk_init_dt();
> + omap4_local_timer_init();
> +}

I guess you did all this because of_clk_add_provider() needs
slab to be initialized. With the below patch[1], now clk inits
happen within .init_timer already, so none of this would
be needed.

[1] http://www.spinics.net/lists/arm-kernel/msg231288.html

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 3/8] ARM: dts: omap: Add usb_otg and glue data

2013-02-06 Thread Rajendra Nayak

[]...



diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..4688265 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -15,6 +15,7 @@ OMAP MUSB GLUE
 represents PERIPHERAL.
   - power : Should be "50". This signifies the controller can supply upto
 100mA when operating in host mode.
+ - usb-phy : the phandle for the PHY device

  SOC specific device node entry
  usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..cb07583 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -107,3 +107,9 @@
 */
ti,pulldowns = <0x03a1c4>;
  };
+
+&usb_otg_hs {
+   interface_type = <0>;
+   mode = <3>;
+   power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
  &twl_gpio {
ti,use-leds;
  };
+
+&usb_otg_hs {
+   interface_type = <0>;
+   mode = <3>;
+   power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
  &twl_gpio {
ti,use-leds;
  };
+
+&usb_otg_hs {
+   interface_type = <0>;
+   mode = <3>;
+   power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..b6472f7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,17 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   usb_otg_hs: usb_otg_hs@480ab000 {
+   compatible = "ti,omap3-musb";
+   reg = <0x480ab000 0x1000>;
+   interrupts = <0 92 0x4>, <0 93 0x4>;
+   interrupt-names = "mc", "dma";
+   ti,hwmods = "usb_otg_hs";
+   usb-phy = <&usb2_phy>;
+   multipoint = <1>;
+   num_eps = <16>;
+   ram_bits = <12>;


Where are these bindings documented? The general convention is to use
a '-' for property names and not '_'


+   };
};
  };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..612c9bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -206,3 +206,9 @@
  &twl_usb_comparator {
usb-supply = <&vusb>;
  };
+
+&usb_otg_hs {
+   interface_type = <1>;
+   mode = <3>;
+   power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..582d7ee 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -428,3 +428,9 @@
  &twl_usb_comparator {
usb-supply = <&vusb>;
  };
+
+&usb_otg_hs {
+   interface_type = <1>;
+   mode = <3>;
+   power = <50>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c829d7e..5171739 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -542,5 +542,18 @@
reg-names = "control_dev_conf", "otghs_control";
ti,type = <1>;
};
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = "ti,omap4-musb";
+   reg = <0x4a0ab000 0x7ff>;
+   interrupts = <0 92 0x4>, <0 93 0x4>;
+   interrupt-names = "mc", "dma";
+   ti,hwmods = "usb_otg_hs";
+   usb-phy = <&usb2_phy>;
+   multipoint = <1>;
+   num_eps = <16>;
+   ram_bits = <12>;
+   ti,has-mailbox;
+   };
};
  };
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..398d2c3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -67,7 +67,7 @@
#interrupt-cells = <1>;
};

-   twl4030-usb {
+   usb2_phy: twl4030-usb {
compatible = "ti,twl4030-usb";
interrupts = <10>, <4>;
usb1v5-supply = <&vusb1v5>;



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: how to specify an OMAP clock in device tree?

2013-02-06 Thread Rajendra Nayak

On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote:

Doesn't look very elegant to me, but I wouldn't mind if there is no better 
option.
Even then, we can't rely on the device name as its index can change based on 
where it is


Well, thats what I said in the first mail, that *if* you are able to
fix the device name, *then* we could use clkdev the way its used in
non-DT case. But then you came back saying 'Fixing the device name
doesn't really solve the problem.' :)


located in the dts file. e.g. in the beginning it may be named phy.8, and if a 
device
node is added before it, it will get changed to phy.9


If you provide a phandle to the PHY node in the board node, for which
you need to add the clk alias, you can always extract the device (using
of_find_device_by_node() ) and hence its name, so it doesn't matter if
its phy.8 or phy.9.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: how to specify an OMAP clock in device tree?

2013-02-05 Thread Rajendra Nayak

On Tuesday 05 February 2013 07:59 PM, Roger Quadros wrote:

On 02/05/2013 04:21 PM, Rajendra Nayak wrote:

On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:

On 02/05/2013 04:13 PM, Rajendra Nayak wrote:

On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:

Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.


Are you saying different OMAP boards will use different Internal clocks?
Or different OMAP boards will use a single Internal clock or an
external one.


All I was saying is that one board can use for example auxclk1 whereas another
one can use auxclk3, both generated by OMAP for the same PHY configuration.


Ok, so lets keep DT aside for a while. How would something like this
work in a non-DT world? Would the driver then be able to do a
clk_get(dev, "main_clk"); and get say auxclk1 on one board and
auxclk3 on another?



Yes, all you need to do is specify an alias to the clock in the board file.


Can we then create a special board specific node for panda and do
similar things from DT?
See a similar discussion below on how to handle the gpio_request()
we had as part of board files
http://www.spinics.net/lists/linux-omap/msg85248.html



e.g. in board 1 file
clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL);

in board 2 file
clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL);

cheers,
-roger



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: how to specify an OMAP clock in device tree?

2013-02-05 Thread Rajendra Nayak

On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:

On 02/05/2013 04:13 PM, Rajendra Nayak wrote:

On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:

Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.


Are you saying different OMAP boards will use different Internal clocks?
Or different OMAP boards will use a single Internal clock or an
external one.


All I was saying is that one board can use for example auxclk1 whereas another
one can use auxclk3, both generated by OMAP for the same PHY configuration.


Ok, so lets keep DT aside for a while. How would something like this
work in a non-DT world? Would the driver then be able to do a
clk_get(dev, "main_clk"); and get say auxclk1 on one board and
auxclk3 on another?



cheers,
-roger



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: how to specify an OMAP clock in device tree?

2013-02-05 Thread Rajendra Nayak

On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:

Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.


Are you saying different OMAP boards will use different Internal clocks?
Or different OMAP boards will use a single Internal clock or an
external one.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 00/13] Device tree support for OMAP HS USB Host

2013-02-05 Thread Rajendra Nayak

On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:

This patchset adds device tree support for OMAP's High Speed USB Host
subsystem. Board adaptation for Panda and Beagleboard is also provided.

Tested on Beagleboard.

Will only work with Panda if we provide a reference to the PHY clock


But there is no reference provided even for Beagle. Does it work because
the default clk speed is 192Mhz?


generator in the device tree in PATCH 11. I do not know how to do that
as there is no way to provide a phandle to any of the OMAP generated clocks
in the device tree. Suggestions welcome:).


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: how to specify an OMAP clock in device tree?

2013-02-05 Thread Rajendra Nayak

On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote:

Hi Rajendra,

On 02/04/2013 05:58 PM, Roger Quadros wrote:

Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

Also provide pin multiplexer information for the USB host
pins.

Signed-off-by: Roger Quadros 
---
  arch/arm/boot/dts/omap4-panda.dts |   55 +
  1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..fe2d3d4 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,35 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+   /* HS USB Port 1 RESET */
+   hsusb1_reset: hsusb1_reset_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb1_reset";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 30 0>; /* gpio_62 */
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   /* HS USB Port 1 Power */
+   hsusb1_power: hsusb1_power_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb1_vbus";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio1 1 0>;  /* gpio_1 */
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   /* HS USB Host PHY on PORT 1 */
+   hsusb1_phy: hsusb1_phy {
+   compatible = "usb-nop-xceiv";
+   reset-supply = <&hsusb1_reset>;
+   vcc-supply = <&hsusb1_power>;
+   };


This is the patch I was discussing with you about before.

Let me explain the problem again.

The Pandaboard has a USB PHY whose reference clock is provided by
FREF_CLK3 pin which is a clock generated by the OMAP.
The PHY driver expects a reference to this clock in the PHY device node.


Well, the driver just does a clk_get(dev, "main_clk"); and clk_get() is
then able to either pick the reference from the PHY dt node or from a
clkdev entry.

The problem here seems to be that you are not able to add a clkdev entry
because the device name wouldn't be fixed, since you have a node in
the form of 'node: node {'. All other onchip OMAP devices don't have
this issue because they have an entry in the form of 'node: node@addr'
and hence have a fixed device name and hence can add a clkdev entry for
the clocks they want to control.

I don't know if there is any good way to define the DT node for the
on board PHY in such a way that the device name is always fixed, in
which case you can then add a clkdev entry for 'dev, main_clk' mapping
to the onchip clock that provides the clock, but if there is one, then
that should fix your problem.


See the above node hsusb1_phy. we would need something like
hsusb1_phy {
...
clocks = <&fref_clk3>;
clock-names = "main_clk";
...
};

Currently on OMAP, there is no way to provide a phandle to this clock.

Is it practical to provide device tree based implementation of at least
the externally accessible OMAP clocks?

cheers,
-roger


  };

  &omap4_pmx_core {
@@ -67,6 +96,7 @@
&mcbsp1_pins
&dss_hdmi_pins
&tpd12s015_pins
+   &hsusbb1_pins
>;

twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +140,23 @@
0x58 0x10b  /* hdmi_hpd.gpio_63 INPUT PULLDOWN | 
MODE3 */
>;
};





___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 2/2] arm/dts: Cleanup regulator naming and remove @0,1..

2012-08-27 Thread Rajendra Nayak

Hi Tony,


* Rajendra Nayak  [120730 06:17]:

regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.


Looks like this needs to be refreshed to apply. Care to
refresh against current devel-dt branch in case other
places need the same change?


Looks like devel-dt is missing the PATCH 1/2 from this series,
which you have already pushed in the -rc for merge.
With that applied, this ones applies cleanly too.

regards,
Rajendra



Regards,

Tony


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH 1/2] arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on

2012-07-30 Thread Rajendra Nayak
vcxio, v2v1 and v1v8 are expected to be always on, update the dtsi
for twl6030 to reflect this.

commit '86f5fc' regulator: core: Mark all DT based boards as having
full constraints) caused these to be disabled at late boot causing
OMAP4 boards (using twl6030) to lockup.

Reported-by: Kishon Vijay Abraham I 
Reported-by: J Keerthy 
Signed-off-by: Rajendra nayak 
---
 arch/arm/boot/dts/twl6030.dtsi |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..d351b27 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -66,6 +66,7 @@
 
vcxio: regulator@8 {
compatible = "ti,twl6030-vcxio";
+   regulator-always-on;
};
 
vusb: regulator@9 {
@@ -74,10 +75,12 @@
 
v1v8: regulator@10 {
compatible = "ti,twl6030-v1v8";
+   regulator-always-on;
};
 
v2v1: regulator@11 {
compatible = "ti,twl6030-v2v1";
+   regulator-always-on;
};
 
clk32kg: regulator@12 {
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH 2/2] arm/dts: Cleanup regulator naming and remove @0,1..

2012-07-30 Thread Rajendra Nayak
regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.

Reported-by: David Brown 
Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap3-beagle.dts |2 +-
 arch/arm/boot/dts/omap4-sdp.dts|4 ++--
 arch/arm/boot/dts/twl4030.dtsi |6 +++---
 arch/arm/boot/dts/twl6030.dtsi |   26 +-
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index cdcb98c..e60cba0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,7 +27,7 @@
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
 
-   vsim: regulator@10 {
+   vsim: regulator-vsim {
compatible = "ti,twl4030-vsim";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <300>;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 72216e9..dbcdc4a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -18,7 +18,7 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
 
-   vdd_eth: fixedregulator@0 {
+   vdd_eth: fixedregulator-vdd-eth {
compatible = "regulator-fixed";
regulator-name = "VDD_ETH";
regulator-min-microvolt = <330>;
@@ -28,7 +28,7 @@
regulator-boot-on;
};
 
-   vbat: fixedregulator@2 {
+   vbat: fixedregulator-vbat {
compatible = "regulator-fixed";
regulator-name = "VBAT";
regulator-min-microvolt = <375>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..ff00017 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -19,19 +19,19 @@
interrupts = <11>;
};
 
-   vdac: regulator@0 {
+   vdac: regulator-vdac {
compatible = "ti,twl4030-vdac";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
};
 
-   vpll2: regulator@1 {
+   vpll2: regulator-vpll2 {
compatible = "ti,twl4030-vpll2";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
};
 
-   vmmc1: regulator@2 {
+   vmmc1: regulator-vmmc1 {
compatible = "ti,twl4030-vmmc1";
regulator-min-microvolt = <185>;
regulator-max-microvolt = <315>;
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index d351b27..123e2c4 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -20,70 +20,70 @@
interrupts = <11>;
};
 
-   vaux1: regulator@0 {
+   vaux1: regulator-vaux1 {
compatible = "ti,twl6030-vaux1";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <300>;
};
 
-   vaux2: regulator@1 {
+   vaux2: regulator-vaux2 {
compatible = "ti,twl6030-vaux2";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <280>;
};
 
-   vaux3: regulator@2 {
+   vaux3: regulator-vaux3 {
compatible = "ti,twl6030-vaux3";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <300>;
};
 
-   vmmc: regulator@3 {
+   vmmc: regulator-vmmc {
compatible = "ti,twl6030-vmmc";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <300>;
};
 
-   vpp: regulator@4 {
+   vpp: regulator-vpp {
compatible = "ti,twl6030-vpp";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <250>;
};
 
-   vusim: regulator@5 {
+   vusim: regulator-vusim {
compatible = "ti,twl6030-vusim";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <290>;
};
 
-   vdac: regulator@6 {
+   vdac: regulator-vdac {
compatible = "ti,twl6030-vdac";
};
 
-   vana: regulator@7 {
+   vana: regulator-vana {
compatible = "ti,twl6030-vana";
};
 
-   vcxio: regulator@8 {
+   vcxio: regulator-vcxio {
compatible

[PATCH 0/2] OMAP DT fixes

2012-07-30 Thread Rajendra Nayak
Hi Tony,

These are couple of DT fixes for OMAP, first fixes a lockup
/boot failure on OMAP4 boards (SDP and panda) on mainline,
second is a long pending cleanup.

regards,
Rajendra

Rajendra Nayak (2):
  arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on
  arm/dts: Cleanup regulator naming and remove @0,1..

 arch/arm/boot/dts/omap3-beagle.dts |2 +-
 arch/arm/boot/dts/omap4-sdp.dts|4 ++--
 arch/arm/boot/dts/twl4030.dtsi |6 +++---
 arch/arm/boot/dts/twl6030.dtsi |   29 -
 4 files changed, 22 insertions(+), 19 deletions(-)

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c

2012-07-10 Thread Rajendra Nayak

On Tuesday 10 July 2012 01:46 PM, ABRAHAM, KISHON VIJAY wrote:

Hi,

On Tue, Jul 10, 2012 at 11:59 AM, Rajendra Nayak  wrote:

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:


All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.

Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
   arch/arm/mach-omap2/omap_phy_internal.c |  138
---
   arch/arm/mach-omap2/twl-common.c|5 -
   arch/arm/mach-omap2/usb-musb.c  |3 -
   3 files changed, 0 insertions(+), 146 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0c610b4 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
   #include
   #include "control.h"

-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF   0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL   0x33c
-#defineAVALID  BIT(0)
-#defineBVALID  BIT(1)
-#defineVBUSVALID   BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG   BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
-   ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
-   if (!ctrl_base) {
-   pr_err("control module ioremap failed\n");
-   return -ENOMEM;
-   }
-   /* Power down the phy */
-   __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);



Just checking, but I hope your new driver handles this too.
You might not see any issues with it now, but not doing this could
gate OMAP hitting low power in idle.


I power down the phy during probe in omap-usb2 phy driver.


ok, thanks, good to know.



Thanks
Kishon


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 10/11] arm/dts: omap: Add usb_otg and glue data

2012-07-10 Thread Rajendra Nayak

On Tuesday 10 July 2012 01:43 PM, ABRAHAM, KISHON VIJAY wrote:

Hi,

On Tue, Jul 10, 2012 at 11:57 AM, Rajendra Nayak  wrote:

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:


Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.dts file.

Signed-off-by: Kishon Vijay Abraham I
---
   arch/arm/boot/dts/omap3-beagle.dts |6 ++
   arch/arm/boot/dts/omap3-evm.dts|6 ++
   arch/arm/boot/dts/omap3.dtsi   |8 
   arch/arm/boot/dts/omap4-panda.dts  |6 ++
   arch/arm/boot/dts/omap4-sdp.dts|6 ++
   arch/arm/boot/dts/omap4.dtsi   |8 
   6 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
   &mmc3 {
 status = "disable";
   };
+
+&usb_otg_hs {
+   interface_type =<0>;
+   mode =<3>;
+   power =<50>;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts
b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
 reg =<0x8000 0x1000>; /* 256 MB */
 };
   };
+
+&usb_otg_hs {
+   interface_type =<0>;
+   mode =<3>;
+   power =<50>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..2f565d6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
 compatible = "ti,omap3-hsmmc";
 ti,hwmods = "mmc3";
 };
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = "ti,musb-omap2430";



this compatible doesn't seem right in omap3.dtsi. Same with
the below entry in omap4.dtsi.
See other IP blocks which are reused across OMAP2/3/4 on
how the compatible for those are handled.


Ok. So it should be like *ti,omap4-musb*, *ti,omap3-musb*?


Yes, that would be more appropriate.



Thanks
Kishon


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

2012-07-10 Thread Rajendra Nayak

On Tuesday 10 July 2012 12:18 PM, ABRAHAM, KISHON VIJAY wrote:

Hi,

On Tue, Jul 10, 2012 at 11:33 AM, Venu Byravarasu
  wrote:

+
+#ifdef CONFIG_PM


Should it not be CONFIG_PM_SLEEP instead of just CONFIG_PM?


Why? I think we should have CONFIG_PM_SLEEP only when we have
*suspend*, *resume* hooks. But this driver has only *runtime_suspend*
and *runtime_resume* hooks.


CONFIG_PM_RUNTIME maybe then?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb

2012-07-10 Thread Rajendra Nayak

On Tuesday 10 July 2012 12:22 PM, ABRAHAM, KISHON VIJAY wrote:

+TWL4030 USB PHY AND COMPARATOR
>>  + - compatible : Should be "ti,twl4030-usb"
>>  + - interrupts : The interrupt numbers to the cpu should be specified.
>>  First
>>  +   interrupt number is the otg interrupt number that raises ID interrupts
>>  +   and VBUS interrupts. The second interrupt number is optional.
>>  + --supply : phandle to the regulator device tree node.
>>  +   should be vusb1v5, vusb1v8 and vusb3v1
>>  + - usb_mode : The mode used by the phy to connect to the controller. "1"
>>  +   specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode.

>
>
>  Are these standard usb phy modes or something specific to the twl4030
>  usb phy?

These are standard modes used to connect the phy to the controller. I
think it's used by other chips other than twl4030 (Something in
am35xx??).


So would it make sense to document these bindings independent of a given
phy and a given controller, so it could be reused and not duplicated in
various forms for various different controllers.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

2012-07-09 Thread Rajendra Nayak



+
+static int __devinit omap_usb2_probe(struct platform_device *pdev)
+{
+   struct omap_usb *phy;
+   struct usb_otg  *otg;
+   struct resource *res;
+
+   phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+   if (!phy) {
+   dev_err(&pdev->dev, "unable to allocate memory for USB2
PHY\n");
+   return -ENOMEM;
+   }
+
+   otg = devm_kzalloc(&pdev->dev, sizeof(*otg), GFP_KERNEL);
+   if (!otg) {
+   dev_err(&pdev->dev, "unable to allocate memory for USB
OTG\n");
+   return -ENOMEM;
+   }
+
+   phy->dev=&pdev->dev;

+
+   phy->phy.dev= phy->dev;
+   phy->phy.label  = "omap-usb2";
+   phy->phy.set_suspend= omap_usb2_suspend;
+   phy->phy.otg= otg;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+   phy->control_dev_conf = devm_request_and_ioremap(&pdev->dev, res);
+   if (phy->control_dev_conf == NULL) {
+   dev_err(&pdev->dev, "Failed to obtain io memory\n");
+   return -ENXIO;
+   }
+
+   phy->is_suspended   = 1;
+   omap_usb_phy_power(phy, 0);
+
+   otg->set_host   = omap_usb_set_host;
+   otg->set_peripheral = omap_usb_set_peripheral;
+   otg->set_vbus   = omap_usb_set_vbus;
+   otg->start_srp  = omap_usb_start_srp;
+   otg->phy=&phy->phy;

+
+   phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");



Why not just use clk_get()? What does devm_clk_get() do?

It just associates the clk with the device. So whenever the the driver
gets detached, the devres will take care to do a clk_put() of the
clock.


ok, makes sense.





+   if (IS_ERR(phy->wkupclk)) {
+   dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
+   return PTR_ERR(phy->wkupclk);
+   }
+   clk_prepare(phy->wkupclk);



Ideally clk_prepare() is an extension of clk_enable() and is expected
to be used that way. Not to be clubbed with clk_get(). Same with
clk_unprepare(). Do you do a clk_enable()/_disable() in interrupt/
atomic context?


Currently it is called from a work queue. But Felipe wanted to remove
those work_queue from omap2430 glue. Then this would be called from
atomic context.
A query for you here. If pm_runtime_get_sync() is called in interrupt
context, will runtime resume of that device will also be called in the
same context?


Yes, it would. You also need to then tell the runtime pm framework about
it by calling a pm_runtime_irq_safe() api I guess.

regards,
Rajendra







+
+   usb_add_phy(&phy->phy, USB_PHY_TYPE_USB2);
+
+   platform_set_drvdata(pdev, phy);
+
+   pm_runtime_enable(phy->dev);
+
+   return 0;
+}
+
+static int __devexit omap_usb2_remove(struct platform_device *pdev)
+{
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_unprepare(phy->wkupclk);
+   usb_remove_phy(&phy->phy);
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+#ifdef CONFIG_PM
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_disable(phy->wkupclk);
+
+   return 0;
+}
+
+static int omap_usb2_runtime_resume(struct device *dev)
+{
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_enable(phy->wkupclk);
+
+   return 0;
+}
+
+static const struct dev_pm_ops omap_usb2_pm_ops = {
+   SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend,
omap_usb2_runtime_resume,
+   NULL)
+};
+
+#define DEV_PM_OPS (&omap_usb2_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id omap_usb2_id_table[] = {
+   { .compatible = "ti,omap-usb2" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#else
+#define omap_usb2_id_table NULL;
+#endif
+
+static struct platform_driver omap_usb2_driver = {
+   .probe  = omap_usb2_probe,
+   .remove = __devexit_p(omap_usb2_remove),
+   .driver = {
+   .name   = "omap-usb2",
+   .owner  = THIS_MODULE,
+   .pm = DEV_PM_OPS,
+   .of_match_table = omap_usb2_id_table,



Use of_match_ptr() instead.


Ok. And I'll remove #define omap_usb2_id_table NULL;.

Thanks
Kishon


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb

2012-07-09 Thread Rajendra Nayak

On Tuesday 10 July 2012 11:58 AM, ABRAHAM, KISHON VIJAY wrote:

Hi,

On Tue, Jul 10, 2012 at 11:28 AM, Rajendra Nayak  wrote:

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:


Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I
---
   .../devicetree/bindings/usb/twl-usb.txt|   18 
   drivers/usb/otg/twl6030-usb.c  |   45
++--
   2 files changed, 50 insertions(+), 13 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be "ti,twl6030-usb"
+ - interrupts : Two interrupt numbers to the cpu should be specified.
First
+   interrupt number is the otg interrupt number that raises ID interrupts
when
+   the controller has to act as host and the second interrupt number is
the
+   usb interrupt number that raises VBUS interrupts when the controller
has to
+   act as device
+ - regulator :   can be "vusb" or "ldousb"
+ --supply : phandle to the regulator device tree node
+
+twl6030-usb {
+   compatible = "ti,twl6030-usb";
+   interrupts =<   4 10>;
+   regulator = "vusb";
+   vusb-supply =<&vusb>;



This doesn't seem right. Why do you ned a 'regulator' string along
with the phandle?


The original code was something like
if (twl->features&  TWL6025_SUBCLASS)
regulator_name = "ldousb";
else
regulator_name = "vusb";

I wasn't sure how to handle this *TWL6025_SUBCLASS* stuff.




+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
 u8  asleep;
 boolirq_enabled;
 boolvbus_enable;
-   unsigned long   features;
+   const char  *regulator;
   };

   #define   comparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)

   static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
   {
-   char *regulator_name;
-
-   if (twl->features&   TWL6025_SUBCLASS)

-   regulator_name = "ldousb";
-   else
-   regulator_name = "vusb";
-
 /* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
 twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);

@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb
*twl)
 /* Program MISC2 register and set bit VUSB_IN_VBAT */
 twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);

-   twl->usb3v3 = regulator_get(twl->dev, regulator_name);
+   twl->usb3v3 = regulator_get(twl->dev, twl->regulator);
 if (IS_ERR(twl->usb3v3))
 return -ENODEV;

@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
   {
 struct twl6030_usb  *twl;
 int status, err;
-   struct twl4030_usb_data *pdata;
-   struct device *dev =&pdev->dev;

-   pdata = dev->platform_data;
+   struct device_node  *np = pdev->dev.of_node;
+   struct device   *dev =&pdev->dev;

+   struct twl4030_usb_data *pdata = dev->platform_data;

 twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
 if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
 twl->dev=&pdev->dev;

 twl->irq1   = platform_get_irq(pdev, 0);
 twl->irq2   = platform_get_irq(pdev, 1);
-   twl->features   = pdata->features;
 twl->linkstat   = OMAP_MUSB_UNKNOWN;

 twl->comparator.set_vbus= twl6030_set_vbus;
 twl->comparator.start_srp   = twl6030_start_srp;
 omap_usb2_set_comparator(&twl->comparator);

+   if (np) {
+   err = of_property_read_string(np,
"regulator",&twl->regulator);

+   if (err<   0) {
+   dev_err(&pdev->dev, "unable to get regulator\n");
+   return err;
+   }



Isn't there a better way for the driver to know which supply to use inste

Re: [PATCH v1 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c

2012-07-09 Thread Rajendra Nayak

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:

All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.

Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
  arch/arm/mach-omap2/omap_phy_internal.c |  138 ---
  arch/arm/mach-omap2/twl-common.c|5 -
  arch/arm/mach-omap2/usb-musb.c  |3 -
  3 files changed, 0 insertions(+), 146 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c 
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0c610b4 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
  #include
  #include "control.h"

-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF   0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL   0x33c
-#defineAVALID  BIT(0)
-#defineBVALID  BIT(1)
-#defineVBUSVALID   BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG   BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
-   ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
-   if (!ctrl_base) {
-   pr_err("control module ioremap failed\n");
-   return -ENOMEM;
-   }
-   /* Power down the phy */
-   __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);


Just checking, but I hope your new driver handles this too.
You might not see any issues with it now, but not doing this could
gate OMAP hitting low power in idle.

regards,
Rajendra


-
-   if (!dev) {
-   iounmap(ctrl_base);
-   return 0;
-   }
-
-   phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
-   if (IS_ERR(phyclk)) {
-   dev_err(dev, "cannot clk_get ocp2scp_usb_phy_ick\n");
-   iounmap(ctrl_base);
-   return PTR_ERR(phyclk);
-   }
-
-   clk48m = clk_get(dev, "ocp2scp_usb_phy_phy_48m");
-   if (IS_ERR(clk48m)) {
-   dev_err(dev, "cannot clk_get ocp2scp_usb_phy_phy_48m\n");
-   clk_put(phyclk);
-   iounmap(ctrl_base);
-   return PTR_ERR(clk48m);
-   }
-
-   clk32k = clk_get(dev, "usb_phy_cm_clk32k");
-   if (IS_ERR(clk32k)) {
-   dev_err(dev, "cannot clk_get usb_phy_cm_clk32k\n");
-   clk_put(phyclk);
-   clk_put(clk48m);
-   iounmap(ctrl_base);
-   return PTR_ERR(clk32k);
-   }
-   return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
-   static int state;
-
-   if (on&&  !state) {
-   /* Enable the phy clocks */
-   clk_enable(phyclk);
-   clk_enable(clk48m);
-   clk_enable(clk32k);
-   state = 1;
-   } else if (state) {
-   /* Disable the phy clocks */
-   clk_disable(phyclk);
-   clk_disable(clk48m);
-   clk_disable(clk32k);
-   state = 0;
-   }
-   return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
-   if (on) {
-   if (ID)
-   /* enable VBUS valid, IDDIG groung */
-   __raw_writel(AVALID | VBUSVALID, ctrl_base +
-   USBOTGHS_CONTROL);
-   else
-   /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
-   __raw_writel(IDDIG | AVALID | VBUSVALID,
-   ctrl_base + USBOTGHS_CONTROL);
-   } else {
-   /* Enable session END and IDIG to high impedance. */
-   __raw_writel(SESSEND | IDDIG, ctrl_base +
-   USBOTGHS_CONTROL);
-   }
-   return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
-   if (suspend) {
-   /* Disable the clocks */
-   omap4430_phy_set_clk(dev, 0);
-   /* Power down the phy */
-   __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
-   /* save the context */
-   usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
-   } else {
-   /* Enable the internel phy clcoks */
-   omap4430_phy_set_clk(dev, 1);
-   /* power on the phy */
-   if (__raw_readl(ctrl_base + CONTROL_DEV_CONF)&  PHY_PD) {
-   __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-   mdelay(200);
-   }
-
-   

Re: [PATCH v1 10/11] arm/dts: omap: Add usb_otg and glue data

2012-07-09 Thread Rajendra Nayak

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:

Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.dts file.

Signed-off-by: Kishon Vijay Abraham I
---
  arch/arm/boot/dts/omap3-beagle.dts |6 ++
  arch/arm/boot/dts/omap3-evm.dts|6 ++
  arch/arm/boot/dts/omap3.dtsi   |8 
  arch/arm/boot/dts/omap4-panda.dts  |6 ++
  arch/arm/boot/dts/omap4-sdp.dts|6 ++
  arch/arm/boot/dts/omap4.dtsi   |8 
  6 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
  &mmc3 {
status = "disable";
  };
+
+&usb_otg_hs {
+   interface_type =<0>;
+   mode =<3>;
+   power =<50>;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg =<0x8000 0x1000>; /* 256 MB */
};
  };
+
+&usb_otg_hs {
+   interface_type =<0>;
+   mode =<3>;
+   power =<50>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..2f565d6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = "ti,omap3-hsmmc";
ti,hwmods = "mmc3";
};
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = "ti,musb-omap2430";


this compatible doesn't seem right in omap3.dtsi. Same with
the below entry in omap4.dtsi.
See other IP blocks which are reused across OMAP2/3/4 on
how the compatible for those are handled.


+   ti,hwmods = "usb_otg_hs";
+   multipoint =<1>;
+   num_eps =<16>;
+   ram_bits =<12>;
+   };
};
  };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..0825fa7 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,9 @@
ti,non-removable;
bus-width =<4>;
  };
+
+&usb_otg_hs {
+   interface_type =<1>;
+   mode =<3>;
+   power =<50>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..5244d51 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,9 @@
bus-width =<4>;
ti,non-removable;
  };
+
+&usb_otg_hs {
+   interface_type =<1>;
+   mode =<3>;
+   power =<50>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4d2dcc1..bc7b3c3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
<0x4a002300 0x1>;
};
};
+
+   usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = "ti,musb-omap2430";
+   ti,hwmods = "usb_otg_hs";
+   multipoint =<1>;
+   num_eps =<16>;
+   ram_bits =<12>;
+   };
};
  };


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 08/11] arm/dts: Add twl4030-usb data

2012-07-09 Thread Rajendra Nayak

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:

Add twl4030-usb data node in twl4030 device tree file.

Signed-off-by: Kishon Vijay Abraham I
---
  arch/arm/boot/dts/twl4030.dtsi |   21 +
  1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..66534a3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt =<315>;
};

+   vusb1v5: regulator@3 {
+   compatible = "ti,twl4030-vusb1v5";
+   };


These @3, @4 are actually wrong since the node do
not have a 'reg' property in it. This was commented on
by David Brown on my original series which added this but
it somehow slipped through the cracks. I understand that
you would have looked up what existed in the file and
extended, but what already exists in the file needs to
be fixed up too. I'll send in a patch to fix those up.

regards,
Rajendra


+
+   vusb1v8: regulator@4 {
+   compatible = "ti,twl4030-vusb1v8";
+   };
+
+   vusb3v1: regulator@5 {
+   compatible = "ti,twl4030-vusb3v1";
+   };
+
twl_gpio: gpio {
compatible = "ti,twl4030-gpio";
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells =<1>;
};
+
+   twl4030-usb {
+   compatible = "ti,twl4030-usb";
+   interrupts =<  10 4>;
+   usb1v5-supply =<&vusb1v5>;
+   usb1v8-supply =<&vusb1v8>;
+   usb3v1-supply =<&vusb3v1>;
+   usb_mode =<1>;
+   };
  };


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb

2012-07-09 Thread Rajendra Nayak

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:

Add device tree support for twl6030 usb driver.


twl4030?


Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I
---
  .../devicetree/bindings/usb/twl-usb.txt|   19 +
  drivers/usb/otg/twl4030-usb.c  |   28 +++
  2 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt 
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index f293271..2d069e4 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -16,3 +16,22 @@ twl6030-usb {
regulator = "vusb";
vusb-supply =<&vusb>;
  };
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be "ti,twl4030-usb"
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+   interrupt number is the otg interrupt number that raises ID interrupts
+   and VBUS interrupts. The second interrupt number is optional.
+ --supply : phandle to the regulator device tree node.
+  should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. "1"
+   specifies "ULPI" mode and "2" specifies "CEA2011_3PIN" mode.


Are these standard usb phy modes or something specific to the twl4030
usb phy?


+
+twl4030-usb {
+   compatible = "ti,twl4030-usb";
+   interrupts =<  10 4>;
+   vusb1v5-supply =<&vusb1v5>;
+   vusb1v8-supply =<&vusb1v8>;
+   vusb3v1-supply =<&vusb3v1>;
+   usb_mode =<1>;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..a4e7434 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct 
platform_device *pdev)
struct twl4030_usb  *twl;
int status, err;
struct usb_otg  *otg;
-
-   if (!pdata) {
-   dev_dbg(&pdev->dev, "platform_data not available\n");
-   return -EINVAL;
-   }
+   struct device_node  *np = pdev->dev.of_node;

twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;

+   if (np)
+   of_property_read_u32(np, "usb_mode",
+   (enum twl4030_usb_mode *)&twl->usb_mode);
+   else if (pdata)
+   twl->usb_mode = pdata->usb_mode;
+   else {
+   dev_err(&pdev->dev, "twl4030 initialized without pdata\n");
+   return -EINVAL;
+   }
+
otg = devm_kzalloc(&pdev->dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;

twl->dev =&pdev->dev;
twl->irq = platform_get_irq(pdev, 0);
-   twl->usb_mode= pdata->usb_mode;
twl->vbus_supplied   = false;
twl->asleep  = 1;
twl->linkstat= OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,23 @@ static int __exit twl4030_usb_remove(struct 
platform_device *pdev)
return 0;
  }

+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+   { .compatible = "ti,twl4030-usb" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#else
+#define twl4030_usb_id_table NULL
+#endif
+
  static struct platform_driver twl4030_usb_driver = {
.probe  = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name   = "twl4030_usb",
.owner  = THIS_MODULE,
+   .of_match_table = twl4030_usb_id_table,


use of_match_ptr().


},
  };



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb

2012-07-09 Thread Rajendra Nayak

On Thursday 28 June 2012 05:21 PM, Kishon Vijay Abraham I wrote:

Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I
---
  .../devicetree/bindings/usb/twl-usb.txt|   18 
  drivers/usb/otg/twl6030-usb.c  |   45 ++--
  2 files changed, 50 insertions(+), 13 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt 
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be "ti,twl6030-usb"
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+   interrupt number is the otg interrupt number that raises ID interrupts when
+   the controller has to act as host and the second interrupt number is the
+   usb interrupt number that raises VBUS interrupts when the controller has to
+   act as device
+ - regulator :  can be "vusb" or "ldousb"
+ --supply : phandle to the regulator device tree node
+
+twl6030-usb {
+   compatible = "ti,twl6030-usb";
+   interrupts =<  4 10>;
+   regulator = "vusb";
+   vusb-supply =<&vusb>;


This doesn't seem right. Why do you ned a 'regulator' string along
with the phandle?


+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8  asleep;
boolirq_enabled;
boolvbus_enable;
-   unsigned long   features;
+   const char  *regulator;
  };

  #define   comparator_to_twl(x) container_of((x), struct twl6030_usb, 
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion 
*comparator)

  static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
  {
-   char *regulator_name;
-
-   if (twl->features&  TWL6025_SUBCLASS)
-   regulator_name = "ldousb";
-   else
-   regulator_name = "vusb";
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);

@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);

-   twl->usb3v3 = regulator_get(twl->dev, regulator_name);
+   twl->usb3v3 = regulator_get(twl->dev, twl->regulator);
if (IS_ERR(twl->usb3v3))
return -ENODEV;

@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
  {
struct twl6030_usb  *twl;
int status, err;
-   struct twl4030_usb_data *pdata;
-   struct device *dev =&pdev->dev;
-   pdata = dev->platform_data;
+   struct device_node  *np = pdev->dev.of_node;
+   struct device   *dev =&pdev->dev;
+   struct twl4030_usb_data *pdata = dev->platform_data;

twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
twl->dev =&pdev->dev;
twl->irq1= platform_get_irq(pdev, 0);
twl->irq2= platform_get_irq(pdev, 1);
-   twl->features= pdata->features;
twl->linkstat= OMAP_MUSB_UNKNOWN;

twl->comparator.set_vbus = twl6030_set_vbus;
twl->comparator.start_srp= twl6030_start_srp;
omap_usb2_set_comparator(&twl->comparator);

+   if (np) {
+   err = of_property_read_string(np, "regulator",&twl->regulator);
+   if (err<  0) {
+   dev_err(&pdev->dev, "unable to get regulator\n");
+   return err;
+   }


Isn't there a better way for the driver to know which supply to use 
instead of DT passing the supply name?


regards,
Rajendra


+   } else if (pdata) {
+   if (pdata->features&  TWL6025_SUBCLASS)
+   twl->regulator = "ldousb";
+   else
+   twl->regulator = "vusb";
+   } else {
+   dev_err(&pdev->dev, "twl6030 initialized without pdata\n");
+   return -EINVAL;
+   }
+
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);

@@ -403,12 +411,23 @@ static int __exit twl6030_usb_remove(struct 
platform_device *pdev)
return 0;
  }

+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+   

Re: [PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

2012-07-09 Thread Rajendra Nayak

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb2"
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+   compatible = "ti,omap-usb2";
+   reg =<0x4a0ad080 0x58>;


Don;t you need a 'ti,hwmods' entry for this one?


--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,273 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com


Copyright (C) 2012? Same for the couple of headers below.


+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+



+
+static int __devinit omap_usb2_probe(struct platform_device *pdev)
+{
+   struct omap_usb *phy;
+   struct usb_otg  *otg;
+   struct resource *res;
+
+   phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+   if (!phy) {
+   dev_err(&pdev->dev, "unable to allocate memory for USB2 PHY\n");
+   return -ENOMEM;
+   }
+
+   otg = devm_kzalloc(&pdev->dev, sizeof(*otg), GFP_KERNEL);
+   if (!otg) {
+   dev_err(&pdev->dev, "unable to allocate memory for USB OTG\n");
+   return -ENOMEM;
+   }
+
+   phy->dev =&pdev->dev;
+
+   phy->phy.dev = phy->dev;
+   phy->phy.label   = "omap-usb2";
+   phy->phy.set_suspend = omap_usb2_suspend;
+   phy->phy.otg = otg;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+   phy->control_dev_conf = devm_request_and_ioremap(&pdev->dev, res);
+   if (phy->control_dev_conf == NULL) {
+   dev_err(&pdev->dev, "Failed to obtain io memory\n");
+   return -ENXIO;
+   }
+
+   phy->is_suspended= 1;
+   omap_usb_phy_power(phy, 0);
+
+   otg->set_host= omap_usb_set_host;
+   otg->set_peripheral  = omap_usb_set_peripheral;
+   otg->set_vbus= omap_usb_set_vbus;
+   otg->start_srp   = omap_usb_start_srp;
+   otg->phy =&phy->phy;
+
+   phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");


Why not just use clk_get()? What does devm_clk_get() do?


+   if (IS_ERR(phy->wkupclk)) {
+   dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
+   return PTR_ERR(phy->wkupclk);
+   }
+   clk_prepare(phy->wkupclk);


Ideally clk_prepare() is an extension of clk_enable() and is expected
to be used that way. Not to be clubbed with clk_get(). Same with
clk_unprepare(). Do you do a clk_enable()/_disable() in interrupt/
atomic context?


+
+   usb_add_phy(&phy->phy, USB_PHY_TYPE_USB2);
+
+   platform_set_drvdata(pdev, phy);
+
+   pm_runtime_enable(phy->dev);
+
+   return 0;
+}
+
+static int __devexit omap_usb2_remove(struct platform_device *pdev)
+{
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_unprepare(phy->wkupclk);
+   usb_remove_phy(&phy->phy);
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+#ifdef CONFIG_PM
+
+static int omap_usb2_runtime_suspend(struct device *dev)
+{
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_disable(phy->wkupclk);
+
+   return 0;
+}
+
+static int omap_usb2_runtime_resume(struct device *dev)
+{
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct omap_usb *phy = platform_get_drvdata(pdev);
+
+   clk_enable(phy->wkupclk);
+
+   return 0;
+}
+
+static const struct dev_pm_ops omap_usb2_pm_ops = {
+   SET_RUNTIME_PM_OPS(omap_usb2_runtime_suspend, omap_usb2_runtime_resume,
+   NULL)
+};
+
+#define DEV_PM_OPS (&omap_usb2_pm_ops)
+#else
+#define DEV_PM_OPS NULL
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id omap_usb2_id_table[] = {
+   { .compatible = "ti,omap-usb2" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#else
+#

Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage

2012-04-11 Thread Rajendra Nayak

On Wednesday 11 April 2012 03:56 PM, Felipe Balbi wrote:

On Wed, Apr 11, 2012 at 03:54:28PM +0530, Rajendra Nayak wrote:

On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:

On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:

@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 * can't be allowed when booting with device
 * tree.
 */
-   (!of_have_populated_dt())) {
+   !host->dev->of_node) {


won't compile


why? compiles fine for me.


aren't you missing the opening parenthesis ? Or is there a something not
shown in the context ?


Its the missing context thats confusing :-)

This is how the code looks in the file after the patch.

   if ((OMAP_HSMMC_READ(host->base, HCTL) & SDVSDET) &&
(ios->vdd == DUAL_VOLT_OCR_BIT) &&
/*
 * With pbias cell programming missing, this
 * can't be allowed when booting with device
 * tree.
 */
!host->dev->of_node) {



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage

2012-04-11 Thread Rajendra Nayak

On Wednesday 11 April 2012 03:39 PM, Felipe Balbi wrote:

On Wed, Apr 11, 2012 at 03:33:13PM +0530, Rajendra Nayak wrote:

@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 * can't be allowed when booting with device
 * tree.
 */
-   (!of_have_populated_dt())) {
+   !host->dev->of_node) {


won't compile


why? compiles fine for me.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage

2012-04-11 Thread Rajendra Nayak
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev->of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.

ERROR: "allnodes" [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev->of_node to make the same dicisions as earlier.

Signed-off-by: Rajendra Nayak 
Reported-by: Benoit Cousson 
Cc: Balaji TK 
Cc: Rob Herring 
Cc: Sebastian Andrzej Siewior 
---
 drivers/mmc/host/omap_hsmmc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
 * the pbias cell programming support is still missing when
 * booting with Device tree
 */
-   if (of_have_populated_dt() && !vdd)
+   if (dev->of_node && !vdd)
return 0;
 
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 * can't be allowed when booting with device
 * tree.
 */
-   (!of_have_populated_dt())) {
+   !host->dev->of_node) {
/*
 * The mmc_select_voltage fn of the core does
 * not seem to set the power_mode to
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC] dt: export of_have_populated_dt

2012-04-10 Thread Rajendra Nayak

On Tuesday 10 April 2012 08:41 PM, Balaji T K wrote:

If of_have_populated_dt is called from module, build fails with "allnodes"
undefined error, so remove inline and export of_have_populated_dt.


Thanks Balaji, for taking care of this while I was out.
But like Rob and Sebastian mentioned, looks like the usage of
of_have_populated_dt() itself is wrong in the first place.
So I will fix that up with a patch shortly.



Signed-off-by: Balaji T K
---
  drivers/of/base.c  |6 ++
  include/linux/of.h |6 +-
  2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5806449..dc1af42 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -186,6 +186,12 @@ struct property *of_find_property(const struct device_node 
*np,
  }
  EXPORT_SYMBOL(of_find_property);

+bool of_have_populated_dt(void)
+{
+   return allnodes != NULL;
+}
+EXPORT_SYMBOL(of_have_populated_dt);
+
  /**
   * of_find_all_nodes - Get next node in global list
   * @prev: Previous node or NULL to start iteration
diff --git a/include/linux/of.h b/include/linux/of.h
index fa7fb1d..28e933e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -92,11 +92,6 @@ extern struct device_node *of_chosen;
  extern struct device_node *of_aliases;
  extern rwlock_t devtree_lock;

-static inline bool of_have_populated_dt(void)
-{
-   return allnodes != NULL;
-}
-
  static inline bool of_node_is_root(const struct device_node *node)
  {
return node&&  (node->parent == NULL);
@@ -112,6 +107,7 @@ static inline void of_node_set_flag(struct device_node *n, 
unsigned long flag)
set_bit(flag,&n->_flags);
  }

+extern bool of_have_populated_dt(void);
  extern struct device_node *of_find_all_nodes(struct device_node *prev);

  /*


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [RFC] dt: export of_have_populated_dt

2012-04-10 Thread Rajendra Nayak

On Tuesday 10 April 2012 10:50 PM, Rob Herring wrote:

Rob,
>  Does it make sense to use that in the driver? So far I was using that
>  only in the arch code to make the difference between the DT boot and the
>  non-DT boot.
>
>  I guess that a driver should rely on of_match_device or non-NULL
>  device_node to figure out that?
>

Agreed. of_match_device or device_node ptr check is the right approach.


Thanks Rob, I'll post a patch to fix that up.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 2/4] mmc: omap_hsmmc: Avoid a regulator voltage change with dt

2012-03-12 Thread Rajendra Nayak
When booting with Device tree, the omap_hsmmc driver does not
program the pbias cell (inside OMAP control module) during
a regulator voltage change.
In case of non-dt boot, this is handled using callbacks
from within platform_data and implemented in machine code.
To be able to do this with device tree, without invoking
any machine code, a OMAP control module driver is needed
which is yet missing.

The pbias cell is used to provide a 1.8v or 3.0v reference
to the mmc/sd/sdio1 interface supporting both 1.8v and 3.0v
voltages.

Until a OMAP control module driver is available to handle this,
when booting with a device tree blob, never change the regulator
voltage which might then require a pbias cell re-program.
There are 2 instances where in the mmc regulator voltage can be
changed.
-1- when the regulator is turned OFF.
-2- when attempting a switch to 1.8v from 3.0v for dual volt cards

This patch avoids a voltage change in both cases when booting from
device tree, and hence compromises on power savings.
Once the OMAP control module driver is available and hsmmc driver
is modified to then do pbias programming even when booting
with device tree, these limitaions can be removed to achieve better
power savings.

Signed-off-by: Rajendra Nayak 
---
 drivers/mmc/host/omap_hsmmc.c |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 38ae8c0..f29e1a2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -244,6 +244,13 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
 */
if (!host->vcc)
return 0;
+   /*
+* With DT, never turn OFF the regulator. This is because
+* the pbias cell programming support is still missing when
+* booting with Device tree
+*/
+   if (of_have_populated_dt() && !vdd)
+   return 0;
 
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -1516,7 +1523,13 @@ 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)) {
+   (ios->vdd == DUAL_VOLT_OCR_BIT) &&
+   /*
+* With pbias cell programming missing, this
+* can't be allowed when booting with device
+* tree.
+*/
+   (!of_have_populated_dt())) {
/*
 * The mmc_select_voltage fn of the core does
 * not seem to set the power_mode to
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-03-12 Thread Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.

Signed-off-by: Rajendra Nayak 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   33 +
 drivers/mmc/host/omap_hsmmc.c  |   73 
 2 files changed, 106 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..dbd4368
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,33 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2 controllers
+ Should be "ti,omap3-hsmmc", for OMAP3 controllers
+ Should be "ti,omap4-hsmmc", for OMAP4 controllers
+- ti,hwmods: Must be "mmc", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is 
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+ti,needs-special-reset: Requires a special softreset sequence
+
+Example:
+   mmc1: mmc@0x4809c000 {
+   compatible = "ti,omap4-hsmmc";
+   reg = <0x4809c000 0x400>;
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,bus-width = <4>;
+   vmmc-supply = <&vmmc>; /* phandle to regulator node */
+   ti,non-removable;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82583bf..38ae8c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1690,6 +1693,65 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
 
 #endif
 
+#ifdef CONFIG_OF
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+   {
+   .compatible = "ti,omap2-hsmmc",
+   },
+   {
+   .compatible = "ti,omap3-hsmmc",
+   },
+   {
+   .compatible = "ti,omap4-hsmmc",
+   .data = &omap4_reg_offset,
+   },
+   {},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+   struct omap_mmc_platform_data *pdata;
+   struct device_node *np = dev->of_node;
+   u32 bus_width;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL; /* out of memory */
+
+   if (of_find_property(np, "ti,dual-volt", NULL))
+   pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+   /* This driver only supports 1 slot */
+   pdata->nr_slots = 1;
+   pdata->slots[0].switch_pin = of_get_named_gpio(np, "cd-gpios", 0);
+   pdata->slots[0].gpio_wp = of_get_named_gpio(np, "wp-gpios", 0);
+
+   if (of_find_property(np, "ti,non-removable", NULL)) {
+   pdata->slots[0].nonremovable = true;
+   pdata->slots[0].no_regulator_off_init = true;
+   }
+   of_property_read_u32(np, "ti,bus-width", &bus_width);
+   if (bus_width == 4)
+   pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA;
+   else if (bus_width == 8)
+   pdata->slots[0].caps |= MMC_CAP_8_BIT_DATA;
+
+   if (of_find_property(np, "ti,needs-special-reset", NULL))
+   pdata->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+
+   return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+   *of_get_hsmmc_pdata(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
 static int __init omap_hsmmc_probe(struct platform_device *pdev)
 {
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1697,6 +1759,16 @@ static int __init omap_hsmmc_probe(struct 
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+   const struct of_device_id *match;
+
+   match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
+   if (mat

[PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-12 Thread Rajendra Nayak
Add omap mmc related device tree data for OMAP3.
Currenly limited to only omap3-beagle board.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap3-beagle.dts |   14 ++
 arch/arm/boot/dts/omap3.dtsi   |   16 
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 714ba5d..5cf67d1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -47,3 +47,17 @@
reg = <0x50>;
};
 };
+
+&mmc1 {
+   vmmc-supply = <&vmmc1>;
+   vmmc_aux-supply = <&vsim>;
+   ti,bus-width = <8>;
+};
+
+&mmc2 {
+   status = "disable";
+};
+
+&mmc3 {
+   status = "disable";
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ca37ba5..3892e34 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,21 @@
#size-cells = <0>;
ti,hwmods = "i2c3";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap3-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap3-hsmmc";
+   ti,hwmods = "mmc2";
+   };
+
+   mmc3: mmc@3 {
+   compatible = "ti,omap3-hsmmc";
+   ti,hwmods = "mmc3";
+   };
};
 };
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data

2012-03-12 Thread Rajendra Nayak
Add omap mmc related device tree data for OMAP4.
Currenly limited to only omap4-panda and omap4-sdp
boards.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap4-panda.dts |   22 ++
 arch/arm/boot/dts/omap4-sdp.dts   |   24 
 arch/arm/boot/dts/omap4.dtsi  |   31 +++
 3 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 29646dc..ea6f5bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,3 +52,25 @@
 &i2c4 {
clock-frequency = <40>;
 };
+
+&mmc1 {
+   vmmc-supply = <&vmmc>;
+   ti,bus-width = <8>;
+};
+
+&mmc2 {
+   status = "disable";
+};
+
+&mmc3 {
+   status = "disable";
+};
+
+&mmc4 {
+   status = "disable";
+};
+
+&mmc5 {
+   ti,non-removable;
+   ti,bus-width = <4>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 01db8b7..852657a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,3 +70,27 @@
reg = <0x1e>;
};
 };
+
+&mmc1 {
+   vmmc-supply = <&vmmc>;
+   ti,bus-width = <8>;
+};
+
+&mmc2 {
+   vmmc-supply = <&vaux1>;
+   ti,bus-width = <8>;
+   ti,non-removable;
+};
+
+&mmc3 {
+   status = "disable";
+};
+
+&mmc4 {
+   status = "disable";
+};
+
+&mmc5 {
+   ti,bus-width = <4>;
+   ti,non-removable;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9226543 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -155,5 +155,36 @@
#size-cells = <0>;
ti,hwmods = "i2c4";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,needs-special-reset;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc2";
+   ti,needs-special-reset;
+   };
+
+   mmc3: mmc@3 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc3";
+   ti,needs-special-reset;
+   };
+
+   mmc4: mmc@4 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc4";
+   ti,needs-special-reset;
+   };
+
+   mmc5: mmc@5 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc5";
+   ti,needs-special-reset;
+   };
};
 };
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 0/4] omap hsmmc device tree support

2012-03-12 Thread Rajendra Nayak
The series adds device tree support for OMAP hsmmc
driver.

Changes in V2:
-1- Minor fixes based on comments from Grant.
-2- Added a seperate compatible for omap3.
-3- Added a new binding "ti,needs-special-reset"
to handle some mmc modules which need special
softreset sequence.
-4- Updated board dts files with "status = disable;"
for unused mmc modules.

Rob,
I retained your ack on patch 1 despite the additional
binding that I added to handle the special softreset
sequence. Let me know if you have any issues with it.

Chris.
Patch 1 and Patch 2 apply cleanly on mmc-next and can
be taken in from the mmc tree after relevent acks from
DT folks.
Patch 3 and Patch 4 which update dts files, I plan to
push via linux-omap/Tony's tree.

The series is tested on omap4sdp (both external and emmc),
omap4panda amd omap3beagle boards.

Things to do:
-1- Card detect isn't functional and needs twl4030 gpio
to be DT converted.
-2- pbias cell programming is missing and needs an OMAP
control module driver.

Rajendra Nayak (4):
  mmc: omap_hsmmc: Convert hsmmc driver to use device tree
  mmc: omap_hsmmc: Avoid a regulator voltage change with dt
  arm/dts: OMAP4: Add mmc controller nodes and board data
  arm/dts: OMAP3: Add mmc controller nodes and board data

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   33 +++
 arch/arm/boot/dts/omap3-beagle.dts |   14 +++
 arch/arm/boot/dts/omap3.dtsi   |   16 
 arch/arm/boot/dts/omap4-panda.dts  |   22 +
 arch/arm/boot/dts/omap4-sdp.dts|   24 ++
 arch/arm/boot/dts/omap4.dtsi   |   31 +++
 drivers/mmc/host/omap_hsmmc.c  |   88 +++-
 7 files changed, 227 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-09 Thread Rajendra Nayak

Hi Paul,

On Friday 09 March 2012 12:21 PM, Paul Walmsley wrote:

On Thu, 8 Mar 2012, Grant Likely wrote:


Yes, absolutely use separate compatible values.  It is always important
to be specific as to the silicon implementing the IP.


In that case, it is probably best to use the full chip name in the
compatible string, e.g., omap2420 or omap2430 rather than just "omap2".


Since omap2420 and omap2430 have different MMC controllers (and these
bindings only cover the hsmmc controller used in 2430 and beyond, I
haven't done the bindings for the legacy one yet), the idea was
to differentiate between omap2420 and omap2430 by using
compatible of "ti,omap2-hsmmc" for the High-Speed controller used in
OMAP2 (2430) and "ti,omap2-mmc" for the legacy one used in OMAP2 (2420).
Does that sound good to you?


Particularly in the case of "OMAP3," which is a largely meaningless group
these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are
quite different from each other...


But these bindings are specific and limited to HSMMC module which is
not quite different in the different SoC variants. There is a single
driver to handle hsmmc module on all the SoCs which does not need to
differentiate which SoC it is on.

regards,
Rajendra




- Paul


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-09 Thread Rajendra Nayak

On Friday 09 March 2012 11:16 AM, Grant Likely wrote:

On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgren  wrote:

* Rajendra Nayak  [120223 19:29]:

On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:

--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =<0>;
ti,hwmods = "i2c3";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc2";
+   };
+
+   mmc3: mmc@3 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc3";
+   };
+
+   mmc4: mmc@4 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc4";
+   };
+
+   mmc5: mmc@5 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc5";
+   };
};
  };


These all should all be "ti,omap3-hsmmc" I guess?


Well, I defined the binding such that both omap2 and omap3
can use the same compatible "ti,omap2-hsmmc" since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.


Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..


Yes, absolutely use separate compatible values.  It is always important
to be specific as to the silicon implementing the IP.  The omap3 instance
can also carry the omap2 string in its compatible list:

compatible = "ti,omap3-hsmmc", "ti,omap2-hsmmc";


Sure, will repost with seperate compatible strings. Also missed adding
the 'status = "disable";' for unused mmc blocks in the board .dts file
causing unused mmc modules to get probed too. Will fix that as well.

thanks,
Rajendra



g.


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-03-09 Thread Rajendra Nayak

Hi Grant,

On Friday 09 March 2012 11:12 AM, Grant Likely wrote:

On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayak  wrote:

Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.

Signed-off-by: Rajendra Nayak
---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   31 +
  drivers/mmc/host/omap_hsmmc.c  |   68 
  2 files changed, 99 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2/3 controllers
+ Should be "ti,omap4-hsmmc", for OMAP4 controllers
+- ti,hwmods: Must be "mmc", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is 
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)


Binding looks okay.  A couple comments below...

[...]

+static const struct of_device_id omap_mmc_of_match[];


If you move the omap_mmc_of_match[] table up to here then there is no
need for the forward declaration.


+
  static int __init omap_hsmmc_probe(struct platform_device *pdev)
  {
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct 
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+   const struct of_device_id *match;
+
+   match = of_match_device(omap_mmc_of_match,&pdev->dev);
+   if (match) {
+   pdata = of_get_hsmmc_pdata(&pdev->dev);
+   if (match->data)
+   pdata->reg_offset = *(u16 *)match->data;


Blech on the ugly cast.  It is slightly safer to do thusly:

u16 *offsetp = match->data;
pdata->reg_offset = *offsetp


thanks for the review. I'll repost with these changes.

regards,
Rajendra




+   }

if (pdata == NULL) {
dev_err(&pdev->dev, "Platform Data is missing\n");
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
  };

+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+   {
+   .compatible = "ti,omap2-hsmmc",
+   },
+   {
+   .compatible = "ti,omap4-hsmmc",
+   .data =&omap4_reg_offset,
+   },
+   {},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+#endif
+
  static struct platform_driver omap_hsmmc_driver = {
.remove = omap_hsmmc_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
.pm =&omap_hsmmc_dev_pm_ops,
+   .of_match_table = of_match_ptr(omap_mmc_of_match),
},
  };

--
1.7.1


___
linaro-dev mailing list
linaro-...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev




___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-03-07 Thread Rajendra Nayak

Hi Rob/Grant,

On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote:

Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.


Any comments on these bindings for omap hsmmc? All the dependent
patches/series on which this series was based have now made it to
the respective -next of Mark and Chris.

regards,
Rajendra



Signed-off-by: Rajendra Nayak
---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   31 +
  drivers/mmc/host/omap_hsmmc.c  |   68 
  2 files changed, 99 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2/3 controllers
+ Should be "ti,omap4-hsmmc", for OMAP4 controllers
+- ti,hwmods: Must be "mmc", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is 
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+   mmc1: mmc@0x4809c000 {
+   compatible = "ti,omap4-hsmmc";
+   reg =<0x4809c000 0x400>;
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,bus-width =<4>;
+   vmmc-supply =<&vmmc>; /* phandle to regulator node */
+   ti,non-removable;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 35f6dc1..0c93d58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
  #include
  #include
  #include
+#include
+#include
+#include
  #include
  #include
  #include
@@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)

  #endif

+#ifdef CONFIG_OF
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+   struct omap_mmc_platform_data *pdata;
+   struct device_node *np = dev->of_node;
+   u32 bus_width;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL; /* out of memory */
+
+   if (of_find_property(np, "ti,dual-volt", NULL))
+   pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+   /* This driver only supports 1 slot */
+   pdata->nr_slots = 1;
+   pdata->slots[0].switch_pin = of_get_named_gpio(np, "cd-gpios", 0);
+   pdata->slots[0].gpio_wp = of_get_named_gpio(np, "wp-gpios", 0);
+
+   if (of_find_property(np, "ti,non-removable", NULL)) {
+   pdata->slots[0].nonremovable = true;
+   pdata->slots[0].no_regulator_off_init = true;
+   }
+   of_property_read_u32(np, "ti,bus-width",&bus_width);
+   if (bus_width == 4)
+   pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA;
+   else if (bus_width == 8)
+   pdata->slots[0].caps |= MMC_CAP_8_BIT_DATA;
+   return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+   *of_get_hsmmc_pdata(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
  static int __init omap_hsmmc_probe(struct platform_device *pdev)
  {
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct 
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+   const struct of_device_id *match;
+
+   match = of_match_device(omap_mmc_of_match,&pdev->dev);
+   if (match) {
+   pdata = of_get_hsmmc_pdata(&pdev->dev);
+   if (match->data)
+   pdata->reg_offset = *(u16 *)match->data;
+   }

if (pdata == NULL) {
dev_err(&pdev->dev, "Platform Data is missing\n");
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.r

Re: [PATCH 0/4] twl-regulator DT adaptation and updates to add new regulators

2012-02-29 Thread Rajendra Nayak

On Thursday 01 March 2012 04:48 AM, Mark Brown wrote:

On Tue, Feb 28, 2012 at 03:09:09PM +0530, Rajendra Nayak wrote:

Hi Mark,

Here is a consolidated series which adds DT support for twl regulator
driver and adds support for VDD1/2/3 regulator and support for
fixed LDO V1V8 and V2V1. The patches are based on -next and tested
on omap3 beagle and omap4 panda boards.


Applied all, thanks.  Please do try to use subject lines consistent with
the subsystem.


Thanks Mark, will remember to keep the subject lines consistent
hence forth.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH 4/4] MFD: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS

2012-02-28 Thread Rajendra Nayak
From: Peter Ujfalusi 

To be able to attach consumers to these supplies from board
files we need to have regulator_init_data for them.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Rajendra Nayak 
Cc: Samuel Ortiz 
Cc: Misael Lopez Cruz 
Cc: Santosh Shilimkar 
---
 drivers/mfd/twl-core.c  |   10 ++
 include/linux/i2c/twl.h |2 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index e1d3a64..6cb1061 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -966,6 +966,16 @@ add_children(struct twl4030_platform_data *pdata, unsigned 
long features)
if (IS_ERR(child))
return PTR_ERR(child);
 
+   child = add_regulator(TWL6030_REG_V1V8, pdata->v1v8,
+   features);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
+
+   child = add_regulator(TWL6030_REG_V2V1, pdata->v2v1,
+   features);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
+
child = add_regulator(TWL6030_REG_VMMC, pdata->vmmc,
features);
if (IS_ERR(child))
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index f66c031..7fcab23 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -734,6 +734,8 @@ struct twl4030_platform_data {
struct regulator_init_data  *vcxio;
struct regulator_init_data  *vusb;
struct regulator_init_data  *clk32kg;
+   struct regulator_init_data  *v1v8;
+   struct regulator_init_data  *v2v1;
/* TWL6025 LDO regulators */
struct regulator_init_data  *ldo1;
struct regulator_init_data  *ldo2;
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH 3/4] regulator: twl-regulator: Add fixed LDO for V1V8, V2V1 supply

2012-02-28 Thread Rajendra Nayak
From: Peter Ujfalusi 

V1V8 supply most common use is to provide VIO for the system.
V2V1 supply is used on SDP4430/PandaBoards to provide 2.1V to
twl6040, and also as an input to VCXIO_IN, VDAC_IN of twl6030.

Also update the bindings documentation with the new compatible
property for these additional LDOs.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Rajendra Nayak 
Cc: Samuel Ortiz 
Cc: Misael Lopez Cruz 
Cc: Santosh Shilimkar 
---
 .../bindings/regulator/twl-regulator.txt   |2 ++
 drivers/regulator/twl-regulator.c  |4 
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt 
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
index ba9d2cc..0c3395d 100644
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -13,6 +13,8 @@ For twl6030 regulators/LDOs
   - "ti,twl6030-vcxio" for VCXIO LDO
   - "ti,twl6030-vdac" for VDAC LDO
   - "ti,twl6030-vusb" for VUSB LDO
+  - "ti,twl6030-v1v8" for V1V8 LDO
+  - "ti,twl6030-v2v1" for V2V1 LDO
   - "ti,twl6030-clk32kg" for CLK32KG RESOURCE
   - "ti,twl6030-vdd1" for VDD1 SMPS
   - "ti,twl6030-vdd2" for VDD2 SMPS
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 2a13211..9cdfc38 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1094,6 +1094,8 @@ TWL6030_FIXED_LDO(VANA, 0x50, 2100, 0);
 TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 0);
 TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 0);
 TWL6030_FIXED_LDO(VUSB, 0x70, 3300, 0);
+TWL6030_FIXED_LDO(V1V8, 0x16, 1800, 0);
+TWL6030_FIXED_LDO(V2V1, 0x1c, 2100, 0);
 TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0);
 TWL6025_ADJUSTABLE_SMPS(SMPS3, 0x34);
 TWL6025_ADJUSTABLE_SMPS(SMPS4, 0x10);
@@ -1173,6 +1175,8 @@ static const struct of_device_id twl_of_match[] 
__devinitconst = {
TWLFIXED_OF_MATCH("ti,twl6030-vcxio", VCXIO),
TWLFIXED_OF_MATCH("ti,twl6030-vdac", VDAC),
TWLFIXED_OF_MATCH("ti,twl6030-vusb", VUSB),
+   TWLFIXED_OF_MATCH("ti,twl6030-v1v8", V1V8),
+   TWLFIXED_OF_MATCH("ti,twl6030-v2v1", V2V1),
TWLRES_OF_MATCH("ti,twl6030-clk32kg", CLK32KG),
TWLSMPS_OF_MATCH("ti,twl6025-smps3", SMPS3),
TWLSMPS_OF_MATCH("ti,twl6025-smps4", SMPS4),
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH 2/4] regulator: twl: adapt twl-regulator driver to dt

2012-02-28 Thread Rajendra Nayak
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)

Also add documentation for TWL regulator specific bindings.

Signed-off-by: Rajendra Nayak 
---
 .../bindings/regulator/twl-regulator.txt   |   66 +
 drivers/regulator/twl-regulator.c  |  259 +---
 2 files changed, 238 insertions(+), 87 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt 
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..ba9d2cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,66 @@
+TWL family of regulators
+
+Required properties:
+For twl6030 regulators/LDOs
+- compatible:
+  - "ti,twl6030-vaux1" for VAUX1 LDO
+  - "ti,twl6030-vaux2" for VAUX2 LDO
+  - "ti,twl6030-vaux3" for VAUX3 LDO
+  - "ti,twl6030-vmmc" for VMMC LDO
+  - "ti,twl6030-vpp" for VPP LDO
+  - "ti,twl6030-vusim" for VUSIM LDO
+  - "ti,twl6030-vana" for VANA LDO
+  - "ti,twl6030-vcxio" for VCXIO LDO
+  - "ti,twl6030-vdac" for VDAC LDO
+  - "ti,twl6030-vusb" for VUSB LDO
+  - "ti,twl6030-clk32kg" for CLK32KG RESOURCE
+  - "ti,twl6030-vdd1" for VDD1 SMPS
+  - "ti,twl6030-vdd2" for VDD2 SMPS
+  - "ti,twl6030-vdd3" for VDD3 SMPS
+For twl6025 regulators/LDOs
+- compatible:
+  - "ti,twl6025-ldo1" for LDO1 LDO
+  - "ti,twl6025-ldo2" for LDO2 LDO
+  - "ti,twl6025-ldo3" for LDO3 LDO
+  - "ti,twl6025-ldo4" for LDO4 LDO
+  - "ti,twl6025-ldo5" for LDO5 LDO
+  - "ti,twl6025-ldo6" for LDO6 LDO
+  - "ti,twl6025-ldo7" for LDO7 LDO
+  - "ti,twl6025-ldoln" for LDOLN LDO
+  - "ti,twl6025-ldousb" for LDOUSB LDO
+  - "ti,twl6025-smps3" for SMPS3 SMPS
+  - "ti,twl6025-smps4" for SMPS4 SMPS
+  - "ti,twl6025-vio" for VIO SMPS
+For twl4030 regulators/LDOs
+- compatible:
+  - "ti,twl4030-vaux1" for VAUX1 LDO
+  - "ti,twl4030-vaux2" for VAUX2 LDO
+  - "ti,twl5030-vaux2" for VAUX2 LDO
+  - "ti,twl4030-vaux3" for VAUX3 LDO
+  - "ti,twl4030-vaux4" for VAUX4 LDO
+  - "ti,twl4030-vmmc1" for VMMC1 LDO
+  - "ti,twl4030-vmmc2" for VMMC2 LDO
+  - "ti,twl4030-vpll1" for VPLL1 LDO
+  - "ti,twl4030-vpll2" for VPLL2 LDO
+  - "ti,twl4030-vsim" for VSIM LDO
+  - "ti,twl4030-vdac" for VDAC LDO
+  - "ti,twl4030-vintana2" for VINTANA2 LDO
+  - "ti,twl4030-vio" for VIO LDO
+  - "ti,twl4030-vdd1" for VDD1 SMPS
+  - "ti,twl4030-vdd2" for VDD2 SMPS
+  - "ti,twl4030-vintana1" for VINTANA1 LDO
+  - "ti,twl4030-vintdig" for VINTDIG LDO
+  - "ti,twl4030-vusb1v5" for VUSB1V5 LDO
+  - "ti,twl4030-vusb1v8" for VUSB1V8 LDO
+  - "ti,twl4030-vusb3v1" for VUSB3V1 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+   xyz: regulator@0 {
+   compatible = "ti,twl6030-vaux1";
+   regulator-min-microvolt  = <100>;
+   regulator-max-microvolt  = <300>;
+   };
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 8611282..2a13211 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -920,7 +923,8 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
 
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { 
\
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
@@ -938,7 +942,7 @@ static struct regulator_ops twlsmps_ops = {
}
 
 #define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf) \
-   { \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.delay = turnon_delay, \
@@ -952,7 +956,8 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL6030_ADJUSTABLE_SMPS(label) { \
+#define TWL6030_ADJUSTABLE_SMPS(label) \
+static struct twlreg_info TWL6030_INFO_##label = { \
.desc = { \
.name = #label, \
   

[PATCH 1/4] regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators

2012-02-28 Thread Rajendra Nayak
From: Tero Kristo 

vdd1 and vdd2 are now common regulators for twl4030 and twl6030. Also
added vdd3 as a new regulator for twl6030. twl6030 vdd1...vdd3 smps
regulator voltages can only be controlled through the smartreflex
voltage channel, thus the support for the voltage_get and set is
minimal and requires external controller.

Signed-off-by: Tero Kristo 
Signed-off-by: Rajendra Nayak 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Samuel Ortiz 
Cc: Kevin Hilman 
---
 drivers/mfd/twl-core.c|   15 ++
 drivers/regulator/twl-regulator.c |   39 +
 include/linux/i2c/twl.h   |5 ++-
 3 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 6c13d9f..e1d3a64 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -951,6 +951,21 @@ add_children(struct twl4030_platform_data *pdata, unsigned 
long features)
/* twl6030 regulators */
if (twl_has_regulator() && twl_class_is_6030() &&
!(features & TWL6025_SUBCLASS)) {
+   child = add_regulator(TWL6030_REG_VDD1, pdata->vdd1,
+   features);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
+
+   child = add_regulator(TWL6030_REG_VDD2, pdata->vdd2,
+   features);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
+
+   child = add_regulator(TWL6030_REG_VDD3, pdata->vdd3,
+   features);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
+
child = add_regulator(TWL6030_REG_VMMC, pdata->vmmc,
features);
if (IS_ERR(child))
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 7ff8bb2..8611282 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -561,6 +561,32 @@ static struct regulator_ops twl4030smps_ops = {
.get_voltage= twl4030smps_get_voltage,
 };
 
+static int twl6030coresmps_set_voltage(struct regulator_dev *rdev, int min_uV,
+   int max_uV, unsigned *selector)
+{
+   struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+   if (info->set_voltage)
+   return info->set_voltage(info->data, min_uV);
+
+   return -ENODEV;
+}
+
+static int twl6030coresmps_get_voltage(struct regulator_dev *rdev)
+{
+   struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+   if (info->get_voltage)
+   return info->get_voltage(info->data);
+
+   return -ENODEV;
+}
+
+static struct regulator_ops twl6030coresmps_ops = {
+   .set_voltage= twl6030coresmps_set_voltage,
+   .get_voltage= twl6030coresmps_get_voltage,
+};
+
 static int twl6030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
 {
struct twlreg_info  *info = rdev_get_drvdata(rdev);
@@ -926,6 +952,16 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
+#define TWL6030_ADJUSTABLE_SMPS(label) { \
+   .desc = { \
+   .name = #label, \
+   .id = TWL6030_REG_##label, \
+   .ops = &twl6030coresmps_ops, \
+   .type = REGULATOR_VOLTAGE, \
+   .owner = THIS_MODULE, \
+   }, \
+   }
+
 #define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
.base = offset, \
.min_mV = min_mVolts, \
@@ -1027,6 +1063,9 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
   verified since the specification is not public */
+   TWL6030_ADJUSTABLE_SMPS(VDD1),
+   TWL6030_ADJUSTABLE_SMPS(VDD2),
+   TWL6030_ADJUSTABLE_SMPS(VDD3),
TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300),
TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300),
TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300),
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 08a82d3..f66c031 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -712,6 +712,9 @@ struct twl4030_platform_data {
struct regulator_init_data  *vaux1;
struct regulator_init_data  *vaux2;
struct regulator_init_data  *vaux3;
+   struct regulator_init_data  *vdd1;
+   struct regulator_init_data  *vdd2;
+   struct regulator_init_data  *vdd3;
/* TWL4030 LDO regulators */
struct regulator_init_data  *vpll1;
struct regulator_init_data  *vpll2;
@@ -720,8 +723,6 @@ struct twl4030_platform_data {
struct regulator_init_data  *vsim;

[PATCH 0/4] twl-regulator DT adaptation and updates to add new regulators

2012-02-28 Thread Rajendra Nayak
Hi Mark,

Here is a consolidated series which adds DT support for twl regulator
driver and adds support for VDD1/2/3 regulator and support for
fixed LDO V1V8 and V2V1. The patches are based on -next and tested
on omap3 beagle and omap4 panda boards.

I have dropped the patch updating the dts entries for twl4030 and
twl6030 because of other dependencies and will submit them via
the OMAP tree. The driver DT changes however do not have any dependency
on the dts file updates (except that regulator support will not work with DT,
but will not break DT build or boot) and no functionality would change
in the non-DT case.

regards,
Rajendra

Peter Ujfalusi (2):
  regulator: twl-regulator: Add fixed LDO for V1V8, V2V1 supply
  MFD: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS

Rajendra Nayak (1):
  regulator: twl: adapt twl-regulator driver to dt

Tero Kristo (1):
  regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators

 .../bindings/regulator/twl-regulator.txt   |   68 +
 drivers/mfd/twl-core.c |   25 ++
 drivers/regulator/twl-regulator.c  |  294 ++--
 include/linux/i2c/twl.h|7 +-
 4 files changed, 309 insertions(+), 85 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v3 0/2] Device tree support for TWL regulators

2012-02-27 Thread Rajendra Nayak

On Monday 27 February 2012 08:23 PM, Mark Brown wrote:

If adding device tree support breaks existing platforms something is
going wrong, while you're pulling things together device tree might not
work until all the support makes it in but the old non-DT code should
continue to function.


Adding device tree support will not break existing platforms. The
non-DT code will function as expected. The dependencies I mentioned
were only with the dtsi/dts files that patch 2 was updating. The driver
changes have no dependencies with any other DT series. I will repost
all of Tero/Peter and my changes (to add DT support to the driver) as
one single series and drop the dts file updates, which I guess can go
via Tony/OMAP tree.





___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v3 0/2] Device tree support for TWL regulators

2012-02-27 Thread Rajendra Nayak

On Monday 27 February 2012 05:45 PM, Peter Ujfalusi wrote:

Hi Rajendra,


On 02/27/2012 12:35 PM, Rajendra Nayak wrote:

Re-sending on top of Tero's changes which are already
in -next and the one which adds support for twl6030
vdd1/2/3 SMPS [1].


Would you be able to add support for V1V8, V2V1 SMPS supplies in
twl6030? These regulators are need on SDP4430, and PandaBoards for the
twl6040 audio codec.
I have sent a series to add this support:
http://marc.info/?l=linux-omap&m=132886849202915&w=2


Sure, seems quite straight forward to add DT support for those
too. I just based my patches on top of whats already in -next and
some changes from Tero. Did not notice there are more patches floating
around touching twl-regulator :)
Depending on what order Mark happens to pull them in, I am fine
re-sending adding support for the 2 twl6030 fixed regulators.



Thanks,
Péter



v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 and twl6030 are
now defined in the twl4030.dtsi and twl6030.dtsi instead of
repeating the nodes in all board files, which also means
the patch ('arm/dts: twl: Pass regulator data from dt')
has a dependency with the series from Benoit which adds the
twl4030.dtsi and twl6030.dtsi files[2].

I have tested the patches on omap4panda and omap3beagle boards.

[1] http://marc.info/?l=linux-omap&m=133009693905864&w=2
[2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
    for_3.4/dt_i2c_twl

Rajendra Nayak (2):
   regulator: twl: adapt twl-regulator driver to dt
   arm/dts: twl: Pass regulator data from dt

  .../bindings/regulator/twl-regulator.txt   |   66 +
  arch/arm/boot/dts/omap3-beagle.dts |6 +
  arch/arm/boot/dts/twl4030.dtsi |   18 ++
  arch/arm/boot/dts/twl6030.dtsi |   60 +
  drivers/regulator/twl-regulator.c  |  259 +---
  5 files changed, 322 insertions(+), 87 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

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


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 0/2] Device tree support for TWL regulators

2012-02-27 Thread Rajendra Nayak
Re-sending on top of Tero's changes which are already
in -next and the one which adds support for twl6030 
vdd1/2/3 SMPS [1].

v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 and twl6030 are
now defined in the twl4030.dtsi and twl6030.dtsi instead of
repeating the nodes in all board files, which also means
the patch ('arm/dts: twl: Pass regulator data from dt')
has a dependency with the series from Benoit which adds the
twl4030.dtsi and twl6030.dtsi files[2].

I have tested the patches on omap4panda and omap3beagle boards.

[1] http://marc.info/?l=linux-omap&m=133009693905864&w=2
[2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
    for_3.4/dt_i2c_twl

Rajendra Nayak (2):
  regulator: twl: adapt twl-regulator driver to dt
  arm/dts: twl: Pass regulator data from dt

 .../bindings/regulator/twl-regulator.txt   |   66 +
 arch/arm/boot/dts/omap3-beagle.dts |6 +
 arch/arm/boot/dts/twl4030.dtsi |   18 ++
 arch/arm/boot/dts/twl6030.dtsi |   60 +
 drivers/regulator/twl-regulator.c  |  259 +---
 5 files changed, 322 insertions(+), 87 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 2/2] arm/dts: twl: Pass regulator data from dt

2012-02-27 Thread Rajendra Nayak
Pass all the voltage regulator information for
twl6030/twl4030 PMIC from device tree.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Benoit Cousson 
---
 arch/arm/boot/dts/omap3-beagle.dts |6 +++
 arch/arm/boot/dts/twl4030.dtsi |   18 +++
 arch/arm/boot/dts/twl6030.dtsi |   60 
 3 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 714ba5d..54556b1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -26,6 +26,12 @@
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
+
+   vsim: regulator@10 {
+   compatible = "ti,twl4030-vsim";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 8be5223..a94654c 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -18,4 +18,22 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+   vdac: regulator@0 {
+   compatible = "ti,twl4030-vdac";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vpll2: regulator@1 {
+   compatible = "ti,twl4030-vpll2";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vmmc1: regulator@2 {
+   compatible = "ti,twl4030-vmmc1";
+   regulator-min-microvolt = <185>;
+   regulator-max-microvolt = <315>;
+   };
 };
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index b7b4e5e..efa19e8 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -19,4 +19,64 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+   vaux1: regulator@0 {
+   compatible = "ti,twl6030-vaux1";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vaux2: regulator@1 {
+   compatible = "ti,twl6030-vaux2";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <280>;
+   };
+
+   vaux3: regulator@2 {
+   compatible = "ti,twl6030-vaux3";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vmmc: regulator@3 {
+   compatible = "ti,twl6030-vmmc";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vpp: regulator@4 {
+   compatible = "ti,twl6030-vpp";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <250>;
+   };
+
+   vusim: regulator@5 {
+   compatible = "ti,twl6030-vusim";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <290>;
+   };
+
+   vdac: regulator@6 {
+   compatible = "ti,twl6030-vdac";
+   };
+
+   vana: regulator@7 {
+   compatible = "ti,twl6030-vana";
+   };
+
+   vcxio: regulator@8 {
+   compatible = "ti,twl6030-vcxio";
+   };
+
+   vusb: regulator@9 {
+   compatible = "ti,twl6030-vusb";
+   };
+
+   vusb: regulator@9 {
+   compatible = "ti,twl6030-vusb";
+   };
+
+   clk32kg: regulator@10 {
+   compatible = "ti,twl6030-clk32kg";
+   };
 };
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 1/2] regulator: twl: adapt twl-regulator driver to dt

2012-02-27 Thread Rajendra Nayak
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)

Also add documentation for TWL regulator specific bindings.

Signed-off-by: Rajendra Nayak 
---
 .../bindings/regulator/twl-regulator.txt   |   66 +
 drivers/regulator/twl-regulator.c  |  259 +---
 2 files changed, 238 insertions(+), 87 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt 
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..ba9d2cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,66 @@
+TWL family of regulators
+
+Required properties:
+For twl6030 regulators/LDOs
+- compatible:
+  - "ti,twl6030-vaux1" for VAUX1 LDO
+  - "ti,twl6030-vaux2" for VAUX2 LDO
+  - "ti,twl6030-vaux3" for VAUX3 LDO
+  - "ti,twl6030-vmmc" for VMMC LDO
+  - "ti,twl6030-vpp" for VPP LDO
+  - "ti,twl6030-vusim" for VUSIM LDO
+  - "ti,twl6030-vana" for VANA LDO
+  - "ti,twl6030-vcxio" for VCXIO LDO
+  - "ti,twl6030-vdac" for VDAC LDO
+  - "ti,twl6030-vusb" for VUSB LDO
+  - "ti,twl6030-clk32kg" for CLK32KG RESOURCE
+  - "ti,twl6030-vdd1" for VDD1 SMPS
+  - "ti,twl6030-vdd2" for VDD2 SMPS
+  - "ti,twl6030-vdd3" for VDD3 SMPS
+For twl6025 regulators/LDOs
+- compatible:
+  - "ti,twl6025-ldo1" for LDO1 LDO
+  - "ti,twl6025-ldo2" for LDO2 LDO
+  - "ti,twl6025-ldo3" for LDO3 LDO
+  - "ti,twl6025-ldo4" for LDO4 LDO
+  - "ti,twl6025-ldo5" for LDO5 LDO
+  - "ti,twl6025-ldo6" for LDO6 LDO
+  - "ti,twl6025-ldo7" for LDO7 LDO
+  - "ti,twl6025-ldoln" for LDOLN LDO
+  - "ti,twl6025-ldousb" for LDOUSB LDO
+  - "ti,twl6025-smps3" for SMPS3 SMPS
+  - "ti,twl6025-smps4" for SMPS4 SMPS
+  - "ti,twl6025-vio" for VIO SMPS
+For twl4030 regulators/LDOs
+- compatible:
+  - "ti,twl4030-vaux1" for VAUX1 LDO
+  - "ti,twl4030-vaux2" for VAUX2 LDO
+  - "ti,twl5030-vaux2" for VAUX2 LDO
+  - "ti,twl4030-vaux3" for VAUX3 LDO
+  - "ti,twl4030-vaux4" for VAUX4 LDO
+  - "ti,twl4030-vmmc1" for VMMC1 LDO
+  - "ti,twl4030-vmmc2" for VMMC2 LDO
+  - "ti,twl4030-vpll1" for VPLL1 LDO
+  - "ti,twl4030-vpll2" for VPLL2 LDO
+  - "ti,twl4030-vsim" for VSIM LDO
+  - "ti,twl4030-vdac" for VDAC LDO
+  - "ti,twl4030-vintana2" for VINTANA2 LDO
+  - "ti,twl4030-vio" for VIO LDO
+  - "ti,twl4030-vdd1" for VDD1 SMPS
+  - "ti,twl4030-vdd2" for VDD2 SMPS
+  - "ti,twl4030-vintana1" for VINTANA1 LDO
+  - "ti,twl4030-vintdig" for VINTDIG LDO
+  - "ti,twl4030-vusb1v5" for VUSB1V5 LDO
+  - "ti,twl4030-vusb1v8" for VUSB1V8 LDO
+  - "ti,twl4030-vusb3v1" for VUSB3V1 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+   xyz: regulator@0 {
+   compatible = "ti,twl6030-vaux1";
+   regulator-min-microvolt  = <100>;
+   regulator-max-microvolt  = <300>;
+   };
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 8611282..2a13211 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -920,7 +923,8 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
 
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { 
\
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
@@ -938,7 +942,7 @@ static struct regulator_ops twlsmps_ops = {
}
 
 #define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf) \
-   { \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.delay = turnon_delay, \
@@ -952,7 +956,8 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL6030_ADJUSTABLE_SMPS(label) { \
+#define TWL6030_ADJUSTABLE_SMPS(label) \
+static struct twlreg_info TWL6030_INFO_##label = { \
.desc = { \
.name = #label, \
   

Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-02-24 Thread Rajendra Nayak

On Friday 24 February 2012 06:32 PM, Cousson, Benoit wrote:

On 2/24/2012 1:58 PM, Rajendra Nayak wrote:

On Friday 24 February 2012 06:21 PM, Cousson, Benoit wrote:

On 2/24/2012 12:35 PM, Rajendra Nayak wrote:

On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:

On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak wrote:

...

+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2/3 controllers


omap_hsmmc is applicable for omap2430 and omap3.
omap2420 has non high speed controller mmci-omap -
drivers/mmc/host/omap.c
May be omap3-hsmmc compatible with omap2430 ?


Agree. I think its best in that case for me to define a
compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
for omap3. Though the IP blocks are same, I cant think of some
common compatible string without causing confusion.


It depends, can we detect that using HW revision?


We don't need to. The driver does not do anything different for
2430 or omap3.


I was thinking of OMAP2420 vs OMAP2430. But I'm now wondering if we are
using the same driver for the non-HS controller?


No, we don't. there is a different driver for 2420.




In that case, there is no need to differentiate again with compatible.


Thats perfectly fine. But what *common* compatible string would you
use?


I think that "ti,omap2-hsmmc" is still fine, because OMAP2420 will have
"ti,omap2-mmc" and thus we can differentiate the 2 versions.

Does that make sense?


yup, that makes sense. So I don't need to change anything :-)



Regards,
Benoit


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-02-24 Thread Rajendra Nayak

On Friday 24 February 2012 06:21 PM, Cousson, Benoit wrote:

On 2/24/2012 12:35 PM, Rajendra Nayak wrote:

On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:

On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak wrote:

Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.

Signed-off-by: Rajendra Nayak
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68 
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2/3 controllers


omap_hsmmc is applicable for omap2430 and omap3.
omap2420 has non high speed controller mmci-omap -
drivers/mmc/host/omap.c
May be omap3-hsmmc compatible with omap2430 ?


Agree. I think its best in that case for me to define a
compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
for omap3. Though the IP blocks are same, I cant think of some
common compatible string without causing confusion.


It depends, can we detect that using HW revision?


We don't need to. The driver does not do anything different for
2430 or omap3.


In that case, there is no need to differentiate again with compatible.


Thats perfectly fine. But what *common* compatible string would you
use?



Regards,
Benoit






+ Should be "ti,omap4-hsmmc", for OMAP4 controllers
+- ti,hwmods: Must be "mmc", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the
property is missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg =<0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ ti,bus-width =<4>;
+ vmmc-supply =<&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss




___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-02-24 Thread Rajendra Nayak

On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:

On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak  wrote:

Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.

Signed-off-by: Rajendra Nayak
---
  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   31 +
  drivers/mmc/host/omap_hsmmc.c  |   68 
  2 files changed, 99 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2/3 controllers


omap_hsmmc is applicable for omap2430 and omap3.
omap2420 has non high speed controller mmci-omap - drivers/mmc/host/omap.c
May be omap3-hsmmc compatible with omap2430 ?


Agree. I think its best in that case for me to define a
compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
for omap3. Though the IP blocks are same, I cant think of some
common compatible string without causing confusion.




+ Should be "ti,omap4-hsmmc", for OMAP4 controllers
+- ti,hwmods: Must be "mmc", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is 
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+   mmc1: mmc@0x4809c000 {
+   compatible = "ti,omap4-hsmmc";
+   reg =<0x4809c000 0x400>;
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,bus-width =<4>;
+   vmmc-supply =<&vmmc>; /* phandle to regulator node */
+   ti,non-removable;
+   };


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data

2012-02-24 Thread Rajendra Nayak

On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
serial1 =&uart2;
serial2 =&uart3;
serial3 =&uart4;
+   mmc1 =&mmc1;
+   mmc2 =&mmc2;
+   mmc3 =&mmc3;
+   mmc4 =&mmc4;
+   mmc5 =&mmc5;
};

cpus {
@@ -155,5 +160,31 @@
#size-cells =<0>;
ti,hwmods = "i2c4";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc2";
+   };


Hi Rajendra,
Is there a way to control the device registration order,
eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
irrespective of whether SD card is mount or not on mmc1 card slot.
So that bootargs would not have to be modified when filesystem is on eMMC.


I don't know if we can, but even if we could, we take care of the same
bootargs working on two boards (say sdp and panda) *if* on sdp I have my
filesystem on eMMC and on panda I have it on external card.
What happens if I want to use my filesystem on both boards on external
card?




+
+   mmc3: mmc@3 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc3";
+   };
+
+   mmc4: mmc@4 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc4";
+   };
+
+   mmc5: mmc@5 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc5";
+   };
};
  };
--
1.7.1



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-02-23 Thread Rajendra Nayak

On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:

--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =<0>;
ti,hwmods = "i2c3";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc2";
+   };
+
+   mmc3: mmc@3 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc3";
+   };
+
+   mmc4: mmc@4 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc4";
+   };
+
+   mmc5: mmc@5 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc5";
+   };
};
  };


These all should all be "ti,omap3-hsmmc" I guess?


Well, I defined the binding such that both omap2 and omap3
can use the same compatible "ti,omap2-hsmmc" since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.



Tony


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v3 1/2] regulator: twl: adapt twl-regulator driver to dt

2012-02-23 Thread Rajendra Nayak

On Thursday 23 February 2012 09:01 PM, Mark Brown wrote:

On Thu, Feb 23, 2012 at 05:05:53PM +0530, Rajendra Nayak wrote:

Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)


This doesn't apply to current -next, I expect because of the SMPS
regulator changes which went in.  Please always submit patches against
-next.  There's also a patch from Tero adding support for some
additional regulators which is floating around and would conflict with
this.  Could you guys please coordinate with each other on this?


Sure, I will co-ordinate with Tero and post my patches against -next.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 0/4] omap hsmmc device tree support

2012-02-23 Thread Rajendra Nayak

On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote:

This series adds device tree support for OMAP hsmmc
driver. The series is dependent on a couple other series,
to add TWL regulator DT support[1] and another to clean
the pdev->id usage within the hsmmc driver[2]

all patches including the dependent series can be
found here
git://gitorious.org/omap-pm/linux.git for-dt/regulator


sorry, the right branch is for-dt/mmc



The series is tested on omap4sdp (both external and emmc),
omap4panda amd omap3beagle boards.

Things to do:
-1- Card detect isn't functional and needs twl4030 gpio
to be DT converted.
-2- pbias cell programming is missing and needs an OMAP
control module driver.

[1] http://marc.info/?l=linux-omap&m=132999699905180&w=2
[2] http://marc.info/?l=linux-omap&m=132999646604985&w=2

Rajendra Nayak (4):
   mmc: omap_hsmmc: Convert hsmmc driver to use device tree
   mmc: omap_hsmmc: Avoid a regulator voltage change with dt
   arm/dts: OMAP4: Add mmc controller nodes and board data
   arm/dts: OMAP3: Add mmc controller nodes and board data

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   31 +++
  arch/arm/boot/dts/omap3-beagle.dts |6 ++
  arch/arm/boot/dts/omap3.dtsi   |   26 ++
  arch/arm/boot/dts/omap4-panda.dts  |   10 +++
  arch/arm/boot/dts/omap4-sdp.dts|   16 
  arch/arm/boot/dts/omap4.dtsi   |   31 +++
  drivers/mmc/host/omap_hsmmc.c  |   83 +++-
  7 files changed, 202 insertions(+), 1 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-02-23 Thread Rajendra Nayak
Add omap mmc related device tree data for OMAP3.
Currenly limited to only omap3-beagle board.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap3-beagle.dts |6 ++
 arch/arm/boot/dts/omap3.dtsi   |   26 ++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 54556b1..c7b92e6 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -53,3 +53,9 @@
reg = <0x50>;
};
 };
+
+&mmc1 {
+   vmmc-supply = <&vmmc1>;
+   vmmc_aux-supply = <&vsim>;
+   ti,bus-width = <8>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ca37ba5..598467c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells = <0>;
ti,hwmods = "i2c3";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc2";
+   };
+
+   mmc3: mmc@3 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc3";
+   };
+
+   mmc4: mmc@4 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc4";
+   };
+
+   mmc5: mmc@5 {
+   compatible = "ti,omap2-hsmmc";
+   ti,hwmods = "mmc5";
+   };
};
 };
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data

2012-02-23 Thread Rajendra Nayak
Add omap mmc related device tree data for OMAP4.
Currenly limited to only omap4-panda and omap4-sdp
boards.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap4-panda.dts |   10 ++
 arch/arm/boot/dts/omap4-sdp.dts   |   16 
 arch/arm/boot/dts/omap4.dtsi  |   31 +++
 3 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 29646dc..9fe51b9 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,3 +52,13 @@
 &i2c4 {
clock-frequency = <40>;
 };
+
+&mmc1 {
+   vmmc-supply = <&vmmc>;
+   ti,bus-width = <8>;
+};
+
+&mmc5 {
+   ti,non-removable;
+   ti,bus-width = <4>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 01db8b7..2fca7a3 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,3 +70,19 @@
reg = <0x1e>;
};
 };
+
+&mmc1 {
+   vmmc-supply = <&vmmc>;
+   ti,bus-width = <8>;
+};
+
+&mmc2 {
+   vmmc-supply = <&vaux1>;
+   ti,bus-width = <8>;
+   ti,non-removable;
+};
+
+&mmc5 {
+   ti,bus-width = <4>;
+   ti,non-removable;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+   mmc1 = &mmc1;
+   mmc2 = &mmc2;
+   mmc3 = &mmc3;
+   mmc4 = &mmc4;
+   mmc5 = &mmc5;
};
 
cpus {
@@ -155,5 +160,31 @@
#size-cells = <0>;
ti,hwmods = "i2c4";
};
+
+   mmc1: mmc@1 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc2";
+   };
+
+   mmc3: mmc@3 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc3";
+   };
+
+   mmc4: mmc@4 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc4";
+   };
+
+   mmc5: mmc@5 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc5";
+   };
};
 };
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 0/4] omap hsmmc device tree support

2012-02-23 Thread Rajendra Nayak
This series adds device tree support for OMAP hsmmc
driver. The series is dependent on a couple other series,
to add TWL regulator DT support[1] and another to clean
the pdev->id usage within the hsmmc driver[2]

all patches including the dependent series can be
found here
git://gitorious.org/omap-pm/linux.git for-dt/regulator

The series is tested on omap4sdp (both external and emmc),
omap4panda amd omap3beagle boards.

Things to do:
-1- Card detect isn't functional and needs twl4030 gpio
to be DT converted.
-2- pbias cell programming is missing and needs an OMAP
control module driver.

[1] http://marc.info/?l=linux-omap&m=132999699905180&w=2
[2] http://marc.info/?l=linux-omap&m=132999646604985&w=2

Rajendra Nayak (4):
  mmc: omap_hsmmc: Convert hsmmc driver to use device tree
  mmc: omap_hsmmc: Avoid a regulator voltage change with dt
  arm/dts: OMAP4: Add mmc controller nodes and board data
  arm/dts: OMAP3: Add mmc controller nodes and board data

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   31 +++
 arch/arm/boot/dts/omap3-beagle.dts |6 ++
 arch/arm/boot/dts/omap3.dtsi   |   26 ++
 arch/arm/boot/dts/omap4-panda.dts  |   10 +++
 arch/arm/boot/dts/omap4-sdp.dts|   16 
 arch/arm/boot/dts/omap4.dtsi   |   31 +++
 drivers/mmc/host/omap_hsmmc.c  |   83 +++-
 7 files changed, 202 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-02-23 Thread Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.

Signed-off-by: Rajendra Nayak 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   31 +
 drivers/mmc/host/omap_hsmmc.c  |   68 
 2 files changed, 99 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be "ti,omap2-hsmmc", for OMAP2/3 controllers
+ Should be "ti,omap4-hsmmc", for OMAP4 controllers
+- ti,hwmods: Must be "mmc", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is 
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+   mmc1: mmc@0x4809c000 {
+   compatible = "ti,omap4-hsmmc";
+   reg = <0x4809c000 0x400>;
+   ti,hwmods = "mmc1";
+   ti,dual-volt;
+   ti,bus-width = <4>;
+   vmmc-supply = <&vmmc>; /* phandle to regulator node */
+   ti,non-removable;
+   };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 35f6dc1..0c93d58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
 
 #endif
 
+#ifdef CONFIG_OF
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+   struct omap_mmc_platform_data *pdata;
+   struct device_node *np = dev->of_node;
+   u32 bus_width;
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL; /* out of memory */
+
+   if (of_find_property(np, "ti,dual-volt", NULL))
+   pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+   /* This driver only supports 1 slot */
+   pdata->nr_slots = 1;
+   pdata->slots[0].switch_pin = of_get_named_gpio(np, "cd-gpios", 0);
+   pdata->slots[0].gpio_wp = of_get_named_gpio(np, "wp-gpios", 0);
+
+   if (of_find_property(np, "ti,non-removable", NULL)) {
+   pdata->slots[0].nonremovable = true;
+   pdata->slots[0].no_regulator_off_init = true;
+   }
+   of_property_read_u32(np, "ti,bus-width", &bus_width);
+   if (bus_width == 4)
+   pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA;
+   else if (bus_width == 8)
+   pdata->slots[0].caps |= MMC_CAP_8_BIT_DATA;
+   return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+   *of_get_hsmmc_pdata(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
 static int __init omap_hsmmc_probe(struct platform_device *pdev)
 {
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct 
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+   const struct of_device_id *match;
+
+   match = of_match_device(omap_mmc_of_match, &pdev->dev);
+   if (match) {
+   pdata = of_get_hsmmc_pdata(&pdev->dev);
+   if (match->data)
+   pdata->reg_offset = *(u16 *)match->data;
+   }
 
if (pdata == NULL) {
dev_err(&pdev->dev, "Platform Data is missing\n");
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
 };
 
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+   {
+   .compatible = "ti,omap2-hsmmc",
+   },
+   {
+   .compatible = "ti,omap4-hsmm

[PATCH v2 2/4] mmc: omap_hsmmc: Avoid a regulator voltage change with dt

2012-02-23 Thread Rajendra Nayak
When booting with Device tree, the omap_hsmmc driver does not
program the pbias cell (inside OMAP control module) during
a regulator voltage change.
In case of non-dt boot, this is handled using callbacks
from within platform_data and implemented in machine code.
To be able to do this with device tree, without invoking
any machine code, a OMAP control module driver is needed
which is yet missing.

The pbias cell is used to provide a 1.8v or 3.0v reference
to the mmc/sd/sdio1 interface supporting both 1.8v and 3.0v
voltages.

Until a OMAP control module driver is available to handle this,
when booting with a device tree blob, never change the regulator
voltage which might then require a pbias cell re-program.
There are 2 instances where in the mmc regulator voltage can be
changed.
-1- when the regulator is turned OFF.
-2- when attempting a switch to 1.8v from 3.0v for dual volt cards

This patch avoids a voltage change in both cases when booting from
device tree, and hence compromises on power savings.
Once the OMAP control module driver is available and hsmmc driver
is modified to then do pbias programming even when booting
with device tree, these limitaions can be removed to achieve better
power savings.

Signed-off-by: Rajendra Nayak 
---
 drivers/mmc/host/omap_hsmmc.c |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0c93d58..dffde8d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -245,6 +245,13 @@ static int omap_hsmmc_set_power(struct device *dev, int 
slot, int power_on,
 */
if (!host->vcc)
return 0;
+   /*
+* With DT, never turn OFF the regulator. This is because
+* the pbias cell programming support is still missing when
+* booting with Device tree
+*/
+   if (of_have_populated_dt() && !vdd)
+   return 0;
 
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -1537,7 +1544,13 @@ 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)) {
+   (ios->vdd == DUAL_VOLT_OCR_BIT) &&
+   /*
+* With pbias cell programming missing, this
+* can't be allowed when booting with device
+* tree.
+*/
+   (!of_have_populated_dt())) {
/*
 * The mmc_select_voltage fn of the core does
 * not seem to set the power_mode to
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 1/2] regulator: twl: adapt twl-regulator driver to dt

2012-02-23 Thread Rajendra Nayak
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)

Also add documentation for TWL regulator specific bindings.

Signed-off-by: Rajendra Nayak 
---
 .../bindings/regulator/twl-regulator.txt   |   63 ++
 drivers/regulator/twl-regulator.c  |  227 +---
 2 files changed, 217 insertions(+), 73 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt 
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..074e344
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,63 @@
+TWL family of regulators
+
+Required properties:
+For twl6030 regulators/LDOs
+- compatible:
+  - "ti,twl6030-vaux1" for VAUX1 LDO
+  - "ti,twl6030-vaux2" for VAUX2 LDO
+  - "ti,twl6030-vaux3" for VAUX3 LDO
+  - "ti,twl6030-vmmc" for VMMC LDO
+  - "ti,twl6030-vpp" for VPP LDO
+  - "ti,twl6030-vusim" for VUSIM LDO
+  - "ti,twl6030-vana" for VANA LDO
+  - "ti,twl6030-vcxio" for VCXIO LDO
+  - "ti,twl6030-vdac" for VDAC LDO
+  - "ti,twl6030-vusb" for VUSB LDO
+  - "ti,twl6030-clk32kg" for CLK32KG LDO
+For twl6025 regulators/LDOs
+- compatible:
+  - "ti,twl6025-ldo1" for LDO1 LDO
+  - "ti,twl6025-ldo2" for LDO2 LDO
+  - "ti,twl6025-ldo3" for LDO3 LDO
+  - "ti,twl6025-ldo4" for LDO4 LDO
+  - "ti,twl6025-ldo5" for LDO5 LDO
+  - "ti,twl6025-ldo6" for LDO6 LDO
+  - "ti,twl6025-ldo7" for LDO7 LDO
+  - "ti,twl6025-ldoln" for LDOLN LDO
+  - "ti,twl6025-ldousb" for LDOUSB LDO
+  - "ti,twl6025-smps3" for SMPS3 LDO
+  - "ti,twl6025-smps4" for SMPS4 LDO
+  - "ti,twl6025-vio" for VIO LDO
+For twl4030 regulators/LDOs
+- compatible:
+  - "ti,twl4030-vaux1" for VAUX1 LDO
+  - "ti,twl4030-vaux2" for VAUX2 LDO
+  - "ti,twl5030-vaux2" for VAUX2 LDO
+  - "ti,twl4030-vaux3" for VAUX3 LDO
+  - "ti,twl4030-vaux4" for VAUX4 LDO
+  - "ti,twl4030-vmmc1" for VMMC1 LDO
+  - "ti,twl4030-vmmc2" for VMMC2 LDO
+  - "ti,twl4030-vpll1" for VPLL1 LDO
+  - "ti,twl4030-vpll2" for VPLL2 LDO
+  - "ti,twl4030-vsim" for VSIM LDO
+  - "ti,twl4030-vdac" for VDAC LDO
+  - "ti,twl4030-vintana2" for VINTANA2 LDO
+  - "ti,twl4030-vio" for VIO LDO
+  - "ti,twl4030-vdd1" for VDD1 LDO
+  - "ti,twl4030-vdd2" for VDD2 LDO
+  - "ti,twl4030-vintana1" for VINTANA1 LDO
+  - "ti,twl4030-vintdig" for VINTDIG LDO
+  - "ti,twl4030-vusb1v5" for VUSB1V5 LDO
+  - "ti,twl4030-vusb1v8" for VUSB1V8 LDO
+  - "ti,twl4030-vusb3v1" for VUSB3V1 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+   xyz: regulator@0 {
+   compatible = "ti,twl6030-vaux1";
+   regulator-min-microvolt  = <100>;
+   regulator-max-microvolt  = <300>;
+   };
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 181a2cf..77808c7 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -866,7 +869,8 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
 
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { 
\
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
@@ -884,7 +888,7 @@ static struct regulator_ops twlsmps_ops = {
}
 
 #define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf) \
-   { \
+static struct twlreg_info TWL4030_INFO_##label = { \
.base = offset, \
.id = num, \
.delay = turnon_delay, \
@@ -898,7 +902,8 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) \
+static struct twlreg_info TWL6030_INFO_##label = { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
@@ -912,7 +917,8 @@ static struct regulator_ops twlsmps_ops = {

[PATCH v3 2/2] arm/dts: twl: Pass regulator data from dt

2012-02-23 Thread Rajendra Nayak
Pass all the voltage regulator information for
twl6030/twl4030 PMIC from device tree.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Benoit Cousson 
---
 arch/arm/boot/dts/omap3-beagle.dts |6 +++
 arch/arm/boot/dts/twl4030.dtsi |   18 +++
 arch/arm/boot/dts/twl6030.dtsi |   60 
 3 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 714ba5d..54556b1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -26,6 +26,12 @@
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
+
+   vsim: regulator@10 {
+   compatible = "ti,twl4030-vsim";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 8be5223..a94654c 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -18,4 +18,22 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+   vdac: regulator@0 {
+   compatible = "ti,twl4030-vdac";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vpll2: regulator@1 {
+   compatible = "ti,twl4030-vpll2";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   vmmc1: regulator@2 {
+   compatible = "ti,twl4030-vmmc1";
+   regulator-min-microvolt = <185>;
+   regulator-max-microvolt = <315>;
+   };
 };
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index b7b4e5e..efa19e8 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -19,4 +19,64 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+   vaux1: regulator@0 {
+   compatible = "ti,twl6030-vaux1";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vaux2: regulator@1 {
+   compatible = "ti,twl6030-vaux2";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <280>;
+   };
+
+   vaux3: regulator@2 {
+   compatible = "ti,twl6030-vaux3";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vmmc: regulator@3 {
+   compatible = "ti,twl6030-vmmc";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vpp: regulator@4 {
+   compatible = "ti,twl6030-vpp";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <250>;
+   };
+
+   vusim: regulator@5 {
+   compatible = "ti,twl6030-vusim";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <290>;
+   };
+
+   vdac: regulator@6 {
+   compatible = "ti,twl6030-vdac";
+   };
+
+   vana: regulator@7 {
+   compatible = "ti,twl6030-vana";
+   };
+
+   vcxio: regulator@8 {
+   compatible = "ti,twl6030-vcxio";
+   };
+
+   vusb: regulator@9 {
+   compatible = "ti,twl6030-vusb";
+   };
+
+   vusb: regulator@9 {
+   compatible = "ti,twl6030-vusb";
+   };
+
+   clk32kg: regulator@10 {
+   compatible = "ti,twl6030-clk32kg";
+   };
 };
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 0/2] Device tree support for TWL regulators

2012-02-23 Thread Rajendra Nayak
Re-sending as these patches did not make it to the lists due to
issues with my 'git send-email'

v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 and twl6030 are
now defined in the twl4030.dtsi and twl6030.dtsi instead of
repeating the nodes in all board files, which also means
the patch ('arm/dts: twl: Pass regulator data from dt')
has a dependency with the series from Benoit which adds the
twl4030.dtsi and twl6030.dtsi files[1].

I have tested the patches on omap4panda and omap3beagle boards.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.4/dt_i2c_twl

Rajendra Nayak (2):
  regulator: twl: adapt twl-regulator driver to dt
  arm/dts: twl: Pass regulator data from dt

 .../bindings/regulator/twl-regulator.txt   |   63 ++
 arch/arm/boot/dts/omap3-beagle.dts |6 +
 arch/arm/boot/dts/twl4030.dtsi |   18 ++
 arch/arm/boot/dts/twl6030.dtsi |   60 +
 drivers/regulator/twl-regulator.c  |  227 +---
 5 files changed, 301 insertions(+), 73 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH] arm/dts: Add minimal device tree support for omap2420 and omap2430

2011-12-15 Thread Rajendra Nayak

On Friday 16 December 2011 03:09 AM, Tony Lindgren wrote:

Add minimal device tree support for omap2420 and omap2430


Looks good to me.



Signed-off-by: Tony Lindgren

--- /dev/null
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Source for OMAP2 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
+
+   aliases {
+   serial0 =&uart1;
+   serial1 =&uart2;
+   serial2 =&uart3;
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = "arm,arm1136jf-s";
+   };
+   };
+
+   soc {
+   compatible = "ti,omap-infra";
+   mpu {
+   compatible = "ti,omap2-mpu";
+   ti,hwmods = "mpu";
+   };
+   };
+
+   ocp {
+   compatible = "simple-bus";
+   #address-cells =<1>;
+   #size-cells =<1>;
+   ranges;
+   ti,hwmods = "l3_main";
+
+   intc: interrupt-controller@1 {
+   compatible = "ti,omap2-intc";
+   interrupt-controller;
+   #interrupt-cells =<1>;
+   };
+
+   uart1: serial@4806a000 {
+   compatible = "ti,omap2-uart";
+   ti,hwmods = "uart1";
+   clock-frequency =<4800>;
+   };
+
+   uart2: serial@4806c000 {
+   compatible = "ti,omap2-uart";
+   ti,hwmods = "uart2";
+   clock-frequency =<4800>;
+   };
+
+   uart3: serial@4806e000 {
+   compatible = "ti,omap2-uart";
+   ti,hwmods = "uart3";
+   clock-frequency =<4800>;
+   };
+   };
+};


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt

2011-12-14 Thread Rajendra Nayak

On Thursday 15 December 2011 12:55 AM, Tony Lindgren wrote:

* Rajendra Nayak  [111214 03:24]:

Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Acked-by: Rob Herring
Signed-off-by: Rajendra Nayak


This we can't merge because this breaks serial console for
omap2 because you're not adding the omap2 specific dtsi
entries for omap2..


But we never had omap2 working with DT, because we never added
a .dtsi file for omap2 or a .dts file for any omap2 board variants.

Until now the DT support on OMAP has been limited to OMAP3 and OMAP4
with boards limited to omap3beagle/omap4Panda and omap4sdp.

So when we do add base support for omap2, we could update those
with the serial entries.




--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);

-   omap_serial_init();
omap_sdrc_init(NULL, NULL);

of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);


..and you're removing the call for omap_serial_init.

Please just update this patch with the omap2 entries
as well. Other than that looks good to me.

Tony


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 1/4] omap-serial: Get rid of all pdev->id usage

2011-12-14 Thread Rajendra Nayak
With Device tree, pdev->id would no longer be Valid.
Hence get rid of all instances of its usage in the
driver. Device tree support for the driver is added
in subsequent patches.

Signed-off-by: Rajendra Nayak 
---
 drivers/tty/serial/omap-serial.c |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..a02cc9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -115,7 +115,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
 
-   dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
up->ier |= UART_IER_MSI;
@@ -418,7 +418,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port 
*port)
unsigned int ret = 0;
 
pm_runtime_get_sync(&up->pdev->dev);
-   dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->port.line);
spin_lock_irqsave(&up->port.lock, flags);
ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
spin_unlock_irqrestore(&up->port.lock, flags);
@@ -436,7 +436,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port 
*port)
status = check_modem_status(up);
pm_runtime_put(&up->pdev->dev);
 
-   dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line);
 
if (status & UART_MSR_DCD)
ret |= TIOCM_CAR;
@@ -454,7 +454,7 @@ static void serial_omap_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char mcr = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->port.line);
if (mctrl & TIOCM_RTS)
mcr |= UART_MCR_RTS;
if (mctrl & TIOCM_DTR)
@@ -478,7 +478,7 @@ static void serial_omap_break_ctl(struct uart_port *port, 
int break_state)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
spin_lock_irqsave(&up->port.lock, flags);
if (break_state == -1)
@@ -504,7 +504,7 @@ static int serial_omap_startup(struct uart_port *port)
if (retval)
return retval;
 
-   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -545,7 +545,7 @@ static int serial_omap_startup(struct uart_port *port)
0);
init_timer(&(up->uart_dma.rx_timer));
up->uart_dma.rx_timer.function = serial_omap_rxdma_poll;
-   up->uart_dma.rx_timer.data = up->pdev->id;
+   up->uart_dma.rx_timer.data = up->port.line;
/* Currently the buffer size is 4KB. Can increase it */
up->uart_dma.rx_buf = dma_alloc_coherent(NULL,
up->uart_dma.rx_buf_size,
@@ -573,7 +573,7 @@ static void serial_omap_shutdown(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -883,7 +883,7 @@ serial_omap_set_termios(struct uart_port *port, struct 
ktermios *termios,
 
spin_unlock_irqrestore(&up->port.lock, flags);
pm_runtime_put(&up->pdev->dev);
-   dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line);
 }
 
 static void
@@ -893,7 +893,7 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char efr;
 
-   dev_dbg(up->port.d

[PATCH v3 3/4] omap-serial: Add minimal device tree support

2011-12-14 Thread Rajendra Nayak
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smartidle bits and handling
remote wakeup and dynamic muxing.

Acked-by: Rob Herring 
Signed-off-by: Rajendra Nayak 
---
 .../devicetree/bindings/serial/omap_serial.txt |   10 
 drivers/tty/serial/omap-serial.c   |   45 ++-
 2 files changed, 52 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap2-uart" for OMAP2 controllers
+- compatible : should be "ti,omap3-uart" for OMAP3 controllers
+- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- ti,hwmods : Must be "uart", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, 
void *data)
return;
 }
 
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+   struct omap_uart_port_info *omap_up_info;
+
+   omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+   if (!omap_up_info)
+   return NULL; /* out of memory */
+
+   of_property_read_u32(dev->of_node, "clock-frequency",
+&omap_up_info->uartclk);
+   return omap_up_info;
+}
+
 static int serial_omap_probe(struct platform_device *pdev)
 {
struct uart_omap_port   *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;
int ret = -ENOSPC;
 
+   if (pdev->dev.of_node)
+   omap_up_info = of_get_uart_port_info(&pdev->dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(&pdev->dev, "no mem resource?\n");
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device 
*pdev)
up->port.regshift = 2;
up->port.fifosize = 64;
up->port.ops = &serial_omap_pops;
-   up->port.line = pdev->id;
-   sprintf(up->name, "OMAP UART%d", up->port.line);
 
+   if (pdev->dev.of_node)
+   up->port.line = of_alias_get_id(pdev->dev.of_node, "serial");
+   else
+   up->port.line = pdev->id;
+
+   if (up->port.line < 0) {
+   dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
+   up->port.line);
+   ret = -ENODEV;
+   goto err;
+   }
+
+   sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = ioremap(mem->start, resource_size(mem));
if (!up->port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
 
-   if (!pdata->enable_wakeup)
+   if (!pdata || !pdata->enable_wakeup)
return 0;
 
if (pdata->get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = 
{
serial_omap_runtime_resume, NULL)
 };
 
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+   { .compatible = "ti,omap2-uart" },
+   { .compatible = "ti,omap3-uart" },
+   { .compatible = "ti,omap4-uart" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
 static struct platform_driver serial_omap_driver = {
.probe  = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name   = DRIVER_NAME,
.pm = &serial_omap_dev_pm_ops,
+   .of_match_table = of_match_ptr(omap_serial_of_match),
},
 };
 
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt

2011-12-14 Thread Rajendra Nayak
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Acked-by: Rob Herring 
Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap3.dtsi|   31 +++
 arch/arm/boot/dts/omap4.dtsi|   28 
 arch/arm/mach-omap2/board-generic.c |1 -
 3 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..216c331 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
 / {
compatible = "ti,omap3430", "ti,omap3";
 
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart2;
+   serial2 = &uart3;
+   serial3 = &uart4;
+   };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +66,29 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+   uart1: serial@0x4806a000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart1";
+   clock-frequency = <4800>;
+   };
+
+   uart2: serial@0x4806c000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart2";
+   clock-frequency = <4800>;
+   };
+
+   uart3: serial@0x4902 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   };
+
+   uart4: serial@0x49042000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart4";
+   clock-frequency = <4800>;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..e8fe75f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
 
aliases {
+   serial0 = &uart1;
+   serial1 = &uart2;
+   serial2 = &uart3;
+   serial3 = &uart4;
};
 
cpus {
@@ -99,5 +103,29 @@
reg = <0x48241000 0x1000>,
  <0x48240100 0x0100>;
};
+
+   uart1: serial@0x4806a000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart1";
+   clock-frequency = <4800>;
+   };
+
+   uart2: serial@0x4806c000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart2";
+   clock-frequency = <4800>;
+   };
+
+   uart3: serial@0x4802 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   };
+
+   uart4: serial@0x4806e000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart4";
+   clock-frequency = <4800>;
+   };
};
 };
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
 
-   omap_serial_init();
omap_sdrc_init(NULL, NULL);
 
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 0/4] OMAP serial device tree support

2011-12-14 Thread Rajendra Nayak
v3 is rebased on top of the latest serial runtime
patches[1] and boot tested with/without DT on OMAP4
SDP and OMAP4 Panda boards.

Patches can be found here..
git://gitorious.org/omap-pm/linux.git for-dt/serial

I also had to pull in a fix[2] for DT testing (already in linux-omap
master) which was missing as the serial runtime branch[1]
was based on an older master commit.

Changes in v3:
-1- Rebased on latest serial runtime patches
-2- Minor typr fixes

Changes in v2:
-1- Got rid of binding to define which uart is console
-2- Added checks to default clock speed to 48Mhz
-3- Added compatible for each OMAP family
-4- Used of_alias_get_id to populate port.line

[1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
[2] http://www.spinics.net/lists/arm-kernel/msg150751.html

Rajendra Nayak (4):
  omap-serial: Get rid of all pdev->id usage
  omap-serial: Use default clock speed (48Mhz) if not specified
  omap-serial: Add minimal device tree support
  ARM: omap: pass minimal SoC/board data for UART from dt

 .../devicetree/bindings/serial/omap_serial.txt |   10 +++
 arch/arm/boot/dts/omap3.dtsi   |   31 
 arch/arm/boot/dts/omap4.dtsi   |   28 +++
 arch/arm/mach-omap2/board-generic.c|1 -
 drivers/tty/serial/omap-serial.c   |   80 +++
 5 files changed, 132 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v3 2/4] omap-serial: Use default clock speed (48Mhz) if not specified

2011-12-14 Thread Rajendra Nayak
Use a default clock speed of 48Mhz, instead of ending up with 0,
if platforms fail to specify a valid clock speed.

Signed-off-by: Rajendra Nayak 
---
 drivers/tty/serial/omap-serial.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a02cc9f..f14b9c5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,8 @@
 #include 
 #include 
 
+#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+
 static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
 
 /* Forward declaration of functions */
@@ -1386,6 +1388,11 @@ static int serial_omap_probe(struct platform_device 
*pdev)
 
up->port.flags = omap_up_info->flags;
up->port.uartclk = omap_up_info->uartclk;
+   if (!up->port.uartclk) {
+   up->port.uartclk = DEFAULT_CLK_SPEED;
+   dev_warn(&pdev->dev, "No clock speed specified: using default:"
+   "%d\n", DEFAULT_CLK_SPEED);
+   }
up->uart_dma.uart_base = mem->start;
up->errata = omap_up_info->errata;
 
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 1/3] regulator: twl: adapt twl-regulator driver to dt

2011-12-13 Thread Rajendra Nayak
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)

Also add documentation for TWL regulator specific bindings.

Signed-off-by: Rajendra Nayak 
---
 .../bindings/regulator/twl-regulator.txt   |   57 +
 drivers/regulator/twl-regulator.c  |  128 +---
 2 files changed, 139 insertions(+), 46 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt 
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..bdd96d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,57 @@
+TWL family of regulators
+
+Required properties:
+- compatible:
+  - "ti,twl4030" for twl4030 regulators
+  - "ti,twl6025" for twl6025 regulators
+  - "ti,twl6030" for twl6030 regulators
+
+Additionally compatible can be used to specify the
+exact regulator/ldo instance like
+For twl6030 regulators/LDO's
+- compatible:
+  - "ti,twl6030-vaux1" for VAUX1 LDO
+  - "ti,twl6030-vaux2" for VAUX2 LDO
+  - "ti,twl6030-vaux3" for VAUX3 LDO
+  - "ti,twl6030-vmmc" for VMMC LDO
+  - "ti,twl6030-vpp" for VPP LDO
+  - "ti,twl6030-vusim" for VUSIM LDO
+For twl6025 regulators/LDO's
+- compatible:
+  - "ti,twl6025-ldo1" for LDO1 LDO
+  - "ti,twl6025-ldo2" for LDO2 LDO
+  - "ti,twl6025-ldo3" for LDO3 LDO
+  - "ti,twl6025-ldo4" for LDO4 LDO
+  - "ti,twl6025-ldo5" for LDO5 LDO
+  - "ti,twl6025-ldo6" for LDO6 LDO
+  - "ti,twl6025-ldo7" for LDO7 LDO
+  - "ti,twl6025-ldoln" for LDOLN LDO
+  - "ti,twl6025-ldousb" for LDOUSB LDO
+For twl4030 regulators/LDO's
+- compatible:
+  - "ti,twl4030-vaux1" for VAUX1 LDO
+  - "ti,twl4030-vaux2" for VAUX2 LDO
+  - "ti,twl5030-vaux2" for VAUX2 LDO
+  - "ti,twl4030-vaux3" for VAUX3 LDO
+  - "ti,twl4030-vaux4" for VAUX4 LDO
+  - "ti,twl4030-vmmc1" for VMMC1 LDO
+  - "ti,twl4030-vmmc2" for VMMC2 LDO
+  - "ti,twl4030-vpll1" for VPLL1 LDO
+  - "ti,twl4030-vpll2" for VPLL2 LDO
+  - "ti,twl4030-vsim" for VSIM LDO
+  - "ti,twl4030-vdac" for VDAC LDO
+  - "ti,twl4030-vintana2" for VINTANA2 LDO
+  - "ti,twl4030-vio" for VIO LDO
+  - "ti,twl4030-vdd1" for VDD1 LDO
+  - "ti,twl4030-vdd2" for VDD2 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+   xyz: regulator@0 {
+   compatible = "ti,twl6030-vaux1","ti,twl6030";
+   regulator-min-microvolt  = <100>;
+   regulator-max-microvolt  = <300>;
+   };
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 181a2cf..e1a4134 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -58,6 +60,7 @@ struct twlreg_info {
 
/* chip specific features */
unsigned long   features;
+   const char  *compatible;
 };
 
 
@@ -866,13 +869,14 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
 
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { 
\
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf, 
comp) { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
.table = label##_VSEL_table, \
.delay = turnon_delay, \
.remap = remap_conf, \
+   .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -883,12 +887,13 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf) \
+#define TWL4030_ADJUSTABLE_SMPS(label, offset, num, turnon_delay, remap_conf, 
comp) \
{ \
.base = offset, \
.id = num, \
.delay = turnon_delay, \
.remap = remap_conf, \
+   .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -898,10 +903,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, 

[PATCH v2 0/3] Device tree support for TWL regulators

2011-12-13 Thread Rajendra Nayak
This series adds DT support for TWL regulator driver and
passes regulator data for two OMAP4 boards (OMAP4 panda and
OMAP4 sdp) from device tree.

Patches are based on for-next of the regulator tree[1] with
omap i2c/twl DT adaptation patches[2] from Benoit pulled in
and are available here:
git://gitorious.org/omap-pm/linux.git for-dt/regulator-twl

regards,
Rajendra

[1] git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
[2] git://gitorious.org/omap-pm/linux.git for_3.3/3_omap_dt_i2c_twl

Rajendra Nayak (3):
  regulator: twl: adapt twl-regulator driver to dt
  ARM: omap4-sdp: Pass regulator data from dt
  omap4: panda: Pass regulator data from dt

 .../bindings/regulator/twl-regulator.txt   |   57 +
 arch/arm/boot/dts/omap4-panda.dts  |   24 
 arch/arm/boot/dts/omap4-sdp.dts|   36 ++
 drivers/regulator/twl-regulator.c  |  128 +---
 4 files changed, 199 insertions(+), 46 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 2/3] ARM: omap4-sdp: Pass regulator data from dt

2011-12-13 Thread Rajendra Nayak
Pass the adjustable voltage regulator information for
omap4sdp board from device tree.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap4-sdp.dts |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 0ab14cb..daf8b69 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -40,6 +40,42 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+   vaux1: regulator@0 {
+   compatible = "ti,twl6030-vaux1","ti,twl6030";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vaux2: regulator@1 {
+   compatible = "ti,twl6030-vaux2","ti,twl6030";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <280>;
+   };
+
+   vaux3: regulator@2 {
+   compatible = "ti,twl6030-vaux3","ti,twl6030";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vmmc: regulator@3 {
+   compatible = "ti,twl6030-vmmc","ti,twl6030";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vpp: regulator@4 {
+   compatible = "ti,twl6030-vpp","ti,twl6030";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <250>;
+   };
+
+   vusim: regulator@5 {
+   compatible = "ti,twl6030-vusim","ti,twl6030";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <290>;
+   };
};
 };
 
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 3/3] omap4: panda: Pass regulator data from dt

2011-12-13 Thread Rajendra Nayak
Pass the adjustable voltage regulator information for
omap4panda board from device tree.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap4-panda.dts |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index b66bcd6..f6cc48a 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -40,6 +40,30 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+   vaux2: regulator@0 {
+   compatible = "ti,twl6030-vaux2","ti,twl6030";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <280>;
+   };
+
+   vaux3: regulator@1 {
+   compatible = "ti,twl6030-vaux3","ti,twl6030";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vmmc: regulator@2 {
+   compatible = "ti,twl6030-vmmc","ti,twl6030";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <300>;
+   };
+
+   vpp: regulator@3 {
+   compatible = "ti,twl6030-vpp","ti,twl6030";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <250>;
+   };
};
 };
 
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller

2011-12-13 Thread Rajendra Nayak

Hi Benoit,


diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..bcfccc2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -156,6 +156,16 @@ void omap3_intc_resume_idle(void);
  void omap2_intc_handle_irq(struct pt_regs *regs);
  void omap3_intc_handle_irq(struct pt_regs *regs);

+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+   return 0;
+}


This seems to break !CONFIG_OF builds as common.h is included in
multiple c files causing 'multiple definition' errors.

regards,
Rajendra


+#endif
+
  /*
   * wfi used in low power code. Directly opcode is used instead
   * of instruction to avoid mulit-omap build break
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 42b1d65..cafc663 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -17,6 +17,9 @@
  #include
  #include
  #include
+#include
+#include
+#include


  /* selected INTC register offsets */
@@ -166,7 +169,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank->base_reg = ioremap(base, SZ_4K);
if (!bank->base_reg) {
-   printk(KERN_ERR "Could not ioremap irq bank%i\n", i);
+   pr_err("Could not ioremap irq bank%i\n", i);
continue;
}

@@ -179,8 +182,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
nr_banks++;
}

-   printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
-  nr_of_irqs, nr_banks, nr_banks>  1 ? "s" : "");
+   pr_info("Total of %ld interrupts on %d active controller%s\n",
+   nr_of_irqs, nr_banks, nr_banks>  1 ? "s" : "");
  }

  void __init omap2_init_irq(void)
@@ -236,6 +239,32 @@ asmlinkage void __exception_irq_entry 
omap2_intc_handle_irq(struct pt_regs *regs
omap_intc_handle_irq(base_addr, regs);
  }

+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+   struct resource res;
+   u32 nr_irqs;
+
+   if (WARN_ON(!node))
+   return -ENODEV;
+
+   if (of_address_to_resource(node, 0,&res)) {
+   WARN(1, "unable to get intc registers\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32(node, "ti,intc-size",&nr_irqs)) {
+   WARN(1, "unable to get intc-size\n");
+   return -EINVAL;
+   }
+
+   omap_init_irq(res.start, nr_irqs);
+   irq_domain_add_simple(node, 0);
+
+   return 0;
+}
+#endif
+
  #ifdef CONFIG_ARCH_OMAP3
  static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

2011-12-05 Thread Rajendra Nayak

On Monday 05 December 2011 04:27 PM, Mark Brown wrote:

On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:

On 5 December 2011 16:04, Mark Brown



With the regulator device tree bindings if the regulator is configured
to run a single voltage the bindings will set apply_uV unconditionally
so there's no need for a separate constraint.



Sorry if I have missed this, but I could not find 'apply_uV' being set
as you described in the v5 of the regulator-dt patchset.


Yes, looks like Rajendra missed that - just fixed it.


Thanks Mark, I certainly seem to have missed it.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v5 3/4] regulator: pass additional of_node to regulator_register()

2011-12-04 Thread Rajendra Nayak


Documentation/power/regulator/regulator.txt would also require an
update the reflect the change in api.


Thanks Thomas, I just sent a patch to fix this up.

regards,
Rajendra



Thanks,
Thomas.

[...]


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 2/5] regulator: fix label names used in device tree bindings

2011-11-29 Thread Rajendra Nayak

On Monday 28 November 2011 07:07 PM, Shawn Guo wrote:

Device tree compiler does not recognize '-' in label name.  Instead,
'_' works fine.


Thanks, that does seem to be the case. I figured it myself when I added
them in actual .dts files but missed updating the bindings.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 1/5] mfd: mc13xxx: add device tree probe support

2011-11-29 Thread Rajendra Nayak

[]...

+};
+MODULE_DEVICE_TABLE(of, mc13xxx_dt_ids);
+
  static int mc13xxx_probe(struct spi_device *spi)
  {
+   struct device_node *np = spi->dev.of_node;
+   const struct of_device_id *of_id;
+   struct spi_driver *sdrv = to_spi_driver(spi->dev.driver);
struct mc13xxx *mc13xxx;
struct mc13xxx_platform_data *pdata = dev_get_platdata(&spi->dev);
enum mc13xxx_id id;
int ret;

-   if (!pdata) {
-   dev_err(&spi->dev, "invalid platform data\n");
-   return -EINVAL;
-   }
+   of_id = of_match_device(mc13xxx_dt_ids,&spi->dev);
+   if (of_id)
+   sdrv->id_table =&mc13xxx_device_id[(enum mc13xxx_id) 
of_id->data];

mc13xxx = kzalloc(sizeof(*mc13xxx), GFP_KERNEL);
if (!mc13xxx)
@@ -735,6 +787,15 @@ static int mc13xxx_probe(struct spi_device *spi)
if (ret)
goto err_mask;

+   mc13xxx->irq_gpio = of_get_named_gpio(np, "mc13xxx-irq-gpios", 0);
+   if (gpio_is_valid(mc13xxx->irq_gpio)) {
+   ret = gpio_request_one(mc13xxx->irq_gpio, GPIOF_IN,
+  "mc13xxx-irq");
+   if (ret)
+   goto err_mask;
+   spi->irq = gpio_to_irq(mc13xxx->irq_gpio);


This seems wrong, because its adding information about the irq actually
being a gpio within the driver (which was otherwise hidden by the board
files doing a gpio_to_irq()). What happens if on some device this is
actually hooked to an irq line instead of a gpio?
There should be a better way to do this using Device tree.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 3/4] omap-serial: Add minimal device tree support

2011-11-28 Thread Rajendra Nayak

On Monday 28 November 2011 07:09 PM, Rob Herring wrote:

On 11/22/2011 07:44 AM, Rajendra Nayak wrote:

Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smaridle bits and handling


typo: smartidle


remote wakeup and dynamic muxing.

Signed-off-by: Rajendra Nayak


Acked-by: Rob Herring


Thanks Rob, will fix the above typo.



Rob


---
  .../devicetree/bindings/serial/omap_serial.txt |   10 
  drivers/tty/serial/omap-serial.c   |   45 ++-
  2 files changed, 52 insertions(+), 3 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap2-uart" for OMAP2 controllers
+- compatible : should be "ti,omap3-uart" for OMAP3 controllers
+- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- ti,hwmods : Must be "uart", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
  #include
  #include
  #include
+#include

  #include
  #include
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, 
void *data)
return;
  }

+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+   struct omap_uart_port_info *omap_up_info;
+
+   omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+   if (!omap_up_info)
+   return NULL; /* out of memory */
+
+   of_property_read_u32(dev->of_node, "clock-frequency",
+   &omap_up_info->uartclk);
+   return omap_up_info;
+}
+
  static int serial_omap_probe(struct platform_device *pdev)
  {
struct uart_omap_port   *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;
int ret = -ENOSPC;

+   if (pdev->dev.of_node)
+   omap_up_info = of_get_uart_port_info(&pdev->dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(&pdev->dev, "no mem resource?\n");
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device 
*pdev)
up->port.regshift = 2;
up->port.fifosize = 64;
up->port.ops =&serial_omap_pops;
-   up->port.line = pdev->id;
-   sprintf(up->name, "OMAP UART%d", up->port.line);

+   if (pdev->dev.of_node)
+   up->port.line = of_alias_get_id(pdev->dev.of_node, "serial");
+   else
+   up->port.line = pdev->id;
+
+   if (up->port.line<  0) {
+   dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
+   up->port.line);
+   ret = -ENODEV;
+   goto err;
+   }
+
+   sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = ioremap(mem->start, resource_size(mem));
if (!up->port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;

-   if (!pdata->enable_wakeup)
+   if (!pdata || !pdata->enable_wakeup)
return 0;

if (pdata->get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = 
{
serial_omap_runtime_resume, NULL)
  };

+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+   { .compatible = "ti,omap2-uart" },
+   { .compatible = "ti,omap3-uart" },
+   { .compatible = "ti,omap4-uart" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
  static struct platform_driver serial_omap_driver = {
.probe  = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name   = DRIVER_NAME,
.pm =&serial_omap_dev_pm_ops,
+   .of_match_table = of_match_ptr(omap_serial_of_match),
},
  };





___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH v2 0/4] OMAP serial device tree support

2011-11-27 Thread Rajendra Nayak

On Sunday 27 November 2011 09:06 AM, Greg KH wrote:

On Tue, Nov 22, 2011 at 07:14:12PM +0530, Rajendra Nayak wrote:

v2 is based on the latest omap-serial runtime patches, which
can be found here[1]

The series passes minimal data that allows serial console
boot, with UART's initialised from device tree.
However some of low power support for UART and remote
wakeup needs more work.
Boot tested on OMAP4 panda and OMAP4 sdp boards.

Patches can be found here..
git://gitorious.org/omap-pm/linux.git for-dt/serial


What tree are these going to go through, some device tree one, or do you
want me to take the serial driver patches?


Hi Greg,

These patches have a dependency on the omap-serial runtime series.
So once that makes it in, through the serial driver tree, and once we
have the necessary Acks from the Device Tree maintainers on the relevant
patches from this series, these could go through the serial driver tree
as well.

thanks,
Rajendra



thanks,

greg k-h


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 0/4] OMAP serial device tree support

2011-11-22 Thread Rajendra Nayak
v2 is based on the latest omap-serial runtime patches, which
can be found here[1]

The series passes minimal data that allows serial console
boot, with UART's initialised from device tree.
However some of low power support for UART and remote
wakeup needs more work.
Boot tested on OMAP4 panda and OMAP4 sdp boards.

Patches can be found here..
git://gitorious.org/omap-pm/linux.git for-dt/serial

Changes in v2:
-1- Got rid of binding to define which uart is console
-2- Added checks to default clock speed to 48Mhz
-3- Added compatible for each OMAP family
-4- Used of_alias_get_id to populate port.line

regards,
Rajendra

[1] git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc2_uart_runtime

Rajendra Nayak (4):
  omap-serial: Get rid of all pdev->id usage
  omap-serial: Use default clock speed (48Mhz) if not specified
  omap-serial: Add minimal device tree support
  ARM: omap: pass minimal SoC/board data for UART from dt

 .../devicetree/bindings/serial/omap_serial.txt |   10 +++
 arch/arm/boot/dts/omap3.dtsi   |   31 
 arch/arm/boot/dts/omap4.dtsi   |   28 +++
 arch/arm/mach-omap2/board-generic.c|1 -
 drivers/tty/serial/omap-serial.c   |   80 +++
 5 files changed, 132 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 4/4] ARM: omap: pass minimal SoC/board data for UART from dt

2011-11-22 Thread Rajendra Nayak
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap3.dtsi|   31 +++
 arch/arm/boot/dts/omap4.dtsi|   28 
 arch/arm/mach-omap2/board-generic.c |1 -
 3 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..216c331 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
 / {
compatible = "ti,omap3430", "ti,omap3";
 
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart2;
+   serial2 = &uart3;
+   serial3 = &uart4;
+   };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +66,29 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+   uart1: serial@0x4806a000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart1";
+   clock-frequency = <4800>;
+   };
+
+   uart2: serial@0x4806c000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart2";
+   clock-frequency = <4800>;
+   };
+
+   uart3: serial@0x4902 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   };
+
+   uart4: serial@0x49042000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart4";
+   clock-frequency = <4800>;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..e8fe75f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
 
aliases {
+   serial0 = &uart1;
+   serial1 = &uart2;
+   serial2 = &uart3;
+   serial3 = &uart4;
};
 
cpus {
@@ -99,5 +103,29 @@
reg = <0x48241000 0x1000>,
  <0x48240100 0x0100>;
};
+
+   uart1: serial@0x4806a000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart1";
+   clock-frequency = <4800>;
+   };
+
+   uart2: serial@0x4806c000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart2";
+   clock-frequency = <4800>;
+   };
+
+   uart3: serial@0x4802 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   };
+
+   uart4: serial@0x4806e000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart4";
+   clock-frequency = <4800>;
+   };
};
 };
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index fb55fa3..bb72809 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -70,7 +70,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
 
-   omap_serial_init();
omap_sdrc_init(NULL, NULL);
 
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 1/4] omap-serial: Get rid of all pdev->id usage

2011-11-22 Thread Rajendra Nayak
With Device tree, pdev->id would no longer be Valid.
Hence get rid of all instances of its usage in the
driver. Device tree support for the driver is added
in subsequent patches.

Signed-off-by: Rajendra Nayak 
---
 drivers/tty/serial/omap-serial.c |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..a02cc9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -115,7 +115,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
 
-   dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
up->ier |= UART_IER_MSI;
@@ -418,7 +418,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port 
*port)
unsigned int ret = 0;
 
pm_runtime_get_sync(&up->pdev->dev);
-   dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->port.line);
spin_lock_irqsave(&up->port.lock, flags);
ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
spin_unlock_irqrestore(&up->port.lock, flags);
@@ -436,7 +436,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port 
*port)
status = check_modem_status(up);
pm_runtime_put(&up->pdev->dev);
 
-   dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line);
 
if (status & UART_MSR_DCD)
ret |= TIOCM_CAR;
@@ -454,7 +454,7 @@ static void serial_omap_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char mcr = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->port.line);
if (mctrl & TIOCM_RTS)
mcr |= UART_MCR_RTS;
if (mctrl & TIOCM_DTR)
@@ -478,7 +478,7 @@ static void serial_omap_break_ctl(struct uart_port *port, 
int break_state)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
spin_lock_irqsave(&up->port.lock, flags);
if (break_state == -1)
@@ -504,7 +504,7 @@ static int serial_omap_startup(struct uart_port *port)
if (retval)
return retval;
 
-   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -545,7 +545,7 @@ static int serial_omap_startup(struct uart_port *port)
0);
init_timer(&(up->uart_dma.rx_timer));
up->uart_dma.rx_timer.function = serial_omap_rxdma_poll;
-   up->uart_dma.rx_timer.data = up->pdev->id;
+   up->uart_dma.rx_timer.data = up->port.line;
/* Currently the buffer size is 4KB. Can increase it */
up->uart_dma.rx_buf = dma_alloc_coherent(NULL,
up->uart_dma.rx_buf_size,
@@ -573,7 +573,7 @@ static void serial_omap_shutdown(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -883,7 +883,7 @@ serial_omap_set_termios(struct uart_port *port, struct 
ktermios *termios,
 
spin_unlock_irqrestore(&up->port.lock, flags);
pm_runtime_put(&up->pdev->dev);
-   dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line);
 }
 
 static void
@@ -893,7 +893,7 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char efr;
 
-   dev_dbg(up->port.d

[PATCH v2 3/4] omap-serial: Add minimal device tree support

2011-11-22 Thread Rajendra Nayak
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smaridle bits and handling
remote wakeup and dynamic muxing.

Signed-off-by: Rajendra Nayak 
---
 .../devicetree/bindings/serial/omap_serial.txt |   10 
 drivers/tty/serial/omap-serial.c   |   45 ++-
 2 files changed, 52 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap2-uart" for OMAP2 controllers
+- compatible : should be "ti,omap3-uart" for OMAP3 controllers
+- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- ti,hwmods : Must be "uart", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, 
void *data)
return;
 }
 
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+   struct omap_uart_port_info *omap_up_info;
+
+   omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+   if (!omap_up_info)
+   return NULL; /* out of memory */
+
+   of_property_read_u32(dev->of_node, "clock-frequency",
+&omap_up_info->uartclk);
+   return omap_up_info;
+}
+
 static int serial_omap_probe(struct platform_device *pdev)
 {
struct uart_omap_port   *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;
int ret = -ENOSPC;
 
+   if (pdev->dev.of_node)
+   omap_up_info = of_get_uart_port_info(&pdev->dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(&pdev->dev, "no mem resource?\n");
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device 
*pdev)
up->port.regshift = 2;
up->port.fifosize = 64;
up->port.ops = &serial_omap_pops;
-   up->port.line = pdev->id;
-   sprintf(up->name, "OMAP UART%d", up->port.line);
 
+   if (pdev->dev.of_node)
+   up->port.line = of_alias_get_id(pdev->dev.of_node, "serial");
+   else
+   up->port.line = pdev->id;
+
+   if (up->port.line < 0) {
+   dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
+   up->port.line);
+   ret = -ENODEV;
+   goto err;
+   }
+
+   sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = ioremap(mem->start, resource_size(mem));
if (!up->port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
 
-   if (!pdata->enable_wakeup)
+   if (!pdata || !pdata->enable_wakeup)
return 0;
 
if (pdata->get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = 
{
serial_omap_runtime_resume, NULL)
 };
 
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+   { .compatible = "ti,omap2-uart" },
+   { .compatible = "ti,omap3-uart" },
+   { .compatible = "ti,omap4-uart" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
 static struct platform_driver serial_omap_driver = {
.probe  = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name   = DRIVER_NAME,
.pm = &serial_omap_dev_pm_ops,
+   .of_match_table = of_match_ptr(omap_serial_of_match),
},
 };
 
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v2 2/4] omap-serial: Use default clock speed (48Mhz) if not specified

2011-11-22 Thread Rajendra Nayak
Use a default clock speed of 48Mhz, instead of ending up with 0,
if platforms fail to specify a valid clock speed.

Signed-off-by: Rajendra Nayak 
---
 drivers/tty/serial/omap-serial.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a02cc9f..f14b9c5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,8 @@
 #include 
 #include 
 
+#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+
 static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
 
 /* Forward declaration of functions */
@@ -1386,6 +1388,11 @@ static int serial_omap_probe(struct platform_device 
*pdev)
 
up->port.flags = omap_up_info->flags;
up->port.uartclk = omap_up_info->uartclk;
+   if (!up->port.uartclk) {
+   up->port.uartclk = DEFAULT_CLK_SPEED;
+   dev_warn(&pdev->dev, "No clock speed specified: using default:"
+   "%d\n", DEFAULT_CLK_SPEED);
+   }
up->uart_dma.uart_base = mem->start;
up->errata = omap_up_info->errata;
 
-- 
1.7.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


[PATCH v5 3/4] regulator: pass additional of_node to regulator_register()

2011-11-18 Thread Rajendra Nayak
With device tree support for regulators, its needed that the
regulator_dev->dev device has the right of_node attached.
To be able to do this add an additional parameter to the
regulator_register() api, wherein the dt-adapted driver can
then pass this additional info onto the regulator core.

Signed-off-by: Rajendra Nayak 
Acked-by: Mark Brown 
Cc: Michael Hennerich 
Cc: Ian Lartey 
Cc: Dimitris Papastamos 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Wolfram Sang 
Cc: Zeng Zhaoming 
Cc: Dan Carpenter 
---
 drivers/regulator/88pm8607.c   |2 +-
 drivers/regulator/aat2870-regulator.c  |2 +-
 drivers/regulator/ab3100.c |2 +-
 drivers/regulator/ab8500.c |2 +-
 drivers/regulator/ad5398.c |2 +-
 drivers/regulator/bq24022.c|2 +-
 drivers/regulator/core.c   |3 ++-
 drivers/regulator/da903x.c |2 +-
 drivers/regulator/db8500-prcmu.c   |2 +-
 drivers/regulator/dummy.c  |2 +-
 drivers/regulator/fixed.c  |2 +-
 drivers/regulator/isl6271a-regulator.c |2 +-
 drivers/regulator/lp3971.c |2 +-
 drivers/regulator/lp3972.c |2 +-
 drivers/regulator/max1586.c|2 +-
 drivers/regulator/max8649.c|2 +-
 drivers/regulator/max8660.c|2 +-
 drivers/regulator/max8925-regulator.c  |2 +-
 drivers/regulator/max8952.c|2 +-
 drivers/regulator/max8997.c|2 +-
 drivers/regulator/max8998.c|2 +-
 drivers/regulator/mc13783-regulator.c  |2 +-
 drivers/regulator/mc13892-regulator.c  |2 +-
 drivers/regulator/pcap-regulator.c |2 +-
 drivers/regulator/pcf50633-regulator.c |2 +-
 drivers/regulator/tps6105x-regulator.c |3 ++-
 drivers/regulator/tps65023-regulator.c |2 +-
 drivers/regulator/tps6507x-regulator.c |2 +-
 drivers/regulator/tps6524x-regulator.c |2 +-
 drivers/regulator/tps6586x-regulator.c |2 +-
 drivers/regulator/tps65910-regulator.c |2 +-
 drivers/regulator/tps65912-regulator.c |2 +-
 drivers/regulator/twl-regulator.c  |2 +-
 drivers/regulator/wm831x-dcdc.c|8 
 drivers/regulator/wm831x-isink.c   |2 +-
 drivers/regulator/wm831x-ldo.c |6 +++---
 drivers/regulator/wm8350-regulator.c   |2 +-
 drivers/regulator/wm8400-regulator.c   |2 +-
 drivers/regulator/wm8994-regulator.c   |2 +-
 include/linux/regulator/driver.h   |2 +-
 sound/soc/codecs/sgtl5000.c|2 +-
 41 files changed, 48 insertions(+), 46 deletions(-)

diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index ca0d608..df33530 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -427,7 +427,7 @@ static int __devinit pm8607_regulator_probe(struct 
platform_device *pdev)
 
/* replace driver_data with info */
info->regulator = regulator_register(&info->desc, &pdev->dev,
-pdata, info);
+pdata, info, NULL);
if (IS_ERR(info->regulator)) {
dev_err(&pdev->dev, "failed to register regulator %s\n",
info->desc.name);
diff --git a/drivers/regulator/aat2870-regulator.c 
b/drivers/regulator/aat2870-regulator.c
index 5abeb3a..07e98ec 100644
--- a/drivers/regulator/aat2870-regulator.c
+++ b/drivers/regulator/aat2870-regulator.c
@@ -188,7 +188,7 @@ static int aat2870_regulator_probe(struct platform_device 
*pdev)
ri->pdev = pdev;
 
rdev = regulator_register(&ri->desc, &pdev->dev,
- pdev->dev.platform_data, ri);
+ pdev->dev.platform_data, ri, NULL);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "Failed to register regulator %s\n",
ri->desc.name);
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index 585e494..042271a 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -634,7 +634,7 @@ static int __devinit ab3100_regulators_probe(struct 
platform_device *pdev)
rdev = regulator_register(&ab3100_regulator_desc[i],
  &pdev->dev,
  &plfdata->reg_constraints[i],
- reg);
+ reg, NULL);
 
if (IS_ERR(rdev)) {
err = PTR_ERR(rdev);
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 6e1ae69..e91b8dd 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -822,7 +822,7 @@ static __devinit int ab8500_regulator_probe(struct 
platform_device *pdev)
 
/* register 

[PATCH v5 4/4] regulator: map consumer regulator based on device tree

2011-11-18 Thread Rajendra Nayak
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.

For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator2>;
};

The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.

of_get_regulator() extracts the regulator node for a given
device, based on the supply name.

Use it to look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.

Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.

Signed-off-by: Rajendra Nayak 
Acked-by: Grant Likely 
Acked-by: Mark Brown 
---
 drivers/regulator/core.c |   79 --
 include/linux/regulator/driver.h |2 +
 2 files changed, 69 insertions(+), 12 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8b01eb0..9867ebc 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -132,6 +134,33 @@ static struct regulator *get_device_regulator(struct 
device *dev)
return NULL;
 }
 
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+static struct device_node *of_get_regulator(struct device *dev, const char 
*supply)
+{
+   struct device_node *regnode = NULL;
+   char prop_name[32]; /* 32 is max size of property name */
+
+   dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+
+   snprintf(prop_name, 32, "%s-supply", supply);
+   regnode = of_parse_phandle(dev->of_node, prop_name, 0);
+
+   if (!regnode) {
+   dev_warn(dev, "%s property in node %s references invalid 
phandle",
+   prop_name, dev->of_node->full_name);
+   return NULL;
+   }
+   return regnode;
+}
+
 /* Platform voltage constraint check */
 static int regulator_check_voltage(struct regulator_dev *rdev,
   int *min_uV, int *max_uV)
@@ -1148,6 +1177,30 @@ static int _regulator_get_enable_time(struct 
regulator_dev *rdev)
return rdev->desc->ops->enable_time(rdev);
 }
 
+static struct regulator_dev *regulator_dev_lookup(struct device *dev,
+const char *supply)
+{
+   struct regulator_dev *r;
+   struct device_node *node;
+
+   /* first do a dt based lookup */
+   if (dev && dev->of_node) {
+   node = of_get_regulator(dev, supply);
+   if (node)
+   list_for_each_entry(r, ®ulator_list, list)
+   if (r->dev.parent &&
+   node == r->dev.of_node)
+   return r;
+   }
+
+   /* if not found, try doing it non-dt way */
+   list_for_each_entry(r, ®ulator_list, list)
+   if (strcmp(rdev_get_name(r), supply) == 0)
+   return r;
+
+   return NULL;
+}
+
 /* Internal regulator request function */
 static struct regulator *_regulator_get(struct device *dev, const char *id,
int exclusive)
@@ -1168,6 +1221,10 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
 
mutex_lock(®ulator_list_mutex);
 
+   rdev = regulator_dev_lookup(dev, id);
+   if (rdev)
+   goto found;
+
list_for_each_entry(map, ®ulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map->dev_name &&
@@ -2642,6 +2699,7 @@ struct regulator_dev *regulator_register(struct 
regulator_desc *regulator_desc,
static atomic_t regulator_no = ATOMIC_INIT(0);
struct regulator_dev *rdev;
int ret, i;
+   const char *supply = NULL;
 
if (regulator_desc == NULL)
return ERR_PTR(-EINVAL);
@@ -2718,21 +2776,18 @@ struct regulator_dev *regulator_register(struct 
regulator_desc *regulator_desc,
if (ret < 0)
goto scrub;
 
-   if (init_data->supply_regulator) {
+   if (init_

[PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

2011-11-18 Thread Rajendra Nayak
The helper routine is meant to be used by the regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Similarly the regulator<-->parent/supply mapping is handled in
subsequent patches.

Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.

Some of the regulator properties which are linux and board specific,
are left out since its not clear if they can
be in someway embedded into the kernel or passed in from DT.
They will be revisited later.

Signed-off-by: Rajendra Nayak 
---
 .../devicetree/bindings/regulator/regulator.txt|   54 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/of_regulator.c   |   81 
 include/linux/regulator/of_regulator.h |   20 +
 4 files changed, 156 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
 create mode 100644 drivers/regulator/of_regulator.c
 create mode 100644 include/linux/regulator/of_regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..82bef20
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,54 @@
+Voltage/Current Regulators
+
+Optional properties:
+- regulator-name: A string used as a descriptive name for regulator outputs
+- regulator-min-microvolt: smallest voltage consumers may set
+- regulator-max-microvolt: largest voltage consumers may set
+- regulator-microvolt-offset: Offset applied to voltages to compensate for 
voltage drops
+- regulator-min-microamp: smallest current consumers may set
+- regulator-max-microamp: largest current consumers may set
+- regulator-always-on: boolean, regulator should never be disabled
+- regulator-boot-on: bootloader/firmware enabled regulator
+- -supply: phandle to the parent supply/regulator node
+
+Example:
+
+   xyzreg: regulator@0 {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <250>;
+   regulator-always-on;
+   vin-supply = <&vin>;
+   };
+
+Regulator Consumers:
+Consumer nodes can reference one or more of its supplies/
+regulators using the below bindings.
+
+- -supply: phandle to the regulator node
+
+These are the same bindings that a regulator in the above
+example used to reference its own supply, in which case
+its just seen as a special case of a regulator being a
+consumer itself.
+
+Example of a consumer device node (mmc) referencing two
+regulators (twl-reg1 and twl-reg2),
+
+   twl-reg1: regulator@0 {
+   ...
+   ...
+   ...
+   };
+
+   twl-reg2: regulator@1 {
+   ...
+   ...
+   ...
+   };
+
+   mmc: mmc@0x0 {
+   ...
+   ...
+   vmmc-supply = <&twl-reg1>;
+   vmmcaux-supply = <&twl-reg2>;
+   };
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 93a6318..c75a522 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -4,6 +4,7 @@
 
 
 obj-$(CONFIG_REGULATOR) += core.o dummy.o
+obj-$(CONFIG_OF) += of_regulator.o
 obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
 obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
 obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
new file mode 100644
index 000..76673c7
--- /dev/null
+++ b/drivers/regulator/of_regulator.c
@@ -0,0 +1,81 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+static void of_get_regulation_constraints(struct device_node *np,
+   struct regulator_init_data **init_data)
+{
+   const __be32 *min_uV, *max_uV, *uV_offset;
+   const __be32 *min_uA, *max_uA;
+   struct regulation_constraints *constraints = &(*init_data)->constraints;
+
+   constraints->name = of_get_property(np, "regulator-name", NULL);
+
+   min_uV = of_get_property(np, "regulator-min-microvolt", NULL);
+   if (min_uV)
+   constraints->min_uV = be32_to_cpu(*min_uV)

[PATCH v5 2/4] regulator: adapt fixed regulator driver to dt

2011-11-18 Thread Rajendra Nayak
The fixed regulator driver uses of_get_fixed_voltage_config()
to extract fixed_voltage_config structure contents from device tree.

Also add documenation for additional bindings for fixed
regulators that can be passed through dt.

Signed-off-by: Rajendra Nayak 
---
 .../bindings/regulator/fixed-regulator.txt |   29 +
 drivers/regulator/fixed.c  |   65 
 2 files changed, 94 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/fixed-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt 
b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
new file mode 100644
index 000..9cf57fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -0,0 +1,29 @@
+Fixed Voltage regulators
+
+Required properties:
+- compatible: Must be "regulator-fixed";
+
+Optional properties:
+- gpio: gpio to use for enable control
+- startup-delay-us: startup time in microseconds
+- enable-active-high: Polarity of GPIO is Active high
+If this property is missing, the default assumed is Active low.
+
+Any property defined as part of the core regulator
+binding, defined in regulator.txt, can also be used.
+However a fixed voltage regulator is expected to have the
+regulator-min-microvolt and regulator-max-microvolt
+to be the same.
+
+Example:
+
+   abc: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-supply";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = <&gpio1 16 0>;
+   startup-delay-us = <7>;
+   enable-active-high;
+   regulator-boot-on
+   };
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 21ecf21..0650856 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -27,6 +27,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 struct fixed_voltage_data {
struct regulator_desc desc;
@@ -38,6 +42,53 @@ struct fixed_voltage_data {
bool is_enabled;
 };
 
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
+{
+   struct fixed_voltage_config *config;
+   struct device_node *np = dev->of_node;
+   const __be32 *delay;
+   struct regulator_init_data *init_data;
+
+   config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config),
+GFP_KERNEL);
+   if (!config)
+   return NULL;
+
+   config->init_data = of_get_regulator_init_data(dev);
+   init_data = config->init_data;
+
+   config->supply_name = init_data->constraints.name;
+   if (init_data->constraints.min_uV == init_data->constraints.max_uV) {
+   config->microvolts = init_data->constraints.min_uV;
+   } else {
+   dev_err(dev,
+"Fixed regulator specified with variable voltages\n");
+   return NULL;
+   }
+
+   if (init_data->constraints.boot_on)
+   config->enabled_at_boot = true;
+
+   config->gpio = of_get_named_gpio(np, "gpio", 0);
+   delay = of_get_property(np, "startup-delay-us", NULL);
+   if (delay)
+   config->startup_delay = be32_to_cpu(*delay);
+
+   if (of_find_property(np, "enable-active-high", NULL))
+   config->enable_high = true;
+
+   return config;
+}
+
 static int fixed_voltage_is_enabled(struct regulator_dev *dev)
 {
struct fixed_voltage_data *data = rdev_get_drvdata(dev);
@@ -109,6 +160,9 @@ static int __devinit reg_fixed_voltage_probe(struct 
platform_device *pdev)
struct fixed_voltage_data *drvdata;
int ret;
 
+   if (pdev->dev.of_node)
+   config = of_get_fixed_voltage_config(&pdev->dev);
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(&pdev->dev, "Failed to allocate device data\n");
@@ -217,12 +271,23 @@ static int __devexit reg_fixed_voltage_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+   { .compatible = "regulator-fixed", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_o

[PATCH v5 0/4] Device tree support for regulators

2011-11-18 Thread Rajendra Nayak
v5 is based on 3.2-rc2 and has the following changes
-1- Used microvolt/microamp in bindings instead of uV/uA
-2- Added more documentation surrounding regulator-consumer
mapping in the core bindings
-3- Dropped CONFIG_OF_REGULATOR and use just CONFIG_OF
-4- Reused core regulator bindings on Fixed regulator bindings
-5- Corrected the gpio binding for Fixed regulator

The patches can be found here:
git://gitorious.org/omap-pm/linux.git for-dt/regulator

For the first 2 patches (1/4 and 2/4) I have dropped
Acks from Mark, since they have changed to some extent
from the last post and retained the Acks recieved on the
last 2 patches (3/4 and 4/4) as they remain unchanged.

regards,
Rajendra

Rajendra Nayak (4):
  regulator: helper routine to extract regulator_init_data
  regulator: adapt fixed regulator driver to dt
  regulator: pass additional of_node to regulator_register()
  regulator: map consumer regulator based on device tree

 .../bindings/regulator/fixed-regulator.txt |   29 +++
 .../devicetree/bindings/regulator/regulator.txt|   54 +
 drivers/regulator/88pm8607.c   |2 +-
 drivers/regulator/Makefile |1 +
 drivers/regulator/aat2870-regulator.c  |2 +-
 drivers/regulator/ab3100.c |2 +-
 drivers/regulator/ab8500.c |2 +-
 drivers/regulator/ad5398.c |2 +-
 drivers/regulator/bq24022.c|2 +-
 drivers/regulator/core.c   |   82 ---
 drivers/regulator/da903x.c |2 +-
 drivers/regulator/db8500-prcmu.c   |2 +-
 drivers/regulator/dummy.c  |2 +-
 drivers/regulator/fixed.c  |   62 +++-
 drivers/regulator/isl6271a-regulator.c |2 +-
 drivers/regulator/lp3971.c |2 +-
 drivers/regulator/lp3972.c |2 +-
 drivers/regulator/max1586.c|2 +-
 drivers/regulator/max8649.c|2 +-
 drivers/regulator/max8660.c|2 +-
 drivers/regulator/max8925-regulator.c  |2 +-
 drivers/regulator/max8952.c|2 +-
 drivers/regulator/max8997.c|2 +-
 drivers/regulator/max8998.c|2 +-
 drivers/regulator/mc13783-regulator.c  |2 +-
 drivers/regulator/mc13892-regulator.c  |2 +-
 drivers/regulator/of_regulator.c   |   81 +++
 drivers/regulator/pcap-regulator.c |2 +-
 drivers/regulator/pcf50633-regulator.c |2 +-
 drivers/regulator/tps6105x-regulator.c |3 +-
 drivers/regulator/tps65023-regulator.c |2 +-
 drivers/regulator/tps6507x-regulator.c |2 +-
 drivers/regulator/tps6524x-regulator.c |2 +-
 drivers/regulator/tps6586x-regulator.c |2 +-
 drivers/regulator/tps65910-regulator.c |2 +-
 drivers/regulator/tps65912-regulator.c |2 +-
 drivers/regulator/twl-regulator.c  |2 +-
 drivers/regulator/wm831x-dcdc.c|8 +-
 drivers/regulator/wm831x-isink.c   |2 +-
 drivers/regulator/wm831x-ldo.c |6 +-
 drivers/regulator/wm8350-regulator.c   |2 +-
 drivers/regulator/wm8400-regulator.c   |2 +-
 drivers/regulator/wm8994-regulator.c   |2 +-
 include/linux/regulator/driver.h   |4 +-
 include/linux/regulator/of_regulator.h |   20 +
 sound/soc/codecs/sgtl5000.c|2 +-
 46 files changed, 362 insertions(+), 58 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
 create mode 100644 drivers/regulator/of_regulator.c
 create mode 100644 include/linux/regulator/of_regulator.h

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

2011-11-17 Thread Rajendra Nayak

[]...


Why do we have to idle -> enable? The module is already enabled, isn't
it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?


Yes, now that I read it, it does sound confusing. I should have at-least
read it once before I picked it from serial.c

But anyway, here's what the problem is.

I feel its partly to do with the inability of hwmod to handle some
modules which are left enabled post a setup, due to the
'HWMOD_INIT_NO_IDLE' flag set.
Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post
a setup. Now when a driver for such devices/modules tries to enable the
module the first time, hwmod throws up a big WARN stating the hwmod is
already in an enabled state.


OK, now, that makes sense :-)
We have hwmod in ENABLE state whereas the omap_device is still in IDLE
or even DISABLE.


Right.




[uart used as console is one such module, which cannot be idled post a
setup by hwmod]

If hwmod could be made in some way intelligent enough to know that the
module is in enabled state because of the 'HWMOD_INIT_NO_IDLE' itself,
a lot of this hackery might not be needed at all.


Fully agree, the fmwk should handle that.


Simplest way to do it could be to just add another intermediate state,
something like '_HWMOD_STATE_ENABLED_AT_INIT'.
I will post a patch for this, see if you like it being handled that way.


That seems to be good. I'm just wondering if we need to introduce a new
state for that or use a dedicated flag.
My concern is just that we will have two flavors of HWMOD_STATE_ENABLED
that we will have to check in various places in the hwmod core code.

Maybe that's not such a big deal. Go ahead, and we will see how it looks
like.


I initially thought I could do that using the existing flag itself, but
the key is that its needed only the first time a enable is done on the
hwmod. The rest of the state handling remains the same.
I just posted the patch, so that should make it more clear.




The other part of the problem is also with the inability to hook up
'custom' omap_device_pm_latency for omap devices created from DT.
Maybe a lot of such cases which need custom activate/deactivate
functions might have to be handled in some way in the framework
itself like the one above.


For the moment, it looks like only the serial is requiring such custom


yes.


stuff, but anyway, we should have a mechanism to allow that...

Thanks,
Benoit



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 3/3] ARM: omap: pass minimal SoC/board data for UART from dt

2011-11-17 Thread Rajendra Nayak

On Thursday 17 November 2011 06:34 AM, Rob Herring wrote:

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:

Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Signed-off-by: Rajendra Nayak
---
  arch/arm/boot/dts/omap3-beagle.dts  |   17 +
  arch/arm/boot/dts/omap3.dtsi|   27 +++
  arch/arm/boot/dts/omap4-panda.dts   |   17 +
  arch/arm/boot/dts/omap4-sdp.dts |   17 +
  arch/arm/boot/dts/omap4.dtsi|   24 
  arch/arm/mach-omap2/board-generic.c |1 -
  6 files changed, 102 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..4c8f11e 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,20 @@
reg =<0x8000 0x2000>; /* 512 MB */
};
  };
+
+&uart1 {
+   clock-frequency =<4800>;
+};
+
+&uart2 {
+   clock-frequency =<4800>;
+};
+
+&uart3 {
+   ti,console_hwmod;
+   clock-frequency =<4800>;
+};
+
+&uart4 {
+   clock-frequency =<4800>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..ea591c5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
  / {
compatible = "ti,omap3430", "ti,omap3";

+   aliases {
+   uart1 =&uart1;
+   uart2 =&uart2;
+   uart3 =&uart3;
+   uart4 =&uart4;
+   };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +66,25 @@
interrupt-controller;
#interrupt-cells =<1>;
};
+
+   uart1: uart@1 {


Use the generic name serial and the address: uart1: serial@1234abcd


ok.




+   compatible = "ti,omap-uart";
+   ti,hwmods = "uart1";
+   };
+
+   uart2: uart@2 {
+   compatible = "ti,omap-uart";
+   ti,hwmods = "uart2";
+   };
+
+   uart3: uart@3 {
+   compatible = "ti,omap-uart";
+   ti,hwmods = "uart3";
+   };
+
+   uart4: uart@4 {
+   compatible = "ti,omap-uart";
+   ti,hwmods = "uart4";
+   };
};
  };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index c702657..aa65449 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,20 @@
reg =<0x8000 0x4000>; /* 1 GB */
};
  };
+
+&uart1 {
+   clock-frequency =<4800>;
+};
+
+&uart2 {
+   clock-frequency =<4800>;
+};
+
+&uart3 {
+   ti,console_hwmod;
+   clock-frequency =<4800>;
+};
+
+&uart4 {
+   clock-frequency =<4800>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..524f5bf 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,3 +27,20 @@
reg =<0x8000 0x4000>; /* 1 GB */
};
  };
+
+&uart1 {
+   clock-frequency =<4800>;
+};
+
+&uart2 {
+   clock-frequency =<4800>;
+};
+
+&uart3 {
+   ti,console_hwmod;
+   clock-frequency =<4800>;
+};
+
+&uart4 {
+   clock-frequency =<4800>;


It doesn't seem that this frequency ever varies and is likely to be
replaced with clock bindings, so maybe just put it in the dtsi files.


sure, will do.

regards,
Rajendra


Rob



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 2/3] omap-serial: Add minimal device tree support

2011-11-17 Thread Rajendra Nayak

On Wednesday 16 November 2011 08:29 PM, Rob Herring wrote:

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:

Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smaridle bits and handling
remote wakeup and dynamic muxing.

Signed-off-by: Rajendra Nayak
---
  .../devicetree/bindings/serial/omap_serial.txt |9 +
  drivers/tty/serial/omap-serial.c   |   37 +++-
  2 files changed, 45 insertions(+), 1 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..bf6d631
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,9 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap-uart"


This seems too generic. There are no h/w differences in the uart since
the 1st OMAP1 device?


This driver supports only OMAP2+ devices, and there doesn't seem to be
really much difference. But I might have to re-look, in case I need to
handle some silicon errata.




+- ti,hwmods : Must be "uart", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
+- ti,console_hwmod : boolean, UART used as debug console
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e1c8527..e3419c6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
  #include
  #include
  #include
+#include

  #include
  #include
@@ -1322,6 +1323,22 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, 
void *data)
return;
  }

+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+   struct omap_uart_port_info *omap_up_info;
+
+   omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+   if (!omap_up_info)
+   return NULL; /* out of memory */
+
+   of_property_read_u32(dev->of_node, "clock-frequency",
+   &(*omap_up_info).uartclk);


&omap_up_info->uartclk

You want 0 to be the default freq?


good point, I need to handle this better.




+
+   return omap_up_info;
+}
+
+static atomic_t omap_uart_next_id = ATOMIC_INIT(0);
+
  static int serial_omap_probe(struct platform_device *pdev)
  {
struct uart_omap_port   *up;
@@ -1329,6 +1346,11 @@ static int serial_omap_probe(struct platform_device 
*pdev)
struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;
int ret = -ENOSPC;

+   if (pdev->dev.of_node) {
+   omap_up_info = of_get_uart_port_info(&pdev->dev);
+   pdev->id = atomic_inc_return(&omap_uart_next_id) - 1;


I don't think a driver changing this value is a good idea. Look at other
serial drivers like iMX for how they use aliases.


Well, I did lookup, but maybe the wrong one. I looked up the msm serial
which added DT support not too long ago and does the exact same thing.




+   }
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(&pdev->dev, "no mem resource?\n");
@@ -1523,7 +1545,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;

-   if (!pdata->enable_wakeup)
+   if (!pdata || !pdata->enable_wakeup)
return 0;

if (pdata->get_context_loss_count)
@@ -1582,12 +1604,25 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = 
{
serial_omap_runtime_resume, NULL)
  };

+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+   {
+   .compatible = "ti,omap-uart",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#else
+#define omap_serial_of_match NULL
+#endif
+
  static struct platform_driver serial_omap_driver = {
.probe  = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name   = DRIVER_NAME,
.pm =&serial_omap_dev_pm_ops,
+   .of_match_table = omap_serial_of_match,


Use of_match_ptr and get rid of the #else


Ok, thanks.
Rajendra


Rob


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

2011-11-16 Thread Rajendra Nayak

Hi Rob,

On Wednesday 16 November 2011 08:20 PM, Rob Herring wrote:
[]...


diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,7 @@ Required properties:
  Optional properties:
  - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console device



This doesn't seem right. Which console is not a h/w property. Why can't
you use aliases like other platforms are doing?


After thinking of this some more, I figured its more of a hwmod problem
to be solved, than with being able to identify which console.
Will post a separate patch to fix it up in hmwod and drop this from the
DT series.

Thanks for the review.

regards,
Rajendra



Also, it's not clear in the documentation where this (and
ti,no_idle_on_suspend) should go in the DT. Both seem like they should
be kernel cmdline params.

Rob


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

2011-11-16 Thread Rajendra Nayak

[...]

+static int omap_console_hwmod_enable(struct omap_device *od)
+{
+   console_lock();
+   /*
+* For early console we prevented hwmod reset and idle


A period is missing. Or maybe it should a comma with not capital letter.


+* So before we enable the uart clocks idle the console
+* uart clocks, then enable back the console uart hwmod.
+*/
+   omap_hwmod_idle(od->hwmods[0]);
+   omap_hwmod_enable(od->hwmods[0]);


Why do we have to idle ->  enable? The module is already enabled, isn't it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?


Yes, now that I read it, it does sound confusing. I should have at-least
read it once before I picked it from serial.c

But anyway, here's what the problem is.

I feel its partly to do with the inability of hwmod to handle some
modules which are left enabled post a setup, due to the
'HWMOD_INIT_NO_IDLE' flag set.
Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post
a setup. Now when a driver for such devices/modules tries to enable the
module the first time, hwmod throws up a big WARN stating the hwmod is
already in an enabled state.
[uart used as console is one such module, which cannot be idled post a
setup by hwmod]

If hwmod could be made in some way intelligent enough to know that the
module is in enabled state because of the 'HWMOD_INIT_NO_IDLE' itself,
a lot of this hackery might not be needed at all.
Simplest way to do it could be to just add another intermediate state,
something like  '_HWMOD_STATE_ENABLED_AT_INIT'.
I will post a patch for this, see if you like it being handled that way.

The other part of the problem is also with the inability to hook up
'custom' omap_device_pm_latency for omap devices created from DT.
Maybe a lot of such cases which need custom activate/deactivate
functions might have to be handled in some way in the framework
itself like the one above.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss


  1   2   3   >