Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion

2014-03-03 Thread Tero Kristo

On 02/28/2014 08:33 PM, Tony Lindgren wrote:

* Tero Kristo  [140228 10:21]:


Hmm, some clock node is broken, might be missing a name or parent
name for some reason. Can you try to boot with DEBUG enabled so you
get pr_debug:s out and see which clock is being initialized during
the crash?


...
[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: 
core_d18_ck
[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: 
vlynq_mux_fck
[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: 
vlynq_fck
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address 
...

We really should be registering the clocks lazily as needed BTW. That
leaves out the dependency to DEBUG_LL for seeing any kind of decent
error messages during the booting.

Regards,

Tony



Hey Tony,

Can you retry with the branch? I just pushed one patch there, seems the 
parents for the vlynq_mux_fck were somewhat broken (there are holes in 
the valid mux values list, which hasn't happened with any other 
mux-clock so far.)


If this works, I will rework the series a bit and send v2 out. 
Alternatively I need to add extra debug info.


-Tero

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


Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver

2014-03-03 Thread Archit Taneja

Hi,

On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote:

Hi Archit!

On 03/03/2014 08:33 AM, Archit Taneja wrote:

Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.

For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.

Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for this purpose.

Some standard crop parameter checks are done in __vpe_try_crop().


Please use the selection ops instead: if you implement cropping with those then 
you'll
support both the selection API and the old cropping API will be implemented by 
the v4l2
core using the selection ops. Two for the price of one...




Thanks for the feedback. I'll use selection ops here.

Archit


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


Re: [PATCH v2 3/8] ARM: dts: omap3-overo: Use complete poweroff

2014-03-03 Thread Florian Vaussard
On 02/27/2014 10:07 PM, Nishanth Menon wrote:
> +devicetree list.
> 
> On 02/27/2014 02:48 PM, Florian Vaussard wrote:
>> On 02/27/2014 09:38 PM, Nishanth Menon wrote:
>>> On 02/27/2014 02:30 PM, Florian Vaussard wrote:
 Currently, the TWL4030 PMIC does not completely poweroff the processor.
 Commit b0fc1da4d0359d3cce8f12e0f014aed0704ae202 introduced the necessary
 binding to do this, so use it.

 Signed-off-by: Florian Vaussard 
 ---
  arch/arm/boot/dts/omap3-overo.dtsi | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
 b/arch/arm/boot/dts/omap3-overo.dtsi
 index aea64c0..018e1e0 100644
 --- a/arch/arm/boot/dts/omap3-overo.dtsi
 +++ b/arch/arm/boot/dts/omap3-overo.dtsi
 @@ -73,6 +73,11 @@
codec {
};
};
 +
 +  twl_power: power {
 +  compatible = "ti,twl4030-power";
 +  ti,use_poweroff;
 +  };
};
  };
  

>>> Urrgh.. this slipped past.. :(
>>>
>>> ti,system-power-controller is traditionally used for other PMICs from
>>> TI to indicate that poweroff functionality will be provided by the
>>> PMIC driver. similar approach is taken by Maxim as well.. I know the
>>> commit introducing the binding has been around for long, but
>>> considering that we do not have a single dts using this yet, should we
>>> consider adding "ti,system-power-controller"(as against removing
>>> ti,use_poweroff - so that older down stream dtbs still work) and using
>>> it in the new code?
>>>
>>
>> It does make sense, so I am not against it. My only concern is that I
>> find the name to be slightly less easy to understand, but I can live
>> with it :-)
> :)
> 
>>
>> I do not remember if DT maintainers came up with a clear policy to
>> deprecate a binding.
> I dont think we can depreciate a binding [1] - as you mentioned -
> renaming the property is probably what is appropriate, but introducing
> a new one which has the same behavior as the old one does'nt seem
> covered either.. considering potential downstream kernel usage, I'd
> suggest additional property inline with today's convention.
> 

Ok, so I will drop this patch from the series, so that the other patches
can hopefully go into 3.15. I will address this issue separately. Thank
you for pointing out this binding issue.

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


[PATCH v3 7/7] ARM: dts: omap3-tobi: Add AT24C01 EEPROM

2014-03-03 Thread Florian Vaussard
Add the AT24C01 EEPROM node populated on most Gumstix expansion board.

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index caddb8c..b5e1b15 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -60,6 +60,13 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c3_pins>;
clock-frequency = <10>;
+
+   /* optional 1K EEPROM with revision information */
+   eeprom@51 {
+   compatible = "atmel,24c01";
+   reg = <0x51>;
+   pagesize = <8>;
+   };
 };
 
 &mmc3 {
-- 
1.8.3.2

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


[PATCH v3 6/7] ARM: dts: omap3-tobi: Use include file omap-gpmc-smsc9221

2014-03-03 Thread Florian Vaussard
Use the timings provided by omap-gpmc-smsc9221. This does not change
the timings, but it avoids code duplication.

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 30 +++---
 1 file changed, 3 insertions(+), 27 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index da7d85b..caddb8c 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -44,39 +44,15 @@
};
 };
 
+#include "omap-gpmc-smsc9221.dtsi"
+
 &gpmc {
ranges = <5 0 0x2c00 0x100>;/* CS5 */
 
-   ethernet@5,0 {
-   compatible = "smsc,lan9221", "smsc,lan9115";
+   ethernet@gpmc {
reg = <5 0 0xff>;
-   bank-width = <2>;
-
-   gpmc,mux-add-data;
-   gpmc,cs-on-ns = <0>;
-   gpmc,cs-rd-off-ns = <42>;
-   gpmc,cs-wr-off-ns = <36>;
-   gpmc,adv-on-ns = <6>;
-   gpmc,adv-rd-off-ns = <12>;
-   gpmc,adv-wr-off-ns = <12>;
-   gpmc,oe-on-ns = <0>;
-   gpmc,oe-off-ns = <42>;
-   gpmc,we-on-ns = <0>;
-   gpmc,we-off-ns = <36>;
-   gpmc,rd-cycle-ns = <60>;
-   gpmc,wr-cycle-ns = <54>;
-   gpmc,access-ns = <36>;
-   gpmc,page-burst-access-ns = <0>;
-   gpmc,bus-turnaround-ns = <0>;
-   gpmc,cycle2cycle-delay-ns = <0>;
-   gpmc,wr-data-mux-bus-ns = <18>;
-   gpmc,wr-access-ns = <42>;
-   gpmc,cycle2cycle-samecsen;
-   gpmc,cycle2cycle-diffcsen;
-
interrupt-parent = <&gpio6>;
interrupts = <16 IRQ_TYPE_LEVEL_LOW>;   /* GPIO 176 */
-   reg-io-width = <4>;
};
 };
 
-- 
1.8.3.2

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


[PATCH v3 3/7] ARM: dts: omap3-overo: Enable WiFi/BT combo

2014-03-03 Thread Florian Vaussard
MMC2 is used by the on-board WiFi module populated on some boards
(based on Marvell Libertas 8688 SDIO). The Bluetooth is connected
to UART2.

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-overo-storm-tobi.dts |  8 
 arch/arm/boot/dts/omap3-overo-tobi.dts   |  8 
 arch/arm/boot/dts/omap3-overo.dtsi   | 58 
 3 files changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
index 966b5c9..2033b52 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
@@ -20,3 +20,11 @@
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", 
"ti,omap36xx", "ti,omap3";
 };
 
+&omap3_pmx_core2 {
+   w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
+   pinctrl-single,pins = <
+   OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 */
+   >;
+   };
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-tobi.dts
index de5653e..21de31d 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
@@ -20,3 +20,11 @@
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", 
"ti,omap3430", "ti,omap3";
 };
 
+&omap3_pmx_core2 {
+   w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
+   pinctrl-single,pins = <
+   OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 */
+   >;
+   };
+};
+
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index aea64c0..07467cc 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -29,6 +29,38 @@
ti,mcbsp = <&mcbsp2>;
ti,codec = <&twl_audio>;
};
+
+   /* Regulator to trigger the nPoweron signal of the Wifi module */
+   w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
+   compatible = "regulator-fixed";
+   regulator-name = "regulator-w3cbw003c-npoweron";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 22 GPIO_ACTIVE_HIGH>;/* gpio_54: 
nPoweron */
+   enable-active-high;
+   };
+
+   /* Regulator to trigger the nReset signal of the Wifi module */
+   w3cbw003c_wifi_nreset: regulator-w3cbw003c-wifi-nreset {
+   pinctrl-names = "default";
+   pinctrl-0 = <&w3cbw003c_pins &w3cbw003c_2_pins>;
+   compatible = "regulator-fixed";
+   regulator-name = "regulator-w3cbw003c-wifi-nreset";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>;/* gpio_16: 
WiFi nReset */
+   startup-delay-us = <1>;
+   };
+
+   /* Regulator to trigger the nReset signal of the Bluetooth module */
+   w3cbw003c_bt_nreset: regulator-w3cbw003c-bt-nreset {
+   compatible = "regulator-fixed";
+   regulator-name = "regulator-w3cbw003c-bt-nreset";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* gpio_164: BT 
nReset */
+   startup-delay-us = <1>;
+   };
 };
 
 &omap3_pmx_core {
@@ -56,6 +88,25 @@
OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat3.sdmmc1_dat3 */
>;
};
+
+   mmc2_pins: pinmux_mmc2_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_clk.sdmmc2_clk */
+   OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_cmd.sdmmc2_cmd */
+   OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_dat0.sdmmc2_dat0 */
+   OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_dat1.sdmmc2_dat1 */
+   OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_dat2.sdmmc2_dat2 */
+   OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc2_dat3.sdmmc2_dat3 */
+   >;
+   };
+
+   /* WiFi/BT combo */
+   w3cbw003c_pins: pinmux_w3cbw003c_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20b4, PIN_OUTPUT | MUX_MODE4)   
/* gpmc_ncs3.gpio_54 */
+   OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)   
/* uart3_rts_sd.gpio_164 */
+   >;
+   };
 };
 
 &i2c1 {
@@ -94,7 +145,14 @@
 
 /* optional on board WiFi

[PATCH v3 5/7] ARM: dts: omap: Add common file for SMSC9221

2014-03-03 Thread Florian Vaussard
Some devices (SMSC9217, SMSC9218 and SMSC9221 at least) have better
timings, allowing a higher transfer speed. Create a common file
with these timings.

Performance results with iperf:

- omap-gpmc-smsc911x.dtsi => 54.9 Mbps
- omap-gpmc-smsc9221.dtsi => 92.7 Mbps

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi | 58 +++
 1 file changed, 58 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi

diff --git a/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi 
b/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
new file mode 100644
index 000..73e272f
--- /dev/null
+++ b/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
@@ -0,0 +1,58 @@
+/*
+ * Common file for GPMC connected smsc9221 on omaps
+ *
+ * Compared to smsc911x, smsc9221 (and others like smsc9217
+ * or smsc 9218) has faster timings, leading to higher
+ * bandwidth.
+ *
+ * Note that the board specifc DTS file needs to specify
+ * ranges, pinctrl, reg, interrupt parent and interrupts.
+ */
+
+/ {
+   vddvario: regulator-vddvario {
+ compatible = "regulator-fixed";
+ regulator-name = "vddvario";
+ regulator-always-on;
+   };
+
+   vdd33a: regulator-vdd33a {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd33a";
+   regulator-always-on;
+   };
+};
+
+&gpmc {
+   ethernet@gpmc {
+   compatible = "smsc,lan9221","smsc,lan9115";
+   bank-width = <2>;
+
+   gpmc,mux-add-data;
+   gpmc,cs-on-ns = <0>;
+   gpmc,cs-rd-off-ns = <42>;
+   gpmc,cs-wr-off-ns = <36>;
+   gpmc,adv-on-ns = <6>;
+   gpmc,adv-rd-off-ns = <12>;
+   gpmc,adv-wr-off-ns = <12>;
+   gpmc,oe-on-ns = <0>;
+   gpmc,oe-off-ns = <42>;
+   gpmc,we-on-ns = <0>;
+   gpmc,we-off-ns = <36>;
+   gpmc,rd-cycle-ns = <60>;
+   gpmc,wr-cycle-ns = <54>;
+   gpmc,access-ns = <36>;
+   gpmc,page-burst-access-ns = <0>;
+   gpmc,bus-turnaround-ns = <0>;
+   gpmc,cycle2cycle-delay-ns = <0>;
+   gpmc,wr-data-mux-bus-ns = <18>;
+   gpmc,wr-access-ns = <42>;
+   gpmc,cycle2cycle-samecsen;
+   gpmc,cycle2cycle-diffcsen;
+
+   vddvario-supply = <&vddvario>;
+   vdd33a-supply = <&vdd33a>;
+   reg-io-width = <4>;
+   smsc,save-mac-address;
+   };
+};
-- 
1.8.3.2

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


[PATCH v3 2/7] ARM: dts: omap3-overo: Add missing pinctrl

2014-03-03 Thread Florian Vaussard
Add missing pinctrl entries for:
- i2c1
- mmc1

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-overo.dtsi | 40 +-
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 5970999..aea64c0 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -31,7 +31,36 @@
};
 };
 
+&omap3_pmx_core {
+   uart3_pins: pinmux_uart3_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
+   OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)   
/* uart3_tx_irtx.uart3_tx_irtx */
+   >;
+   };
+
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)
/* i2c1_scl.i2c1_scl */
+   OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)
/* i2c1_sda.i2c1_sda */
+   >;
+   };
+
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_clk.sdmmc1_clk */
+   OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_cmd.sdmmc1_cmd */
+   OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat0.sdmmc1_dat0 */
+   OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat1.sdmmc1_dat1 */
+   OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat2.sdmmc1_dat2 */
+   OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat3.sdmmc1_dat3 */
+   >;
+   };
+};
+
 &i2c1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins>;
clock-frequency = <260>;
 
twl: twl@48 {
@@ -57,6 +86,8 @@
 
 /* on board microSD slot */
 &mmc1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc1_pins>;
vmmc-supply = <&vmmc1>;
bus-width = <4>;
 };
@@ -79,15 +110,6 @@
power = <50>;
 };
 
-&omap3_pmx_core {
-   uart3_pins: pinmux_uart3_pins {
-   pinctrl-single,pins = <
-   0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* 
uart3_rx_irrx.uart3_rx_irrx */
-   0x170 (PIN_OUTPUT | MUX_MODE0) /* 
uart3_tx_irtx.uart3_tx_irtx */
-   >;
-   };
-};
-
 &uart3 {
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
-- 
1.8.3.2

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


[PATCH v3 0/7] ARM: dts: Better support for Gumstix Overo (for 3.15?)

2014-03-03 Thread Florian Vaussard
Hello Tony, Benoit,

This is the third version of my Overo series. No major changes since v2,
I just dropped the patch related to the "ti,use_poweroff" binding, and
will address this issue later.

Most patches are pretty obvious. Patch 5 adds some specific timings for
LAN9221 into a generic file. By using shorter timing, it is possible to
double the Ethernet bandwidth. Thus is may interest people using a similar
chip.

I tested this series with both the OMAP35xx Overo and the OMAP36xx Overo.
Wifi is functional, HSUSB works.

Note: I hope that this can go into 3.15, since the patches were first
posted before the 3.14 merge window. They add a number of useful peripherals,
so this would be much appreciated.


Regards,
Florian


Florian Vaussard (7):
  ARM: dts: omap3-tobi: Add missing pinctrl
  ARM: dts: omap3-overo: Add missing pinctrl
  ARM: dts: omap3-overo: Enable WiFi/BT combo
  ARM: dts: omap3-overo: Add HSUSB PHY
  ARM: dts: omap: Add common file for SMSC9221
  ARM: dts: omap3-tobi: Use include file omap-gpmc-smsc9221
  ARM: dts: omap3-tobi: Add AT24C01 EEPROM

 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi  |  58 +++
 arch/arm/boot/dts/omap3-overo-storm-tobi.dts   |  24 +
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi |  48 -
 arch/arm/boot/dts/omap3-overo-tobi.dts |  24 +
 arch/arm/boot/dts/omap3-overo.dtsi | 138 +++--
 5 files changed, 258 insertions(+), 34 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi

-- 
1.8.3.2

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


[PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY

2014-03-03 Thread Florian Vaussard
Add the High-Speed USB PHY.

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++
 arch/arm/boot/dts/omap3-overo-tobi.dts   | 16 ++
 arch/arm/boot/dts/omap3-overo.dtsi   | 44 
 3 files changed, 76 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
index 2033b52..eb93e3a 100644
--- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
@@ -21,6 +21,22 @@
 };
 
 &omap3_pmx_core2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <
+   &hsusb2_2_pins
+   >;
+
+   hsusb2_2_pins: pinmux_hsusb2_2_pins {
+   pinctrl-single,pins = <
+   OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+   OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+   OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d12.hsusb2_dir */
+   OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+   OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+   OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+   >;
+   };
+
w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
pinctrl-single,pins = <
OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 */
diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
b/arch/arm/boot/dts/omap3-overo-tobi.dts
index 21de31d..e77be26 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi.dts
+++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
@@ -21,6 +21,22 @@
 };
 
 &omap3_pmx_core2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <
+   &hsusb2_2_pins
+   >;
+
+   hsusb2_2_pins: pinmux_hsusb2_2_pins {
+   pinctrl-single,pins = <
+   OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+   OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+   OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d12.hsusb2_dir */
+   OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+   OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+   OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+   >;
+   };
+
w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
pinctrl-single,pins = <
OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
/* etk_d2.gpio_16 */
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
b/arch/arm/boot/dts/omap3-overo.dtsi
index 07467cc..8f810db 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -30,6 +30,24 @@
ti,codec = <&twl_audio>;
};
 
+   /* HS USB Port 2 Power */
+   hsusb2_power: hsusb2_power_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb2_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio6 8 0>;/* gpio_168: 
vbus enable */
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   /* HS USB Host PHY on PORT 2 */
+   hsusb2_phy: hsusb2_phy {
+   compatible = "usb-nop-xceiv";
+   reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>;  /* gpio_183 */
+   vcc-supply = <&hsusb2_power>;
+   };
+
/* Regulator to trigger the nPoweron signal of the Wifi module */
w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
compatible = "regulator-fixed";
@@ -64,6 +82,11 @@
 };
 
 &omap3_pmx_core {
+   pinctrl-names = "default";
+   pinctrl-0 = <
+   &hsusb2_pins
+   >;
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
@@ -107,6 +130,19 @@
OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)   
/* uart3_rts_sd.gpio_164 */
>;
};
+
+   hsusb2_pins: pinmux_hsusb2_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN | 
MUX_MODE3)   /* mcspi1_cs3.hsusb2_data2 */
+   

[PATCH v3 1/7] ARM: dts: omap3-tobi: Add missing pinctrl

2014-03-03 Thread Florian Vaussard
Add missing pinctrl entries:
- i2c3

Signed-off-by: Florian Vaussard 
---
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi 
b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index 4edc013..da7d85b 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -35,6 +35,15 @@
};
 };
 
+&omap3_pmx_core {
+   i2c3_pins: pinmux_i2c3_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0)
/* i2c3_scl.i2c3_scl */
+   OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0)
/* i2c3_sda.i2c3_sda */
+   >;
+   };
+};
+
 &gpmc {
ranges = <5 0 0x2c00 0x100>;/* CS5 */
 
@@ -72,6 +81,8 @@
 };
 
 &i2c3 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c3_pins>;
clock-frequency = <10>;
 };
 
-- 
1.8.3.2

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


Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM

2014-03-03 Thread Roger Quadros
Hi Tony,

On 03/01/2014 12:56 AM, Tony Lindgren wrote:
> * Roger Quadros  [140227 06:21]:
>> Hi,
>>
>> This patchset brings up USB Host ports and Ethernet port on
>> the OMAP5 uEVM board.
>>
>> It also does some cleanup with respect to DT clock binding
>> for the mfd/omap-usb-host driver.
>>
>> Please queue these for -next.
>>
>> Lee,
>>
>> I've folded some platform data dependent patches with mfd patches
>> so that they don't break functionality when applied individually.
>> You can safely pull in all MFD patches (1 to 6).
>>
>> Tony & Benoit,
>>
>> Can you please accept patches 7, 8 and 9?
> 
> Are 7, 8 and 9 safe to queue separately from the MFD changes
> or do they need to wait for the MFD changes to get merged
> first?
> 

They are safe to queue separately.

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


Help needed USB hub disconnected at resume

2014-03-03 Thread Marc Murphy
Hi,
I am using the latest stable 3.4.80 kernel with some changes to get the EMAC 
Phy to initialise correctly after a suspend/resume.  The platform is AM3517 
with most of the system working nice and smoothly. I have 1 issue though and 
need some advice/help to get the system to use the USB hub I have connected to 
the EHCI controller after a suspend to memory and resume.

At boot all is recognised;

