Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 17:41 schrieb Tony Lindgren <t...@atomide.com>:

> Hi,
> 
> * H. Nikolaus Schaller <h...@goldelico.com> [160106 00:12]:
>> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <t...@atomide.com>:
>>> 
>>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
>>> on omap5-uevm. It's working on x15 though.
>>> 
>>> Nikolaus, is hwclock command working for you on omap5-uevm?
>> 
>> Well, yes and no. It appears it *was* working when tested last time
>> (we sometimes have months of delay for submitting patches upstream).
>> 
>> I have found an SD image with 4.3-rc6 with this patch in the dtb and
>> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
>> 10 seconds (I guess some timeout).
>> 
>> I have checked the dtb and in both cases it is interrupts = <8 0>;
>> 
>> xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
>> 000:  0008  
>> 
>> So I think something has changed in the rtc driver or somewhere else.
> 
> I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
> RTC, and I still don't have hwclock working with RTC.
> 
> It seems you have some additional patches there that make it work?

Hm. Not that I am aware of. We just did add the rtc nodes but did not
touch palmas drivers (except adding the gpadc of this patch series).

> 
> I guess it could also be a bootloader change if it's a different
> SD image that works for you.

Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
source. I will try to find out if it makes a difference.

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 02:00 schrieb Tony Lindgren <t...@atomide.com>:

> * Nishanth Menon <n...@ti.com> [160105 15:40]:
>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>> tested on OMP5432 EVM
>>> 
>>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>>> ---
>>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>>> 1 file changed, 8 insertions(+)
>>> 
>>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
>>> b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> index 5cf76a1..30c0d3b 100644
>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> @@ -358,6 +358,14 @@
>>> #clock-cells = <0>;
>>> };
>>> 
>>> +   rtc {
>>> +   compatible = "ti,palmas-rtc";
>>> +   interrupt-parent = <>;
>>> +   interrupts = <8 IRQ_TYPE_NONE>;
>> 
>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>> it had none, there'd be no interrupt, right?
> 
> Also I'm not seeing just zeroes coming from RTC after typing hwclock
> on omap5-uevm. It's working on x15 though.
> 
> Nikolaus, is hwclock command working for you on omap5-uevm?

Well, yes and no. It appears it *was* working when tested last time
(we sometimes have months of delay for submitting patches upstream).

I have found an SD image with 4.3-rc6 with this patch in the dtb and
there it works. With 4.4-rc8 it does not work. hwclock command hangs for
10 seconds (I guess some timeout).

I have checked the dtb and in both cases it is interrupts = <8 0>;

xxd /sys/firmware/devicetree/base/ocp/i2c@4807/palmas@48/rtc/interrupts
000:  0008  

So I think something has changed in the rtc driver or somewhere else.

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon <n...@ti.com>:

> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>> tested on OMP5432 EVM
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 
>> 1 file changed, 8 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
>> b/arch/arm/boot/dts/omap5-board-common.dtsi
>> index 5cf76a1..30c0d3b 100644
>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>> @@ -358,6 +358,14 @@
>>  #clock-cells = <0>;
>>  };
>> 
>> +rtc {
>> +compatible = "ti,palmas-rtc";
>> +interrupt-parent = <>;
>> +interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Well, it just translates IRQ_TYPE_NONE through

Linux/include/dt-bindings/interrupt-controller/irq.h

to 

interrupts = <8 0>;

which is given as an example in

Documentation//devicetree/bindings/rtc/rtc-palmas.txt

Since I don't know anything about the rtc driver beyond the bindings 
documentation I assume it is correct...
I have added Laxman Dewangan because he introduced this interrupts = <8 0>;

> 
>> +ti,backup-battery-chargeable;
>> +ti,backup-battery-charge-high-current;
>> +};
>> +
>>  palmas_pmic {
>>  compatible = "ti,palmas-pmic";
>>  interrupt-parent = <>;
>> 
> 
> 
> -- 
> Regards,
> Nishanth Menon


BR,
Nikolaus

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

[PATCH 3/3] ARM: dts: twl6030: add gpadc

[H. Nikolaus Schaller]

tested on Pandaboard ES.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 55eb35f..98e444d 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -99,4 +99,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+   adc {
+   compatible = "ti,twl6030-gpadc";
+   interrupts = <3>;
+   #io-channel-cells = <1>;
+   };
 };
-- 
2.5.1

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

[PATCH 0/3] Enable twl603x-GPADC for some OMAP4/OMAP5 boards and Palmas-RTC for OMAP5

[H. Nikolaus Schaller]

This patch series adds DT nodes for:

twl6030-gpadc for omap4 based boards (Pandaboard ES)
twl6037-gpadc for omap5 based boards (OMAP5 EVM)
twl6037-rtc for omap5 based boards (OMAP5 EVM)


H. Nikolaus Schaller (3):
  ARM: dts: omap5-board-common: enable rtc and charging of backup
battery
  ARM: dts: omap5-board-common: enable iio gpadc for Palmas
  ARM: dts: twl6030: add gpadc

 arch/arm/boot/dts/omap5-board-common.dtsi | 18 ++
 arch/arm/boot/dts/twl6030.dtsi|  6 ++
 2 files changed, 24 insertions(+)

-- 
2.5.1

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

[PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

tested on OMP5432 EVM

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap5-board-common.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
b/arch/arm/boot/dts/omap5-board-common.dtsi
index 5cf76a1..30c0d3b 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -358,6 +358,14 @@
#clock-cells = <0>;
};
 
+   rtc {
+   compatible = "ti,palmas-rtc";
+   interrupt-parent = <>;
+   interrupts = <8 IRQ_TYPE_NONE>;
+   ti,backup-battery-chargeable;
+   ti,backup-battery-charge-high-current;
+   };
+
palmas_pmic {
compatible = "ti,palmas-pmic";
interrupt-parent = <>;
-- 
2.5.1

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

[PATCH 2/3] ARM: dts: omap5-board-common: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

tested on OMP5432 EVM

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi 
b/arch/arm/boot/dts/omap5-board-common.dtsi
index 30c0d3b..56429ce 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -366,6 +366,16 @@
ti,backup-battery-charge-high-current;
};
 
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   #io-channel-cells = <1>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+
palmas_pmic {
compatible = "ti,palmas-pmic";
interrupt-parent = <>;
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

HI,

Am 16.11.2015 um 15:37 schrieb Grazvydas Ignotas <nota...@gmail.com>:

> Hi,
> 
> On Fri, Nov 13, 2015 at 10:35 PM, H. Nikolaus Schaller
> <h...@goldelico.com> wrote:
>> The standard touch screen bindings [1] replace the private ti,swap-xy
>> with touchscreen-swaped-x-y. And for the Openpandora we use
>> touchscreen-size etc. to match the LCD screen size.
>> 
>> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
>> arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
>> arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  2 +-
>> 3 files changed, 15 insertions(+), 6 deletions(-)
>> 
>> diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
>> b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
>> index d0dd036..01dae66 100644
>> --- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
>> +++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
>> @@ -325,7 +325,7 @@
>>ti,y-max = /bits/ 16 <3600>;
>>ti,x-plate-ohms = /bits/ 16 <80>;
>>ti,pressure-max = /bits/ 16 <255>;
>> -   ti,swap-xy;
>> +   touchscreen-swapped-x-y;
>> 
>>linux,wakeup;
>>};
>> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
>> b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> index f672a04..9497cc6 100644
>> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> @@ -696,10 +696,19 @@
>>pendown-gpio = < 30 0>;
>>vcc-supply = <>;
>> 
>> -   ti,x-min = /bits/ 16 <0>;
>> -   ti,x-max = /bits/ 16 <8000>;
>> -   ti,y-min = /bits/ 16 <0>;
>> -   ti,y-max = /bits/ 16 <4800>;
>> +   touchscreen-size-x = <800>;
>> +   touchscreen-size-y = <480>;
>> +   touchscreen-max-pressure = <1000>;
>> +   touchscreen-fuzz-x = <16>;
>> +   touchscreen-fuzz-y = <16>;
>> +   touchscreen-fuzz-pressure = <10>;
>> +   touchscreen-inverted-x;
>> +   touchscreen-inverted-y;
>> +
>> +   ti,x-min = /bits/ 16 <160>;
>> +   ti,x-max = /bits/ 16 <3900>;
>> +   ti,y-min = /bits/ 16 <220>;
>> +   ti,y-max = /bits/ 16 <3750>;
> 
> I'm not sure this is a good idea, there have been at least 3 different
> batches of LCDs which slightly different touchscreens attached, with
> such thresholds we might end up with unreachable touchscreen points on
> some units. If I understand right, calibration won't help if for some
> screen locations ADC reading goes below/above these min/max thresholds
> on some specific units? If so there should probably be at least 10%
> margin in either case to make calibration useful.

Ok, then someone owning all variants should test and we should use the
min/max values we find. I.e. the touch with the biggest ADC value range.
All others have smaller screens which can be calibrated in user space.
But 10% is good enough to boot and start manual calibration.

Alternatively, we can set them to 0 and 4095 (or remove them to use defaults).

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 6/8] drivers:input:ads7846(+tsc2046): recognise old binding for coordinate flipping

[H. Nikolaus Schaller]

Am 15.11.2015 um 03:19 schrieb Rob Herring <robh...@kernel.org>:

> On Fri, Nov 13, 2015 at 2:35 PM, H. Nikolaus Schaller <h...@goldelico.com> 
> wrote:
>> By this patch we still recognise the old binding ti,swap-xy in parallel to
>> the common binding touchscreen-swapped-x-y. This keeps compatibility
>> to older (out-of-tree) device tree binaries.
>> 
>> We do this in a separate patch so that it can be easily reverted in the
>> future to retire the old API. A notice is printed to remind developers
>> of using old API.
>> 
>> We also fix the bindings name for all in-tree device tree sources in
>> a separate patch.
> 
> This one and patch 5 should be combined, so the series is bisectable.

Ok. We will loose the easy "revert single patch" option, but you are right that 
it is simpler if combined.
I will add a comment to source code that ti,swap-xy is deprecated and should be 
removed in the future.

> 
> Rob
> 
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> drivers/input/touchscreen/ads7846.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/input/touchscreen/ads7846.c 
>> b/drivers/input/touchscreen/ads7846.c
>> index 4525f00..b9896fd 100644
>> --- a/drivers/input/touchscreen/ads7846.c
>> +++ b/drivers/input/touchscreen/ads7846.c
>> @@ -1259,7 +1259,11 @@ static const struct ads7846_platform_data 
>> *ads7846_probe_dt(struct device *dev)
>>of_property_read_u16(node, "ti,vref-mv", >vref_mv);
>>pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
>> 
>> -   pdata->swap_xy = of_property_read_bool(node, 
>> "touchscreen-swapped-x-y");
>> +   pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
>> +   if (pdata->swap_xy)
>> +   dev_notice(dev, "please update device tree to use 
>> touchscreen-swapped-x-y");
>> +   pdata->swap_xy |= of_property_read_bool(node,
>> +   "touchscreen-swapped-x-y");
>> 
>>of_property_read_u16(node, "ti,settle-delay-usec",
>> >settle_delay_usecs);
>> --
>> 2.5.1
>> 

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

Re: [PATCH v2 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Am 15.11.2015 um 03:14 schrieb Rob Herring <r...@kernel.org>:

> On Fri, Nov 13, 2015 at 09:35:52PM +0100, H. Nikolaus Schaller wrote:
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>> introduced common DT bindings for touchscreens [1] and a helper function to
>> parse the DT.
>> 
>> This has been integrated and interpretation of the inversion (flipping)
>> properties for the x and y axis has been added to accommodate any
>> orientation of the touch in relation to the LCD.
>> 
>> By scaling the min/max ADC values to the screen size it is now possible to
>> pre-calibrate the touch so that is (almost) exactly matches the LCD it is
>> glued onto. This allows to well enough operate the touch before a user
>> space calibration can improve the precision.
>> 
>> calculate_pressure has been renamed to calculate_resistance because
>> that is what it is doing.
>> 
>> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> This still looks like it will break with old dtbs. It doesn't matter if 
> you update the in tree dts files, you should not force users to update 
> their dtb.

I have studied the situation a little more and there is also a real bug 
involved.

The unpatched tsc2007 driver reports "touch resistance" as "pressure" to the 
input
layer by default.

I.e. if you touch, you will get the pressure value jump from 0 to a maximum 
value
and the more you press, the value goes down. This is opposite of what the 
tsc2046
driver reports (and most user-space code would assume).

Our patch fixes that as a side-effect (we forgot to mention it explicitly) 
unless
you explicitly specify "ti,report-resistance" which restores the old behaviour.

Basically this property should not be needed in normal operation.

So if we do it the way we do, old dtbs still work but no longer report 
"resistance"
but "pressure".

And only if the user space gets problems with that (most code I know just 
decides
between 0 and >0), the dts can be augmented by "ti,report-resistance" and 
recompiled
to report the resistance value. Maybe, this could even be achieved by a dt 
overlay if
the dts is not available for modifications.

The other properties (all min/max values) have the same defaults as without
this patch set (0 / 4095). Old dtbs should therefore work unchanged. And in the
worst case may need recalibration in user-space.

This is the way we were thinking when designing this patch.

So I think we should just better describe this bug fix and how to restore the 
old behaviour.

BR and thanks,
Nikolaus


> 
> Rob
> 
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> .../bindings/input/touchscreen/tsc2007.txt |  20 +--
>> drivers/input/touchscreen/tsc2007.c| 135 
>> +
>> include/linux/i2c/tsc2007.h|   8 ++
>> 3 files changed, 135 insertions(+), 28 deletions(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
>> b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
>> index ec365e1..6e9fd55 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
>> @@ -6,6 +6,7 @@ Required properties:
>> - ti,x-plate-ohms: X-plate resistance in ohms.
>> 
>> Optional properties:
>> +- generic touch screen properties: see touchscreen binding [2].
>> - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
>>   The penirq pin goes to low when the panel is touched.
>>   (see GPIO binding[1] for more details).
>> @@ -13,17 +14,20 @@ Optional properties:
>>   (see interrupt binding[0]).
>> - interrupts: (gpio) interrupt to which the chip is connected
>>   (see interrupt binding[0]).
>> -- ti,max-rt: maximum pressure.
>> -- ti,fuzzx: specifies the absolute input fuzz x value.
>> -  If set, it will permit noise in the data up to +- the value given to the 
>> fuzz
>> -  parameter, that is used to filter noise from the event stream.
>> -- ti,fuzzy: specifies the absolute input fuzz y value.
>> -- ti,fuzzz: specifies the absolute input fuzz z value.
>> +- ti,max-rt: maximum pressure resistance above which samples are ignored
>> +  (default: 4095).
>> +- ti,report-resistance: report resistance (no pressure = max_rt) instead
>> +  of pressure (no pressure = 0).
>> +- ti,min-x: minimum value reported by X axis ADC (default 0).
>> +- ti,max-x: maximum value reported by X axis ADC (default 4095).
>> +- ti,min-y: minimum valu

[PATCH v2 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

this should reduce unnecessary input events.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/tsc2007.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index e0c7173..1a8a79d 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
 
wait_queue_head_t   wait;
boolstopped;
+   boolpendown;
 
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -251,7 +252,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
dev_dbg(>client->dev,
"shaped point(%4d,%4d), pressure 
(%4u)\n",
tc.x, tc.y, rt);
-   input_report_key(input, BTN_TOUCH, 1);
+   if (!ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 1);
+   ts->pendown = true;
+   }
input_report_abs(input, ABS_X, tc.x);
input_report_abs(input, ABS_Y, tc.y);
input_report_abs(input, ABS_PRESSURE, rt);
@@ -272,9 +276,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
dev_dbg(>client->dev, "UP\n");
 
-   input_report_key(input, BTN_TOUCH, 0);
-   input_report_abs(input, ABS_PRESSURE, 0);
-   input_sync(input);
+   if (ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 0);
+   input_report_abs(input, ABS_PRESSURE, 0);
+   input_sync(input);
+
+   ts->pendown = false;
+   }
 
if (ts->clear_penirq)
ts->clear_penirq();
-- 
2.5.1

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

[PATCH v2 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  2 +-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index d0dd036..01dae66 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
ti,y-max = /bits/ 16 <3600>;
ti,x-plate-ohms = /bits/ 16 <80>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
 
linux,wakeup;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index f672a04..9497cc6 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -696,10 +696,19 @@
pendown-gpio = < 30 0>;
vcc-supply = <>;
 
-   ti,x-min = /bits/ 16 <0>;
-   ti,x-max = /bits/ 16 <8000>;
-   ti,y-min = /bits/ 16 <0>;
-   ti,y-max = /bits/ 16 <4800>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <16>;
+   touchscreen-fuzz-y = <16>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+
+   ti,x-min = /bits/ 16 <160>;
+   ti,x-max = /bits/ 16 <3900>;
+   ti,y-min = /bits/ 16 <220>;
+   ti,y-max = /bits/ 16 <3750>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index f4b1a61..c772b76 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -65,7 +65,7 @@
ti,y-max = /bits/ 16 <4800>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
linux,wakeup;
};
 };
-- 
2.5.1

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

[PATCH v2 4/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

Tested on: GTA04A4 (Letux2804), Letux3704, Letux7004

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 7166d88..95fed8e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -357,10 +357,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+   touchscreen-size-x = <480>;
+   touchscreen-size-y = <640>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <2>;
+   touchscreen-fuzz-y = <2>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-y;
+   ti,min-x = <0x100>;
+   ti,max-x = <0xf00>;
+   ti,min-y = <0x100>;
+   ti,max-y = <0xf00>;
+   ti,max-rt = <4096>;
+   ti,x-plate-ohms = <550>;
};
 };
 
-- 
2.5.1

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

