from:"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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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

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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-03-11 Thread 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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-03-11 Thread 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 v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings

2015-04-01 Thread 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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 3/4] usb: phy: twl4030: add support for reading restore on ID pin.

2015-03-03 Thread Dr. H. Nikolaus Schaller


Am 04.03.2015 um 07:35 schrieb NeilBrown ne...@suse.de:

 On Mon, 2 Mar 2015 22:04:31 +0100 Pavel Machek pa...@ucw.cz wrote:
 
 Hi!
 
 The twl4030 phy can measure, with low precision, the
 resistance-to-ground of the ID pin.
 
 Add a function to read the value, and export the result
 via sysfs.
 
 If the read fails, which it does sometimes, try again in 50msec.
 
 Signed-off-by: NeilBrown ne...@suse.de
 ---
 drivers/phy/phy-twl4030-usb.c |   63 
 +
 1 file changed, 63 insertions(+)
 
 diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
 index 023fe150c7a1..759950898df9 100644
 --- a/drivers/phy/phy-twl4030-usb.c
 +++ b/drivers/phy/phy-twl4030-usb.c
 @@ -374,6 +374,56 @@ static void twl4030_i2c_access(struct twl4030_usb 
 *twl, int on)
 }
 }
 
 +enum twl4030_id_status {
 +   TWL4030_GROUND,
 +   TWL4030_102K,
 +   TWL4030_200K,
 +   TWL4030_440K,
 +   TWL4030_FLOATING,
 +   TWL4030_ID_UNKNOWN,
 +};
 +static char *twl4030_id_names[] = {
 +   ground,
 +   102k,
 +   200k,
 +   440k,
 
 New /sys files should be documented somewhere...?
 
 Preferably with the code...
 
 
 Does it make sense to change 440k - 440KOhm?
 
 Interesting question.  I prefer to avoid including units in files - bare
 numbers is better.  But there is no number to match floating unless I spell
 it out as infinity, and wouldn't be helpful.
 
 Certainly K would be preferred over k“,

The international standard for kilo = 1000 is a lower case k.
While it is (non-standard) to use K for 1024:

http://en.wikipedia.org/wiki/Kilobyte

So I would keep the string constants lower case to avoid this potential 
confusion.

 and given that I have ground
 and  floating, it is more consistent to include the Ohm
 
 These are really names, not measures of resistance.  The data sheet calls
 them:
 ID_RES_FLOAT  (or sometimes ID_FLOAT)
 ID_RES_440K
 ID_RES_200K
 ID_RES_102K
 ID_GND(or sometimes ID_RES_GND)
 
 So using those names is defensible.
 
 I think I'll change them all to upper case, but leave out the Ohm.
 My justification is consistency with the data sheet.
 
 
 
 
 
 Plus I guess you need to update Documentation/
 
 I guess I'll need to give in to this eventually :-)
 
 
 Acked-by: Pavel Machek pa...@ucw.cz
 
 
 Thanks,
 NeilBrown
 ___
 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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAPDSS: restore name sysfs entry.

2015-02-24 Thread Dr. H. Nikolaus Schaller

I have tested it with

X.Org X Server 1.12.4
Release Date: 2012-08-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-mx5 armv7l Debian

(coming from Debian Wheezy) on:

* gta04 (SPI panel)
* openpandora (SPI panel)
* BeagleBoard XM (with RGB panel)
* PandaBoard ES (w/o panel)
* omap5432-evm + Pyra prototype (MIPI panel)

Without this patch, X Server simply fails with:

Fatal server error:
no screens found

So please add
Tested-by: Nikolaus Schaller h...@goldelico.com

Thanks,
Nikolaus


Am 24.02.2015 um 10:37 schrieb NeilBrown ne...@suse.de:

 
 
 commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
OMAPDSS: rename display-sysfs 'name' entry
 
 broke the xorg X server on my device as it couldn't find the display
 any more.  It needs the 'name' file and now there isn't one.
 
 That commit claims that 'name' is not compatible with i2c or spi.
 i2c does register it own 'name' file, but spi does not, hence my
 problem - I have an spi display.
 
 So create a special case for i2c: add the name attribute for non-i2c
 devices.
 
 Fixes: 303e4697e762dc92a40405f4e4b8aac02cd0d70b
 Signed-off-by: NeilBrown ne...@suse.de
 
 --
 
 Hi Tomi,
 I wonder if you would consider this for the next merge window (or maybe even 
 sooner as a bug-fix).
 I haven't tested it with an i2c display, but it certainly allows xorg to work
 on my spi-attached display.
 
 Thanks,
 NeilBrown
 
 
 diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c 
 b/drivers/video/fbdev/omap2/dss/display-sysfs.c
 index 5a2095a98ed8..53897b743130 100644
 --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
 +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
 @@ -25,6 +25,15 @@
 #include linux/platform_device.h
 #include linux/sysfs.h
 
 +#if IS_ENABLED(CONFIG_I2C)
 +#include linux/i2c.h
 +#else
 +static inline int i2c_verify_client(struct device *dev)
 +{
 + return NULL;
 +}
 +#endif
 +
 #include video/omapdss.h
 #include dss.h
 
 @@ -278,6 +287,7 @@ static ssize_t display_wss_store(struct device *dev,
 }
 
 static DEVICE_ATTR(display_name, S_IRUGO, display_name_show, NULL);
 +static DEVICE_ATTR(name, S_IRUGO, display_name_show, NULL);
 static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
   display_enabled_show, display_enabled_store);
 static DEVICE_ATTR(tear_elim, S_IRUGO|S_IWUSR,
 @@ -315,6 +325,17 @@ int display_init_sysfs(struct platform_device *pdev)
   DSSERR(failed to create sysfs files\n);
   goto err;
   }
 + if (!i2c_verify_client(dssdev-dev)) {
 + /*
 +  * Add 'name' file - not compatible with i2c, but
 +  * need by Xorg for other devices.
 +  */
 + r = sysfs_create_file(kobj, dev_attr_name.attr);
 + if (r) {
 + DSSERR(fail to create 'name' sysfs file\n);
 + goto err;
 + }
 + }
 
   r = sysfs_create_link(pdev-dev.kobj, kobj, dssdev-alias);
   if (r) {
 @@ -341,5 +362,7 @@ void display_uninit_sysfs(struct platform_device *pdev)
   sysfs_remove_link(pdev-dev.kobj, dssdev-alias);
   sysfs_remove_files(dssdev-dev-kobj,
   display_sysfs_attrs);
 + sysfs_remove_file(dssdev-dev-kobj,
 +   dev_attr_name.attr);
   }
 }

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

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

2015-04-04 Thread 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

2015-04-01 Thread 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 linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-04-01 Thread 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 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.

2015-06-02 Thread Dr. H. Nikolaus Schaller

Hi,

Am 02.06.2015 um 22:11 schrieb Pavel Machek pa...@ucw.cz:

 On Tue 2015-06-02 16:06:47, Dr. H. Nikolaus Schaller wrote:
 Hi,
 
 Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I kis...@ti.com:
 
 Hi,
 
 On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote:
 On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com
 wrote:
 
 Hi,
 
 On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
 From: NeilBrown ne...@suse.de
 
 The twl4030 phy can measure, with low precision, the
 resistance-to-ground of the ID pin.
 
 Add a function to read the value, and export the result
 via sysfs.
 
 Little sceptical about adding new sysfs entries. Do you have a good 
 reason to
 add this?
 
 The hardware can report the value, so why not present it to user-space?
 
 I originally used this with a udev rule which would configure the maximum
 current based on the resistance measure - to work with the particular 
 charger
 hardware I have.
 
 More recent patches try to do all of the max-current configuration in the
 kernel, so I could live without exporting the value via sysfs if that is a
 show-stopper.
 
 I can't see where the scepticism comes from though.  It is a well defined
 and cleary documented feature of the hardware.  Why not expose it?
 
 Is it well defined enough that it will work on other chargers, too?

It reports the resistance of the charger’s ID pin. So that works for all 
chargers connected
to a twl4030. As long as the ID pin goes to a 5 pin USB socket.

Other charger drivers do not need to expose a similar attribute since each 
twl4030 has its
unique path within the /sys tree.

 
 ABI can never be removed or modified later. So should be really careful 
 before adding it.
 
 Is /sys considered ABI?
 
 Yes.

You are right: https://lwn.net/Articles/172986/

But I am as well with my doubts: https://lwn.net/Articles/173093/

 
 User space developers are always reminded not to rely on /sys nodes.
 
 No.

Then please explain why I have the impression that it is quite unstable.

BR,
Nikolaus

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

Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.

2015-06-23 Thread Dr. H. Nikolaus Schaller

Hi Neil,

Am 01.06.2015 um 23:37 schrieb NeilBrown ne...@suse.de:

 On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com
 wrote:
 
 Hi,
 
 On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
 From: NeilBrown ne...@suse.de
 
 The twl4030 phy can measure, with low precision, the
 resistance-to-ground of the ID pin.
 
 Add a function to read the value, and export the result
 via sysfs.
 
 Little sceptical about adding new sysfs entries. Do you have a good reason 
 to 
 add this?
 
 The hardware can report the value, so why not present it to user-space?

I just had another idea how to present the value to user space.

The TWL6030 has connected the USB ID pin to one of the GPADC channels:


http://lxr.free-electrons.com/source/drivers/iio/adc/twl6030-gpadc.c#L235

And therefore automatically presents the ID pin voltage through iio.

Would it be possible and useful to provide an iio interface for the 
resistance-to-ground
of the tw4030 ID pin as well?

This would resemble a 6 or 7 level ADC with non-linear scale, but better than 
nothing.

And to avoid the “floating” issue, it could also present some voltage value 
(assuming
a defined current).

So that “floating” is reported as some maximum voltage (e.g. 3.3V) and “ground” 
as 0V.

What do you think?