[1.486816] usbcore: registered new interface driver cdc_ether
[1.493255] usbcore: registered new interface driver cdc_ncm
[1.499450] usbcore: registered new interface driver qmi_wwan
[1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator
[2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus 
number 1
[2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
[2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
[2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[2.574035] usb usb1: Product: OMAP-EHCI Host Controller
[2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd
[2.585296] usb usb1: SerialNumber: ehci-omap.0
[2.591278] hub 1-0:1.0: USB hub found
[2.595306] hub 1-0:1.0: 3 ports detected

And I can see everything OK.

# lsusb
Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc.
#
#
# echo mem > /sys/power/state
[   73.736572] PM: Syncing filesystems ... done.
[   73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) 
done.
[   73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle
[   73.968872] PM: suspend of devices complete after 170.410 msecs
[   73.975433] PM: late suspend of devices complete after 0.305 msecs
[   73.982635] PM: noirq suspend of devices complete after 0.732 msecs
[   83.430450] Powerdomain (core_pwrdm) didn't enter target state 1
[   83.436737] Could not enter target state in pm_suspend
[   83.443176] PM: noirq resume of devices complete after 0.915 msecs
 [   83.450164] PM: early resume of devices complete after 0.274 msecs
[   83.457336] <6>Waiting for PHY clock good...
[   83.463287] davinci_mdio davinci_mdio.0: resetting idled controller
[   83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] 
(mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[   84.771881] PM: resume of devices complete after 1315.185 msecs
[   84.778472] Restarting tasks ...
[   84.782379] usb 1-1: USB disconnect, device number 2
[   84.790557] done.
[   84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
sh: write error:[   84.800781] usb 1-1.1: USB disconnect, device number 3
 Operation not p[   84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' 
usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device
ermitted
[   84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz
[   86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full
#
#
# lsusb
Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
#

Is there any relevant patch out there that would address the issue that I see ?

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


Re: [PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

2014-03-03 Thread Florian Vaussard
Hi Tony, Benoit,

On 02/24/2014 06:07 PM, Florian Vaussard wrote:
> Gumstix DuoVero is an OMAP4430-based Computer On Module.
> Parlor is one of the available expansion board.
> 
> Tested features:
> - GPMC ethernet
> - HSUSB2 and OTG
> - Audio out
> - WiFi and Bluetooth (w2cbw0015 SDIO module)
> - LED and button
> 

Can this patch go into 3.15? The other one (HDMI support) can wait for
the DSS support to be merged, but I would like to give to this DTS a
wider exposure to testing opportunities.

Regards,
Florian

> Signed-off-by: Florian Vaussard 
> ---
>  .../devicetree/bindings/arm/omap/omap.txt  |   3 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/omap4-duovero-parlor.dts | 146 
>  arch/arm/boot/dts/omap4-duovero.dtsi   | 252 
> +
>  4 files changed, 402 insertions(+)
>  create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
>  create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index af9b4a0..95b1372 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -99,6 +99,9 @@ Boards:
>  - OMAP4 PandaBoard : Low cost community board
>compatible = "ti,omap4-panda", "ti,omap4430"
>  
> +- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
> +  compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", 
> "ti,omap4430", "ti,omap4";
> +
>  - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
>compatible = "ti,omap3-evm", "ti,omap3"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0320303..8b23abb 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -215,6 +215,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>   omap3-igep0020.dtb \
>   omap3-igep0030.dtb \
>   omap3-zoom3.dtb \
> + omap4-duovero-parlor.dtb \
>   omap4-panda.dtb \
>   omap4-panda-a4.dtb \
>   omap4-panda-es.dtb \
> diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts 
> b/arch/arm/boot/dts/omap4-duovero-parlor.dts
> new file mode 100644
> index 000..96f51d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "omap4-duovero.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "OMAP4430 Gumstix Duovero on Parlor";
> + compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", 
> "ti,omap4430", "ti,omap4";
> +
> + leds {
> + compatible = "gpio-leds";
> + led0 {
> + label = "duovero:blue:led0";
> + gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;   /* gpio_122 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + button0@121 {
> + label = "button0";
> + linux,code = ;
> + gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;/* gpio_121 */
> + gpio-key,wakeup;
> + };
> + };
> +};
> +
> +&omap4_pmx_core {
> + pinctrl-0 = <
> + &led_pins
> + &button_pins
> + &smsc_pins
> + >;
> +
> + led_pins: pinmux_led_pins {
> + pinctrl-single,pins = <
> + 0xd6 (PIN_OUTPUT | MUX_MODE3)   /* 
> abe_dmic_din3.gpio_122 */
> + >;
> + };
> +
> + button_pins: pinmux_button_pins {
> + pinctrl-single,pins = <
> + 0xd4 (PIN_INPUT_PULLUP | MUX_MODE3) /* 
> abe_dmic_din2.gpio_121 */
> + >;
> + };
> +
> + i2c2_pins: pinmux_i2c2_pins {
> + pinctrl-single,pins = <
> + 0xe6 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c2_scl */
> + 0xe8 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c2_sda */
> + >;
> + };
> +
> + i2c3_pins: pinmux_i2c3_pins {
> + pinctrl-single,pins = <
> + 0xea (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c3_scl */
> + 0xec (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c3_sda */
> + >;
> + };
> +
> + smsc_pins: pinmux_smsc_pins {
> + pinctrl-single,pins = <
> + 0x28 (PIN_INPUT | MUX_MODE3)/* 
> gpmc_a20.gpio_44: IRQ */
> + 0x2a (PIN_INPUT_PULLUP | MUX_MODE3) 

Re: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm

2014-03-03 Thread Pavel Machek
Hi!

> > > Just to convey that is_battery_full is a local function and not generic. 
> > > You
> > > can find similar usage in power_supply_core.c 
> > > (__power_supply_changed_work)
> > > and in other drivers. Isn't it advised to have __ prefixes?
> > 
> > It is static; everybody sees it is local. __ prefix usually means
> > something else.
> 
> Agreed, I will remove the __ prefix in next patchset. Meanwhile I would
> appreciate if anyone could help me to understand what __ prefix
> really means.

If you have __foo() and foo(), the __foo() is typically worker
function, where foo() provides locking around it etc. 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/1] net: cpsw: fix cpdma rx descriptor leak on down interface

2014-03-03 Thread Mugunthan V N
From: Schuyler Patton 

This patch fixes a CPDMA RX Descriptor leak that occurs after taking
the interface down when the CPSW is in Dual MAC mode. Previously
the CPSW_ALE port was left open up which causes packets to be received
and processed by the RX interrupt handler and were passed to the
non active network interface where they were ignored.

The fix is for the slave_stop function of the selected interface
to disable the respective CPSW_ALE Port from forwarding packets. This
blocks traffic from being received on the inactive interface.

Signed-off-by: Schuyler Patton 
Reviewed-by: Felipe Balbi 
Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 651087b..ffd4d12 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1164,11 +1164,17 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
 
 static void cpsw_slave_stop(struct cpsw_slave *slave, struct cpsw_priv *priv)
 {
+   u32 slave_port;
+
+   slave_port = cpsw_get_slave_port(priv, slave->slave_num);
+
if (!slave->phy)
return;
phy_stop(slave->phy);
phy_disconnect(slave->phy);
slave->phy = NULL;
+   cpsw_ale_control_set(priv->ale, slave_port,
+ALE_PORT_STATE, ALE_PORT_STATE_DISABLE);
 }
 
 static int cpsw_ndo_open(struct net_device *ndev)
-- 
1.9.0

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


Re: [PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY

2014-03-03 Thread Roger Quadros
Hi Florian,


On 03/03/2014 11:34 AM, Florian Vaussard wrote:
> Add the High-Speed USB PHY.
> 
> Signed-off-by: Florian Vaussard 
> ---
>  arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++
>  arch/arm/boot/dts/omap3-overo-tobi.dts   | 16 ++
>  arch/arm/boot/dts/omap3-overo.dtsi   | 44 
> 
>  3 files changed, 76 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
> b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> index 2033b52..eb93e3a 100644
> --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
> @@ -21,6 +21,22 @@
>  };
>  
>  &omap3_pmx_core2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &hsusb2_2_pins
> + >;
> +
> + hsusb2_2_pins: pinmux_hsusb2_2_pins {
> + pinctrl-single,pins = <
> + OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
> /* etk_d10.hsusb2_clk */
> + OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
> /* etk_d11.hsusb2_stp */
> + OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d12.hsusb2_dir */
> + OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d13.hsusb2_nxt */
> + OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d14.hsusb2_data0 */
> + OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d15.hsusb2_data1 */
> + >;
> + };
> +
>   w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
>   pinctrl-single,pins = <
>   OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
> /* etk_d2.gpio_16 */
> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
> b/arch/arm/boot/dts/omap3-overo-tobi.dts
> index 21de31d..e77be26 100644
> --- a/arch/arm/boot/dts/omap3-overo-tobi.dts
> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
> @@ -21,6 +21,22 @@
>  };
>  
>  &omap3_pmx_core2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &hsusb2_2_pins
> + >;
> +
> + hsusb2_2_pins: pinmux_hsusb2_2_pins {
> + pinctrl-single,pins = <
> + OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
> /* etk_d10.hsusb2_clk */
> + OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
> /* etk_d11.hsusb2_stp */
> + OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d12.hsusb2_dir */
> + OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d13.hsusb2_nxt */
> + OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d14.hsusb2_data0 */
> + OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
> MUX_MODE3)/* etk_d15.hsusb2_data1 */
> + >;
> + };
> +
>   w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
>   pinctrl-single,pins = <
>   OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
> /* etk_d2.gpio_16 */
> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
> b/arch/arm/boot/dts/omap3-overo.dtsi
> index 07467cc..8f810db 100644
> --- a/arch/arm/boot/dts/omap3-overo.dtsi
> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
> @@ -30,6 +30,24 @@
>   ti,codec = <&twl_audio>;
>   };
>  
> + /* HS USB Port 2 Power */
> + hsusb2_power: hsusb2_power_reg {
> + compatible = "regulator-fixed";
> + regulator-name = "hsusb2_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&gpio6 8 0>;/* gpio_168: 
> vbus enable */
> + startup-delay-us = <7>;
> + enable-active-high;
> + };
> +
> + /* HS USB Host PHY on PORT 2 */
> + hsusb2_phy: hsusb2_phy {
> + compatible = "usb-nop-xceiv";
> + reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>;  /* gpio_183 */
> + vcc-supply = <&hsusb2_power>;
> + };
> +
>   /* Regulator to trigger the nPoweron signal of the Wifi module */
>   w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
>   compatible = "regulator-fixed";
> @@ -64,6 +82,11 @@
>  };
>  
>  &omap3_pmx_core {
> + pinctrl-names = "default";
> + pinctrl-0 = <
> + &hsusb2_pins
> + >;
> +
>   uart3_pins: pinmux_uart3_pins {
>   pinctrl-single,pins = <
>   OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
> PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
> @@ -107,6 +130,19 @@
>   OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)   
> /* uart3_rts_sd.gpio_164 */
>   >;
>   };
> +
> + hsusb2_pins:

Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling

2014-03-03 Thread Sørensen , Stefan
On Sun, 2014-03-02 at 09:37 -0800, Tony Lindgren wrote:
> * Sørensen, Stefan  [140301 02:02]:
> > On Fri, 2014-02-28 at 09:11 -0800, Tony Lindgren wrote:
> > > * Stefan Sørensen  [140224 02:12]:
> > > > Currently INTC interrupts are handled using handle_level_irq which
> > > > will acknowledge the interrupt before running the handler. If a second
> > > > interrupt is then asserted and this interrupt is disabled while
> > > > running the first handler, the INTC will be brought into an
> > > > inconsistent state.
> > > 
> > > Hmm care to explain a bit more here if the second interrupt you're
> > > talking about is the same interrupt or any interrupt in the same
> > > interrupt bank? Is this limited to GPIO interrupts?
> > 
> > I am seeing it with the cpsw driver on a custom board and on the
> > beaglebone. When a tx irq is handled the cpsw irq handler disables both
> > the tx and the rx irqs, and if the rx irq was also asserted (i.e. duplex
> > traffic), this bug will trigger. Reproducing it is very simple, just hit
> > a beaglebone with a flood ping and watch a function trace.
> 
> OK so it's for the same interrupt. And that sounds like a good test :)

No, the tx and rx are separate interrupts, but the cpsw driver has a
common handler.
 
> > > The reason I'm asking is because of the issues we've seen earlier
> > > with not flushing posted writes from the interrupt handlers. In
> > > those case the interrupt on the device gets acked too late without
> > > the read back call.
> > 
> > I am not very familiar with the low level details of the irq handling,  
> > but am335x TRM states that a data synchronization barrier should be used
> > after the ACK is posted to the INTC, and I don't see that anywhere in
> > the code. Is this related?
> 
> Well sort of, except DSB won't do it as it won't guarantee the write
> gets to the device on the bus. So a readback from the device is needed
> as only the order of reads and writes is guaranteed.

I think that we are talking about two different scenarios, what I am
seeing is that an interrupt is disabled while active on the INTC.

1. CPSW device asserts TX IRQ
2. CPSW device asserts RX IRQ
3. INTC interrupts CPU, TX IRQ marked as active
4. omap_intc_handle_irq ACKs TX IRQ on the INTC
5. INTC marks RX IRQ as active
6. omap_intc_handle_irq calls cpsw_interrupt
7. cpsw_interrupt disables RX+TX IRQ in CPSW device
8. cpsw_interrupt disables RX+TX IRQ in INTC (the IRQs are masked)
9.. omap_intc_handle_irq sees no unmasked IRQs are pending and returns
10. INTC interrupts CPU, RX IRQ marked as pending
11. omap_intc_handle_irq sees no unmasked IRQs are pending and returns
12. Go to step 10

The problem arises in step 8 where an active IRQ is masked. This will
not make it inactive in the INTC but it will be cleared from the
pending IRQ registers - this is the register that omap_intc_handle_irq
uses to decide which IRQ is active.

> A good sanity check would be to find the related interrupt handler(s)
> in the cpsw driver that do the write to the cpsw registers to ack
> interrupts.
> 
> Then check if there's a readback in the cpsw interrupt handler(s) of
> some harmless cpsw register after acking the interrupt(s) and before
> doing return IRQ_HANDLED.
> 
> If this fixes things without your patch, then we know it's a driver
> issue and there's no need to debug it further :) The missing flush of
> posted write usually shows up as a spurious interrupts with no status
> in the device, but depending on the driver code handling of spurious
> interrupts it may also have other side effects.
> 
> I'm not too familiar with the cpsw driver so I can't do a test patch
> without digging into it further sorry. For similar examples, you
> may want to grep for "flush posted write" and "OCP barrier" in the
> kernel code.

I tried this with an assortment of different CPSW registers - no change.

Stefan



Re: Help needed USB hub disconnected at resume

2014-03-03 Thread Roger Quadros
Hi Marc,

On 03/03/2014 12:04 PM, Marc Murphy wrote:
> Hi,
> I am using the latest stable 3.4.80 kernel with some changes to get the EMAC 
> Phy to initialise correctly after a suspend/resume.  The platform is AM3517 
> with most of the system working nice and smoothly. I have 1 issue though and 
> need some advice/help to get the system to use the USB hub I have connected 
> to the EHCI controller after a suspend to memory and resume.
> 
> At boot all is recognised;
> 
> [1.486816] usbcore: registered new interface driver cdc_ether
> [1.493255] usbcore: registered new interface driver cdc_ncm
> [1.499450] usbcore: registered new interface driver qmi_wwan
> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator
> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus 
> number 1
> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1
> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller
> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd
> [2.585296] usb usb1: SerialNumber: ehci-omap.0
> [2.591278] hub 1-0:1.0: USB hub found
> [2.595306] hub 1-0:1.0: 3 ports detected
> 
> And I can see everything OK.
> 
> # lsusb
> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc.
> #
> #
> # echo mem > /sys/power/state
> [   73.736572] PM: Syncing filesystems ... done.
> [   73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [   73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) 
> done.
> [   73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle
> [   73.968872] PM: suspend of devices complete after 170.410 msecs
> [   73.975433] PM: late suspend of devices complete after 0.305 msecs
> [   73.982635] PM: noirq suspend of devices complete after 0.732 msecs
> [   83.430450] Powerdomain (core_pwrdm) didn't enter target state 1
> [   83.436737] Could not enter target state in pm_suspend
> [   83.443176] PM: noirq resume of devices complete after 0.915 msecs
>  [   83.450164] PM: early resume of devices complete after 0.274 msecs
> [   83.457336] <6>Waiting for PHY clock good...
> [   83.463287] davinci_mdio davinci_mdio.0: resetting idled controller
> [   83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] 
> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
> [   84.771881] PM: resume of devices complete after 1315.185 msecs
> [   84.778472] Restarting tasks ...
> [   84.782379] usb 1-1: USB disconnect, device number 2
> [   84.790557] done.
> [   84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
> sh: write error:[   84.800781] usb 1-1.1: USB disconnect, device number 3
>  Operation not p[   84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 
> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device
> ermitted
> [   84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz
> [   86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full
> #
> #
> # lsusb
> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> #
> 
> Is there any relevant patch out there that would address the issue that I see 
> ?

Does this happen because of OFF mode?
Can you please try the tests with off mode disabled?

e.g.
mount -t debugfs none /sys/kernel/debug
echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode
suspend & resume

Also please send the output of /sys/kernel/debug/pm_debug/count
before suspend and after resume. Thanks.

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


Re: [PATCH 1/3] mfd: twl6040: Select i2c fast mode as default with regmap patch

2014-03-03 Thread Peter Ujfalusi
On 02/28/2014 05:07 PM, Nishanth Menon wrote:
> On 02/28/2014 08:26 AM, Peter Ujfalusi wrote:
>> On 02/28/2014 03:30 PM, Nishanth Menon wrote:
>>> TWL6030 can do 3.3MHz by default and there are no speed registers to
>>> configure.
>>
>> According to the datasheet the speed of twl6030 is limited to 2.4MHz. I have
>> not seen registers or pins to select the speed. As the documentation puts
>> this: High-speed mode (limited to 2.4Mbit/s maximum)
> 
> Aye, you are correct, the latest data sheet does show this - i made
> the mistake of opening an older spec doc :(..

As a note: I tried first with 3.4MHz bus speed (who reads documentation?)
twl6030 was working fine as far as I can tell. But the TRM is really
expressing that 2.4MHz is the limit for twl6030.

> I do however suggest that you put one of those i2c analyser on the
> rail to see what is happening. else, we'd be doing a lot of guessing here.

If I would have access to one...


>> If I have fast mode configured to the controller, I can still communicate 
>> with
>> twl6040 even if it is set to normal mode.
> 
>>
>> I still think that this patch is safe for now. We could try to figure out how
>> to increase the i2c speed on the bus for twl6030 and twl6040. This has to be
>> done in the same series.
> 
> ?? you mean set i2c bus speed to full speed on PandaBoard? it is
> already full speed[1]!

No, I was thinking of Fast+ or HighSpeed but I have doubts that it can be done.

>> Now after several boots:
>> It seams if I set the i2c to 2.4MHz and I can not communicate with twl6040
>> right after cold power on.
>> So if the i2c bus is already set to 2.4GHz I can not set the twl6040 ACCCTL
>> register. But the content of ACCCTL register seams to be preserved between
>> reboots and this is why I saw that the 2.4MHz bus speed might be even 
>> possible.
> 
> This observation is the key.
> 
> Are you power cycling the regulators for TWL6040 as part of your
> shutdown handler?

When the mfd driver is removed, yes powers are asked to be turned off but in
reality at least vio is always on in all of the boards I have seen.

> Did you read the ACCTL register after a reboot to
> see if the register contents are still the same as before?

Yes I did. after reboot the ACCCTL register is the same in u-boot as I set
previously, before the reboot.
Disconnect power + Power the board the ACCCTL is as it has been specified in
the datasheet.

> Based on this observation, I suggest switching [1] to 100KHz.

After several power cycle, reboot, cold boot etc. I think we can leave the i2c
speed at 400KHz and configure the twl6040 to Fast mode as the first thing when
the driver probes or the chip is powering on (regmap patch functionality).
I have not seen a single case when this failed on me and the the 4x bandwidth
does matter for twl6030 IMHO.

> 
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap4-panda-common.dtsi#n291
> 


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


[PATCH v5 3/6] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework

2014-03-03 Thread Kishon Vijay Abraham I
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-ti-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/Kconfig|   11 +
 drivers/phy/Makefile   |1 +
 .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} |  240 
 drivers/usb/phy/Kconfig|   11 -
 drivers/usb/phy/Makefile   |1 -
 5 files changed, 158 insertions(+), 106 deletions(-)
 rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c7a551c..e3ec7d1 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -40,6 +40,17 @@ config OMAP_USB2
  The USB OTG controller communicates with the comparator using this
  driver.
 
+config TI_PIPE3
+   tristate "TI PIPE3 PHY Driver"
+   depends on ARCH_OMAP2PLUS || COMPILE_TEST
+   select GENERIC_PHY
+   select OMAP_CONTROL_USB
+   help
+ Enable this to support the PIPE3 PHY that is part of TI SOCs. This
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the "OMAP Control PHY Driver" to power
+ on/off the PHY.
+
 config TWL4030_USB
tristate "TWL4030 USB Transceiver Driver"
depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index b57c253..32e3f94 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -8,4 +8,5 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)   += phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
 obj-$(CONFIG_PHY_MVEBU_SATA)   += phy-mvebu-sata.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-ti-pipe3.c
similarity index 54%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-ti-pipe3.c
index 0c6ba29..67b189d 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -1,5 +1,5 @@
 /*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * phy-ti-pipe3 - PIPE3 PHY driver.
  *
  * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
  * This program is free software; you can redistribute it and/or modify
@@ -19,10 +19,11 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,17 +53,34 @@
 
 /*
  * This is an Empirical value that works, need to confirm the actual
- * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status
- * to be correctly reflected in the USB3PHY_PLL_STATUS register.
+ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
+ * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
  */
 # define PLL_IDLE_TIME  100;
 
-struct usb_dpll_map {
+struct pipe3_dpll_params {
+   u16 m;
+   u8  n;
+   u8  freq:3;
+   u8  sd;
+   u32 mf;
+};
+
+struct ti_pipe3 {
+   void __iomem*pll_ctrl_base;
+   struct device   *dev;
+   struct device   *control_dev;
+   struct clk  *wkupclk;
+   struct clk  *sys_clk;
+   struct clk  *optclk;
+};
+
+struct pipe3_dpll_map {
unsigned long rate;
-   struct usb_dpll_params params;
+   struct pipe3_dpll_params params;
 };
 
-static struct usb_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map[] = {
{1200, {1250, 5, 4, 20, 0} },   /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} },  /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} },   /* 19.2 MHz */
@@ -71,7 +89,18 @@ static struct usb_dpll_map dpll_map[] = {
{3840, {3125, 47, 4, 20, 92843} },  /* 38.4 MHz */
 };
 
-static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate)
+static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset)
+{
+   return __raw_readl(addr + offset);
+}
+
+static inline void ti_pipe3_writel(void __iomem *addr, unsigned offset,
+   u32 data)
+{
+   __raw_writel(data, addr + offset);
+}
+
+static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate)
 {
int i;
 
@@ -83,110 +112,123 @@ static struct usb_dpll_params 
*omap_usb3_get_dpll_params(unsigned long rate)
return NULL;
 }
 
-static int omap_usb3_suspend(struct usb_phy *x, int suspend)
+static int ti_pipe3_power_off(struct phy *x)
+{
+   struct ti_pipe3 *phy = phy_get_drvdata(x);
+   int val;
+   int timeout = PLL_IDLE_TIME;
+
+   val = ti_

[PATCH v5 6/6] arm/dts: added dt properties to adapt to the new phy framwork

2014-03-03 Thread Kishon Vijay Abraham I
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/omap5.dtsi |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..1c68558 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -732,7 +732,8 @@
compatible = "snps,dwc3";
reg = <0x4a03 0x1>;
interrupts = ;
-   usb-phy = <&usb2_phy>, <&usb3_phy>;
+   phys = <&usb2_phy>, <&usb3_phy>;
+   phy-names = "usb2-phy", "usb3-phy";
dr_mode = "peripheral";
tx-fifo-resize;
};
@@ -749,6 +750,7 @@
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x7c>;
ctrl-module = <&omap_control_usb2phy>;
+   #phy-cells = <0>;
};
 
usb3_phy: usb3phy@4a084400 {
@@ -758,6 +760,7 @@
  <0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <&omap_control_usb3phy>;
+   #phy-cells = <0>;
};
};
 
-- 
1.7.9.5

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


[PATCH v5 5/6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/

2014-03-03 Thread Kishon Vijay Abraham I
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-omap-usb2.c   |2 +-
 include/linux/{usb => phy}/omap_usb.h |3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)
 rename include/linux/{usb => phy}/omap_usb.h (95%)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 705af5a..9c3f056 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
 struct omap_usb {
struct usb_phy  phy;
struct phy_companion*comparator;
-   void __iomem*pll_ctrl_base;
struct device   *dev;
struct device   *control_dev;
struct clk  *wkupclk;
-   struct clk  *sys_clk;
struct clk  *optclk;
-   u8  is_suspended:1;
 };
 
 #definephy_to_omapusb(x)   container_of((x), struct omap_usb, phy)
-- 
1.7.9.5

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


[PATCH v5 0/6] Make dwc3 use Generic PHY Framework

2014-03-03 Thread Kishon Vijay Abraham I
Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3
should be programmed. While this can be considered as a temporary fix,
a long term solution would be to add 'nop' PHY for platforms that does
not have programmable PHY.
Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the
name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to
be used for SATA and PCIE too.

Changes from v4: (sending the entire patch series again)
* check the return values of phy_init and phy_power_on
* print errors if power_on or power_off of PHY fails.

Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) 
* avoided using quirks and rely on the return values of PHY APIs to find the
presence of PHY.

Changes from v2:
* added a couple of fixes. One is invoking phy_resume after phy_init and the
other is power off phy in error patch
* used quirks to identify if a particular platform does not have PHYs
* removed using separate header for pipe3 driver and also removed all referencs
to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers.

Changes from v1:
* The logic in which the driver detects the presence of PHYs has changed.
* patch ordering has changed
* udelay is replaced with usleep_range
* A patch to remove set_suspend callback which was deferred from Generic
PHY Framework series has been included.

Kishon Vijay Abraham I (6):
  usb: dwc3: core: support optional PHYs
  usb: dwc3: adapt dwc3 core to use Generic PHY Framework
  drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
  arm/dts: added dt properties to adapt to the new phy framwork

 Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
 arch/arm/boot/dts/omap5.dtsi   |5 +-
 drivers/phy/Kconfig|   11 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-omap-usb2.c|   27 +--
 .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} |  240 
 drivers/usb/dwc3/core.c|  116 +++---
 drivers/usb/dwc3/core.h|7 +
 drivers/usb/phy/Kconfig|   11 -
 drivers/usb/phy/Makefile   |1 -
 include/linux/{usb => phy}/omap_usb.h  |3 -
 11 files changed, 264 insertions(+), 164 deletions(-)
 rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%)
 rename include/linux/{usb => phy}/omap_usb.h (95%)

-- 
1.7.9.5

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


[PATCH v5 4/6] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

2014-03-03 Thread Kishon Vijay Abraham I
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/phy/phy-omap-usb2.c |   25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7699752..705af5a 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -98,28 +98,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-   struct omap_usb *phy = phy_to_omapusb(x);
-   int ret;
-
-   if (suspend && !phy->is_suspended) {
-   omap_control_usb_phy_power(phy->control_dev, 0);
-   pm_runtime_put_sync(phy->dev);
-   phy->is_suspended = 1;
-   } else if (!suspend && phy->is_suspended) {
-   ret = pm_runtime_get_sync(phy->dev);
-   if (ret < 0) {
-   dev_err(phy->dev, "get_sync failed with err %d\n", ret);
-   return ret;
-   }
-   omap_control_usb_phy_power(phy->control_dev, 1);
-   phy->is_suspended = 0;
-   }
-
-   return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
@@ -173,7 +151,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
phy->phy.dev= phy->dev;
phy->phy.label  = "omap-usb2";
-   phy->phy.set_suspend= omap_usb2_suspend;
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
@@ -190,8 +167,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy->control_dev = &control_pdev->dev;
-
-   phy->is_suspended   = 1;
omap_control_usb_phy_power(phy->control_dev, 0);
 
otg->set_host   = omap_usb_set_host;
-- 
1.7.9.5

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


[PATCH v5 1/6] usb: dwc3: core: support optional PHYs

2014-03-03 Thread Kishon Vijay Abraham I
Since PHYs for dwc3 is optional (not all SoCs having PHYs for DWC3
should be programmed), do not return from probe if the USB PHY library
returns -ENODEV as that indicates the platform does not have a
programmable PHY.

While this can be considered as a temporary fix, a long term solution
would be to add 'nop' PHY for platforms that does not have programmable
PHY.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Roger Quadros 
---
 drivers/usb/dwc3/core.c |   34 ++
 1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7d0cb34..225a4d6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -529,32 +529,26 @@ static int dwc3_probe(struct platform_device *pdev)
 
if (IS_ERR(dwc->usb2_phy)) {
ret = PTR_ERR(dwc->usb2_phy);
-
-   /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
-   if (ret == -ENXIO)
+   if (ret == -ENXIO || ret == -ENODEV) {
+   dwc->usb2_phy = NULL;
+   } else if (ret == -EPROBE_DEFER) {
return ret;
-
-   dev_err(dev, "no usb2 phy configured\n");
-   return -EPROBE_DEFER;
+   } else {
+   dev_err(dev, "no usb2 phy configured\n");
+   return ret;
+   }
}
 
if (IS_ERR(dwc->usb3_phy)) {
ret = PTR_ERR(dwc->usb3_phy);
-
-   /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
-   if (ret == -ENXIO)
+   if (ret == -ENXIO || ret == -ENODEV) {
+   dwc->usb3_phy = NULL;
+   } else if (ret == -EPROBE_DEFER) {
return ret;
-
-   dev_err(dev, "no usb3 phy configured\n");
-   return -EPROBE_DEFER;
+   } else {
+   dev_err(dev, "no usb3 phy configured\n");
+   return ret;
+   }
}
 
dwc->xhci_resources[0].start = res->start;
-- 
1.7.9.5

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


[PATCH v5 2/6] usb: dwc3: adapt dwc3 core to use Generic PHY Framework

2014-03-03 Thread Kishon Vijay Abraham I
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().

However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
 drivers/usb/dwc3/core.c|   86 +---
 drivers/usb/dwc3/core.h|7 ++
 3 files changed, 89 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
  - compatible: must be "snps,dwc3"
  - reg : Address and length of the register set for the device
  - interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
  - usb-phy : array of phandle for the PHY device.  The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
  - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
 
 This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 225a4d6..497234a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -61,9 +61,10 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
  * dwc3_core_soft_reset - Issues core soft reset and PHY reset
  * @dwc: pointer to our context structure
  */
-static void dwc3_core_soft_reset(struct dwc3 *dwc)
+static int dwc3_core_soft_reset(struct dwc3 *dwc)
 {
u32 reg;
+   int ret;
 
/* Before Resetting PHY, put Core in Reset */
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
@@ -82,6 +83,15 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
 
usb_phy_init(dwc->usb2_phy);
usb_phy_init(dwc->usb3_phy);
+   ret = phy_init(dwc->usb2_generic_phy);
+   if (ret < 0)
+   return ret;
+
+   ret = phy_init(dwc->usb3_generic_phy);
+   if (ret < 0) {
+   phy_exit(dwc->usb2_generic_phy);
+   return ret;
+   }
mdelay(100);
 
/* Clear USB3 PHY reset */
@@ -100,6 +110,8 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~DWC3_GCTL_CORESOFTRESET;
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+   return 0;
 }
 
 /**
@@ -381,7 +393,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
cpu_relax();
} while (true);
 
-   dwc3_core_soft_reset(dwc);
+   ret = dwc3_core_soft_reset(dwc);
+   if (ret)
+   goto err0;
 
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
@@ -446,6 +460,8 @@ err2:
 err1:
usb_phy_shutdown(dwc->usb2_phy);
usb_phy_shutdown(dwc->usb3_phy);
+   phy_exit(dwc->usb2_generic_phy);
+   phy_exit(dwc->usb3_generic_phy);
 
 err0:
return ret;
@@ -453,14 +469,12 @@ err0:
 
 static void dwc3_core_exit(struct dwc3 *dwc)
 {
-   if (!IS_ERR(dwc->usb2_phy))
-   usb_phy_shutdown(dwc->usb2_phy);
-   if (!IS_ERR(dwc->usb3_phy))
-   usb_phy_shutdown(dwc->usb3_phy);
-
dwc3_free_scratch_buffers(dwc);
usb_phy_shutdown(dwc->usb2_phy);
usb_phy_shutdown(dwc->usb3_phy);
+   phy_exit(dwc->usb2_generic_phy);
+   phy_exit(dwc->usb3_generic_phy);
+
 }
 
 #define DWC3_ALIGN_MASK(16 - 1)
@@ -551,6 +565,32 @@ static int dwc3_probe(struct platform_device *pdev)
}
}
 
+   dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
+   if (IS_ERR(dwc->usb2_generic_phy)) {
+   ret = PTR_ERR(dwc->usb2_generic_phy);
+   if (ret == -ENOSYS || ret == -ENODEV) {
+   dwc->usb2_generic_phy = NULL;
+   } else if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else {
+   dev_err(dev, "no usb2 phy configured\n");
+   return ret;
+   }
+   }
+
+   dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
+   if (IS_ERR(dwc->usb3_generic_phy)) {
+   ret = PTR_ERR(dwc->usb3_generic_phy);
+   if (ret == -ENOSYS || ret == -ENODEV) {
+   dwc->usb3_generic_phy = NULL;
+   } else if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else {
+   dev_err(dev, "no usb3 phy configured\n");
+   re

[PATCH] OMAPDSS: convert pixel clock to common videomode style

2014-03-03 Thread Tomi Valkeinen
omapdss has its own video-timings struct, but we want to move the common
videomode.

The first step is to change the omapdss's pixelclock unit from kHz to
Hz. Also, omapdss uses "pixel_clock" field name, whereas the common
videomode uses "pixelclock" field name. This patch changes the field
name also, as that makes it easy to spot any non-converted pixel_clock
uses.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_connector.c   |  6 +-
 .../video/omap2/displays-new/connector-analog-tv.c |  2 +-
 drivers/video/omap2/displays-new/connector-dvi.c   |  2 +-
 drivers/video/omap2/displays-new/connector-hdmi.c  |  2 +-
 drivers/video/omap2/displays-new/panel-dsi-cm.c|  2 +-
 .../omap2/displays-new/panel-lgphilips-lb035q02.c  |  2 +-
 .../omap2/displays-new/panel-nec-nl8048hl11.c  |  4 +-
 .../omap2/displays-new/panel-sharp-ls037v7dw01.c   |  2 +-
 .../omap2/displays-new/panel-sony-acx565akm.c  |  2 +-
 .../omap2/displays-new/panel-tpo-td028ttec1.c  |  2 +-
 .../omap2/displays-new/panel-tpo-td043mtea1.c  |  2 +-
 drivers/video/omap2/dss/dispc.c|  8 +--
 drivers/video/omap2/dss/display-sysfs.c|  4 +-
 drivers/video/omap2/dss/display.c  |  4 +-
 drivers/video/omap2/dss/dpi.c  | 25 
 drivers/video/omap2/dss/dsi.c  | 16 ++---
 drivers/video/omap2/dss/hdmi4.c|  9 +--
 drivers/video/omap2/dss/hdmi_common.c  | 74 +++---
 drivers/video/omap2/dss/sdi.c  | 15 ++---
 drivers/video/omap2/dss/venc.c |  4 +-
 drivers/video/omap2/dss/venc_panel.c   |  2 +-
 drivers/video/omap2/omapfb/omapfb-main.c   |  8 +--
 include/video/omapdss.h|  4 +-
 23 files changed, 100 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 912759daf562..86f4ead0441d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -37,7 +37,7 @@ struct omap_connector {
 void copy_timings_omap_to_drm(struct drm_display_mode *mode,
struct omap_video_timings *timings)
 {
-   mode->clock = timings->pixel_clock;
+   mode->clock = timings->pixelclock / 1000;
 
mode->hdisplay = timings->x_res;
mode->hsync_start = mode->hdisplay + timings->hfp;
@@ -68,7 +68,7 @@ void copy_timings_omap_to_drm(struct drm_display_mode *mode,
 void copy_timings_drm_to_omap(struct omap_video_timings *timings,
struct drm_display_mode *mode)
 {
-   timings->pixel_clock = mode->clock;
+   timings->pixelclock = mode->clock * 1000;
 
timings->x_res = mode->hdisplay;
timings->hfp = mode->hsync_start - mode->hdisplay;
@@ -220,7 +220,7 @@ static int omap_connector_mode_valid(struct drm_connector 
*connector,
if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
-   new_mode->clock = timings.pixel_clock;
+   new_mode->clock = timings.pixelclock / 1000;
new_mode->vrefresh = 0;
if (mode->vrefresh == drm_mode_vrefresh(new_mode))
ret = MODE_OK;
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c 
b/drivers/video/omap2/displays-new/connector-analog-tv.c
index ccd9073f706f..27f33ef8fca1 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -31,7 +31,7 @@ struct panel_drv_data {
 static const struct omap_video_timings tvc_pal_timings = {
.x_res  = 720,
.y_res  = 574,
-   .pixel_clock= 13500,
+   .pixelclock = 1350,
.hsw= 64,
.hfp= 12,
.hbp= 68,
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c 
b/drivers/video/omap2/displays-new/connector-dvi.c
index b6c50904038e..d18e4b8c0731 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -23,7 +23,7 @@ static const struct omap_video_timings dvic_default_timings = 
{
.x_res  = 640,
.y_res  = 480,
 
-   .pixel_clock= 23500,
+   .pixelclock = 2350,
 
.hfp= 48,
.hsw= 32,
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c 
b/drivers/video/omap2/displays-new/connector-hdmi.c
index 9abe2c039ae9..9393e2d6473d 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -21,7 +21,7 @@
 static const struct omap_video_timings hdmic_default_timings = {
.x_res  = 640,
.y_res  = 480,
-   .pixel_clock= 25175,
+   .pixelclock = 25175000,
.hsw

RE: [PATCH 5/7] v4l: ti-vpe: Allow usage of smaller images

2014-03-03 Thread Kamil Debski
Hi Archit,

> From: Archit Taneja [mailto:arc...@ti.com]
> Sent: Monday, March 03, 2014 8:33 AM
> 
> The minimum width and height for VPE input/output was kept as 128
> pixels. VPE doesn't have a constraint on the image height, it requires
> the image width to be atleast 16 bytes.

"16 bytes" - shouldn't it be pixels? (also "at least" :) ) 
I can correct it when applying the patch if the above is the case.
 
> Change the minimum supported dimensions to 32x32. This allows us to de-
> interlace qcif content. A smaller image size than 32x32 didn't make
> much sense, so stopped at this.
> 
> Signed-off-by: Archit Taneja 

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland


> ---
>  drivers/media/platform/ti-vpe/vpe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/vpe.c
> b/drivers/media/platform/ti-vpe/vpe.c
> index 915029b..3a610a6 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -49,8 +49,8 @@
>  #define VPE_MODULE_NAME "vpe"
> 
>  /* minimum and maximum frame sizes */
> -#define MIN_W128
> -#define MIN_H128
> +#define MIN_W32
> +#define MIN_H32
>  #define MAX_W1920
>  #define MAX_H1080
> 
> --
> 1.8.3.2

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


Re: Help needed USB hub disconnected at resume

2014-03-03 Thread Igor Grinberg
On 03/03/14 13:06, Roger Quadros wrote:
> Hi Marc,
> 
> On 03/03/2014 12:04 PM, Marc Murphy wrote:
>> Hi,
>> I am using the latest stable 3.4.80 kernel with some changes to get the EMAC 
>> Phy to initialise correctly after a suspend/resume.  The platform is AM3517 
>> with most of the system working nice and smoothly. I have 1 issue though and 
>> need some advice/help to get the system to use the USB hub I have connected 
>> to the EHCI controller after a suspend to memory and resume.
>>
>> At boot all is recognised;
>>
>> [1.486816] usbcore: registered new interface driver cdc_ether
>> [1.493255] usbcore: registered new interface driver cdc_ncm
>> [1.499450] usbcore: registered new interface driver qmi_wwan
>> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator
>> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
>> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus 
>> number 1
>> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
>> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
>> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, 
>> SerialNumber=1
>> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller
>> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd
>> [2.585296] usb usb1: SerialNumber: ehci-omap.0
>> [2.591278] hub 1-0:1.0: USB hub found
>> [2.595306] hub 1-0:1.0: 3 ports detected
>>
>> And I can see everything OK.
>>
>> # lsusb
>> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc.
>> #
>> #
>> # echo mem > /sys/power/state
>> [   73.736572] PM: Syncing filesystems ... done.
>> [   73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done.
>> [   73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) 
>> done.
>> [   73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle
>> [   73.968872] PM: suspend of devices complete after 170.410 msecs
>> [   73.975433] PM: late suspend of devices complete after 0.305 msecs
>> [   73.982635] PM: noirq suspend of devices complete after 0.732 msecs
>> [   83.430450] Powerdomain (core_pwrdm) didn't enter target state 1
>> [   83.436737] Could not enter target state in pm_suspend
>> [   83.443176] PM: noirq resume of devices complete after 0.915 msecs
>>  [   83.450164] PM: early resume of devices complete after 0.274 msecs
>> [   83.457336] <6>Waiting for PHY clock good...
>> [   83.463287] davinci_mdio davinci_mdio.0: resetting idled controller
>> [   83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] 
>> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
>> [   84.771881] PM: resume of devices complete after 1315.185 msecs
>> [   84.778472] Restarting tasks ...
>> [   84.782379] usb 1-1: USB disconnect, device number 2
>> [   84.790557] done.
>> [   84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
>> sh: write error:[   84.800781] usb 1-1.1: USB disconnect, device number 3
>>  Operation not p[   84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 
>> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device
>> ermitted
>> [   84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz
>> [   86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full
>> #
>> #
>> # lsusb
>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> #
>>
>> Is there any relevant patch out there that would address the issue that I 
>> see ?
> 
> Does this happen because of OFF mode?
> Can you please try the tests with off mode disabled?
> 
> e.g.
> mount -t debugfs none /sys/kernel/debug
> echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode
> suspend & resume

AFAIK, AM3517 does not have OFF mode.
We had something similar with runtime pm...
It might be useful to know which hub is this and how is it connected...

> 
> Also please send the output of /sys/kernel/debug/pm_debug/count
> before suspend and after resume. Thanks.



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


RE: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver

2014-03-03 Thread Kamil Debski
Hi Archit,

> From: Archit Taneja [mailto:arc...@ti.com]
> Sent: Monday, March 03, 2014 9:26 AM
> 
> Hi,
> 
> On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote:
> > Hi Archit!
> >
> > On 03/03/2014 08:33 AM, Archit Taneja wrote:
> >> Add crop ioctl ops. For VPE, cropping only makes sense with the
> input
> >> to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
> >>
> >> For the CAPTURE type, a S_CROP ioctl results in setting the crop
> >> region as the whole image itself, hence making crop dimensions same
> as the pix dimensions.
> >>
> >> Setting the crop successfully should result in re-configuration of
> >> those registers which are affected when either source or destination
> >> dimensions change, set_srcdst_params() is called for this purpose.
> >>
> >> Some standard crop parameter checks are done in __vpe_try_crop().
> >
> > Please use the selection ops instead: if you implement cropping with
> > those then you'll support both the selection API and the old cropping
> > API will be implemented by the v4l2 core using the selection ops. Two
> for the price of one...
> 
> 
> 
> Thanks for the feedback. I'll use selection ops here.

>From your reply I understand that you will send a v2 of these patches,
right?
If so, please correct the typos I mentioned in the patch 5/7.

Also, it is quite late for v3.15. I did already send a pull request to
Mauro,
However I have one patch pending. Could you tell me when are you planning to
post v2 of these patches? I want to decide whether should I wait for your
patchset or should I send the second pull request with the pending patch
as soon as possible.
 

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland


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


Re: [PATCH v5 0/6] Make dwc3 use Generic PHY Framework

2014-03-03 Thread Roger Quadros
Hi Kishon,

Which tree are these patches based on?

cheers,
-roger

On 03/03/2014 01:38 PM, Kishon Vijay Abraham I wrote:
> Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3
> should be programmed. While this can be considered as a temporary fix,
> a long term solution would be to add 'nop' PHY for platforms that does
> not have programmable PHY.
> Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the
> name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to
> be used for SATA and PCIE too.
> 
> Changes from v4: (sending the entire patch series again)
> * check the return values of phy_init and phy_power_on
> * print errors if power_on or power_off of PHY fails.
> 
> Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) 
> * avoided using quirks and rely on the return values of PHY APIs to find the
> presence of PHY.
> 
> Changes from v2:
> * added a couple of fixes. One is invoking phy_resume after phy_init and the
> other is power off phy in error patch
> * used quirks to identify if a particular platform does not have PHYs
> * removed using separate header for pipe3 driver and also removed all 
> referencs
> to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers.
> 
> Changes from v1:
> * The logic in which the driver detects the presence of PHYs has changed.
> * patch ordering has changed
> * udelay is replaced with usleep_range
> * A patch to remove set_suspend callback which was deferred from Generic
> PHY Framework series has been included.
> 
> Kishon Vijay Abraham I (6):
>   usb: dwc3: core: support optional PHYs
>   usb: dwc3: adapt dwc3 core to use Generic PHY Framework
>   drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
>   usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
>   phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
>   arm/dts: added dt properties to adapt to the new phy framwork
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
>  arch/arm/boot/dts/omap5.dtsi   |5 +-
>  drivers/phy/Kconfig|   11 +
>  drivers/phy/Makefile   |1 +
>  drivers/phy/phy-omap-usb2.c|   27 +--
>  .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} |  240 
> 
>  drivers/usb/dwc3/core.c|  116 +++---
>  drivers/usb/dwc3/core.h|7 +
>  drivers/usb/phy/Kconfig|   11 -
>  drivers/usb/phy/Makefile   |1 -
>  include/linux/{usb => phy}/omap_usb.h  |3 -
>  11 files changed, 264 insertions(+), 164 deletions(-)
>  rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%)
>  rename include/linux/{usb => phy}/omap_usb.h (95%)
> 

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


Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver

2014-03-03 Thread Archit Taneja

Hi,

On Monday 03 March 2014 05:51 PM, Kamil Debski wrote:

Hi Archit,


From: Archit Taneja [mailto:arc...@ti.com]
Sent: Monday, March 03, 2014 9:26 AM

Hi,

On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote:

Hi Archit!

On 03/03/2014 08:33 AM, Archit Taneja wrote:

Add crop ioctl ops. For VPE, cropping only makes sense with the

input

to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.

For the CAPTURE type, a S_CROP ioctl results in setting the crop
region as the whole image itself, hence making crop dimensions same

as the pix dimensions.


Setting the crop successfully should result in re-configuration of
those registers which are affected when either source or destination
dimensions change, set_srcdst_params() is called for this purpose.

Some standard crop parameter checks are done in __vpe_try_crop().


Please use the selection ops instead: if you implement cropping with
those then you'll support both the selection API and the old cropping
API will be implemented by the v4l2 core using the selection ops. Two

for the price of one...



Thanks for the feedback. I'll use selection ops here.


 From your reply I understand that you will send a v2 of these patches,
right?
If so, please correct the typos I mentioned in the patch 5/7.

Also, it is quite late for v3.15. I did already send a pull request to
Mauro,
However I have one patch pending. Could you tell me when are you planning to
post v2 of these patches? I want to decide whether should I wait for your
patchset or should I send the second pull request with the pending patch
as soon as possible.


I'll post a v2 of this set by tomorrow(India time). I have worked on a 
patch which converts it to selection ioctls, but I need to test it, and 
get some comments on whether I have implemented the selection ops 
correctly.


Thanks,
Archit


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


Re: [PATCH v5 0/6] Make dwc3 use Generic PHY Framework

2014-03-03 Thread Kishon Vijay Abraham I

Roger,

On Monday 03 March 2014 05:51 PM, Roger Quadros wrote:

Hi Kishon,

Which tree are these patches based on?


mainline + Felipe's testing/next + Revert "usb: dwc3: core: enable 
Suspend bit for USB2/3 PHYs" + Revert "usb: dwc3: preparation for 
adapting dwc3 to generic phy framework"


Thanks
Kishon



cheers,
-roger

On 03/03/2014 01:38 PM, Kishon Vijay Abraham I wrote:

Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3
should be programmed. While this can be considered as a temporary fix,
a long term solution would be to add 'nop' PHY for platforms that does
not have programmable PHY.
Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the
name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to
be used for SATA and PCIE too.

Changes from v4: (sending the entire patch series again)
* check the return values of phy_init and phy_power_on
* print errors if power_on or power_off of PHY fails.

Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework)
* avoided using quirks and rely on the return values of PHY APIs to find the
presence of PHY.

Changes from v2:
* added a couple of fixes. One is invoking phy_resume after phy_init and the
other is power off phy in error patch
* used quirks to identify if a particular platform does not have PHYs
* removed using separate header for pipe3 driver and also removed all referencs
to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers.

Changes from v1:
* The logic in which the driver detects the presence of PHYs has changed.
* patch ordering has changed
* udelay is replaced with usleep_range
* A patch to remove set_suspend callback which was deferred from Generic
PHY Framework series has been included.

Kishon Vijay Abraham I (6):
   usb: dwc3: core: support optional PHYs
   usb: dwc3: adapt dwc3 core to use Generic PHY Framework
   drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
   usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
   phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
   arm/dts: added dt properties to adapt to the new phy framwork

  Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
  arch/arm/boot/dts/omap5.dtsi   |5 +-
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-omap-usb2.c|   27 +--
  .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} |  240 
  drivers/usb/dwc3/core.c|  116 +++---
  drivers/usb/dwc3/core.h|7 +
  drivers/usb/phy/Kconfig|   11 -
  drivers/usb/phy/Makefile   |1 -
  include/linux/{usb => phy}/omap_usb.h  |3 -
  11 files changed, 264 insertions(+), 164 deletions(-)
  rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%)
  rename include/linux/{usb => phy}/omap_usb.h (95%)




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


Re: [PATCH 5/7] v4l: ti-vpe: Allow usage of smaller images

2014-03-03 Thread Archit Taneja

Hi,

On Monday 03 March 2014 05:44 PM, Kamil Debski wrote:

Hi Archit,


From: Archit Taneja [mailto:arc...@ti.com]
Sent: Monday, March 03, 2014 8:33 AM

The minimum width and height for VPE input/output was kept as 128
pixels. VPE doesn't have a constraint on the image height, it requires
the image width to be atleast 16 bytes.


"16 bytes" - shouldn't it be pixels? (also "at least" :) )
I can correct it when applying the patch if the above is the case.


VPDMA IP requires the line stride of the input/output images to be at 
least 16 bytes in total.


This can safely result in a minimum width of 16 pixels(NV12 has the 
least bpp with 1 byte per pixel). But we don't really have any need to 
support such small image resolutions. So I picked up 32x32 as the 
minimum size, and tested VPE with that.


Thanks,
Archit

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


Re: [PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY

2014-03-03 Thread Florian Vaussard
Hi Roger,

On 03/03/2014 12:03 PM, Roger Quadros wrote:
> Hi Florian,
> 
> 
> On 03/03/2014 11:34 AM, Florian Vaussard wrote:
>> Add the High-Speed USB PHY.
>>
>> Signed-off-by: Florian Vaussard 
>> ---
>>  arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++
>>  arch/arm/boot/dts/omap3-overo-tobi.dts   | 16 ++
>>  arch/arm/boot/dts/omap3-overo.dtsi   | 44 
>> 
>>  3 files changed, 76 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
>> b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>> index 2033b52..eb93e3a 100644
>> --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>> @@ -21,6 +21,22 @@
>>  };
>>  
>>  &omap3_pmx_core2 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +&hsusb2_2_pins
>> +>;
>> +
>> +hsusb2_2_pins: pinmux_hsusb2_2_pins {
>> +pinctrl-single,pins = <
>> +OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
>> /* etk_d10.hsusb2_clk */
>> +OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
>> /* etk_d11.hsusb2_stp */
>> +OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d12.hsusb2_dir */
>> +OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d13.hsusb2_nxt */
>> +OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d14.hsusb2_data0 */
>> +OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d15.hsusb2_data1 */
>> +>;
>> +};
>> +
>>  w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
>>  pinctrl-single,pins = <
>>  OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
>> /* etk_d2.gpio_16 */
>> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
>> b/arch/arm/boot/dts/omap3-overo-tobi.dts
>> index 21de31d..e77be26 100644
>> --- a/arch/arm/boot/dts/omap3-overo-tobi.dts
>> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
>> @@ -21,6 +21,22 @@
>>  };
>>  
>>  &omap3_pmx_core2 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +&hsusb2_2_pins
>> +>;
>> +
>> +hsusb2_2_pins: pinmux_hsusb2_2_pins {
>> +pinctrl-single,pins = <
>> +OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
>> /* etk_d10.hsusb2_clk */
>> +OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
>> /* etk_d11.hsusb2_stp */
>> +OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d12.hsusb2_dir */
>> +OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d13.hsusb2_nxt */
>> +OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d14.hsusb2_data0 */
>> +OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
>> MUX_MODE3)/* etk_d15.hsusb2_data1 */
>> +>;
>> +};
>> +
>>  w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
>>  pinctrl-single,pins = <
>>  OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
>> /* etk_d2.gpio_16 */
>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
>> b/arch/arm/boot/dts/omap3-overo.dtsi
>> index 07467cc..8f810db 100644
>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>> @@ -30,6 +30,24 @@
>>  ti,codec = <&twl_audio>;
>>  };
>>  
>> +/* HS USB Port 2 Power */
>> +hsusb2_power: hsusb2_power_reg {
>> +compatible = "regulator-fixed";
>> +regulator-name = "hsusb2_vbus";
>> +regulator-min-microvolt = <500>;
>> +regulator-max-microvolt = <500>;
>> +gpio = <&gpio6 8 0>;/* gpio_168: 
>> vbus enable */
>> +startup-delay-us = <7>;
>> +enable-active-high;
>> +};
>> +
>> +/* HS USB Host PHY on PORT 2 */
>> +hsusb2_phy: hsusb2_phy {
>> +compatible = "usb-nop-xceiv";
>> +reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>;  /* gpio_183 */
>> +vcc-supply = <&hsusb2_power>;
>> +};
>> +
>>  /* Regulator to trigger the nPoweron signal of the Wifi module */
>>  w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
>>  compatible = "regulator-fixed";
>> @@ -64,6 +82,11 @@
>>  };
>>  
>>  &omap3_pmx_core {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +&hsusb2_pins
>> +>;
>> +
>>  uart3_pins: pinmux_uart3_pins {
>>  pinctrl-single,pins = <
>>  OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
>> PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
>> @@ -107,6 +130,19 @@
>>  OMAP3_CORE1_IOPAD(0x219c

Re: [PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY

2014-03-03 Thread Roger Quadros

On 03/03/2014 02:48 PM, Florian Vaussard wrote:
> Hi Roger,
> 
> On 03/03/2014 12:03 PM, Roger Quadros wrote:
>> Hi Florian,
>>
>>
>> On 03/03/2014 11:34 AM, Florian Vaussard wrote:
>>> Add the High-Speed USB PHY.
>>>
>>> Signed-off-by: Florian Vaussard 
>>> ---
>>>  arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++
>>>  arch/arm/boot/dts/omap3-overo-tobi.dts   | 16 ++
>>>  arch/arm/boot/dts/omap3-overo.dtsi   | 44 
>>> 
>>>  3 files changed, 76 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts 
>>> b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>>> index 2033b52..eb93e3a 100644
>>> --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>>> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts
>>> @@ -21,6 +21,22 @@
>>>  };
>>>  
>>>  &omap3_pmx_core2 {
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <
>>> +   &hsusb2_2_pins
>>> +   >;
>>> +
>>> +   hsusb2_2_pins: pinmux_hsusb2_2_pins {
>>> +   pinctrl-single,pins = <
>>> +   OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
>>> /* etk_d10.hsusb2_clk */
>>> +   OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
>>> /* etk_d11.hsusb2_stp */
>>> +   OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d12.hsusb2_dir */
>>> +   OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d13.hsusb2_nxt */
>>> +   OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d14.hsusb2_data0 */
>>> +   OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d15.hsusb2_data1 */
>>> +   >;
>>> +   };
>>> +
>>> w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
>>> pinctrl-single,pins = <
>>> OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
>>> /* etk_d2.gpio_16 */
>>> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts 
>>> b/arch/arm/boot/dts/omap3-overo-tobi.dts
>>> index 21de31d..e77be26 100644
>>> --- a/arch/arm/boot/dts/omap3-overo-tobi.dts
>>> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
>>> @@ -21,6 +21,22 @@
>>>  };
>>>  
>>>  &omap3_pmx_core2 {
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <
>>> +   &hsusb2_2_pins
>>> +   >;
>>> +
>>> +   hsusb2_2_pins: pinmux_hsusb2_2_pins {
>>> +   pinctrl-single,pins = <
>>> +   OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
>>> /* etk_d10.hsusb2_clk */
>>> +   OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
>>> /* etk_d11.hsusb2_stp */
>>> +   OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d12.hsusb2_dir */
>>> +   OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d13.hsusb2_nxt */
>>> +   OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d14.hsusb2_data0 */
>>> +   OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | 
>>> MUX_MODE3)/* etk_d15.hsusb2_data1 */
>>> +   >;
>>> +   };
>>> +
>>> w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins {
>>> pinctrl-single,pins = <
>>> OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4)
>>> /* etk_d2.gpio_16 */
>>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi 
>>> b/arch/arm/boot/dts/omap3-overo.dtsi
>>> index 07467cc..8f810db 100644
>>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>>> @@ -30,6 +30,24 @@
>>> ti,codec = <&twl_audio>;
>>> };
>>>  
>>> +   /* HS USB Port 2 Power */
>>> +   hsusb2_power: hsusb2_power_reg {
>>> +   compatible = "regulator-fixed";
>>> +   regulator-name = "hsusb2_vbus";
>>> +   regulator-min-microvolt = <500>;
>>> +   regulator-max-microvolt = <500>;
>>> +   gpio = <&gpio6 8 0>;/* gpio_168: 
>>> vbus enable */
>>> +   startup-delay-us = <7>;
>>> +   enable-active-high;
>>> +   };
>>> +
>>> +   /* HS USB Host PHY on PORT 2 */
>>> +   hsusb2_phy: hsusb2_phy {
>>> +   compatible = "usb-nop-xceiv";
>>> +   reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>;  /* gpio_183 */
>>> +   vcc-supply = <&hsusb2_power>;
>>> +   };
>>> +
>>> /* Regulator to trigger the nPoweron signal of the Wifi module */
>>> w3cbw003c_npoweron: regulator-w3cbw003c-npoweron {
>>> compatible = "regulator-fixed";
>>> @@ -64,6 +82,11 @@
>>>  };
>>>  
>>>  &omap3_pmx_core {
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <
>>> +   &hsusb2_pins
>>> +   >;
>>> +
>>> uart3_pins: pinmux_uart3_pins {
>>> pinctrl-single,pins = <
>>> OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | 
>>> PIN_OFF_WAKEUPENABLE 

[PATCH 5/5] doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue

2014-03-03 Thread George Cherian
Add the compatible "ti,am437x-dwc3" for dwc3 glue driver.

Signed-off-by: George Cherian 
---
 Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index c495135..1d38569 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -44,7 +44,9 @@ Board specific device node entry
 };
 
 OMAP DWC3 GLUE
- - compatible : Should be "ti,dwc3"
+ - compatible : Should be
+   * "ti,dwc3" for OMAP5 and DRA7
+   * "ti,am437x-dwc3" for AM437x
  - ti,hwmods : Should be "usb_otg_ss"
  - reg : Address and length of the register set for the device.
  - interrupts : The irq number of this device that is used to interrupt the
-- 
1.8.3.1

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


[PATCH 4/5] ARM: dts: am43x-epos-evm: Enable USB

2014-03-03 Thread George Cherian
Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB

for am43x-epos-evm

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index a7d0db1..165026b 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -251,3 +251,47 @@
pinctrl-0 = <&spi1_pins>;
status = "okay";
 };
+
+&am43xx_control_usb2phy1 {
+   status = "okay";
+};
+
+&ocp2scp0 {
+   status = "okay";
+};
+
+&usb2_phy1 {
+   status = "okay";
+};
+
+&dwc3_1 {
+   status = "okay";
+};
+
+&usb1 {
+   dr_mode = "peripheral";
+   maximum-speed = "high-speed";
+   status = "okay";
+};
+
+&am43xx_control_usb2phy2 {
+   status = "okay";
+};
+
+&ocp2scp1 {
+   status = "okay";
+};
+
+&usb2_phy2 {
+   status = "okay";
+};
+
+&dwc3_2 {
+   status = "okay";
+};
+
+&usb2 {
+   dr_mode = "host";
+   maximum-speed = "high-speed";
+   status = "okay";
+};
-- 
1.8.3.1

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


[PATCH 3/5] ARM: dts: am437x-gp-evm: Enable USB

2014-03-03 Thread George Cherian
Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for am437x-gp-evm

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 44 +
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 4eb72b8..89e08cd 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,3 +98,47 @@
 &gpio4 {
status = "okay";
 };
+
+&am43xx_control_usb2phy1 {
+   status = "okay";
+};
+
+&ocp2scp0 {
+   status = "okay";
+};
+
+&usb2_phy1 {
+   status = "okay";
+};
+
+&dwc3_1 {
+   status = "okay";
+};
+
+&usb1 {
+   dr_mode = "peripheral";
+   maximum-speed = "high-speed";
+   status = "okay";
+};
+
+&am43xx_control_usb2phy2 {
+   status = "okay";
+};
+
+&ocp2scp1 {
+   status = "okay";
+};
+
+&usb2_phy2 {
+   status = "okay";
+};
+
+&dwc3_2 {
+   status = "okay";
+};
+
+&usb2 {
+   dr_mode = "host";
+   maximum-speed = "high-speed";
+   status = "okay";
+};
-- 
1.8.3.1

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


[PATCH 2/5] ARM: dts: AM4372: Add USB nodes

2014-03-03 Thread George Cherian
Add nodes for 2 instances each of
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB

for AM43xx.

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/am4372.dtsi | 99 +++
 1 file changed, 99 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5a7cc38..90408b3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -698,6 +698,105 @@
   <&edma 11>;
dma-names = "tx", "rx";
};
+
+   am43xx_control_usb2phy1: control-phy@44e10620 {
+   compatible = "ti,control-phy-am437usb2";
+   reg = <0x44e10620 0x4>;
+   reg-names = "power";
+   status = "disabled";
+   };
+
+   am43xx_control_usb2phy2: control-phy@0x44e10628 {
+   compatible = "ti,control-phy-am437usb2";
+   reg = <0x44e10628 0x4>;
+   reg-names = "power";
+   status = "disabled";
+   };
+
+   ocp2scp0: ocp2scp@483a8000 {
+   compatible = "ti,omap-ocp2scp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   ti,hwmods = "ocp2scp0";
+   status = "disabled";
+
+   usb2_phy1: usb2phy1@483a8000 {
+   compatible = "ti,am437x-usb2";
+   reg = <0x483a8000 0x8000>;
+   ctrl-module = <&am43xx_control_usb2phy1>;
+   clocks = <&clk_32768_ck>,
+<&usb_otg_ss0_refclk960m>;
+   clock-names = "usb_phy_cm_clk32k",
+ "usb_otg_ss_refclk960m";
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+   };
+
+   ocp2scp1: ocp2scp@483e8000 {
+   compatible = "ti,omap-ocp2scp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   ti,hwmods = "ocp2scp1";
+   status = "disabled";
+
+   usb2_phy2: usb2phy2@483e8000 {
+   compatible = "ti,am437x-usb2";
+   reg = <0x483e8000 0x8000>;
+   ctrl-module = <&am43xx_control_usb2phy2>;
+   clocks = <&clk_32768_ck>,
+<&usb_otg_ss1_refclk960m>;
+   clock-names = "usb_phy_cm_clk32k",
+ "usb_otg_ss_refclk960m";
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+   };
+
+   dwc3_1: omap_dwc3_1@4838 {
+   compatible = "ti,am437x-dwc3";
+   ti,hwmods = "usb_otg_ss0";
+   reg = <0x4838 0x1>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   utmi-mode = <1>;
+   ranges;
+   status = "disabled";
+
+   usb1: usb@4839 {
+   compatible = "synopsys,dwc3";
+   reg = <0x4839 0x17000>;
+   interrupts = ;
+   usb-phy = <&usb2_phy1>;
+   phy-names = "usb2-phy";
+   status = "disabled";
+   };
+   };
+
+   dwc3_2: omap_dwc3_2@483c {
+   compatible = "ti,am437x-dwc3";
+   ti,hwmods = "usb_otg_ss1";
+   reg = <0x483c 0x1>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   utmi-mode = <1>;
+   ranges;
+   status = "disabled";
+
+   usb2: usb@483d {
+   compatible = "synopsys,dwc3";
+   reg = <0x483d 0x17000>;
+   interrupts = ;
+   usb-phy = <&usb2_phy2>;
+   phy-names = "usb2-phy";
+   status = "disabled";
+   };
+   };
+
};
 };
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsu

[PATCH 1/5] ARM: dts: am43xx clock data

2014-03-03 Thread George Cherian
Add USB reference clock data

Signed-off-by: George Cherian 
---
 arch/arm/boot/dts/am43xx-clocks.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..506d036 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,21 @@
clocks = <&clk_32768_ck>, <&clk_32k_tpm_ck>;
reg = <0x4260>;
};
+
+   usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&dpll_per_clkdcoldo>;
+   ti,bit-shift = <8>;
+   reg = <0x8a60>;
+   };
+
+   usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+   #clock-cells = <0>;
+   compatible = "ti,gate-clock";
+   clocks = <&dpll_per_clkdcoldo>;
+   ti,bit-shift = <8>;
+   reg = <0x8a68>;
+   };
+
 };
