Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Tomi Valkeinen 
On 2014-01-29 20:52, Ivaylo Dimitrov wrote:

>> Can you try this one:
>>
>>  From e511789f7be00be0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
>> From: Tomi Valkeinen 
>> Date: Wed, 29 Jan 2014 13:28:53 +0200
>> Subject: [PATCH] clkoutx2 fix
>>
>> ---
>>   arch/arm/mach-omap2/cclock3xxx_data.c |  7 +++
>>   arch/arm/mach-omap2/dpll3xxx.c| 20 
>>   2 files changed, 27 insertions(+)
>>
> 
> Yep, that one fixes the problem. Thanks!

Ok, good. I'll probably do some studying about clk framework and clean
up the patch and post it.

Btw, the clkoutx2 fix makes the DSS clocks work for you generally, but
if you happen to hit clock rates that don't divide evenly, you may also
need the patches for clk-divider and dss I posted earlier.

> Now I only need to find why maemo is 10 times slower with linux-next
> compared to 3.13-rc7, but that is another story :).

I sure hope it's not DSS's doings =).

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 0/5] Smart Card(SC) interface, TI USIM & NxP SC phy driver

2014-01-29 Thread Satish Patel 

On 1/20/2014 10:03 AM, Satish Patel wrote:
> Changes from v1:
> * RFC(v1) comments are fixed
>
> ** removed "gpio_to_irq" as GPIO controller process  cell from DT and
> give it to DT node
> ** comments on documentation
> ** few other comments on null checks are resolved
>
> * BWT timing configuration is added to ti-usim driver
>
> v1 cover letter link#
> https://lkml.org/lkml/2014/1/6/250
>
> Satish Patel (5):
>   sc_phy:SmartCard(SC) PHY interface to SC controller
>   misc: tda8026: Add NXP TDA8026 PHY driver
>   char: ti-usim: Add driver for USIM module on AM43xx
>   ARM: dts: AM43xx: DT entries added for ti-usim
>   ARM: dts: AM43xx-epos-evm: DT entries  for ti-usim and phy
>
>  Documentation/devicetree/bindings/misc/tda8026.txt |   19 +
>  .../devicetree/bindings/ti-usim/ti-usim.txt|   31 +
>  Documentation/sc_phy.txt   |  171 ++
>  arch/arm/boot/dts/am4372.dtsi  |   10 +
>  arch/arm/boot/dts/am43x-epos-evm.dts   |   43 +
>  drivers/char/Kconfig   |7 +
>  drivers/char/Makefile  |1 +
>  drivers/char/ti-usim-hw.h  |  863 +
>  drivers/char/ti-usim.c | 1859 
> 
>  drivers/misc/Kconfig   |7 +
>  drivers/misc/Makefile  |1 +
>  drivers/misc/tda8026.c | 1255 +
>  include/linux/sc_phy.h |  132 ++
>  include/linux/ti-usim.h|   98 +
>  14 files changed, 4497 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt
>  create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt
>  create mode 100644 Documentation/sc_phy.txt
>  create mode 100644 drivers/char/ti-usim-hw.h
>  create mode 100644 drivers/char/ti-usim.c
>  create mode 100644 drivers/misc/tda8026.c
>  create mode 100644 include/linux/sc_phy.h
>  create mode 100644 include/linux/ti-usim.h
Any comments on this patch series ?

If not,
Can you accept these patches for next merge window

Thanks
Satish

>
>

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

[PATCH 0/4] ARM: dts: OMAP3630+: Add ABB device nodes

2014-01-29 Thread Nishanth Menon 
Now that clock nodes have been merged to master,
refresh of the series meant for all TI platforms using ABB.
Originally posted [1], I will restart with v1.

dt bindings and driver is already in upstream, and only the dt node is missing.

NOTE: dra7 support depends on [2] - but dt can get sequenced as needed.

This series is based on:
master 0e47c96 Merge tag 'for-linus-20140127' of 
git://git.infradead.org/linux-mtd
Testing was performed on next-20140123[3]

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

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

 arch/arm/boot/dts/dra7.dtsi |  132 +++
 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 +++
 arch/arm/boot/dts/omap5.dtsi|   63 +++
 6 files changed, 304 insertions(+)

[1] http://marc.info/?l=linux-omap&m=136751535923806&w=2
[2] 
https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=topic/ti-abb
[3] https://patchwork.kernel.org/patch/3530111/

-- 
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 2/4] ARM: dts: OMAP4: Add device nodes for ABB

2014-01-29 Thread Nishanth Menon 
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 
---
 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 d3f8a6e..72e6bd7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -757,6 +757,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";
+
+   ti,abb_i

[PATCH 1/4] ARM: dts: OMAP36xx: Add device node for ABB

2014-01-29 Thread Nishanth Menon 
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 
---
 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.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 4/4] ARM: dts: DRA7: Add device nodes for ABB

2014-01-29 Thread 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 
---
Depends on https://patchwork.kernel.org/patch/3530111/

 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 1fd75aa..23a2a11 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -559,6 +559,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
+

[PATCH 3/4] ARM: dts: OMAP5: Add device nodes for ABB

2014-01-29 Thread Nishanth Menon 
From: "Andrii.Tseglytskyi" 

Add ABB device nodes for OMAP5 family of devices. Data is based on
OMAP543x Technical Reference Manual revision U (April 2013).
NOTE: clock node has been disabled in this patch due to the lack of
OMAP5 clock data.

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

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..6159f20 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -801,6 +801,69 @@
 
#thermal-sensor-cells = <1>;
};
+
+   abb_mpu: regulator-abb-mpu {
+   compatible = "ti,abb-v2";
+   regulator-name = "abb_mpu";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   clocks = <&sys_clkin>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   reg = <0x4ae07cdc 0x8>, <0x4ae06014 0x4>,
+ <0x4a0021ac 0x18>, <0x4ae0C318 0x4>;
+   reg-names = "base-address", "int-address",
+   "efuse-address", "ldo-address";
+   ti,tranxdone-status-mask = <0x80>;
+   /* LDOVBBMPU_MUX_CTRL */
+   ti,ldovbb-override-mask = <0x400>;
+   /* LDOVBBMPU_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*/
+   88  0   0x4 0 0x2000 0x1F00
+   106 0   0x8 0 0x2000 0x1F00
+   125 0   0x100 0x2000 0x1F00
+   126 1   0x140 0x2000 0x1F00
+   >;
+   };
+
+   abb_mm: regulator-abb-mm {
+   compatible = "ti,abb-v2";
+   regulator-name = "abb_mm";
+   #address-cells = <0>;
+   #size-cells = <0>;
+   clocks = <&sys_clkin>;
+   ti,settling-time = <50>;
+   ti,clock-cycles = <16>;
+
+   reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>,
+ <0x4a002194 0x14>, <0x4ae0C314 0x4>;
+   reg-names = "base-address", "int-address",
+   "efuse-address", "ldo-address";
+   ti,tranxdone-status-mask = <0x8000>;
+   /* LDOVBBMM_MUX_CTRL */
+   ti,ldovbb-override-mask = <0x400>;
+   /* LDOVBBMM_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*/
+   88  0   0x4 0 0x2000 0x1F00
+   1025000 0   0x8 0 0x2000 0x1F00
+   112 1   0x100 0x2000 0x1F00
+   >;
+   };
};
 };
 