BR,
Nikolaus

 
 I originally used this with a udev rule which would configure the maximum
 current based on the resistance measure - to work with the particular charger
 hardware I have.
 
 More recent patches try to do all of the max-current configuration in the
 kernel, so I could live without exporting the value via sysfs if that is a
 show-stopper.
 
 I can't see where the scepticism comes from though.  It is a well defined
 and cleary documented feature of the hardware.  Why not expose it?
 
 Thanks,
 NeilBrown
 
 
 
 Thanks
 Kishon
 
 If the read fails, which it does sometimes, try again in 50msec.
 
 Acked-by: Pavel Machek pa...@ucw.cz
 Signed-off-by: NeilBrown ne...@suse.de
 ---
  .../ABI/testing/sysfs-platform-twl4030-usb |   22 +++
  drivers/phy/phy-twl4030-usb.c  |   63 
 
  2 files changed, 85 insertions(+)
 
 diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb 
 b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
 index 512c51be64ae..425d23676f8a 100644
 --- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
 +++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
 @@ -6,3 +6,25 @@ Description:
 Possible values: on, off.
 
 Changes are notified via select/poll.
 +
 +What: /sys/bus/platform/devices/*twl4030-usb/id
 +Description:
 +   Read-only report on measurement of USB-OTG ID pin.
 +
 +   The ID pin may be floating, grounded, or pulled to
 +   ground by a resistor.
 +
 +   A very course grained reading of the resistance is
 +   available.  The numbers given in kilo-ohms are roughly
 +   the center-point of the detected range.
 +
 +   Possible values are:
 +   ground
 +   102k
 +   200k
 +   440k
 +   floating
 +   unknown
 +
 +   unknown indicates a problem with trying to detect
 +   the resistance.
 diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
 index 3a707dd14238..1d6f3e70193e 100644
 --- a/drivers/phy/phy-twl4030-usb.c
 +++ b/drivers/phy/phy-twl4030-usb.c
 @@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb 
 *twl, int on)
 }
  }
 
 +enum twl4030_id_status {
 +   TWL4030_GROUND,
 +   TWL4030_102K,
 +   TWL4030_200K,
 +   TWL4030_440K,
 +   TWL4030_FLOATING,
 +   TWL4030_ID_UNKNOWN,
 +};
 +static char *twl4030_id_names[] = {
 +   ground,
 +   102k,
 +   200k,
 +   440k,
 +   floating,
 +   unknown
 +};
 +
 +enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
 +{
 +   int ret;
 +
 +   pm_runtime_get_sync(twl-dev);
 +   if (twl-usb_mode == T2_USB_MODE_ULPI)
 +   twl4030_i2c_access(twl, 1);
 +   ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
 +   if (ret  0 || !(ret  ULPI_OTG_ID_PULLUP)) {
 +   /* Need pull-up to read ID */
 +   twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
 +ULPI_OTG_ID_PULLUP);
 +   mdelay(50);
 +   }
 +   ret = twl4030_usb_read(twl, ID_STATUS);
 +   if (ret  0 || (ret  0x1f) == 0) {
 +   mdelay(50);
 +   ret = twl4030_usb_read(twl, ID_STATUS);
 +   }
 +
 +   if (twl-usb_mode == T2_USB_MODE_ULPI)
 +   twl4030_i2c_access(twl, 0);
 +   pm_runtime_put_autosuspend(twl-dev);
 +
 +   if (ret  0)
 +   return TWL4030_ID_UNKNOWN;
 +   ret = ffs(ret) - 1;
 +   if (ret  TWL4030_GROUND || ret  TWL4030_FLOATING)
 +   return TWL4030_ID_UNKNOWN;
 +
 +   return ret;
 +}
 +
  static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
  {
 u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
 @@ -532,6 +582,16 @@ static ssize_t twl4030_usb_vbus_show(struct device 
 *dev,
  }
  static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show,

Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.

2015-06-02 Thread Dr. H. Nikolaus Schaller

Hi,

Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I kis...@ti.com:

 Hi,
 
 On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote:
 On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com
 wrote:
 
 Hi,
 
 On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
 From: NeilBrown ne...@suse.de
 
 The twl4030 phy can measure, with low precision, the
 resistance-to-ground of the ID pin.
 
 Add a function to read the value, and export the result
 via sysfs.
 
 Little sceptical about adding new sysfs entries. Do you have a good reason 
 to
 add this?
 
 The hardware can report the value, so why not present it to user-space?
 
 I originally used this with a udev rule which would configure the maximum
 current based on the resistance measure - to work with the particular charger
 hardware I have.
 
 More recent patches try to do all of the max-current configuration in the
 kernel, so I could live without exporting the value via sysfs if that is a
 show-stopper.
 
 I can't see where the scepticism comes from though.  It is a well defined
 and cleary documented feature of the hardware.  Why not expose it?
 
 ABI can never be removed or modified later. So should be really careful 
 before adding it.

Is /sys considered ABI? It is permanently changing. At least in what I see.

User space developers are always reminded not to rely on /sys nodes.
Or if they do they have to follow kernel changes at their own risk.

And if something is useful (and has a use case as Neil mentioned), why shouldn’t
it be provided.

There are use cases where user space needs to know the value. Udev rule being
an example. E.g. to make LEDs show the state.

Or see it as a debugging tool. Just cat /sys/…path…/id to check if your 3 types
of charger are recognised properly.

Or write a tool that displays the charger type.

So isn’t that a little too narrow view applied here?

Just my opinion.

BR,
Nikolaus

 
 Thanks
 Kishon
 
 
 Thanks,
 NeilBrown
 
 
 
 Thanks
 Kishon
 
 If the read fails, which it does sometimes, try again in 50msec.
 
 Acked-by: Pavel Machek pa...@ucw.cz
 Signed-off-by: NeilBrown ne...@suse.de
 ---
   .../ABI/testing/sysfs-platform-twl4030-usb |   22 +++
   drivers/phy/phy-twl4030-usb.c  |   63 
 
   2 files changed, 85 insertions(+)
 
 diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb 
 b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
 index 512c51be64ae..425d23676f8a 100644
 --- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
 +++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
 @@ -6,3 +6,25 @@ Description:
Possible values: on, off.
 
Changes are notified via select/poll.
 +
 +What: /sys/bus/platform/devices/*twl4030-usb/id
 +Description:
 +  Read-only report on measurement of USB-OTG ID pin.
 +
 +  The ID pin may be floating, grounded, or pulled to
 +  ground by a resistor.
 +
 +  A very course grained reading of the resistance is
 +  available.  The numbers given in kilo-ohms are roughly
 +  the center-point of the detected range.
 +
 +  Possible values are:
 +  ground
 +  102k
 +  200k
 +  440k
 +  floating
 +  unknown
 +
 +  unknown indicates a problem with trying to detect
 +  the resistance.
 diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
 index 3a707dd14238..1d6f3e70193e 100644
 --- a/drivers/phy/phy-twl4030-usb.c
 +++ b/drivers/phy/phy-twl4030-usb.c
 @@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb 
 *twl, int on)
}
   }
 
 +enum twl4030_id_status {
 +  TWL4030_GROUND,
 +  TWL4030_102K,
 +  TWL4030_200K,
 +  TWL4030_440K,
 +  TWL4030_FLOATING,
 +  TWL4030_ID_UNKNOWN,
 +};
 +static char *twl4030_id_names[] = {
 +  ground,
 +  102k,
 +  200k,
 +  440k,
 +  floating,
 +  unknown
 +};
 +
 +enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
 +{
 +  int ret;
 +
 +  pm_runtime_get_sync(twl-dev);
 +  if (twl-usb_mode == T2_USB_MODE_ULPI)
 +  twl4030_i2c_access(twl, 1);
 +  ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
 +  if (ret  0 || !(ret  ULPI_OTG_ID_PULLUP)) {
 +  /* Need pull-up to read ID */
 +  twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
 +   ULPI_OTG_ID_PULLUP);
 +  mdelay(50);
 +  }
 +  ret = twl4030_usb_read(twl, ID_STATUS);
 +  if (ret  0 || (ret  0x1f) == 0) {
 +  mdelay(50);
 +  ret = twl4030_usb_read(twl, ID_STATUS);
 +  }
 +
 +  if (twl-usb_mode == T2_USB_MODE_ULPI)
 +  twl4030_i2c_access(twl, 0);
 +  pm_runtime_put_autosuspend(twl-dev);
 +
 +  if (ret  0)
 +  return TWL4030_ID_UNKNOWN;
 +  ret = ffs(ret) - 1;
 +  if (ret  TWL4030_GROUND || ret  TWL4030_FLOATING)
 +  return TWL4030_ID_UNKNOWN;
 +
 +  return ret;
 +}
 +
   static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
   {
u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
 @@ -532,6 +582,16 @@ static ssize_t

Re: twl6030-gpadc support for twl6037

2015-07-22 Thread Dr. H. Nikolaus Schaller


Am 22.07.2015 um 21:41 schrieb Graeme Gregory g...@slimlogic.co.uk:

 
 
 On Wed, 22 Jul 2015, at 08:33 PM, Graeme Gregory wrote:
 
 
 On Wed, 22 Jul 2015, at 08:28 PM, Belisko Marek wrote:
 Adding also twl6030-gpadc driver authors to loop
 
 On Mon, Jul 20, 2015 at 8:57 AM, Belisko Marek marek.beli...@gmail.com
 wrote:
 Hi all,
 
 I'm trying to figure out what is relation between palmas mfd driver
 and twl-core for twl603x devices.
 twl-core driver seems to be older than palmas driver but seems both
 export same functionality (except that palmas have defined structs for
 gpadc but functionality is missing). My main focus is to add support
 for twl6037 to gpadc iio driver in iio/adc/twl6030-gpadc which is
 using twl-core for twl6030 and twl6032. Adding twl6037 support should
 be straightforward but dts file used in omap5-uevm using palmas driver
 and not twl6030. So it's completely confusing to me how to proceed or
 which direction is correct. Seems I'm missing some parts of puzzle ;)
 Thanks for any hints.
 
 Phoenix is twl6030, twl6032
 
 Palmas is twl6035, twl6037 and maybe others.
 
 Phoenix and Palmas are two totally different chips but marketing gave
 them numbers near each other for unknown reasons.
 
 Also this might be useful.
 
 https://github.com/slimlogic/linux/commit/312a6a1c8013fd056431c31567b43d8eef40f333

That is basically what we are looking for.

We will give it a try asap and let you know results.

 
 A pre IIO palmas ADC driver which I never got around to upstreaming

Well, unless it already exists somewhere, it should be converterd to iio by 
updating the
driver structure to follow iio/adc/twl6030-gpadc.

 because TIpocalypse left me with no access to a palmas chip.

The OMAP5432EVM by SVtronics [1] comes with a twl6037 (and it is
supported by mainline device tree omap5-uevm.dts). And we hope
that the pyra-handheld.com hardware is finished soon. For hardware
bring-up it would be good to already have the gpadc available - so
we have some hen-and-egg situation here.

BR and thanks,
Nikolaus

[1]: http://www.svtronics.com/5432

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

Re: gpadc iio support for tlw6037/palmas [was: twl6030-gpadc support for twl6037]

2015-07-23 Thread Dr. H. Nikolaus Schaller

Hi Graeme,

Am 22.07.2015 um 21:41 schrieb Graeme Gregory g...@slimlogic.co.uk:

On Wed, 22 Jul 2015, at 08:33 PM, Graeme Gregory wrote:

On Wed, 22 Jul 2015, at 08:28 PM, Belisko Marek wrote:
Adding also twl6030-gpadc driver authors to loop

On Mon, Jul 20, 2015 at 8:57 AM, Belisko Marek marek.beli...@gmail.com
wrote:
Hi all,

I'm trying to figure out what is relation between palmas mfd driver
and twl-core for twl603x devices.
twl-core driver seems to be older than palmas driver but seems both
export same functionality (except that palmas have defined structs for
gpadc but functionality is missing). My main focus is to add support
for twl6037 to gpadc iio driver in iio/adc/twl6030-gpadc which is
using twl-core for twl6030 and twl6032. Adding twl6037 support should
be straightforward but dts file used in omap5-uevm using palmas driver
and not twl6030. So it's completely confusing to me how to proceed or
which direction is correct. Seems I'm missing some parts of puzzle ;)
Thanks for any hints.

Phoenix is twl6030, twl6032

Palmas is twl6035, twl6037 and maybe others.

Phoenix and Palmas are two totally different chips but marketing gave
them numbers near each other for unknown reasons.

Also this might be useful.

https://github.com/slimlogic/linux/commit/312a6a1c8013fd056431c31567b43d8eef40f333

A pre IIO palmas ADC driver which I never got around to upstreaming
because TIpocalypse left me with no access to a palmas chip.

We managed to integrate your code into our 4.1 kernel (needed minor fixes
mainly for
irq initialization) and it appears to work on the omap5432evm. Especially
channels
in6_channel and in7_channel in
/sys/bus/platform/drivers/palmas-gpadc/4807.i2c:palmas@48:gpadc
show reasonable (and slightly fluctuating) volt values.

Now the question is how to proceed. We could either write some
drivers/iio/adc/palmas-gpadc.c
wrapper around your driver, or could try this one which appears to be a pure
iio implementation:

https://android.googlesource.com/kernel/tegra.git/+/28f245bb8f590f61bb244f1b4d03f4b4919d32ea/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc/palmas_gpadc.c

Do you think the latter has a chance to be accepted upstream?

The reason we ask is that we neither want to write new code if something exists
nor base
our work on something that can not be upstreamed.

We have added the author(s) of this tegra/android driver so they can please
also comment
on their plans for submitting the driver upstream.

BR and thank you,
Nikolaus and Marek

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

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

2015-10-25 Thread 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 5/7] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