[PATCH v2 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/ads7846.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index b9896fd..6bedbfa 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1563,6 +1563,17 @@ static int ads7846_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+   { "tsc2046", 0 },
+   { "ads7843", 0 },
+   { "ads7845", 0 },
+   { "ads7846", 0 },
+   { "ads7873", 0 },
+   { }
+};
+
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
.driver = {
.name   = "ads7846",
-- 
2.5.1

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

[PATCH v2 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

This has been integrated and interpretation of the inversion (flipping)
properties for the x and y axis has been added to accommodate any
orientation of the touch in relation to the LCD.

By scaling the min/max ADC values to the screen size it is now possible to
pre-calibrate the touch so that is (almost) exactly matches the LCD it is
glued onto. This allows to well enough operate the touch before a user
space calibration can improve the precision.

calculate_pressure has been renamed to calculate_resistance because
that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 .../bindings/input/touchscreen/tsc2007.txt |  20 +--
 drivers/input/touchscreen/tsc2007.c| 135 +
 include/linux/i2c/tsc2007.h|   8 ++
 3 files changed, 135 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again 
the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 0 0>;
ti,x-plate-ohms = <180>;
+   touchscreen-size-x = <640>;
+   touchscreen-size-y = <480>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..e0c7173 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
u16 model;
u16 x_plate_ohms;
+   boolswap_xy;
+   boolinvert_x;
+   boolinvert_y;
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   u16 max_x;
+   u16 max_y;
u16 max_rt;
unsigned long   poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct 
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+   struct ts_event *tc)
 {
u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
 
+   dev_dbg(>client->dev, "sof

[PATCH v2 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property 
(suggested by Rob Herring)

2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by commit b98abe52fa8e:

Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y 
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
  drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
  drivers:input:tsc2007: add iio interface to read external ADC input,
temperature and raw conversion values
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
  drivers:input:ads7846(+tsc2046): recognise old binding for coordinate
flipping
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings

 .../devicetree/bindings/input/ads7846.txt  |   8 +-
 .../bindings/input/touchscreen/tsc2007.txt |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  18 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   2 +-
 drivers/input/touchscreen/Kconfig  |   1 +
 drivers/input/touchscreen/ads7846.c|  85 +-
 drivers/input/touchscreen/tsc2007.c| 286 +++--
 include/linux/i2c/tsc2007.h|   8 +
 10 files changed, 401 insertions(+), 46 deletions(-)

-- 
2.5.1

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

[PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

This has been integrated and interpretation of the inversion (flipping)
properties for the x and y axis has been added to accommodate any
orientation of the touch in relation to the LCD.

By scaling the min/max ADC values to the screen size it is now possible to
pre-calibrate the touch so that is (almost) exactly matches the LCD it is
glued onto. This allows to well enough operate the touch before a user
space calibration can improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 .../devicetree/bindings/input/ads7846.txt  |  8 ++-
 drivers/input/touchscreen/ads7846.c| 72 --
 2 files changed, 74 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
b/Documentation/devicetree/bindings/input/ads7846.txt
index df8b127..ae56355 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,12 +26,17 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+   Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv  The VREF voltage, in millivolts (u16).
ti,keep-vref-on set to keep vref on for differential
measurements as well
-   ti,swap-xy  swap x and y axis
ti,settle-delay-usecSettling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers.  If set to non-zero,
@@ -79,6 +84,7 @@ Example for a TSC2046 chip connected to an McSPI controller 
of an OMAP SoC::
pendown-gpio = < 8 0>;
vcc-supply = <_vcc3>;
 
+   touchscreen-swapped-x-y;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 04edc8f..4525f00 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -109,8 +110,14 @@ struct ads7846 {
u16 vref_delay_usecs;
u16 x_plate_ohms;
u16 pressure_max;
+   u16 x_min;
+   u16 x_max;
+   u16 y_min;
+   u16 y_max;
 
boolswap_xy;
+   boolinvert_x;
+   boolinvert_y;
booluse_internal;
 
struct ads7846_packet   *packet;
@@ -828,9 +835,48 @@ static void ads7846_report_state(struct ads7846 *ts)
if (Rt) {
struct input_dev *input = ts->input;
 
+   dev_dbg(>spi->dev,
+   "Raw point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+   /* clamp to expected ADC range */
+   if (x < ts->x_min)
+   x = ts->x_min;
+   if (x > ts->x_max)
+   x = ts->x_max;
+   if (y < ts->y_min)
+   y = ts->y_min;
+   if (y > ts->y_max)
+   y = ts->y_max;
+
+   dev_dbg(>spi->dev,
+   "Clamped point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* flip */
+   if (ts->invert_x)
+   x = (ts->x_max - x) + ts->x_min;
+   if (ts->invert_y)
+   y = (ts->y_max - y) + ts->y_min;
+
+   dev_dbg(>spi->dev,
+   "Flipped point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* scale to desired output range */
+   x = (input->absinfo[ABS_X].maximum * (x - ts->x_min))
+   / (ts->x_max - ts->x_min);
+   y = (input->absinfo[ABS_Y].maximum * (y - ts->y_min))
+   / 

[PATCH v2 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This driver provides an iio interface for these adc channels
in addition to the raw x, y, z values and the estimated touch
screen resistance. This can be used for debugging or special
applications.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/Kconfig   |   1 +
 drivers/input/touchscreen/tsc2007.c | 137 +++-
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index deb14c1..b437ead 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -941,6 +941,7 @@ config TOUCHSCREEN_TSC2005
 config TOUCHSCREEN_TSC2007
tristate "TSC2007 based touchscreens"
depends on I2C
+   select IIO
help
  Say Y here if you have a TSC2007 based touchscreen.
 
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 1a8a79d..4d3c995 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -61,6 +64,16 @@
 #define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
 #define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
 
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+   .datasheet_name = _name, \
+   .type = _type, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+   BIT(_chan_info), \
+   .indexed = 1, \
+   .channel = _chan, \
+}
+
 struct ts_event {
u16 x;
u16 y;
@@ -69,9 +82,11 @@ struct ts_event {
 
 struct tsc2007 {
struct input_dev*input;
+   struct iio_dev  *indio;
charphys[32];
 
struct i2c_client   *client;
+   struct mutexmlock;
 
u16 model;
u16 x_plate_ohms;
@@ -192,7 +207,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
/* pen is down, continue with the measurement */
+
+   mutex_lock(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -340,6 +358,86 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
 }
 
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+   TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+   TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+   struct  tsc2007 *tsc = iio_priv(indio_dev);
+   int adc_chan = chan->channel;
+   int ret = 0;
+
+   if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+   return -EINVAL;
+
+   if (mask != IIO_CHAN_INFO_RAW)
+   return -EINVAL;
+
+   mutex_lock(>mlock);
+
+   switch (chan->channel) {
+   case 0:
+   *val = tsc2007_xfer(tsc, READ_X);
+   break;
+   case 1:
+   *val = tsc2007_xfer(tsc, READ_Y);
+   break;
+   case 2:
+   *val = tsc2007_xfer(tsc, READ_Z1);
+   break;
+   case 3:
+   *val = tsc2007_xfer(tsc, READ_Z2);
+   break;
+   case 4:
+   *val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
+   break;
+   case 5: {
+   struct ts_event tc;
+
+   tc.x = tsc2007_xfer(tsc, READ_X);
+   tc.z1 = tsc2007_xfer(tsc, READ_Z1);
+   tc.z2 = tsc2007_xfer(tsc, READ_Z2);
+   *val = tsc2007_calculate_resistance(tsc, );
+   break;
+   }
+   case 6:
+   *val = tsc2007_

[PATCH v2 6/8] drivers:input:ads7846(+tsc2046): recognise old binding for coordinate flipping

[H. Nikolaus Schaller]

By this patch we still recognise the old binding ti,swap-xy in parallel to
the common binding touchscreen-swapped-x-y. This keeps compatibility
to older (out-of-tree) device tree binaries.

We do this in a separate patch so that it can be easily reverted in the
future to retire the old API. A notice is printed to remind developers
of using old API.

We also fix the bindings name for all in-tree device tree sources in
a separate patch.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/ads7846.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 4525f00..b9896fd 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1259,7 +1259,11 @@ static const struct ads7846_platform_data 
*ads7846_probe_dt(struct device *dev)
of_property_read_u16(node, "ti,vref-mv", >vref_mv);
pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
 
-   pdata->swap_xy = of_property_read_bool(node, "touchscreen-swapped-x-y");
+   pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
+   if (pdata->swap_xy)
+   dev_notice(dev, "please update device tree to use 
touchscreen-swapped-x-y");
+   pdata->swap_xy |= of_property_read_bool(node,
+   "touchscreen-swapped-x-y");
 
of_property_read_u16(node, "ti,settle-delay-usec",
 >settle_delay_usecs);
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

Am 09.11.2015 um 18:31 schrieb Rob Herring <r...@kernel.org>:

> On Fri, Nov 06, 2015 at 04:14:47PM +0100, H. Nikolaus Schaller wrote:
>> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
>> introduced common DT bindings for touchscreens [1] and a helper function to
>> parse the DT.
>> 
>> This has been integrated and interpretation of the inversion (flipping)
>> properties for the x and y axis has been added to accommodate any
>> orientation of the touch in relation to the LCD.
>> 
>> By scaling the min/max ADC values to the screen size it is now possible to
>> pre-calibrate the touch so that is (almost) exactly matches the LCD it is
>> glued onto. This allows to well enough operate the touch before a user
>> space calibration can improve the precision.
>> 
>> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> .../devicetree/bindings/input/ads7846.txt  |  8 ++-
> 
> The binding change looks okay, but...
> 
>> @@ -1213,7 +1259,7 @@ static const struct ads7846_platform_data 
>> *ads7846_probe_dt(struct device *dev)
>>  of_property_read_u16(node, "ti,vref-mv", >vref_mv);
>>  pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
>> 
>> -pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
>> +pdata->swap_xy = of_property_read_bool(node, "touchscreen-swapped-x-y");
> 
> This will break with old dtb's.

We have a patch for all boards in tree (external dtbs must be modified by their 
maintainers).

> The driver should look for either 
> property.

It is easy to recognize either one.

Noted for V2.

BR and thanks,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

this should reduce unnecessary input events.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/tsc2007.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index e0c7173..1a8a79d 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
 
wait_queue_head_t   wait;
boolstopped;
+   boolpendown;
 
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -251,7 +252,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
dev_dbg(>client->dev,
"shaped point(%4d,%4d), pressure 
(%4u)\n",
tc.x, tc.y, rt);
-   input_report_key(input, BTN_TOUCH, 1);
+   if (!ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 1);
+   ts->pendown = true;
+   }
input_report_abs(input, ABS_X, tc.x);
input_report_abs(input, ABS_Y, tc.y);
input_report_abs(input, ABS_PRESSURE, rt);
@@ -272,9 +276,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
dev_dbg(>client->dev, "UP\n");
 
-   input_report_key(input, BTN_TOUCH, 0);
-   input_report_abs(input, ABS_PRESSURE, 0);
-   input_sync(input);
+   if (ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 0);
+   input_report_abs(input, ABS_PRESSURE, 0);
+   input_sync(input);
+
+   ts->pendown = false;
+   }
 
if (ts->clear_penirq)
ts->clear_penirq();
-- 
2.5.1

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

[PATCH 1/7] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

This has been integrated and interpretation of the inversion (flipping)
properties for the x and y axis has been added to accommodate any
orientation of the touch in relation to the LCD.

By scaling the min/max ADC values to the screen size it is now possible to
pre-calibrate the touch so that is (almost) exactly matches the LCD it is
glued onto. This allows to well enough operate the touch before a user
space calibration can improve the precision.

calculate_pressure has been renamed to calculate_resistance because
that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 .../bindings/input/touchscreen/tsc2007.txt |  20 +--
 drivers/input/touchscreen/tsc2007.c| 135 +
 include/linux/i2c/tsc2007.h|   8 ++
 3 files changed, 135 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again 
the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 0 0>;
ti,x-plate-ohms = <180>;
+   touchscreen-size-x = <640>;
+   touchscreen-size-y = <480>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..e0c7173 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
u16 model;
u16 x_plate_ohms;
+   boolswap_xy;
+   boolinvert_x;
+   boolinvert_y;
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   u16 max_x;
+   u16 max_y;
u16 max_rt;
unsigned long   poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct 
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+   struct ts_event *tc)
 {
u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
 
+   dev_dbg(>client->dev, "sof

[PATCH 4/7] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

Tested on: GTA04A4 (Letux2804), Letux3704, Letux7004

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 7166d88..95fed8e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -357,10 +357,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+   touchscreen-size-x = <480>;
+   touchscreen-size-y = <640>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <2>;
+   touchscreen-fuzz-y = <2>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-y;
+   ti,min-x = <0x100>;
+   ti,max-x = <0xf00>;
+   ti,min-y = <0x100>;
+   ti,max-y = <0xf00>;
+   ti,max-rt = <4096>;
+   ti,x-plate-ohms = <550>;
};
 };
 
-- 
2.5.1

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

[PATCH 0/7] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

This patch series improves the drivers for the tsc2007 and ads7846/tsc2046
touchscreen controllers which are e.g. used by the GTA04, OpenPandora
and Pyra devices.

New common bindings have been defined by commit b98abe52fa8e:

Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y 
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (7):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
  drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
  drivers:input:tsc2007: add iio interface to read external ADC input,
temperature and raw conversion values
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings

 .../devicetree/bindings/input/ads7846.txt  |   8 +-
 .../bindings/input/touchscreen/tsc2007.txt |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  18 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   2 +-
 drivers/input/touchscreen/ads7846.c|  83 +-
 drivers/input/touchscreen/tsc2007.c| 286 +++--
 include/linux/i2c/tsc2007.h|   8 +
 9 files changed, 397 insertions(+), 47 deletions(-)

-- 
2.5.1

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

[PATCH 7/7] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  2 +-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index d0dd036..01dae66 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
ti,y-max = /bits/ 16 <3600>;
ti,x-plate-ohms = /bits/ 16 <80>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
 
linux,wakeup;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index f672a04..9497cc6 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -696,10 +696,19 @@
pendown-gpio = < 30 0>;
vcc-supply = <>;
 
-   ti,x-min = /bits/ 16 <0>;
-   ti,x-max = /bits/ 16 <8000>;
-   ti,y-min = /bits/ 16 <0>;
-   ti,y-max = /bits/ 16 <4800>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <16>;
+   touchscreen-fuzz-y = <16>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+
+   ti,x-min = /bits/ 16 <160>;
+   ti,x-max = /bits/ 16 <3900>;
+   ti,y-min = /bits/ 16 <220>;
+   ti,y-max = /bits/ 16 <3750>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index f4b1a61..c772b76 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -65,7 +65,7 @@
ti,y-max = /bits/ 16 <4800>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
linux,wakeup;
};
 };
-- 
2.5.1

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

[PATCH 3/7] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This driver provides an iio interface for these adc channels
in addition to the raw x, y, z values and the estimated touch
screen resistance. This can be used for debugging or special
applications.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/tsc2007.c | 137 +++-
 1 file changed, 135 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 1a8a79d..4d3c995 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -61,6 +64,16 @@
 #define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
 #define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
 
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+   .datasheet_name = _name, \
+   .type = _type, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+   BIT(_chan_info), \
+   .indexed = 1, \
+   .channel = _chan, \
+}
+
 struct ts_event {
u16 x;
u16 y;
@@ -69,9 +82,11 @@ struct ts_event {
 
 struct tsc2007 {
struct input_dev*input;
+   struct iio_dev  *indio;
charphys[32];
 
struct i2c_client   *client;
+   struct mutexmlock;
 
u16 model;
u16 x_plate_ohms;
@@ -192,7 +207,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
/* pen is down, continue with the measurement */
+
+   mutex_lock(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -340,6 +358,86 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
 }
 
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+   TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+   TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+   struct  tsc2007 *tsc = iio_priv(indio_dev);
+   int adc_chan = chan->channel;
+   int ret = 0;
+
+   if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+   return -EINVAL;
+
+   if (mask != IIO_CHAN_INFO_RAW)
+   return -EINVAL;
+
+   mutex_lock(>mlock);
+
+   switch (chan->channel) {
+   case 0:
+   *val = tsc2007_xfer(tsc, READ_X);
+   break;
+   case 1:
+   *val = tsc2007_xfer(tsc, READ_Y);
+   break;
+   case 2:
+   *val = tsc2007_xfer(tsc, READ_Z1);
+   break;
+   case 3:
+   *val = tsc2007_xfer(tsc, READ_Z2);
+   break;
+   case 4:
+   *val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
+   break;
+   case 5: {
+   struct ts_event tc;
+
+   tc.x = tsc2007_xfer(tsc, READ_X);
+   tc.z1 = tsc2007_xfer(tsc, READ_Z1);
+   tc.z2 = tsc2007_xfer(tsc, READ_Z2);
+   *val = tsc2007_calculate_resistance(tsc, );
+   break;
+   }
+   case 6:
+   *val = tsc2007_is_pen_down(tsc);
+   break;
+   case 7:
+   *val = tsc2007_xfer(tsc,
+   (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
+   break;
+   case 8:
+   *val = tsc2007_xfer(tsc,
+   (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
+   break;
+   }
+
+   /* Prepare for next touch reading - power down ADC, enable PENIRQ */
+   tsc2007_xfer(tsc, PWRDOWN);
+
+   mutex_unl

[PATCH 5/7] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

This has been integrated and interpretation of the inversion (flipping)
properties for the x and y axis has been added to accommodate any
orientation of the touch in relation to the LCD.

By scaling the min/max ADC values to the screen size it is now possible to
pre-calibrate the touch so that is (almost) exactly matches the LCD it is
glued onto. This allows to well enough operate the touch before a user
space calibration can improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 .../devicetree/bindings/input/ads7846.txt  |  8 ++-
 drivers/input/touchscreen/ads7846.c| 72 --
 2 files changed, 74 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
b/Documentation/devicetree/bindings/input/ads7846.txt
index df8b127..ae56355 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,12 +26,17 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+   Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv  The VREF voltage, in millivolts (u16).
ti,keep-vref-on set to keep vref on for differential
measurements as well
-   ti,swap-xy  swap x and y axis
ti,settle-delay-usecSettling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers.  If set to non-zero,
@@ -79,6 +84,7 @@ Example for a TSC2046 chip connected to an McSPI controller 
of an OMAP SoC::
pendown-gpio = < 8 0>;
vcc-supply = <_vcc3>;
 
+   touchscreen-swapped-x-y;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 04edc8f..4525f00 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -109,8 +110,14 @@ struct ads7846 {
u16 vref_delay_usecs;
u16 x_plate_ohms;
u16 pressure_max;
+   u16 x_min;
+   u16 x_max;
+   u16 y_min;
+   u16 y_max;
 
boolswap_xy;
+   boolinvert_x;
+   boolinvert_y;
booluse_internal;
 
struct ads7846_packet   *packet;
@@ -828,9 +835,48 @@ static void ads7846_report_state(struct ads7846 *ts)
if (Rt) {
struct input_dev *input = ts->input;
 
+   dev_dbg(>spi->dev,
+   "Raw point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+   /* clamp to expected ADC range */
+   if (x < ts->x_min)
+   x = ts->x_min;
+   if (x > ts->x_max)
+   x = ts->x_max;
+   if (y < ts->y_min)
+   y = ts->y_min;
+   if (y > ts->y_max)
+   y = ts->y_max;
+
+   dev_dbg(>spi->dev,
+   "Clamped point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* flip */
+   if (ts->invert_x)
+   x = (ts->x_max - x) + ts->x_min;
+   if (ts->invert_y)
+   y = (ts->y_max - y) + ts->y_min;
+
+   dev_dbg(>spi->dev,
+   "Flipped point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* scale to desired output range */
+   x = (input->absinfo[ABS_X].maximum * (x - ts->x_min))
+   / (ts->x_max - ts->x_min);
+   y = (input->absinfo[ABS_Y].maximum * (y - ts->y_min))
+   / 

[PATCH 6/7] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/input/touchscreen/ads7846.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 4525f00..04d00e8 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1559,6 +1559,17 @@ static int ads7846_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+   { "tsc2046", 0 },
+   { "ads7843", 0 },
+   { "ads7845", 0 },
+   { "ads7846", 0 },
+   { "ads7873", 0 },
+   { }
+};
+
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
.driver = {
.name   = "ads7846",
-- 
2.5.1

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

Re: [PATCH 3/7] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

[H. Nikolaus Schaller]

Am 06.11.2015 um 17:08 schrieb kbuild test robot <l...@intel.com>:

> Hi Nikolaus,
> 
> [auto build test ERROR on input/next]
> [also build test ERROR on v4.3 next-20151106]
> 
> url:
> https://github.com/0day-ci/linux/commits/H-Nikolaus-Schaller/drivers-touchscreen-tsc2007-and-ads7846-tsc2046-improvements-use-common-touchscreen-bindings-pre-calibration-spi-fix-and-provide-iio-raw-values/20151106-231936
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
> config: x86_64-randconfig-s2-11062316 (attached as .config)
> reproduce:
># save the attached .config to linux build tree
>make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>   drivers/built-in.o: In function `tsc2007_remove':
>>> tsc2007.c:(.text+0x23a2a6): undefined reference to `iio_device_unregister'
>   drivers/built-in.o: In function `tsc2007_probe':
>>> tsc2007.c:(.text+0x23a3bf): undefined reference to `devm_iio_device_alloc'
>>> tsc2007.c:(.text+0x23a436): undefined reference to `iio_device_register'

Ok, that is a missing dependency on CONFIG_IIO.

Has been noted for V2.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

Am 25.10.2015 um 13:04 schrieb Jonathan Cameron <ji...@kernel.org>:

> On 16/10/15 13:53, H. Nikolaus Schaller wrote:
>> This driver code was found as:
>> 
>> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
>> 
>> Fixed various compilation issues and test this driver on omap5 evm.
>> 
>> Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> Signed-off-by: Marek Belisko <ma...@goldelico.com>
>> Acked-by: Laxman Dewangan <ldewan...@nvidia.com>
>> Reviewed-by: Jonathan Cameron <ji...@kernel.org>
>> Acked-by: Lee Jones <lee.jo...@linaro.org>
> Applied to the togreg branch of iio.git - initially pushed out as testing.

Thanks! I was just working on a V4 - but that is a fix for omap5-uevm DT only. 
So I will remove the driver code and submit separately.

> Unfortunately the timing is such that it's not going to make the upcoming
> merge window so will be an early entry to linux-next after the merge window
> closes.

Well, that happens. We can forward-port it to our distribution kernel so that 
it is
already available to users.

> 
> Jonathan

BR,
Nikolaus

>> ---
>> drivers/iio/adc/Kconfig|   8 +
>> drivers/iio/adc/Makefile   |   1 +
>> drivers/iio/adc/palmas_gpadc.c | 817 
>> +
>> include/linux/mfd/palmas.h |  75 ++--
>> 4 files changed, 877 insertions(+), 24 deletions(-)
>> create mode 100644 drivers/iio/adc/palmas_gpadc.c
>> 
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 50c103d..5100e56 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -264,6 +264,14 @@ config NAU7802
>>To compile this driver as a module, choose M here: the
>>module will be called nau7802.
>> 
>> +config PALMAS_GPADC
>> +tristate "TI Palmas General Purpose ADC"
>> +depends on MFD_PALMAS
>> +help
>> +  Palmas series pmic chip by Texas Instruments (twl6035/6037)
>> +  is used in smartphones and tablets and supports a 16 channel
>> +  general purpose ADC.
>> +
>> config QCOM_SPMI_IADC
>>  tristate "Qualcomm SPMI PMIC current ADC"
>>  depends on SPMI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index a096210..716f112 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>> obj-$(CONFIG_MCP3422) += mcp3422.o
>> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>> obj-$(CONFIG_NAU7802) += nau7802.o
>> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
>> new file mode 100644
>> index 000..71763c5
>> --- /dev/null
>> +++ b/drivers/iio/adc/palmas_gpadc.c
>> @@ -0,0 +1,817 @@
>> +/*
>> + * palmas-adc.c -- TI PALMAS GPADC.
>> + *
>> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
>> + *
>> + * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MOD_NAME "palmas-gpadc"
>> +#define PALMAS_ADC_CONVERSION_TIMEOUT   (msecs_to_jiffies(5000))
>> +#define PALMAS_TO_BE_CALCULATED 0
>> +#define PALMAS_GPADC_TRIMINVALID-1
>> +
>> +struct palmas_gpadc_info {
>> +/* calibration codes and regs */
>> +int x1; /* lower ideal code */
>> +int x2; /* higher ideal code */
>> +int v1; /* expected lower volt reading */
>> +int v2; /* expected higher volt reading */
>> +u8 trim1_reg;   /* register number for lower trim */
>> +u8 trim2_reg;   /* register number for upper trim */
>> +int gain;   /* calculated from above (after reading trim regs) */
>> +int offset; 

Re: [PATCH v3 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Hi,

Am 20.10.2015 um 18:24 schrieb Tony Lindgren <t...@atomide.com>:

> Hi,
> 
> * H. Nikolaus Schaller <h...@goldelico.com> [151016 05:58]:
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap5-uevm.dts | 10 ++
>> 1 file changed, 10 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
>> b/arch/arm/boot/dts/omap5-uevm.dts
>> index 0e8128b..63f81bb 100644
>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>> @@ -342,6 +342,16 @@
>> 
>>  ti,ldo6-vibrator;
>> 
>> +gpadc {
>> +compatible = "ti,palmas-gpadc";
>> +interrupts = <18 0
>> +  16 0
>> +  17 0>;
>> +#io-channel-cells = <1>;
>> +ti,channel0-current-microamp = <5>;
>> +ti,channel3-current-microamp = <10>;
>> +};
>> +
>>  regulators {
>>  smps123_reg: smps123 {
>>  /* VDD_OPP_MPU */
> 
> FYI, please send this one separately once the binding and driver is
> merged.
> 
> This need to be updated arch/arm/boot/dts/omap5-board-common.dts, so
> this will cause merge conflicts if applied with the driver.

Ok!

We have our own OMAP5 board in the pipeline and there it will help
as well to rebase it using arch/arm/boot/dts/omap5-board-common.dts

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

Am 19.10.2015 um 13:57 schrieb Lars-Peter Clausen <l...@metafoo.de>:

> On 10/16/2015 02:53 PM, H. Nikolaus Schaller wrote:
> [...]
>> +Optional sub-nodes:
>> +ti,channel0-current-microamp: Channel 0 current in uA.
>> +Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
>> +ti,channel3-current-microamp: Channel 3 current in uA.
>> +Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
>> +ti,enable-extended-delay: Enable extended delay.
> 
> Those three above sound more like configuration policy, rather than hardware
> description. What influence which values should be chosen?

e.g. the nominal value of the NTC that can be connected if the Palmas
is hooked up in a standard way.

If a board has no NTC and uses channel0 for a different purpose one
should choose 0uA.

If it is let's say 10kOhm it should probably be 20uA to give a nominal voltage
reading of 200mV.

100kOhm will give 2V which is at the limit of the ADC input range and
therefore it would be better to choose 15uA or 5uA.

I think choosing extended delay depends on the noisiness of the input
signal but I am not a specialist for this feature.

So I would say the board hardware mandates some specific value.

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/3] UART slave device support (goldelico version)

[H. Nikolaus Schaller]

H. Nikolaus Schaller (3):
  tty: serial core: provide a method to search uart by phandle
  tty: serial_core: add hooks for uart slave drivers
  misc: Add w2sg0004 gps receiver driver

 .../devicetree/bindings/misc/wi2wi,w2sg0004.txt|  18 +
 .../devicetree/bindings/serial/slaves.txt  |  16 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 Documentation/serial/slaves.txt|  36 ++
 drivers/misc/Kconfig   |  18 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/w2sg0004.c| 443 +
 drivers/tty/serial/serial_core.c   | 214 +-
 include/linux/serial_core.h|  25 +-
 include/linux/w2sg0004.h   |  27 ++
 10 files changed, 793 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
 create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
 create mode 100644 Documentation/serial/slaves.txt
 create mode 100644 drivers/misc/w2sg0004.c
 create mode 100644 include/linux/w2sg0004.h

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 3/3] misc: Add w2sg0004 gps receiver driver

[H. Nikolaus Schaller]

Am 16.10.2015 um 20:08 schrieb H. Nikolaus Schaller <h...@goldelico.com>:

> Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
> Use uart slave + notification hooks to glue with tty and turn on/off the
> module. Detect if the module is turned on (sends data) but should be off,
> e.g. if already turned on during boot.
> 
> Additionally, rfkill block/unblock can be used to control an external LNA
> (and power down the module if not needed).
> 
> The driver concept is based on code developed by NeilBrown <ne...@suse.de>
> but simplified and adapted to use the serial slave API.
> 
> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> ---
> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt|  18 +
> .../devicetree/bindings/vendor-prefixes.txt|   1 +
> drivers/misc/Kconfig   |  18 +
> drivers/misc/Makefile  |   1 +
> drivers/misc/w2sg0004.c| 443 +
> drivers/tty/serial/serial_core.c   |  25 +-
^^^sorry this change is garbage from patch editing^^^
> include/linux/w2sg0004.h   |  27 ++
> 7 files changed, 522 insertions(+), 11 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> create mode 100644 drivers/misc/w2sg0004.c
> create mode 100644 include/linux/w2sg0004.h
> 
> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt 
> b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> new file mode 100644
> index 000..ef0d6d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> @@ -0,0 +1,18 @@
> +Wi2Wi GPS module connected through UART
> +
> +Required properties:
> +- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
> +- uart: the uart we are connected to (provides DTR for power control)
> +
> +Optional properties:
> +- lna-suppy: an (optional) LNA regulator that is enabled together with the 
> GPS receiver
> +
> +example:
> +
> +gps_receiver: w2sg0004 {
> +compatible = "wi2wi,w2sg0004";
> +lna-supply = <>;/* LNA regulator */
> +on-off-gpio = < 17 0>; /* GPIO_145: trigger for 
> turning on/off w2sg0004 */
> +uart = <>; /* we are a slave of uart1 */
> +}
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..a778eb5 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -230,6 +230,7 @@ via   VIA Technologies, Inc.
> virtioVirtual I/O Device Specification, developed by the OASIS 
> consortium
> voipacVoipac Technologies s.r.o.
> wexlerWexler
> +wi2wiWi2Wi, Inc.
> winbond Winbond Electronics corp.
> wlf   Wolfson Microelectronics
> wmWondermedia Technologies, Inc.
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index c29..1279faf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -537,4 +537,22 @@ source "drivers/misc/mic/Kconfig"
> source "drivers/misc/genwqe/Kconfig"
> source "drivers/misc/echo/Kconfig"
> source "drivers/misc/cxl/Kconfig"
> +
> +menu "GTA04 misc hardware support"
> +
> +config W2SG0004
> + tristate "W2SG0004 on/off control"
> + depends on GPIOLIB
> + help
> +   Enable on/off control of W2SG0004 GPS to allow powering up/down if
> +   the /dev/tty$n is opened/closed.
> +   It also provides a rfkill gps node to control the LNA power.
> +
> +config W2SG0004_DEBUG
> + bool "W2SG0004 on/off debugging"
> + depends on W2SG0004
> + help
> +   Enable driver debugging mode of W2SG0004 GPS.
> +
> +endmenu
> endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 537d7f3..a153a89 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,5 +54,6 @@ obj-$(CONFIG_SRAM)  += sram.o
> obj-y += mic/
> obj-$(CONFIG_GENWQE)  += genwqe/
> obj-$(CONFIG_ECHO)+= echo/
> +obj-$(CONFIG_W2SG0004)   += w2sg0004.o
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE)+= cxl/
> diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
> new file mode 100644
> index 000..6aadf44
> --- /dev/null
> +++ b/driv

Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver

[H. Nikolaus Schaller]

Am 16.10.2015 um 21:06 schrieb Arnd Bergmann <a...@arndb.de>:

> On Friday 16 October 2015 20:08:35 H. Nikolaus Schaller wrote:
>> +
>> +static int w2sg_data_probe(struct platform_device *pdev)
>> +{
>> +   struct w2sg_pdata *pdata = dev_get_platdata(>dev);
>> +   struct w2sg_data *data;
>> +   struct rfkill *rf_kill;
>> +   int err;
>> +
>> +   pr_debug("%s()\n", __func__);
>> +
>> +   if (pdev->dev.of_node) {
>> +   struct device *dev = >dev;
>> +   enum of_gpio_flags flags;
>> +
>> +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> +   if (!pdata)
>> 
> 
> Why is this a platform_device and not a serio_device?

I can't find a struct serio_device. What is that?

BR and thanks,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 0/3] UART slave device support (goldelico version)

[H. Nikolaus Schaller]

Changes V3:
- changed from RFC to PATCH
- added separate bindings and concept documentation documents
- worked in comments by Sergei Zviagintsev

Changes V2:
- fixed some formatting

This patch series is our proposal to add hooks so that the driver for a device 
connected to an UART can
monitor modem control lines and data activity of the connected chip.

It contains an example for such a device driver which needs such sophisticated 
power control: wi2wi,w2sg0004

A remote device connected to a RS232 interface is usually power controlled by 
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close() 
syscalls
and on demand by tcsetattr().

With embedded devices, the serial peripheral might be directly and always 
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to 
be done by some
chip specific device driver (which we call "UART slave") through some 
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state 
except by sending
or not sending data to the UART. In such a case the device driver must be able 
to monitor data
activity. The role of the device driver is to encapsulate such power control in 
a single place.

This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is 
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART

A slave device tree entry simply adds a phandle reference to the UART it is 
connected to, e.g.

   gps {
   compatible = "wi2wi,w2sg0004";
   uart = <>;
   };

The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart 
driver.
devm_serial_get_uart_by_phandle() follows the concept of 
devm_usb_get_phy_by_phandle().

A slave device driver registers itself with serial_register_slave() to receive 
notifications.
Notification handlers can be registered by serial_register_mctrl_notification() 
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL 
handler registered,
no notifications are sent.

RX notification handlers can define a ktermios setup and modify or decide to 
throw away the
character that is passed upwards.

This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want 
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself 
as a "virtual
GPIO". The idea of a "virtual GPIO"  is not compatible with the concept that DT 
must
describe hardware (and not virtual hardware). So in this new solution DT only 
describes that
the w2sg0004 is connected to some UART and how the power state signalling works 
is left
to the driver implementations.

The rx data notification also removes the concept of having two different 
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line 
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might 
even be
extensible that the chip driver could filter or consume the rx data before it 
is passed
to the tty layer.

This patch works on 4.3-rc as intended except one major weakness: we have to 
call
uart_change_speed() each time we open the tty. This is the opposite of what we 
would like
to have: that the slave initializes the uart speed through some termios and the 
tty level just uses
this setting. We have not yet completely understood how to make this work and 
are happy
about help in this area.


Am 16.10.2015 um 20:08 schrieb H. Nikolaus Schaller <h...@goldelico.com>:

> H. Nikolaus Schaller (3):
>  tty: serial core: provide a method to search uart by phandle
>  tty: serial_core: add hooks for uart slave drivers
>  misc: Add w2sg0004 gps receiver driver
> 
> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt|  18 +
> .../devicetree/bindings/serial/slaves.txt  |  16 +
> .../devicetree/bindings/vendor-prefixes.txt|   1 +
> Documentation/serial/slaves.txt|  36 ++
> drivers/misc/Kconfig   |  18 +
> drivers/misc/Makefile  |   1 +
> drivers/misc/w2sg0004.c| 443 +
> drivers/tty/serial/serial_core.c   | 214 +-
> include/linux/serial_core.h|  25 +-
> include/linux/w2sg0004.h   |  27 ++
> 10 files changed, 793 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
> create mode 100644 Documentation/serial/slaves.txt
> create mode 100644 drivers/mis

Re: [PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle

[H. Nikolaus Schaller]

Am 16.10.2015 um 20:39 schrieb Mark Rutland <mark.rutl...@arm.com>:

> On Fri, Oct 16, 2015 at 08:08:33PM +0200, H. Nikolaus Schaller wrote:
>> 1. add uart_ports to a search list as soon as they are registered
>> 2. provide a function to search an uart_port by phandle. This copies the
>>   mechanism how devm_usb_get_phy_by_phandle() works
>> 3. add a bindings document how serial slaves should use this feature
>> 4. add Documentation how serla slaves work in general
> 
> I thought maintainers preferred the child node approach to the phandle
> approach,

> and this series comes with no rationale (nor change log,
> despite being 'v3').

For unknown reasons it was not part of the outgoing git send-email.

Today is not my day of operating command line git...

I have added it as a reply.

> 
> I don't understand. What is going on here?

There was a discussion about child vs. phandle and I came up with thousands
of technical arguments and examples from other subsystems where phandle
is common. Because I still don't believe that child node approach is the right 
one.

At some time of this discussion, I was asked to provide code because people
wanted to compare both ideas on code basis.

Therefore I wrote an implementation that works and shows all aspects.
I published V1 and V2 and got some comments, but not really much.

What I never got was a really convincing argumentation or principle or DT 
writer's
guideline why uart slaves must be subnodes (except that "uart" is a degenerate
variant of a "bus" and therefore must be prepared to have multiple child nodes).

The latest counter-example I have found is how iio adcs are accessed:
Documentation/devicetree/bindings/iio/iio-bindings.txt

One could as well argue that adcs are a "bus" (especially if they have multiple
inputs) and therefore all consumers of adc data must be their children... But 
they
are not.

Nothing has happened since I submittted RFC V2. I.e. there is no child node 
based
approach accepted. There was no significant comparison or discussion.

Therefore I took the freedom to resubmit my code and prevent it from bitrotting
in my local git repo.

Hope this explains.

BR and thanks,
Nikolaus


> Mark.
> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> .../devicetree/bindings/serial/slaves.txt  |  16 +++
>> Documentation/serial/slaves.txt|  36 +++
>> drivers/tty/serial/serial_core.c   | 107 
>> +
>> include/linux/serial_core.h|  10 ++
>> 4 files changed, 169 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
>> create mode 100644 Documentation/serial/slaves.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/serial/slaves.txt 
>> b/Documentation/devicetree/bindings/serial/slaves.txt
>> new file mode 100644
>> index 000..353b87f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/slaves.txt
>> @@ -0,0 +1,16 @@
>> +Device-Tree bindings for UART slave devices
>> +
>> +A node describing a slave device defines a phandle to reference the UART
>> +the device is connected to. In the (unexpected) case of two or more UARTs
>> +a list of phandles can be specified.
>> +
>> +properties:
>> +- uart: (list of) phandle(s) of UART(s) the device is connected to
>> +
>> +
>> +example:
>> +
>> +gps {
>> +compatible = "wi2wi,w2sg0004";
>> +uart = <>;
>> +};
>> diff --git a/Documentation/serial/slaves.txt 
>> b/Documentation/serial/slaves.txt
>> new file mode 100644
>> index 000..6f8d44d
>> --- /dev/null
>> +++ b/Documentation/serial/slaves.txt
>> @@ -0,0 +1,36 @@
>> +UART slave device support
>> +
>> +A remote device connected to a RS232 interface is usually power controlled 
>> by the DTR line.
>> +The DTR line is managed automatically by the UART driver for open() and 
>> close() syscalls
>> +and on demand by tcsetattr().
>> +
>> +With embedded devices, the serial peripheral might be directly and always 
>> connected to the UART
>> +and there might be no physical DTR line involved. Power control (on/off) 
>> has to be done by some
>> +chip specific device driver (which we call "UART slave") through some 
>> mechanisms (I2C, GPIOs etc.)
>> +not related to the serial interface. Some devices do not explicitly tell 
>> their power state except
>> +by sending or not sending data to the UART. In such a case the device 
>> driver must be able to monitor
>> +data activity. The role 

Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver

[H. Nikolaus Schaller]

Am 16.10.2015 um 21:38 schrieb Arnd Bergmann <a...@arndb.de>:

> On Friday 16 October 2015 21:27:11 H. Nikolaus Schaller wrote:
>> Am 16.10.2015 um 21:06 schrieb Arnd Bergmann <a...@arndb.de>:
>> 
>>> On Friday 16 October 2015 20:08:35 H. Nikolaus Schaller wrote:
>>>> +
>>>> +static int w2sg_data_probe(struct platform_device *pdev)
>>>> +{
>>>> +   struct w2sg_pdata *pdata = dev_get_platdata(>dev);
>>>> +   struct w2sg_data *data;
>>>> +   struct rfkill *rf_kill;
>>>> +   int err;
>>>> +
>>>> +   pr_debug("%s()\n", __func__);
>>>> +
>>>> +   if (pdev->dev.of_node) {
>>>> +   struct device *dev = >dev;
>>>> +   enum of_gpio_flags flags;
>>>> +
>>>> +   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>>> +   if (!pdata)
>>>> 
>>> 
>>> Why is this a platform_device and not a serio_device?
>> 
>> I can't find a struct serio_device. What is that?
>> 
> 
> Sorry, I meant 'struct serio', see drivers/input/serio/
> 
> This is an existing infrastructure that is used for devices attached
> to a dumb serial device (rs232 or 8042/psaux usually). They have
> a user interface for connecting a driver to a port, but you should
> be able to do it all in the kernel as well if DT has the information
> what device is connected.

Ah, I understand. But it is for a different purpose. E.g. making a
serial device (mouse/touch) an input device. So it is a driver sitting
"on top" of tty/uart drivers.

The problem to be solved here is a different one. The only task for
the driver is to do power control of the device. I.e. turn it on by
open("/dev/ttyX") or asserting DTR.

So we are on a much lower level.

Please see also the patch 0/3 I have resent (the BLURB defined
by git --edit-description was apparently eaten by my git send-email).

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

From: Marek Belisko 

Code was found at:
https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1

Signed-off-by: Laxman Dewangan 
Signed-off-by: Marek Belisko  [Fixed minor typos + add 
channels list to documentation]
---
 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 48 
 drivers/iio/adc/palmas_gpadc.c | 52 +++---
 2 files changed, 95 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
new file mode 100644
index 000..a6de996
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
@@ -0,0 +1,48 @@
+* Palmas general purpose ADC IP block devicetree bindings
+
+Channels list:
+   0 battery type
+   1 battery temp NTC (optional current source)
+   2 GP
+   3 temp (with ext. diode, optional current source)
+   4 GP
+   5 GP
+   6 VBAT_SENSE
+   7 VCC_SENSE
+   8 Backup Battery voltage
+   9 external charger (VCHG)
+   10 VBUS
+   11 DC-DC current probe (how does this work?)
+   12 internal die temp
+   13 internal die temp
+   14 USB ID pin voltage
+   15 test network
+
+Required properties:
+- compatible : Must be "ti,palmas-gpadc".
+- #io-channel-cells: Should be set to <1>.
+
+Optional sub-nodes:
+ti,channel0-current-microamp: Channel 0 current in uA.
+   Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
+ti,channel3-current-microamp: Channel 3 current in uA.
+   Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
+ti,enable-extended-delay: Enable extended delay.
+
+Example:
+
+pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   ...
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   #io-channel-cells = <1>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+   };
+   ...
+};
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
index 71763c5..f42eb8a 100644
--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -460,6 +462,34 @@ static const struct iio_chan_spec 
palmas_gpadc_iio_channel[] = {
PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
 };
 
+static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
+   struct palmas_gpadc_platform_data **gpadc_pdata)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct palmas_gpadc_platform_data *gp_data;
+   int ret;
+   u32 pval;
+
+   gp_data = devm_kzalloc(>dev, sizeof(*gp_data), GFP_KERNEL);
+   if (!gp_data)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "ti,channel0-current-microamp", );
+   if (!ret)
+   gp_data->ch0_current = pval;
+
+   ret = of_property_read_u32(np, "ti,channel3-current-microamp", );
+   if (!ret)
+   gp_data->ch3_current = pval;
+
+   gp_data->extended_delay = of_property_read_bool(np,
+   "ti,enable-extended-delay");
+
+   *gpadc_pdata = gp_data;
+
+   return 0;
+}
+
 static int palmas_gpadc_probe(struct platform_device *pdev)
 {
struct palmas_gpadc *adc;
@@ -469,12 +499,17 @@ static int palmas_gpadc_probe(struct platform_device 
*pdev)
int ret, i;
 
pdata = dev_get_platdata(pdev->dev.parent);
-   if (!pdata || !pdata->gpadc_pdata) {
-   dev_err(>dev, "No platform data\n");
-   return -ENODEV;
-   }
 
-   gpadc_pdata = pdata->gpadc_pdata;
+   if (pdata && pdata->gpadc_pdata)
+   gpadc_pdata = pdata->gpadc_pdata;
+
+   if (!gpadc_pdata && pdev->dev.of_node) {
+   ret = palmas_gpadc_get_adc_dt_data(pdev, _pdata);
+   if (ret < 0)
+   return ret;
+   }
+   if (!gpadc_pdata)
+   return -EINVAL;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*adc));
if (!indio_dev) {
@@ -790,12 +825,19 @@ static const struct dev_pm_ops palmas_pm_ops = {
palmas_gpadc_resume)
 };
 
+static const struct of_device_id of_palmas_gpadc_match_tbl[] = {
+   { .compatible = "ti,palmas-gpadc", },
+   { /* end */ }
+};
+MODULE_DEVICE_TABLE(of, of_palmas_gpadc_match_tbl);
+
 static struct platform_driver palmas_gpadc_driver = {
.probe = palmas_gpadc_probe,
.remove = palmas_gpadc_remove,
.driver = {
.name = MOD_NAME,
   

[PATCH v3 0/3] Add Palmas iio gpadc

[H. Nikolaus Schaller]

H. Nikolaus Schaller (2):
  iio:adc: add iio driver for Palmas (twl6035/7) gpadc
  ARM: dts: omap5-uevm: enable iio gpadc for Palmas

Marek Belisko (1):
  iio:adc:palmas: add DT support

 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  48 ++
 arch/arm/boot/dts/omap5-uevm.dts   |  10 +
 drivers/iio/adc/Kconfig|   8 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 859 +
 include/linux/mfd/palmas.h |  75 +-
 6 files changed, 977 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

-- 
2.5.1

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

[PATCH v3 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
Signed-off-by: Marek Belisko <ma...@goldelico.com>
Acked-by: Laxman Dewangan <ldewan...@nvidia.com>
Reviewed-by: Jonathan Cameron <ji...@kernel.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>
---
 drivers/iio/adc/Kconfig|   8 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 817 +
 include/linux/mfd/palmas.h |  75 ++--
 4 files changed, 877 insertions(+), 24 deletions(-)
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 50c103d..5100e56 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -264,6 +264,14 @@ config NAU7802
  To compile this driver as a module, choose M here: the
  module will be called nau7802.
 
+config PALMAS_GPADC
+   tristate "TI Palmas General Purpose ADC"
+   depends on MFD_PALMAS
+   help
+ Palmas series pmic chip by Texas Instruments (twl6035/6037)
+ is used in smartphones and tablets and supports a 16 channel
+ general purpose ADC.
+
 config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..716f112 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
 obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
 obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
new file mode 100644
index 000..71763c5
--- /dev/null
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -0,0 +1,817 @@
+/*
+ * palmas-adc.c -- TI PALMAS GPADC.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOD_NAME "palmas-gpadc"
+#define PALMAS_ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
+#define PALMAS_TO_BE_CALCULATED 0
+#define PALMAS_GPADC_TRIMINVALID   -1
+
+struct palmas_gpadc_info {
+/* calibration codes and regs */
+   int x1; /* lower ideal code */
+   int x2; /* higher ideal code */
+   int v1; /* expected lower volt reading */
+   int v2; /* expected higher volt reading */
+   u8 trim1_reg;   /* register number for lower trim */
+   u8 trim2_reg;   /* register number for upper trim */
+   int gain;   /* calculated from above (after reading trim regs) */
+   int offset; /* calculated from above (after reading trim regs) */
+   int gain_error; /* calculated from above (after reading trim regs) */
+   bool is_uncalibrated;   /* if channel has calibration data */
+};
+
+#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, _is_uncalibrated) 
\
+   [PALMAS_ADC_CH_##_chan] = { \
+   .x1 = _x1, \
+   .x2 = _x2, \
+   .v1 = _v1, \
+   .v2 = _v2, \
+   .gain = PALMAS_TO_BE_CALCULATED, \
+   .offset = PALMAS_TO_BE_CALCULATED, \
+   .gain_error = PALMAS_TO_BE_CALCULATED, \
+   .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
+   .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
+   .is_uncalibrated = _is_uncalibrated \
+   }
+
+static struct palmas_gpadc_info palmas_gpadc_info[] = {
+   PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
+   PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
+   PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
+   PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
+   PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, fal

[PATCH v3 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 0e8128b..63f81bb 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -342,6 +342,16 @@
 
ti,ldo6-vibrator;
 
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   #io-channel-cells = <1>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+
regulators {
smps123_reg: smps123 {
/* VDD_OPP_MPU */
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/3] tty: serial_core: add hooks for uart slave drivers

[H. Nikolaus Schaller]

1. allow drivers to get notified about mctrl changes
2. allow drivers to get notified about rx data (indicating to the
   driver that the connected chip is active)
3. the driver also has the option to modify or block the
   received character instead of passing to the tty layer

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/tty/serial/serial_core.c | 104 +--
 include/linux/serial_core.h  |  15 +-
 2 files changed, 113 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9caa33e..b731100 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -166,6 +166,86 @@ err0:
 }
 EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
 
+void uart_register_slave(struct uart_port *uport, void *slave)
+{
+   if (!slave) {
+   uart_register_mctrl_notification(uport, NULL);
+   uart_register_rx_notification(uport, NULL, NULL);
+   }
+   uport->slave = slave;
+}
+EXPORT_SYMBOL_GPL(uart_register_slave);
+
+void uart_register_mctrl_notification(struct uart_port *uport,
+   int (*function)(void *slave, int state))
+{
+   uport->mctrl_notification = function;
+}
+EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
+
+static int uart_port_startup(struct tty_struct *tty, struct uart_state *state,
+   int init_hw);
+
+static void uart_port_shutdown(struct tty_port *port);
+
+void uart_register_rx_notification(struct uart_port *uport,
+   int (*function)(void *slave, unsigned int *c),
+   struct ktermios *termios)
+{
+   struct uart_state *state = uport->state;
+   struct tty_port *tty_port = >port;
+
+   if (!uport->slave)
+   return; /* slave must be registered first */
+
+   uport->rx_notification = function;
+
+   if (tty_port->count == 0) {
+   if (function) {
+   int retval = 0;
+
+   uart_change_pm(state, UART_PM_STATE_ON);
+   retval = uport->ops->startup(uport);
+   if (retval == 0 && termios) {
+   int hw_stopped;
+   /*
+* Initialise the hardware port settings.
+*/
+   uport->ops->set_termios(uport, termios, NULL);
+
+   /*
+* Set modem status enables based on termios 
cflag
+*/
+   spin_lock_irq(>lock);
+   if (termios->c_cflag & CRTSCTS)
+   uport->status |= UPSTAT_CTS_ENABLE;
+   else
+   uport->status &= ~UPSTAT_CTS_ENABLE;
+
+   if (termios->c_cflag & CLOCAL)
+   uport->status &= ~UPSTAT_DCD_ENABLE;
+   else
+   uport->status |= UPSTAT_DCD_ENABLE;
+
+   /* reset sw-assisted CTS flow control based on 
(possibly) new mode */
+   hw_stopped = uport->hw_stopped;
+   uport->hw_stopped = uart_softcts_mode(uport) &&
+   !(uport->ops->get_mctrl(uport)
+   & TIOCM_CTS);
+   if (uport->hw_stopped) {
+   if (!hw_stopped)
+   uport->ops->stop_tx(uport);
+   } else {
+   if (hw_stopped)
+   uport->ops->start_tx(uport);
+   }
+   spin_unlock_irq(>lock);
+   }
+   } else
+   uart_port_shutdown(tty_port);
+   }
+}
+EXPORT_SYMBOL_GPL(uart_register_rx_notification);
 
 /*
  * This routine is used by the interrupt handler to schedule processing in
@@ -224,6 +304,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int 
set, unsigned int clear)
port->mctrl = (old & ~clear) | set;
if (old != port->mctrl)
port->ops->set_mctrl(port, port->mctrl);
+
+   if (port->mctrl_notification)
+   (*port->mctrl_notification)(port->slave, port->mctrl);
+
spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -263,7 +347,8 @@ static int uart_port_startup(struct tty_struct *tty, struct 
uart_state *state,
uart_circ_clear(>xmit);
}
 
-

[PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver

[H. Nikolaus Schaller]

Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
Use uart slave + notification hooks to glue with tty and turn on/off the
module. Detect if the module is turned on (sends data) but should be off,
e.g. if already turned on during boot.

Additionally, rfkill block/unblock can be used to control an external LNA
(and power down the module if not needed).

The driver concept is based on code developed by NeilBrown <ne...@suse.de>
but simplified and adapted to use the serial slave API.

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 .../devicetree/bindings/misc/wi2wi,w2sg0004.txt|  18 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/misc/Kconfig   |  18 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/w2sg0004.c| 443 +
 drivers/tty/serial/serial_core.c   |  25 +-
 include/linux/w2sg0004.h   |  27 ++
 7 files changed, 522 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
 create mode 100644 drivers/misc/w2sg0004.c
 create mode 100644 include/linux/w2sg0004.h

diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt 
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index 000..ef0d6d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,18 @@
+Wi2Wi GPS module connected through UART
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+- uart: the uart we are connected to (provides DTR for power control)
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together with the GPS 
receiver
+
+example:
+
+gps_receiver: w2sg0004 {
+compatible = "wi2wi,w2sg0004";
+lna-supply = <>;  /* LNA regulator */
+on-off-gpio = < 17 0>;   /* GPIO_145: trigger for 
turning on/off w2sg0004 */
+uart = <>;   /* we are a slave of uart1 */
+}
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..a778eb5 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -230,6 +230,7 @@ via VIA Technologies, Inc.
 virtio Virtual I/O Device Specification, developed by the OASIS consortium
 voipac Voipac Technologies s.r.o.
 wexler Wexler
+wi2wi  Wi2Wi, Inc.
 winbond Winbond Electronics corp.
 wlfWolfson Microelectronics
 wm Wondermedia Technologies, Inc.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c29..1279faf 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -537,4 +537,22 @@ source "drivers/misc/mic/Kconfig"
 source "drivers/misc/genwqe/Kconfig"
 source "drivers/misc/echo/Kconfig"
 source "drivers/misc/cxl/Kconfig"
+
+menu "GTA04 misc hardware support"
+
+config W2SG0004
+   tristate "W2SG0004 on/off control"
+   depends on GPIOLIB
+   help
+ Enable on/off control of W2SG0004 GPS to allow powering up/down if
+ the /dev/tty$n is opened/closed.
+ It also provides a rfkill gps node to control the LNA power.
+
+config W2SG0004_DEBUG
+   bool "W2SG0004 on/off debugging"
+   depends on W2SG0004
+   help
+ Enable driver debugging mode of W2SG0004 GPS.
+
+endmenu
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3..a153a89 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -54,5 +54,6 @@ obj-$(CONFIG_SRAM)+= sram.o
 obj-y  += mic/
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
 obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index 000..6aadf44
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,443 @@
+/*
+ * w2sg0004.c
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'.  A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART da

[PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle

[H. Nikolaus Schaller]

1. add uart_ports to a search list as soon as they are registered
2. provide a function to search an uart_port by phandle. This copies the
   mechanism how devm_usb_get_phy_by_phandle() works
3. add a bindings document how serial slaves should use this feature
4. add Documentation how serla slaves work in general

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 .../devicetree/bindings/serial/slaves.txt  |  16 +++
 Documentation/serial/slaves.txt|  36 +++
 drivers/tty/serial/serial_core.c   | 107 +
 include/linux/serial_core.h|  10 ++
 4 files changed, 169 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
 create mode 100644 Documentation/serial/slaves.txt

diff --git a/Documentation/devicetree/bindings/serial/slaves.txt 
b/Documentation/devicetree/bindings/serial/slaves.txt
new file mode 100644
index 000..353b87f
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/slaves.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for UART slave devices
+
+A node describing a slave device defines a phandle to reference the UART
+the device is connected to. In the (unexpected) case of two or more UARTs
+a list of phandles can be specified.
+
+properties:
+   - uart: (list of) phandle(s) of UART(s) the device is connected to
+
+
+example:
+
+   gps {
+   compatible = "wi2wi,w2sg0004";
+   uart = <>;
+   };
diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
new file mode 100644
index 000..6f8d44d
--- /dev/null
+++ b/Documentation/serial/slaves.txt
@@ -0,0 +1,36 @@
+UART slave device support
+
+A remote device connected to a RS232 interface is usually power controlled by 
the DTR line.
+The DTR line is managed automatically by the UART driver for open() and 
close() syscalls
+and on demand by tcsetattr().
+
+With embedded devices, the serial peripheral might be directly and always 
connected to the UART
+and there might be no physical DTR line involved. Power control (on/off) has 
to be done by some
+chip specific device driver (which we call "UART slave") through some 
mechanisms (I2C, GPIOs etc.)
+not related to the serial interface. Some devices do not explicitly tell their 
power state except
+by sending or not sending data to the UART. In such a case the device driver 
must be able to monitor
+data activity. The role of the device driver is to encapsulate such power 
control in a single place.
+
+This patch series allows to support such drivers by providing:
+* a mechanism that a slave driver can identify the UART instance it is 
connected to
+* a mechanism that UART slave drivers can register to be notified
+* notfications for DTR (and other modem control) state changes
+* notifications that the UART has received some data from the UART
+
+A slave device simply adds a phandle reference to the UART it is connected to, 
e.g.
+
+   gps {
+   compatible = "wi2wi,w2sg0004";
+   uart = <>;
+   };
+
+The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart 
driver.
+This API follows the concept of devm_usb_get_phy_by_phandle().
+
+A slave device driver registers itself with serial_register_slave() to receive 
notifications.
+Notification handler callbacks can be registered by 
serial_register_mctrl_notification() and
+serial_register_rx_notification(). If an UART has registered a NULL slave or a 
NULL handler,
+no notifications are sent.
+
+RX notification handlers can define a ktermios during setup and the handler 
function can modify
+or decide to throw away each character that is passed upwards.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 603d2cc..9caa33e 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -38,6 +38,36 @@
 #include 
 #include 
 
+static LIST_HEAD(uart_list);
+static DEFINE_SPINLOCK(uart_lock);
+
+/* same concept as __of_usb_find_phy */
+static struct uart_port *__of_serial_find_uart(struct device_node *node)
+{
+   struct uart_port  *uart;
+
+   if (!of_device_is_available(node))
+   return ERR_PTR(-ENODEV);
+
+   list_for_each_entry(uart, _list, head) {
+   if (node != uart->dev->of_node)
+   continue;
+
+   return uart;
+   }
+
+   return ERR_PTR(-EPROBE_DEFER);
+}
+
+static void devm_serial_uart_release(struct device *dev, void *res)
+{
+   struct uart_port *uart = *(struct uart_port **)res;
+
+   /* FIXME: I don't understand the serial subsystem well enough
+* to know if we should call serial_put_uart(uart); here
+*/
+}
+
 /*
  * This is used to lock changes in serial line configuration.
  */
@@ -64,6 +94,79 @@ static int uart_dcd_enabled(struct uart_port *upor

[PATCH v2 2/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

From: Marek Belisko 

Code was found at:
https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1

Signed-off-by: Laxman Dewangan 
[Fixed minor typos + add channels list to documentation]
Signed-off-by: Marek Belisko 
---
 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 46 +++
 drivers/iio/adc/palmas_gpadc.c | 52 +++---
 2 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
new file mode 100644
index 000..2149afe
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
@@ -0,0 +1,46 @@
+* Palmas general purpose ADC IP block devicetree bindings
+
+Channels list:
+   0 battery type
+   1 battery temp NTC (optional current source)
+   2 GP
+   3 temp (with ext. diode, optional current source)
+   4 GP
+   5 GP
+   6 VBAT_SENSE
+   7 VCC_SENSE
+   8 Backup Battery voltage
+   9 external charger (VCHG)
+   10 VBUS
+   11 DC-DC current probe (how does this work?)
+   12 internal die temp
+   13 internal die temp
+   14 USB ID pin voltage
+   15 test network
+
+Required properties:
+- compatible : Must be "ti,palmas-gpadc".
+
+Optional sub-nodes:
+ti,channel0-current-microamp: Channel 0 current in uA.
+   Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
+ti,channel3-current-microamp: Channel 3 current in uA.
+   Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
+ti,enable-extended-delay: Enable extended delay.
+
+Example:
+
+pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   ...
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+   };
+   ...
+};
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
index 6805d81..1297c81 100644
--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -460,6 +462,34 @@ static const struct iio_chan_spec 
palmas_gpadc_iio_channel[] = {
PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
 };
 
+static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
+   struct palmas_gpadc_platform_data **gpadc_pdata)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct palmas_gpadc_platform_data *gp_data;
+   int ret;
+   u32 pval;
+
+   gp_data = devm_kzalloc(>dev, sizeof(*gp_data), GFP_KERNEL);
+   if (!gp_data)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "ti,channel0-current-microamp", );
+   if (!ret)
+   gp_data->ch0_current = pval;
+
+   ret = of_property_read_u32(np, "ti,channel3-current-microamp", );
+   if (!ret)
+   gp_data->ch3_current = pval;
+
+   gp_data->extended_delay = of_property_read_bool(np,
+   "ti,enable-extended-delay");
+
+   *gpadc_pdata = gp_data;
+
+   return 0;
+}
+
 static int palmas_gpadc_probe(struct platform_device *pdev)
 {
struct palmas_gpadc *adc;
@@ -469,12 +499,17 @@ static int palmas_gpadc_probe(struct platform_device 
*pdev)
int ret, i;
 
pdata = dev_get_platdata(pdev->dev.parent);
-   if (!pdata || !pdata->gpadc_pdata) {
-   dev_err(>dev, "No platform data\n");
-   return -ENODEV;
-   }
 
-   gpadc_pdata = pdata->gpadc_pdata;
+   if (pdata && pdata->gpadc_pdata)
+   gpadc_pdata = pdata->gpadc_pdata;
+
+   if (!gpadc_pdata && pdev->dev.of_node) {
+   ret = palmas_gpadc_get_adc_dt_data(pdev, _pdata);
+   if (ret < 0)
+   return ret;
+   }
+   if (!gpadc_pdata)
+   return -EINVAL;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*adc));
if (!indio_dev) {
@@ -790,6 +825,12 @@ static const struct dev_pm_ops palmas_pm_ops = {
palmas_gpadc_resume)
 };
 
+static const struct of_device_id of_palmas_gpadc_match_tbl[] = {
+   { .compatible = "ti,palmas-gpadc", },
+   { /* end */ }
+};
+MODULE_DEVICE_TABLE(of, of_palmas_gpadc_match_tbl);
+
 static struct platform_driver palmas_gpadc_driver = {
.probe = palmas_gpadc_probe,
.remove = palmas_gpadc_remove,
@@ -797,6 +838,7 @@ static struct platform_driver palmas_gpadc_driver = {
.name = MOD_NAME,
.owner = 

[PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
Signed-off-by: Marek Belisko <ma...@goldelico.com>
---
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 818 +
 include/linux/mfd/palmas.h |  75 ++--
 4 files changed, 879 insertions(+), 24 deletions(-)
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..05a0368 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -242,6 +242,15 @@ config NAU7802
  To compile this driver as a module, choose M here: the
  module will be called nau7802.
 
+config PALMAS_GPADC
+   tristate "TI Palmas General Purpose ADC"
+   depends on MFD_PALMAS
+   help
+ Say yes here to build support for Texas Instruments Palmas.
+
+ Palmas series pmic chip (twl6035/6037) is used in smartphones and
+ tablets and supports a 16 channel general purpose ADC.
+
 config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..716f112 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
 obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
 obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
new file mode 100644
index 000..6805d81
--- /dev/null
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -0,0 +1,818 @@
+/*
+ * palmas-adc.c -- TI PALMAS GPADC.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOD_NAME "palmas-gpadc"
+#define PALMAS_ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
+#define PALMAS_TO_BE_CALCULATED 0
+#define PALMAS_GPADC_TRIMINVALID   -1
+
+struct palmas_gpadc_info {
+/* calibration codes and regs */
+   int x1; /* lower ideal code */
+   int x2; /* higher ideal code */
+   int v1; /* expected lower volt reading */
+   int v2; /* expected higher volt reading */
+   u8 trim1_reg;   /* register number for lower trim */
+   u8 trim2_reg;   /* register number for upper trim */
+   int gain;   /* calculated from above (after reading trim regs) */
+   int offset; /* calculated from above (after reading trim regs) */
+   int gain_error; /* calculated from above (after reading trim regs) */
+   bool is_uncalibrated;   /* if channel has calibration data */
+};
+
+#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, _is_uncalibrated) 
\
+   [PALMAS_ADC_CH_##_chan] = { \
+   .x1 = _x1, \
+   .x2 = _x2, \
+   .v1 = _v1, \
+   .v2 = _v2, \
+   .gain = PALMAS_TO_BE_CALCULATED, \
+   .offset = PALMAS_TO_BE_CALCULATED, \
+   .gain_error = PALMAS_TO_BE_CALCULATED, \
+   .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
+   .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
+   .is_uncalibrated = _is_uncalibrated \
+   }
+
+static struct palmas_gpadc_info palmas_gpadc_info[] = {
+   PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
+   PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
+   PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
+   PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
+   PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, false),
+   PALMAS_ADC_INFO(IN10, 2064, 3112, 3465, 5225, 13, 14, false),
+   PALMAS_ADC_INFO(IN11, 0, 0, 0, 0, INVALID, INVALID, tr

[PATCH v2 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 arch/arm/boot/dts/omap5-uevm.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b16e8f..c78ee2f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -342,6 +342,15 @@
 
ti,ldo6-vibrator;
 
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+
regulators {
smps123_reg: smps123 {
/* VDD_OPP_MPU */
-- 
2.5.1

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

[PATCH v2 0/3] Add Palmas iio gpadc

[H. Nikolaus Schaller]

V2 changes:
- worked in review comments by Peter Meerwald
- made channels 1 and 3 report (raw) temperature values
- moved PALMAS_GPADC_TRIMINVALID to driver core
- worked in review comments by Jonathan Cameron
- iio_map removed

Add iio driver for the TI Palmas (twl6035, 6037) including device tree bindings.
It enables the gpadc for the OMAP5 uevm.

This patch series is based on original code taken from Android Tegra kernels:
(https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc)

Tegra code was developed by:
Pradeep Goudagunta <pgoudagu...@nvidia.com>
Laxman Dewangan <ldewan...@nvidia.com>

Edited and extended for mainline by:
H. Nikolaus Schaller <h...@goldelico.com>
Marek Belisko <ma...@goldelico.com>


H. Nikolaus Schaller (2):
  iio:adc: add iio driver for Palmas (twl6035/7) gpadc
  ARM: dts: omap5-uevm: enable iio gpadc for Palmas

Marek Belisko (1):
  iio:adc:palmas: add DT support

 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  46 ++
 arch/arm/boot/dts/omap5-uevm.dts   |   9 +
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 860 +
 include/linux/mfd/palmas.h |  75 +-
 6 files changed, 976 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

Am 05.10.2015 um 13:17 schrieb Mark Rutland <mark.rutl...@arm.com>:

> On Sun, Oct 04, 2015 at 06:05:59PM +0200, H. Nikolaus Schaller wrote:
>> From: Marek Belisko <ma...@goldelico.com>
>> 
>> Code was found at:
>> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
>> 
>> Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
>> [Fixed minor typos + add channels list to documentation]
>> Signed-off-by: Marek Belisko <ma...@goldelico.com>
>> ---
>> .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 46 +++
>> drivers/iio/adc/palmas_gpadc.c | 52 
>> +++---
>> 2 files changed, 93 insertions(+), 5 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
>> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> new file mode 100644
>> index 000..2149afe
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> @@ -0,0 +1,46 @@
>> +* Palmas general purpose ADC IP block devicetree bindings
>> +
>> +Channels list:
>> +0 battery type
>> +1 battery temp NTC (optional current source)
>> +2 GP
>> +3 temp (with ext. diode, optional current source)
>> +4 GP
>> +5 GP
>> +6 VBAT_SENSE
>> +7 VCC_SENSE
>> +8 Backup Battery voltage
>> +9 external charger (VCHG)
>> +10 VBUS
>> +11 DC-DC current probe (how does this work?)
>> +12 internal die temp
>> +13 internal die temp
>> +14 USB ID pin voltage
>> +15 test network
>> +
>> +Required properties:
>> +- compatible : Must be "ti,palmas-gpadc".
>> +
>> +Optional sub-nodes:
>> +ti,channel0-current-microamp: Channel 0 current in uA.
>> +Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
>> +ti,channel3-current-microamp: Channel 3 current in uA.
>> +Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
> 
> It's only possible to configure channels 0 and 3 in this manner?

Yes. The other channels have no built-in current source, i.e. these
channels are special.

> 
>> +ti,enable-extended-delay: Enable extended delay.
> 
> What is this? When would I select it? Why does it belong in the DT
> rather than being a runtime option?

The chip allows to extend the time window between channel selection
and sampling by 400µs (according to data sheet). But for all channels
and not each one. As far as I understand, this is - depending on hardware
setup - to get more stable ADC readings.

Most channels have a fixed function (e.g. battery voltage, USB VBUS,
temperature NTC) so it can't be arbitrarily chosen and depends on how
the Palmas is embedded (it is a PMIC with a bank of ADCs and not a
general purpose ADC chip).

So I think it is really a hardware dependent parameter and not something
the user should be able to change.

> 
>> +Example:
>> +
>> +pmic {
>> +compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
>> +...
>> +gpadc {
>> +compatible = "ti,palmas-gpadc";
>> +interrupts = <18 0
>> +  16 0
>> +  17 0>;
>> +ti,channel0-current-microamp = <5>;
>> +ti,channel3-current-microamp = <10>;
>> +};
>> +};
>> +...
>> +};
> 
> I thought you needed #iio-cells for encoding the channel?

Yes, we forgot (we don't have a client for it in our setup yet - so did not 
test :)

> 
> Mark.

Thanks,
Nikolaus Schaller

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

[PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
Signed-off-by: Marek Belisko <ma...@goldelico.com>
---
drivers/iio/adc/Kconfig|   9 +
drivers/iio/adc/Makefile   |   1 +
drivers/iio/adc/palmas_gpadc.c | 818 +
include/linux/mfd/palmas.h |  75 ++--
4 files changed, 879 insertions(+), 24 deletions(-)
create mode 100644 drivers/iio/adc/palmas_gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..05a0368 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -242,6 +242,15 @@ config NAU7802
  To compile this driver as a module, choose M here: the
  module will be called nau7802.

+config PALMAS_GPADC
+   tristate "TI Palmas General Purpose ADC"
+   depends on MFD_PALMAS
+   help
+ Say yes here to build support for Texas Instruments Palmas.
+
+ Palmas series pmic chip (twl6035/6037) is used in smartphones and
+ tablets and supports a 16 channel general purpose ADC.
+
config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..716f112 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
new file mode 100644
index 000..6805d81
--- /dev/null
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -0,0 +1,818 @@
+/*
+ * palmas-adc.c -- TI PALMAS GPADC.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOD_NAME "palmas-gpadc"
+#define PALMAS_ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
+#define PALMAS_TO_BE_CALCULATED 0
+#define PALMAS_GPADC_TRIMINVALID   -1
+
+struct palmas_gpadc_info {
+/* calibration codes and regs */
+   int x1; /* lower ideal code */
+   int x2; /* higher ideal code */
+   int v1; /* expected lower volt reading */
+   int v2; /* expected higher volt reading */
+   u8 trim1_reg;   /* register number for lower trim */
+   u8 trim2_reg;   /* register number for upper trim */
+   int gain;   /* calculated from above (after reading trim regs) */
+   int offset; /* calculated from above (after reading trim regs) */
+   int gain_error; /* calculated from above (after reading trim regs) */
+   bool is_uncalibrated;   /* if channel has calibration data */
+};
+
+#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, _is_uncalibrated) 
\
+   [PALMAS_ADC_CH_##_chan] = { \
+   .x1 = _x1, \
+   .x2 = _x2, \
+   .v1 = _v1, \
+   .v2 = _v2, \
+   .gain = PALMAS_TO_BE_CALCULATED, \
+   .offset = PALMAS_TO_BE_CALCULATED, \
+   .gain_error = PALMAS_TO_BE_CALCULATED, \
+   .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
+   .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
+   .is_uncalibrated = _is_uncalibrated \
+   }
+
+static struct palmas_gpadc_info palmas_gpadc_info[] = {
+   PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
+   PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
+   PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
+   PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
+   PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, false),
+   PALMAS_ADC_INFO(IN10, 2064, 3112, 3465, 5225, 13, 14, false),
+   PALMAS_ADC_INFO(IN11, 0, 0, 0, 0, INVALID, INVALID, true),
+   PA

Re: [PATCH 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

Hi,

Am 27.09.2015 um 17:21 schrieb Jonathan Cameron <ji...@kernel.org>:

> On 23/09/15 13:48, H. Nikolaus Schaller wrote:
>> This driver code was found as:
>> 
>> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
>> 
>> Fixed various compilation issues and test this driver on omap5 evm.
>> 
>> Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> Signed-off-by: Marek Belisko <ma...@goldelico.com>
> Various bits inline.

thanks for the valuable comments!

Will work into V2.

Nikolaus

> 
> Jonathan
>> ---
>> drivers/iio/adc/Kconfig|   9 +
>> drivers/iio/adc/Makefile   |   1 +
>> drivers/iio/adc/palmas_gpadc.c | 797 
>> +
>> include/linux/mfd/palmas.h |  59 ++-
>> 4 files changed, 862 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/iio/adc/palmas_gpadc.c
>> 
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index eb0cd89..f6df9db 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -242,6 +242,15 @@ config NAU7802
>>To compile this driver as a module, choose M here: the
>>module will be called nau7802.
>> 
>> +config PALMAS_GPADC
>> +tristate "TI Palmas General Purpose ADC"
>> +depends on MFD_PALMAS
>> +help
>> +  Palmas series pmic chip by texas Instruments (twl6035/6037)
>> +  is used in smartphones and tablets and supports a 16 channel
>> +  general purpose ADC. Add iio driver to read different channel
>> +  of the GPADCs.
>> +
>> config QCOM_SPMI_IADC
>>  tristate "Qualcomm SPMI PMIC current ADC"
>>  depends on SPMI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index a096210..716f112 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>> obj-$(CONFIG_MCP3422) += mcp3422.o
>> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>> obj-$(CONFIG_NAU7802) += nau7802.o
>> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
>> new file mode 100644
>> index 000..17abb28
>> --- /dev/null
>> +++ b/drivers/iio/adc/palmas_gpadc.c
>> @@ -0,0 +1,797 @@
>> +/*
>> + * palmas-adc.c -- TI PALMAS GPADC.
>> + *
>> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
>> + *
>> + * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MOD_NAME "palmas-gpadc"
>> +#define ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
>> +#define TO_BE_CALCULATED 0
>> +
>> +struct palmas_gpadc_info {
>> +/* calibration codes and regs */
> Full docs on this would be appreciated.
>> +int x1;
>> +int x2;
>> +int v1;
>> +int v2;
>> +u8 trim1_reg;
>> +u8 trim2_reg;
>> +int gain;
>> +int offset;
>> +int gain_error;
>> +bool is_correct_code;
>> +};
>> +
>> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
>> _is_correct_code)\
>> +[PALMAS_ADC_CH_##_chan] = { \
>> +.x1 = _x1,  \
>> +.x2 = _x2,  \
>> +.v1 = _v1,  \
>> +.v2 = _v2,  \
>> +.gain = TO_BE_CALCULATED,   \
>> +.offset = TO_BE_CALCULATED, \
>> +.gain_error = TO_BE_CALCULATED, \
>> +

Re: [PATCH] gpio:pca953x: add mechanism to simulate open drain outputs

[H. Nikolaus Schaller]

Am 25.09.2015 um 00:11 schrieb Linus Walleij <linus.wall...@linaro.org>:

> On Wed, Sep 23, 2015 at 11:13 AM, H. Nikolaus Schaller
> <h...@goldelico.com> wrote:
> 
>> 1. add a DT property to specify the list of GPIO pins that are to become
>>   "open drain"
>> 2. if a pin is configured as "open drain", set value by either outputting a
>>   "0" (low level) or switching to input (high impedance)
>> 
>> Tested on OMAP5 uEVM with TCA6424 and some LEDs connected to 5V.
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> 
> I understand the approach, but this is the wrong way to do it.
> Instead of indicating that a pin on the pin controller should be
> open drain, the *consumer* specifying its gpios = <> should
> do this.

On a second thought I am no longer sure if that is the right approach.

A gpio is for input and output of “0” and “1” values. And a gpio consumer
can control if the output should be active or inactive and input.

How the output is physically represented (totem-pole or single-ended,
high power, low power etc.) is not a property of the gpio itself and
there is IMHO no need for the consumer to be able to define (or change)
it.

On SoC with integrated gpio controllers it is very common to have
pinmux definitions completely separated from the gpio controller
properties. But the gpio consumer can connect to pinctrl settings
to describe that the pin should have certain physical properties.

There, it is common to be able to enable/disable pull-up/downs as
well.

So turning a totem-pole output (as it is available in the tca6424)
into an open-drain output is sort of turning off the pull-up transistor.
I.e. comparable to a pinmux setting.

So such controllers should get the option to define pinctrl.

Some chips might have special control registers for doing that
while others need the trick to switch between input and output
mode but that is driver implementation detail.

But I am not sure if this has other implications.

> 
> I just sent a patch adding the bindings because Tony Lindgren
> and Grygorii Strashko approached me similar problems so let's
> begin with the bindings.
> 
> Implementing it in the kernel requires some elaboration and it's
> going to be more complicated than this local approach, but it
> will be more generic and reusable so that is what we need to do.
> 
> Yours,
> Linus Walleij

BR,
Nikolaus Schaller--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

Am 23.09.2015 um 15:26 schrieb Peter Meerwald <pme...@pmeerw.net>:

> 
>> This driver code was found as:
>> 
>> https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc
>> 
>> Fixed various compilation issues and test this driver on omap5 evm.
> 
> several minor comments below

thanks!
I have worked in for a V2 but will wait a little for further comments until I 
post it.

> probably the mfd part should be split out in a separate patch

well, I think those changes should stay bundled in a single patch
since they depend on each other.

> 
>> Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> Signed-off-by: Marek Belisko <ma...@goldelico.com>
>> ---
>> drivers/iio/adc/Kconfig|   9 +
>> drivers/iio/adc/Makefile   |   1 +
>> drivers/iio/adc/palmas_gpadc.c | 797 
>> +
>> include/linux/mfd/palmas.h |  59 ++-
>> 4 files changed, 862 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/iio/adc/palmas_gpadc.c
>> 
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index eb0cd89..f6df9db 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -242,6 +242,15 @@ config NAU7802
>>To compile this driver as a module, choose M here: the
>>module will be called nau7802.
>> 
>> +config PALMAS_GPADC
>> +tristate "TI Palmas General Purpose ADC"
>> +depends on MFD_PALMAS
>> +help
>> +  Palmas series pmic chip by texas Instruments (twl6035/6037)
>> +  is used in smartphones and tablets and supports a 16 channel
>> +  general purpose ADC. Add iio driver to read different channel
>> +  of the GPADCs.
> 
> PMIC
> _T_exas
> 
> drop meaningless "Add iio driver to read different channel of the GPADCs."
> 
>> +
>> config QCOM_SPMI_IADC
>>  tristate "Qualcomm SPMI PMIC current ADC"
>>  depends on SPMI
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index a096210..716f112 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>> obj-$(CONFIG_MCP3422) += mcp3422.o
>> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>> obj-$(CONFIG_NAU7802) += nau7802.o
>> +obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>> obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
>> new file mode 100644
>> index 000..17abb28
>> --- /dev/null
>> +++ b/drivers/iio/adc/palmas_gpadc.c
>> @@ -0,0 +1,797 @@
>> +/*
>> + * palmas-adc.c -- TI PALMAS GPADC.
>> + *
>> + * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
>> + *
>> + * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
>> + */
> 
> newline
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MOD_NAME "palmas-gpadc"
>> +#define ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
>> +#define TO_BE_CALCULATED 0
> 
> add prefix PALMAS_
> 
>> +
>> +struct palmas_gpadc_info {
>> +/* calibration codes and regs */
>> +int x1;
>> +int x2;
>> +int v1;
>> +int v2;
>> +u8 trim1_reg;
>> +u8 trim2_reg;
>> +int gain;
>> +int offset;
>> +int gain_error;
>> +bool is_correct_code;
>> +};
>> +
>> +#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, 
>> _is_correct_code)\
> 
> whitespace and indentation
> 
>> +[PALMAS_ADC_CH_##_chan] = { \
>> +.x1 = _x1,  \
>> +.x2 = _x2,  \
>> +.v1 = _v1,  \
>>

Re: [PATCH] gpio:pca953x: add mechanism to simulate open drain outputs

[H. Nikolaus Schaller]

Am 25.09.2015 um 00:11 schrieb Linus Walleij <linus.wall...@linaro.org>:

> On Wed, Sep 23, 2015 at 11:13 AM, H. Nikolaus Schaller
> <h...@goldelico.com> wrote:
> 
>> 1. add a DT property to specify the list of GPIO pins that are to become
>>   "open drain"
>> 2. if a pin is configured as "open drain", set value by either outputting a
>>   "0" (low level) or switching to input (high impedance)
>> 
>> Tested on OMAP5 uEVM with TCA6424 and some LEDs connected to 5V.
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> 
> I understand the approach, but this is the wrong way to do it.
> Instead of indicating that a pin on the pin controller should be
> open drain, the *consumer* specifying its gpios = <> should
> do this.
> 
> I just sent a patch adding the bindings because Tony Lindgren
> and Grygorii Strashko approached me similar problems so let's
> begin with the bindings.
> 
> Implementing it in the kernel requires some elaboration and it's
> going to be more complicated than this local approach, but it
> will be more generic and reusable so that is what we need to do.

Ok, I understand.

Should not be too difficult to modify the driver.

BR,
Nikolaus Schaller


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

[PATCH 2/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

From: Marek Belisko 

Code was found at:
https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1

Signed-off-by: Laxman Dewangan 
[Fixed minor typos + add channels list to documentation]
Signed-off-by: Marek Belisko 
---
.../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  67 +++
drivers/iio/adc/palmas_gpadc.c | 130 +
2 files changed, 175 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
new file mode 100644
index 000..a5a33ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
@@ -0,0 +1,67 @@
+* Palmas general purpose ADC IP block devicetree bindings
+
+Channels list:
+   0 battery type
+1 battery temp NTC
+   2 GP
+   3 temp (with ext. diode)
+   4 GP
+   5 GP
+   6 VBAT_SENSE
+   7 VCC_SENSE
+   8 Backup Battery voltage
+   9 external charger (VCHG)
+   10 VBUS
+   11 DC-DC current probe (how does this work?)
+   12 internal die temp
+   13 internal die temp
+   14 USB ID pin voltage
+   15 test network
+
+Required properties:
+- compatible : Must be "ti,palmas-gpadc".
+
+Optional sub-nodes:
+ti,channel0-current-microamp: Channel 0 current in uA.
+   Valid values 0uA, 5uA, 15uA, 20uA.
+ti,channel3-current-microamp: Channel 3 current in uA.
+   Valid value 0uA, 10uA, 400uA, 800uA.
+ti,enable-channel3-dual-current: Enable dual current on channel 3.
+ti,enable-extended-delay: Enable extended delay.
+
+Optional sub-node:
+The Palmas ADC node has optional subnode to define the iio mapping.
+It is the name with "iio_map". This node has again subnode to define
+the property of the channel. The sub subnode has following properties:
+- ti,adc-channel-number: ADC channel number.
+- ti,adc-consumer-device: Consumer device name.
+- ti,adc-consumer-channel: ADC consumer channel name.
+
+Example:
+
+pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   ...
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   iio_map {
+   ch1 {
+   ti,adc-channel-number = <1>;
+   ti,adc-consumer-device = 
"generic-adc-thermal.0";
+   ti,adc-consumer-channel ="battery-temp-channel";
+   };
+
+   ch6 {
+   ti,adc-channel-number = <6>;
+   ti,adc-consumer-device = "palmas-battery";
+   ti,adc-consumer-channel ="vbat_channel";
+   };
+   };
+   };
+   ...
+};
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
index 17abb28..bc4db43 100644
--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -20,6 +20,8 @@
#include 
#include 
#include 
+#include 
+#include 
#include 
#include 
#include 
@@ -434,20 +436,97 @@ static const struct iio_chan_spec 
palmas_gpadc_iio_channel[] = {
PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE),
};

+static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
+   struct palmas_gpadc_platform_data **gpadc_pdata)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct palmas_gpadc_platform_data *gp_data;
+   struct device_node *map_node;
+   struct device_node *child;
+   struct iio_map *palmas_iio_map;
+   int ret;
+   u32 pval;
+   int nmap, nvalid_map;
+
+   gp_data = devm_kzalloc(>dev, sizeof(*gp_data), GFP_KERNEL);
+   if (!gp_data)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "ti,channel0-current-microamp", );
+   if (!ret)
+   gp_data->ch0_current = pval;
+
+   ret = of_property_read_u32(np, "ti,channel3-current-microamp", );
+   if (!ret)
+   gp_data->ch3_current = pval;
+
+   gp_data->extended_delay = of_property_read_bool(np,
+   "ti,enable-extended-delay");
+
+   map_node = of_get_child_by_name(np, "iio_map");
+   if (!map_node) {
+   dev_warn(>dev, "IIO map table not found\n");
+   goto done;
+   }
+
+   nmap = of_get_child_count(map_node);
+   if (!nmap)
+   goto done;
+
+   nmap++;
+   palmas_iio_map = devm_kzalloc(>dev,
+   sizeof(*palmas_iio_map) * nmap, GFP_KERNEL);
+   if (!palmas_iio_map)
+   goto done;
+
+   

[PATCH 0/3] Add Palmas iio gpadc

[H. Nikolaus Schaller]

Add iio driver for the TI Palmas (twl6035, 6037) including device tree bindings.
It enables the gpadc for the OMAP5 uevm.

This patch series is based on original code taken from Android Tegra kernels:
(https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc)

Tegra code was developed by:
Pradeep Goudagunta <pgoudagu...@nvidia.com>
Laxman Dewangan <ldewan...@nvidia.com>

Edited and extended for mainline by:
H. Nikolaus Schaller <h...@goldelico.com>
Marek Belisko <ma...@goldelico.com>



H. Nikolaus Schaller (2):
 iio:adc: add iio driver for Palmas (twl6035/7) gpadc
 ARM: dts: omap5-uevm: enable iio gpadc for Palmas

Marek Belisko (1):
 iio:adc:palmas: add DT support

.../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  67 ++
arch/arm/boot/dts/omap5-uevm.dts   |  22 +
drivers/iio/adc/Kconfig|   9 +
drivers/iio/adc/Makefile   |   1 +
drivers/iio/adc/palmas_gpadc.c | 883 +
include/linux/mfd/palmas.h |  59 +-
6 files changed, 1037 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
create mode 100644 drivers/iio/adc/palmas_gpadc.c

-- 
2.5.1

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

[PATCH 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
arch/arm/boot/dts/omap5-uevm.dts | 22 ++
1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b16e8f..0d4c8ff 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -342,6 +342,28 @@

ti,ldo6-vibrator;

+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   iio_map {
+   ch1 {
+   ti,adc-channel-number = <1>;
+   ti,adc-consumer-device = 
"generic-adc-thermal.0";
+   ti,adc-consumer-channel 
="battery-temp-channel";
+   };
+
+   ch6 {
+   ti,adc-channel-number = <6>;
+   ti,adc-consumer-device = 
"palmas-battery";
+   ti,adc-consumer-channel 
="vbat_channel";
+   };
+   };
+   };
+
regulators {
smps123_reg: smps123 {
/* VDD_OPP_MPU */
-- 
2.5.1

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

[PATCH 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com>
Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
Signed-off-by: Marek Belisko <ma...@goldelico.com>
---
drivers/iio/adc/Kconfig|   9 +
drivers/iio/adc/Makefile   |   1 +
drivers/iio/adc/palmas_gpadc.c | 797 +
include/linux/mfd/palmas.h |  59 ++-
4 files changed, 862 insertions(+), 4 deletions(-)
create mode 100644 drivers/iio/adc/palmas_gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..f6df9db 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -242,6 +242,15 @@ config NAU7802
  To compile this driver as a module, choose M here: the
  module will be called nau7802.

+config PALMAS_GPADC
+   tristate "TI Palmas General Purpose ADC"
+   depends on MFD_PALMAS
+   help
+ Palmas series pmic chip by texas Instruments (twl6035/6037)
+ is used in smartphones and tablets and supports a 16 channel
+ general purpose ADC. Add iio driver to read different channel
+ of the GPADCs.
+
config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..716f112 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
new file mode 100644
index 000..17abb28
--- /dev/null
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -0,0 +1,797 @@
+/*
+ * palmas-adc.c -- TI PALMAS GPADC.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Author: Pradeep Goudagunta <pgoudagu...@nvidia.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 version 2.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOD_NAME "palmas-gpadc"
+#define ADC_CONVERSION_TIMEOUT (msecs_to_jiffies(5000))
+#define TO_BE_CALCULATED 0
+
+struct palmas_gpadc_info {
+/* calibration codes and regs */
+   int x1;
+   int x2;
+   int v1;
+   int v2;
+   u8 trim1_reg;
+   u8 trim2_reg;
+   int gain;
+   int offset;
+   int gain_error;
+   bool is_correct_code;
+};
+
+#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, _is_correct_code)\
+[PALMAS_ADC_CH_##_chan] = {\
+   .x1 = _x1,  \
+   .x2 = _x2,  \
+   .v1 = _v1,  \
+   .v2 = _v2,  \
+   .gain = TO_BE_CALCULATED,   \
+   .offset = TO_BE_CALCULATED, \
+   .gain_error = TO_BE_CALCULATED, \
+   .trim1_reg = PALMAS_GPADC_TRIM##_t1,\
+   .trim2_reg = PALMAS_GPADC_TRIM##_t2,\
+   .is_correct_code = _is_correct_code \
+   }
+
+static struct palmas_gpadc_info palmas_gpadc_info[] = {
+   PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
+   PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
+   PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
+   PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
+   PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, false),
+   PALMAS_ADC_INFO(IN10, 2064, 3112, 3465, 5225, 13, 14, false),
+   PALMAS_ADC_INFO(IN11, 0, 0, 0, 0, INVALID, INVALID, true),
+   PALMAS_ADC_INFO(IN12, 0, 0, 0, 0, INVALID, INVALID, true),
+   PALMAS_ADC_INFO(IN13, 0, 0, 0, 0, INVALID, INVALID,

Re: [PATCH 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Hi,

Am 23.09.2015 um 18:56 schrieb Tony Lindgren <t...@atomide.com>:

> * H. Nikolaus Schaller <h...@goldelico.com> [150923 05:53]:
> 
> Missing description?

well, description is “ARM: dts: omap5-uevm: enable iio gpadc for Palmas"

and I didn’t catch that the commit is otherwise empty. Sorry.

> BTW, this I want to queue separately
> as I have patches in works to support omap5 variants with
> omap5-board-common.dtsi to avoid duplicating things as
> we get omap5 better supported for things like regulators.

Yes, it should work for all Palmas based OMAP5 boards and a 
omap5-board-common.dtsi would be the right place (after
it comes to existence).

> 
> Regards,
> 
> Tony
> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap5-uevm.dts | 22 ++
>> 1 file changed, 22 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts 
>> b/arch/arm/boot/dts/omap5-uevm.dts
>> index 3b16e8f..0d4c8ff 100644
>> --- a/arch/arm/boot/dts/omap5-uevm.dts
>> +++ b/arch/arm/boot/dts/omap5-uevm.dts
>> @@ -342,6 +342,28 @@
>> 
>>  ti,ldo6-vibrator;
>> 
>> +gpadc {
>> +compatible = "ti,palmas-gpadc";
>> +interrupts = <18 0
>> +  16 0
>> +  17 0>;
>> +ti,channel0-current-microamp = <5>;
>> +ti,channel3-current-microamp = <10>;
>> +iio_map {
>> +ch1 {
>> +ti,adc-channel-number = <1>;
>> +ti,adc-consumer-device = 
>> "generic-adc-thermal.0";
>> +ti,adc-consumer-channel 
>> ="battery-temp-channel";
>> +};
>> +
>> +ch6 {
>> +ti,adc-channel-number = <6>;
>> +ti,adc-consumer-device = 
>> "palmas-battery";
>> +ti,adc-consumer-channel 
>> ="vbat_channel";
>> +};
>> +};
>> +};
>> +
>>  regulators {
>>  smps123_reg: smps123 {
>>  /* VDD_OPP_MPU */
>> -- 
>> 2.5.1
>> 

BR,
Nikolaus

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

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 28.08.2015 um 09:02 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 we (the developers of the hardware) have proposed an alternative
 approach to Neil’s implementation - for the same device and solving
 the same problem (notifying tty open/close and uart activity to the
 slave device driver), but differently.
 
 See:
 https://lkml.org/lkml/2015/6/28/91
 
 Discussion has not yet settled on which approach is better. So your
 opinion of comparing both is welcome.
 
 Actually, yes, discussion has settled, agreeing that phandle reference
 for the uart is a bad idea, Nikolaus just refuses to listen to anyone,

no, I only refuse to listen to you.

You are neither maintainer for any subsystem that is involved nor have
you contributed technical arguments pro/con and it appears to me that
you refuse to listen to my argumentation.

 asking device tree maintainer opinion, and then just simply ignoring
 it when he does not like it, and then making promises he did not keep.


Which promises did I not keep? Please be specific, instead of insulting.

I bring up this alternative again, since I get the impression that most readers
are simply not aware of *both* alternative proposals.

 Please don't stall patches just because of that.

Please provide better arguments and don’t spread FUD.

Please have a look into our RFC implementation and study it carefully
to learn why it is the better (IMHO more flexible, easier to maintain, more
modular) approach. Even if you don’t like phandles.

 
 Best regards,
   Pavel
 -- 
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


BR,
Nikolaus

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

Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[Dr. H. Nikolaus Schaller]

Hi Linus,

Am 12.08.2015 um 01:20 schrieb NeilBrown n...@brown.name:

 On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
 linus.wall...@linaro.org wrote:
 
 Hi Neil,
 
 first, this is a *VERY* interesting and much needed patch series,
 I intend to look closer at it, and if possible test it with some
 (heh) board file device. Would be happy of you put me on CC for these.
 
 On Mon, May 11, 2015 at 3:56 AM, NeilBrown n...@brown.name wrote:
 
 When a device is connected to a UART via RS-232 (or similar), there
 is a DTR line that can be used for power management, and other modem
 control lines.
 
 On an embedded board, it is very likely that there is no DTR, and
 any power management need to be done using some completely separate
 mechanism.
 
 So these slaves are really just for devices permanently attached to
 UARTs without a full RS-232 (or similar) connection.  The driver
 does all the extra control beyond Tx/Rx.
 
 What is usually happening (and I have seen it in a few places) is that
 the SoC has *one* fully featured RS232 with CTS/RTS and even
 DTS,DCD,RI and other esoterica, which is intended to be connected to a
 host serial port or so, for example if this SoC is to act as a modem
 or a fax machine, or if it is to drive one.
 
 Then they often have a few more UART blocks, usually identical, which
 only have RxD+TxD available, so they are just UARTs.
 
 To complicate things further, you may wonder what happened with
 the CTS/RTS (etc) signals from the other blocks. Usually they are there
 in the silicon but just routed to dead ends.
 
 To complicate it even further, usually all these pins are placed under
 pin control multiplexing, so in an actual electronic design, the
 system will mux out CTS/RTS (etc) from the fully featured RS232
 blocks and only use them as UARTs anyways.
 
 Then there are those who created real simple RxD/TxD-only UARTs
 (yeah lets dump this RS232 legacy crap / yeah yeah)
 and then realized they want to drive modems (oh crap, it seemed
 like a good idea at the time). Then they usually take
 two GPIO pins for CTS/RTS and drive them as GPIOs using
 software and you have a cheap 4-line modem line. This is what
 drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
 
 I've tested this set and it seems to work ... except that something
 is sadly broken with bluetooth support in 4.1-rc1 so I've only really
 tested the GPS driver.  I guess it is time to rebase to -rc3.
 
 You have a hardware taget I see. Which one?
 
 GTA04 (www.gta04.org - openmoko successor).
 
 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
 half of a wifi/bluetooth module, and one to a GPS.
 
 For the GPS, I just want to power on/off when the TTY is opened/closed,
 but the power-on sequence is non-trivial as both turn on and
 turn-off' toggle the same line, so I need to be able to detect current
 state.
 
 For the bluetooth, the power is a (shared) regulator.  As well as
 power-on when the TTY is opened, I'd like regulator to be turned of
 when I hciconfig down - even though the TTY is still open.
 I did a patch a while ago which hooked in to hci_uart_{open,close} to
 make this work, but it isn't a really good patch.
 
 It would be nice to hide the TTY from user-space in the bluetooth case,
 and have the hciattach happen in the kernel, but I think hciattach
 does extra initialisation...
 
 NeilBrown


we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.

See:
https://lkml.org/lkml/2015/6/28/91

Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.

BR,
Nikolaus


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

[PATCH RFC 0/3] UART slave device support

[Dr. H. Nikolaus Schaller]

Hi all,
this patch series is our proposal to add hooks so that the driver for a device 
connected to an UART can
monitor modem control lines and data activity of the connected chip.

It contains an example for such a device driver which needs such sophisticated 
power control: wi2wi,w2sg0004

A remote device connected to a RS232 interface is usually power controlled by 
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close() 
syscalls
and on demand by tcsetattr().

With embedded devices, the serial peripheral might be directly and always 
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to 
be done by some
chip specific device driver (which we call UART slave) through some 
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state 
except by sending
or not sending data to the UART. In such a case the device driver must be able 
to monitor data
activity. The role of the device driver is to encapsulate such power control in 
a single place.

This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is 
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART

A slave device tree entry simply adds a phandle reference to the UART it is 
connected to, e.g.

gps {
compatible = wi2wi,w2sg0004;
uart = uart1;
};

The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart 
driver.
devm_serial_get_uart_by_phandle() follows the concept of 
devm_usb_get_phy_by_phandle().

A slave device driver registers itself with serial_register_slave() to receive 
notifications.
Notification handlers can be registered by serial_register_mctrl_notification() 
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL 
handler registered,
no notifications are sent.

RX notification handlers can define a ktermios setup and modify or decide to 
throw away the
character that is passed upwards.

This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want 
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself 
as a virtual
GPIO. The idea of a virtual GPIO  is not compatible with the concept that DT 
must
describe hardware (and not virtual hardware). So in this new solution DT only 
describes that
the w2sg0004 is connected to some UART and how the power state signalling works 
is left
to the driver implementations.

The rx data notification also removes the concept of having two different 
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line 
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might 
even be
extensible that the chip driver could filter or consume the rx data before it 
is passed
to the tty layer.

This patch works on linux-next as intended except one major weakness: we have 
to call 
uart_change_speed() each time we open the tty. This is the opposite of what we 
would like
to have: that the slave initializes the uart speed through some termios and the 
tty level just uses
this setting. We have not yet completely understood how to make this work and 
are happy
about help in this area.

And of course we would like to see general comments about the whole 
implementation
approach.


Signed-off-by: H. Nikolaus Schaller h...@goldelico.com


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

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 06.05.2015 um 11:27 schrieb Pavel Machek pa...@ucw.cz:

 On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
 Hi Peter,
 
 Am 05.05.2015 um 21:54 schrieb Peter Hurley pe...@hurleysoftware.com:
 
 Hi Neil,
 
 On 03/18/2015 01:58 AM, NeilBrown wrote:
 here is version 3 of support for tty-slaves.
 
 Is there a v4 of this that I missed?
 
 We did have a lengthy discussion about [PATCH 3/3] how to best (1)
 represent the slave device in the device tree but as far as I am concerned,
 I do not see that we have a consensus (2) and the device tree maintainers
 have no comments or clear guidelines so far.
 
 Yes. Everyone and their dog disagrees

What a wonderful argument…
I still ask myself who the dog is.

 with Nikolaus, who is playing
 devil's advocate

I hope you don't think that Linux users are devils…

No, I am not playing devil’s advocate (which would imply that I am doing this
for fun to tease the dog), but I feel I have to be the advocate of future board
designers who want to easily import an existing board DT and overwrite device
tree nodes to describe design changes, i.e. what slave device is connected to
which uart.

At least in this regard, the alternatives are really differently easy to handle.

And, the alternatives have some influence how a tty driver and a slave device
driver is designed. So that is for me the root question, before discussing 
(some)
implementation details.

Because it is not resolved in a way that convinces me (and future board DT
designers), I bring it up again and again. Even if you and some dog apparently
disagree.

 here, so we clearly have to get confirmation from
 device tree maintainers. And when they disagree with him, we'll need
 to get concensus from Linus, too...
   Pavel

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

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 27.04.2015 um 22:35 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 In my opinion making something a node in / is always the
 last resort and in my perspective it has been handled in such a way
 so far.
 
 But that contradicts some documents I have found and linked. Please
 show me a document about DT that supports your view.
 
 I agree that both views can be valid, but in lack of some ?official? 
 guideline
 we can?t decide ourselves.
 
 This is not how kernel development works.
 
 We can decide ourselves, and DT people will swear at us if we decide wrongly,
 and then Linus swears at them if they do too obvious mistakes.
 
 Lets KISS.

some time ago you also wrote in this thread:

 Device tree is not operating system specific. 

In other words: this is a discussion about compatibility with the world outside 
of Linux.
And compatibility can not be achieved by decisions about Linux implementation 
details,
even if Linus is deciding. He can just decide to stay incompatible (but then it 
should
IMHO be a general decision and not case specific).

So I think we should follow some basic design principles, if they exist (which 
I don’t know),
to have this compatibility. And then adapt the Linux implementation (using the 
KISS principle).

Anyways I have not yet seen any comment from the DT people or did I miss them?

BR,
Nikolaus

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

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 04.04.2015 um 10:16 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 Please propose your own code doing that so that we can test if it is
 better.
 
 So, how does this look?
 
 It looks to me like you have cca 0.1 Ohm resistance in your system,
 
 This is completely unknown.
 
 and are using cca 75mA while discharging, and charge by cca 1.4A.
 
 Where do you get these figures from?
 
 Least squares fitting of my coefficients to your tables.

Ah, I see.

 
 A GTA04 board discharges usually between 50 and 400 mA (depending on 
 activities)
 and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw 
 even more
 during operation.
 
 How big battery do you have?

1200 mAh

 According to least squares fitting,
 assuming maximum charge of .46A, you were taking about 25mA when
 doing the discharge test.

No, that can’t fit well. But I do not remember who has done this calibration in 
which situation
because it was done many months ago for the platform data version. We have just 
reformatted
the table for the DT.

 
 Total current going in is 500-800 mA (depending on USB negotiations) and 
 this is
 split into system operation and charging current. So 1.4A charging current 
 is not
 possible. Rather 200-500 mA.
 
 So it might be that the battery is discharged although the system is 
 connected
 to a charger.
 
 Yah, and your battery meter will be wrong in such case, as will be
 mine, because they are based on same information.

Well, it is not “mine”, it is the platform_data based driver already in 
kernel.org
since ca. 3.12.

We have just updated it to DT to get rid of platform_data in this area as well…

Yes, I see your argument that hiding the tables (two characteristic curves)
into an analytic approximation can be superior. 

The problem I see is just that your formula needs some parameters which
are difficult to derive or estimate. And must be adjusted to the specific
battery and system setup in a non-trivial way.

At least we must supply a tool (in the kernel/scripts directory?) where someone
can can estimate the parameters of the formula from the characteristic curves.

Maybe a tool that automatically runs several charge/discharge cycles at
different system load. And measures time vs. voltage. And assumes a linear
capacity decrease between the end points. (i.e. if it needs 10 hours to charge
from completely empty to full, we can assume 50% after 5,0 hours).

So my goal is to measure all characteristics of the battery - and no need to
study a (potentially non-existing) data sheet.

If you can provide that for all parameters of your algorithm I am fine with it.

 The thing is, mine
 can be improved without adding more tables. 

How can you improve your algorithm without tweaking or adding new parameters?

 
 It is tricky to do a good job near 0%... or anywhere else. See for
 example
 
 http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf
 
 You start a call, percentage goes down, end a call, it will go
 back up. I'm pretty sure you will not be able to make a call with 5%
 indication from your code at low battery temperature (say -10C).
 
 The whole system is heating up a little, so that you never have -10C for the
 battery.
 
 Umm. When not calling, your phone should not heat itself up.

Yes, in suspend it needs 20 mA which does not heat or course.
But steady operation at 20-400 mA does significantly rise OMAP
temperature beyond environment temperature.

 And you
 definitely can power it down, leave it in outer pocket, then power it
 up. It is actually something people do when they want to preserve battery...
 
 I think you are trying to solve situations that don’t exist in practice.
 
 And AFAIK, the GTA04 board is the only user of this driver in case the 
 battery
 has no built-in fuel gauge. So why improve it beyond what the GTA04
 users need?
 
 Because then other users can share the same code, and because you

But you have ugly parameters in dts that nobody can easily see in the schematics
and that are full of assumptions.

From a perspective of uncertainty analysis, estimation of the internal 
parameters
needs a higher precision than the calibration points.

 avoid big ugly tables in dts.

Well, the biggest tables I have seen in dts are keyboard matrix codes…

 
 I repeat myself: this driver is not built for highest precision because 
 there are
 better methods (fuel gauge chip). These might not be available so this 
 fall-back
 driver has been built.
 
 It is definitively better than no driver and worse than the optimum.
 
 And my email suggested solution better than your driver, so why not
 just use it?

I am not yet convinced that it is better.

It just moves the (unavoidable) limitations (measuring multiple calibration 
points)
just to a different area (measuring the hidden and not precisely known parameter
of the system).

 
 
 #perc = percent(volt)
 compute(charging, 1)
 compute(discharging, 0)
 
 Please explain what you calculate here. Especially what “Badness” is?
 
 

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 31.03.2015 um 09:26 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 + io-channels = twl_madc 1,
 +   twl_madc 10,
 +   twl_madc 12;
 + io-channel-names = temp,
 +ichg,
 +vbat;
 + };
 
 Rather than just making platform_data into device tree properties..
 
 Can't you hide the these custom properties behind the compatible flag?
 
 You can initialize that data in the driver based on the compatible
 flag and the match data.
 
 This makes sense if you can group things to similar configurations.
 
 Maybe I have not completely understood your proposal.
 
 Do you mean to go back to have big parameter tables for each device/battery
 combination in the driver code and the compatible flag (e.g. compatible = 
 “board17”)
 chooses the right data set for the charging map and channels?
 
 If you can somehow group them, then yes. Not for every board if there
 are many of them naturally.
 
 I thought this is what the DT was introduced for - to have the same driver 
 code but adapt to different boards depending on hardware variations.
 
 Yeah but you also need to consider the issues related to introducing
 new device tree properties. The device tree properties introduced
 should be generic where possible.
 
 And batteries have very different characteristics and vary between devices…
 
 Right. Maybe that has been already agreed on to use capacity-uah for
 batteries in general? In that case I have not problem with that as
 it's a generic property :)
 
 The charging maps are depending on the battery type connected to the twl4030
 and which madc channel is which value is also a little hardware dependent
 (although the twl4030 doesn’t give much choice).
 
 Just to consider alternatives before introducing driver specific
 property for the maps.. Maybe here you could have few different type
 of maps and select something safe by default? Of course it could be this
 is higly board specific, I think some devices may be able to run below
 3.3V for example..
 
 As I explained in some other mail, those tables should not be
 neccessary at all. They can be computed from li-ion characteristics
 and internal resistance, and assumed current during charge and
 discharge.

I already explained that we do not know the charging and discharging
current well enough for such a calculation.

And I explained that the “internal resistance” is a system (battery + cables +
connectors + other circuits) parameter that is not easy to derive or measure
and type into the .dts source code.

At least I have no idea how I should find it out for my boards. While I can
easily determine the curves (and we already have them for the platform_data
driver).

Please propose your own code doing that so that we can test if it is
better.

 
 Running below 3.3V.. not really. At that point, the battery is really
 _empty_, and voltage is going down really really fast.

It is the diffference between 2% and 0% where a fuel indication might
be most important…

 
 Plus, you are damaging the battery at that point.

The power controller will shut down - but the driver should report
reasonable (but IMHO not necessarily perfect) values until the last
moment.

BR,
Nikolaus

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

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 01.04.2015 um 18:30 schrieb Rob Herring robherri...@gmail.com:

 On Tue, Mar 10, 2015 at 4:27 PM, Marek Belisko ma...@goldelico.com wrote:
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
 .../bindings/power_supply/twl4030_madc_battery.txt | 43 
 ++
 1 file changed, 43 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..d3dd9d8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery
 
 Is this a sub-node of the twl4030 or something? Please define where
 this fits (hint: I would expect to be a sub node of a charging
 controller or battery monitor).

It is a driver connecting some battery parameters with measurements provided
by the twl4030-madc to present a /sys/class/power_supply node for the battery
with a coarse estimate for the charging level.

So maybe the best wording is that it is a battery-driver assuming a twl4030-madc
providing raw measurements (voltage, charging).

Therefore it could as well be battery-twl4030-madc.

 
 + - capacity-uah : battery capacity in uAh
 + - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
 +   for charging calibration (see example)
 + - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
 +   for discharging calibration (see example)
 
 These seem like properties of the battery independent of the
 battery/charging controller which is the twl4030. Ideally we would
 define battery nodes generically and independent of the charge
 controllers. Then there are smart batteries to consider too.

For smart batteries there are completely independent mechanisms
like I2C and HDQ/1-wire communication with fuel gauge chips (e.g. b27xxx).

Those do not need such battery properties because they are stored
in EEPROMs within these chips.

So all this is a quite special solution just for those handful of board that
have no smart battery and use exactly this twl4030 chip.

It is not intended to become a generic charging/fuel solution. Just
make it work with DT (it worked with platform_data since ~3.12).

BR,
Nikolaus



 
 Rob
 
 + - io-channels: Should contain IIO channel specifiers
 +   for each element in io-channel-names.
 +- io-channel-names: Should contain the following values:
 + * temp - The ADC channel for temperature reading
 + * ichg - The ADC channel for battery charging status
 + * vbat - The ADC channel to measure the battery voltage
 +
 +Example:
 +   madc-battery {
 +   compatible = ti,twl4030-madc-battery;
 +   capacity-uah = 120;
 +   ti,volt-to-capacity-charging-map = 4200 100,
 +   4100 75,
 +   4000 55,
 +   3900 25,
 +   3800 5,
 +   3700 2,
 +   3600 1,
 +   3300 0;
 +
 +   ti,volt-to-capacity-discharging-map = 4200 100
 +  4100 95,
 +  4000 70,
 +  3800 50,
 +  3700 10,
 +  3600 5,
 +  3300 0;
 +   io-channels = twl_madc 1,
 + twl_madc 10,
 + twl_madc 12;
 +   io-channel-names = temp,
 +  ichg,
 +  vbat;
 +   };
 --
 1.9.1
 

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

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 01.04.2015 um 22:16 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 As I explained in some other mail, those tables should not be
 neccessary at all. They can be computed from li-ion characteristics
 and internal resistance, and assumed current during charge and
 discharge.
 
 I already explained that we do not know the charging and discharging
 current well enough for such a calculation.
 
 And I explained that the “internal resistance” is a system (battery + cables 
 +
 connectors + other circuits) parameter that is not easy to derive or measure
 and type into the .dts source code.
 
 At least I have no idea how I should find it out for my boards. While I can
 easily determine the curves (and we already have them for the platform_data
 driver).
 
 Please propose your own code doing that so that we can test if it is
 better.
 
 So, how does this look?
 
 It looks to me like you have cca 0.1 Ohm resistance in your system,

This is completely unknown.

 and are using cca 75mA while discharging, and charge by cca 1.4A.

Where do you get these figures from?

A GTA04 board discharges usually between 50 and 400 mA (depending on activities)
and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw 
even more
during operation.

Total current going in is 500-800 mA (depending on USB negotiations) and this is
split into system operation and charging current. So 1.4A charging current is 
not
possible. Rather 200-500 mA.

So it might be that the battery is discharged although the system is connected
to a charger.

 (And
 these are all the coefficients the code should need; rest is battery
 characteristics -- common to all li-ions, and charger characteristics
 -- that will be common to all cellphones. If current can be measured,
 this code should go more precise answers).
 
 pavel@amd:~/g/tui/ofone$ ./liion_maps
 Charging
 Voltage  4.2 V ; table  100 %  internal voltage 4.18 V current 0.233 A 
 computed  97 %
 Voltage  4.1 V ; table  75 %  internal voltage 4.08 V current 0.233 A 
 computed  87 %
 Voltage  4.0 V ; table  55 %  internal voltage 3.93 V current 0.700 A 
 computed  69 %
 Voltage  3.9 V ; table  25 %  internal voltage 3.76 V current 1.400 A 
 computed  26 %
 Voltage  3.8 V ; table  5 %  internal voltage 3.66 V current 1.400 A computed 
  3 %
 Voltage  3.7 V ; table  2 %  internal voltage 3.56 V current 1.400 A computed 
  2 %
 Voltage  3.6 V ; table  1 %  internal voltage 3.46 V current 1.400 A computed 
  1 %
 Voltage  3.3 V ; table  0 %  internal voltage 3.16 V current 1.400 A computed 
  -1 %
 Badness  395.4861761427434
 Discharging
 Voltage  4.2 V ; table  100 %  internal voltage 4.21 V current -0.075 A 
 computed  100 %
 Voltage  4.1 V ; table  95 %  internal voltage 4.11 V current -0.075 A 
 computed  91 %
 Voltage  4.0 V ; table  70 %  internal voltage 4.01 V current -0.075 A 
 computed  79 %
 Voltage  3.8 V ; table  50 %  internal voltage 3.81 V current -0.075 A 
 computed  46 %
 Voltage  3.7 V ; table  10 %  internal voltage 3.71 V current -0.075 A 
 computed  3 %
 Voltage  3.6 V ; table  5 %  internal voltage 3.61 V current -0.075 A 
 computed  2 %
 Voltage  3.3 V ; table  0 %  internal voltage 3.31 V current -0.075 A 
 computed  0 %
 Badness  171.69576218433212
 
 Running below 3.3V.. not really. At that point, the battery is really
 _empty_, and voltage is going down really really fast.
 
 It is the diffference between 2% and 0% where a fuel indication might
 be most important…
 
 Plus, you are damaging the battery at that point.
 
 The power controller will shut down - but the driver should report
 reasonable (but IMHO not necessarily perfect) values until the last
 moment.
 
 It is tricky to do a good job near 0%... or anywhere else. See for
 example
 
 http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf
 
 You start a call, percentage goes down, end a call, it will go
 back up. I'm pretty sure you will not be able to make a call with 5%
 indication from your code at low battery temperature (say -10C).

The whole system is heating up a little, so that you never have -10C for the
battery.

I think you are trying to solve situations that don’t exist in practice.

And AFAIK, the GTA04 board is the only user of this driver in case the battery
has no built-in fuel gauge. So why improve it beyond what the GTA04 users need?

I repeat myself: this driver is not built for highest precision because there 
are
better methods (fuel gauge chip). These might not be available so this fall-back
driver has been built.

It is definitively better than no driver and worse than the optimum.

 
 Anyway, see above, I think I provide reasonable values even in that range.
 
 Signed-off-by: Pavel Machek pa...@ucw.cz
   Pavel
 
 #!/usr/bin/python3
 import math
 
 def percent_internal(v):
u = 0.0387-(1.4523*(3.7835-v))
if u  0:
# Formula above does gives 19.66% for 3.756, and refuses to
# work below that. 

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 19:08 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
 Am 25.03.2015 um 16:21 schrieb Sebastian Reichel s...@kernel.org:
 On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
 Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org:
 On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
 So you propose that the parent-child relationship is “control”? I.e. 
 some
 channel which allows to address some bus client (through reg) and
 control that devices.
 
 Makes sense. This is how i2c and spi clients are specified.
 
 In the case of our GPS, it receives control over the serial connection 
 from
 the UART,
 
 Ahem - does it?
 
 AFAIK the chip simply starts to emit NMEA records if powered on.
 There is no command going over the serial interface to address it
 or control it.
 
 Right, since GPS basically doesn't need any configuration/control.
 That’s not true for other UART attached devices, though.
 
 Do you have an example? Usually an UART data stream is transparently
 presented to a /dev/tty - and user-space daemon can configure/control the
 attached device. In most cases it can mix payload data and control command
 by some AT command and escape sequences.
 
 Yes, but the configuration is minimal. Anyways as you said there
 *is* some kind of control happening over the UART.
 
 Control is happening on a higher network stack level than UART. It
 control is done through AT commands.
 
 Yes, obviously UART is only the physical layer. The same is true for
 busses and does not really matter.

Fine that we agree on that. I just mentioned it because we discussed about line
disciplines and tty which are higher level.

 
 also receives control via a GPIO to the on/off pin, and also needs
 a regulator to power the antenna.
 
 So should the parent be the uart, the on/off GPIO, or the regulator?
 
 I would much rather there wasn't a parent, and that each of these were 
 listed
 as ad-hoc attribute assignments.  But device-tree says there must be a 
 parent
 (where possible), and the parent is the thing that is “primarily in 
 control.
 
 Well, IMHO the “parent” could also be the root. Representing the
 whole board.
 
 Nevertheless, I doubt your rule that “ability to control” defines
 the parentchild relation (see below).
 
 
 I think the GPS is “primarily a uart-attached device.
 
 But not in the same way as an I2C device.
 
 Especially the serial interface is not a bus and not used for
 signalling and power control. It is payload data (only).
 
 Actually many I2C devices are also powered on/off via a GPIO and
 even use additional GPIOs for sending interrupts. Nevertheless they
 are normally identified as an I2C device.
 
 Because I2C is a bus that can address multiple clients and gpio isn’t
 a bus and a point-to-point connection.
 
 But IMHO it is not because they (can) send payload data over i2c.
 
 From my POV it's not because I2C is a bus, but because the primary
 function is happening via I2C (e.g. configuring sensor, gettings its
 data). The GPIOs are only needed to compensate some I2C shortcomings
 (missing irq feature in I2C) or reduce the complexity of the client
 (power GPIO). The actual system interaction with the I2C chip is
 going via I2C, though.
 
 Yes, but this is in my new understanding irrelevant for proper DT
 description.
 
 And for my understanding it is. We are arguing in a circle…

Yes, and that is the reason why I try to go to a higher level of discussion. 
I.e.
find out the principles behind. If we can agree on those, it becomes easy
to decide the details.

 
 If you assume that parentchild relationship is about control (only). 
 But if it
 is about data flow, there is a different concept in DT. For example the 
 CSI/DSI
 (OMAP DSS) use the “port” concept.
 
 Yes, this is about data not going to the cpu / system memory.
 
 Really? The frame buffer data is in system memory and gets to the panel. 
 Or a
 camera image ends up in system memory.
 
 Really? So the panel accesses the system memory? Check again. The
 panel is simply connected via DSI/SDI/... and does not access the
 system memory at all. The display controller OTH does. So let's have
 a look at the DT structure (simplified):
 
 ocp - dss - { port = panel; }
 ... - spi - panel { port = dss; }
 
 So the port models a device-to-device connection, which works
 independent of the remaining system. No system memory is involved.
 
 Sorry, but I can’t exactly follow what you want to show.
 
 Yes, the port mechanism describes a device to device connection.
 
 But it does not describe system memory. Although it is the source of
 the video (i.e. the framebuffer).
 
 This shows that the DT does not necessarily describe data flow.
 
 So why do you want to describe data flow from tty to uart to some
 connected device?
 
 It shows, that the tree models system memory flow and adds
 references for stuff

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 27.03.2015 um 17:31 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote:
 Coming back at my sentence: I asked about a non-trivial, non-bus
 connected HW, which has a DT binding.
 
 from omap3-beagle-xm.dts:
 hsusb2_phy (connected through ULPI)
 gpio-keys (it is not a trivial on/off)
 tfp410 (DVI encoder only part of the video pipeline)
 
 These just need a couple of gpios. For me that's trivial compared to
 an interface as complex as UART. Since they do not have any complex
 interface they could be a child of, they must land in /.

ULPI-PHY is not at all “just a couple of GPIOs”. It is a 60 MHz 8 bit wide
parallel protocol with handshake… Sort of 8 UARTs or SPI with common clock.

But still no bus. The bus driven by the ULPI-PHY is “USB2” which is known
not to be a physical bus but a tree. It just becomes a bus by higher level
protocols.

I must admit that I lost the goal that you want to demonstrate with this
question/examples.

 
 sound/codec (connected through McBSPs)
 
 The audio codec is a child device of the TWL. The node you are
 talking about is a ***virtual*** device.

Ah interesting that they exist! A virtual gpio was not acceptable…

 See also
 
 http://devicetree.org/SoC_Audio
 
 Note that the audio binding of many devices is not that clean,
 since quite some relationships are hidden away behind kernel quirks
 and very specific compatible strings.
 
 and there are components on the board which are not described at
 all but work out of the box: audio connectors, usb/ethernet hub
 
 Sure. Everything that can be identified automatically (USB/Ethernet
 stuff) is not encoded into DT. DT has been created to provide a
 description for devices, which can *not* be identified automatically.

Exactly.

 
 And passive components like audio connectors are normally not
 encoded into DT, since no configuration is needed and no information
 is gained. Before you argument with video connectors: Yes they are
 different, but IMHO for good reasons:
 
 1. The user can see DVI label for DVI output and HDMI label
   for HDMI output. This is not known by the display controller.
 2. The display data channel is i2c and the connector may use a
   system i2c controller together with the data wires provided by
   the display controller. The display subsystem must know which
   i2c controller takes care of the port.

Yes. Indeed.

 
 In the meantime, I have proposed an IMHO even better approach.
 
 It is not to make the gps a regulator or a subnode of some “primary 
 interface”,
 but give it a reference to the uart it is connected to.
 
 And make it an independent node on DT root level.
 
 Then we are completely independent on how the gps driver presents
 data to any user space on any OS.
 
 IMHO that approach is not better per se. The child variant is more
 generic it contains information without the kernel even knowing
 about uart specific stuff.
 
 Note, that we could always use references in DT. The tree structure
 is not needed at all, since references make it possible to describe
 a graph.

Right.

 Obviously that would defeat the purpose of the tree
 structure.

Which might be there for completeness if something wants to be
better described in a tree structure. Multiple clients of a single bus 
controller
that can be selected (addressed) are obviously better described by
a parentchild relationship (which includes some sort of “address”
to describe how this addressing works).

 In my opinion making something a node in / is always the
 last resort and in my perspective it has been handled in such a way
 so far.

But that contradicts some documents I have found and linked. Please
show me a document about DT that supports your view.

I agree that both views can be valid, but in lack of some “official” guideline
we can’t decide ourselves.

 
 What is bad with having a net? Why must we squeeze everything into
 a tree structure just because it is called such? DT language
 provides the syntax for references and that allows to make nets.
 And it is heavily used.
 
 I think so far references were mainly used when tree structure was
 too limited to describe something.
 
 You said NAK about referencing a regulator from the UART node and
 now?
 
 No. I said NAK about referencing *the* regulator from the BT/GPS
 node. My NAK was about referencing a regulator in the UART node
 (local side), which is actually needed by the GPS/BT module (remote
 side).
 
 Ah, now I understand your argument, and agree to it.
 
 My comment was on a slightly different topic that the DTR line from the
 UART (node) can be used to signal the remote regulator to be turned on.
 
 But I learned yesterday that we can even hide this explicit signalling
 mechanism (being regulator, gpio or whatever) by:
 
 bt {
  compatible = “vendor,btchip”;
  regulator = regulator to power the btchip;
  uart = uart1;
  gpio = gpio to enable the chip;
 };
 
 uart1

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 06:56 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 Main reason is, that I would need to go
 through the UART to “communicate with the w2sg0004.
 
 You can always communicate” through the UART. Even without DT. As long as
 the connected chip is powered up by any means (could be some 
 fixed-regulator
 or hard wired).
 
 But you don't know how to communicate through the uart.
 
 Maybe we are talking using different assumptions. As long as you have a user 
 space
 gpsd daemon that talks to the gps chip the kernel simply has to 
 transparently (except
 line disciplines) pass the data to the uart.
 
 Forget userspace, some other operating system (or future linux) may
 want to put gps handling into the kernel. (To hide differences between
 different GPSes).
 
 Because we want the phone to boot knowing I have a bluetooth or I
 have a GPS, as it would if it was connected using USB, and not having
 user figure out what commands he needs to do to enable reasonable
 hardware support (and getting it wrong, because you need to specify
 _many_ critical parameters to hciattach).
 
 Yes, this is indeed something I also would like to see for the GTA04 (and 
 other)
 devices.
 
 So the reason is that some kernel driver wants to use the tty/uart to 
 communicate
 directly with the chip. This is very similar to a gpio that some driver 
 wants to use.
 
 Thus please consider the
 
 / {
  bt {
  compatible = vendor,product“;
  uart = uart1;
  enable = gpio17 34 0;
  };
 };
 
 Would work, too, but I and everyone knows that subnode is better,
 easier solution.

“Everyone” could be wrong and ignorant.

And I thought we are not looking for the easiest solution but the right one.
Especially if we define something that is for other operating systems as well.

About easier: the one given above allows to modify the driver to present e.g. 
an iio
interface to user space (and no /dev/tty) *without changing the DT*. Because the
driver code decides which interface it presents. And not where it is a subnode 
in DT.

This is the level of abstraction DT nodes should have.


It may be that you did not read my previous argumentation completely.

In short, please see:

http://www.devicetree.org/Device_Tree_Usage#Devices

And check of there is anything that mandates useage of a subnode in this case.
I simply don’t find it.

Rather, although it is also not explicitly excluded, I read hints that it 
should *not* be
done the subnode way.

The reason is that it appears to me that the DT hierarchy is intended to 
describe
how kernel drivers can *address* different components. Nothing less and nothing 
more.

Especially there is no hint that layering in DT has anything to do with data 
flow
hierarchies or a “primary” interface as Sebastian calls it.

 
 approach.
 
 And if you want to hide uart1 from the user-space, that should be a property
 of the uart1 node (whereever it is defined).
 
 Sorry? That would be one heck of layering violation.

Which layering?

I think you still mix the software/kernel driver/data flow layers with DT 
layers.

DT can and must be independent on that.

BR,
Nikolaus


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

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
 So you propose that the parent-child relationship is “control”? I.e. some
 channel which allows to address some bus client (through reg) and
 control that devices.
 
 Makes sense. This is how i2c and spi clients are specified.
 
 
 In the case of our GPS, it receives control over the serial connection from
 the UART,
 
 Ahem - does it?
 
 AFAIK the chip simply starts to emit NMEA records if powered on.
 There is no command going over the serial interface to address it
 or control it.
 
 Right, since GPS basically doesn't need any configuration/control.
 That’s not true for other UART attached devices, though.

Do you have an example? Usually an UART data stream is transparently
presented to a /dev/tty - and user-space daemon can configure/control the
attached device. In most cases it can mix payload data and control command
by some AT command and escape sequences.

 
 also receives control via a GPIO to the on/off pin, and also needs
 a regulator to power the antenna.
 
 So should the parent be the uart, the on/off GPIO, or the regulator?
 
 I would much rather there wasn't a parent, and that each of these were 
 listed
 as ad-hoc attribute assignments.  But device-tree says there must be a 
 parent
 (where possible), and the parent is the thing that is “primarily in 
 control.
 
 Well, IMHO the “parent” could also be the root. Representing the
 whole board.
 
 Nevertheless, I doubt your rule that “ability to control” defines
 the parentchild relation (see below).
 
 
 I think the GPS is “primarily a uart-attached device.
 
 But not in the same way as an I2C device.
 
 Especially the serial interface is not a bus and not used for
 signalling and power control. It is payload data (only).
 
 Actually many I2C devices are also powered on/off via a GPIO and
 even use additional GPIOs for sending interrupts. Nevertheless they
 are normally identified as an I2C device.

Because I2C is a bus that can address multiple clients and gpio isn’t
a bus and a point-to-point connection.

But IMHO it is not because they (can) send payload data over i2c.

 
 Also for non-GPS device the serial connection is used for
 controlling and configuring the device.

This assumes that “controls a device” is the criterion for making a device
a subnode. I doubt that.

 
 So I propose a device-node which describes the GPS, which is a child of the
 UART, and explicitly identifies the GPIO it uses to power on/off, the
 regulator it uses to power the antenna, and how it receives on or off
 status indications from the GPS.
 
 The more I think about that, you have given good arguments *not*
 to use the parent-child relationship for the UART interface of
 the GPS.
 
 Let me give another example. The 3G Modem has 3 (or 4) interfaces:
 1. an USB-Interface for AT signalling and payload
 2. some GPIOs for power control.
 3. a PCM interface for digital voice. 
 4. it might also have a serial interface as alternate AT command and (GPRS
low speed) payload.
 
 So which one is the most prominent or most important to make it a child of?
 
 If you use “control” you must make it a child of the USB phy and the serial 
 interface
 which requires multiple inheritance…
 
 So I am not sure at all. None is IMHO prominent and unique enough to make it
 a parentchild relation.
 
 Threrefore, I would be happy to see it as multiple children of /. For 
 example a
 MFD with subnodes.
 
 This scenario has already been seen before and can happen for
 non-UART based devices (e.g. SPI + I2C). So far the decision was to
 postpone the discussion about this kind of devices until one of them
 appears.
 
 It is arguable that the antenna should be treated as a separate device - a
 child of the GPS - which controls the regulator and also provides a 'extcon'
 which reports whether an external GPS antenna is attached, or whether the
 internal on is in use.  I haven't made the time to properly explore that
 issue yet.
 
 If you assume that parentchild relationship is about control (only). But if 
 it
 is about data flow, there is a different concept in DT. For example the 
 CSI/DSI
 (OMAP DSS) use the “port” concept.
 
 Yes, this is about data not going to the cpu / system memory.

Really? The frame buffer data is in system memory and gets to the panel. Or a
camera image ends up in system memory.

 
 This means that indeed parentchild is used for control, e.g. I2C
 or SPI to tell the panel controller to switch on.
 
 well parent  child is not about power control, but about primary
 control.

Can you clearly and precisely define what “primary” control is? I think
two people will have three opinions about that.

For example I would see the w2sg0004 on/off gpio as the primary “control”
which makes the light (NMES records) turned on.

Therefore we should make it the subnode of some gpio-controller, shouldn’t we?

 Some I2C/SPI

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 16:21 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
 Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org:
 On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
 So you propose that the parent-child relationship is “control”? I.e. some
 channel which allows to address some bus client (through reg) and
 control that devices.
 
 Makes sense. This is how i2c and spi clients are specified.
 
 
 In the case of our GPS, it receives control over the serial connection 
 from
 the UART,
 
 Ahem - does it?
 
 AFAIK the chip simply starts to emit NMEA records if powered on.
 There is no command going over the serial interface to address it
 or control it.
 
 Right, since GPS basically doesn't need any configuration/control.
 That’s not true for other UART attached devices, though.
 
 Do you have an example? Usually an UART data stream is transparently
 presented to a /dev/tty - and user-space daemon can configure/control the
 attached device. In most cases it can mix payload data and control command
 by some AT command and escape sequences.
 
 Yes, but the configuration is minimal. Anyways as you said there
 *is* some kind of control happening over the UART.

Control is happening on a higher network stack level than UART. It
control is done through AT commands.

 
 also receives control via a GPIO to the on/off pin, and also needs
 a regulator to power the antenna.
 
 So should the parent be the uart, the on/off GPIO, or the regulator?
 
 I would much rather there wasn't a parent, and that each of these were 
 listed
 as ad-hoc attribute assignments.  But device-tree says there must be a 
 parent
 (where possible), and the parent is the thing that is “primarily in 
 control.
 
 Well, IMHO the “parent” could also be the root. Representing the
 whole board.
 
 Nevertheless, I doubt your rule that “ability to control” defines
 the parentchild relation (see below).
 
 
 I think the GPS is “primarily a uart-attached device.
 
 But not in the same way as an I2C device.
 
 Especially the serial interface is not a bus and not used for
 signalling and power control. It is payload data (only).
 
 Actually many I2C devices are also powered on/off via a GPIO and
 even use additional GPIOs for sending interrupts. Nevertheless they
 are normally identified as an I2C device.
 
 Because I2C is a bus that can address multiple clients and gpio isn’t
 a bus and a point-to-point connection.
 
 But IMHO it is not because they (can) send payload data over i2c.
 
 From my POV it's not because I2C is a bus, but because the primary
 function is happening via I2C (e.g. configuring sensor, gettings its
 data). The GPIOs are only needed to compensate some I2C shortcomings
 (missing irq feature in I2C) or reduce the complexity of the client
 (power GPIO). The actual system interaction with the I2C chip is
 going via I2C, though.

Yes, but this is in my new understanding irrelevant for proper DT description.

 
 Also for non-GPS device the serial connection is used for
 controlling and configuring the device.
 
 This assumes that “controls a device” is the criterion for making a device
 a subnode. I doubt that.
 
 For me the criterion always was accessing the device's
 registers/configuration/data from the system's point of view (so
 your video port does not count, since it models a connection between
 two components without system interaction).

 
 So I propose a device-node which describes the GPS, which is a child of 
 the
 UART, and explicitly identifies the GPIO it uses to power on/off, the
 regulator it uses to power the antenna, and how it receives on or off
 status indications from the GPS.
 
 The more I think about that, you have given good arguments *not*
 to use the parent-child relationship for the UART interface of
 the GPS.
 
 Let me give another example. The 3G Modem has 3 (or 4) interfaces:
 1. an USB-Interface for AT signalling and payload
 2. some GPIOs for power control.
 3. a PCM interface for digital voice. 
 4. it might also have a serial interface as alternate AT command and (GPRS
   low speed) payload.
 
 So which one is the most prominent or most important to make it a child of?
 
 If you use “control” you must make it a child of the USB phy and the 
 serial interface
 which requires multiple inheritance…
 
 So I am not sure at all. None is IMHO prominent and unique enough to make 
 it
 a parentchild relation.
 
 Threrefore, I would be happy to see it as multiple children of /. For 
 example a
 MFD with subnodes.
 
 This scenario has already been seen before and can happen for
 non-UART based devices (e.g. SPI + I2C). So far the decision was to
 postpone the discussion about this kind of devices until one of them
 appears.
 
 It is arguable that the antenna should be treated as a separate device 
 - a
 child of the GPS - which controls the regulator and also provides a 
 'extcon'
 which

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 21:42 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 In the case of our GPS, it receives control over the serial connection from
 the UART,
 
 Ahem - does it?
 
 AFAIK the chip simply starts to emit NMEA records if powered on. There is no
 command going over the serial interface to address it or control it.
 
 Well _most_ GPSes enable you to control them over the serial
 line. (Things like sampling rate, AGPS data upload, …)

Yes, I know.

But is this something the kernel is/must be aware? And
must it be represented by the DT? Or does it have to influence
the way the DT is structured?

Well, if GPS data is presented through iio, these commands must
be handled by some driver.

 
 I think the GPS is “primarily a uart-attached device.
 
 But not in the same way as an I2C device.
 
 Especially the serial interface is not a bus and not used for signalling and
 power control. It is payload data (only).
 
 Serial interface looks a lot like a (point-to-point) bus to
 me. Similar to SATA, for example.

In that sense a gpio looks also a lot like a 1-bit bus...

Anyways, there are no subnodes (clients) of a gpio but the
gpiocontroller pattern is used.

In other words: a driver that wants to control a gpio asks for a
reference of the gpio controller and uses the gpiolib to control it.

In the same way, a driver that wants to use an uart could ask
for a reference to the tty/uart driver and use some functions to
control it (and send commands). So a hypothetical gps-iio
driver could set sampling rate etc.

And it can also ask the tty/uart: „please register me and notify if
some syscall wants you to open() or close() so that I (the driver of
the GPS chip) can turn on power of the GPS chip (and only I know
how to do that - nobody else has to care)“.

I am just playing the Devil's advocate to find out what the really
common principle is and how the DT for clients of a serial interface
should really be represented in a DT in a way that is agnostic to
a specific driver structure, driver functions and user space.

And to find out if we need tty/slaves (as proposed in the title of this
patch series) at all. Or if there is a better way to describe the relation
of the gps chip driver and the tty/uart.

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

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 25.03.2015 um 21:53 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 AFAIK the chip simply starts to emit NMEA records if powered on.
 There is no command going over the serial interface to address it
 or control it.
 
 Right, since GPS basically doesn't need any configuration/control.
 That’s not true for other UART attached devices, though.
 
 Do you have an example? Usually an UART data stream is transparently
 presented to a /dev/tty - and user-space daemon can configure/control the
 attached device. In most cases it can mix payload data and control command
 by some AT command and escape sequences.
 
 Bluetooth H4P protocol is one example.
 
 well parent  child is not about power control, but about primary
 control.
 
 Can you clearly and precisely define what “primary” control is? I think
 two people will have three opinions about that.
 
 This has not be a problem so far...
 
 For example I would see the w2sg0004 on/off gpio as the primary “control”
 which makes the light (NMES records) turned on.
 
 ...and I don't think it is a problem now.
 
 Main reason is, that I would need to go
 through the UART to “communicate with the w2sg0004.
 
 You can always communicate” through the UART. Even without DT. As long as
 the connected chip is powered up by any means (could be some fixed-regulator
 or hard wired).
 
 But you don't know how to communicate through the uart.

Maybe we are talking using different assumptions. As long as you have a user 
space
gpsd daemon that talks to the gps chip the kernel simply has to transparently 
(except
line disciplines) pass the data to the uart.

For that there is no need to describe anything in DT.

 
 Let me raise the question:
 
 Why do we need to describe in the DT (independently of Linux power control
 structures and drivers!) that the GPS data interface is connected to a 
 specific UART?
 
 Because we want the phone to boot knowing I have a bluetooth or I
 have a GPS, as it would if it was connected using USB, and not having
 user figure out what commands he needs to do to enable reasonable
 hardware support (and getting it wrong, because you need to specify
 _many_ critical parameters to hciattach).

Yes, this is indeed something I also would like to see for the GTA04 (and other)
devices.

So the reason is that some kernel driver wants to use the tty/uart to 
communicate
directly with the chip. This is very similar to a gpio that some driver wants 
to use.

Thus please consider the

/ {
bt {
compatible = vendor,product“;
uart = uart1;
enable = gpio17 34 0;
};
};

approach.

And if you want to hide uart1 from the user-space, that should be a property
of the uart1 node (whereever it is defined).

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

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 21.03.2015 um 00:31 schrieb NeilBrown ne...@suse.de:

 On Fri, 20 Mar 2015 10:34:18 +0100 Dr. H. Nikolaus Schaller
 h...@goldelico.com wrote:
 
 
 Am 20.03.2015 um 09:54 schrieb NeilBrown ne...@suse.de:
 
 There needs to be one device-node for each device, and that device-node 
 needs
 to be a child of the device-node for the device which is the primary
 connection to the child device.
 
 Then please explain to me nodes like
 
 / {
  compatible = ti,omap3-gta04, ti,omap36xx, ti,omap3;
 
  cpus {
  cpu@0 {
  cpu0-supply = vcc;
  };
  };
 
 According to the rule you apply here it should be something like
 
  cpu@0 {
  regulator {
  …
  }
 
 
 
 This exactly highlight one of the big problems with device tree as I see it.
 
 Each device can potentially have relationships with a number of other
 devices, for the supply of power, reset signalling, interrupt handled, data
 transfer, command transfer etc etc etc.

Yes. The network is a mesh.

 
 devicetree provides two ways to indicated a relationship between devices.
 One way is a parent/child arrangement.  The other way is ad-hoc
   attribute = devicename
 assignments.

Yes.

 
 Each device can only have one parent, but can have multiple arbitrary
 assignments.
 
 I would much rather that the parent/child relationship didn't exist at all.
 Each device should stand alone, and list all relationships explicitly.  But
 that is not the way devicetree works, and we need to live with that.

Is it not how the device tree works or how we use it? Or how you think it
should better be?

What stops us from using it in arbitrary assignments like clocks and
regulators?

GPIOs are also a nice example: you just specify the gpio controller
and the gpio number to use it. There is no parent/child connection.

Why for tty / serial and serial consumers but not for GPIOs?

I have tried to find out the rules when parentchild is used (see below).

 
 So we need a clear understanding of what the 'parent' of a given device
 should be.
 I don't know what the specifications say, if anything, but what I see is that
 the parent is in practive a device which can ‘address' the child.  

I think this holds only for “bus” devices - where it is really a good and
standard way of structuring the bus and it’s masters/slaves. One child
node per client.

 i.e.
 control signalling is the key parent-child relationship.
 This is consistent with the fact that many device nodes have a 
   reg=xxx
 attribute which gives the address of the node as seen by it's parent.
 
 Given that understanding, a regulator must be a child of the device which can
 control it - which can turn it on or off.  Not a child of the device which
 receives power from it.

So you propose that the parent-child relationship is “control”? I.e. some
channel which allows to address some bus client (through reg) and
control that devices.

Makes sense. This is how i2c and spi clients are specified.

 
 In the case of our GPS, it receives control over the serial connection from
 the UART,

Ahem - does it?

AFAIK the chip simply starts to emit NMEA records if powered on. There is no
command going over the serial interface to address it or control it.

 also receives control via a GPIO to the on/off pin, and also needs
 a regulator to power the antenna.
 
 So should the parent be the uart, the on/off GPIO, or the regulator?
 
 I would much rather there wasn't a parent, and that each of these were listed
 as ad-hoc attribute assignments.  But device-tree says there must be a parent
 (where possible), and the parent is the thing that is “primarily in control.

Well, IMHO the “parent” could also be the root. Representing the whole board.

Nevertheless, I doubt your rule that “ability to control” defines the 
parentchild
relation (see below).

 
 I think the GPS is “primarily a uart-attached device.

But not in the same way as an I2C device.

Especially the serial interface is not a bus and not used for signalling and
power control. It is payload data (only).

 So I propose a device-node which describes the GPS, which is a child of the
 UART, and explicitly identifies the GPIO it uses to power on/off, the
 regulator it uses to power the antenna, and how it receives on or off
 status indications from the GPS.

The more I think about that, you have given good arguments *not* to use the
parent-child relationship for the UART interface of the GPS.

Let me give another example. The 3G Modem has 3 (or 4) interfaces:
1. an USB-Interface for AT signalling and payload
2. some GPIOs for power control.
3. a PCM interface for digital voice. 
4. it might also have a serial interface as alternate AT command and (GPRS
low speed) payload.

So which one is the most prominent or most important to make it a child of?

If you use “control” you must make it a child of the USB phy and the serial 
interface
which requires multiple inheritance

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 18.03.2015 um 06:58 schrieb NeilBrown n...@brown.name:

 If a platform has a particular device permanently attached to a UART,
 there may be out-of-band signaling necessary to power the device
 on and off.
 
 This driver controls that signalling for a number of different devices.
 It can
 - enable/disable a regulator
 - toggle a GPIO
 - register an 'rfkill' which can force the device to be off.
 
 When the rfkill is absent or unblocked, the device will be on when the
 associated tty device is open, and closed otherwise.
 
 Signed-off-by: NeilBrown n...@brown.name
 ---
 .../bindings/tty_slave/wi2wi,w2cbw003.txt  |   19 +
 .../bindings/tty_slave/wi2wi,w2sg0004.txt  |   37 +
 .../devicetree/bindings/vendor-prefixes.txt|1 
 drivers/tty/slave/Kconfig  |   14 +
 drivers/tty/slave/Makefile |2 
 drivers/tty/slave/serial-power-manager.c   |  510 
 6 files changed, 583 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 create mode 100644 
 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/slave/serial-power-manager.c
 
 diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt 
 b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 new file mode 100644
 index ..cfe6ee5e01e9
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 @@ -0,0 +1,19 @@
 +wi2wi bluetooth module
 +
 +This is accessed via a serial port and is largely controlled via that
 +link.  Extra configuration is needed to enable power on/off
 +
 +Required properties:
 +- compatible: wi2wi,w2cbw003
 +- vdd-supply: regulator used to power the device.
 +
 +The node for this device must be the child of a UART.
 +
 +Example:
 +
 +uart1 {
 +   bluetooth {
 +   compatible = wi2wi,w2cbw003;
 +   vdd-supply = vaux4;
 +   };
 +};

Wouldn’t it be easier to simply write

uart1 {
vdd-suppy = vaux4;
}

 diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt 
 b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 new file mode 100644
 index ..fdc52cf56533
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 @@ -0,0 +1,37 @@
 +wi2wi GPS device
 +
 +This is accessed via a serial port and is largely controlled via that
 +link.  Extra configuration is needed to enable power on/off
 +
 +Required properties:
 +- compatible: wi2wi,w2sg0004
 +- gpios: gpios used to toggle 'on/off' pin
 +- interrupts: interrupt generated by RX pin when device
 +  should be off
 +
 +Optional properties:
 +- vdd-supply: regulator used to power antenna
 +- pinctrl: default, off
 +  if off setting is provided it is imposed when device should
 +  be off.  This can route the RX pin to a GPIO interrupt.
 +
 +The w2sg0004 uses a pin-toggle both to power-on and to
 +power-off, so the driver needs to detect what state it is in.
 +It does this by detecting characters on the RX line.
 +When it should be off, these can optionally be detected by a GPIO.
 +
 +The node for this device must be the child of a UART.
 +
 +Example:
 +uart2 {
 +   gps {
 +   compatible = wi2iw,w2sg0004;
 +   vdd-supply = vsim;
 +   gpios = gpio5 17 0; /* GPIO_145 */
 +   interrupts-extended = gpio5 19 0; /* GPIO_147 */
 +   /* When off, switch RX to be an interrupt */
 +   pinctrl-names = default, off;
 +   pinctrl-0 = uart2_pins;
 +   pinctrl-1 = uart2_pins_rx_gpio;
 +   };
 +};

If the wi2wi driver is a regulator driver one would write

/ {
   gps-regulator: gps {
   compatible = wi2iw,w2sg0004;
   vdd-supply = vsim;
   gpios = gpio5 17 0; /* GPIO_145 */
   interrupts-extended = gpio5 19 0; /* GPIO_147 */
   /* When off, switch RX to be an interrupt */
   pinctrl-names = default, off;
   pinctrl-0 = uart2_pins;
   pinctrl-1 = uart2_pins_rx_gpio;
   };
}

uart2 {
vdd-suppy = gps-regulator;
};

Which IMHO better describes that the uart controls power of a separate driver.

And this pattern for writing a DT would IMHO be more flexible because you
can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.


 diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
 b/Documentation/devicetree/bindings/vendor-prefixes.txt
 index 389ca1347a77..81d259303710 100644
 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
 +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
 @@ -189,6 +189,7 @@ variscite Variscite Ltd.
 via   VIA Technologies, Inc.
 virtioVirtual I/O Device Specification, developed by the OASIS 
 consortium
 voipacVoipac Technologies s.r.o.
 +wi2wi

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Neil,

Am 18.03.2015 um 06:58 schrieb NeilBrown n...@brown.name:

 Hi again,
 here is version 3 of support for tty-slaves.
 
 This version introduces a new bus-type for tty-slaves,

Hm. I am still not convinced that a tty is a „bus“ and 
that this is a solution for a wide-spread problem.

 and causes
 a tty-slave device to appear in /sys/devices between the uart and the
 tty.
 It effectively intercepts and calls from the tty to the uart (i.e. any
 tty_operations) and applies extra functionality at that point.

 
 Currently the only driver intercepts open and close.
 It powers on the device on open, and powers off at last-close.

That is what the missing piece in Linux is to make the w2sg0004
chip work.

 
 Power can be controlled by a regulator or by toggling a GPIO.

I think such a GPIO logic has nothing to do with serial and
should be left over to the regulator logic, i.e. we need a special
regulator-w2sg0004 driver.

So I suggest to remove the GPIO logic from your 

drivers/tty/slave/serial-power-manager.c

And then you can even get rid of adding a chip specific „compatible“
entry for the subnodes.

 
 I think I've incorporated most of the feed back I received from
 previous versions, but if I missed something - I apologize.  If
 this approach is structurally acceptable then I can fix up all the
 smaller issues.

As said I would prefer that the w2sg0004 driver is just a separate
„regulator“ driver as we had proposed before.

Nikolaus



 
 Thanks for your review,
 NeilBrown
 
 
 ---
 
 NeilBrown (3):
  TTY: use class_find_device to find port in uart_suspend/resume.
  TTY: add support for tty_slave devices.
  tty/slaves: add a driver to power on/off UART attached devices.
 
 
 .../bindings/tty_slave/wi2wi,w2cbw003.txt  |   19 +
 .../bindings/tty_slave/wi2wi,w2sg0004.txt  |   37 +
 .../devicetree/bindings/vendor-prefixes.txt|1 
 drivers/tty/Kconfig|1 
 drivers/tty/Makefile   |1 
 drivers/tty/serial/serial_core.c   |   21 -
 drivers/tty/slave/Kconfig  |   21 +
 drivers/tty/slave/Makefile |4 
 drivers/tty/slave/serial-power-manager.c   |  510 
 drivers/tty/slave/tty_slave_core.c |  136 +
 drivers/tty/tty_io.c   |   60 ++
 include/linux/tty.h|2 
 include/linux/tty_slave.h  |   26 +
 13 files changed, 813 insertions(+), 26 deletions(-)
 create mode 100644 
 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 create mode 100644 
 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/slave/Kconfig
 create mode 100644 drivers/tty/slave/Makefile
 create mode 100644 drivers/tty/slave/serial-power-manager.c
 create mode 100644 drivers/tty/slave/tty_slave_core.c
 create mode 100644 include/linux/tty_slave.h
 
 --
 Signature
 
 ___
 Gta04-owner mailing list
 gta04-ow...@goldelico.com
 http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

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

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 20.03.2015 um 09:54 schrieb NeilBrown ne...@suse.de:

 On Fri, 20 Mar 2015 08:54:38 +0100 Dr. H. Nikolaus Schaller
 h...@goldelico.com wrote:
 
 
 Am 18.03.2015 um 06:58 schrieb NeilBrown n...@brown.name:
 
 If a platform has a particular device permanently attached to a UART,
 there may be out-of-band signaling necessary to power the device
 on and off.
 
 This driver controls that signalling for a number of different devices.
 It can
 - enable/disable a regulator
 - toggle a GPIO
 - register an 'rfkill' which can force the device to be off.
 
 When the rfkill is absent or unblocked, the device will be on when the
 associated tty device is open, and closed otherwise.
 
 Signed-off-by: NeilBrown n...@brown.name
 ---
 .../bindings/tty_slave/wi2wi,w2cbw003.txt  |   19 +
 .../bindings/tty_slave/wi2wi,w2sg0004.txt  |   37 +
 .../devicetree/bindings/vendor-prefixes.txt|1 
 drivers/tty/slave/Kconfig  |   14 +
 drivers/tty/slave/Makefile |2 
 drivers/tty/slave/serial-power-manager.c   |  510 
 
 6 files changed, 583 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 create mode 100644 
 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/slave/serial-power-manager.c
 
 diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt 
 b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 new file mode 100644
 index ..cfe6ee5e01e9
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 @@ -0,0 +1,19 @@
 +wi2wi bluetooth module
 +
 +This is accessed via a serial port and is largely controlled via that
 +link.  Extra configuration is needed to enable power on/off
 +
 +Required properties:
 +- compatible: wi2wi,w2cbw003
 +- vdd-supply: regulator used to power the device.
 +
 +The node for this device must be the child of a UART.
 +
 +Example:
 +
 +uart1 {
 +   bluetooth {
 +   compatible = wi2wi,w2cbw003;
 +   vdd-supply = vaux4;
 +   };
 +};
 
 Wouldn’t it be easier to simply write
 
 uart1 {
  vdd-suppy = vaux4;
 }
 
 Easier to write: certainly.
 Easier to justify? No.

I just justified.

 Easier to get merged upstream?  Definitely not.

Are you the maintainer?

 After all, the uart itself doesn't require a power supply.
 It is the device connected to the uart which requires the power supply.

Yes.

 
 
 
 diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt 
 b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 new file mode 100644
 index ..fdc52cf56533
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 @@ -0,0 +1,37 @@
 +wi2wi GPS device
 +
 +This is accessed via a serial port and is largely controlled via that
 +link.  Extra configuration is needed to enable power on/off
 +
 +Required properties:
 +- compatible: wi2wi,w2sg0004
 +- gpios: gpios used to toggle 'on/off' pin
 +- interrupts: interrupt generated by RX pin when device
 +  should be off
 +
 +Optional properties:
 +- vdd-supply: regulator used to power antenna
 +- pinctrl: default, off
 +  if off setting is provided it is imposed when device should
 +  be off.  This can route the RX pin to a GPIO interrupt.
 +
 +The w2sg0004 uses a pin-toggle both to power-on and to
 +power-off, so the driver needs to detect what state it is in.
 +It does this by detecting characters on the RX line.
 +When it should be off, these can optionally be detected by a GPIO.
 +
 +The node for this device must be the child of a UART.
 +
 +Example:
 +uart2 {
 +   gps {
 +   compatible = wi2iw,w2sg0004;
 +   vdd-supply = vsim;
 +   gpios = gpio5 17 0; /* GPIO_145 */
 +   interrupts-extended = gpio5 19 0; /* GPIO_147 */
 +   /* When off, switch RX to be an interrupt */
 +   pinctrl-names = default, off;
 +   pinctrl-0 = uart2_pins;
 +   pinctrl-1 = uart2_pins_rx_gpio;
 +   };
 +};
 
 If the wi2wi driver is a regulator driver one would write
 
 / {
   gps-regulator: gps {
   compatible = wi2iw,w2sg0004;
   vdd-supply = vsim;
   gpios = gpio5 17 0; /* GPIO_145 */
   interrupts-extended = gpio5 19 0; /* GPIO_147 */
   /* When off, switch RX to be an interrupt */
   pinctrl-names = default, off;
   pinctrl-0 = uart2_pins;
   pinctrl-1 = uart2_pins_rx_gpio;
   };
 }
 
 uart2 {
  vdd-suppy = gps-regulator;
 };
 
 Which IMHO better describes that the uart controls power of a separate 
 driver.
 
 But the uart doesn’t control the power.
 An 'open' on the tty causes one driver to turn on a regulator, and another
 driver to activate a uart so that the device represented by the tty can

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 20.03.2015 um 14:08 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
 [...]
 And we do not write a driver for the w2sg0004 but the regulator inside that
 chip.
 
 DT describes the hardware structure and not the Linux driver
 structure.

I am not advocating for describing the Linux driver structure in DT.
Rather I suggest that the DT should describe hardware and there
is a regulator inside that chip… Linux drivers can follow that or mix
everything into a single driver if that is better.

 
 You also won’t expect that the omap3 driver hides everything. You
 expect that the twl4030 provides some regulators that can be enabled
 by subsystems inside the omap3. And if I remember correctly there are
 regulators inside the omap3 which have explicit regulator nodes in the DT.
 
 so let's have a look at twl regulators. They can be found below
 the twl node, so they will look similar to
 
 / - omap3 - i2c - twl - regulator
 
 So properly mapped to the w2sg0004 device this would put your
 regulator to
 
 / - omap3 - serial - w2sg0004 - regulator

Yes. Indeed.

Currently it is

omap3 - serial - serial-power-manager (trying to cover a multitude
of different chips).

 
 This will gain you nothing as far as I can tell.

And because of that I think Neil’s argument isn’t for or against
anything.

 
 Please note that subdevices under the serial node are pretty useful,
 since then the kernel can e.g. automatically setup correct line
 disciplines for serial attached bluetooth chips and make bluetooth
 work out of the box.

I don’t doubt that such subnodes are useful. I just object mixing
different chips and controls into a single subnode driver.

And as soon as you want to control line disciplines from such
a subnode, you indeed need a driver for each variant.

So a GPS chip needing some line discipline could be

 / - omap3 - serial - w2sg0004 - line-discipline
 / - omap3 - serial - w2sg0004 - regulator

And if omap3 - serial can directly control a regulator, it can
easily be the w2sg0004 - regulator

 
 I am aware, that the Linux kernel has no such thing for serial
 attached GPS devices, but that's Linux specific and irrelevant
 for the DT description.
 
 The w2sg0004-regulator approach just follows this principle.
 Anyone willing to control the power of the w2sg0004 can use this
 regulator interface.
 
 From a HW perspective your regulator hides the information, that
 there is a device attached to the serial port and instead claims,
 that a regulator is needed to make the serial port work.

Yes, without this regulator the serial port does not work. It is IMHO
more important than stating the obvious that a serial device is
connected to a serial port.

And if there is nothing to hide (the obvious serial interface wiring), why
describe it at all?

Anyways, in my proposal there will be a subnode of the uart, the
one where it is specified that it should control the regulator of the
w2sg.

Basically, Neil’s proposal already covers this case. His bluetooth
subnode just controls vaux4 which turns on power for the w2cbw003
chip.

So for my view it is not really understandable why one uart subnode
can control a regulator, and the other can’t or shouldn’t and why
this regulator function can’t be divided from the serial management
into a regulator driver.

 
 Apart from that this interface is limited in its features. I'm
 currently working on N900's bluetooth chip. This one needs to set a
 gpio before data is sent data to the chip, has a reset gpio and
 a gpio to wakeup the OMAP SoC from idle states to avoid data loss
 on the UART.

Yes, that looks equally complicated to solve if not even more than
the w2sg chip.

But what would you prefer:

* extend the drivers/tty/slave/serial-power-manager.c to also cover your
  special case

* instantiate a drivers/misc/n900-bluetooth-regulator.c and hook it up
  exactly like the vaux4 of the gta04 bluetooth chip? Just referencing
  a different regulator node?

And as said I don’t mind if the regulator is a subnode of the omap3 serial.

BR,
Nikolaus

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

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 20.03.2015 um 09:43 schrieb NeilBrown ne...@suse.de:

 On Fri, 20 Mar 2015 08:54:35 +0100 Dr. H. Nikolaus Schaller
 h...@goldelico.com wrote:
 
 Hi Neil,
 
 Am 18.03.2015 um 06:58 schrieb NeilBrown n...@brown.name:
 
 Hi again,
 here is version 3 of support for tty-slaves.
 
 This version introduces a new bus-type for tty-slaves,
 
 Hm. I am still not convinced that a tty is a „bus“ and 
 that this is a solution for a wide-spread problem.
 
 Don’t read too much into the word bus.  

Then we should find a different word.

 It is really just a mechanism for
 grouping drivers together - with maybe a hint of a suggestions that it helps
 communicate with the devices which the drivers drive.
 
 And I'm not particularly interested in solving wide-spread problems, just in
 solving my problem in a suitably idiomatic way.
 
 
 
 and causes
 a tty-slave device to appear in /sys/devices between the uart and the
 tty.
 It effectively intercepts and calls from the tty to the uart (i.e. any
 tty_operations) and applies extra functionality at that point.
 
 
 Currently the only driver intercepts open and close.
 It powers on the device on open, and powers off at last-close.
 
 That is what the missing piece in Linux is to make the w2sg0004
 chip work.
 
 
 Power can be controlled by a regulator or by toggling a GPIO.
 
 I think such a GPIO logic has nothing to do with serial and
 should be left over to the regulator logic, i.e. we need a special
 regulator-w2sg0004 driver.
 
 So I suggest to remove the GPIO logic from your 
 
 drivers/tty/slave/serial-power-manager.c
 
 And then you can even get rid of adding a chip specific „compatible“
 entry for the subnodes.
 
 But (nearly) every node has a compatible entry.
 Each node describes a device, and the compatible string tells us what sort
 of device.

Yes, it should - if necessary.

 Surely you agree that there is a particular device that needs to be
 controlled?

No, my opinion is that a specific regulator should be controlled.

  In that case there needs to be a node representing it and a
 compatible string describing it.  That is how “devicetree works.

For this there is the vdd-regulator = regulator idiom and that is
how “devicetree” works as well.

 
 
 
 
 I think I've incorporated most of the feed back I received from
 previous versions, but if I missed something - I apologize.  If
 this approach is structurally acceptable then I can fix up all the
 smaller issues.
 
 As said I would prefer that the w2sg0004 driver is just a separate
 „regulator“ driver as we had proposed before.
 
 You can prefer that if you wish.  But given that the w2sg0004 is not in fact
 a regulator,

therefore our proposal is to make it a drivers/misc and not a drivers/regulator.
But it has a regulator inside that can obviously be turned on or off. So I want 
to
keep close to the logical energy flow.

 but is in fact a GPS device, I doubt you will find a lot of
 support for your approach (as indeed I didn’t when I tried it...)

We got a lot of support. The main opposition was about using a “virtual”
gpio controller instead of a regulator API to turn the chip on and off as
directed by the tty driver.

And we do not write a driver for the w2sg0004 but the regulator inside that
chip. You also won’t expect that the omap3 driver hides everything. You
expect that the twl4030 provides some regulators that can be enabled
by subsystems inside the omap3. And if I remember correctly there are
regulators inside the omap3 which have explicit regulator nodes in the DT.

The w2sg0004-regulator approach just follows this principle. Anyone willing
to control the power of the w2sg0004 can use this regulator interface.

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe devicetree 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 17.03.2015 um 09:47 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..bb3580c
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery
 + - capacity-uah : battery capacity in uAh
 
 Could we make it capacity-uAh ?
 This name was suggested by Mark Rutland [1] and naming convention
 should be all lowercase. There exists already bindings
 without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
 
 Messing up SI units due to convention is _stupid_. Don't do it.
 
 to introduce coefficients for temperature and discharge rate?
 What do you mean? Nothing like that is used in current driver why do
 we need to add it?
 
 Well, conversion between Li-ion's voltage and state of charge at 0
 current is well known:

We can’t measure at 0 current since the OMAP is driven from battery
and charger and may also draw some mA…

 
def percent(m, v):
   u = 0.0387-(1.4523*(3.7835-v))
if u  0:
return 0
  return (0.1966+math.sqrt(u))*100
 
 And there's not much to calibrate there, and it should become library
 helper function; there's no need to write it to every single dts.
 
 The charge/discharge difference is due to internal battery resistance,
 and Ohm's law. (Then, you should not need different values for
 charging/discharging case.)

Yes, and that also depends on the board and battery type. So you always
need to specify some battery specific coefficient for that in the DT.

We simply did choose a table, because calculating the right coefficients
is more complex and getting the table values can easily be done from
running one full charge-discharge-charge cycle.

 
 With your aproach, you'll get lower percentage when phone is under
 load vs. idle. Taking internal resistance into account would give you
 more precise readings. (Attached, old patch for zaurus shows the
 needed computation).

This is why we have a charging and a discharging table to compensate
for this effect.

 
 And if you wanted even more precise readings... internal resistance
 depends on temperature.

We don’t necessarily know the real battery temperature.

 
 I guess this should go into library somewhere, because many machines
 need similar code.

Is a library easier to maintain and handle than just a set of table values?

Anyways it ends up in a representation of a mapping function with two
input parameters (voltage and charge/discharge indication).

My proposal: keep it simple for everybody. And I can’t imagine something
easier than a mapping table.

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe devicetree 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 17.03.2015 um 09:48 schrieb Pavel Machek pa...@ucw.cz:

 
 Temperature calibration should have already been done in the underlaying 
 twl4030 iio driver.
 
 Discharge rate is the real current flow reported in uA. Also
 reported by iio.
 
 Ack, but there's rather severe temperature dependency of the lithium
 battery, which you should take into account if you want to compute
 “percentage charged.

We just want to estimate it as good as possible. 5-10% is sufficient
and better than no value at all (which is what you get without this
driver).

And, we just convert the (existing) driver from non-DT to DT and to use
iio, so we do not want to change the inner logic what it does and how it
works.

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe devicetree 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 17.03.2015 um 09:47 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..bb3580c
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery
 + - capacity-uah : battery capacity in uAh
 
 Could we make it capacity-uAh ?
 This name was suggested by Mark Rutland [1] and naming convention
 should be all lowercase. There exists already bindings
 without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
 
 Messing up SI units due to convention is _stupid_. Don't do it.
 
 to introduce coefficients for temperature and discharge rate?
 What do you mean? Nothing like that is used in current driver why do
 we need to add it?
 
 Well, conversion between Li-ion's voltage and state of charge at 0
 current is well known:
 
def percent(m, v):
   u = 0.0387-(1.4523*(3.7835-v))
if u  0:
return 0
  return (0.1966+math.sqrt(u))*100

I forgot to ask: does the kernel have a sqrt() function?
 
 And there's not much to calibrate there, and it should become library
 helper function; there's no need to write it to every single dts.
 
 The charge/discharge difference is due to internal battery resistance,
 and Ohm's law. (Then, you should not need different values for
 charging/discharging case.)
 
 With your aproach, you'll get lower percentage when phone is under
 load vs. idle. Taking internal resistance into account would give you
 more precise readings. (Attached, old patch for zaurus shows the
 needed computation).
 
 And if you wanted even more precise readings... internal resistance
 depends on temperature.
 
 I guess this should go into library somewhere, because many machines
 need similar code.
 
   Pavel
 -- 
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 zbattery.10.diff

--
To unsubscribe from this list: send the line unsubscribe devicetree 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 11:37 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 to introduce coefficients for temperature and discharge rate?
 What do you mean? Nothing like that is used in current driver why do
 we need to add it?
 
 Well, conversion between Li-ion's voltage and state of charge at 0
 current is well known:
 
 We can’t measure at 0 current since the OMAP is driven from battery
 and charger and may also draw some mA…
 
 Yes, but you know how many mA you are taking just now. So if you knew
 the internal resistance, you could compute the voltage at 0
 current. (And it should also work during charging, as long as you know
 how much current is going in.)

As far as I understand the twl4030 charger and MADC it is not possible to
separate these values. It is only reporting the inflow from charger to
battery + system. So you don’t know how many mA are supplying the system
and how many mA are left over for charging.

You can only assume how much the system is drawing while running (something
between 50 and 600 mA but this depends on system activities, power state
of peripherald and e.g. backlight being switched on).

I think your basic assumption that we know any time how many mA the system
is taking is not given.

 
   def percent(m, v):
 u = 0.0387-(1.4523*(3.7835-v))
   if u  0:
   return 0
 return (0.1966+math.sqrt(u))*100
 
 And there's not much to calibrate there, and it should become library
 helper function; there's no need to write it to every single dts.
 
 The charge/discharge difference is due to internal battery resistance,
 and Ohm's law. (Then, you should not need different values for
 charging/discharging case.)
 
 Yes, and that also depends on the board and battery type. So you always
 need to specify some battery specific coefficient for that in the DT.
 
 Yes, and that coefficient should be internal battery resistance ;-).

But where do you know this value from to write it into a DT file?
Usually you can’t measure it easily and for some batteries you don’t have
a data sheet.

Contrary, the calibration curves can easily be measured on the device
(assuming that the charge level decreases/increases linearly over time
between Full and Empty).

I tend to make software easy to use for the user (developer of a board support
package) of a driver, not theoretically correct or mathematically elegant.

 
 We simply did choose a table, because calculating the right coefficients
 is more complex and getting the table values can easily be done from
 running one full charge-discharge-charge cycle.
 
 Well.. One set of coefficients would be kind of ok. But you are doing
 two, because it really depends on current, not charge/discharge. So
 why not do it right, for all currents…?

Because the right solution for all these issues is to use a fuel gauge chip
(bq27xxx).

This driver is just for systems where the hardware designer did forget
(or did not want to spend money) for such a chip, but user space
expects some /sys/class/power_supply indication (e.g. Android/Replicant).

The missing optimal precision is something we can live with.

 
 With your aproach, you'll get lower percentage when phone is under
 load vs. idle. Taking internal resistance into account would give you
 more precise readings. (Attached, old patch for zaurus shows the
 needed computation).
 
 This is why we have a charging and a discharging table to compensate
 for this effect.
 
 Yes, but there's very different current during idle phone and during
 call (for example). So yes, you are compensating for different current
 during charge and discharge, but it is possible to do better.

I am not convinced that it can be really done better, considering the
limitations of the twl4030 circuits, and I doubt that it is worth the efforts
of doing it better.

 
 I guess this should go into library somewhere, because many machines
 need similar code.
 
 Is a library easier to maintain and handle than just a set of table
 values?
 
 I think so, yes, because otherwise you need a set of tables for each
 machine.

Yes, but what is the problem? We have different device trees for each
machine anyways. And as soon as they differ in battery characteristics
the coefficients for your calculation have to be defined for each machine.

So someone has to write in some DT values (difficult to understand
and derive coefficients or two simple mapping tables).

To me it looks as if you want to make it a 100% solution while I am happy
with the 80% solution, which already exists as a platform data driver and
just want to get it back into DT based boards.

So I would suggest that Mareks patches to make the platform data
driver DT compatible are applied first, and you are invited to submit a
technically better solution for testing on real hardware.

BR,
Nikolaus

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

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 14:59 schrieb Pavel Machek pa...@ucw.cz:

 Hi!
 
 to introduce coefficients for temperature and discharge rate?
 What do you mean? Nothing like that is used in current driver why do
 we need to add it?
 
 Well, conversion between Li-ion's voltage and state of charge at 0
 current is well known:
 
 We can’t measure at 0 current since the OMAP is driven from battery
 and charger and may also draw some mA…
 
 Yes, but you know how many mA you are taking just now. So if you knew
 the internal resistance, you could compute the voltage at 0
 current. (And it should also work during charging, as long as you know
 how much current is going in.)
 
 As far as I understand the twl4030 charger and MADC it is not possible to
 separate these values. It is only reporting the inflow from charger to
 battery + system. So you don’t know how many mA are supplying the system
 and how many mA are left over for charging.
 
 You can only assume how much the system is drawing while running (something
 between 50 and 600 mA but this depends on system activities, power state
 of peripherald and e.g. backlight being switched on).
 
 I think your basic assumption that we know any time how many mA the system
 is taking is not given.
 
 So.. you won't be able to get exact value while charging, but you
 get one while discharging, which is what really matters…?

Is it the same during charging?

And, as we already discussed it depends on the situation.

In addition, GSM power consumption runs in bursts and I don’t know if the sample
rate of the MADC is good enough to track that correctly.

 
 Yes, and that coefficient should be internal battery resistance ;-).
 
 But where do you know this value from to write it into a DT file?
 Usually you can’t measure it easily and for some batteries you don’t have
 a data sheet.
 
 Contrary, the calibration curves can easily be measured on the device
 (assuming that the charge level decreases/increases linearly over time
 between Full and Empty).
 
 If you can copy it from the data sheet, that's the easiest option. If
 not, you should be able to easily compute it from the charge/discharge
 curves or from measured voltage at different loads.

Well, this again assumes that you can generate/control different loads
easily (e.g. turn on/off this and that peripheral) to check the voltage
drop. Sounds good in theory, but I don’t want to do it in practice to
derive this parameter.

And, don’t forget that the MADC signals are nosiy and don’t have the
best precision. So it is likely that you get wrong values.

As said, I think it is not worth the effort around the imperfect twl4030/MADC
charging system.

If someone wants precise data, that is what fuel gauge chips are good for.
And we already have drivers for them.

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe devicetree 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 16.03.2015 um 22:20 schrieb Belisko Marek marek.beli...@gmail.com:

 On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek pa...@ucw.cz wrote:
 On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
 .../bindings/power_supply/twl4030_madc_battery.txt | 43 
 ++
 1 file changed, 43 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..bb3580c
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery
 + - capacity-uah : battery capacity in uAh
 
 Could we make it capacity-uAh ?
 This name was suggested by Mark Rutland [1] and naming convention
 should be all lowercase. There exists already bindings
 without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
 
 + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
 + for charging calibration (see example)
 + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
 + for discharging calibration (see example)
 
 Would mV-to-capacity... be more accurate? Also, would it make sense
 Again maybe mv but it can be added also later.
 to introduce coefficients for temperature and discharge rate?
 What do you mean? Nothing like that is used in current driver why do
 we need to add it?

Temperature calibration should have already been done in the underlaying 
twl4030 iio driver.

Discharge rate is the real current flow reported in uA. Also reported by iio.

 
 Thanks,
Pavel
 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 
 [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104
 
 BR,
 
 marek
 

BR,
Nikolaus


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

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 11.03.2015 um 16:24 schrieb Tony Lindgren t...@atomide.com:

 Hi,
 
 * Marek Belisko ma...@goldelico.com [150310 14:28]:
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
 .../bindings/power_supply/twl4030_madc_battery.txt | 43 
 ++
 1 file changed, 43 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..d3dd9d8
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery
 + - capacity-uah : battery capacity in uAh
 + - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
 +for charging calibration (see example)
 + - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
 +for discharging calibration (see example)
 + - io-channels: Should contain IIO channel specifiers
 +for each element in io-channel-names.
 +- io-channel-names: Should contain the following values:
 + * temp - The ADC channel for temperature reading
 + * ichg - The ADC channel for battery charging status
 + * vbat - The ADC channel to measure the battery voltage
 +
 +Example:
 +madc-battery {
 +compatible = ti,twl4030-madc-battery;
 +capacity-uah = 120;
 +ti,volt-to-capacity-charging-map = 4200 100,
 +4100 75,
 +4000 55,
 +3900 25,
 +3800 5,
 +3700 2,
 +3600 1,
 +3300 0;
 +
 +ti,volt-to-capacity-discharging-map = 4200 100
 +   4100 95,
 +   4000 70,
 +   3800 50,
 +   3700 10,
 +   3600 5,
 +   3300 0;
 +io-channels = twl_madc 1,
 +  twl_madc 10,
 +  twl_madc 12;
 +io-channel-names = temp,
 +   ichg,
 +   vbat;
 +};
 
 Rather than just making platform_data into device tree properties..
 
 Can't you hide the these custom properties behind the compatible flag?
 
 You can initialize that data in the driver based on the compatible
 flag and the match data.
 
 This makes sense if you can group things to similar configurations.

Maybe I have not completely understood your proposal.

Do you mean to go back to have big parameter tables for each device/battery
combination in the driver code and the compatible flag (e.g. compatible = 
“board17”)
chooses the right data set for the charging map and channels?

I thought this is what the DT was introduced for - to have the same driver 
code but adapt to different boards depending on hardware variations.

And batteries have very different characteristics and vary between devices…

The charging maps are depending on the battery type connected to the twl4030
and which madc channel is which value is also a little hardware dependent
(although the twl4030 doesn’t give much choice).

And moving this information into the driver for each board that uses it
would blow up the code.

BR,
Nikolaus

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

Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 11.03.2015 um 17:44 schrieb Tony Lindgren t...@atomide.com:

 * Dr. H. Nikolaus Schaller h...@goldelico.com [150311 09:17]:
 Hi,
 
 Am 11.03.2015 um 16:24 schrieb Tony Lindgren t...@atomide.com:
 
 Hi,
 
 * Marek Belisko ma...@goldelico.com [150310 14:28]:
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
 .../bindings/power_supply/twl4030_madc_battery.txt | 43 
 ++
 1 file changed, 43 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 new file mode 100644
 index 000..d3dd9d8
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
 @@ -0,0 +1,43 @@
 +twl4030_madc_battery
 +
 +Required properties:
 + - compatible : ti,twl4030-madc-battery
 + - capacity-uah : battery capacity in uAh
 + - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
 +  for charging calibration (see example)
 + - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) 
 values
 +  for discharging calibration (see example)
 + - io-channels: Should contain IIO channel specifiers
 +  for each element in io-channel-names.
 +- io-channel-names: Should contain the following values:
 + * temp - The ADC channel for temperature reading
 + * ichg - The ADC channel for battery charging status
 + * vbat - The ADC channel to measure the battery voltage
 +
 +Example:
 +  madc-battery {
 +  compatible = ti,twl4030-madc-battery;
 +  capacity-uah = 120;
 +  ti,volt-to-capacity-charging-map = 4200 100,
 +  4100 75,
 +  4000 55,
 +  3900 25,
 +  3800 5,
 +  3700 2,
 +  3600 1,
 +  3300 0;
 +
 +  ti,volt-to-capacity-discharging-map = 4200 100
 + 4100 95,
 + 4000 70,
 + 3800 50,
 + 3700 10,
 + 3600 5,
 + 3300 0;
 +  io-channels = twl_madc 1,
 +twl_madc 10,
 +twl_madc 12;
 +  io-channel-names = temp,
 + ichg,
 + vbat;
 +  };
 
 Rather than just making platform_data into device tree properties..
 
 Can't you hide the these custom properties behind the compatible flag?
 
 You can initialize that data in the driver based on the compatible
 flag and the match data.
 
 This makes sense if you can group things to similar configurations.
 
 Maybe I have not completely understood your proposal.
 
 Do you mean to go back to have big parameter tables for each device/battery
 combination in the driver code and the compatible flag (e.g. compatible = 
 “board17”)
 chooses the right data set for the charging map and channels?
 
 If you can somehow group them, then yes.

I don’t see how to group them. Could you make a proposal?

 Not for every board if there
 are many of them naturally.
 
 I thought this is what the DT was introduced for - to have the same driver 
 code but adapt to different boards depending on hardware variations.
 
 Yeah but you also need to consider the issues related to introducing
 new device tree properties. The device tree properties introduced
 should be generic where possible.

Yes, that was discussed for a while for this driver’s bindings leading to v4.

Which ones do you think are not generic enough?

 
 And batteries have very different characteristics and vary between devices…
 
 Right. Maybe that has been already agreed on to use capacity-uah for
 batteries in general?

Ah, do you mean with generic/not generic the distinction between a “ti,” prefix
and no prefix?

Well, I don’t know if there is such an agreement and I would have no argument
against calling it “ti,capacity-uah”.

 In that case I have not problem with that as
 it’s a generic property :)

Well, many batteries and systems have a fuel gauge chip (e.g. bq27000). This
chip “knows” the capacity. But therefore it is not needed to specify
it anywhere because it can be read out (usually in uAh).

This driver is to solve the issue that there is no such factory-programmed
battery or fuel gauge chip connected to a twl4030 driver. Nobody can program
that capacity value - except someone matching the device tree with real 
hardware.

And, by doing and averaging some charge-discharge cycles the fuel gauge
mapping is calibrated.

 
 The charging maps are depending on the battery type

Re: [PATCH 1/4] ARM: dts: omap3-pandora: add common device tree

[Dr. H. Nikolaus Schaller]

Am 12.02.2015 um 18:47 schrieb Grazvydas Ignotas nota...@gmail.com:

 On Thu, Feb 12, 2015 at 3:03 PM, Marek Belisko ma...@goldelico.com wrote:
 From: H. Nikolaus Schaller h...@goldelico.com
 
 This device tree allows to boot, supports the panel,
 framebuffer, touch screen, as well as some more peripherals.
 Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
 1 GHz variant we must include this common device tree code
 in one of two CPU specific device trees.
 
 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 Signed-off-by: Marek Belisko ma...@goldelico.com
 ---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 641 
 
 1 file changed, 641 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
 
 diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
 b/arch/arm/boot/dts/omap3-pandora-common.dtsi
 new file mode 100644
 index 000..0a2a878
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
 @@ -0,0 +1,641 @@
 
 ...
 
 +
 +   gpio-leds {
 +
 +   compatible = gpio-leds;
 +
 +   pinctrl-names = default;
 +   pinctrl-0 = led_pins;
 +
 +   led@1 {
 +   label = pandora::sd1;
 +   gpios = gpio5 0 GPIO_ACTIVE_HIGH;/* GPIO_128 
 */
 +   linux,default-trigger = mmc0;
 +   default-state = off;
 +   };
 +
 +   led@2 {
 +   label = pandora::sd2;
 +   gpios = gpio5 1 GPIO_ACTIVE_HIGH;/* GPIO_129 
 */
 +   linux,default-trigger = mmc1;
 +   default-state = off;
 +   };
 +
 +   led@3 {
 +   label = pandora::bluetooth;
 +   gpios = gpio5 30 GPIO_ACTIVE_HIGH;   /* GPIO_158 
 */
 +   linux,default-trigger = heartbeat;
 
 I’d prefer this had no trigger, but no strong feelings here.

Ok. Well, this is more or less our testing setup - so that we did see something 
before
we could fix the display setup. I think practice will show what is better, and 
then
it can be patched. We are at the beginning of Pandora DT work…

 
 +   default-state = off;
 +   };
 +
 +   led@4 {
 +   label = pandora::wifi;
 +   gpios = gpio5 31 GPIO_ACTIVE_HIGH;   /* GPIO_159 
 */
 +   linux,default-trigger = mmc2;
 +   default-state = off;
 +   };
 +   };
 +
 +   gpio-keys {
 +   compatible = gpio-keys;
 +
 +   pinctrl-names = default;
 +   pinctrl-0 = button_pins;
 +
 +   up-button {
 +   label = up;
 +   linux,code = KEY_UP;
 +   gpios = gpio4 14 GPIO_ACTIVE_HIGH;   /* GPIO_110 
 */
 +   gpio-key,wakeup;
 +   };
 +
 +   down-button {
 +   label = down;
 +   linux,code = KEY_DOWN;
 +   gpios = gpio4 7 GPIO_ACTIVE_HIGH;/* GPIO_103 
 */
 +   gpio-key,wakeup;
 +   };
 +
 +   left-button {
 +   label = left;
 +   linux,code = KEY_LEFT;
 +   gpios = gpio4 0 GPIO_ACTIVE_HIGH;/* GPIO_96 */
 +   gpio-key,wakeup;
 +   };
 +
 +   right-button {
 +   label = right;
 +   linux,code = KEY_RIGHT;
 +   gpios = gpio4 2 GPIO_ACTIVE_HIGH;/* GPIO_98 */
 +   gpio-key,wakeup;
 +   };
 +
 +   pageup-button {
 +   label = game 1;
 +   linux,code = KEY_PAGEUP;
 +   gpios = gpio4 13 GPIO_ACTIVE_HIGH;   /* GPIO_109 
 */
 +   gpio-key,wakeup;
 +   };
 +
 +   pagedown-button {
 +   label = game 3;
 +   linux,code = KEY_PAGEDOWN;
 +   gpios = gpio4 10 GPIO_ACTIVE_HIGH;   /* GPIO_106 
 */
 +   gpio-key,wakeup;
 +   };
 +
 +   home-button {
 +   label = game 4;
 +   linux,code = KEY_HOME;
 +   gpios = gpio4 5 GPIO_ACTIVE_HIGH;/* GPIO_101 
 */
 +   gpio-key,wakeup;
 +   };
 +
 +   end-button {
 +   label = game 2;
 +   linux,code = KEY_END;
 +   gpios = gpio4 15 GPIO_ACTIVE_HIGH;   /* GPIO_111 
 */
 +   gpio-key,wakeup;
 +   };
 +
 +   right-shift {
 +   label = l;
 +   linux,code = KEY_RIGHTSHIFT

Re: [PATCH 1/4] ARM: dts: omap3-pandora: add common device tree

[Dr. H. Nikolaus Schaller]

Am 12.02.2015 um 17:03 schrieb Tony Lindgren t...@atomide.com:

 Hi,
 
 Few comments below.
 
 * Marek Belisko ma...@goldelico.com [150212 05:07]:
 +
 +omap3_pmx_core {
 +
 +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 */
 +;
 ...
 
 +omap3_pmx_core2 {
 +/* define in CPU specific file that includes this one
 + * use either OMAP3430_CORE2_IOPAD() or OMAP3630_CORE2_IOPAD()
 + */
 +};
 
 OK looks like you have some SoC specific pins too.. I assume you
 guys have checked that all the pins defined in this file are at
 the same offset between 34xx and 36xx variants?

Yes. All in this file are common between 34xx and 36xx.
The 600mhz / 1ghz files cover the differences for pmx_core2 through the 
different macros
(OMAP3430_CORE2_IOPAD vs. OMAP3460_CORE2_IOPAD).

 
 +i2c1 {
 +clock-frequency = 260;
 +
 +twl: twl@48 {
 +reg = 0x48;
 +interrupts = 7; /* SYS_NIRQ cascaded to intc */
 +interrupt-parent = intc;
 +
 +twl_power: power {
 +compatible = ti,twl4030-power-reset;
 +ti,use_poweroff;
 +};
 +
 +twl_audio: audio {
 +compatible = ti,twl4030-audio;
 +
 +codec {
 +ti,ramp_delay_value = 3;
 +};
 +};
 +};
 +};
 
 Can be done later naturally, but ere you probably want
 ti,twl4030-power-idle or ti,twl4030-power-idle-osc-off
 if the osicllator can be shut down during off-idle.

Good hint. We have to check and test if it can be shut down.
But as said, this is just the beginning of DT support.

 
 +gpmc {
 +ranges = 0 0 0x3000 0x04; /* CS0: NAND */
 
 The ranges here allocate the GPMC partition, so it needs to be
 a minimum of 16MB:
 
   ranges = 0 0 0x3000 0x100,/* CS0: 16MB for NAND */
 
 +nand@0,0 {
 +reg = 0 0 0; /* CS0, offset 0 */
 
 The reg is for the device driver to ioremap it's registers,
 for NAND it's just 4:
 
   reg = 0 0 4;  /* CS0, offset 0, IO size 4 */

Ok, that was a typo and we have not tested how compatible it is to the
board file scheme.

 
 +filesystem@68 {
 +label = rootfs;
 +reg = 0xc8 0; /* 0 = MTDPART_SIZ_FULL */
 +};
 +};
 +};
 
 Is the NAND the same size on all of them?

AFAIK not necessarily.

 I don't think dts
 has a binding for MTDPART_SIZ_FULL type thing..

It does not need a special binding, we just set the size to 0. This
is interpreted as MTDPART_SIZ_FULL later on. For board files,
there is just a #define in include/linux/mtd/partitions.h and it appears
to work.

 
 +lcd: lcd@1 {
 +reg = 1;  /* CS1 */
 +compatible =omapdss,tpo,td043mtea1;
 +spi-max-frequency = 10;
 +spi-cpol;
 +spi-cpha;
 +
 +label = lcd;
 +reset-gpios = gpio5 29 GPIO_ACTIVE_LOW;  /* GPIO_157 */
 +vcc-supply = vaux1;
 +
 +port {
 +lcd_in: endpoint {
 +remote-endpoint = dpi_out;
 +};
 +};
 +};
 
 Oh there's already a binding for the LCD too? That’s great :)

Yes, we were happy to find that the panel driver has already been upgraded
for DT use.

 
 Nine job, good to see this happening!
 
 Regards,
 
 
 Tony

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe devicetree 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] input: tsc2007: Add pre-calibration, flipping and rotation

[Dr. H. Nikolaus Schaller]

Am 15.01.2015 um 19:16 schrieb Dmitry Torokhov dmitry.torok...@gmail.com:

 On Thu, Jan 15, 2015 at 05:14:38PM +0100, Dr. H. Nikolaus Schaller wrote:
 
 Am 15.01.2015 um 15:38 schrieb Sebastian Reichel s...@kernel.org:
 
 Hi,
 
 On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote:
 1. Perform conversion in input core rather than individual drivers. I
 think we should allocate a new bitmaps for some transformations and have
 the code do X/Y flip/clip of the coordinates.
 
 Do you have a suggestion where this should be (I have no clue how
 the input system works or is structured - we just know how to extend a
 driver that uses it)?
 
 2. Standardize on bindings. We already have of-touchscreen.c doing
 rudimentary parsing, we shoudl look into extending it rather than
 creating myriad of driver-specific bindings.
 
 Ok, looks reasonable.
 
 Documentation is in 
 
 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 I did look into it now. Unfortunately, it does not fit well into my view of 
 how bindings
 should be. They should describe hardware (as we are told for many other 
 kernel
 subsystems).
 
 Pixels and resolutions are IMHO related to the screen it is glued on - and 
 that is
 quite independent.
 
 Well, I think pixels was the wrong word to be used there. It is meant to
 be native units, as opposed to millimeters, inches, points, etc.

ok.

 
 
 So I don’t see how they do describe the different ways the touch screen can 
 be
 wired to a tsc2007 controller.
 
 Please can you add minimum and maximum properties for us?
 
 Then, inverted-x and inverted-y is redundant because it is the same as having
 an expected higher value from the ADC for the minimum coordinate and a lower
 for the maximum.
 
 I'd rather not add minimum and maximum, but add the touchscreen-start-x and
 touchscreen-start-y instead so that we limit the number of obsolete
 properties.

ok, that should not be too difficult to add.

So we will modify our driver to use the new functions and align 
omap3-gta04.dtsi accordingly.

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe devicetree 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] input: tsc2007: Add pre-calibration, flipping and rotation

[Dr. H. Nikolaus Schaller]

Hi,

Am 15.01.2015 um 15:38 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote:
 1. Perform conversion in input core rather than individual drivers. I
 think we should allocate a new bitmaps for some transformations and have
 the code do X/Y flip/clip of the coordinates.
 
 Do you have a suggestion where this should be (I have no clue how
 the input system works or is structured - we just know how to extend a
 driver that uses it)?
 
 2. Standardize on bindings. We already have of-touchscreen.c doing
 rudimentary parsing, we shoudl look into extending it rather than
 creating myriad of driver-specific bindings.
 
 Ok, looks reasonable.
 
 Documentation is in 
 
 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Also, do we need swap and flip or do we simply need rotation (like the
 proposed Broadcom iproc driver has)?
 
 Well, since the DT should describe hardware, there are 3 sets of wires which
 can have a cross-over: X+ and X-, Y+ and Y-, X and Y.
 
 So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an
 interpretation of the result of these connections in combination with some
 panel the touch is glued to and should therefore not be represented in the 
 DT.
 
 As a result we have proposed a scheme without explicit rotation. We specify 
 what
 coordinates X- and X+ should report at their ends (min, max) because the DT
 programmer has to specify them anyways. Flipping is a result of defining 
 these
 coordinates in an ascending or descending way. Only swapping of the X and Y
 wires can’t be implicitly defined so it has its own property. So the scheme 
 we
 have proposed tries to optimize the efforts needed to adapt new boards and 
 write
 DTs and focus the DT on hardware description.
 
 As a bonus we also specify the min and max value to be reported for the touch
 pressure (Z axis) using the same basic principle.
 
 And it is a pure add-on on top of the existing driver so that it attempts not
 to break existing device trees.
 
 from what I can see there are no in-tree-users using any of the
 new properties.

Not yet. But our [patch 2/3] of this series defines the DT entry for the GTA04 
devices:

https://lkml.org/lkml/2014/9/30/663

 
 Maybe could you accept it as a first step for this specific driver (and 
 let’s do
 the big standardization work later on)?
 
 That does not work, since you create an ABI.

Hm. I don’t understand what you mean with creating an ABI?




--
To unsubscribe from this list: send the line unsubscribe devicetree 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] input: tsc2007: Add pre-calibration, flipping and rotation

[Dr. H. Nikolaus Schaller]

Am 15.01.2015 um 15:38 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote:
 1. Perform conversion in input core rather than individual drivers. I
 think we should allocate a new bitmaps for some transformations and have
 the code do X/Y flip/clip of the coordinates.
 
 Do you have a suggestion where this should be (I have no clue how
 the input system works or is structured - we just know how to extend a
 driver that uses it)?
 
 2. Standardize on bindings. We already have of-touchscreen.c doing
 rudimentary parsing, we shoudl look into extending it rather than
 creating myriad of driver-specific bindings.
 
 Ok, looks reasonable.
 
 Documentation is in 
 
 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

I did look into it now. Unfortunately, it does not fit well into my view of how 
bindings
should be. They should describe hardware (as we are told for many other kernel
subsystems).

Pixels and resolutions are IMHO related to the screen it is glued on - and that 
is
quite independent.

So I don’t see how they do describe the different ways the touch screen can be
wired to a tsc2007 controller.

Please can you add minimum and maximum properties for us?

Then, inverted-x and inverted-y is redundant because it is the same as having
an expected higher value from the ADC for the minimum coordinate and a lower
for the maximum.

 
 Also, do we need swap and flip or do we simply need rotation (like the
 proposed Broadcom iproc driver has)?
 
 Well, since the DT should describe hardware, there are 3 sets of wires which
 can have a cross-over: X+ and X-, Y+ and Y-, X and Y.
 
 So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an
 interpretation of the result of these connections in combination with some
 panel the touch is glued to and should therefore not be represented in the 
 DT.
 
 As a result we have proposed a scheme without explicit rotation. We specify 
 what
 coordinates X- and X+ should report at their ends (min, max) because the DT
 programmer has to specify them anyways. Flipping is a result of defining 
 these
 coordinates in an ascending or descending way. Only swapping of the X and Y
 wires can’t be implicitly defined so it has its own property. So the scheme 
 we
 have proposed tries to optimize the efforts needed to adapt new boards and 
 write
 DTs and focus the DT on hardware description.
 
 As a bonus we also specify the min and max value to be reported for the touch
 pressure (Z axis) using the same basic principle.
 
 And it is a pure add-on on top of the existing driver so that it attempts not
 to break existing device trees.
 
 from what I can see there are no in-tree-users using any of the
 new properties.
 
 Maybe could you accept it as a first step for this specific driver (and 
 let’s do
 the big standardization work later on)?
 
 That does not work, since you create an ABI.
 
 -- Sebastian

--
To unsubscribe from this list: send the line unsubscribe devicetree 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] input: tsc2007: Add pre-calibration, flipping and rotation

[Dr. H. Nikolaus Schaller]

Hi,

Am 15.01.2015 um 01:59 schrieb Dmitry Torokhov dmitry.torok...@gmail.com:

 On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote:
 Ping for input maintainer. DT changes was acked. Thanks.
 
 On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko ma...@goldelico.com wrote:
 This patch adds new parameters that allow to address typical hardware
 design differences: touch screens may be wired or oriented differently
 (portrait or landscape). And usually the active area of the touch is a
 little larger than the active area of the LCD. This results in the touch
 coordinates that have some significant deviation from LCD coordinates.
 Usually this is addressed in user space by a calibration tool (e.g. tslib
 or xinput-calibrator) but some systems don't have these tools or require
 that the screen is already roughly calibrated (e.g. Replicant) to operate
 the device until a better calibration can be done. And, some systems
 react very strangely if the touch event stream reports coordinates
 outside of the active area.
 
 This makes it necessry to be able to configure:
 1. swapping x and y wires (coordinate values)
 2. flipping of x (left - right) or y (top - bottom) or even both
 3. define an active area so that an uncalibrated screen already
 roughly matches the LCD to be useful.
 4. clip reported coordinates to the active area.
 
 If none of the new parameters is defined (in DT) or set in a board file,
 the driver behaves the same as without this patch.
 
 Author (12): H. Nikolaus Schaller h...@goldelico.com
 Author (34): Paul Kocialkowski cont...@paulk.fr
 
 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 
 OK, I was hesitant of adding these as normally we have tslib to perform
 the conversion, but maybe it is time to allow it in the kernel and
 standardize users.

Well, tslib isn’t a good replacement for this problem any more and
pre-initializing tslib makes some deep hardware dependency visible
in user space (each board needs a different tslib config and pointercal
default - and on some user spaces tslib is broken with Xorg).

But the issue to be solved is more hardware related, i.e. if the Y- and Y+
pins of the controller are connected in a swapped way to the resistor
ends of the panel.

Hence in a DT based system, this must IMHO be described by the DT
and can not be left to some user-space functions any more.

 However, this seems like a general issue and we
 should:
 
 1. Perform conversion in input core rather than individual drivers. I
 think we should allocate a new bitmaps for some transformations and have
 the code do X/Y flip/clip of the coordinates.

Do you have a suggestion where this should be (I have no clue how
the input system works or is structured - we just know how to extend a
driver that uses it)?

 
 2. Standardize on bindings. We already have of-touchscreen.c doing
 rudimentary parsing, we shoudl look into extending it rather than
 creating myriad of driver-specific bindings.

Ok, looks reasonable.

 
 Also, do we need swap and flip or do we simply need rotation (like the
 proposed Broadcom iproc driver has)?

Well, since the DT should describe hardware, there are 3 sets of wires which
can have a cross-over: X+ and X-, Y+ and Y-, X and Y.

So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an
interpretation of the result of these connections in combination with some
panel the touch is glued to and should therefore not be represented in the DT.

As a result we have proposed a scheme without explicit rotation. We specify what
coordinates X- and X+ should report at their ends (min, max) because the DT
programmer has to specify them anyways. Flipping is a result of defining these
coordinates in an ascending or descending way. Only swapping of the X and Y
wires can’t be implicitly defined so it has its own property. So the scheme we
have proposed tries to optimize the efforts needed to adapt new boards and write
DTs and focus the DT on hardware description.

As a bonus we also specify the min and max value to be reported for the touch
pressure (Z axis) using the same basic principle.

And it is a pure add-on on top of the existing driver so that it attempts not
to break existing device trees.

Maybe could you accept it as a first step for this specific driver (and let’s do
the big standardization work later on)?

— hns


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

Re: [Gta04-owner] [PATCH 1/2] mmc: core: allow a reset gpio to be configured.

[Dr. H. Nikolaus Schaller]

Hi Neil,

Am 02.12.2014 um 02:55 schrieb NeilBrown ne...@suse.de:

 On Fri, 28 Nov 2014 12:56:33 +0100 Ulf Hansson ulf.hans...@linaro.org wrote:
 
 On 8 November 2014 at 01:14, NeilBrown ne...@suse.de wrote:
 If the regulator supplying an SDIO device is shared
 with another device, the turning the regulator 'on' and 'off'
 will not actually cycle power and so will not reset
 the device.
 
 This is particularly a problem for some wi2si wireless modules which
 have a BT module on chip and can share power lines.
 Without the power-cycle, subsequent reset commands fail.
 
 So allow a 'reset' gpio to be specified.  If provided, the
 line is asserted during power-up.
 
 There have been several attempts to fix similar issues as this patch
 does. The latest one I posted a few month ago, which wasn't accepted.
 http://comments.gmane.org/gmane.linux.power-management.general/46635
 
 Thanks for that link.
 
 
 There has also been some off-list discussions on especially how we
 should describe this in DT and there were actually some consensus made
 around that. Still I haven't seen any patches on the mailing lists.
 
 Wish I could have a link for those off-list discussions :-)
 
 Based on what I read and my own thoughts about other devices that I'm having
 trouble managing I wonder if the right approach might be to admit that these
 buses are *not* 100% discoverable.
 
 i.e. you can discover what is there once it is turned on, but you cannot
 discover how to turn it on.

Indeed.

 
 So the *fix* is to allow attached devices to be explicitly listed.
 In my case I would create a child node of the mmc1 node, which is
 compatible=“libertas,wifi (or whatever the proper name is).

Sounds like a good idea to me.

 
 Then when the mmc1 wants to power-up, it does:
 
   device_for_each_child(mmc_dev, NULL, power_up)
 
 where:
 
 static int power_up(struct device *dev, void *data)
 {
   pm_runtime_get_sync(dev);
   return 0;
 }
 
 Then I can put my reset-line management in the libertas driver instead of
 trying to include some of it in the mmc driver.
 
 This has the advantage of the devicetree actually describing the hardware
 (there is a libertas wifi SDIO chip attached) rather than the behaviour
 (please turn on this regulator and toggle this GPIO to initialise the device).
 
 I want to do a very similar thing for UARTs (so my GPS and Bluetooth turn on
 when /dev/ttyO? is opened), and I've been thinking about something similar
 for USB - I have a USB attached GSM module, but it also has an Audio link and
 some reset/interrupt lines that need to be configured.
 If I could say to device tree This USB port has this device attached, I
 think it would be a step in the right direction.

Thinking a little further, it could either be the core driver of the 
device/bus/protocol
or a special driver that only does power management. Or audio.

And we should consider using a list of strings in the compatible entry so that
several drivers can be loaded if the subsystem structure shows that this is 
simpler.

It could be one for power, one for audio. Or in the case of the libertas a 
separate
powerreset driver for a specific chip that uses the libertas driver so that 
chip
specific reset management is not introduced into the libertas core but separate.

For the usb connected modem the subnode to be attached is likely the PHY
where the self-powered device is connected to.

 
 
 
 
 So to summarize, I am really concerned that we keep having these power
 sequence issues for SDIO devices and right now the discussion has been
 on hold. I am considering to hack on it myself, since I am tired of
 waiting. :-)
 
 Please Cc me if you do.  Meanwhile I'll try to hack together code supporting
 my latest idea and let you know if I get anywhere.
 
 
 Regarding this patch, I don't intent to apply it.
 
 Fair enough, I’m starting to not like it so much anyway.
 

BR,
Nikolaus

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

Re: [PATCH v2 1/5] video: omapdss: Add opa362 driver

[Dr. H. Nikolaus Schaller]

Am 13.11.2014 um 17:41 schrieb Tomi Valkeinen tomi.valkei...@ti.com:

 On 13/11/14 18:25, Dr. H. Nikolaus Schaller wrote:
 Hi,
 
 Am 13.11.2014 um 12:51 schrieb Tomi Valkeinen tomi.valkei...@ti.com:
 
 On 13/11/14 00:10, Marek Belisko wrote:
 opa362 is amplifier for video and can be connected to the tvout pads
 of the OMAP3. It has one gpio control for enable/disable of the output
 (high impedance).
 
 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 ---
 drivers/video/fbdev/omap2/displays-new/Kconfig |   6 +
 drivers/video/fbdev/omap2/displays-new/Makefile|   1 +
 .../fbdev/omap2/displays-new/amplifier-opa362.c| 343 
 +
 
 I think it would be better to rename this to encoder-opa362.c. It's not
 
 When developing this driver we did simply rename the encoder-tfp410 file,
 but thent hough that it does not fit into the „encoder“ category, because we
 would expect something digital or digital to analog „encoding“ which it does 
 not.
 
 That is true, but we already have other encoders like
 encoder-tpd12s015.c, which also do not encode. encoder in this context
 means something that takes a video input, and has a video output. In
 contrast to a panel or a connector.
 
 +
 +  in-ops.atv-set_timings(in, ddata-timings);
 +  /* fixme: should we receive the invert from our consumer, i.e. the 
 connector? */
 +  in-ops.atv-invert_vid_out_polarity(in, true);
 
 Well this does seem to be broken. I don't know what the answer to the
 question above is, but the code doesn't work properly.
 
 In the opa362_invert_vid_out_polarity function below, you get the invert
 boolean from the connector. This you pass to the OMAP venc. However,
 above you always override that value in venc with true.
 
 So, either the invert_vid_out_polarity value has to be always true or
 false, because _OPA362_ requires it to be true or false, OR you need use
 the value from the connector.
 
 Seeing the comment in opa362_invert_vid_out_polarity, my guess is the
 latter, and the call above should be removed.
 
 Yes, you are right - this is not systematic.
 
 But the problem is that we can’t ask the connector here what it wants
 to see. It might (or might not) call our opa362_invert_vid_out_polarity() 
 later
 which we can then forward to overwrite the inital state of this 
 opa362_enable().
 
 You don't need to ask. The connector calls invert_vid_out_polarity
 before enabling the output.

Unfortunately it doesn’t. At least not always.

It does only for pdata systems but not for DT based systems:

if (!ddata-dev-of_node) {
in-ops.atv-set_type(in, ddata-connector_type);
in-ops.atv-invert_vid_out_polarity(in,
ddata-invert_polarity);
}

Not calling is in our case different from calling with ddata-invert_polarity 
== 0.

 You can just pass it forward inverted, as
 you already do in this driver. If it doesn't, it's either a bug or you
 can just rely on the value that is already programmed to venc.

Therefore it is not called with “false” which would make our 
invert_vid_out_polarity
invert it and send “true” towards the VENC. So VENC remains non-inverted.

We will also add a patch for the connector-analog.c

 We are going to support only DT boot at some point. Thus I think the
 whole platform data code should be left out.
 
 Is there already a decision? I think it should not be done before. And it
 does not harm to still have it.
 
 It's just a matter of time. I don't accept any new boards using platform
 data for display, or new display drivers using platform data, because I
 don't want to spend my time converting them later. And as this is a new
 driver, no existing board can be using the opa362 platform_data. So we
 can support DT only.

Ok, that looks reasonable - as long as we can rely on that all mainline DSS
drivers are already fully converted to DT :)

BR,
Nikolaus

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

Re: [PATCH v2 1/5] video: omapdss: Add opa362 driver

[Dr. H. Nikolaus Schaller]

Hi,

Am 13.11.2014 um 12:51 schrieb Tomi Valkeinen tomi.valkei...@ti.com:

 On 13/11/14 00:10, Marek Belisko wrote:
 opa362 is amplifier for video and can be connected to the tvout pads
 of the OMAP3. It has one gpio control for enable/disable of the output
 (high impedance).
 
 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 ---
 drivers/video/fbdev/omap2/displays-new/Kconfig |   6 +
 drivers/video/fbdev/omap2/displays-new/Makefile|   1 +
 .../fbdev/omap2/displays-new/amplifier-opa362.c| 343 
 +
 
 I think it would be better to rename this to encoder-opa362.c. It's not

When developing this driver we did simply rename the encoder-tfp410 file,
but thent hough that it does not fit into the „encoder“ category, because we
would expect something digital or digital to analog „encoding“ which it does 
not.

 encoder as such, but it falls into the same category.

But we can change it.

 
 include/video/omap-panel-data.h|  12 +
 4 files changed, 362 insertions(+)
 create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
 
 diff --git a/drivers/video/fbdev/omap2/displays-new/Kconfig 
 b/drivers/video/fbdev/omap2/displays-new/Kconfig
 index e6cfc38..211b3ec 100644
 --- a/drivers/video/fbdev/omap2/displays-new/Kconfig
 +++ b/drivers/video/fbdev/omap2/displays-new/Kconfig
 @@ -1,6 +1,12 @@
 menu OMAP Display Device Drivers (new device model)
 depends on OMAP2_DSS
 
 +config DISPLAY_AMPLIFIER_OPA362
 
 Here also use ENCODER instead.
 
 +tristate external analog amplifier with output disable/high-Z 
 (e.g. OPA362)
 +help
 +  Driver to enable an external analog TV amplifier (e.g. OPA362)
 +  through a GPIO.
 
 The indentation above seems funny.
 
 The text looks a bit odd. So is this a driver for OPA362, or is this a
 generic driver for any similar devices? Most of the names and code makes
 me think this is a driver for OPA362, but the text above quite clearly
 gives the impression that this is a driver for any analog video amp,
 with single enable gpio.

Hm. We can imagine that there are other devices with similar functionality
and gpio but we have not tested any. So it is indeed better to describe it as
a pure OPA362 driver.

 
 +
 config DISPLAY_ENCODER_TFP410
 tristate TFP410 DPI to DVI Encoder
  help
 diff --git a/drivers/video/fbdev/omap2/displays-new/Makefile 
 b/drivers/video/fbdev/omap2/displays-new/Makefile
 index 0323a8a..b311542 100644
 --- a/drivers/video/fbdev/omap2/displays-new/Makefile
 +++ b/drivers/video/fbdev/omap2/displays-new/Makefile
 @@ -1,3 +1,4 @@
 +obj-$(CONFIG_DISPLAY_AMPLIFIER_OPA362) += amplifier-opa362.o
 obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
 obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
 obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
 diff --git a/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c 
 b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
 new file mode 100644
 index 000..8065a28
 --- /dev/null
 +++ b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
 @@ -0,0 +1,343 @@
 +/*
 + * OPA362 analog video amplifier with output/power control
 + *
 + * Copyright (C) 2014 Golden Delicious Computers
 + * Author: H. Nikolaus Schaller h...@goldelico.com
 + *
 + * based on encoder-tfp410
 + *
 + * Copyright (C) 2013 Texas Instruments
 + * Author: Tomi Valkeinen tomi.valkei...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 as published 
 by
 + * the Free Software Foundation.
 + */
 +
 +#include linux/gpio.h
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/slab.h
 +#include linux/of_gpio.h
 +
 +#include video/omapdss.h
 +#include video/omap-panel-data.h
 +
 +struct panel_drv_data {
 +struct omap_dss_device dssdev;
 +struct omap_dss_device *in;
 +
 +int enable_gpio;
 +
 +struct omap_video_timings timings;
 +};
 +
 +#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
 +
 +static int opa362_connect(struct omap_dss_device *dssdev,
 +struct omap_dss_device *dst)
 +{
 +struct panel_drv_data *ddata = to_panel_data(dssdev);
 +struct omap_dss_device *in = ddata-in;
 +int r;
 +
 +dev_dbg(dssdev-dev, connect\n);
 +
 +if (omapdss_device_is_connected(dssdev))
 +return -EBUSY;
 +
 +r = in-ops.atv-connect(in, dssdev);
 +if (r)
 +return r;
 +
 +dst-src = dssdev;
 +dssdev-dst = dst;
 +
 +return 0;
 +}
 +
 +static void opa362_disconnect(struct omap_dss_device *dssdev,
 +struct omap_dss_device *dst)
 +{
 +struct panel_drv_data *ddata = to_panel_data(dssdev);
 +struct omap_dss_device *in = ddata-in;
 +
 +dev_dbg(dssdev-dev, disconnect\n);
 +
 +WARN_ON(!omapdss_device_is_connected(dssdev));
 +if (!omapdss_device_is_connected(dssdev

Re: [Gta04-owner] [PATCH 2/3] ASoC: twl4030: allow voice port to be connected externally.

[Dr. H. Nikolaus Schaller]

Am 10.11.2014 um 00:25 schrieb NeilBrown ne...@suse.de:

 On Sat, 8 Nov 2014 09:26:22 + Mark Brown broo...@kernel.org wrote:
 
 On Sat, Nov 08, 2014 at 11:38:03AM +1100, NeilBrown wrote:
 
 If voice port on twl4030 is not connected to a McBSP (or similar)
 then we cannot configure the format the way we normally do for a DAI.
 
 Yes we can, you need to represent the DAI link to whatever else the
 device is connected to in the driver like we do anything else - and in
 any case this isn't a device specific issue so we shouldn't be doing
 something driver specific to solve it.  Look at something like speyside.
 
 Hi Mark,
 thanks for the reply ... I might need a little bit more help though.
 
 I had a look at sound/soc/samsung/speyside.c, but I'm not entirely sure what
 I'm looking for.
 Presumably this is an audio processor not unlike the audio module in the
 twl4030.
 
 I see that there are 3 dai-links:
  CPU-DSP
  DSP-CODEC
  Baseband
 
 Presumably Baseband is similar, in purpose at least, to the voice
 interface on the twl4030.
 
 Each dai-link has a cpu_dai_name and a codec_dai_name, even though it
 appears that only CPU-DSP is connected to the CPU.  Maybe that naming is
 the source of some of my confusion.
 
 Baseband declares
.cpu_dai_name = wm8996-aif2,
 so wm8996 is something with 2 audio interfaces, (aif), and this is the second
 one?  Maybe the  wm8996 is the audio module, so what is the speyside?
 
 http://opensource.wolfsonmicro.com/content/speyside-audio
 
 says it is a reference platform.  Does that mean it is a board with a bunch
 of chips soldered onto it?  If it were a board it should be described by a
 dts file, not by a pile of C code (I thought), so I must be wrong about that.
 
 
 In my case, I have a board with a GSM module and the twl4030 module.  Each
 has an audio interface and these are connected.  I assume that I need to
 express this connection in the dts file.
 The GSM module doesn't currently appear in the dts file as it is usb-attached.
 However I've been thinking that we will need to add it so we can express
 power-on controls (twiddling some GPIOs).  So let's suppose we have the GSM
 module in the dts file (child of a USB interface)

It is a quite complex connection pattern and I am not sure if the modem is 
really
a logical child of the USB interface. Powering up/down the USB interface has 
nothing
to do with the modem power. Rather, it continues to operate if USB is suspended
and the modem notifies USB that it has become active.

The connections on this GTA04 board are:

Modem USB — CPU USB
Modem PCM — TWL4030 Voice — OMAP3 McBSP4 (yes, it is a 3-way connection)
Modem Power control — 1 or 2 GPIOs (depending on board variant)

The reason for the 3-way connection is that user space can chose if the GSM
voice is routed directly to the TWL codec (low latency, independent of CPU) or
goes through the CPU (e.g. for DTAM or voice scrambling by software) and
then through the other PCM link between the CPU and the TWL.

This is why I would make the McBSP4 a separate sound card.

And, this is why it needs some control and tri-state of the TWL4030 and OMAP3
McBSP4 since only one can provide a digital PCM stream to the modem.

One more thing to consider for a general solution is that there are modem 
modules
that communicate data through UART or SPI - but otherwise have a similar 
connection
for digital audio. So forcing the power control driver to be a subnode of USB 
doesn’t
appear general enough to me.

Finally, this connection pattern is not specific to this modem (OPTION GTM601) 
on this
GTA04 board. We plan to use a Gemalto PHS8  in the Pyra-Handheld and the Neo900
devices - but the general connection pattern as defined above remains the same.

So my proposal is to have a specific wwan-power driver for this type of modems.
And power control can and should be kept separately from USB (except the case
where only 1 GPIO exists and USB must be tapped to detect the modem power
state). You can find work in progress for this approach here:

http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/misc/wwan-on-off.c;h=e13f47dbd734d14f4e38ea9cf622982dc3550212;hb=154bcd388a8f5bcc7fcf0e57e93b6388daa16980

 and the twl4030 as well
 (beneath an i2c interface).
 
 The twl4030 needs to know the master/polarity of the clk/frm lines.  The GSM
 module declares that these are.  So presumably we need some sort of linkage.
 A... I found Documentation/devicetree/bindings/sound/simple-card.txt
 
 So I need to make the voice port on the twl4030 look like a cpu end of a
 dai-link, and create a codec end in the GSM module, and use sound-dai to
 point from the twl4030 to the GSM module.

What I wonder a little is that we have all these dai-links working since your 
3.7
kernel for GTA04. Is it necessary to re-invent a solution or should we just make
the solution device tree compatible?

 Then I use frame-master, bitclock-master, bitclock-inversion, frame-inversion
 for the