-- 
1.8.3.1

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


[PATCH 0/5] Add USB nodes for am43xx epos and gp evm

2014-03-03 Thread George Cherian
The patch series adds USB dt nodes for am43xx epos and gp evm

Boot tested with  Benoit's for_3.15 + following patches

https://patchwork.kernel.org/patch/3600821/
https://patchwork.kernel.org/patch/3600831/
https://patchwork.kernel.org/patch/3600851/
https://patchwork.kernel.org/patch/3600841/



George Cherian (5):
  ARM: dts: am43xx clock data
  ARM: dts: AM4372: Add USB nodes
  ARM: dts: am437x-gp-evm: Enable USB
  ARM: dts: am43x-epos-evm: Enable USB
  doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue

 Documentation/devicetree/bindings/usb/omap-usb.txt |  4 +-
 arch/arm/boot/dts/am4372.dtsi  | 99 ++
 arch/arm/boot/dts/am437x-gp-evm.dts| 44 ++
 arch/arm/boot/dts/am43x-epos-evm.dts   | 44 ++
 arch/arm/boot/dts/am43xx-clocks.dtsi   | 17 
 5 files changed, 207 insertions(+), 1 deletion(-)

-- 
1.8.3.1

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


RE: Help needed USB hub disconnected at resume

2014-03-03 Thread Marc Murphy
Hi Igor