2015-11-09 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

Here the test results:

Am 13.11.2015 um 13:01 schrieb Laurent Pinchart 
<laurent.pinch...@ideasonboard.com>:

> On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote:
>> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
>>> Include VENC in the set of drivers where it is assimed that the cable
>>> is always connected. Like DPI, DSI, DBI and SDI do.
>>> 
>>> Otherwise, the VENC will return cable status "unknown" and is not enabled
>>> by the X-server. So there is no video output signal.
>>> 
>>> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>>> 
>>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>>> ---
>>> 
>>> drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>>> @@ -120,6 +120,7 @@ static enum drm_connector_status
>>> omap_connector_detect(
>>> else
>>> ret = connector_status_disconnected;
>>> } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
>>> +   dssdev->type == OMAP_DISPLAY_TYPE_VENC ||
>>> dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>>> dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>>> dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>> 
>> I have no idea why VENC is not working for you when using
>> connector_status_unknown, but I just tested DPI with
>> connector_status_unknown (i.e. changed the above func to return unknown
>> for DPI), and it works fine with X and X omap driver. And xrandr
>> confirms that the connection status is unknown:
>> 
>> # xrandr
>> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
>> HDMI-1 disconnected (normal left inverted right x axis y axis)
>> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
>> axis y axis) 0mm x 0mm
>>   1920x1200 60.00*+  60.00 +

A) with this VENC patch:

root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 640, maximum 2048 x 2048
None-1 connected 720x574+0+0 0mm x 0mm
   720x574i  50.00*+
None-2 connected 480x640+0+0 0mm x 0mm
   480x640   65.74*+
root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
enabled
enabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status 
connected
connected

B) w/o VENC patch (VENC returns returning connector_status_unknown):

root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 480 x 640, maximum 2048 x 2048
None-1 connected 480x640+0+0 0mm x 0mm
   480x640   65.74*+
None-2 unknown connection
   720x574i  50.00 +
root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
enabled
disabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
connected
unknown

C) with DPI (also) returning connector_status_unknown

root@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 640, maximum 2048 x 2048
None-1 unknown connection 720x574+0+0 0mm x 0mm
   720x574i  50.00*+
None-2 unknown connection 480x640+0+0 0mm x 0mm
   480x640   65.74*+
root@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
enabled
enabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
unknown
unknown
root@letux:~# 

D) VENC patch but DPI returning connector_status_unknown

rroot@letux:~# xrandr
Screen 0: minimum 320 x 200, current 720 x 574, maximum 2048 x 2048
None-1 unknown connection
   480x640   65.74 +
None-2 connected 720x574+0+0 0mm x 0mm
   720x574i  50.00*+oot@letux:~# cat /sys/class/drm/card0-Unknown-*/enabled
disabled
enabled
root@letux:~# cat /sys/class/drm/card0-Unknown-*/status
unknown
connected

In case B) I have no TV out and in case D) I have no LCD.

So it looks as if it works if my LCD and VENC report the same
connection status. And fails if they differ.

Anyone with an explanation or even vague idea where to search
for the real bug?

BR and thanks,
Nikolaus

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

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

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 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 4/8] DT:omap3+tsc2007: use new common touchscreen bindings

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-11-15 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-11-15 Thread 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

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

2015-11-16 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 0/7] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 2/7] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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))
+   /

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


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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-19 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] twl4030_charger: add missing iio dependency

2015-10-15 Thread H. Nikolaus Schaller

Acked-by: Nikolaus Schaller 

BR,
Nikolaus

Am 15.10.2015 um 11:11 schrieb Sebastian Reichel :