-- 
1.7.9.5

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

Re: [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU

2014-01-29 Thread Nishanth Menon 
On 01/29/2014 01:29 PM, Robert Nelson wrote:
> On Wed, Jan 29, 2014 at 12:19 PM, Nishanth Menon  wrote:
>> OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
>>
>> OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
>> dpll_mpu clock.
>>
>> Latency used is the generic latency defined in omap-cpufreq
>> driver.
>>
>> Signed-off-by: Nishanth Menon 
> 
> Hi Nishanth,
> 
> After this patch, do you see any limitation to finally enabling 1Ghz
> operation on the beagle-xm by default? Or are we still missing a
> dependicy somewhere?

yes, there is:
a) ABB dt series - i will repost this in a few mins
b) AVS conversion from non-dt mode to dt supported mode. (which by
itself depends on VC/VP conversion).
c) clk notifier based dvfs for cpufreq-cpu0 -> this allows us to
introduce the necessary plumbing for mpu voltage domain such that the
TWL4030 regulator, AVS and ABB are rightly sequenced.

What you have done in the patch below is to introduce ABB regulator -
but no one is actually using it -> this might actually work on certain
samples at 1GHz, but prolonged operation will either damage the device
or fail on other samples - I have tried numerous times Internally to
get approval for non ABB/AVS configuration for 1GHz - but I have a
clear feedback that it cannot be done with the constraints of
DM3730/OMAP3630.

Lets do this a series at a time and build up the necessary support -
we get clock nodes for dvfs (using i2c1) here with cpufreq-cpu0 with
this series. If folks can ack and queue this up, we can get in ABB dts
nodes in place - allowing us to work on the next set -> sequencing
using clock notifier. in parallel we could work on converting AVS back
to dt based solution.

yes, the road is long.

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

[PATCH 1/5] iio: add support for pulse width capture devices

2014-01-29 Thread Matt Porter 
Add a channel type to support pulse width capture devices.
These devices capture the timing of a PWM signal based on a
configurable trigger

Signed-off-by: Matt Porter 
---
 drivers/iio/industrialio-core.c | 1 +
 include/linux/iio/types.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a..6ea0cf8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CCT] = "cct",
[IIO_PRESSURE] = "pressure",
[IIO_HUMIDITYRELATIVE] = "humidityrelative",
+   [IIO_PULSE] = "pulse",
 };
 
 static const char * const iio_modifier_names[] = {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..4fa8840 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -30,6 +30,7 @@ enum iio_chan_type {
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
+   IIO_PULSE,
 };
 
 enum iio_modifier {
-- 
1.8.4

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

[PATCH 5/5] ARM: dts: AM33XX: Add ecap interrupt properties

2014-01-29 Thread Matt Porter 
Add missing interrupt properties to the ecap0, ecap1, and ecap2
nodes.

Signed-off-by: Matt Porter 
---
 arch/arm/boot/dts/am33xx.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..b4139ba 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -582,6 +582,8 @@
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48300100 0x80>;
+   interrupts = <31>;
+   interrupt-names = "ecap0";
ti,hwmods = "ecap0";
status = "disabled";
};
@@ -610,6 +612,8 @@
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48302100 0x80>;
+   interrupts = <47>;
+   interrupt-names = "ecap1";
ti,hwmods = "ecap1";
status = "disabled";
};
@@ -638,6 +642,8 @@
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48304100 0x80>;
+   interrupts = <61>;
+   interrupt-names = "ecap2";
ti,hwmods = "ecap2";
status = "disabled";
};
-- 
1.8.4

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

[PATCH 4/5] pwm: enable TI PWMSS if the IIO tiecap driver is selected

2014-01-29 Thread Matt Porter 
The IIO TI ECAP driver depends on the TI PWMSS management
driver in this subsystem. Enable PWMSS when the IIO TI ECAP
driver is selected.

Signed-off-by: Matt Porter 
---
 drivers/pwm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 22f2f28..bd3cc65 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -219,7 +219,7 @@ config  PWM_TIEHRPWM
 
 config  PWM_TIPWMSS
bool
-   default y if SOC_AM33XX && (PWM_TIECAP || PWM_TIEHRPWM)
+   default y if SOC_AM33XX && (IIO_TIECAP || PWM_TIECAP || PWM_TIEHRPWM)
help
  PWM Subsystem driver support for AM33xx SOC.
 
-- 
1.8.4

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

[PATCH 3/5] iio: enable selection and build of pulse drivers

2014-01-29 Thread Matt Porter 
Add the pulse driver subdirectory when configuring and building
IIO.

Signed-off-by: Matt Porter 
---
 drivers/iio/Kconfig  | 1 +
 drivers/iio/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 5dd0e12..286acc3 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -74,6 +74,7 @@ if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
 endif #IIO_TRIGGER
 source "drivers/iio/pressure/Kconfig"
+source "drivers/iio/pulse/Kconfig"
 source "drivers/iio/temperature/Kconfig"
 
 endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 887d390..9a953c9 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -24,5 +24,6 @@ obj-y += light/
 obj-y += magnetometer/
 obj-y += orientation/
 obj-y += pressure/
+obj-y += pulse/
 obj-y += temperature/
 obj-y += trigger/
-- 
1.8.4

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

[PATCH 2/5] iio: pulse: add TI ECAP driver

2014-01-29 Thread Matt Porter 
Adds support for capturing PWM signals using the TI ECAP peripheral.
This driver supports triggered buffer capture of pulses on multiple
ECAP instances. In addition, the driver supports configurable polarity
of the signal to be captured.

Signed-off-by: Matt Porter 
---
 drivers/iio/pulse/Kconfig  |  20 ++
 drivers/iio/pulse/Makefile |   6 +
 drivers/iio/pulse/tiecap.c | 493 +
 3 files changed, 519 insertions(+)
 create mode 100644 drivers/iio/pulse/Kconfig
 create mode 100644 drivers/iio/pulse/Makefile
 create mode 100644 drivers/iio/pulse/tiecap.c

diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
new file mode 100644
index 000..9864d4b
--- /dev/null
+++ b/drivers/iio/pulse/Kconfig
@@ -0,0 +1,20 @@
+#
+# Pulse Capture Devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Pulse Capture Devices"
+
+config IIO_TIECAP
+   tristate "TI ECAP Pulse Capture"
+   depends on SOC_AM33XX
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+If you say yes here you get support for the TI ECAP peripheral
+in pulse capture mode.
+
+This driver can also be built as a module.  If so, the module
+will be called tiecap
+
+endmenu
diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
new file mode 100644
index 000..94d4b00
--- /dev/null
+++ b/drivers/iio/pulse/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO PWM Capture Devices
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_TIECAP)   += tiecap.o
diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
new file mode 100644
index 000..8e2b3a0
--- /dev/null
+++ b/drivers/iio/pulse/tiecap.c
@@ -0,0 +1,493 @@
+/*
+ * ECAP IIO pulse capture driver
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: Matt Porter 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../../pwm/pwm-tipwmss.h"
+
+/* ECAP regs and bits */
+#define CAP1   0x08
+#define CAP2   0x0c
+#define ECCTL1 0x28
+#define ECCTL1_RUN_FREEBIT(15)
+#define ECCTL1_CAPLDEN BIT(8)
+#define ECCTL1_CAP2POL BIT(2)
+#define ECCTL1_CTRRST1 BIT(1)
+#define ECCTL1_CAP1POL BIT(0)
+#define ECCTL2 0x2a
+#define ECCTL2_SYNCO_SEL_DIS   BIT(7)
+#define ECCTL2_TSCTR_FREERUN   BIT(4)
+#define ECCTL2_REARM   BIT(3)
+#define ECCTL2_STOP_WRAP_2 BIT(1)
+#define ECEINT 0x2c
+#define ECFLG  0x2e
+#define ECCLR  0x30
+#define ECINT_CTRCMP   BIT(7)
+#define ECINT_CTRPRD   BIT(6)
+#define ECINT_CTROVF   BIT(5)
+#define ECINT_CEVT4BIT(4)
+#define ECINT_CEVT3BIT(3)
+#define ECINT_CEVT2BIT(2)
+#define ECINT_CEVT1BIT(1)
+#define ECINT_ALL  (ECINT_CTRCMP | \
+   ECINT_CTRPRD |  \
+   ECINT_CTROVF |  \
+   ECINT_CEVT4 |   \
+   ECINT_CEVT3 |   \
+   ECINT_CEVT2 |   \
+   ECINT_CEVT1)
+
+/* ECAP driver flags */
+#define ECAP_POLARITY_HIGH BIT(1)
+#define ECAP_ENABLED   BIT(0)
+
+struct ecap_context {
+   u32 cap1;
+   u32 cap2;
+   u16 ecctl1;
+   u16 ecctl2;
+   u16 eceint;
+};
+
+struct ecap_state {
+   unsigned long   flags;
+   unsigned intclk_rate;
+   void __iomem*regs;
+   u32 *buf;
+   struct ecap_context ctx;
+};
+
+#define dev_to_ecap_state(d)   iio_priv(dev_to_iio_dev(d))
+
+static const struct iio_chan_spec ecap_channels[] = {
+   {
+   .type   = IIO_PULSE,
+   .channel= 0,
+   .info_mask_separate =
+   BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+   .scan_index = 0,
+   .scan_type = {
+   .sign   = 'u',
+   .realbits   = 32,
+   .storagebits= 32,
+   .endianness = IIO_LE,
+   },
+   .modified = 0,
+   },
+   IIO_CHAN_SOFT_TIMESTAMP(1)
+};
+
+static ssize_t ecap_attr_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct ecap_state *state = dev_to_ecap_state(dev);
+
+   return sprint

[PATCH 0/5] IIO pulse capture support for TI ECAP

2014-01-29 Thread Matt Porter 
This series adds support for PWM capture devices within IIO and
adds a TI ECAP IIO driver.

PWM capture devices are supported using a new IIO "pulse" channel type.

The IIO ECAP driver implements interrupt driven triggered buffer capture
only as raw sample reads are not applicable to this hardware.
Initially, the driver supports a single pulse width measurement with
configurable polarity. The ECAP hardware can support measurement of a
complete period and duty cycle but this is not yet implemented.

Matt Porter (5):
  iio: add support for pulse width capture devices
  iio: pulse: add TI ECAP driver
  iio: enable selection and build of pulse drivers
  pwm: enable TI PWMSS if the IIO tiecap driver is selected
  ARM: dts: AM33XX: Add ecap interrupt properties

 arch/arm/boot/dts/am33xx.dtsi   |   6 +
 drivers/iio/Kconfig |   1 +
 drivers/iio/Makefile|   1 +
 drivers/iio/industrialio-core.c |   1 +
 drivers/iio/pulse/Kconfig   |  20 ++
 drivers/iio/pulse/Makefile  |   6 +
 drivers/iio/pulse/tiecap.c  | 493 
 drivers/pwm/Kconfig |   2 +-
 include/linux/iio/types.h   |   1 +
 9 files changed, 530 insertions(+), 1 deletion(-)
 create mode 100644 drivers/iio/pulse/Kconfig
 create mode 100644 drivers/iio/pulse/Makefile
 create mode 100644 drivers/iio/pulse/tiecap.c

-- 
1.8.4

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

Re: [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU

2014-01-29 Thread Robert Nelson 
On Wed, Jan 29, 2014 at 12:19 PM, Nishanth Menon  wrote:
> OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
>
> OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
> dpll_mpu clock.
>
> Latency used is the generic latency defined in omap-cpufreq
> driver.
>
> Signed-off-by: Nishanth Menon 

Hi Nishanth,

After this patch, do you see any limitation to finally enabling 1Ghz
operation on the beagle-xm by default? Or are we still missing a
dependicy somewhere?

cpufreq stats: 300 MHz:98.64%, 600 MHz:0.04%, 800 MHz:0.09%, 1000
MHz:1.23%  (11)
full cpufreq output: http://paste.debian.net/79073/

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index bb5dad0..b0e5863 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -16,9 +16,36 @@
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
+   operating-points = <
+   /* kHzuV */
+   30   1012500
+   60   120
+   80   1325000
+   100  138
+   >;
};
};