The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port 
via the DUP_P and DUP_N pins.  There is a reset applied to the chip at power on.

Regards
Marc

From: Igor Grinberg [grinb...@compulab.co.il]
Sent: 03 March 2014 12:16
To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org
Subject: Re: Help needed USB hub disconnected at resume

On 03/03/14 13:06, Roger Quadros wrote:
> Hi Marc,
>
> On 03/03/2014 12:04 PM, Marc Murphy wrote:
>> Hi,
>> I am using the latest stable 3.4.80 kernel with some changes to get the EMAC 
>> Phy to initialise correctly after a suspend/resume.  The platform is AM3517 
>> with most of the system working nice and smoothly. I have 1 issue though and 
>> need some advice/help to get the system to use the USB hub I have connected 
>> to the EHCI controller after a suspend to memory and resume.
>>
>> At boot all is recognised;
>>
>> [1.486816] usbcore: registered new interface driver cdc_ether
>> [1.493255] usbcore: registered new interface driver cdc_ncm
>> [1.499450] usbcore: registered new interface driver qmi_wwan
>> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator
>> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
>> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus 
>> number 1
>> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
>> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
>> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, 
>> SerialNumber=1
>> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller
>> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd
>> [2.585296] usb usb1: SerialNumber: ehci-omap.0
>> [2.591278] hub 1-0:1.0: USB hub found
>> [2.595306] hub 1-0:1.0: 3 ports detected
>>
>> And I can see everything OK.
>>
>> # lsusb
>> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc.
>> #
>> #
>> # echo mem > /sys/power/state
>> [   73.736572] PM: Syncing filesystems ... done.
>> [   73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done.
>> [   73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) 
>> done.
>> [   73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle
>> [   73.968872] PM: suspend of devices complete after 170.410 msecs
>> [   73.975433] PM: late suspend of devices complete after 0.305 msecs
>> [   73.982635] PM: noirq suspend of devices complete after 0.732 msecs
>> [   83.430450] Powerdomain (core_pwrdm) didn't enter target state 1
>> [   83.436737] Could not enter target state in pm_suspend
>> [   83.443176] PM: noirq resume of devices complete after 0.915 msecs
>>  [   83.450164] PM: early resume of devices complete after 0.274 msecs
>> [   83.457336] <6>Waiting for PHY clock good...
>> [   83.463287] davinci_mdio davinci_mdio.0: resetting idled controller
>> [   83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] 
>> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
>> [   84.771881] PM: resume of devices complete after 1315.185 msecs
>> [   84.778472] Restarting tasks ...
>> [   84.782379] usb 1-1: USB disconnect, device number 2
>> [   84.790557] done.
>> [   84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
>> sh: write error:[   84.800781] usb 1-1.1: USB disconnect, device number 3
>>  Operation not p[   84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 
>> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device
>> ermitted
>> [   84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz
>> [   86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full
>> #
>> #
>> # lsusb
>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> #
>>
>> Is there any relevant patch out there that would address the issue that I 
>> see ?
>
> Does this happen because of OFF mode?
> Can you please try the tests with off mode disabled?
>
> e.g.
> mount -t debugfs none /sys/kernel/debug
> echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode
> suspend & resume

AFAIK, AM3517 does not have OFF mode.
We had something similar with runtime pm...
It might be useful to know which hub is this and how is it connected...

>
> Also please send the output of /sys/kernel/debug/pm_debug/count
> before suspend and after resume. Thanks.



--
Regards,
Igor.
--
To unsubscribe from this

Re: [PATCH RESEND v11 6/7] ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig

2014-03-03 Thread Balaji T K

On Wednesday 26 February 2014 10:31 PM, Tony Lindgren wrote:

* Balaji T K  [140219 07:00]:

Enable REGULATOR_PBIAS needed for SD card on most OMAPs.

Signed-off-by: Balaji T K 


I belive this is the only one missing my ack:

Acked-by: Tony Lindgren 



Thanks Tony


Probably best that this all gets queued along with other MMC related
patches by Balaji and Chris.


Hi Chris,

Can you please pull this patch series for 3.15?

Thanks and Regards,
Balaji T K




---
  arch/arm/configs/omap2plus_defconfig |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 3a0b53d..e4fec1c 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -169,6 +169,7 @@ CONFIG_DRA752_THERMAL=y
  CONFIG_WATCHDOG=y
  CONFIG_OMAP_WATCHDOG=y
  CONFIG_TWL4030_WATCHDOG=y
+CONFIG_MFD_SYSCON=y
  CONFIG_MFD_PALMAS=y
  CONFIG_MFD_TPS65217=y
  CONFIG_MFD_TPS65910=y
@@ -180,6 +181,7 @@ CONFIG_REGULATOR_TPS6507X=y
  CONFIG_REGULATOR_TPS65217=y
  CONFIG_REGULATOR_TPS65910=y
  CONFIG_REGULATOR_TWL4030=y
+CONFIG_REGULATOR_PBIAS=y
  CONFIG_FB=y
  CONFIG_FIRMWARE_EDID=y
  CONFIG_FB_MODE_HELPERS=y
--
1.7.5.4

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


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


[RESEND Patch 6/9] ARM: dts: DRA7: Add device nodes for ABB

2014-03-03 Thread Mugunthan V N
From: Nishanth Menon 

Add ABB device nodes for DRA7 family of devices. Data is based on
DRA7 Technical Reference Manual revision I (Sept 2013)

Signed-off-by: Nishanth Menon 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 132 
 1 file changed, 132 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 499974a..9e3caf3 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -578,6 +578,138 @@
status = "disabled";
};
 
+   abb_mpu: regulator-abb-mpu {
+   compatible = "ti,abb-v3";
+   regulator-name = "abb_mpu";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   clocks = <&sys_clkin1>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   reg = <0x4ae07ddc 0x4>, <0x4ae07de0 0x4>,
+ <0x4ae06014 0x4>, <0x4a003b20 0x8>,
+ <0x4ae0c158 0x4>;
+   reg-names = "setup-address", "control-address",
+   "int-address", "efuse-address",
+   "ldo-address";
+   ti,tranxdone-status-mask = <0x80>;
+   /* LDOVBBMPU_FBB_MUX_CTRL */
+   ti,ldovbb-override-mask = <0x400>;
+   /* LDOVBBMPU_FBB_VSET_OUT */
+   ti,ldovbb-vset-mask = <0x1F>;
+
+   /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+   ti,abb_info = <
+   /*uVABB efuse   rbb_m fbb_m vset_m*/
+   106 0   0x0 0 0x0200 0x01F0
+   116 0   0x4 0 0x0200 0x01F0
+   121 0   0x8 0 0x0200 0x01F0
+   >;
+   };
+
+   abb_ivahd: regulator-abb-ivahd {
+   compatible = "ti,abb-v3";
+   regulator-name = "abb_ivahd";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   clocks = <&sys_clkin1>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   reg = <0x4ae07e34 0x4>, <0x4ae07e24 0x4>,
+ <0x4ae06010 0x4>, <0x4a0025cc 0x8>,
+ <0x4a002470 0x4>;
+   reg-names = "setup-address", "control-address",
+   "int-address", "efuse-address",
+   "ldo-address";
+   ti,tranxdone-status-mask = <0x4000>;
+   /* LDOVBBIVA_FBB_MUX_CTRL */
+   ti,ldovbb-override-mask = <0x400>;
+   /* LDOVBBIVA_FBB_VSET_OUT */
+   ti,ldovbb-vset-mask = <0x1F>;
+
+   /*
+* NOTE: only FBB mode used but actual vset will
+* determine final biasing
+*/
+   ti,abb_info = <
+   /*uVABB efuse   rbb_m fbb_m vset_m*/
+   1055000 0   0x0 0 0x0200 0x01F0
+   115 0   0x4 0 0x0200 0x01F0
+   125 0   0x8 0 0x0200 0x01F0
+   >;
+   };
+
+   abb_dspeve: regulator-abb-dspeve {
+   compatible = "ti,abb-v3";
+   regulator-name = "abb_dspeve";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   clocks = <&sys_clkin1>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   reg = <0x4ae07e30 0x4>, <0x4ae07e20 0x4>,
+ <0x4ae06010 0x4>, <0x4a0025e0 0x8>,
+ <0x4a00246c 0x4>;
+   reg-names = "setup-address", "control-address",
+   "int-address", "efuse-address",
+   "ldo-address";
+   ti,tranxdone-status-mask = <0x2000>;
+   /* LDOVBBDSPEVE_FBB_MUX_CTRL */
+   ti,ldovbb-override-mask = <0x400>;
+   /* LDOVBBDSPEVE_FBB_VSET_OUT */
+   ti,ldovbb-vset-mask = <0x1F>;
+
+   /*
+* NOTE: only FBB mode used but actual vset will
+

[RESEND Patch 9/9] ARM: DTS: DRA7: Add routable-irqs property for gic node

2014-03-03 Thread Mugunthan V N
From: Sricharan R 

There is a IRQ crossbar device in the soc, which maps the
irq requests from the peripherals to the mpu interrupt
controller's inputs. The gic provides the support for such
IPs in the form of routable-irqs. So adding the property
here to gic node.

Cc: Benoit Cousson 
Cc: Santosh Shilimkar 
Cc: Rajendra Nayak 
Cc: Tony Lindgren 
Signed-off-by: Sricharan R 
Acked-by: Santosh Shilimkar 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 2bd3a9a..824e316 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -72,6 +72,7 @@
compatible = "arm,cortex-a15-gic";
interrupt-controller;
#interrupt-cells = <3>;
+   arm,routable-irqs = <160>;
reg = <0x48211000 0x1000>,
  <0x48212000 0x1000>,
  <0x48214000 0x2000>,
-- 
1.9.0

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


[RESEND Patch 8/9] ARM: DTS: DRA7: Replace peripheral interrupt numbers with crossbar inputs

2014-03-03 Thread Mugunthan V N
From: Sricharan R 

Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.

Cc: Benoit Cousson 
Cc: Santosh Shilimkar 
Cc: Rajendra Nayak 
Cc: Tony Lindgren 
Signed-off-by: Sricharan R 
Acked-by: Santosh Shilimkar 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 86 ++---
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 88fc2eb..2bd3a9a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -166,10 +166,10 @@
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
-   interrupts = ,
-,
-,
-;
+   interrupts = ,
+,
+,
+;
#dma-cells = <1>;
#dma-channels = <32>;
#dma-requests = <127>;
@@ -178,7 +178,7 @@
gpio1: gpio@4ae1 {
compatible = "ti,omap4-gpio";
reg = <0x4ae1 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -189,7 +189,7 @@
gpio2: gpio@48055000 {
compatible = "ti,omap4-gpio";
reg = <0x48055000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -200,7 +200,7 @@
gpio3: gpio@48057000 {
compatible = "ti,omap4-gpio";
reg = <0x48057000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -211,7 +211,7 @@
gpio4: gpio@48059000 {
compatible = "ti,omap4-gpio";
reg = <0x48059000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -222,7 +222,7 @@
gpio5: gpio@4805b000 {
compatible = "ti,omap4-gpio";
reg = <0x4805b000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -233,7 +233,7 @@
gpio6: gpio@4805d000 {
compatible = "ti,omap4-gpio";
reg = <0x4805d000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -244,7 +244,7 @@
gpio7: gpio@48051000 {
compatible = "ti,omap4-gpio";
reg = <0x48051000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -255,7 +255,7 @@
gpio8: gpio@48053000 {
compatible = "ti,omap4-gpio";
reg = <0x48053000 0x200>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
@@ -266,7 +266,7 @@
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
-   interrupts = ;
+   interrupts = ;
ti,hwmods = "uart1";
clock-frequency = <4800>;
status = "disabled";
@@ -275,7 +275,7 @@
uart2: serial@4806c000 {
compatible = "ti,omap4-uart";
reg = <0x4806c000 0x100>;
-   interrupts = ;
+   interrupts = ;
   

[RESEND Patch 5/9] ARM: dts: OMAP4: Add device nodes for ABB

2014-03-03 Thread Mugunthan V N
From: "Andrii.Tseglytskyi" 

Add ABB device nodes for OMAP443x family of devices. abb_iva is
populated, but disabled as it is not used on current OMAP443x family,
but the node is used on OMAP446x family. Data is based on OMAP443x
Technical Reference Manual revision AN (April 2013).

ABB device nodes for OMAP4460 device Data is based on OMAP4460
Technical Reference Manual revision Z (April 2013)

[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon 
Signed-off-by: Andrii.Tseglytskyi 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/omap4.dtsi| 26 ++
 arch/arm/boot/dts/omap443x.dtsi | 26 ++
 arch/arm/boot/dts/omap4460.dtsi | 37 +
 3 files changed, 89 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index afa23bc..c18f0fd 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -776,6 +776,32 @@
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
};
+
+   abb_mpu: regulator-abb-mpu {
+   compatible = "ti,abb-v2";
+   regulator-name = "abb_mpu";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   ti,tranxdone-status-mask = <0x80>;
+   clocks = <&sys_clkin_ck>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   status = "disabled";
+   };
+
+   abb_iva: regulator-abb-iva {
+   compatible = "ti,abb-v2";
+   regulator-name = "abb_iva";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   ti,tranxdone-status-mask = <0x8000>;
+   clocks = <&sys_clkin_ck>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   status = "disabled";
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 8c1cfad..0adfa1d 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -43,6 +43,32 @@
#thermal-sensor-cells = <0>;
};
};
+
+   ocp {
+   abb_mpu: regulator-abb-mpu {
+   status = "okay";
+
+   reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>;
+   reg-names = "base-address", "int-address";
+
+   ti,abb_info = <
+   /*uVABB efuse   rbb_m   fbb_m   vset_m*/
+   1025000 0   0   0   0   0
+   120 0   0   0   0   0
+   1313000 0   0   0   0   0
+   1375000 1   0   0   0   0
+   1389000 1   0   0   0   0
+   >;
+   };
+
+   /* Default unused, just provide register info for record */
+   abb_iva: regulator-abb-iva {
+   reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>;
+   reg-names = "base-address", "int-address";
+   };
+
+   };
+
 };
 
 /include/ "omap443x-clocks.dtsi"
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 6b32f52..194f9ef 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -50,7 +50,44 @@
 
#thermal-sensor-cells = <0>;
};
+
+   abb_mpu: regulator-abb-mpu {
+   status = "okay";
+
+   reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>,
+ <0x4A002268 0x4>;
+   reg-names = "base-address", "int-address",
+   "efuse-address";
+
+   ti,abb_info = <
+   /*uVABB efuse   rbb_m   fbb_m   vset_m*/
+   1025000 0   0   0   0   0
+   120 0   0   0   0   0
+   1313000 0   0   0x10 0x4 0
+   1375000 1   0   0   0   0
+   1389000 1   0   0   0   0
+   >;
+   };
+
+   abb_iva: regulator-abb-iva {
+   status = "okay";
+
+   reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>,
+ <0x4A002268 0x4>;
+   reg-names = "base-address", "int-address",
+   "efuse-address";
+
+   

[RESEND Patch 7/9] ARM: DTS: DRA7: Add crossbar device binding

2014-03-03 Thread Mugunthan V N
From: Sricharan R 

This adds the irq crossbar device node.

There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.

Cc: Benoit Cousson 
Cc: Santosh Shilimkar 
Cc: Rajendra Nayak 
Cc: Tony Lindgren 
Signed-off-by: Sricharan R 
Acked-by: Santosh Shilimkar 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9e3caf3..88fc2eb 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -773,6 +773,14 @@
status = "disabled";
};
};
+
+   crossbar_mpu: crossbar@4a02 {
+   compatible = "ti,irq-crossbar";
+   reg = <0x4a002a48 0x130>;
+   ti,max-irqs = <160>;
+   ti,reg-size = <2>;
+   ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+   };
 };
 
 /include/ "dra7xx-clocks.dtsi"