> This driver fails to link without CONFIG_IIO, since
> there are no stubs for the iio_channels functions.
> 
> Signed-off-by: Sebastian Reichel 
> ---
> drivers/power/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 9e68853217ca..cb0ae666dc68 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -313,7 +313,7 @@ config CHARGER_MAX8903
> 
> config CHARGER_TWL4030
>   tristate "OMAP TWL4030 BCI charger driver"
> - depends on TWL4030_CORE
> + depends on IIO && TWL4030_CORE
>   help
> Say Y here to enable support for TWL4030 Battery Charge Interface.
> 
> -- 
> 2.6.1
> 

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

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

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 (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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-10-20 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

Include VENC in the set of drivers where it is assimed that the cable
is always connected. Like DPI, DSI, DBI and SDI do.

Otherwise, the VENC will return cable status "unknown" and is not enabled
by the X-server. So there is no video output signal.

Tested on: BeagleBoard XM, GTA04 and OpenPandora

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 83f2a91..98ddb5d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -120,6 +120,7 @@ static enum drm_connector_status omap_connector_detect(
else
ret = connector_status_disconnected;
} else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_VENC ||
dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
-- 
2.5.1

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

[PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

Otherwise check_timings fails and we get a "has no modes" message
from xrandr.

This fix makes the venc assume PAL and NTSC timings that match the
timings synthetized by copy_timings_drm_to_omap() from omapdrm
mode settings so that check_timings() succeeds.

Tested on: BeagleBoard XM, GTA04 and OpenPandora

Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
---
 drivers/video/fbdev/omap2/dss/venc.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/video/fbdev/omap2/dss/venc.c 
b/drivers/video/fbdev/omap2/dss/venc.c
index 99ca268..d05a549 100644
--- a/drivers/video/fbdev/omap2/dss/venc.c
+++ b/drivers/video/fbdev/omap2/dss/venc.c
@@ -275,6 +275,12 @@ const struct omap_video_timings omap_dss_pal_timings = {
.vbp= 41,
 
.interlace  = true,
+
+   .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+   .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+   .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+   .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+   .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
 };
 EXPORT_SYMBOL(omap_dss_pal_timings);
 
@@ -290,6 +296,12 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
.vbp= 31,
 
.interlace  = true,
+
+   .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+   .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+   .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+   .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+   .sync_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
 };
 EXPORT_SYMBOL(omap_dss_ntsc_timings);
 
-- 
2.5.1

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

[PATCH 0/2] Fix omap VENC (PAL/NTSC TV out) operation with omapdrm driver

This patch set fixes some issues with the OMAP VENC
when used with the omapdrm driver.

Tested on: BeagleBoard XM, GTA04 and OpenPandora


H. Nikolaus Schaller (2):
  video:omap2:dss: fix timings for VENC to match what omapdrm expects
  video:omapdrm: make omapdrm assume the tv-out cable is always
connected

 drivers/gpu/drm/omapdrm/omap_connector.c |  1 +
 drivers/video/fbdev/omap2/dss/venc.c | 12 
 2 files changed, 13 insertions(+)

-- 
2.5.1

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

Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

Hi Laurent and Tomi,

Am 13.11.2015 um 13:01 schrieb Laurent Pinchart 
<laurent.pinch...@ideasonboard.com>:

> On Friday 13 November 2015 13:46:01 Tomi Valkeinen wrote:
>> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
>>> Include VENC in the set of drivers where it is assimed that the cable
>>> is always connected. Like DPI, DSI, DBI and SDI do.
>>> 
>>> Otherwise, the VENC will return cable status "unknown" and is not enabled
>>> by the X-server. So there is no video output signal.
>>> 
>>> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>>> 
>>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>>> ---
>>> 
>>> drivers/gpu/drm/omapdrm/omap_connector.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> b/drivers/gpu/drm/omapdrm/omap_connector.c index 83f2a91..98ddb5d 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
>>> @@ -120,6 +120,7 @@ static enum drm_connector_status
>>> omap_connector_detect(
>>> else
>>> ret = connector_status_disconnected;
>>> } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
>>> +   dssdev->type == OMAP_DISPLAY_TYPE_VENC ||
>>> dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>>> dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>>> dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>> 
>> I have no idea why VENC is not working for you when using
>> connector_status_unknown,

I agree that it should...

>> but I just tested DPI with
>> connector_status_unknown (i.e. changed the above func to return unknown
>> for DPI

Good hint. I can do the same check. Maybe it highlights the real issue.

>> ), and it works fine with X and X omap driver. And xrandr
>> confirms that the connection status is unknown:
>> 
>> # xrandr
>> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 2048 x 2048
>> HDMI-1 disconnected (normal left inverted right x axis y axis)
>> None-1 unknown connection 1920x1200+0+0 (normal left inverted right x
>> axis y axis) 0mm x 0mm
>>   1920x1200 60.00*+  60.00 +

Which configs, drivers and system are you using for this results?

>> 
>> Grep also shows that there are many drivers using
>> connector_status_unknown, so I'm guessing it should work fine...
> 
> And beside it's not right to consider VENC as always connected, as it isn't. 

Hm. Well, the VENC (meaning the D/A converter inside the OMAP3 chip)
is always connected. But the monitor or cable isn't.

> The unknown status is there for a reason, to describe connectors for which we 
> can't get any status information. The situation is different for DPI, DBI, 
> SDI 
> and DSI as those are on-board busses that connect to a non-removable panel, 
> so 
> we can say with a good confidence that the panel is connected (the situation 
> could be changed with a hammer and a chisel, but that's unlikely to happen, 
> hence the confidence).

Well, it may be that the omapdrm and X11 combination (unfortuantely I don't
understand either and have not found a good description how they interwork),
 keeps the VENC disabled if the connector is unknown.

And since there is no code to detect that a cable has been connected, there
might be missing some trigger to enable the interface.

The symptom I see is that the status of this card is "disabled" while the LCD
panel is "enabled". After doing my proposed patch, both come up "enabled".

So my patch appears to be a work around some other still hidden problem.

Any hint from the experts how to debug / find the real issue & solution is 
welcome.

BR,
Nikolaus

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

Re: mysterious crashes on OMAP5 uevm

2015-09-10 Thread Dr. H. Nikolaus Schaller


Am 10.09.2015 um 10:30 schrieb Russell King - ARM Linux 
<li...@arm.linux.org.uk>:

> On Thu, Sep 10, 2015 at 08:42:57AM +0200, Dr. H. Nikolaus Schaller wrote:
>> 
>> Am 08.09.2015 um 23:07 schrieb Tony Lindgren <t...@atomide.com>:
>> 
>>> * Grazvydas Ignotas <nota...@gmail.com> [150908 13:44]:
>>>> On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren <t...@atomide.com> wrote:
>>>>> * Grazvydas Ignotas <nota...@gmail.com> [150908 05:50]:
>>>>>> Hi,
>>>>>> 
>>>>>> this is a longstanding problem I'm seeing since the very beginning,
>>>>>> which was around 3.12 or so (when I've first got the hardware) and it
>>>>>> seems 4.2 is affected by it still. Basically what happens is Xorg
>>>>>> randomly segfaults at some "impossible" location. I don't have the
>>>>>> details at the moment (could get them is needed), but from what I
>>>>>> examined with gdb some time ago the situation did not make any sense.
>>>>>> 
>>>>>> There are 2 workarounds that I know which make the problem go away
>>>>>> (one is enough):
>>>>>> - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
>>>>>> default)
>>>>>> - disable ARCH_MULTI_V6 in the kernel config
>>>>>> 
>>>>>> Because of the above workarounds I have forgotten about it several
>>>>>> times, but it regularly comes back and bites again. It would look like
>>>>>> some missing erratum workaround, but I have all of them enabled in the
>>>>>> kernel.
>>>>>> 
>>>>>> Does anyone know about this? Perhaps some missing erratum workaround
>>>>>> in the bootloader? u-boot isn't too old here (2015.07).
>>>>> 
>>>>> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
>>>>> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
>>>>> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
>>>>> places ignoring uncompress and davinci code.
>>>> 
>>>> ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
>>>> disabled, it is enough to just do this:
>>>> 
>>>> --- a/arch/arm/kernel/signal.c
>>>> +++ b/arch/arm/kernel/signal.c
>>>> @@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal 
>>>> *ksig,
>>>>   /*
>>>>* The LSB of the handler determines if we're going to
>>>>* be using THUMB or ARM mode for this signal handler.
>>>>*/
>>>>   thumb = handler & 1;
>>>> 
>>>> -#if __LINUX_ARM_ARCH__ >= 7
>>>> +#if 0 //__LINUX_ARM_ARCH__ >= 7
>>>>   /*
>>>>* Clear the If-Then Thumb-2 execution state
>>>>* ARM spec requires this to be all 000s in ARM mode
>>>>* Snapdragon S4/Krait misbehaves on a Thumb=>ARM
>>>>* signal transition without this.
>>>>*/
>>>> 
>>>> ... and the problem appears, so I guess this needs some real
>>>> multiplatform handling,.
>>> 
>>> OK nice to hear you found it. Yeah looks like some runtime
>>> capability check is needed.
>>> 
>>>>> Do you have some easy way to reproduce this issue?
>>>> 
>>>> Just moving a browser window around with mouse usually triggers it
>>>> within a minute.
>>> 
>>> OK good to know.
>> 
>> It looks as if this is the solution for the same symptom on our OMAP3 board 
>> (gta04).
>> There, it suffices to draw on the touch screen for ~10 seconds to make the 
>> xserver segfault.
>> 
>> [we are using the binary xserver from debian wheezy
>> ii  xserver-xorg-core2:1.12.4-6+deb7u5 
>> armhfXorg X server - core server]
>> 
>> We know about this bug for a while, but so far did think that some touch 
>> screen
>> event bit has changed and we have to fix our touch screen driver.
>> 
>> Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and adding the
>>>> #if 0 //__LINUX_ARM_ARCH__ >= 7
>> makes it re-appear.
>> 
>> A while ago I tried to debug running the x-server under strace

Re: mysterious crashes on OMAP5 uevm

2015-09-10 Thread Dr. H. Nikolaus Schaller

Am 08.09.2015 um 23:07 schrieb Tony Lindgren :

> * Grazvydas Ignotas  [150908 13:44]:
>> On Tue, Sep 8, 2015 at 4:38 PM, Tony Lindgren  wrote:
>>> * Grazvydas Ignotas  [150908 05:50]:
 Hi,

 this is a longstanding problem I'm seeing since the very beginning,
 which was around 3.12 or so (when I've first got the hardware) and it
 seems 4.2 is affected by it still. Basically what happens is Xorg
 randomly segfaults at some "impossible" location. I don't have the
 details at the moment (could get them is needed), but from what I
 examined with gdb some time ago the situation did not make any sense.

 There are 2 workarounds that I know which make the problem go away
 (one is enough):
 - recompile Xorg with -marm (I'm using Debian armhf so it's thumb2 by 
 default)
 - disable ARCH_MULTI_V6 in the kernel config

 Because of the above workarounds I have forgotten about it several
 times, but it regularly comes back and bites again. It would look like
 some missing erratum workaround, but I have all of them enabled in the
 kernel.

 Does anyone know about this? Perhaps some missing erratum workaround
 in the bootloader? u-boot isn't too old here (2015.07).
>>> 
>>> Seems like some incorrect handling with CONFIG_CPU_V6 compiled in..
>>> Maybe try to narrow it down by commenting out some CONFIG_CPU_V6 and
>>> __LINUX_ARM_ARCH__ = 6 ifdefs in the git grep CONFIG_CPU_V6
>>> places ignoring uncompress and davinci code.
>> 
>> ok with that it was quite easy to find. On a kernel with ARCH_MULTI_V6
>> disabled, it is enough to just do this:
>> 
>> --- a/arch/arm/kernel/signal.c
>> +++ b/arch/arm/kernel/signal.c
>> @@ -340,13 +340,13 @@ setup_return(struct pt_regs *regs, struct ksignal 
>> *ksig,
>>/*
>> * The LSB of the handler determines if we're going to
>> * be using THUMB or ARM mode for this signal handler.
>> */
>>thumb = handler & 1;
>> 
>> -#if __LINUX_ARM_ARCH__ >= 7
>> +#if 0 //__LINUX_ARM_ARCH__ >= 7
>>/*
>> * Clear the If-Then Thumb-2 execution state
>> * ARM spec requires this to be all 000s in ARM mode
>> * Snapdragon S4/Krait misbehaves on a Thumb=>ARM
>> * signal transition without this.
>> */
>> 
>> ... and the problem appears, so I guess this needs some real
>> multiplatform handling,.
> 
> OK nice to hear you found it. Yeah looks like some runtime
> capability check is needed.
> 
>>> Do you have some easy way to reproduce this issue?
>> 
>> Just moving a browser window around with mouse usually triggers it
>> within a minute.
> 
> OK good to know.

It looks as if this is the solution for the same symptom on our OMAP3 board 
(gta04).
There, it suffices to draw on the touch screen for ~10 seconds to make the 
xserver segfault.

[we are using the binary xserver from debian wheezy
ii  xserver-xorg-core2:1.12.4-6+deb7u5 
armhfXorg X server - core server]

We know about this bug for a while, but so far did think that some touch screen
event bit has changed and we have to fix our touch screen driver.

Now, disabling CONFIG_ARCH_MULTI_V6 also makes the bug go away and adding the
>> #if 0 //__LINUX_ARM_ARCH__ >= 7
makes it re-appear.

A while ago I tried to debug running the x-server under strace and could find 
that it also has
something to do with SIGALRM.

And that is very consistent with “enable/disable” by modifying 
arch/arm/kernel/signal.c

BR,
Nikolaus

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

Re: mysterious crashes on OMAP5 uevm

2015-09-14 Thread Dr. H. Nikolaus Schaller


Am 14.09.2015 um 21:02 schrieb Tony Lindgren <t...@atomide.com>:

> * Russell King - ARM Linux <li...@arm.linux.org.uk> [150914 05:16]:
>> On Fri, Sep 11, 2015 at 03:03:07PM +0100, Russell King - ARM Linux wrote:
>>> 
>>> Merely changing __LINUX_ARM_ARCH__ >= 7 to >= 6 should fix the problem,
>>> and I doubt there's any ARMv6 non-T2 systems out there that would be
>>> affected by clearing the IT state bits.
>> 
>> Please test the following patch:
> 
> While we're waiting for Grazvydas to test.. Looks good to me:
> 
> Acked-by: Tony Lindgren <t...@atomide.com>

I have tested on:
* GTA04 with DM3730 (OMAP3)
* Pyra prototype with OMAP5432
No X server crashes seen any more.

Tested-by: H. Nikolaus Schaller <h...@goldelico.com>

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

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

2015-09-28 Thread 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, \
>> +

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

2015-10-04 Thread 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

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

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 0/3] Add Palmas iio gpadc

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Add Palmas iio gpadc

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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,

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

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 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2015-09-24 Thread 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 v2 2/3] iio:adc:palmas: add DT support


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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

2015-12-13 Thread H. Nikolaus Schaller

Hi Tomi,

Am 09.12.2015 um 09:18 schrieb Tomi Valkeinen <tomi.valkei...@ti.com>:

> 
> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
>> Otherwise check_timings fails and we get a "has no modes" message
>> from xrandr.
>> 
>> This fix makes the venc assume PAL and NTSC timings that match the
>> timings synthetized by copy_timings_drm_to_omap() from omapdrm
>> mode settings so that check_timings() succeeds.
>> 
>> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>> 
>> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
>> ---
>> drivers/video/fbdev/omap2/dss/venc.c | 12 
>> 1 file changed, 12 insertions(+)
> 
> I've picked this up.

Thanks!

> 
> With this patch and the one below I can get tv-out working on my very old
> beagleboard, and it seems to work with X also. It doesn't start automatically
> as the connection state is unknown, but doing "xrandr --output None-1 --auto"
> was all I needed to enable it.

Great that you did find the real reason of the problem.

I have tested it on the GTA04 and it also works.

Will the patches arrive in 4.5?

So thanks a lot,
Nikolaus

> 
> Tomi
> 
> From a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkei...@ti.com>
> Date: Tue, 8 Dec 2015 18:32:14 +0200
> Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms
> 
> omap_fbdev always creates a framebuffer with ARGB pixel format. On
> OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
> OMAP2 none of the overlays support ARGB888.
> 
> This patch changes the omap_fbdev's fb to XRGB, which is supported
> by all platforms.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> index b8e4cdec28c3..24f92bea39c7 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper 
> *helper,
>   dma_addr_t paddr;
>   int ret;
> 
> - /* only doing ARGB32 since this is what is needed to alpha-blend
> -  * with video overlays:
> -  */
>   sizes->surface_bpp = 32;
> - sizes->surface_depth = 32;
> + sizes->surface_depth = 24;
> 
>   DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
>   sizes->surface_height, sizes->surface_bpp,
> 

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

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

2016-01-06 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2016-01-06 Thread 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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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 linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DSS display-new custom enable/disable hooks

Hi,

Am 25.09.2013 um 09:09 schrieb Belisko Marek:

 CC - Nikolaus Schaller
 
 On Wed, Sep 25, 2013 at 8:12 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 24/09/13 23:04, Belisko Marek wrote:
 Hi,
 
 we're using connector-analog-tv driver to enable TV out on gta04
 board. There is exception that we need to change some twl registers +
 some gpio when enable/disable TV output. My question is if there is
 some way how to do that or do we need to copy'n'paste code from
 connector-analog-tv driver and extend it for handling we need (let's
 call it hack)?
 
 What are those TWL registers and GPIO used for?

The GTA04 devices uses an OPA362 video amplifier connected to the TV_VFB1 pin
of the DM3730. According to some not well known discussion with TI [1] we must
therefore configure the AC bias and Bypass through the DEVCONF1 register.

[1] 
https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/94072/343691.aspx

And we have to disable (High-Z) the OPA362 amplifier if TVout is not in use 
since the
line is shared with a different function (microphone input).

The reasons to use the OPA362 at all are to do short circuit protection and to 
high-Z
the driver (both are n/a with the DM3730 as far as we know).

The code we did use successfully in the 2.6.32 board file is:

120 #define TV_OUT_GPIO 23

374 static int gta04_panel_enable_tv(struct omap_dss_device *dssdev)
375 {
376 u32 reg;
377 
378 #define ENABLE_VDAC_DEDICATED   0x03
379 #define ENABLE_VDAC_DEV_GRP 0x20
380 #define OMAP2_TVACEN(1  11)
381 #define OMAP2_TVOUTBYPASS   (1  18)
382 
383 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER,
384 ENABLE_VDAC_DEDICATED,
385 TWL4030_VDAC_DEDICATED);
386 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER,
387 ENABLE_VDAC_DEV_GRP, TWL4030_VDAC_DEV_GRP);
388 
389 /* idea taken from 
https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/94072/343691.aspx
 */