+   abb: regulator-abb {
+   compatible = "ti,abb-v1";
+   regulator-name = "abb";
+   #address-cell = <0>;
+   #size-cells = <0>;
+   reg = <0x483072f0 0x8>, <0x48306818 0x4>;
+   reg-names = "base-address", "int-address";
+   ti,tranxdone-status-mask = <0x400>;
+   clocks = <&dpll1_ck>;
+   ti,settling-time = <30>;
+   ti,clock-cycles = <8>;
+   ti,abb_info = <
+   /* uV   ABB efuse   rbb_m   fbb_m
 vset_m */
+   1012500 0   0   0   0
 0 /* Bypass */
+   120 3   0   0   0
 0 /* RBB mandatory */
+   132 1   0   0   0
 0 /* FBB mandatory */
+   138 1   0   0   0   0
+   >;
+   };
+
memory {
device_type = "memory";
reg = <0x8000 0x2000>; /* 512 MB */
-- 
1.8.5.3

Regards,

-- 
Robert Nelson
http://www.rcn-ee.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: OMAP: clock DT conversion issues with omap36xx

2014-01-29 Thread Nishanth Menon 
On 01/29/2014 05:21 AM, Christoph Fritz wrote:
> On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
>> On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
>>>
> Due to a regression since next-20140122 the following errors are present:
>
>   - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
> in this set, erroneously outputs only 12 Mhz.
> Just out of curiosity, configuring it to 48 Mhz puts out desired 24 
> Mhz.
>
>   - omap_dss, which gets configured by the third patch in this set, fails
> to do 'dss_set_fck_rate(fck);' in
> drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads 
> to:
>
>  | omapdss_dss: probe of omapdss_dss failed with error -22
>  | omapdss CORE error: Failed to initialize DSS platform driver
>  | panel-dpi panel-dpi.0: failed to find video source 'dpi.0
>
>Both regressions seem to have something to do with the clock framework.
>Could this be related to the DT clock conversion patches?

>>>
>>> Yea its definitely possible, as the clock DT conversion touches pretty 
>>> much everything. Have you tried whether this works properly with legacy 
>>> boot? Personally I don't have access to any omap3 devices that would 
>>> have display and have no possibility to check this out myself. Anyway, 
>>> my initial guess is that some clock divider setup might be wrong with 
>>> omap3, or we are missing some ti,set-rate-parent flag for some clock 
>>> node which prevents escalating clk_set_rate properly. However, it should 
>>> be easy to debug this by looking at the clock node in question, and its 
>>> parent nodes to see if there are any problems.
>>
>> Currently I only analyzed sys_clkout2 (see attachments for full
>> clk_summary files):

To help us debug similar problems, I wrote a tool today:
https://github.com/nmenon/ctt-dump - it is a simple memory read utility,

Input file is CTT dump-out
For example: 3630 CTT is here:
http://www.ti.com/pdfs/wtbu/CTT-OMAP3630ES1.x-v1.6.0.4.zip

to give an idea - i posted a screen shot here:
https://plus.google.com/112464029509057661457/posts/hNdee4gNfob

After generating the the rd1 file from CTT,
we pick up the registers using ctt-dump -> any tool which can do
register reads could do, but it might be handy having this.
Example output on beagle-xm: http://slexy.org/view/s2YWmM1ium
importing it back into CTT and after setting up the correct sysclk, we
can compare clock frequencies Vs debugfs output - example:
http://slexy.org/view/s21iQyDTct


I mean, it is awesome having to debugfs data, but with nascent
systems, it is always good to compare to what the hardware is really
configured to - and CTT is the easy way to deal with it.

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

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Ivaylo Dimitrov 



On 29.01.2014 13:30, Tomi Valkeinen wrote:

On 2014-01-28 20:17, Ivaylo Dimitrov wrote:



On 28.01.2014 10:48, Tomi Valkeinen wrote:


I made a somewhat hacky quickfix for beagle. Applying that and the
clk-divider from the link above makes things work for me. However, as I
said, the issue with n900 might be different, but it'd be interesting to
hear if it has any effect.

   Tomi



Applying those 2 patches doesn't help, still get exactly the same warning.

Find attached my clk_summary (with my hacky patch applied, otherwise I
cannot boot the device)


Can you try this one:

 From e511789f7be00be0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Wed, 29 Jan 2014 13:28:53 +0200
Subject: [PATCH] clkoutx2 fix

---
  arch/arm/mach-omap2/cclock3xxx_data.c |  7 +++
  arch/arm/mach-omap2/dpll3xxx.c| 20 
  2 files changed, 27 insertions(+)



Yep, that one fixes the problem. Thanks!

Now I only need to find why maemo is 10 times slower with linux-next 
compared to 3.13-rc7, but that is another story :).


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

[PATCH 1/2] clk: ti: am335x: remove unecessary cpu0 clk node

2014-01-29 Thread Nishanth Menon 
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.

Signed-off-by: Nishanth Menon 
---
 drivers/clk/ti/clk-33xx.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index 776ee45..028b337 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
DT_CLK(NULL, "dpll_core_m5_ck", "dpll_core_m5_ck"),
DT_CLK(NULL, "dpll_core_m6_ck", "dpll_core_m6_ck"),
DT_CLK(NULL, "dpll_mpu_ck", "dpll_mpu_ck"),
-   DT_CLK("cpu0", NULL, "dpll_mpu_ck"),
DT_CLK(NULL, "dpll_mpu_m2_ck", "dpll_mpu_m2_ck"),
DT_CLK(NULL, "dpll_ddr_ck", "dpll_ddr_ck"),
DT_CLK(NULL, "dpll_ddr_m2_ck", "dpll_ddr_m2_ck"),
-- 
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 2/2] ARM: dts: OMAP3+: add clock nodes for CPU

2014-01-29 Thread Nishanth Menon 
OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.

OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
dpll_mpu clock.

Latency used is the generic latency defined in omap-cpufreq
driver.

Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/am33xx.dtsi |4 
 arch/arm/boot/dts/am4372.dtsi |5 +
 arch/arm/boot/dts/dra7.dtsi   |5 +
 arch/arm/boot/dts/omap3.dtsi  |5 +
 arch/arm/boot/dts/omap4.dtsi  |5 +
 arch/arm/boot/dts/omap5.dtsi  |6 ++
 6 files changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..4bbba26 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -58,6 +58,10 @@
275000  1125000
>;
voltage-tolerance = <2>; /* 2 percentage */
+
+   clocks = <&dpll_mpu_ck>;
+   clock-names = "cpu";
+
clock-latency = <30>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c6bd4d9..33798d9 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -33,6 +33,11 @@
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
+
+   clocks = <&dpll_mpu_ck>;
+   clock-names = "cpu";
+
+   clock-latency = <30>; /* From omap-cpufreq driver */
};
};
 
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..ce591e5 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -47,6 +47,11 @@
100 106
1176000 116
>;
+
+   clocks = <&dpll_mpu_ck>;
+   clock-names = "cpu";
+
+   clock-latency = <30>; /* From omap-cpufreq driver */
};
cpu@1 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..01f2b3b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -35,6 +35,11 @@
compatible = "arm,cortex-a8";
device_type = "cpu";
reg = <0x0>;
+
+   clocks = <&dpll1_ck>;
+   clock-names = "cpu";
+
+   clock-latency = <30>; /* From omap-cpufreq driver */
};
};
 
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..ce87996 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,11 @@
device_type = "cpu";
next-level-cache = <&L2>;
reg = <0x0>;
+
+   clocks = <&dpll_mpu_ck>;
+   clock-names = "cpu";
+
+   clock-latency = <30>; /* From omap-cpufreq driver */
};
cpu@1 {
compatible = "arm,cortex-a9";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..8bb4134 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -49,6 +49,12 @@
100 106
150 125
>;
+
+   clocks = <&dpll_mpu_ck>;
+   clock-names = "cpu";
+
+   clock-latency = <30>; /* From omap-cpufreq driver */
+
/* cooling options */
cooling-min-level = <0>;
cooling-max-level = <2>;
-- 
1.7.9.5

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

[PATCH 0/2] ARM: dts/OMAP: add cpu clock nodes

2014-01-29 Thread Nishanth Menon 
Add clock nodes for all existing OMAP platforms where cpufreq-cpu0
can be used.

Sanity tested with linux next-20140128 tag, applies on
master 0e47c96 Merge tag 'for-linus-20140127' of 
git://git.infradead.org/linux-mtd

Ofcourse, I have send 7 different versions[1] previously, so I will start from
version 1 again considering that I have finally based on master.

If folks feel that the clock nodes must be split out into various platforms, I
can regenerate the series again.

Nishanth Menon (2):
  clk: ti: am335x: remove unecessary cpu0 clk node
  ARM: dts: OMAP3+: add clock nodes for CPU

 arch/arm/boot/dts/am33xx.dtsi |4 
 arch/arm/boot/dts/am4372.dtsi |5 +
 arch/arm/boot/dts/dra7.dtsi   |5 +
 arch/arm/boot/dts/omap3.dtsi  |5 +
 arch/arm/boot/dts/omap4.dtsi  |5 +
 arch/arm/boot/dts/omap5.dtsi  |6 ++
 drivers/clk/ti/clk-33xx.c |1 -
 7 files changed, 30 insertions(+), 1 deletion(-)

[1] Last version of the patch series was posted here:
http://marc.info/?l=linux-omap&m=138245695726479&w=2
-- 
1.7.9.5

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

[PATCH] ARM: dts: OMAP5: add pmu node

2014-01-29 Thread Nathan Lynch 
Expose the PMU on OMAP5.

Signed-off-by: Nathan Lynch 
---

Notes:
Briefly tested with perf on OMAP5 UEVM with next-20140124.

 arch/arm/boot/dts/omap5.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a9663e..fbf4661436e2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -76,6 +76,12 @@
 ;
};
 