-- 
1.9.0

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


[RESEND Patch 0/9] dts pending patches for TI omap

2014-03-03 Thread Mugunthan V N
Benoit/Tony

Here I am send all the pending dt patches that can go into 3.15 merge window,
all the patches were already posted to mailing list and has beed reviewed.

I have rebased the patches on top of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
omap-for-v3.15/dt
and fixed all the merge conflicts.

Pasting the mail archive for the patches series

* Add ABB device nodes
http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html

* MMC hot plug support
http://mail.blameitonlove.com/lists/linux-omap/msg101933.html
Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as this
is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a

* DRA7 Cross bar DTS patches
Cross bar driver has been pulled for next merge, so the dts patches can also
be pulled for next merge window.

Here is the pull request for the same patch series.

The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84:

  Merge tag 'for_3.15/dts_signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into 
omap-for-v3.15/dt (2014-03-02 14:22:03 -0800)

are available in the git repository at:


  git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15

for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4:

  ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 19:53:25 
+0530)


Andrii.Tseglytskyi (2):
  ARM: dts: OMAP36xx: Add device node for ABB
  ARM: dts: OMAP4: Add device nodes for ABB

Balaji T K (3):
  ARM: dts: am437x gp-evm: add sd card dt nodes
  ARM: dts: am335x-evm: add SD card hotplug support
  ARM: dts: am43x-epos-evm: add SD card hotplug support

Nishanth Menon (1):
  ARM: dts: DRA7: Add device nodes for ABB

Sricharan R (3):
  ARM: DTS: DRA7: Add crossbar device binding
  ARM: DTS: DRA7: Replace peripheral interrupt numbers with crossbar inputs
  ARM: DTS: DRA7: Add routable-irqs property for gic node

 arch/arm/boot/dts/am335x-evm.dts |   9 ++
 arch/arm/boot/dts/am4372.dtsi|   1 +
 arch/arm/boot/dts/am437x-gp-evm.dts  |  27 +
 arch/arm/boot/dts/am43x-epos-evm.dts |   9 ++
 arch/arm/boot/dts/dra7.dtsi  | 227 ---
 arch/arm/boot/dts/omap36xx.dtsi  |  20 +++
 arch/arm/boot/dts/omap4.dtsi |  26 
 arch/arm/boot/dts/omap443x.dtsi  |  26 
 arch/arm/boot/dts/omap4460.dtsi  |  37 ++
 9 files changed, 339 insertions(+), 43 deletions(-)

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


[RESEND Patch 4/9] ARM: dts: OMAP36xx: Add device node for ABB

2014-03-03 Thread Mugunthan V N
From: "Andrii.Tseglytskyi" 

Add ABB device node for OMAP36xx family of devices. Data is based on
OMAP36XX Technical Reference Manual revision AB (Dec 2012).

[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon 
Signed-off-by: Andrii.Tseglytskyi 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/omap36xx.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 7e8dee9..ba077cd 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -39,6 +39,26 @@
clock-frequency = <4800>;
};
 
+   abb_mpu_iva: regulator-abb-mpu {
+   compatible = "ti,abb-v1";
+   regulator-name = "abb_mpu_iva";
+   #address-cell = <0>;
+   #size-cells = <0>;
+   reg = <0x483072f0 0x8>, <0x48306818 0x4>;
+   reg-names = "base-address", "int-address";
+   ti,tranxdone-status-mask = <0x400>;
+   clocks = <&sys_ck>;
+   ti,settling-time = <30>;
+   ti,clock-cycles = <8>;
+   ti,abb_info = <
+   /*uVABB efuse   rbb_m   fbb_m   vset_m*/
+   1012500 0   0   0   0   0
+   120 0   0   0   0   0
+   1325000 0   0   0   0   0
+   1375000 1   0   0   0   0
+   >;
+   };
+
omap3_pmx_core2: pinmux@480025a0 {
compatible = "ti,omap3-padconf", "pinctrl-single";
reg = <0x480025a0 0x5c>;
-- 
1.9.0

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


[RESEND Patch 2/9] ARM: dts: am335x-evm: add SD card hotplug support

2014-03-03 Thread Mugunthan V N
From: Balaji T K 

Add card detect gpio for SD card slot

Signed-off-by: Balaji T K 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am335x-evm.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 07d61bb..28ae040 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -260,6 +260,12 @@
>;
};
 
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
+   >;
+   };
+
lcd_pins_s0: lcd_pins_s0 {
pinctrl-single,pins = <
0x20 0x01   /* gpmc_ad8.lcd_data16, OUTPUT | MODE1 
*/
@@ -644,6 +650,9 @@
status = "okay";
vmmc-supply = <&vmmc_reg>;
bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc1_pins>;
+   cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
 };
 
 &sham {
-- 
1.9.0

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


[RESEND Patch 3/9] ARM: dts: am43x-epos-evm: add SD card hotplug support

2014-03-03 Thread Mugunthan V N
From: Balaji T K 

Add card detect gpio for SD card slot and include dt gpio header.

Signed-off-by: Balaji T K 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am4372.dtsi| 1 +
 arch/arm/boot/dts/am43x-epos-evm.dts | 9 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index b687869..36d523a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -8,6 +8,7 @@
  * kind, whether express or implied.
  */
 
+#include 
 #include 
 
 #include "skeleton.dtsi"
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index a3a53ce..167dbc8 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -132,6 +132,12 @@
0x19c (PIN_OUTPUT | MUX_MODE3)  /* 
mcasp0_ahclkr.spi1_cs0 */
>;
};
+
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   0x160 (PIN_INPUT | MUX_MODE7) /* 
spi0_cs1.gpio0_6 */
+   >;
+   };
};
 
matrix_keypad: matrix_keypad@0 {
@@ -179,6 +185,9 @@
status = "okay";
vmmc-supply = <&vmmcsd_fixed>;
bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc1_pins>;
+   cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
 };
 
 &mac {
-- 
1.9.0

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


[RESEND Patch 0/9] dts pending patches for TI omap

2014-03-03 Thread Mugunthan V N
Benoit/Tony

Here I am send all the pending patches that can go into 3.15 merge window,
all the patches were already posted to mailing list and has beed reviewed.

Here I am rebasing the patches on top of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git 
omap-for-v3.15/dt
and fixed all the merge conflicts.

Here I am pasting the mail archieve for the patches series

* Add ABB device nodes
http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html

* MMC hot plug support
http://mail.blameitonlove.com/lists/linux-omap/msg101933.html
Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as this
is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a

* DRA7 Cross bar DTS patches
Cross bar driver has been pulled for next merge, so the dts patches can also
be pulled for next merge window.

Here is the pull request for the same set.


The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84:

  Merge tag 'for_3.15/dts_signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into 
omap-for-v3.15/dt (2014-03-02 14:22:03 -0800)

are available in the git repository at:


  git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15

for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4:

  ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 19:53:25 
+0530)


Andrii.Tseglytskyi (2):
  ARM: dts: OMAP36xx: Add device node for ABB
  ARM: dts: OMAP4: Add device nodes for ABB

Balaji T K (3):
  ARM: dts: am437x gp-evm: add sd card dt nodes
  ARM: dts: am335x-evm: add SD card hotplug support
  ARM: dts: am43x-epos-evm: add SD card hotplug support

Nishanth Menon (1):
  ARM: dts: DRA7: Add device nodes for ABB

Sricharan R (3):
  ARM: DTS: DRA7: Add crossbar device binding
  ARM: DTS: DRA7: Replace peripheral interrupt numbers with crossbar inputs
  ARM: DTS: DRA7: Add routable-irqs property for gic node

 arch/arm/boot/dts/am335x-evm.dts |   9 ++
 arch/arm/boot/dts/am4372.dtsi|   1 +
 arch/arm/boot/dts/am437x-gp-evm.dts  |  27 +
 arch/arm/boot/dts/am43x-epos-evm.dts |   9 ++
 arch/arm/boot/dts/dra7.dtsi  | 227 ---
 arch/arm/boot/dts/omap36xx.dtsi  |  20 +++
 arch/arm/boot/dts/omap4.dtsi |  26 
 arch/arm/boot/dts/omap443x.dtsi  |  26 
 arch/arm/boot/dts/omap4460.dtsi  |  37 ++
 9 files changed, 339 insertions(+), 43 deletions(-)

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


[RESEND Patch 1/9] ARM: dts: am437x gp-evm: add sd card dt nodes

2014-03-03 Thread Mugunthan V N
From: Balaji T K 

enable sd card slot on am437x-gp-evm

Signed-off-by: Balaji T K 
Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 4eb72b8..df8798e 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -19,6 +19,14 @@
model = "TI AM437x GP EVM";
compatible = "ti,am437x-gp-evm","ti,am4372","ti,am43";
 
+   vmmcsd_fixed: fixedregulator-sd {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   enable-active-high;
+   };
+
backlight {
compatible = "pwm-backlight";
pwms = <&ecap0 0 5 PWM_POLARITY_INVERTED>;
@@ -62,6 +70,12 @@
>;
};
 
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
+   >;
+   };
+
ecap0_pins: backlight_pins {
pinctrl-single,pins = <
0x164 MUX_MODE0   /* 
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
@@ -91,6 +105,10 @@
pinctrl-0 = <&ecap0_pins>;
 };
 
+&gpio0 {
+   status = "okay";
+};
+
 &gpio3 {
status = "okay";
 };
@@ -98,3 +116,12 @@
 &gpio4 {
status = "okay";
 };
+
+&mmc1 {
+   status = "okay";
+   vmmc-supply = <&vmmcsd_fixed>;
+   bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc1_pins>;
+   cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+};
-- 
1.9.0

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


[PATCH 09/12] phy: ti-pipe3: streamline PHY operations

2014-03-03 Thread Roger Quadros
Limit .power_on() and .power_off() to just control the
PHY power and not the DPLL. The DPLL will be enabled
in .init() and idled in .exit().

Don't reprogram the DPLL if it has been already locked
by the bootloader. This fixes a problem with SATA, where
it fails if SATA was used by the bootloader.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-ti-pipe3.c | 114 +
 1 file changed, 63 insertions(+), 51 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index ee8871d..d3c085a 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -47,7 +47,8 @@
 #definePLL_SD_MASK 0x0003FC00
 #definePLL_SD_SHIFT10
 #defineSET_PLL_GO  0x1
-#definePLL_TICOPWDN0x1
+#define PLL_LDOPWDNBIT(15)
+#define PLL_TICOPWDN   BIT(16)
 #definePLL_LOCK0x2
 #definePLL_IDLE0x1
 
@@ -56,7 +57,8 @@
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
  * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
  */
-# define PLL_IDLE_TIME  100;
+#define PLL_IDLE_TIME  100 /* in milliseconds */
+#define PLL_LOCK_TIME  100 /* in milliseconds */
 
 struct pipe3_dpll_params {
u16 m;
@@ -132,24 +134,6 @@ static struct pipe3_dpll_params 
*ti_pipe3_get_dpll_params(struct ti_pipe3 *phy)
 static int ti_pipe3_power_off(struct phy *x)
 {
struct ti_pipe3 *phy = phy_get_drvdata(x);
-   int val;
-   int timeout = PLL_IDLE_TIME;
-
-   val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
-   val |= PLL_IDLE;
-   ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
-
-   do {
-   val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
-   if (val & PLL_TICOPWDN)
-   break;
-   udelay(5);
-   } while (--timeout);
-
-   if (!timeout) {
-   dev_err(phy->dev, "power off failed\n");
-   return -EBUSY;
-   }
 
omap_control_phy_power(phy->control_dev, 0);
 
@@ -159,44 +143,34 @@ static int ti_pipe3_power_off(struct phy *x)
 static int ti_pipe3_power_on(struct phy *x)
 {
struct ti_pipe3 *phy = phy_get_drvdata(x);
-   int val;
-   int timeout = PLL_IDLE_TIME;
-
-   val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
-   val &= ~PLL_IDLE;
-   ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
 
-   do {
-   val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
-   if (!(val & PLL_TICOPWDN))
-   break;
-   udelay(5);
-   } while (--timeout);
-
-   if (!timeout) {
-   dev_err(phy->dev, "power on failed\n");
-   return -EBUSY;
-   }
+   omap_control_phy_power(phy->control_dev, 1);
 
return 0;
 }
 
-static void ti_pipe3_dpll_relock(struct ti_pipe3 *phy)
+static int ti_pipe3_dpll_wait_lock(struct ti_pipe3 *phy)
 {
u32 val;
unsigned long   timeout;
 
-   ti_pipe3_writel(phy->pll_ctrl_base, PLL_GO, SET_PLL_GO);
-
-   timeout = jiffies + msecs_to_jiffies(20);
+   timeout = jiffies + msecs_to_jiffies(PLL_LOCK_TIME);
do {
+   cpu_relax();
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
if (val & PLL_LOCK)
break;
-   } while (!WARN_ON(time_after(jiffies, timeout)));
+   } while (!time_after(jiffies, timeout));
+
+   if (!(val & PLL_LOCK)) {
+   dev_err(phy->dev, "DPLL failed to lock\n");
+   return -EBUSY;
+   }
+
+   return 0;
 }
 
-static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy)
+static int ti_pipe3_dpll_program(struct ti_pipe3 *phy)
 {
u32 val;
struct pipe3_dpll_params *dpll_params;
@@ -230,27 +204,65 @@ static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy)
val |= dpll_params->sd << PLL_SD_SHIFT;
ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION3, val);
 
-   ti_pipe3_dpll_relock(phy);
+   ti_pipe3_writel(phy->pll_ctrl_base, PLL_GO, SET_PLL_GO);
 
-   return 0;
+   return ti_pipe3_dpll_wait_lock(phy);
 }
 
 static int ti_pipe3_init(struct phy *x)
 {
struct ti_pipe3 *phy = phy_get_drvdata(x);
-   int ret;
+   u32 val;
+   int ret = 0;
 
-   ret = ti_pipe3_dpll_lock(phy);
-   if (ret)
-   return ret;
+   /* Bring it out of IDLE if it is IDLE */
+   val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
+   if (val & PLL_IDLE) {
+   val &= ~PLL_IDLE;
+   ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
+   ret = ti_pipe3_dpll_wait_lock(phy);
+   }
 
-   omap_control_phy_power(phy->control_dev, 1);
+   /* Program the DPLL only if not locked

[PATCH 08/12] ARM: dts: omap5: add sata node

2014-03-03 Thread Roger Quadros
From: Balaji T K 

Add support for sata.

[Roger Q] Clean up.

CC: Benoit Cousson 
CC: Tony Lindgren 
Signed-off-by: Balaji T K 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap5.dtsi | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a7f5930..8e55e97 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -806,6 +806,46 @@
 
#thermal-sensor-cells = <1>;
};
+
+   omap_control_sata: control-phy@4a002374 {
+   compatible = "ti,control-phy-pipe3";
+   reg = <0x4a002374 0x4>;
+   reg-names = "power";
+   clocks = <&sys_clkin>;
+   clock-names = "sysclk";
+   };
+
+   /* OCP2SCP3 */
+   ocp2scp@4a09 {
+   compatible = "ti,omap-ocp2scp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x4a09 0x20>;
+   ranges;
+   ti,hwmods = "ocp2scp3";
+   sata_phy: phy@4a096000 {
+   compatible = "ti,phy-pipe3-sata";
+   reg = <0x4A096000 0x80>, /* phy_rx */
+ <0x4A096400 0x64>, /* phy_tx */
+ <0x4A096800 0x40>; /* pll_ctrl */
+   reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+   ctrl-module = <&omap_control_sata>;
+   clocks = <&sys_clkin>;
+   clock-names = "sysclk";
+   #phy-cells = <0>;
+   };
+   };
+
+   sata: sata@4a141100 {
+   compatible = "snps,dwc-ahci";
+   reg = <0x4a14 0x1100>, <0x4a141100 0x7>;
+   interrupts = ;
+   phys = <&sata_phy>;
+   phy-names = "sata-phy";
+   clocks = <&sata_ref_clk>;
+   ti,hwmods = "sata";
+   };
+
};
 };
 
-- 
1.8.3.2

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


[PATCH 12/12] ARM: dts: dra7: add OCP2SCP3 and SATA nodes

2014-03-03 Thread Roger Quadros
From: Balaji T K 

Add nodes for OCP2SCP3 bus, SATA controller and SATA PHY.

[Roger Q] Clean up.

CC: Benoit Cousson 
Signed-off-by: Balaji T K 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..74e44bc 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -621,6 +621,45 @@
dma-names = "tx0", "rx0";
status = "disabled";
};
+
+   omap_control_sata: control-phy@4a002374 {
+   compatible = "ti,control-phy-pipe3";
+   reg = <0x4a002374 0x4>;
+   reg-names = "power";
+   clocks = <&sys_clkin1>;
+   clock-names = "sysclk";
+   };
+
+   /* OCP2SCP3 */
+   ocp2scp@4a09 {
+   compatible = "ti,omap-ocp2scp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   reg = <0x4a09 0x20>;
+   ti,hwmods = "ocp2scp3";
+   sata_phy: phy@4A096000 {
+   compatible = "ti,phy-pipe3-sata";
+   reg = <0x4A096000 0x80>, /* phy_rx */
+ <0x4A096400 0x64>, /* phy_tx */
+ <0x4A096800 0x40>; /* pll_ctrl */
+   reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+   ctrl-module = <&omap_control_sata>;
+   clocks = <&sys_clkin1>;
+   clock-names = "sysclk";
+   #phy-cells = <0>;
+   };
+   };
+
+   sata: sata@4a141100 {
+   compatible = "snps,dwc-ahci";
+   reg = <0x4a14 0x1100>, <0x4a141100 0x7>;
+   interrupts = ;
+   phys = <&sata_phy>;
+   phy-names = "sata-phy";
+   clocks = <&sata_ref_clk>;
+   ti,hwmods = "sata";
+   };
};
 };
 
-- 
1.8.3.2

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


[PATCH 11/12] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods

2014-03-03 Thread Roger Quadros
From: Nikhil Devshatwar 

Add hwmods for ocp2scp3 and sata modules.

[Roger Q] Clean up.