390 reg = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
391 //  printk(KERN_INFO Value of DEVCONF1 was: %08x\n, reg);
392 reg |= OMAP2_TVOUTBYPASS;   /* enable TV bypass mode for 
external video driver (for OPA362 driver) */
393 reg |= OMAP2_TVACEN;/* assume AC coupling to remove DC 
offset */
394 omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
395 reg = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
396 //  printk(KERN_INFO Value of DEVCONF1 now: %08x\n, reg);
397 
398 gpio_set_value(TV_OUT_GPIO, 1); /* enable output driver (OPA362) */
399 
400 return 0;
401 }
402 
403 static void gta04_panel_disable_tv(struct omap_dss_device *dssdev)
404 {
405 gpio_set_value(TV_OUT_GPIO, 0); /* disable output driver (and 
re-enable microphone) */
406 
407 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0x00,
408 TWL4030_VDAC_DEDICATED);
409 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0x00,
410 TWL4030_VDAC_DEV_GRP);
411 }
412
413 static struct omap_dss_device gta04_tv_device = {
414 .name = tv,
415 .driver_name = venc,
416 .type = OMAP_DISPLAY_TYPE_VENC,
417 /* GTA04 has a single composite output (with external video driver) 
*/
418 .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
419 .phy.venc.invert_polarity = true,   /* needed if we use 
external video driver */
420 .platform_enable = gta04_panel_enable_tv,
421 .platform_disable = gta04_panel_disable_tv,
422 };

I think (but don't know) that controlling the TWL/VDAC is no longer needed 
because
it should be done through the connector-analog-tv driver.

So we need to
1. control a GPIO - very similar to a TFT panel
2. invert polarity
3. configure the OMAP343X_CONTROL_DEVCONF1 register as needed

I don't know if we must do step 3. each time we enable TVout (because we can't
assume that no other part of the kernel code writes to the DEVCONF1 register) 
so that
it could be done in the board init code.

 If they are board
 specific things, then I see two options:
 
 - Presuming you're using board files, you could add
 platform_enable/disable callbacks to the connector's platform_data, and
 make the connector driver call those callbacks.
 
 - Create a new display encoder driver, which handles the TWL and GPIO,
 and position it in the video pipeline between VENC and the connector.
 
 The first option is obviously not upstreamable, as it won't work with
 DT. And I'm not enthusiastic about merging board specific display
 drivers either, but so far I haven't figured better ways to implement
 board specific oddities.
 
 Tomi
 
 
 
 marek


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

Re: DSS display-new custom enable/disable hooks

Hi Tomi,

Am 25.09.2013 um 10:29 schrieb Tomi Valkeinen:

 On 25/09/13 10:45, Dr. H. Nikolaus Schaller wrote:
 Hi,
 
 Am 25.09.2013 um 09:09 schrieb Belisko Marek:
 
 CC - Nikolaus Schaller
 
 On Wed, Sep 25, 2013 at 8:12 AM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
 On 24/09/13 23:04, Belisko Marek wrote:
 Hi,
 
 we're using connector-analog-tv driver to enable TV out on gta04
 board. There is exception that we need to change some twl registers +
 some gpio when enable/disable TV output. My question is if there is
 some way how to do that or do we need to copy'n'paste code from
 connector-analog-tv driver and extend it for handling we need (let's
 call it hack)?
 
 What are those TWL registers and GPIO used for?
 
 The GTA04 devices uses an OPA362 video amplifier connected to the TV_VFB1 pin
 of the DM3730. According to some not well known discussion with TI [1] we 
 must
 therefore configure the AC bias and Bypass through the DEVCONF1 register.
 
 Ah, OPA. A blast from the past =).
 
 Well, OPA is a distinct hardware block in the video path, I see no issue
 in having an OPA encoder driver, that sits in between VENC and the
 connector.
 
 The driver should handle things described in the OPA datasheet. With a
 quick glance, there seems to be one GPIO and one power line to OPA.

Hm. Why need a driver for a specific piece of hardware? For software it is just 
an
analog TV out with additional control options.

And, it must not be the OPA362 - it could be something completely different.

 
 [1] 
 https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/94072/343691.aspx
 
 And we have to disable (High-Z) the OPA362 amplifier if TVout is not in use 
 since the
 line is shared with a different function (microphone input).
 
 The reasons to use the OPA362 at all are to do short circuit protection and 
 to high-Z
 the driver (both are n/a with the DM3730 as far as we know).
 
 The code we did use successfully in the 2.6.32 board file is:
 
 120 #define TV_OUT_GPIO 23
 
 374 static int gta04_panel_enable_tv(struct omap_dss_device *dssdev)
 375 {
 376 u32 reg;
 377 
 378 #define ENABLE_VDAC_DEDICATED   0x03
 379 #define ENABLE_VDAC_DEV_GRP 0x20
 380 #define OMAP2_TVACEN(1  11)
 381 #define OMAP2_TVOUTBYPASS   (1  18)
 382 
 383 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER,
 384 ENABLE_VDAC_DEDICATED,
 385 TWL4030_VDAC_DEDICATED);
 386 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER,
 387 ENABLE_VDAC_DEV_GRP, TWL4030_VDAC_DEV_GRP);
 
 All that i2c stuff should be handled by using the normal regulator
 framework.
 
 388 
 389 /* idea taken from 
 https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/94072/343691.aspx
  */
 390 reg = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
 391 //  printk(KERN_INFO Value of DEVCONF1 was: %08x\n, reg);
 392 reg |= OMAP2_TVOUTBYPASS;   /* enable TV bypass mode for 
 external video driver (for OPA362 driver) */
 393 reg |= OMAP2_TVACEN;/* assume AC coupling to remove 
 DC offset */
 394 omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
 395 reg = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
 396 //  printk(KERN_INFO Value of DEVCONF1 now: %08x\n, reg);
 397 
 398 gpio_set_value(TV_OUT_GPIO, 1); /* enable output driver (OPA362) 
 */
 399 
 400 return 0;
 401 }
 402 
 403 static void gta04_panel_disable_tv(struct omap_dss_device *dssdev)
 404 {
 405 gpio_set_value(TV_OUT_GPIO, 0); /* disable output driver (and 
 re-enable microphone) */
 406 
 407 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0x00,
 408 TWL4030_VDAC_DEDICATED);
 409 twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0x00,
 410 TWL4030_VDAC_DEV_GRP);
 411 }
 412
 413 static struct omap_dss_device gta04_tv_device = {
 414 .name = tv,
 415 .driver_name = venc,
 416 .type = OMAP_DISPLAY_TYPE_VENC,
 417 /* GTA04 has a single composite output (with external video 
 driver) */
 418 .phy.venc.type = OMAP_DSS_VENC_TYPE_COMPOSITE,
 419 .phy.venc.invert_polarity = true,   /* needed if we use 
 external video driver */
 420 .platform_enable = gta04_panel_enable_tv,
 421 .platform_disable = gta04_panel_disable_tv,
 422 };
 
 I think (but don't know) that controlling the TWL/VDAC is no longer needed 
 because
 it should be done through the connector-analog-tv driver.
 
 I don't think VDAC is related to the connector (although I didn't
 actually look at the analog video when I created the new
 connector-analog-driver). If there's something specifically related to
 an analog tv out connector that requires power, then, yes, it's needed.
 But if it's all about OMAP's VENC and OPA, then the connector itself
 does not require anything

Re: DSS display-new custom enable/disable hooks

Hi Tomi,

Am 25.09.2013 um 12:50 schrieb Tomi Valkeinen:

 On 25/09/13 12:00, Dr. H. Nikolaus Schaller wrote:
 
 Well, OPA is a distinct hardware block in the video path, I see no issue
 in having an OPA encoder driver, that sits in between VENC and the
 connector.
 
 The driver should handle things described in the OPA datasheet. With a
 quick glance, there seems to be one GPIO and one power line to OPA.
 
 Hm. Why need a driver for a specific piece of hardware? For software it is 
 just an
 analog TV out with additional control options.
 
 I'm not sure I follow. Linux device drivers are drivers for specific
 pieces of hardware. If the hardware needs to be controlled somehow, like
 setting gpios, enabling regulators, then we need a driver for that piece
 of hardware.

 
 And, it must not be the OPA362 - it could be something completely different.
 
 Right. If it's something completely different, then you need a driver
 for the completely different piece of hardware. At the board code, or
 board's device tree data, you specify which pieces of hardware you have
 on your board, and the respective drivers are then used

 
 So, is the GPIO the one that goes to OPA?
 
 Yes. Like the enable_gpio in struct panel_dpi_platform_data.
 
 So I now think we would be happy if the connector-analog-tv would have a gpio
 in its platform data that can handle such an enable/disable.
 
 Sure, but the gpio is not related to the connector, it's related to
 another component.

I would see it as a part of the interface.

 And say, if we added the enable gpio to the
 connector. What if the next board uses another version of OPA that
 requires two gpios. Should we then add another gpio to the connector?
 Maybe third also? How about a bunch of regulators? Where does it end?