+   pmu {
+   compatible = "arm,cortex-a15-pmu";
+   interrupts = <0 131 4>,
+<0 132 4>;
+   };
+
gic: interrupt-controller@48211000 {
compatible = "arm,cortex-a15-gic";
interrupt-controller;
-- 
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: [PATCH 0/6] N900 DTS additions for 3.14

2014-01-29 Thread Sebastian Reichel 
Hi Nishanth,

On Wed, Jan 29, 2014 at 09:04:46AM -0600, Nishanth Menon wrote:
> On 01/29/2014 09:03 AM, Sebastian Reichel wrote:
> > On Sat, Jan 11, 2014 at 10:16:57PM +0100, Sebastian Reichel wrote:
> >> Here are a couple of additions for the Nokia N900 Device Tree
> >> Source file. All related drivers changes are queued for 3.14
> >> (except for the tpa6130a2, which got merged into 3.13).
> >>
> >> I may have some more additions if the driver changes for the
> >> accelerometer, the touchscreen or the wireless lan chip will be
> >> queued up.
> > 
> > Ping. If I'm not mistaken the merge window will probably be closed
> > at the weekend (2014-01-19 + 2 weeks = 2014-02-02).
> > 
> > P.S.: Accelerometer, Touchscreen and WLAN driver changes haven't
> > made it into 3.14, so the patchset I mailed is complete.
> > 
> > -- Sebastian
> > 
> 
> It is usually suggested for dts patches to be cced with devicetree and
> linux-arm-kernel lists as well..

Well I CC'd them for the patches adding the binding documentation
and updating the drivers. I think its not so common for the dts
entries to reduce the workload of the DT binding maintainers?

Of course I can add them for future patchsets.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 0/6] N900 DTS additions for 3.14

2014-01-29 Thread Sebastian Reichel 
Hi,

On Sat, Jan 11, 2014 at 10:16:57PM +0100, Sebastian Reichel wrote:
>Here are a couple of additions for the Nokia N900 Device Tree
>Source file. All related drivers changes are queued for 3.14
>(except for the tpa6130a2, which got merged into 3.13).
>
>I may have some more additions if the driver changes for the
>accelerometer, the touchscreen or the wireless lan chip will be
>queued up.

Ping. If I'm not mistaken the merge window will probably be closed
at the weekend (2014-01-19 + 2 weeks = 2014-02-02).

P.S.: Accelerometer, Touchscreen and WLAN driver changes haven't
made it into 3.14, so the patchset I mailed is complete.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 0/6] N900 DTS additions for 3.14

2014-01-29 Thread Nishanth Menon 
On 01/29/2014 09:03 AM, Sebastian Reichel wrote:
> Hi,
> 
> On Sat, Jan 11, 2014 at 10:16:57PM +0100, Sebastian Reichel wrote:
>> Here are a couple of additions for the Nokia N900 Device Tree
>> Source file. All related drivers changes are queued for 3.14
>> (except for the tpa6130a2, which got merged into 3.13).
>>
>> I may have some more additions if the driver changes for the
>> accelerometer, the touchscreen or the wireless lan chip will be
>> queued up.
> 
> Ping. If I'm not mistaken the merge window will probably be closed
> at the weekend (2014-01-19 + 2 weeks = 2014-02-02).
> 
> P.S.: Accelerometer, Touchscreen and WLAN driver changes haven't
> made it into 3.14, so the patchset I mailed is complete.
> 
> -- Sebastian
> 

It is usually suggested for dts patches to be cced with devicetree and
linux-arm-kernel lists as well..

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

Re: OMAP: clock DT conversion issues with omap36xx

2014-01-29 Thread Tero Kristo 

On 01/29/2014 01:21 PM, Christoph Fritz wrote:

On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:

On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:



Due to a regression since next-20140122 the following errors are present:

   - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
 in this set, erroneously outputs only 12 Mhz.
 Just out of curiosity, configuring it to 48 Mhz puts out desired 24 Mhz.

   - omap_dss, which gets configured by the third patch in this set, fails
 to do 'dss_set_fck_rate(fck);' in
 drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads to:

  | omapdss_dss: probe of omapdss_dss failed with error -22
  | omapdss CORE error: Failed to initialize DSS platform driver
  | panel-dpi panel-dpi.0: failed to find video source 'dpi.0

Both regressions seem to have something to do with the clock framework.
Could this be related to the DT clock conversion patches?




Yea its definitely possible, as the clock DT conversion touches pretty
much everything. Have you tried whether this works properly with legacy
boot? Personally I don't have access to any omap3 devices that would
have display and have no possibility to check this out myself. Anyway,
my initial guess is that some clock divider setup might be wrong with
omap3, or we are missing some ti,set-rate-parent flag for some clock
node which prevents escalating clk_set_rate properly. However, it should
be easy to debug this by looking at the clock node in question, and its
parent nodes to see if there are any problems.


Currently I only analyzed sys_clkout2 (see attachments for full
clk_summary files):

clk_summary__next-20140115__works_as_expected:
  dpll4_m2_ck1   19600
 dpll4_m2x2_ck   1   19600
omap_192m_alwon_fck 1   19600
   omap_96m_alwon_fck 1   29600
  per_96m_fck 0   69600
 mcbsp4_fck 0   19600
 mcbsp3_fck 0   29600
 mcbsp2_fck 0   29600
  cm_96m_fck 2   39600
 clkout2_src_ck 1   19600
sys_clkout2 1   12400

For real, on pin sys_clkout2 are correctly 24 Mhz measured.