CC: Benoit Cousson 
CC: Paul Walmsley 
Signed-off-by: Balaji T K 
Signed-off-by: Nikhil Devshatwar 
Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 18f333c..c180b54 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,40 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
 };
 
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
+static struct omap_hwmod_addr_space dra7xx_ocp2scp3_addrs[] = {
+   {
+   .name   = "ocp2scp3",
+   .pa_start   = 0x4a09,
+   .pa_end = 0x4a09001f,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
+/* l4_cfg -> ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+   .master = &dra7xx_l4_cfg_hwmod,
+   .slave  = &dra7xx_ocp2scp3_hwmod,
+   .clk= "l4_root_clk_div",
+   .addr   = dra7xx_ocp2scp3_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+   .name   = "ocp2scp3",
+   .class  = &dra7xx_ocp2scp_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = 
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+   .context_offs = 
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
 /*
  * 'qspi' class
  *
@@ -1268,9 +1302,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
 };
 
 /* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
-   { .role = "ref_clk", .clk = "sata_ref_clk" },
-};
 
 static struct omap_hwmod dra7xx_sata_hwmod = {
.name   = "sata",
@@ -1278,6 +1309,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = "l3init_clkdm",
.flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk   = "func_48m_fclk",
+   .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1285,8 +1317,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode   = MODULEMODE_SWCTRL,
},
},
-   .opt_clks   = sata_opt_clks,
-   .opt_clks_cnt   = ARRAY_SIZE(sata_opt_clks),
 };
 
 /*
@@ -2683,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
&dra7xx_l4_per1__mmc4,
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
+   &dra7xx_l4_cfg__ocp2scp3,
&dra7xx_l3_main_1__qspi,
&dra7xx_l4_cfg__sata,
&dra7xx_l4_cfg__smartreflex_core,
-- 
1.8.3.2

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


[PATCH 10/12] phy: ti-pipe3: Fix suspend/resume and module reload

2014-03-03 Thread Roger Quadros
Due to Errata i783, SATA breaks if its DPLL is idled. The recommeded
workaround to issue a softreset to the SATA controller doesn't seem to
work. Here we just prevent SATA DPLL from Idling and hence avoid
the issue altogether.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-ti-pipe3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index d3c085a..611f7c3 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -238,6 +238,10 @@ static int ti_pipe3_exit(struct phy *x)
u32 val;
unsigned long timeout;
 
+   /* SATA DPLL can't be powered down due to Errata i783 */
+   if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata"))
+   return 0;
+
/* Put DPLL in IDLE mode */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
val |= PLL_IDLE;
-- 
1.8.3.2

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


[PATCH 02/12] phy: omap-control: Update DT binding information

2014-03-03 Thread Roger Quadros
Move omap-control binding information to the right location.

Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt   | 25 ++
 Documentation/devicetree/bindings/usb/omap-usb.txt | 24 -
 2 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 207e14c..41dc132 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -1,5 +1,30 @@
 TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
 
+OMAP CONTROL PHY
+
+Required properties:
+ - compatible: Should be one of
+ "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
+ "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
+e.g. USB2_PHY on OMAP5.
+ "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
+e.g. USB3 PHY and SATA PHY on OMAP5.
+ "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
+DRA7 platform.
+ "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
+AM437 platform.
+ - reg : Address and length of the register set for the device. It contains
+   the address of "otghs_control" for control-phy-otghs or "power" register
+   for other types.
+ - reg-names: should be "otghs_control" control-phy-otghs and "power" for
+   other types.
+
+omap_control_usb: omap-control-usb@4a002300 {
+compatible = "ti,control-phy-otghs";
+reg = <0x4a00233c 0x4>;
+reg-names = "otghs_control";
+};
+
 OMAP USB2 PHY
 
 Required properties:
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index c495135..38b2fae 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -76,27 +76,3 @@ omap_dwc3 {
ranges;
 };
 
-OMAP CONTROL USB
-
-Required properties:
- - compatible: Should be one of
- "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
- "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
-   e.g. USB2_PHY on OMAP5.
- "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
-   e.g. USB3 PHY and SATA PHY on OMAP5.
- "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
-   DRA7 platform.
- "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
-   AM437 platform.
- - reg : Address and length of the register set for the device. It contains
-   the address of "otghs_control" for control-phy-otghs or "power" register
-   for other types.
- - reg-names: should be "otghs_control" control-phy-otghs and "power" for
-   other types.
-
-omap_control_usb: omap-control-usb@4a002300 {
-   compatible = "ti,control-phy-otghs";
-   reg = <0x4a00233c 0x4>;
-   reg-names = "otghs_control";
-};
-- 
1.8.3.2

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


[PATCH 01/12] phy: rename struct omap_control_usb to struct omap_control_phy

2014-03-03 Thread Roger Quadros
From: Kishon Vijay Abraham I 

Rename struct omap_control_usb to struct omap_control_phy since it can
be used to control PHY of USB, SATA and PCIE. Also move the driver and
include files under *phy* and made the corresponding changes in the users
of phy-omap-control.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Roger Quadros 
---
 drivers/phy/Kconfig  |  14 +-
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-omap-control.c   | 320 +++
 drivers/phy/phy-omap-usb2.c  |   8 +-
 drivers/phy/phy-ti-pipe3.c   |   8 +-
 drivers/usb/musb/omap2430.c  |   2 +-
 drivers/usb/phy/Kconfig  |  10 --
 drivers/usb/phy/Makefile |   1 -
 drivers/usb/phy/phy-omap-control.c   | 319 --
 include/linux/phy/omap_control_phy.h |  89 ++
 include/linux/usb/omap_control_usb.h |  89 --
 11 files changed, 431 insertions(+), 430 deletions(-)
 create mode 100644 drivers/phy/phy-omap-control.c
 delete mode 100644 drivers/usb/phy/phy-omap-control.c
 create mode 100644 include/linux/phy/omap_control_phy.h
 delete mode 100644 include/linux/usb/omap_control_usb.h

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index bb238d4..2f02ec8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -28,12 +28,22 @@ config PHY_MVEBU_SATA
depends on OF
select GENERIC_PHY
 
+config OMAP_CONTROL_PHY
+   tristate "OMAP CONTROL PHY Driver"
+   help
+ Enable this to add support for the PHY part present in the control
+ module. This driver has API to power on the USB2 PHY and to write to
+ the mailbox. The mailbox is present only in omap4 and the register to
+ power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
+ additional register to power on USB3 PHY/SATA PHY/PCIE PHY
+ (PIPE3 PHY).
+
 config OMAP_USB2
tristate "OMAP USB2 PHY Driver"
depends on ARCH_OMAP2PLUS
depends on USB_PHY
select GENERIC_PHY
-   select OMAP_CONTROL_USB
+   select OMAP_CONTROL_PHY
help
  Enable this to support the transceiver that is part of SOC. This
  driver takes care of all the PHY functionality apart from comparator.
@@ -44,7 +54,7 @@ config TI_PIPE3
tristate "TI PIPE3 PHY Driver"
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select GENERIC_PHY
-   select OMAP_CONTROL_USB
+   select OMAP_CONTROL_PHY
help
  Enable this to support the PIPE3 PHY that is part of TI SOCs. This
  driver takes care of all the PHY functionality apart from comparator.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 32e3f94..7518497 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_PHY_MVEBU_SATA)  += phy-mvebu-sata.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
 obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
+obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
new file mode 100644
index 000..17fc200
--- /dev/null
+++ b/drivers/phy/phy-omap-control.c
@@ -0,0 +1,320 @@
+/*
+ * omap-control-phy.c - The PHY part of control module.
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * omap_control_phy_power - power on/off the phy using control module reg
+ * @dev: the control module device
+ * @on: 0 or 1, based on powering on or off the PHY
+ */
+void omap_control_phy_power(struct device *dev, int on)
+{
+   u32 val;
+   unsigned long rate;
+   struct omap_control_phy *control_phy;
+
+   if (IS_ERR(dev) || !dev) {
+   pr_err("%s: invalid device\n", __func__);
+   return;
+   }
+
+   control_phy = dev_get_drvdata(dev);
+   if (!control_phy) {
+   dev_err(dev, "%s: invalid control phy device\n", __func__);
+   return;
+   }
+
+   if (control_phy->type == OMAP_CTRL_TYPE_OTGHS)
+   return;
+
+   val = readl(control_phy->power);
+
+   switch (control_phy->type) {
+   case OMAP_CTRL_TYPE_USB2:
+  

[PATCH 05/12] phy: ti-pipe3: Add SATA DPLL support

2014-03-03 Thread Roger Quadros
USB and SATA DPLLs need different settings. Provide
the SATA DPLL settings and use the proper DPLL settings
based on device tree node's compatible_id.

Update the DT binding information.

Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |  3 +-
 drivers/phy/phy-ti-pipe3.c   | 76 +---
 2 files changed, 57 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 41dc132..6a65081 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -49,7 +49,8 @@ usb2phy@4a0ad080 {
 TI PIPE3 PHY
 
 Required properties:
- - compatible: Should be "ti,phy-usb3". "ti,omap-usb3" is deprecated.
+ - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata".
+   "ti,omap-usb3" is deprecated.
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in "reg".
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3662e28..ee8871d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -66,6 +66,11 @@ struct pipe3_dpll_params {
u32 mf;
 };
 
+struct pipe3_dpll_map {
+   unsigned long rate;
+   struct pipe3_dpll_params params;
+};
+
 struct ti_pipe3 {
void __iomem*pll_ctrl_base;
struct device   *dev;
@@ -73,20 +78,27 @@ struct ti_pipe3 {
struct clk  *wkupclk;
struct clk  *sys_clk;
struct clk  *optclk;
+   struct pipe3_dpll_map   *dpll_map;
 };
 
-struct pipe3_dpll_map {
-   unsigned long rate;
-   struct pipe3_dpll_params params;
-};
-
-static struct pipe3_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map_usb[] = {
{1200, {1250, 5, 4, 20, 0} },   /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} },  /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} },   /* 19.2 MHz */
{2000, {1000, 7, 4, 10, 0} },   /* 20 MHz */
{2600, {1250, 12, 4, 20, 0} },  /* 26 MHz */
{3840, {3125, 47, 4, 20, 92843} },  /* 38.4 MHz */
+   { },/* Terminator */
+};
+
+static struct pipe3_dpll_map dpll_map_sata[] = {
+   {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
+   {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
+   {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+   {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
+   {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
+   {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
+   { },/* Terminator */
 };
 
 static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset)
@@ -100,15 +112,20 @@ static inline void ti_pipe3_writel(void __iomem *addr, 
unsigned offset,
__raw_writel(data, addr + offset);
 }
 
-static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(struct ti_pipe3 *phy)
 {
-   int i;
+   unsigned long rate;
+   struct pipe3_dpll_map *dpll_map = phy->dpll_map;
 
-   for (i = 0; i < ARRAY_SIZE(dpll_map); i++) {
-   if (rate == dpll_map[i].rate)
-   return &dpll_map[i].params;
+   rate = clk_get_rate(phy->sys_clk);
+
+   for (; dpll_map->rate; dpll_map++) {
+   if (rate == dpll_map->rate)
+   return &dpll_map->params;
}
 
+   dev_err(phy->dev, "No DPLL configuration for %lu Hz SYS CLK\n", rate);
+
return NULL;
 }
 
@@ -182,16 +199,11 @@ static void ti_pipe3_dpll_relock(struct ti_pipe3 *phy)
 static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy)
 {
u32 val;
-   unsigned long   rate;
struct pipe3_dpll_params *dpll_params;
 
-   rate = clk_get_rate(phy->sys_clk);
-   dpll_params = ti_pipe3_get_dpll_params(rate);
-   if (!dpll_params) {
-   dev_err(phy->dev,
- "No DPLL configuration for %lu Hz SYS CLK\n", rate);
+   dpll_params = ti_pipe3_get_dpll_params(phy);
+   if (!dpll_params)
return -EINVAL;
-   }
 
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION1);
val &= ~PLL_REGN_MASK;
@@ -244,6 +256,10 @@ static struct phy_ops ops = {
.owner  = THIS_MODULE,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id ti_pipe3_id_table[];
+#endif
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
@@ -253,8 +269,10 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct device_node *control_node;
struct platform_device *control_p

[PATCH 06/12] phy: omap: Select OMAP_OCP2SCP bus driver

2014-03-03 Thread Roger Quadros
The OMAP_USB2 and OMAP_PIP3 phy devices will not be
detected if the OMAP_OCP2SCP driver is not present.
So select it.

Signed-off-by: Roger Quadros 
---
 drivers/phy/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2f02ec8..afdab3e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -44,6 +44,7 @@ config OMAP_USB2
depends on USB_PHY
select GENERIC_PHY
select OMAP_CONTROL_PHY
+   select OMAP_OCP2SCP
help
  Enable this to support the transceiver that is part of SOC. This
  driver takes care of all the PHY functionality apart from comparator.
@@ -55,6 +56,7 @@ config TI_PIPE3
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select GENERIC_PHY
select OMAP_CONTROL_PHY
+   select OMAP_OCP2SCP
help
  Enable this to support the PIPE3 PHY that is part of TI SOCs. This
  driver takes care of all the PHY functionality apart from comparator.
-- 
1.8.3.2

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


[PATCH 00/12] ARM: OMAP: SATA support for OMAP5 & DRA7

2014-03-03 Thread Roger Quadros
Hi,

This series adds SATA support for OMAP5 uevm and DRA7-evm boards.

- Cleans up the ti-pipe3 PHY driver
- Adds SATA DPLL support to ti-pipe3 PHY driver
- Adds SATA nodes to hwmod and SoC DT data

Patches are based on [1].
To test SATA you will also need [2].

[1] - http://article.gmane.org/gmane.linux.kernel/1658825
[2] - http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7285

cheers,
-roger

---
Balaji T K (2):
  ARM: dts: omap5: add sata node
  ARM: dts: dra7: add OCP2SCP3 and SATA nodes

Keshava Munegowda (1):
  ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods

Kishon Vijay Abraham I (1):
  phy: rename struct omap_control_usb to struct omap_control_phy

Nikhil Devshatwar (1):
  ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods

Roger Quadros (7):
  phy: omap-control: Update DT binding information
  phy: ti-pipe3: cleanup clock handling
  ARM: dts: omap5: Add clocks to usb3_phy node
  phy: ti-pipe3: Add SATA DPLL support
  phy: omap: Select OMAP_OCP2SCP bus driver
  phy: ti-pipe3: streamline PHY operations
  phy: ti-pipe3: Fix suspend/resume and module reload

 Documentation/devicetree/bindings/phy/ti-phy.txt   |  28 +-
 Documentation/devicetree/bindings/usb/omap-usb.txt |  24 --
 arch/arm/boot/dts/dra7.dtsi|  39 +++
 arch/arm/boot/dts/omap5.dtsi   |  42 +++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  73 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  41 ++-
 drivers/phy/Kconfig|  16 +-
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-omap-control.c | 320 +
 drivers/phy/phy-omap-usb2.c|   8 +-
 drivers/phy/phy-ti-pipe3.c | 257 ++---
 drivers/usb/musb/omap2430.c|   2 +-
 drivers/usb/phy/Kconfig|  10 -
 drivers/usb/phy/Makefile   |   1 -
 drivers/usb/phy/phy-omap-control.c | 319 
 include/linux/phy/omap_control_phy.h   |  89 ++
 include/linux/usb/omap_control_usb.h   |  89 --
 17 files changed, 798 insertions(+), 561 deletions(-)
 create mode 100644 drivers/phy/phy-omap-control.c
 delete mode 100644 drivers/usb/phy/phy-omap-control.c
 create mode 100644 include/linux/phy/omap_control_phy.h
 delete mode 100644 include/linux/usb/omap_control_usb.h

-- 
1.8.3.2

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


[PATCH 04/12] ARM: dts: omap5: Add clocks to usb3_phy node

2014-03-03 Thread Roger Quadros
The pipe3-phy driver expects certain named clocks.
Provide the necessary clocks.

CC: Benoît Cousson 
CC: Tony Lindgren 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap5.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1c68558..a7f5930 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -760,6 +760,8 @@
  <0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <&omap_control_usb3phy>;
+   clocks = <&usb_phy_cm_clk32k>, <&sys_clkin>;
+   clock-names = "wkupclk", "sysclk";
#phy-cells = <0>;
};
};
-- 
1.8.3.2

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


[PATCH 03/12] phy: ti-pipe3: cleanup clock handling

2014-03-03 Thread Roger Quadros
As this driver is no longer USB specific, use generic clock names.
- Fix PLL_SD_SHIFT from 9 to 10
- As optclk and wkupclk may not be always required, don't bail out
if they aren't available.
- Don't separate prepare/unprepare clock from enable/disable. This
ensures optimal power savings.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-ti-pipe3.c | 57 ++
 1 file changed, 27 insertions(+), 30 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 54859fc..3662e28 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -45,7 +45,7 @@
 #definePLL_SELFREQDCO_MASK 0x000E
 #definePLL_SELFREQDCO_SHIFT0x1
 #definePLL_SD_MASK 0x0003FC00
-#definePLL_SD_SHIFT0x9
+#definePLL_SD_SHIFT10
 #defineSET_PLL_GO  0x1
 #definePLL_TICOPWDN0x1
 #definePLL_LOCK0x2
@@ -270,23 +270,17 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
phy->dev= &pdev->dev;
 
-   phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
-   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);
+   phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
+   if (IS_ERR(phy->wkupclk))
+   dev_dbg(&pdev->dev, "unable to get wkupclk\n");
 
-   phy->optclk = devm_clk_get(phy->dev, "usb_otg_ss_refclk960m");
-   if (IS_ERR(phy->optclk)) {
-   dev_err(&pdev->dev, "unable to get usb_otg_ss_refclk960m\n");
-   return PTR_ERR(phy->optclk);
-   }
-   clk_prepare(phy->optclk);
+   phy->optclk = devm_clk_get(phy->dev, "optclk");
+   if (IS_ERR(phy->optclk))
+   dev_dbg(&pdev->dev, "unable to get optclk\n");
 
-   phy->sys_clk = devm_clk_get(phy->dev, "sys_clkin");
+   phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
if (IS_ERR(phy->sys_clk)) {
-   pr_err("%s: unable to get sys_clkin\n", __func__);
+   dev_err(&pdev->dev, "unable to get sysclk\n");
return -EINVAL;
}
 
@@ -326,10 +320,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
 static int ti_pipe3_remove(struct platform_device *pdev)
 {
-   struct ti_pipe3 *phy = platform_get_drvdata(pdev);
-
-   clk_unprepare(phy->wkupclk);
-   clk_unprepare(phy->optclk);
if (!pm_runtime_suspended(&pdev->dev))
pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
@@ -343,8 +333,10 @@ static int ti_pipe3_runtime_suspend(struct device *dev)
 {
struct ti_pipe3 *phy = dev_get_drvdata(dev);
 
-   clk_disable(phy->wkupclk);
-   clk_disable(phy->optclk);
+   if (!IS_ERR(phy->wkupclk))
+   clk_disable_unprepare(phy->wkupclk);
+   if (!IS_ERR(phy->optclk))
+   clk_disable_unprepare(phy->optclk);
 
return 0;
 }
@@ -354,22 +346,27 @@ static int ti_pipe3_runtime_resume(struct device *dev)
u32 ret = 0;
struct ti_pipe3 *phy = dev_get_drvdata(dev);
 
-   ret = clk_enable(phy->optclk);
-   if (ret) {
-   dev_err(phy->dev, "Failed to enable optclk %d\n", ret);
-   goto err1;
+   if (!IS_ERR(phy->optclk)) {
+   ret = clk_prepare_enable(phy->optclk);
+   if (ret) {
+   dev_err(phy->dev, "Failed to enable optclk %d\n", ret);
+   goto err1;
+   }
}
 
-   ret = clk_enable(phy->wkupclk);
-   if (ret) {
-   dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret);
-   goto err2;
+   if (!IS_ERR(phy->wkupclk)) {
+   ret = clk_prepare_enable(phy->wkupclk);
+   if (ret) {
+   dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret);
+   goto err2;
+   }
}
 
return 0;
 
 err2:
-   clk_disable(phy->optclk);
+   if (!IS_ERR(phy->optclk))
+   clk_disable_unprepare(phy->optclk);
 
 err1:
return ret;
-- 
1.8.3.2

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


[PATCH 07/12] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods

2014-03-03 Thread Roger Quadros
From: Keshava Munegowda 

Create hwmods for ocp2scp3 and sata modules.

[Roger Q] Clean up.

CC: Benoit Cousson 
CC: Paul Walmsley 
CC: Tony Lindgren 
Signed-off-by: Balaji T K 
Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..227a69f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
 };
 
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg -> ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+   .master = &omap54xx_l4_cfg_hwmod,
+   .slave  = &omap54xx_ocp2scp3_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+   .name   = "ocp2scp3",
+   .class  = &omap54xx_ocp2scp_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = 
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+   .context_offs = 
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
+/*
+ * 'sata' class
+ * sata:  serial ata interface  gen2 compliant   ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+   .sysc_offs  = 0x,
+   .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+   .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+   .name   = "sata",
+   .sysc   = &omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+   .name   = "sata",
+   .class  = &omap54xx_sata_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+   .main_clk   = "func_48m_fclk",
+   .mpu_rt_idx = 1,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+   .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* l4_cfg -> sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+   .master = &omap54xx_l4_cfg_hwmod,
+   .slave  = &omap54xx_sata_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
 
 /*
  * Interfaces
@@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] 
__initdata = {
&omap54xx_l4_cfg__usb_tll_hs,
&omap54xx_l4_cfg__usb_otg_ss,
&omap54xx_l4_wkup__wd_timer2,
+   &omap54xx_l4_cfg__ocp2scp3,
+   &omap54xx_l4_cfg__sata,
NULL,
 };
 
-- 
1.8.3.2

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


Re: [PATCH v5 0/6] Make dwc3 use Generic PHY Framework

2014-03-03 Thread Felipe Balbi
Hi,

On Mon, Mar 03, 2014 at 05:08:09PM +0530, Kishon Vijay Abraham I wrote:
> Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3
> should be programmed. While this can be considered as a temporary fix,
> a long term solution would be to add 'nop' PHY for platforms that does
> not have programmable PHY.
> Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the
> name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to
> be used for SATA and PCIE too.
> 
> Changes from v4: (sending the entire patch series again)
> * check the return values of phy_init and phy_power_on
> * print errors if power_on or power_off of PHY fails.
> 
> Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) 
> * avoided using quirks and rely on the return values of PHY APIs to find the
> presence of PHY.
> 
> Changes from v2:
> * added a couple of fixes. One is invoking phy_resume after phy_init and the
> other is power off phy in error patch
> * used quirks to identify if a particular platform does not have PHYs
> * removed using separate header for pipe3 driver and also removed all 
> referencs
> to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers.
> 
> Changes from v1:
> * The logic in which the driver detects the presence of PHYs has changed.
> * patch ordering has changed
> * udelay is replaced with usleep_range
> * A patch to remove set_suspend callback which was deferred from Generic
> PHY Framework series has been included.
> 
> Kishon Vijay Abraham I (6):
>   usb: dwc3: core: support optional PHYs
>   usb: dwc3: adapt dwc3 core to use Generic PHY Framework
>   drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
>   usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
>   phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
>   arm/dts: added dt properties to adapt to the new phy framwork

patches 1 and 2 are in my testing/next, I guess 3,4,5 and 6 have no
direct dependency on those, right ?

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling

2014-03-03 Thread Tony Lindgren
* Sørensen, Stefan  [140303 03:08]:
> On Sun, 2014-03-02 at 09:37 -0800, Tony Lindgren wrote:
> > * Sørensen, Stefan  [140301 02:02]:
> > > On Fri, 2014-02-28 at 09:11 -0800, Tony Lindgren wrote:
> > > > * Stefan Sørensen  [140224 02:12]:
> > > > > Currently INTC interrupts are handled using handle_level_irq which
> > > > > will acknowledge the interrupt before running the handler. If a second
> > > > > interrupt is then asserted and this interrupt is disabled while
> > > > > running the first handler, the INTC will be brought into an
> > > > > inconsistent state.
> > > > 
> > > > Hmm care to explain a bit more here if the second interrupt you're
> > > > talking about is the same interrupt or any interrupt in the same
> > > > interrupt bank? Is this limited to GPIO interrupts?
> > > 
> > > I am seeing it with the cpsw driver on a custom board and on the
> > > beaglebone. When a tx irq is handled the cpsw irq handler disables both
> > > the tx and the rx irqs, and if the rx irq was also asserted (i.e. duplex
> > > traffic), this bug will trigger. Reproducing it is very simple, just hit
> > > a beaglebone with a flood ping and watch a function trace.
> > 
> > OK so it's for the same interrupt. And that sounds like a good test :)
> 
> No, the tx and rx are separate interrupts, but the cpsw driver has a
> common handler.

Oh OK sounds like that's where the problem is :)
  
> > > > The reason I'm asking is because of the issues we've seen earlier
> > > > with not flushing posted writes from the interrupt handlers. In
> > > > those case the interrupt on the device gets acked too late without
> > > > the read back call.
> > > 
> > > I am not very familiar with the low level details of the irq handling,  
> > > but am335x TRM states that a data synchronization barrier should be used
> > > after the ACK is posted to the INTC, and I don't see that anywhere in
> > > the code. Is this related?
> > 
> > Well sort of, except DSB won't do it as it won't guarantee the write
> > gets to the device on the bus. So a readback from the device is needed
> > as only the order of reads and writes is guaranteed.
> 
> I think that we are talking about two different scenarios, what I am
> seeing is that an interrupt is disabled while active on the INTC.

Yes sounds like these are different issues.
 
>   1. CPSW device asserts TX IRQ
>   2. CPSW device asserts RX IRQ
>   3. INTC interrupts CPU, TX IRQ marked as active
>   4. omap_intc_handle_irq ACKs TX IRQ on the INTC
>   5. INTC marks RX IRQ as active
>   6. omap_intc_handle_irq calls cpsw_interrupt
>   7. cpsw_interrupt disables RX+TX IRQ in CPSW device
>   8. cpsw_interrupt disables RX+TX IRQ in INTC (the IRQs are masked)
>   9.. omap_intc_handle_irq sees no unmasked IRQs are pending and returns
>   10. INTC interrupts CPU, RX IRQ marked as pending
>   11. omap_intc_handle_irq sees no unmasked IRQs are pending and returns
>   12. Go to step 10
> 
> The problem arises in step 8 where an active IRQ is masked. This will
> not make it inactive in the INTC but it will be cleared from the
> pending IRQ registers - this is the register that omap_intc_handle_irq
> uses to decide which IRQ is active.

OK thanks for the info. Looking at your trace above it seems like the
two separate TX and RX INTC interrupts are not really treated as separate
interrupts in the cpsw driver. It seems the real fix is to fix up the
cpsw interrupt handler so it's not racy. It seems that at least step 7
and 8 above should be handled separately for TX and RX based on the INTC
interrupts.

>From the INTC point of view we should just have standard level IRQ
handling for each interrupt, right? INTC does not need to know about
driver specific coordination between two separate interrupts.
 
> > A good sanity check would be to find the related interrupt handler(s)
> > in the cpsw driver that do the write to the cpsw registers to ack
> > interrupts.
> > 
> > Then check if there's a readback in the cpsw interrupt handler(s) of
> > some harmless cpsw register after acking the interrupt(s) and before
> > doing return IRQ_HANDLED.
> > 
> > If this fixes things without your patch, then we know it's a driver
> > issue and there's no need to debug it further :) The missing flush of
> > posted write usually shows up as a spurious interrupts with no status
> > in the device, but depending on the driver code handling of spurious
> > interrupts it may also have other side effects.
> > 
> > I'm not too familiar with the cpsw driver so I can't do a test patch
> > without digging into it further sorry. For similar examples, you
> > may want to grep for "flush posted write" and "OCP barrier" in the
> > kernel code.
> 
> I tried this with an assortment of different CPSW registers - no change.

OK thanks for trying. Based on your description above it seems that
the problem you found is not related to flushing posted writes even
though that issue might be there also once race issue is fixe

Re: [PATCH] sound: omap: n810: fix init with DT boot

2014-03-03 Thread Jarkko Nikula
On 03/01/2014 08:08 PM, Aaro Koskinen wrote:
> Since 3.14-rc1 only DT boot has been supported on N810. Make a minimal
> fix to retain functionality. This file should be properly converted
> to DT in longer term.
> 
> Signed-off-by: Aaro Koskinen 
> ---
>  sound/soc/omap/n810.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
Right, so there is actually regression. Can you get codec to probe? I
get this when drivers are modules:

tlv320aic3x-codec: probe of 1-0018 failed with error -16

I don't see quickly from where this -EBUSY comes but
arch/arm/mach-omap2/board-n8x0.c seems to register it since module is
loaded.

With your patch basic n810 machine driver probing works again although
audio card is not registered for me due failing codec probe.

Please resend you fix and cc maintainers Mark Brown 
and Liam Girdwood . You can add my ack

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


Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers

2014-03-03 Thread Suman Anna

Ohad,

On 03/02/2014 02:19 PM, Bjorn Andersson wrote:

On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen  wrote:

On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna  wrote:

On 02/07/2014 04:49 PM, Bjorn Andersson wrote:

It seems to be standard practice to pass the error value back to the
consumer, so you should
return ERR_PTR(ret); here instead of the NULL...



I have modelled the return values in this function based on the return
values in the existing hwspin_lock_request interfaces. I would need to
change those functions as well.

Ohad,
Do you have any objections to the return code convention change?


Unless strictly needed, I prefer we don't switch to the ERR_PTR code
convention, as it reduces code readability and increases chances of
user bugs.



From a current user/client perspectives, I didn't find any clients of 
hwspinlock within the kernel. So, this is probably the right time to 
change the return code convention.



In our case, switching to ERR_PTR and friends seems only to optimize a
few error paths, and I'm not sure it's a big win over simplicity.


The usage on the clients will also not become too complicated. The only 
change on the clients is mostly the base error check change from if 
(!hwlock) to if (IS_ERR(hwlock)).


regards
Suman


When introducing the ability to reference a hwspin lock via a phandle
in device tree it makes a big difference to be able to differ between
the case of "initialization failed" or "device not yet probed"; so
that the client knows if it should fail or retry later.

Regards,
Bjorn


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


Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion

2014-03-03 Thread Tony Lindgren
* Tero Kristo  [140303 00:20]:
> On 02/28/2014 08:33 PM, Tony Lindgren wrote:
> >* Tero Kristo  [140228 10:21]:
> >>
> >>Hmm, some clock node is broken, might be missing a name or parent
> >>name for some reason. Can you try to boot with DEBUG enabled so you
> >>get pr_debug:s out and see which clock is being initialized during
> >>the crash?
> >
> >...
> >[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: 
> >initializing: core_d18_ck
> >[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: 
> >initializing: vlynq_mux_fck
> >[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: 
> >initializing: vlynq_fck
> >[0.00] Unable to handle kernel NULL pointer dereference at virtual 
> >address 
> >...
> >
> >We really should be registering the clocks lazily as needed BTW. That
> >leaves out the dependency to DEBUG_LL for seeing any kind of decent
> >error messages during the booting.
> >
> >Regards,
> >
> >Tony
> >
> 
> Hey Tony,
> 
> Can you retry with the branch? I just pushed one patch there, seems
> the parents for the vlynq_mux_fck were somewhat broken (there are
> holes in the valid mux values list, which hasn't happened with any
> other mux-clock so far.)
> 
> If this works, I will rework the series a bit and send v2 out.
> Alternatively I need to add extra debug info.

Still getting this without omap3:

drivers/built-in.o: In function `of_ti_dpll_setup':
/home/tmlind/src/linux-2.6/drivers/clk/ti/dpll.c:235: undefined reference to 
`clkhwops_omap3_dpll'
drivers/built-in.o:(.rodata+0x1d7a0): undefined reference to 
`omap3_noncore_dpll_enable'
drivers/built-in.o:(.rodata+0x1d7a4): undefined reference to 
`omap3_noncore_dpll_disable'
drivers/built-in.o:(.rodata+0x1d7b0): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0x1d7c4): undefined reference to 
`omap3_noncore_dpll_set_rate'
drivers/built-in.o:(.rodata+0x1d808): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0x1d84c): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0x1d860): undefined reference to 
`omap3_noncore_dpll_set_rate'

and after enabling omap3 getting this without 2430:

drivers/built-in.o: In function `of_ti_omap2430_interface_clk_setup':
/home/tmlind/src/linux-2.6/drivers/clk/ti/interface.c:129: undefined reference 
to `clkhwops_omap2430_i2chs_wait'

But after enabling those, it now boots on n8x0. The dmesg is below.

Care to post a patch to try dropping the legacy clock data as it should
now work with the DT clocks only for omap2?

Regards,

Tony


[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.14.0-rc5-00014-g2297f72-dirty (tmlind@muffinssi) 
(gcc version 4.3.5 (Debian 4.3.5-4) ) #388 Mon Mar 3 10:38:58 PST 2014
[0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 
(ARMv6TEJ), cr=00c5387d
[0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache
[0.00] Machine model: Nokia N800
[0.00] bootconsole [earlycon0] enabled
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 32512
[0.00] free_area_init_node: node 0, pgdat c07969a8, node_mem_map 
c7df9000
[0.00]   Normal zone: 256 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 32512 pages, LIFO batch:7
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP2420
[0.00] 
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32256
[0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait 
console=ttyO2,115200 earlyprintk ignore_loglevel
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 115492K/130048K available (5098K kernel code, 457K 
rwdata, 1884K rodata, 304K init, 5485K bss, 14556K reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xc880 - 0xff00   ( 872 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc06d9e10   (6984 kB)
[0.00]   .init : 0xc06da000 - 0xc072601c   ( 305 kB)
[0.00]   .data : 0xc0728000 - 0xc079a690   ( 458 kB)
[0.00].bss : 0xc079a690 - 0xc0cf5b10   (5486 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96 
inte

Re: [PATCH 06/12] phy: omap: Select OMAP_OCP2SCP bus driver

2014-03-03 Thread Tony Lindgren
* Roger Quadros  [140303 07:11]:
> The OMAP_USB2 and OMAP_PIP3 phy devices will not be
> detected if the OMAP_OCP2SCP driver is not present.
> So select it.

Selecting drivers like this will easily lead into missing
dependencies. Especially it's bad for tristate driver
options that people may want to have as loadable modules.

How about instead depends on OMAP_OCP2SCP?

Regards,

Tony

 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/phy/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 2f02ec8..afdab3e 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -44,6 +44,7 @@ config OMAP_USB2
>   depends on USB_PHY
>   select GENERIC_PHY
>   select OMAP_CONTROL_PHY
> + select OMAP_OCP2SCP
>   help
> Enable this to support the transceiver that is part of SOC. This
> driver takes care of all the PHY functionality apart from comparator.
> @@ -55,6 +56,7 @@ config TI_PIPE3
>   depends on ARCH_OMAP2PLUS || COMPILE_TEST
>   select GENERIC_PHY
>   select OMAP_CONTROL_PHY
> + select OMAP_OCP2SCP
>   help
> Enable this to support the PIPE3 PHY that is part of TI SOCs. This
> driver takes care of all the PHY functionality apart from comparator.
> -- 
> 1.8.3.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion

2014-03-03 Thread Tero Kristo

On 03/03/2014 08:46 PM, Tony Lindgren wrote:

* Tero Kristo  [140303 00:20]:

On 02/28/2014 08:33 PM, Tony Lindgren wrote:

* Tero Kristo  [140228 10:21]:


Hmm, some clock node is broken, might be missing a name or parent
name for some reason. Can you try to boot with DEBUG enabled so you
get pr_debug:s out and see which clock is being initialized during
the crash?


...
[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: 
core_d18_ck
[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: 
vlynq_mux_fck
[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: 
vlynq_fck
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address 
...

We really should be registering the clocks lazily as needed BTW. That
leaves out the dependency to DEBUG_LL for seeing any kind of decent
error messages during the booting.

Regards,

Tony



Hey Tony,

Can you retry with the branch? I just pushed one patch there, seems
the parents for the vlynq_mux_fck were somewhat broken (there are
holes in the valid mux values list, which hasn't happened with any
other mux-clock so far.)

If this works, I will rework the series a bit and send v2 out.
Alternatively I need to add extra debug info.


Still getting this without omap3:

drivers/built-in.o: In function `of_ti_dpll_setup':
/home/tmlind/src/linux-2.6/drivers/clk/ti/dpll.c:235: undefined reference to 
`clkhwops_omap3_dpll'
drivers/built-in.o:(.rodata+0x1d7a0): undefined reference to 
`omap3_noncore_dpll_enable'
drivers/built-in.o:(.rodata+0x1d7a4): undefined reference to 
`omap3_noncore_dpll_disable'
drivers/built-in.o:(.rodata+0x1d7b0): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0x1d7c4): undefined reference to 
`omap3_noncore_dpll_set_rate'
drivers/built-in.o:(.rodata+0x1d808): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0x1d84c): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0x1d860): undefined reference to 
`omap3_noncore_dpll_set_rate'

and after enabling omap3 getting this without 2430:

drivers/built-in.o: In function `of_ti_omap2430_interface_clk_setup':
/home/tmlind/src/linux-2.6/drivers/clk/ti/interface.c:129: undefined reference 
to `clkhwops_omap2430_i2chs_wait'


Yea, I didn't fix these with the patch I pushed, just the boot problem. 
I will fix these with the next version of the set, in addition to the 
issues reported by Nishanth.




But after enabling those, it now boots on n8x0. The dmesg is below.


This is good, so the culprit was only the vlynq fck.


Care to post a patch to try dropping the legacy clock data as it should
now work with the DT clocks only for omap2?


Yes, I can post patches for this for omap2/omap3 also tomorrow.

-Tero



Regards,

Tony


[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.14.0-rc5-00014-g2297f72-dirty (tmlind@muffinssi) 
(gcc version 4.3.5 (Debian 4.3.5-4) ) #388 Mon Mar 3 10:38:58 PST 2014
[0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 
(ARMv6TEJ), cr=00c5387d
[0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache
[0.00] Machine model: Nokia N800
[0.00] bootconsole [earlycon0] enabled
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 32512
[0.00] free_area_init_node: node 0, pgdat c07969a8, node_mem_map 
c7df9000
[0.00]   Normal zone: 256 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 32512 pages, LIFO batch:7
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP2420
[0.00]
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32256
[0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait 
console=ttyO2,115200 earlyprintk ignore_loglevel
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 115492K/130048K available (5098K kernel code, 457K 
rwdata, 1884K rodata, 304K init, 5485K bss, 14556K reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xc880 - 0xff00   ( 872 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc06d9e10   (6984 kB)
[0.00]   .init : 0xc06da000 - 0xc072601c   (

Re: [PATCH 02/12] phy: omap-control: Update DT binding information

2014-03-03 Thread Tony Lindgren
* Roger Quadros  [140303 07:10]:
> Move omap-control binding information to the right location.
> 
> Signed-off-by: Roger Quadros 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt   | 25 
> ++
>  Documentation/devicetree/bindings/usb/omap-usb.txt | 24 -
>  2 files changed, 25 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
> b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 207e14c..41dc132 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -1,5 +1,30 @@
>  TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
>  
> +OMAP CONTROL PHY
> +
> +Required properties:
> + - compatible: Should be one of
> + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on 
> OMAP4.
> + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf 
> register
> +e.g. USB2_PHY on OMAP5.
> + "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
> +e.g. USB3 PHY and SATA PHY on OMAP5.
> + "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
> +DRA7 platform.
> + "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
> +AM437 platform.

To me it seems that you can leave out all the above. You can set these falgs
flags directly in the driver based on the compatible flag. Then just initialize
the .data in the driver based on the compatible flag.

> + - reg : Address and length of the register set for the device. It contains
> +   the address of "otghs_control" for control-phy-otghs or "power" register
> +   for other types.
> + - reg-names: should be "otghs_control" control-phy-otghs and "power" for
> +   other types.
> +
> +omap_control_usb: omap-control-usb@4a002300 {
> +compatible = "ti,control-phy-otghs";
> +reg = <0x4a00233c 0x4>;
> +reg-names = "otghs_control";
> +};

Then you would instead have something like this:

compatible = "ti,am347-control-phy-otghs";

That way you can initialize things without a need for custom bindings.

Regards,

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


Ethernet controller not starting

2014-03-03 Thread Jon Ringle
I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
the latest LTS kernel).
I found that Ethernet controller on the board no longer comes up on linux-3.12.
I was able to bisect the issue I'm having to the following commit:

>   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>   Author: Rafael J. Wysocki 
>   Date:   Mon Jun 3 21:49:52 2013 +0200
>
>   PM / Runtime: Rework the "runtime idle" helper routine
>
>   The "runtime idle" helper routine, rpm_idle(), currently ignores
>   return values from .runtime_idle() callbacks executed by it.
>   However, it turns out that many subsystems use
>   pm_generic_runtime_idle() which checks the return value of the
>   driver's callback and executes pm_runtime_suspend() for the device
>   unless that value is not 0.  If that logic is moved to rpm_idle()
>   instead, pm_generic_runtime_idle() can be dropped and its users
>   will not need any .runtime_idle() callbacks any more.
>
>   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>   ata_port_runtime_idle(), respectively, as well as a few drivers'
>   ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
>   been returned by the .runtime_idle() callback executed by it.
>
>   To reduce overall code bloat, make the changes described above.
>
>   Tested-by: Mika Westerberg 
>   Tested-by: Kevin Hilman 
>   Signed-off-by: Rafael J. Wysocki 
>   Acked-by: Kevin Hilman 
>   Reviewed-by: Ulf Hansson 
>   Acked-by: Alan Stern 

Can anyone offer any suggestions on what I should be looking for to
fix this on my board?

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


Re: [GIT PULL] ARM: OMAP: Device Tree for 3.15

2014-03-03 Thread Benoit Cousson

On 02/03/2014 23:17, Tony Lindgren wrote:

* Benoit Cousson  [140302 12:45]:

Hi Tony,

Please pull the following commits for OMAP Device Tree for v3.15.


Thanks pulling into omap-for-v3.15/dt.


Thank you Tony.

Regards,
Benoit

--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi

2014-03-03 Thread Benoit Cousson

On 28/02/2014 23:17, Tony Lindgren wrote:

* Jack Mitchell  [140122 03:09]:

From: Jack Mitchell 

Devicetree include file for setting up the am335x mcasp bus, i2c-2
bus, and audio codec required for a functioning BeagleBone Audio Cape.

Signed-off-by: Jack Mitchell 
Signed-off-by: Matt Porter 
---
  arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +
  arch/arm/boot/dts/am335x-bone-common.dtsi  |  14 +++
  2 files changed, 138 insertions(+)
  create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi

diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi 
b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
new file mode 100644
index 000..b8ec3dc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2014 Jack Mitchell 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * In order to enable the BeagleBone Audio Cape this dtsi must be
+ * incuded in the top level dts. On BeagleBone Black hardware the
+ * status of the HDMI dts node must also be set to "disabled".


Seems like this is unsafe to merge then? This probably also needs
comments from Peter Ujfalusi, added him to Cc.


Maybe, we'd better define a new DTS board (like 
am335x-boneblack-audio.dts) if we cannot use audio cape without losing 
the HDMI.
Since we don't have mechanism like overlay, we don't have the choice but 
defining several boards for each cape variant.


BTW, what is the conflict source with HDMI?
At some point I remember that the mcasp for audio cape was broken 
because of changes in the mcasp for the HDMI, but it is not the case 
anymore, thanks to the cleanup from Jyri.





+ * --- a/arch/arm/boot/dts/am335x-bone.dts
+ * +++ b/arch/arm/boot/dts/am335x-bone.dts
+ * @@ -9,6 +9,7 @@
+ *
+ *  #include "am33xx.dtsi"
+ *  #include "am335x-bone-common.dtsi"
+ * +#include "am335x-bone-audio-cape-reva.dtsi"
+ *
+ *  &ldo3_reg {
+ * regulator-min-microvolt = <180>;
+ *
+ * On BeagleBone Black hardware the status of the HDMI dts node must
+ * also be set to "disabled"
+ *
+ * --- a/arch/arm/boot/dts/am335x-boneblack.dts
+ * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
+ * @@ -73,6 +74,6 @@
+ * pinctrl-names = "default", "off";
+ * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+ * -   status = "okay";
+ * +   status = "disabled";
+ * };
+ *  };
+ */
+
+/ {
+   sound {
+   compatible = "ti,da830-evm-audio";
+   ti,model = "AM335x BeagleBone Audio Cape Rev. A";
+   ti,audio-codec = <&tlv320aic3106>;
+   ti,mcasp-controller = <&mcasp0>;
+   ti,codec-clock-rate = <1200>;
+   ti,audio-routing =
+   "Headphone Jack",   "HPLOUT",
+   "Headphone Jack",   "HPROUT",
+   "LINE1L",   "Line In",
+   "LINE1R",   "Line In";
+   };
+
+   audio-cape-gpio-leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&bone_audio_cape_led_pins>;
+
+   audio-led0 {
+   label = "audio:green:usr0";
+   gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+
+   audio-led1 {
+   label = "audio:green:usr1";
+   gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   default-state = "off";
+   };
+   };
+};
+
+&am33xx_pinmux {
+   bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins {
+   pinctrl-single,pins = <
+   0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
gpmc_a2.gpio1_18 */
+   0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
gpmc_a3.gpio1_19 */
+   >;
+   };
+
+   bone_audio_cape_pins: bone_audio_cape_pins {
+   pinctrl-single,pins = <
+   0x190 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mcasp0_aclkx.mcasp0_aclkx */
+   0x194 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
mcasp0_fsx.mcasp0_fsx */
+   0x19c (PIN_INPUT_PULLUP | MUX_MODE2)/* 
mcasp0_ahclkr.mcasp0_axr2 */
+   0x1ac (PIN_INPUT_PULLUP | MUX_MODE2)/* 
mcasp0_ahclkx.mcasp0_axr3 */
+   >;
+   };
+};
+
+&i2c2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_pins>;
+
+   status = "okay";
+   clock-frequency = <10>;
+
+   tlv320aic3106: tlv320aic3106@1b {


A more generic name will be prefered here.

Re

Re: [PATCH 1/1] net: cpsw: fix cpdma rx descriptor leak on down interface

2014-03-03 Thread David Miller
From: Mugunthan V N 
Date: Mon, 3 Mar 2014 16:19:06 +0530

> From: Schuyler Patton 
> 
> This patch fixes a CPDMA RX Descriptor leak that occurs after taking
> the interface down when the CPSW is in Dual MAC mode. Previously
> the CPSW_ALE port was left open up which causes packets to be received
> and processed by the RX interrupt handler and were passed to the
> non active network interface where they were ignored.
> 
> The fix is for the slave_stop function of the selected interface
> to disable the respective CPSW_ALE Port from forwarding packets. This
> blocks traffic from being received on the inactive interface.
> 
> Signed-off-by: Schuyler Patton 
> Reviewed-by: Felipe Balbi 
> Signed-off-by: Mugunthan V N 

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


[PATCH RESEND] mmc: omap_hsmmc: support more DT properties

2014-03-03 Thread Daniel Mack
This should probably be done implicitly through mmc_of_parse(), but that
doesn't play well along with the multi-slot model the hsmmc driver
features. Hence, for now, do it manually. The properties are already
documented in Documentation/devicetree/bindings/mmc/mmc.txt.

Signed-off-by: Daniel Mack 
Acked-by: Balaji T K 
---
This is a resend of a patch that was already acked by Balaji T K:

  http://www.spinics.net/lists/linux-mmc/msg25029.html


 drivers/mmc/host/omap_hsmmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2815de6..a5a38cc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, "ti,needs-special-hs-handling", NULL))
pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
+   if (of_find_property(np, "keep-power-in-suspend", NULL))
+   pdata->slots[0].pm_caps |= MMC_PM_KEEP_POWER;
+
+   if (of_find_property(np, "enable-sdio-wakeup", NULL))
+   pdata->slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
return pdata;
 }
 #else
-- 
1.8.5.3

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


[PATCH RESEND] sound: omap: n810: fix init with DT boot

2014-03-03 Thread Aaro Koskinen
Since 3.14-rc1 only DT boot has been supported on N810, so this
file fails to init. Make a minimal fix to retain functionality.
This file should be properly converted to DT in longer term.

There seems to be still other unresolved issues with N810 audio support,
but this patch is needed at minimum as otherwise the machine driver
probing would completely fail.

Signed-off-by: Aaro Koskinen 
Acked-by: Jarkko Nikula 
---

Previous discussion:
http://marc.info/?l=linux-omap&m=139387208426122&w=2

 sound/soc/omap/n810.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c
index 3fde9e4..d163e18 100644
--- a/sound/soc/omap/n810.c
+++ b/sound/soc/omap/n810.c
@@ -305,7 +305,9 @@ static int __init n810_soc_init(void)
int err;
struct device *dev;
 
-   if (!(machine_is_nokia_n810() || machine_is_nokia_n810_wimax()))
+   if (!of_have_populated_dt() ||
+   (!of_machine_is_compatible("nokia,n810") &&
+!of_machine_is_compatible("nokia,n810-wimax")))
return -ENODEV;
 
n810_snd_device = platform_device_alloc("soc-audio", -1);
-- 
1.9.0

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


Re: Ethernet controller not starting

2014-03-03 Thread Rafael J. Wysocki
On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
> the latest LTS kernel).
> I found that Ethernet controller on the board no longer comes up on 
> linux-3.12.
> I was able to bisect the issue I'm having to the following commit:
> 
> >   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
> >   commit 45f0a85c8258741d11bda25c0a5669c06267204a
> >   Author: Rafael J. Wysocki 
> >   Date:   Mon Jun 3 21:49:52 2013 +0200
> >
> >   PM / Runtime: Rework the "runtime idle" helper routine
> >
> >   The "runtime idle" helper routine, rpm_idle(), currently ignores
> >   return values from .runtime_idle() callbacks executed by it.
> >   However, it turns out that many subsystems use
> >   pm_generic_runtime_idle() which checks the return value of the
> >   driver's callback and executes pm_runtime_suspend() for the device
> >   unless that value is not 0.  If that logic is moved to rpm_idle()
> >   instead, pm_generic_runtime_idle() can be dropped and its users
> >   will not need any .runtime_idle() callbacks any more.
> >
> >   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
> >   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
> >   ata_port_runtime_idle(), respectively, as well as a few drivers'
> >   ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
> >   been returned by the .runtime_idle() callback executed by it.
> >
> >   To reduce overall code bloat, make the changes described above.
> >
> >   Tested-by: Mika Westerberg 
> >   Tested-by: Kevin Hilman 
> >   Signed-off-by: Rafael J. Wysocki 
> >   Acked-by: Kevin Hilman 
> >   Reviewed-by: Ulf Hansson 
> >   Acked-by: Alan Stern 
> 
> Can anyone offer any suggestions on what I should be looking for to
> fix this on my board?

Any pointers to the driver in question?

Rafael

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


Re: Ethernet controller not starting

2014-03-03 Thread Jon Ringle
On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki  wrote:
> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
>> the latest LTS kernel).
>> I found that Ethernet controller on the board no longer comes up on 
>> linux-3.12.
>> I was able to bisect the issue I'm having to the following commit:
>>
>> >   45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>> >   commit 45f0a85c8258741d11bda25c0a5669c06267204a
>> >   Author: Rafael J. Wysocki 
>> >   Date:   Mon Jun 3 21:49:52 2013 +0200
>> >
>> >   PM / Runtime: Rework the "runtime idle" helper routine
>> >
>> >   The "runtime idle" helper routine, rpm_idle(), currently ignores
>> >   return values from .runtime_idle() callbacks executed by it.
>> >   However, it turns out that many subsystems use
>> >   pm_generic_runtime_idle() which checks the return value of the
>> >   driver's callback and executes pm_runtime_suspend() for the device
>> >   unless that value is not 0.  If that logic is moved to rpm_idle()
>> >   instead, pm_generic_runtime_idle() can be dropped and its users
>> >   will not need any .runtime_idle() callbacks any more.
>> >
>> >   Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>> >   routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>> >   ata_port_runtime_idle(), respectively, as well as a few drivers'
>> >   ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
>> >   been returned by the .runtime_idle() callback executed by it.
>> >
>> >   To reduce overall code bloat, make the changes described above.
>> >
>> >   Tested-by: Mika Westerberg 
>> >   Tested-by: Kevin Hilman 
>> >   Signed-off-by: Rafael J. Wysocki 
>> >   Acked-by: Kevin Hilman 
>> >   Reviewed-by: Ulf Hansson 
>> >   Acked-by: Alan Stern 
>>
>> Can anyone offer any suggestions on what I should be looking for to
>> fix this on my board?
>
> Any pointers to the driver in question?