Yes. Because we did have this already for the LCD panels (before display-new)
and it was reduced in the latest updates to a single gpio for reasons I don't 
know.

But why should we hesitate to solve an existing problem because there could
arrive a not-yet existing one of low likelihood?

 
 The DEVCONF1 register is problematic. For that we need some kind of
 platform hooks. We have some already for PM and DSI pins, so we could
 add a new one for TV-out. However, the DSI pins (hopefully) could be
 handled by the pinmuxing framework. Maybe that would be applicable here
 also.
 
 Hm. Looks like a complex solution for a simple problem and isn't related to
 pinmuxing (IMHO).
 
 Right, I only suggested pinmuxing as that's why we need the callback for
 DSI. I don't remember the details about DEVCONF1 and tv-out.
 
 And I disagree that it's a simple problem =). Making generic, reusable
 drivers is not simple.
 Making a hack to make it work on your particular
 platform and board is simple, though.

But could be a good starting point until someone else has a real need for
a different solution :)

And in my view our hack would just be an add-on, not removing any existing
functionality. I.e. all those who were happy with the existing solution will be
as well in the future.

The only conflict I currently see is that if they don't initialize the 
enable_gpio to -1
and happen to have a gpio #0 there would be an initialization problem.

Anyways the connector-analog-tv is really new in the kernel and we are probably
the first ones who try to use it in real life.

 
 Could we just add a enable_ac and enable_bypass  to struct 
 connector_atv_platform_data,
 that sets/resets these flags in the DEVCONF1 register each time the tvout is 
 enabled?
 
 No, those are properties of the SoC, as far as I understand, nothing to
 do with the connector.

Hm. I again get the impression that we have a different view on what a 
connector is.

For me the connector that should be seen in kernel code are the analog video
outputs of the SoC (i.e. TVOUT1, TV_VFB1, TV_OU2, TV_VFB2). Not the physical
one going to some TV screen or other video signal consumer outside the board.

Like with UARTs. They are not drivers for a 9 or 25 pin socket. And there may be
a level shifetr chip in between that the software does not see.

 Although I have to say I have no idea what TV AC
 coupled load enable or Active high enable AVDAC TV out bypass do.
 
 I guess I need to refresh my memory on the VENC, although if I recall
 right, it wasn't explained very well in the TRM.

There is a post-amplifier stage right after the Video DAC on the DM3730 chip
and these bits we discuss control some electrical properties of that 
post-amplifier.

I.e. bypass means that it is turned off and the VDAC signal is directly fed to 
the
output pin.

Section 7.2.3 and 7-58 to 7-61 depict this.

 Also, note that drivers cannot touch DEVCONF1 register. That can only be
 touched by the OMAP's platform code.

Ah, I see.

That may be one of the reasons why it did end up in our 2.6.32 board file,
because there we know that it is an OMAP3 and can directly read/write registers.

But I wonder how drivers access the DISPC to modify e.g. sync

Re: DSS display-new custom enable/disable hooks

Hi Tomi,

Am 25.09.2013 um 15:57 schrieb Tomi Valkeinen:

 On 25/09/13 15:26, Dr. H. Nikolaus Schaller wrote:
 
 Sure, but the gpio is not related to the connector, it's related to
 another component.
 
 I would see it as a part of the interface.
 
 I don't know what you mean here with interface.

interface = set of mechanical, electrical and logical definitions so that two 
components can be connected and work together for communication

Here I refer mostly to the signals coming out / going into the DM3730 chip.

 
 But why should we hesitate to solve an existing problem because there could
 arrive a not-yet existing one of low likelihood?
 
 Even if a solution works, but is clearly not correct in design-sense, I
 don't want to merge it. Why? In the future, if and when the wrong
 solution creates problems, somebody needs to fix it. Who'll it be? Yes,
 me, the maintainer of the software. And so I want to avoid merging
 anything that I know might cause problems in the future.

Yes, I understand that and therefore we discuss it before we expect that
you accept any code.

 
 And I disagree that it's a simple problem =). Making generic, reusable
 drivers is not simple.
 Making a hack to make it work on your particular
 platform and board is simple, though.
 
 But could be a good starting point until someone else has a real need for
 a different solution :)
 
 Well, see my comment above about who'll need to fix it =). Even if we
 don't find a good solution, and merge the hack, I want first to try to
 find a good solution.
 
 Anyways the connector-analog-tv is really new in the kernel and we are 
 probably
 the first ones who try to use it in real life.
 
 Possibly. I did try it with Beagle, if I recall right, but I guess it's
 maybe the simplest possible hardware setup.
 
 Could we just add a enable_ac and enable_bypass  to struct 
 connector_atv_platform_data,
 that sets/resets these flags in the DEVCONF1 register each time the tvout 
 is enabled?
 
 No, those are properties of the SoC, as far as I understand, nothing to
 do with the connector.
 
 Hm. I again get the impression that we have a different view on what a 
 connector is.
 
 Connector here means the physical component that is the
 S-video/composite connector, to which the cable is connected. In this
 case it doesn't really do much at all, but we have a driver for it
 because the display device model requires it. We need a kind of
 terminator at the end of the video pipeline, and that is either a
 panel driver or a connector driver.

Hm. I a not sure if this model is complete if it ends at the physical connector.
But that would be a different topic.

 Let me describe how DVI works on Beagle/Panda, to give a better example.
 We have the following components, arrows showing the dataflow:
 
 DPI - TFP410 - DVI connector
 
 DPI is the DPI encoder in the SoC's DSS. TFP410 takes DPI input, and
 outputs DVI. And DVI connector represents the physical connector on the
 board.

Ok!

 We have drivers for each of those components, and they handle things
 related only to that particular component:
 
 - DPI driver handles programming the DPI registers on the SoC, and any
 regulators required to power the DPI encoder.

Ok!

 
 - TFP410 driver handles power-down GPIO to enable/disable TFP410, and
 regulators related to it.

Ok!

 
 - DVI connector driver uses i2c to read the EDID from the monitor, and
 also supplies the required +5V to the DVI connector. It could also
 handle hotplug detection.

Ah, I start to understand the way how you are thinking: a signal-transformation
pipeline starting with the framebuffer RAM and ending with something we can see.

This is much more fine grained than I had expected.

 Each driver should only be concerned about things related to that
 particular component. For example, you could change the SoC, you could
 change the TFP410, but DVI connector would still be the same.
 
 For me the connector that should be seen in kernel code are the analog 
 video
 outputs of the SoC (i.e. TVOUT1, TV_VFB1, TV_OU2, TV_VFB2). Not the physical
 one going to some TV screen or other video signal consumer outside the board.
 
 Like with UARTs. They are not drivers for a 9 or 25 pin socket. And there 
 may be
 a level shifetr chip in between that the software does not see.
 
 Right. For UART, it works. For display, we have so complex video
 pipelines that such a simple model does not work.
 
 Of course, if the video pipeline has so trivial components that require
 no control and no regulators, well, I don't see a need to have drivers
 for those.

Ok!

 
 Although I have to say I have no idea what TV AC
 coupled load enable or Active high enable AVDAC TV out bypass do.
 
 I guess I need to refresh my memory on the VENC, although if I recall
 right, it wasn't explained very well in the TRM.
 
 There is a post-amplifier stage right after the Video DAC on the DM3730 chip
 and these bits we discuss control some electrical properties of that 
 post

Re: DSS display-new custom enable/disable hooks

2013-09-26 Thread Dr. H. Nikolaus Schaller


Am 26.09.2013 um 13:49 schrieb Tomi Valkeinen:

 On 26/09/13 14:01, Dr. H. Nikolaus Schaller wrote:
 
 So this essentially means that the invert property and the bypass, 
 acen properties
 should be defined for the VENC (if it also controls the DAC-Stage).
 
 I.e. I am not sure if invert is really a property (control) of the connector 
 or an amplifier.
 
 Invert bit is programmed to VENC, so it is a property of VENC. At least
 in the end.
 
 The question is, does it need to be changed dynamically at runtime? I
 don't think so. OPA always wants its input inverted. Without OPA, the TV
 out signal is always un-inverted. So we can have it as a property of
 VENC, just like bypass and acen.
 
 True, it's currently set at the connector, but I think that's wrong.

Yes, this is how I would have argued as well.

 
 The OPA itself then should also participate in suspend/resume. Well, that
 would be something important for proper power management. Only then
 we can make sure the OPA is disabled correctly.
 
 There isn't really anything to suspend/resume on that level. If the
 display is enabled, it stays enabled, there's no automatic suspend. If
 there's a system suspend, omapfb (or similar component) will disable the
 displays.
 
 So it's only about enable/disable on this level.
 
 Ok. I think this is also sufficient since the OPA362 is in low power if it is
 disabled. I.e. suspend and disable are the same.
 
 I think that fits more or less all hardware.
 
 Well, sometimes there could be different power-states, and waking up
 from those takes different amounts of time. I think that's normally not
 needed for display, it doesn't matter if enabling a display encoder
 takes 15ms or 100ms.
 
 Although one could argue that one is just controlling the GPIO and the other
 one is controlling some regulator...
 
 Sorry, didn't understand that one...

I meant that there could be a differece between enable/disable and power-on/off
(e.g. retaining register values vs. loosing everything). But I can't imagine 
that for
a simple video amplifier.

 
 Well, this is perhaps a bit about semantics, but it is a driver for
 OPA362 hardware. Sure, we can make a more generic driver if we see that
 there are other external amps that have very similar controls.
 
 That was my assumption. Analog amplifiers just have an input and an output.
 And can be powered on or off. This would imho fit 99% of all such amplifiers.
 Well, one could think about switching different signal strenghts but this is 
 AFAIK
 not defined by the composite video standards.
 
 Ok.
 
 But I would presume all of them have power and gpio inputs. Does the
 power need to be enabled before enabling the gpio, and if so, for how
 long does the power need to be enabled until the gpio can be set? Etc. I
 don't know if simple components like analog amp needs those, but very
 often display component datasheets list quite specifically the order and
 timing of all the powers and gpios.
 
 That said... Maybe a generic amp driver would work for the 99% of cases.
 It's always difficult to guess what kind of hardware there is out there =).

Yes, and therefore I think we should focus on the 362 first like the 410.

 
 But it's
 still an OPA362 driver, but it would also be OPA123, OPA321, etc. driver.
 
 Making it external-video-amplifier driver is probably taking it too
 far. We don't know what kind of amps there are. Maybe some are
 controlled via i2c. Dumping all the different functionality for
 different amps into one driver would just make one messy driver.
 
 Ok, I will start to write an amplifier-opa362.c based on the 
 encoder-ftp410.c
 code.
 
 Yep, I don't have a strong opinion on whether to create opa362, or more
 generic driver. Try one =).