clk_summary__next-20140124__sysclkout2_dss_fails:
  dpll4_m2_ck1   19600
 dpll4_m2x2_mul_ck 1   119200
dpll4_m2x2_ck 1   119200
   omap_192m_alwon_fck 0   019200
   omap_96m_alwon_fck 1   219200
  per_96m_fck 0   619200
 mcbsp4_fck 0   119200
 mcbsp3_fck 0   219200
 mcbsp2_fck 0   219200
  cm_96m_fck 2   319200
 clkout2_src_ck 1   119200
sys_clkout2 1   12400

For real, on pin sys_clkout2 are only ~12 Mhz measured.

So I added this patch:

Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck

Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck.
So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1.
---
  arch/arm/boot/dts/omap3xxx-clocks.dtsi |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
index cb04d4b..b594050 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -212,7 +212,7 @@
#clock-cells = <0>;
compatible = "fixed-factor-clock";
clocks = <&dpll4_m2_ck>;
-   clock-mult = <2>;
+   clock-mult = <1>;
clock-div = <1>;
};

And it works again. But due to the fact that sys_clkout2 was at 12 Mhz
instead of 24, shouldn't it have been at 48 caused by "clock-mult = 2 ?


Any ideas on that?

I reverted the patch above and added:


Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding 
ti,min-div = <2>; and ti,max-div = <4>; to properties of the clock node.


-Tero



From: Tero Kristo 
Date: Wed, 29 Jan 2014 11:03:46 +0200
Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck

OMAP36xx has different hardware implementation for the omap96m_alwon_fck
compared to other OMAP3 variants. Reflect this

Re: [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO

2014-01-29 Thread Heikki Krogerus 
Hi,

On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote:
> On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote:
> > On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote:
> > For the controller drivers the PHYs are just a resource like any
> > other. The controller drivers can't have any responsibility of
> > them. They should not care if PHY drivers are available for them or
> > not, or even if the PHY framework is available or not.
> 
> huh? If memory isn't available you don't continue probing, right ? If
> your IORESOURCE_MEM is missing, you also don't continue probing, if your
> IRQ line is missing, you bail too. Those are also nothing but resources
> to the driver, what you're asking here is to treat PHY as a _different_
> resource; which might be fine, but we need to make sure we don't
> continue probing when a PHY is missing in a platform that certainly
> needs a PHY.

Yes, true. In my head I was comparing the PHY only to resources like
gpios, clocks, dma channels, etc. that are often optional to the
drivers.

> > > > > But I really want to see the argument against using no-op. As far as I
> > > > > could see, everybody needs a PHY driver one way or another, some
> > > > > platforms just haven't sent any PHY driver upstream and have their own
> > > > > hacked up solution to avoid using the PHY layer.
> > > > 
> > > > Not true in our case. Platforms using Intel's SoCs and chip sets may
> > > > or may not have controllable USB PHY. Quite often they don't. The
> > > > Baytrails have usually ULPI PHY for USB2, but that does not mean they
> > > > provide any vendor specific functions or any need for a driver in any
> > > > case.
> > > 
> > > that's different from what I heard.
> > 
> > I don't know where you got that impression, but it's not true. The
> > Baytrail SoCs for example don't have internal USB PHYs, which means
> > the manufacturers using it can select what they want. So we have
> > boards where PHY driver(s) is needed and boards where it isn't.
> 
> alright, that explains it ;-) So you have external USB2 and USB3 PHYs ?
> You have an external PIPE3 interface ? That's quite an achievement,
> kudos to your HW designers. Getting timing closure on PIPE3 is a
> difficult task.

No, only the USB2 PHY is external. I'm giving you wrong information,
I'm sorry about that. Need to concentrate on what I'm writing.



> > This is really good to get. We have some projects where we are dealing
> > with more embedded environments, like IVI, where the kernel should be
> > stripped of everything useless. Since the PHYs are autonomous, we
> > should be able to disable the PHY libraries/frameworks.
> 
> hmmm, in that case it's a lot easier to treat. We can use
> ERR_PTR(-ENXIO) as an indication that the framework is disabled, or
> something like that.
> 
> The difficult is really reliably supporting e.g. OMAP5 (which won't work
> without a PHY) and your BayTrail with autonomous PHYs. What can we use
> as an indication ?

OMAP has it's own glue driver, so shouldn't it depend on the PHY
layer?

> I mean, I need to know that a particular platform depends on a PHY
> driver before I decide to return -EPROBE_DEFER or just assume the PHY
> isn't needed ;-)

I don't think dwc3 (core) should care about that. The PHY layer needs
to tell us that. If the PHY driver that the platform depends is not
available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up
returning -EPROBE_DEFER.



> > I think our goals are the same. I just want to also minimize the need
> > for any platform specific extra work from the upper layers regarding
> > the PHYs.
> 
> I'll agree to that, but let's not apply patches until we're 100% sure
> there will be no regressions. Looking at $subject, I don't think it
> satisfies that condition ;-)

Agreed. Let's think this through carefully.


Cheers,

-- 
heikki
--
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 basic devices for AM3517-craneboard

2014-01-29 Thread Nishanth Menon 
On 01/20/2014 10:43 AM, Nishanth Menon wrote:
> Benoit,
> 
> On 12/18/2013 11:16 AM, Benoit Cousson wrote:
>> On 18/12/2013 18:02, Nishanth Menon wrote:
>>> On 12/18/2013 10:57 AM, Benoit Cousson wrote:
 On 17/12/2013 20:45, Nishanth Menon wrote:
> On 12/09/2013 03:55 PM, Nishanth Menon wrote:
>> Craneboard is a hardware development platform based on the Sitara
>> AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
>> details. Add basic devices for craneboard as replacement for the board
>> file scheduled for removal as part of device tree conversion
>>
>> [1] http://craneboard.org
>>
>> Signed-off-by: Nishanth Menon 
>> ---
>
> gentle ping.. had'nt seen a response on this patch. Could we queue
> this up for v3.14-rc1?

 Yep, it looks good to me.
>>> Thanks benoit.
>>>
 But if you don't mind I'll start pushing my branch after Xmas :-).
>>>
>>> As long as Tony is ok with it, I have no issues either - will be great
>>> to have dt only boot in .14-rc1 though.
>>
>> Good point, it is already -rc4.
>>
>> OK, I'll just queued it and pushed it to for_3.14/dts.
> 
> I dont see this in next-20140120 yet - wondering if Tony or you have
> plans for one of .14 rcs OR if this is queued for .15.