drivers/net/ethernet/ti/davinci_emac.c

I also get the following output:

 Starting Network Manager Wait Online...
[   30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
[   30.953220] net net0: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
[   30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
[   31.082087] genirq: Flags mismatch irq 33.  (net0) vs.
 (net0)
[   31.089425] CPU: 0 PID: 679 Comm: NetworkManager Not tainted
3.12.13-fs1-003-g5ae24fe-dirty+ #1218
[   31.098496] Function entered at [] from []
[   31.104398] Function entered at [] from []
[   31.110292] Function entered at [] from []
[   31.116180] Function entered at [] from []
[   31.122069] Function entered at [] from []
[   31.127958] Function entered at [] from []
[   31.133852] Function entered at [] from []
[   31.139741] Function entered at [] from []
[   31.145630] Function entered at [] from []
[   31.151523] Function entered at [] from []
[   31.157412] Function entered at [] from []
[   31.163303] Function entered at [] from []
[   31.169193] Function entered at [] from []
[   31.175080] Function entered at [] from []
[   31.180969] Function entered at [] from []
[   31.186857] Function entered at [] from []
[   31.192747] Function entered at [] from []
[   31.198637] Function entered at [] from []
[   31.204528] Function entered at [] from []
[   31.210600] net net0: DaVinci EMAC: devm_request_irq() failed
[FAILED] Failed to start Network Manager Wait Online.

Putting a breakpoint on the genirq message, the backtrace is:

#0  __setup_irq (irq=irq@entry=33, desc=desc@entry=0xc0d24b10
, new=new@entry=0xc0a6a320) at kernel/irq/manage.c:1177
#1  0xc0042fa4 in request_threaded_irq (irq=irq@entry=33,
handler=handler@entry=0xc02a6bbc ,
thread_fn=thread_fn@entry=0x0 <__vectors_start>, irqflags=0,
irqflags@entry=3234987536, devname=0xc2f87000 \"net0\",
devname@entry=0xc02a7954  \"\",
dev_id=dev_id@entry=0xc2f87000) at kernel/irq/manage.c:1438
#2  0xc0044794 in devm_request_threaded_irq (dev=0xc0d1e688
, irq=irq@entry=33,
handler=handler@entry=0xc02a6bbc ,
thread_fn=thread_fn@entry=0x0 <__vectors_start>,
irqflags=irqflags@entry=0, devname=devname@entry=0xc2f87000 \"net0\",
dev_id=dev_id@entry=0xc2f87000) at kernel/irq/devres.c:60
#3  0xc02a7954 in devm_request_irq (dev_id=0xc2f87000,
devname=0xc2f87000 \"net0\", irqflags=0, handler=0xc02a6bbc
, irq=33, dev=) at
include/linux/interrupt.h:158
#4  emac_dev_open (ndev=0xc2f87000) at
drivers/net/ethernet/ti/davinci_emac.c:1569
#5  0xc03289b8 in __dev_open (dev=0xc2f87000) at net/core/dev.c:1256
#6  0xc0328bd8 in __dev_change_flags (dev=dev@entry=0xc2f87000,
flags=4099) at net/core/dev.c:5042
#7  0xc0328ce4 in dev_change_flags (dev=dev@entry=0xc2f87000,
flags=) at net/core/dev.c:5103
#8  0xc03340fc in do_setlink (dev=dev@entry=0xc2f87000,
ifm=ifm@entry=0xc2e67ed0, tb=tb@entry=0xc0a5dc64,
if