Well, let's start with amplifier-opa362 and see if someone else ever needs
a different one. And amplifier-generic would be a quite strange name...

 
 That said, if the feature, invert in this case, never needs to be
 changed at runtime, there's no real reason to have that kind of method
 for OPA to change the inversion. So the board file could just pass the
 invert flag as a parameter to VENC.
 
 Yes, that is what I now also think. And the flag should/could be removed from
 the connector-analog-tv at all. I.e. I think the opa362 driver should have a 
 call
 
  in-ops.atv-invert_vid_out_polarity(in, true);
 
 in the opa362_enable() code because it knows that it wants to see an inverted
 input.
 
 I think the whole function should be removed. Again, if there's no need
 to ever change it during runtime by OPA, the call is quite unnecessary.
 And the invert flag could just be passed to VENC in platform data.

Yes, that is how I also would prefer it.

 And note that with change it during runtime I don't mean VENC could
 not change it during runtime. If the bit needs to be cleared when the
 output is disabled, VENC can do that. But that is VENC's internal thing,
 no need for a invert_vid_out_polarity() API for it.

Yes.

 
 Now how can we

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

2013-10-10 Thread Dr. H. Nikolaus Schaller

Hi Tomi,

Am 10.10.2013 um 10:19 schrieb Tomi Valkeinen:

 Hi,
 
 On 10/10/13 00:08, Marek Belisko wrote:
 For communicating with driver is used gpio bitbanging because TD028 does
 not have a standard compliant SPI interface. It is a 3-wire thing with
 direction reversal.
 
 Isn't that SPI_3WIRE?

Maybe - but we have no complete datasheet and I don't know an official spec of
a 3-wire SPI protocol to compare how 3-wire should work.

And I think (but I may be wrong) that SPI_3WIRE is an optional feature of the 
SoC
specific SPI drivers and in my understanding the OMAP has no such driver:

http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L874

And spi-bitbang.c hasn't either.

So I would prefer to leave this as an area for optimizations for future work.
Maybe we can add some more comments on this.

 
 Communication with display is used only during panel enable/disable so it's
 not performance issue.
 
 Signed-off-by: Marek Belisko ma...@goldelico.com
 Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
 ---
 drivers/video/omap2/displays-new/Kconfig   |   6 +
 drivers/video/omap2/displays-new/Makefile  |   1 +
 .../omap2/displays-new/panel-tpo-td028ttec1.c  | 537 
 +
 include/video/omap-panel-data.h|  22 +
 4 files changed, 566 insertions(+)
 create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
 
 diff --git a/drivers/video/omap2/displays-new/Kconfig 
 b/drivers/video/omap2/displays-new/Kconfig
 index 6c90885..3f86432 100644
 --- a/drivers/video/omap2/displays-new/Kconfig
 +++ b/drivers/video/omap2/displays-new/Kconfig
 @@ -56,6 +56,11 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
 help
   LCD Panel used in TI's SDP3430 and EVM boards
 
 +config DISPLAY_PANEL_TPO_TD028TTEC1
 +tristate TPO TD028TTEC1 LCD Panel
 +help
 +  LCD panel used by Openmoko.
 +
 config DISPLAY_PANEL_TPO_TD043MTEA1
 tristate TPO TD043MTEA1 LCD Panel
 depends on SPI
 @@ -70,4 +75,5 @@ config DISPLAY_PANEL_NEC_NL8048HL11
  This NEC NL8048HL11 panel is TFT LCD used in the
  Zoom2/3/3630 sdp boards.
 
 +
 
 Extra change.
 
 endmenu
 diff --git a/drivers/video/omap2/displays-new/Makefile 
 b/drivers/video/omap2/displays-new/Makefile
 index 5aeb11b..0323a8a 100644
 --- a/drivers/video/omap2/displays-new/Makefile
 +++ b/drivers/video/omap2/displays-new/Makefile
 @@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
 obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
 obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
 obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
 +obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
 obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
 diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c 
 b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
 new file mode 100644
 index 000..b63586e
 --- /dev/null
 +++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
 @@ -0,0 +1,537 @@
 +/*
 + * Toppoly TD028TTEC1 panel support
 + *
 + * Copyright (C) 2008 Nokia Corporation
 + * Author: Tomi Valkeinen tomi.valkei...@nokia.com
 + *
 + * Neo 1973 code (jbt6k74.c):
 + * Copyright (C) 2006-2007 by OpenMoko, Inc.
 + * Author: Harald Welte lafo...@openmoko.org
 + *
 + * Ported and adapted from Neo 1973 U-Boot by:
 + * H. Nikolaus Schaller h...@goldelico.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.
 + *
 + * This program is distributed in the hope that it will be useful, but 
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License along 
 with
 + * this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +
 +#include linux/module.h
 +#include linux/delay.h
 +#include linux/platform_device.h
 +#include linux/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 data_lines;
 +
 +struct omap_video_timings videomode;
 +
 +int cs_gpio;
 +int scl_gpio;
 +int din_gpio;
 +int dout_gpio;
 
 Three wires, but four gpios? What am I missing here...

We have wired up the 3-wire SPI interface of the display
to 4 wires of the McSPI interface because we initially thought
that it could work in 4 wire mode as well.

The next step we did was to port the driver code from the
Openmoko Neo1973 U-Boot which used the gpio-bitbang
mechanism.

Since

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

2013-10-10 Thread Dr. H. Nikolaus Schaller

Hi Tomi,

Am 10.10.2013 um 13:10 schrieb Tomi Valkeinen:

 On 10/10/13 12:34, Dr. H. Nikolaus Schaller wrote:
 Hi Tomi,
 
 Am 10.10.2013 um 10:19 schrieb Tomi Valkeinen:
 
 Hi,
 
 On 10/10/13 00:08, Marek Belisko wrote:
 For communicating with driver is used gpio bitbanging because TD028 does
 not have a standard compliant SPI interface. It is a 3-wire thing with
 direction reversal.
 
 Isn't that SPI_3WIRE?
 
 Maybe - but we have no complete datasheet and I don't know an official spec 
 of
 a 3-wire SPI protocol to compare how 3-wire should work.
 
 Yep, and I know only what I read on wikipedia a few hours ago =).
 
 And I think (but I may be wrong) that SPI_3WIRE is an optional feature of 
 the SoC
 specific SPI drivers and in my understanding the OMAP has no such driver:
 
 http://lxr.free-electrons.com/source/drivers/spi/spi-omap2-mcspi.c#L874
 
 And spi-bitbang.c hasn't either.
 
 So I would prefer to leave this as an area for optimizations for future work.
 Maybe we can add some more comments on this.
 
 Ok. Well, I guess it's not too bad. But it's really not something that
 should be in the panel driver (assuming it's standard 3-wire SPI).
 Some SoC could support 3-wire SPI, and then it'd be good to use the SoCs
 hardware for SPI communication. Having bitbanging hardcoded into the
 driver will prevent that.

Yes, I agree and I am willing to help if someone comes up with such a SoC.
At the moment we have connected it to the OMAP3 only.

I.e. I want not to do a lot of work for others who we just guess about that they
might exist...

 
 +  int cs_gpio;
 +  int scl_gpio;
 +  int din_gpio;
 +  int dout_gpio;
 
 Three wires, but four gpios? What am I missing here...
 
 We have wired up the 3-wire SPI interface of the display
 to 4 wires of the McSPI interface because we initially thought
 that it could work in 4 wire mode as well.
 
 The next step we did was to port the driver code from the
 Openmoko Neo1973 U-Boot which used the gpio-bitbang
 mechanism.
 
 Since it worked and is used only for enabling/disabling the
 display and for no other purpose we never felt it important
 to check or modify the code to use SPI.
 
 But you are right - we don't use the din_gpio really since
 we never read registers from the chip. So 3 gpios could be
 sufficient.
 
 Or we must handle the case that din_gpio == dout_gpio
 in panel_probe to avoid duplicate use of the same gpio.
 
 The panel hardware has three wires, so the panel driver (if it does
 handle the bus by bitbanging) can only refer to three gpios.

Hm. The panle hardware has 3 but the SoC (OMAP3) the driver
is running on has 4.

 So either
 the bus details should be hidden by using the normal spi framework, or
 if the driver does the bitbanging, use the gpios as specified in the
 panel spec. The panel driver cannot contain any board specific stuff.

The bitbang driver shown below can handle either 3 or 4 gpios (except
for initialization).

 
 +static int jbt_spi_xfer(struct panel_drv_data *data, int wordnum, int 
 bitlen)
 
 Hmm, if it's not SPI, maybe it shouldn't be called SPI?
 
 Yes, we can remove the _spi_ in this name.
 
 Or maybe use spi3w or such, just to make it clear it's not plain
 standard spi. Again, presuming it's really 3-wire spi =).
 
 +static int td028ttec1_panel_probe(struct platform_device *pdev)
 +{
 +  struct panel_drv_data *ddata;
 +  struct omap_dss_device *dssdev;
 +  int r;
 +
 +  ddata = devm_kzalloc(pdev-dev, sizeof(*ddata), GFP_KERNEL);
 +  if (ddata == NULL)
 +  return -ENOMEM;
 +
 +  platform_set_drvdata(pdev, ddata);
 +
 +  if (dev_get_platdata(pdev-dev)) {
 +  r = td028ttec1_panel_probe_pdata(pdev);
 +  if (r)
 +  return r;
 +  } else {
 +  return -ENODEV;
 +  }
 +
 +  if (gpio_is_valid(ddata-cs_gpio)) {
 +  r = devm_gpio_request_one(pdev-dev, ddata-cs_gpio,
 +  GPIOF_OUT_INIT_HIGH, lcd cs);
 +  if (r)
 +  goto err_gpio;
 +  }
 +
 +  if (gpio_is_valid(ddata-scl_gpio)) {
 +  r = devm_gpio_request_one(pdev-dev, ddata-scl_gpio,
 +  GPIOF_OUT_INIT_HIGH, lcd scl);
 +  if (r)
 +  goto err_gpio;
 +  }
 +
 +  if (gpio_is_valid(ddata-dout_gpio)) {
 +  r = devm_gpio_request_one(pdev-dev, ddata-dout_gpio,
 +  GPIOF_OUT_INIT_LOW, lcd dout);
 +  if (r)
 +  goto err_gpio;
 +  }
 +
 +  if (gpio_is_valid(ddata-din_gpio)) {
 +  r = devm_gpio_request_one(pdev-dev, ddata-din_gpio,
 +  GPIOF_IN, lcd din);
 +  if (r)
 +  goto err_gpio;
 +  }
 +
 +  /* according to data sheet: wait 50ms (Tpos of LCM). However, 50ms
 +   * seems unreliable with later LCM batches, increasing to 90ms */
 +  mdelay(90);
 
 What is this delay for? Usually sleeps/delays should be between two HW
 actions. Here there's nothing below this line that would count as such
 an action.
 
 I guess that this delay

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

2013-10-10 Thread Dr. H. Nikolaus Schaller