gentle ping yet again :(


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

Re: [PATCH] ARM: OMAP2+: add missing ARCH_HAS_OPP

2014-01-29 Thread Nishanth Menon 
Hi Tony,
On 01/15/2014 02:00 PM, Nishanth Menon wrote:
> OMAP5, DRA7, AM43xx all have OPPs. So select the same to allow SoC
> only configuration boot to work with OPP.
> 
> Reported-by: Nikhil Devshatwar 
> Signed-off-by: Nishanth Menon 
> ---
> 
> For DRA7, depends on: https://patchwork.kernel.org/patch/3465411/

Considering that dependent patch is now on linus master,
a gentle ping -> The patch does apply on latest linus master commit
0e47c969c65e213421450c31043353ebe3c67e0c

patchworks reference: https://patchwork.kernel.org/patch/3493581/

> 
>  arch/arm/mach-omap2/Kconfig |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 35c23e5..66a9c4a 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -50,6 +50,7 @@ config SOC_OMAP5
>   bool "TI OMAP5"
>   depends on ARCH_MULTI_V7
>   select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
>   select ARM_CPU_SUSPEND if PM
>   select ARM_GIC
>   select CPU_V7
> @@ -63,6 +64,7 @@ config SOC_AM33XX
>   bool "TI AM33XX"
>   depends on ARCH_MULTI_V7
>   select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
>   select ARM_CPU_SUSPEND if PM
>   select CPU_V7
>   select MULTI_IRQ_HANDLER
> @@ -72,6 +74,7 @@ config SOC_AM43XX
>   depends on ARCH_MULTI_V7
>   select CPU_V7
>   select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
>   select MULTI_IRQ_HANDLER
>   select ARM_GIC
>   select MACH_OMAP_GENERIC
> @@ -80,6 +83,7 @@ config SOC_DRA7XX
>   bool "TI DRA7XX"
>   depends on ARCH_MULTI_V7
>   select ARCH_OMAP2PLUS
> + select ARCH_HAS_OPP
>   select ARM_CPU_SUSPEND if PM
>   select ARM_GIC
>   select CPU_V7
> 


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

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Tomi Valkeinen 
On 2014-01-28 20:17, Ivaylo Dimitrov wrote:
> 
> 
> On 28.01.2014 10:48, Tomi Valkeinen wrote:
> 
>> I made a somewhat hacky quickfix for beagle. Applying that and the
>> clk-divider from the link above makes things work for me. However, as I
>> said, the issue with n900 might be different, but it'd be interesting to
>> hear if it has any effect.
>>
>>   Tomi
>>
> 
> Applying those 2 patches doesn't help, still get exactly the same warning.
> 
> Find attached my clk_summary (with my hacky patch applied, otherwise I
> cannot boot the device)

Can you try this one:

From e511789f7be00be0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Wed, 29 Jan 2014 13:28:53 +0200
Subject: [PATCH] clkoutx2 fix

---
 arch/arm/mach-omap2/cclock3xxx_data.c |  7 +++
 arch/arm/mach-omap2/dpll3xxx.c| 20 
 2 files changed, 27 insertions(+)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea56d1f..49247701a56c 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -428,12 +428,19 @@ static const char *dpll4_m5x2_ck_parent_names[] = {
"dpll4_m5_ck",
 };
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate);
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long target_rate,
+   unsigned long *parent_rate);
+
 static const struct clk_ops dpll4_m5x2_ck_ops = {
.init   = &omap2_init_clk_clkdm,
.enable = &omap2_dflt_clk_enable,
.disable= &omap2_dflt_clk_disable,
.is_enabled = &omap2_dflt_clk_is_enabled,
+   .set_rate   = &omap3_clkoutx2_set_rate,
.recalc_rate= &omap3_clkoutx2_recalc,
+   .round_rate = &omap3_clkoutx2_round_rate,
 };
 
 static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3a0296cfcace..794665fe234b 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -669,6 +669,26 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
return rate;
 }
 
+int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   return 0;
+}
+
+long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *prate)
+{
+   if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+   unsigned long best_parent;
+
+   best_parent = (rate / 2);
+   *prate = __clk_round_rate(__clk_get_parent(hw->clk),
+   best_parent);
+   }
+
+   return *prate * 2;
+}
+
 /* OMAP3/4 non-CORE DPLL clkops */
 const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
.allow_idle = omap3_dpll_allow_idle,
-- 
1.8.3.2





signature.asc
Description: OpenPGP digital signature

OMAP: clock DT conversion issues with omap36xx

2014-01-29 Thread Christoph Fritz 
On Tue, 2014-01-28 at 18:02 +0100, Christoph Fritz wrote:
> On Tue, 2014-01-28 at 15:40 +0200, Tero Kristo wrote:
> > 
> > >> Due to a regression since next-20140122 the following errors are present:
> > >>
> > >>   - pin sys_clkout2, which gets configured to 24 Mhz by the fourth patch
> > >> in this set, erroneously outputs only 12 Mhz.
> > >> Just out of curiosity, configuring it to 48 Mhz puts out desired 24 
> > >> Mhz.
> > >>
> > >>   - omap_dss, which gets configured by the third patch in this set, fails
> > >> to do 'dss_set_fck_rate(fck);' in
> > >> drivers/video/omap2/dss/dss.c:dss_setup_default_clock() which leads 
> > >> to:
> > >>
> > >>  | omapdss_dss: probe of omapdss_dss failed with error -22
> > >>  | omapdss CORE error: Failed to initialize DSS platform driver
> > >>  | panel-dpi panel-dpi.0: failed to find video source 'dpi.0
> > >>
> > >>Both regressions seem to have something to do with the clock 
> > >> framework.
> > >>Could this be related to the DT clock conversion patches?
> > >
> > 
> > Yea its definitely possible, as the clock DT conversion touches pretty 
> > much everything. Have you tried whether this works properly with legacy 
> > boot? Personally I don't have access to any omap3 devices that would 
> > have display and have no possibility to check this out myself. Anyway, 
> > my initial guess is that some clock divider setup might be wrong with 
> > omap3, or we are missing some ti,set-rate-parent flag for some clock 
> > node which prevents escalating clk_set_rate properly. However, it should 
> > be easy to debug this by looking at the clock node in question, and its 
> > parent nodes to see if there are any problems.
> 
> Currently I only analyzed sys_clkout2 (see attachments for full
> clk_summary files):
> 
> clk_summary__next-20140115__works_as_expected:
>  dpll4_m2_ck1   19600
> dpll4_m2x2_ck   1   19600
>omap_192m_alwon_fck 1   19600
>   omap_96m_alwon_fck 1   29600
>  per_96m_fck 0   69600
> mcbsp4_fck 0   19600
> mcbsp3_fck 0   29600
> mcbsp2_fck 0   29600
>  cm_96m_fck 2   39600
> clkout2_src_ck 1   19600
>sys_clkout2 1   12400
> 
> For real, on pin sys_clkout2 are correctly 24 Mhz measured.
> 
> clk_summary__next-20140124__sysclkout2_dss_fails:
>  dpll4_m2_ck1   19600
> dpll4_m2x2_mul_ck 1   119200
>dpll4_m2x2_ck 1   119200
>   omap_192m_alwon_fck 0   019200
>   omap_96m_alwon_fck 1   219200
>  per_96m_fck 0   619200
> mcbsp4_fck 0   119200
> mcbsp3_fck 0   219200
> mcbsp2_fck 0   219200
>  cm_96m_fck 2   319200
> clkout2_src_ck 1   119200
>sys_clkout2 1   12400
> 
> For real, on pin sys_clkout2 are only ~12 Mhz measured.
> 
> So I added this patch:
> 
> Subject: [PATCH] ARM: dts: fix omap3 clock multiplier for dpll4_m2x2_ck
> 
> Before DT clock conversion, there was no multiplier for dpll4_m2x2_ck.
> So to be compatible again, set dpll4_m2x2_mul_ck multiplier back to 1.
> ---
>  arch/arm/boot/dts/omap3xxx-clocks.dtsi |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi 
> b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> index cb04d4b..b594050 100644
> --- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
> @@ -212,7 +212,7 @@
>   #clock-cells = <0>;
>   compatible = "fixed-factor-clock";
>   clocks = <&dpll4_m2_ck>;
> - clock-mult = <2>;
> + clock-mult = <1>;
>   clock-div = <1>;
>   };
>
> And it works again. But due to the fact that sys_clkout2 was at 12 Mhz
> instead of 24, shouldn't it have been at 48 caused by "clock-mult = 2 ?