Re: [PATCH RESEND] sound: omap: n810: fix init with DT boot

2014-03-03 Thread Mark Brown
On Tue, Mar 04, 2014 at 12:45:18AM +0200, Aaro Koskinen wrote:
> Since 3.14-rc1 only DT boot has been supported on N810, so this
> file fails to init. Make a minimal fix to retain functionality.
> This file should be properly converted to DT in longer term.

Applied, please remember to use subject lines consistent with those for
the rest of the subsystem.


signature.asc
Description: Digital signature


Re: Help needed USB hub disconnected at resume

2014-03-03 Thread Igor Grinberg
On 03/03/14 16:11, Marc Murphy wrote:
> Hi Igor
> 
> The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port 
> via the DUP_P and DUP_N pins.  There is a reset applied to the chip at power 
> on.
> 

If the reset signal is sw controllable, you might want to toggle it
before the EHCI controller resumes.

There is also a USB phy on the way from EHCI controller to the hub.
You might also want to check if the phy resumes correctly.
Which phy do you use and how is it reset?

> Regards
> Marc
> 
> From: Igor Grinberg [grinb...@compulab.co.il]
> Sent: 03 March 2014 12:16
> To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org
> Subject: Re: Help needed USB hub disconnected at resume
> 
> On 03/03/14 13:06, Roger Quadros wrote:
>> Hi Marc,
>>
>> On 03/03/2014 12:04 PM, Marc Murphy wrote:
>>> Hi,
>>> I am using the latest stable 3.4.80 kernel with some changes to get the 
>>> EMAC Phy to initialise correctly after a suspend/resume.  The platform is 
>>> AM3517 with most of the system working nice and smoothly. I have 1 issue 
>>> though and need some advice/help to get the system to use the USB hub I 
>>> have connected to the EHCI controller after a suspend to memory and resume.
>>>
>>> At boot all is recognised;
>>>
>>> [1.486816] usbcore: registered new interface driver cdc_ether
>>> [1.493255] usbcore: registered new interface driver cdc_ncm
>>> [1.499450] usbcore: registered new interface driver qmi_wwan
>>> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator
>>> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
>>> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus 
>>> number 1
>>> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
>>> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
>>> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>>> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, 
>>> SerialNumber=1
>>> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller
>>> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd
>>> [2.585296] usb usb1: SerialNumber: ehci-omap.0
>>> [2.591278] hub 1-0:1.0: USB hub found
>>> [2.595306] hub 1-0:1.0: 3 ports detected
>>>
>>> And I can see everything OK.
>>>
>>> # lsusb
>>> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
>>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc.
>>> #
>>> #
>>> # echo mem > /sys/power/state
>>> [   73.736572] PM: Syncing filesystems ... done.
>>> [   73.743530] Freezing user space processes ... (elapsed 0.01 seconds) 
>>> done.
>>> [   73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 
>>> seconds) done.
>>> [   73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle
>>> [   73.968872] PM: suspend of devices complete after 170.410 msecs
>>> [   73.975433] PM: late suspend of devices complete after 0.305 msecs
>>> [   73.982635] PM: noirq suspend of devices complete after 0.732 msecs
>>> [   83.430450] Powerdomain (core_pwrdm) didn't enter target state 1
>>> [   83.436737] Could not enter target state in pm_suspend
>>> [   83.443176] PM: noirq resume of devices complete after 0.915 msecs
>>>  [   83.450164] PM: early resume of devices complete after 0.274 msecs
>>> [   83.457336] <6>Waiting for PHY clock good...
>>> [   83.463287] davinci_mdio davinci_mdio.0: resetting idled controller
>>> [   83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] 
>>> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
>>> [   84.771881] PM: resume of devices complete after 1315.185 msecs
>>> [   84.778472] Restarting tasks ...
>>> [   84.782379] usb 1-1: USB disconnect, device number 2
>>> [   84.790557] done.
>>> [   84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
>>> sh: write error:[   84.800781] usb 1-1.1: USB disconnect, device number 3
>>>  Operation not p[   84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 
>>> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device
>>> ermitted
>>> [   84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz
>>> [   86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full
>>> #
>>> #
>>> # lsusb
>>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> #
>>>
>>> Is there any relevant patch out there that would address the issue that I 
>>> see ?
>>
>> Does this happen because of OFF mode?
>> Can you please try the tests with off mode disabled?
>>
>> e

[PATCHv7 0/4] power_supply: Introduce power supply charging driver

2014-03-03 Thread Jenny TC
v1: introduced feature as a framework within power supply class driver with
separate files for battid framework and charging framework
v2: fixed review comments, moved macros and inline functions to power_supply.h
v3: moved the feature as a separate driver, combined battid framework and
charging framework inside the power supply charging driver. Moved
charger specific properties to power_supply_charger.h and plugged the
driver with power supply subsystem using power_supply_notifier
introduced in my previous patch. Also a sample charger chip driver
(bq24261) patch added to give more idea on the psy charging driver
usage
v4: Fixed review comments, no major design changes.
v5: Fixed makefile inconsistencies, removed unused pdata callbacks
v6: Fixed nested loops, commenting style
v7: added kerneldocs for structs and minor fixes

The Power Supply charging driver connects multiple subsystems
to do charging in a generic way. The subsystems involves power_supply,
thermal and battery communication subsystems (1wire).With this the charging is
handled in a generic way.

The driver makes use of different new features - Battery Identification
interfaces, pluggable charging algorithms, charger cable arbitrations etc.
The patch also introduces generic interface for charger cable notifications.
Charger cable events and capabilities can be notified using the generic
power_supply_notifier chain.

Overall this driver removes the charging logic out of the charger chip driver
and the charger chip driver can just listen to the request from the power
supply charging driver to set the charger properties. This can be implemented
by exposing get_property and set property callbacks.

Jenny TC (4):
  power_supply: Add inlmt,iterm, min/max temp props
  power_supply: Introduce generic psy charging driver
  power_supply: Introduce PSE compliant algorithm
  power_supply: bq24261 charger driver

 Documentation/power/power_supply_charger.txt |  353 +++
 Documentation/power/power_supply_class.txt   |6 +
 drivers/power/Kconfig|   31 +
 drivers/power/Makefile   |3 +
 drivers/power/bq24261-charger.c  | 1350 ++
 drivers/power/charging_algo_pse.c|  204 
 drivers/power/power_supply_charger.c | 1186 ++
 drivers/power/power_supply_charger.h |  218 +
 drivers/power/power_supply_core.c|3 +
 drivers/power/power_supply_sysfs.c   |4 +
 include/linux/power/bq24261-charger.h|   25 +
 include/linux/power/power_supply_charger.h   |  341 +++
 include/linux/power_supply.h |  164 
 13 files changed, 3888 insertions(+)
 create mode 100644 Documentation/power/power_supply_charger.txt
 create mode 100644 drivers/power/bq24261-charger.c
 create mode 100644 drivers/power/charging_algo_pse.c
 create mode 100644 drivers/power/power_supply_charger.c
 create mode 100644 drivers/power/power_supply_charger.h
 create mode 100644 include/linux/power/bq24261-charger.h
 create mode 100644 include/linux/power/power_supply_charger.h

-- 
1.7.9.5

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


[PATCHv7 4/4] power_supply: bq24261 charger driver

2014-03-03 Thread Jenny TC
This patch introduces BQ24261 charger driver. The driver makes use of power
supply charging driver to setup charging. So the driver does hardware
abstraction and handles h/w specific corner cases. The charging logic resides
with power supply charging driver

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig |   10 +
 drivers/power/Makefile|1 +
 drivers/power/bq24261-charger.c   | 1350 +
 include/linux/power/bq24261-charger.h |   25 +
 4 files changed, 1386 insertions(+)
 create mode 100644 drivers/power/bq24261-charger.c
 create mode 100644 include/linux/power/bq24261-charger.h

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 913ec36..a1c2780 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -409,6 +409,16 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config CHARGER_BQ24261
+   tristate "BQ24261 charger driver"
+   select POWER_SUPPLY_CHARGER
+   depends on I2C
+   help
+ Say Y to include support for BQ24261 Charger driver. This driver
+ makes use of power supply charging driver. So the driver gives
+ the charger hardware abstraction only. Charging logic is abstracted
+ in the power supply charging driver.
+
 source "drivers/power/reset/Kconfig"
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 77535fd..9dde895 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
+obj-$(CONFIG_CHARGER_BQ24261)  += bq24261-charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
diff --git a/drivers/power/bq24261-charger.c b/drivers/power/bq24261-charger.c
new file mode 100644
index 000..187c1fe
--- /dev/null
+++ b/drivers/power/bq24261-charger.c
@@ -0,0 +1,1350 @@
+/*
+ * bq24261-charger.c - BQ24261 Charger I2C client driver
+ *
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * ~~
+ *
+ * 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; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define DEV_NAME "bq24261_charger"
+#define MODEL_NAME_SIZE 8
+
+#define EXCEPTION_MONITOR_DELAY (60 * HZ)
+#define WDT_RESET_DELAY (15 * HZ)
+
+/* BQ24261 registers */
+#define BQ24261_STAT_CTRL0_ADDR0x00
+#define BQ24261_CTRL_ADDR  0x01
+#define BQ24261_BATT_VOL_CTRL_ADDR 0x02
+#define BQ24261_VENDOR_REV_ADDR0x03
+#define BQ24261_TERM_FCC_ADDR  0x04
+#define BQ24261_VINDPM_STAT_ADDR   0x05
+#define BQ24261_ST_NTC_MON_ADDR0x06
+
+#define BQ24261_RESET_MASK (0x01 << 7)
+#define BQ24261_RESET_ENABLE   (0x01 << 7)
+
+#define BQ24261_FAULT_MASK 0x07
+#define BQ24261_STAT_MASK  (0x03 << 4)
+#define BQ24261_BOOST_MASK (0x01 << 6)
+#define BQ24261_TMR_RST_MASK   (0x01 << 7)
+#define BQ24261_TMR_RST(0x01 << 7)
+
+#define BQ24261_ENABLE_BOOST   (0x01 << 6)
+
+#define BQ24261_VOVP   0x01
+#define BQ24261_LOW_SUPPLY 0x02
+#define BQ24261_THERMAL_SHUTDOWN   0x03
+#define BQ24261_BATT_TEMP_FAULT0x04
+#define BQ24261_TIMER_FAULT0x05
+#define BQ24261_BATT_OVP   0x06
+#define BQ24261_NO_BATTERY 0x07
+#define BQ24261_STAT_READY 0x00
+
+#define BQ24261_STAT_CHRG_PRGRSS   (0x01 << 4)
+#define BQ24261_STAT_CHRG_DONE (0x02 << 4)
+#define BQ24261_STAT_FAULT (0x03 << 4)
+
+#define BQ24261_CE_MASK(0x01 << 1)
+#define BQ24261_CE_DISABLE (0x01 << 1)
+
+#define BQ24261_HZ_MASK(0x01)
+#define BQ24261_HZ_ENABLE  (0x01)
+
+#define BQ24261_ICHRG_MASK (0x1F << 3)
+#define BQ24261_MIN_CC 500 /* 500mA */
+#define BQ24261_MAX_CC 3000 /* 3A */
+
+#define BQ24261_ITERM_MASK (0x03)
+#define BQ24261_MIN_ITERM 50 /* 50 mA */
+#define BQ24261_MAX_ITERM 300 /* 300

[PATCH v7 1/4] power_supply: Add inlmt,iterm, min/max temp props

2014-03-03 Thread Jenny TC
Add new power supply properties for input current, charge termination
current, min and max temperature

POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature

POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates
the input current for a charging source.

POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect
the end of charge condition

Signed-off-by: Jenny TC 
---
 Documentation/power/power_supply_class.txt |6 ++
 drivers/power/power_supply_sysfs.c |4 
 include/linux/power_supply.h   |4 
 3 files changed, 14 insertions(+)

diff --git a/Documentation/power/power_supply_class.txt 
b/Documentation/power/power_supply_class.txt
index 89a8816..48cff88 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -118,6 +118,10 @@ relative, time-based measurements.
 CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
 CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
 power supply object.
+INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
+the current drawn from a charging source.
+CHARGE_TERM_CURRENT - Charge termination current used to detect the end of 
charge
+condition.
 
 CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
 CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
@@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert.
 TEMP_AMBIENT - ambient temperature.
 TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
 TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
+TEMP_MIN - minimum operatable temperature
+TEMP_MAX - maximum operatable temperature
 
 TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
 while battery powers a load)
diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 44420d1..750a202 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+   POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
@@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(capacity_alert_max),
POWER_SUPPLY_ATTR(capacity_level),
POWER_SUPPLY_ATTR(temp),
+   POWER_SUPPLY_ATTR(temp_max),
+   POWER_SUPPLY_ATTR(temp_min),
POWER_SUPPLY_ATTR(temp_alert_min),
POWER_SUPPLY_ATTR(temp_alert_max),
POWER_SUPPLY_ATTR(temp_ambient),
@@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
+   POWER_SUPPLY_ATTR(charge_term_current),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c9dc4e0..0278600 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -120,6 +120,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+   POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -131,6 +132,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
+   POWER_SUPPLY_PROP_TEMP_MAX,
+   POWER_SUPPLY_PROP_TEMP_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
@@ -142,6 +145,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
+   POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
-- 
1.7.9.5

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


[PATCHv7 3/4] power_supply: Introduce PSE compliant algorithm

2014-03-03 Thread Jenny TC
As per Product Safety Engineering (PSE) specification for battery charging, the
battery characteristics and thereby the charging rates can vary on different
temperature zones. This patch introduces a PSE compliant charging algorithm with
maintenance charging support. The algorithm can be selected by the power supply
charging driver based on the type of the battery charging profile.

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig  |   13 ++
 drivers/power/Makefile |1 +
 drivers/power/charging_algo_pse.c  |  204 
 include/linux/power/power_supply_charger.h |   63 +
 4 files changed, 281 insertions(+)
 create mode 100644 drivers/power/charging_algo_pse.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f679f82..913ec36 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER
  drivers to keep the charging logic outside and the charger driver
  just need to abstract the charger hardware.
 
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+   bool "PSE compliant charging algorithm"
+   help
+ Say Y here to select Product Safety Engineering (PSE) compliant
+ charging algorithm. As per PSE standard the battery characteristics
+ and thereby the charging rates can vary on different temperature
+ zones. This config will enable PSE compliant charging algorithm with
+ maintenance charging support. At runtime the algorithm will be
+ selected by the psy charger driver based on the type of the battery
+ charging profile.
+
+   depends on POWER_SUPPLY_CHARGER
+
 config PDA_POWER
tristate "Generic PDA/phone power driver"
depends on !S390
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 405f0f4..77535fd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY)  += power_supply.o
 obj-$(CONFIG_GENERIC_ADC_BATTERY)  += generic-adc-battery.o
 
 obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
+obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
diff --git a/drivers/power/charging_algo_pse.c 
b/drivers/power/charging_algo_pse.c
new file mode 100644
index 000..ac95885
--- /dev/null
+++ b/drivers/power/charging_algo_pse.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~
+ *
+ * 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; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "power_supply.h"
+#include "power_supply_charger.h"
+
+/* 98% of CV is considered as voltage to detect Full */
+#define FULL_CV_MIN 98
+
+/*
+ * Offset to exit from maintenance charging. In maintenance charging
+ * if the volatge is less than the (maintenance_lower_threshold -
+ * MAINT_EXIT_OFFSET) then system can switch to normal charging
+ */
+
+#define MAINT_EXIT_OFFSET 50  /* mV */
+
+static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
+   int temp)
+{
+   int i = 0;
+   int temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
+   BATT_TEMP_NR_RNG);
+
+   if ((temp < pse_mod_bprof->temp_low_lim) ||
+   (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim))
+   return -EINVAL;
+
+   for (i = 0; i < temp_range_cnt; ++i)
+   if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim)
+   break;
+   return i-1;
+}
+
+static inline bool is_charge_terminated(long volt, long cur,
+   long iterm, unsigned long cv)
+{
+   pr_devel("%s:current=%ld pse_mod_bprof->chrg_term_mA =%ld 
voltage_now=%ld full_cond=%ld",
+   __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv));
+
+   return (cur > 0) && (cur <= iterm) &&
+   ((volt * 100)  >= (FULL_CV_MIN * cv));
+
+}
+
+static inline bool is_battery_full(struct psy_batt_props bat_prop,
+   struct psy_pse_chrg_prof *pse_mod_bprof, unsigned long cv)
+{
+
+   int i;
+
+   /*
+   * Software full detection. Check

Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver

2014-03-03 Thread Archit Taneja

Hi Hans,

On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote:

Hi Archit!

On 03/03/2014 08:33 AM, Archit Taneja wrote:

Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.

For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.

Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for this purpose.

Some standard crop parameter checks are done in __vpe_try_crop().


Please use the selection ops instead: if you implement cropping with those then 
you'll
support both the selection API and the old cropping API will be implemented by 
the v4l2
core using the selection ops. Two for the price of one...



When using selection API, I was finding issues using the older cropping 
API. The v4l_s_crop() ioctl func assumes that "crop means compose for 
output devices". However, for a m2m device. It probably makes sense to 
provide the following configuration:


for V4L2_BUF_TYPE_VIDEO_OUTPUT (input to the mem to mem HW), use CROP 
target(to crop the input buffer)


and, for V4L2_BUF_TYPE_VIDEO_CAPTURE(output of the mem to mem HW), use 
COMPOSE target(to place the HW output into a larger region)


Don't you think forcing OUTPUT devices to 'COMPOSE' for older cropping 
API is a bit limiting?



Thanks,
Archit

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


Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver

2014-03-03 Thread Hans Verkuil
On 03/04/2014 08:38 AM, Archit Taneja wrote:
> Hi Hans,
> 
> On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote:
>> Hi Archit!
>>
>> On 03/03/2014 08:33 AM, Archit Taneja wrote:
>>> Add crop ioctl ops. For VPE, cropping only makes sense with the input to 
>>> VPE, or
>>> the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
>>>
>>> For the CAPTURE type, a S_CROP ioctl results in setting the crop region as 
>>> the
>>> whole image itself, hence making crop dimensions same as the pix dimensions.
>>>
>>> Setting the crop successfully should result in re-configuration of those
>>> registers which are affected when either source or destination dimensions
>>> change, set_srcdst_params() is called for this purpose.
>>>
>>> Some standard crop parameter checks are done in __vpe_try_crop().
>>
>> Please use the selection ops instead: if you implement cropping with those 
>> then you'll
>> support both the selection API and the old cropping API will be implemented 
>> by the v4l2
>> core using the selection ops. Two for the price of one...
> 
> 
> When using selection API, I was finding issues using the older cropping 
> API. The v4l_s_crop() ioctl func assumes that "crop means compose for 
> output devices". However, for a m2m device. It probably makes sense to 
> provide the following configuration:
> 
> for V4L2_BUF_TYPE_VIDEO_OUTPUT (input to the mem to mem HW), use CROP 
> target(to crop the input buffer)
> 
> and, for V4L2_BUF_TYPE_VIDEO_CAPTURE(output of the mem to mem HW), use 
> COMPOSE target(to place the HW output into a larger region)
> 
> Don't you think forcing OUTPUT devices to 'COMPOSE' for older cropping 
> API is a bit limiting?

Yes, and that's why the selection API was created to work around that
limitation :-)

The old cropping API was insufficiently flexible for modern devices, so
we came up with this replacement.

Another reason why you have to implement the selection API: it's the only
way to implement your functionality.

Regards,

Hans

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