Am 10.10.2013 um 14:26 schrieb Lars-Peter Clausen:

 On 10/10/2013 02:13 PM, Tomi Valkeinen wrote:
 On 10/10/13 14:52, Dr. H. Nikolaus Schaller wrote:
 
 Yes, I agree and I am willing to help if someone comes up with such a SoC.
 At the moment we have connected it to the OMAP3 only.
 
 True, but even without that kind of SoC, SPI bitbanging should be
 handled by an SPI driver, not by the drivers that use the bus.
 
 I.e. I want not to do a lot of work for others who we just guess about that 
 they
 might exist...
 
 Yep. It's fine for me, it's not that much extra code in the panel driver.
 
 The panel hardware has three wires, so the panel driver (if it does
 handle the bus by bitbanging) can only refer to three gpios.
 
 Hm. The panle hardware has 3 but the SoC (OMAP3) the driver
 is running on has 4.
 
 Right, but this panel driver is a driver for the panel hardware. Not for
 the SoC, or the SoC+panel combination. So the panel driver must only use
 resources as seen by the panel hardware.
 
 So either
 the bus details should be hidden by using the normal spi framework, or
 if the driver does the bitbanging, use the gpios as specified in the
 panel spec. The panel driver cannot contain any board specific stuff.
 
 The bitbang driver shown below can handle either 3 or 4 gpios (except
 for initialization).
 
 It's not a bitbang driver, it's a panel driver. And anyway, if I
 understood right, your use of 4 gpios was just a hack to try to make it
 look like a normal 4-wire SPI bus. What you really have is 3 wires, 3
 gpios. I don't see any reason to use 4 gpios, as two of them are the same.

There is a protection resistor in the one defined as output so that
protocol errors don't have two outputs work against each other.

 
 Hmm, how does it work anyway. Did I understand it right, the panel's
 'DIN' pin is connected to two gpios on the SoC, and one of those gpios
 is set as output, and the other as input?

Yes.

 So the SoC is always pulling
 that line up or down, and the panel is also pulling it up or down when
 it's sending data. I'm no HW guy but that sounds quite bad =).

Yes, that is the strange thing with this protocol. It does a direction reversal
after some time. I.e. the panel switches its input to output and the SoC has
to be fast enough to do the same. Therefore, we have one output GPIO
(protected by a resistor) and a separate input GPIO.

Sometimes interfacing hardware is indeed strange.

 
 I've never written or studied a bitbanging driver, but shouldn't there
 be just one gpio used on the SoC for DIN, and it would be set to either
 output or input mode, depending on if we are reading or writing?
 
 Back in the OpenMoko days we used the panel in normal 4-wire SPI mode with
 the GPIO bitbang SPI master. The bitbang code in this driver also looks like
 normal 4 wire.


Thanks for this hint!

Maybe using a standard 4-wire SPI simply works if we only write data and
make sure the panel is not sending anything...

I still hesitate to break working code because it needs quite some time to debug
and we don't even know if it ever works, i.e. sends us to swampy ground...

BR,
Nikolaus


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

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

Hi all,

Am 11.10.2013 um 06:41 schrieb Tomi Valkeinen:

 On 10/10/13 21:58, Lars-Peter Clausen wrote:
 
 According to the datasheet the the panel as a dedicated dout pin. Maybe
 you did not connect it in your design, which means you won't be able to
 read any data from the panel at all.
 
 I don't see a dedicated dout in the datasheet...
 http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf
 
 Also your custom bitbang code looks a bit strange:
 
gpio_set_value(data-dout_gpio, 1);
if (gpio_get_value(data-din_gpio) == 0)
return 1;
 
 You set the state on the dout pin and then read the din pin, if both do
 not match you abort with an error. This suggest that, for whatever
 reason,

Detecting hardware failure.

If the panel is not connected or broken (short circuit) reading back
may fail and this can help to detect a hardware failure.

 you feed the dout pin back into the din pin in your design. Btw.
 this is also the only place where din is used in your driver.

Ok, I see the issue with that. It assumes this type of feedback which does
not necessarily exist. I.e. if someone else doesn't have this feedback
line the driver will not work.

So a more general solution should work with any setup, even if no
din gpio has been defined. I.e. do this test only if the din_gpio exists.

The main reason that we don't use din_gpio elsewhere is that we have
no jbt_read() function because we lack information what we can
read from the panel controller chip - and have not seen a use-case
for that.

And thanks to your hint, I think either returning 1 is wrong (should be
some -EIO or similar). Or the return r; at the end of td028ttec1_panel_enable
is wrong (should be return rc ? -EIO : 0; ).

We will check that.

 Yes, he said the single Serial interface data input/output pin is
 connected to both din and dout on the SoC.

I have found two public links which may describe what we do:

The panel data sheet [1], Section 9 describes the interface as
3 wire serial interface.

It sometimes calls the data lines DIN and DOUT and describes them
separately, i.e. like a 4 wire interface.

So I guess the jbt6k chip has indeed 4 wires, but (as you said),

din/dout are lines are tied together on the panel side to save
(share) one wire in the flex cable.
 
[2] shows in figure 2 an example how to connect a 3-wire interface
to a 4-wire SPI SoC. This is the way we have done it.


  I guess the purpose of that
 gpio_get_value() is to ensure that the panel is not pulling the line
 when the SoC is writing to it. Not that I really understand how that can
 work, but I'm not a HW guy =).

Finally, I have checked one detail which rules out to use a standard
SPI driver for OMAP on our board. The reason is that we have a McBSP
port of the OMAP3 and not a McSPI. So we have to run this 3 wire
serial interface protocol by bitbanging.

IMHO, the most flexible way to hook up the panel (and driver) to arbitrary
hardware is by using GPIOs and not having the panel driver restrict to a
SPI interface.

And having the bitbanging encapsulated in the driver itself (instead on
relying on some spi-bitbang) makes it less dependent on changes
somewhere else. I.e. the driver module is indeed a module.

Marek is preparing an updated patch for further discussion.

BR,
Nikolaus


[1]: http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf
[2]: http://www.totalphase.com/support/kb/10059/

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

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

Hi Lars-Peter,
ah, I didn't see your mail while writing mine - so some overlap.

Am 11.10.2013 um 09:08 schrieb Lars-Peter Clausen:

 On 10/11/2013 06:41 AM, Tomi Valkeinen wrote:
 On 10/10/13 21:58, Lars-Peter Clausen wrote:
 
 According to the datasheet the the panel as a dedicated dout pin. Maybe
 you did not connect it in your design, which means you won't be able to
 read any data from the panel at all.
 
 I don't see a dedicated dout in the datasheet...
 http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf
 
 Hm, ok, looks like the display controller used in the panel (the jbt6k74) has 
 separate DIN and DOUT, but the panel only has one pin.

Yes

 But the datasheet for the panel is not exactly clear

Yes

 on whether it's DIN pin is both the DIN and DOUT pin from the controller or, 
 just DIN and DOUT not being connected at all.

I think they have a 4-wire controller in the panel and tied the lines together.
This works if they properly control the data direction.
There are some read commands where this direction reversal happens.

 
 
 Also your custom bitbang code looks a bit strange:
 
 gpio_set_value(data-dout_gpio, 1);
 if (gpio_get_value(data-din_gpio) == 0)
 return 1;
 
 You set the state on the dout pin and then read the din pin, if both do
 not match you abort with an error. This suggest that, for whatever
 reason, you feed the dout pin back into the din pin in your design. Btw.
 this is also the only place where din is used in your driver.
 
 Yes, he said the single Serial interface data input/output pin is
 connected to both din and dout on the SoC. I guess the purpose of that
 gpio_get_value() is to ensure that the panel is not pulling the line
 when the SoC is writing to it. Not that I really understand how that can
 work, but I'm not a HW guy =).
 
 Hm, ok. I don't think the panel will ever actively drive the line.

Well it will drive it if we issue some read command (but I have no information
about these commands).

 So in my opinion using either the McBSP SPI master or the GPIO bitbang SPI 
 master should work just fine. You just wouldn't be able to read any register 
 from the device. But the driver is not attempting to do this, so it should be 
 fine.

I am not sure if there is a SPI driver for a McBSP port [1]? And to make that
work (reliably) and tested it might need a lot of work for us. At least I think
such a change (e.g. setting up clock polarity etc.) is not done in some minutes.
And the only feedback we have from the panel is does not work/works. I.e.
if we are not lucky that it works immediately we have no real means to debug.

IMHO it also gives more flexibility to board designers to choose GPIOs instead
of enforcing some SPI interface by the driver (and encapsulate this arguable
protocol in the driver). Maybe some board has 3 spare GPIOs but neither
McBSPs nor McSPIs available.

BR,
Nikolaus

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/053064.html

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

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.

Hi all,

Am 11.10.2013 um 11:06 schrieb Lars-Peter Clausen:

 On 10/11/2013 10:59 AM, Belisko Marek wrote:
 Hi Tomi,
 
 On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com 
 wrote:
 On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote:
 
 I am not sure if there is a SPI driver for a McBSP port [1]? And to make 
 that
 work (reliably) and tested it might need a lot of work for us. At least I 
 think
 such a change (e.g. setting up clock polarity etc.) is not done in some 
 minutes.
 And the only feedback we have from the panel is does not work/works. 
 I.e.
 if we are not lucky that it works immediately we have no real means to 
 debug.
 
 IMHO it also gives more flexibility to board designers to choose GPIOs 
 instead
 of enforcing some SPI interface by the driver (and encapsulate this 
 arguable
 protocol in the driver). Maybe some board has 3 spare GPIOs but neither
 McBSPs nor McSPIs available.
 
 This has been an interesting thread, I've learnt a lot =).
 
 I still think the panel driver should not handle this, but there should
 be a separate spi bitbang driver for it.
 
 I understand you're not enthusiastic going that way, as the current
 version works for you. However, when using DT, we need to think how to
 represent the hardware in the device tree data, and it has to be right
 from the beginning.
 
 That's why I won't allow representing this panel as having 4 gpios in
 the DT data, because that is not correct. The panel has 3 pins. But
 then, the panel does allow reading, which could be implemented using 4
 gpios as you have done. This data should be in the spi-bitbang data, and
 the panel should just use the standard SPI framework.
 I disagree. There are different drivers which pass in platform data
 gpios (encoder-tfp410.c or encoder-tpd12s015.c)
 and those must be covered by DT then. I cannot see problem why to have
 for td028 panel 3 or 4 gpios defined in DT.
 
 The problem is not representing it in the devicetree, but representing it
 correctly. This is a SPI slave device, hence it should be presented in the
 devicetree as a SPI slave device and not as a platform device with 4 GPIOs.

Hm. Is this a SPI or does it just look like one? Or is it some - otherwise
unknown - 3 wire serial interface. Or is it a 3(+1) GPIO slave device?
I am still not sure about this.

If we really want to do it correctly, we may have to write a driver for that
special serial protocol as well. If it turns out that we can't mis-use and tweak
it into a standard SPI driver with bit-bang backend.

I simply fear that we get dependencies with the SPI subsystem and have
to test, debug and maintain it. Maintaining the GPIO thing we currently have
is easy.

What would be against taking the GPIO approach first and then upgrade as soon
as someone raises his/her finger that he/she wants to really interface this 
display
differently and is not happy with the 3/4 GPIOs? Either they come up with a 
patch
or contact the driver author (=me).

BR,
Nikolaus

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

Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.