Any ideas on that?

I reverted the patch above and added:

From: Tero Kristo 
Date: Wed, 29 Jan 2014 11:03:46 +0200
Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck

OMAP36xx has different hardware implementation for the omap96m_al

Re: [PATCH 2/4] power_supply: Introduce Generic Power Supply charging driver

2014-01-29 Thread Jenny Tc 
On Sat, Jan 25, 2014 at 10:04:03AM -0700, Pavel Machek wrote:
> > +   * Write access using set_property
> > +   * Set Maximum charging current
> > +   * Action: Configure safety charging registers if any. If not no
> > + actions expected for this.
> 
> Having property that does nothing sounds evil to me.

No h/w actions expected. But driver action expected. Will fix in next patch set

> > +* POWER_SUPPLY_CHARGER_PROP_ENABLE_CHARGING
> > +   * Write access using set_property
> > +   * Enable/Disable charging. Charger supplies power to platform,
> > + but charging is disabled
> 
> This is unclear. Charging is always disabled?

Writing 0, disables charger. Writing 1 enables charging. 

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

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Tero Kristo 

On 01/29/2014 11:38 AM, Tomi Valkeinen wrote:

On 2014-01-29 11:29, Ivaylo Dimitrov wrote:



On 29.01.2014 11:10, Tero Kristo wrote:



It looks like the omap36xx version of the omap96m_alwon_fck is modelled
improperly in the dts files. I don't have access to omap36xx hardware
myself, but give a try for the following patch:




It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I
am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess
that patch won't help much (unless I am missing something and DT is used
even with legacy boot and 36xx clocks are used on 3430es2)


I think Tero's reply was to Christoph. I believe the issues you see and
what Christoph sees are totally different.

  Tomi


Oh yea sorry about the confusion, have too many separate issues listed 
under this thread. :P That was definitely for Christoph.


For the DSS clk rate part, Tomi should answer that as it seems to come 
from some display driver changes. This might be caused by the infamous 
rounding issues with the clk_set_rate / clk_round_rate and the hackery 
around it in display driver...


-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: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Tomi Valkeinen 
On 2014-01-29 11:29, Ivaylo Dimitrov wrote:
> 
> 
> On 29.01.2014 11:10, Tero Kristo wrote:
> 
>>
>> It looks like the omap36xx version of the omap96m_alwon_fck is modelled
>> improperly in the dts files. I don't have access to omap36xx hardware
>> myself, but give a try for the following patch:
>>
>>
> 
> It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I
> am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess
> that patch won't help much (unless I am missing something and DT is used
> even with legacy boot and 36xx clocks are used on 3430es2)

I think Tero's reply was to Christoph. I believe the issues you see and
what Christoph sees are totally different.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/4] power_supply: bq24261 charger driver

2014-01-29 Thread Pavel Machek 
On Wed 2014-01-29 18:53:34, Jenny Tc wrote:
> On Tue, Jan 28, 2014 at 07:14:45AM -0700, Pavel Machek wrote:
> > > +#define BQ24261_ICHRG_MASK   (0x1F << 3)
> > > +#define BQ24261_ICHRG_100ma  (0x01 << 3)
> > > +#define BQ24261_ICHRG_200ma  (0x01 << 4)
> > > +#define BQ24261_ICHRG_400ma  (0x01 << 5)
> > > +#define BQ24261_ICHRG_800ma  (0x01 << 6)
> > > +#define BQ24261_ICHRG_1600ma (0x01 << 7)
> > 
> > First, its mA, not ma.
> 
> Camel Case allowed? Ignore Checkpatch.pl warning?

This is not camel case, this is mili ampers. 

> > (x/50) << 3, right ?
> 
> Few register settings need table mapping, but some can have logic as your
> comment say. Just wanted to keep same logic for all register settings.
> Doesn't it make more readable?

No, it is definitely not readable. Please use logic where you can.

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

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Ivaylo Dimitrov 



On 29.01.2014 11:10, Tero Kristo wrote:



It looks like the omap36xx version of the omap96m_alwon_fck is modelled
improperly in the dts files. I don't have access to omap36xx hardware
myself, but give a try for the following patch:




It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I 
am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess 
that patch won't help much (unless I am missing something and DT is used 
even with legacy boot and 36xx clocks are used on 3430es2)


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

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Tero Kristo 

On 01/28/2014 08:17 PM, Ivaylo Dimitrov wrote:



On 28.01.2014 10:48, Tomi Valkeinen wrote:


I made a somewhat hacky quickfix for beagle. Applying that and the
clk-divider from the link above makes things work for me. However, as I
said, the issue with n900 might be different, but it'd be interesting to
hear if it has any effect.

  Tomi



Applying those 2 patches doesn't help, still get exactly the same warning.

Find attached my clk_summary (with my hacky patch applied, otherwise I
cannot boot the device)

Ivo


It looks like the omap36xx version of the omap96m_alwon_fck is modelled 
improperly in the dts files. I don't have access to omap36xx hardware 
myself, but give a try for the following patch:



From: Tero Kristo 
Date: Wed, 29 Jan 2014 11:03:46 +0200
Subject: [PATCH] ARM: dts: omap36xx: fix omap96m_alwon_fck

OMAP36xx has different hardware implementation for the omap96m_alwon_fck
compared to other OMAP3 variants. Reflect this properly in the dts file.

Signed-off-by: Tero Kristo 
---
 arch/arm/boot/dts/omap36xx-clocks.dtsi |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap36xx-clocks.dtsi 
b/arch/arm/boot/dts/omap36xx-clocks.dtsi

index 2fcf253..24ddf3f 100644
--- a/arch/arm/boot/dts/omap36xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-clocks.dtsi
@@ -88,3 +88,12 @@
 <&mcbsp4_ick>, <&uart4_fck>;
};
 };
+
+&omap_96m_alwon_fck {
+   compatible = "ti,divider-clock";
+   clocks = <&omap_192m_alwon_fck>;
+   ti,bit-shift = <12>;
+   ti,max-div = <2>;
+   reg = <0x0a40>;
+   ti,index-starts-at-one;
+};
--
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