* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2016-11-11 20:26 UTC (permalink / raw)
To: Linus Walleij
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <CACRpkdaP3_6x0GMpy_+fSok5r+5CP6RvP6dmDCtz4ayAm-TuSQ@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [161111 12:17]:
> On Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> > Having the pin control framework call pin controller functions
> > before it's probe has finished is not nice as the pin controller
> > device driver does not yet have struct pinctrl_dev handle.
> >
> > Let's fix this issue by adding deferred work for hogs. This is
> > needed to be able to add pinctrl generic helper functions.
> >
> > Note that the pinctrl functions already take care of the necessary
> > locking.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> I don't see why this is necessary?
It's needed because the pin controller driver has not yet
finished it's probe at this point. We end up calling functions
in the device driver where no struct pinctrl_dev is yet known
to the driver. Asking a device driver to do something before
it's probe is done does not quite follow the Linux driver model :)
> The hogging was placed inside pinctrl_register() so that any hogs
> would be taken before it returns, so nothing else can take it
> before the controller itself has the first chance. This semantic
> needs to be preserved I think.
>
> > + schedule_delayed_work(&pctldev->hog_work,
> > + msecs_to_jiffies(100));
>
> If we arbitrarily delay, something else can go in and take the
> pins used by the hogs before the pinctrl core? That is what
> we want to avoid.
>
> Hm, 100ms seems arbitrarily chosen BTW. Can it be 1 ms?
> 1 ns?
Yeah well seems like it should not matter but the race we need
to remove somehow.
> I'm pretty sure that whatever it is that needs to happen before
> the hog work runs can race with this delayed work under
> some circumstances (such as slow external expanders
> on i2c). It should be impossible for that to happen
> and I don't think it is?
Yes it's totally possible even with delay set to 0.
Maybe we could add some trigger on the first consumer request
and if that does not happen use the timer?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Linus Walleij @ 2016-11-11 20:17 UTC (permalink / raw)
To: Tony Lindgren
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161025210221.9150-2-tony@atomide.com>
On Tue, Oct 25, 2016 at 11:02 PM, Tony Lindgren <tony@atomide.com> wrote:
> Having the pin control framework call pin controller functions
> before it's probe has finished is not nice as the pin controller
> device driver does not yet have struct pinctrl_dev handle.
>
> Let's fix this issue by adding deferred work for hogs. This is
> needed to be able to add pinctrl generic helper functions.
>
> Note that the pinctrl functions already take care of the necessary
> locking.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
I don't see why this is necessary?
The hogging was placed inside pinctrl_register() so that any hogs
would be taken before it returns, so nothing else can take it
before the controller itself has the first chance. This semantic
needs to be preserved I think.
> + schedule_delayed_work(&pctldev->hog_work,
> + msecs_to_jiffies(100));
If we arbitrarily delay, something else can go in and take the
pins used by the hogs before the pinctrl core? That is what
we want to avoid.
Hm, 100ms seems arbitrarily chosen BTW. Can it be 1 ms?
1 ns?
I'm pretty sure that whatever it is that needs to happen before
the hog work runs can race with this delayed work under
some circumstances (such as slow external expanders
on i2c). It should be impossible for that to happen
and I don't think it is?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Benjamin Herrenschmidt @ 2016-11-11 19:12 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree, Guilherme G. Piccoli, marc.zyngier, linux-pci,
linuxppc-dev, robh+dt, frowand.list
In-Reply-To: <20161111163241.GL11945@leverpostej>
On Fri, 2016-11-11 at 16:32 +0000, Mark Rutland wrote:
> On Fri, Nov 11, 2016 at 08:30:43AM +1100, Benjamin Herrenschmidt
> wrote:
> >
> > On Wed, 2016-11-09 at 19:04 +0000, Mark Rutland wrote:
> > >
> > >
> > > If we don't have an interrupt-map on a PCI controller, why don't
> > > we
> > > instead log a message regarding that being missing, and give up
> > > early?
> >
> > Why ? It's legit to not support LSIs.
>
> Sure; I had envisioned a message like:
>
> pr_info("%s: no interrupt-map, INTx interrupts not possible\n",
> pci_controller_name);
>
> ... Which tells the user exaclty what we know, and doesn't imply
> either
> an error or the actual absence of HW support.
Works for me.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v7 9/9] DT:omap3+ads7846: use new common touchscreen bindings
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
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
Tested with OpenPandora.
Signed-off-by: H. Nikolaus Schaller <hns@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 | 3 ++-
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5..b8b3864 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;
wakeup-source;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index b0d1551..d12008a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -700,10 +700,19 @@
pendown-gpio = <&gpio3 30 GPIO_ACTIVE_HIGH>;
vcc-supply = <&vaux4>;
- 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 157345b..3627a63 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -66,6 +66,7 @@
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
ti,swap-xy;
- wakeup-source;
+ touchscreen-swapped-x-y;
+ linux,wakeup;
};
};
--
2.7.3
^ permalink raw reply related
* [PATCH v7 8/9] drivers:input:ads7846(+tsc2046): fix spi module table
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
Fix module table so that the driver is loaded if compiled
as module and requested by DT.
Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
---
drivers/input/touchscreen/ads7846.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index 400e421..50c85d2 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1532,6 +1532,16 @@ 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",
@@ -1546,4 +1556,3 @@ module_spi_driver(ads7846_driver);
MODULE_DESCRIPTION("ADS7846 TouchScreen Driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("spi:ads7846");
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 7/9] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (100%)
diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
similarity index 100%
rename from Documentation/devicetree/bindings/input/ads7846.txt
rename to Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
--
2.7.3
^ permalink raw reply
* [PATCH v7 6/9] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.
commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.
Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.
A new feature is to introduce scaling the min/max ADC values to the screen
size.
This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.
[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/input/ads7846.txt | 9 +++-
drivers/input/touchscreen/ads7846.c | 60 ++++++++++++++++++----
2 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt
index 9fc47b0..29f91ed 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,6 +26,12 @@ 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).
@@ -33,7 +39,7 @@ Optional properties:
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
- ti,swap-xy swap x and y axis
+ ti,swap-xy deprecated name for touchscreen-swapped-x-y
ti,settle-delay-usec Settling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers. If set to non-zero,
@@ -82,6 +88,7 @@ Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
pendown-gpio = <&gpio1 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 1ce3ecb..400e421 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
#include <linux/spi/ads7846.h>
#include <linux/regulator/consumer.h>
#include <linux/module.h>
+#include <linux/input/touchscreen.h>
#include <asm/irq.h>
/*
@@ -109,8 +110,13 @@ 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;
+
+ struct touchscreen_properties prop;
- bool swap_xy;
bool use_internal;
struct ads7846_packet *packet;
@@ -825,22 +831,36 @@ static void ads7846_report_state(struct ads7846 *ts)
*/
if (Rt) {
struct input_dev *input = ts->input;
+ int sx, sy;
+
+ dev_dbg(&ts->spi->dev,
+ "Raw point(%4d,%4d), pressure (%4u)\n",
+ x, y, Rt);
+
+ /* scale ADC values to desired output range */
+ sx = (ts->prop.max_x * (x - ts->x_min))
+ / (ts->x_max - ts->x_min);
+ sy = (ts->prop.max_y * (y - ts->y_min))
+ / (ts->y_max - ts->y_min);
- if (ts->swap_xy)
- swap(x, y);
+ dev_dbg(&ts->spi->dev,
+ "Scaled point(%4d,%4d), pressure (%4u)\n",
+ sx, sy, Rt);
+ /* report event */
if (!ts->pendown) {
input_report_key(input, BTN_TOUCH, 1);
ts->pendown = true;
dev_vdbg(&ts->spi->dev, "DOWN\n");
}
- input_report_abs(input, ABS_X, x);
- input_report_abs(input, ABS_Y, y);
+ touchscreen_report_pos(ts->input, &ts->prop,
+ (unsigned int) sx, (unsigned int) sy,
+ false);
input_report_abs(input, ABS_PRESSURE, ts->pressure_max - Rt);
input_sync(input);
- dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", x, y, Rt);
+ dev_vdbg(&ts->spi->dev, "%4d/%4d/%4d\n", sx, sy, Rt);
}
}
@@ -1212,6 +1232,8 @@ static const struct ads7846_platform_data *ads7846_probe_dt(struct device *dev)
pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
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");
of_property_read_u16(node, "ti,settle-delay-usec",
&pdata->settle_delay_usecs);
@@ -1315,7 +1337,6 @@ static int ads7846_probe(struct spi_device *spi)
ts->pressure_max = pdata->pressure_max ? : ~0;
ts->vref_mv = pdata->vref_mv;
- ts->swap_xy = pdata->swap_xy;
if (pdata->filter != NULL) {
if (pdata->filter_init != NULL) {
@@ -1355,18 +1376,35 @@ static int ads7846_probe(struct spi_device *spi)
input_dev->dev.parent = &spi->dev;
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+ input_dev->absbit[0] = BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) |
+ BIT_MASK(ABS_PRESSURE);
input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+ ts->x_min = pdata->x_min ? : 0;
+ ts->x_max = pdata->x_max ? : MAX_12BIT;
+ ts->y_min = pdata->y_min ? : 0;
+ ts->y_max = pdata->y_max ? : MAX_12BIT;
+
input_set_abs_params(input_dev, ABS_X,
- pdata->x_min ? : 0,
- pdata->x_max ? : MAX_12BIT,
+ ts->x_min,
+ ts->x_max,
0, 0);
input_set_abs_params(input_dev, ABS_Y,
- pdata->y_min ? : 0,
- pdata->y_max ? : MAX_12BIT,
+ ts->y_min,
+ ts->y_max,
0, 0);
input_set_abs_params(input_dev, ABS_PRESSURE,
pdata->pressure_min, pdata->pressure_max, 0, 0);
+ if (spi->dev.of_node) {
+ input_abs_set_min(input_dev, ABS_X, 0);
+ input_abs_set_min(input_dev, ABS_Y, 0);
+
+ touchscreen_parse_properties(ts->input, false, &ts->prop);
+ }
+
+ ts->prop.swap_x_y |= pdata->swap_xy;
+
ads7846_setup_spi_msg(ts, pdata);
ts->reg = regulator_get(&spi->dev, "vcc");
--
2.7.3
^ permalink raw reply related
* [PATCH v7 5/9] DT:omap3+tsc2007: use new common touchscreen bindings
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
While we fix the GTA04 we add proper pinmux for the
penirq gpio.
Tested on: GTA04A4 and Pyra-Handheld
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4) /* gpio112 */
>;
};
+
+ penirq_pins: pinmux_penirq_pins {
+ pinctrl-single,pins = <
+ /* here we could enable to wakeup the cpu from suspend by a pen touch */
+ OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4) /* gpio160 */
+ >;
+ };
};
&omap3_pmx_core2 {
@@ -410,10 +417,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&penirq_pins>;
interrupt-parent = <&gpio6>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
- gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
- ti,x-plate-ohms = <600>;
+ gpios = <&gpio6 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <640>;
+ touchscreen-max-pressure = <1000>;
+ touchscreen-fuzz-x = <3>;
+ touchscreen-fuzz-y = <8>;
+ 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>;
};
/* RFID EEPROM */
--
2.7.3
^ permalink raw reply related
* [PATCH v7 4/9] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
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 extension provides an iio interface for these adc channels.
Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.
This patch also splits the tsc2007 driver in several source files:
tsc2007.h -- constants, structs and stubs
tsc2007_core.c -- functional parts of the original driver
tsc2007_iio.c -- the optional iio stuff
Makefile magic allows to conditionally link the iio
stuff if CONFIG_IIO=y in a way that it works with
CONFIG_TOUCHSCREEN_TSC2007=m.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/input/touchscreen/Makefile | 2 +
drivers/input/touchscreen/tsc2007.h | 118 ++++++++++++++++
.../touchscreen/{tsc2007.c => tsc2007_core.c} | 119 ++++++----------
drivers/input/touchscreen/tsc2007_iio.c | 152 +++++++++++++++++++++
4 files changed, 310 insertions(+), 81 deletions(-)
create mode 100644 drivers/input/touchscreen/tsc2007.h
rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (85%)
create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 81b8645..d932e2d 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO) += tsc40.o
obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
obj-$(CONFIG_TOUCHSCREEN_TSC2004) += tsc2004.o
obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o
+tsc2007-y := tsc2007_core.o
+tsc2007-$(CONFIG_IIO) += tsc2007_iio.o
obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o
obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o
diff --git a/drivers/input/touchscreen/tsc2007.h b/drivers/input/touchscreen/tsc2007.h
new file mode 100644
index 0000000..5049bf8
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007.h
@@ -0,0 +1,118 @@
+/*
+ * drivers/input/touchscreen/tsc2007.h
+ *
+ * Copyright (c) 2008 MtekVision Co., Ltd.
+ * Kwangwoo Lee <kwlee@mtekvision.com>
+ *
+ * Using code from:
+ * - ads7846.c
+ * Copyright (c) 2005 David Brownell
+ * Copyright (c) 2006 Nokia Corporation
+ * - corgi_ts.c
+ * Copyright (C) 2004-2005 Richard Purdie
+ * - omap_ts.[hc], ads7846.h, ts_osk.c
+ * Copyright (C) 2002 MontaVista Software
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2005 Dirk Behme
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/input/touchscreen.h>
+
+#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
+#define TSC2007_MEASURE_AUX (0x2 << 4)
+#define TSC2007_MEASURE_TEMP1 (0x4 << 4)
+#define TSC2007_ACTIVATE_XN (0x8 << 4)
+#define TSC2007_ACTIVATE_YN (0x9 << 4)
+#define TSC2007_ACTIVATE_YP_XN (0xa << 4)
+#define TSC2007_SETUP (0xb << 4)
+#define TSC2007_MEASURE_X (0xc << 4)
+#define TSC2007_MEASURE_Y (0xd << 4)
+#define TSC2007_MEASURE_Z1 (0xe << 4)
+#define TSC2007_MEASURE_Z2 (0xf << 4)
+
+#define TSC2007_POWER_OFF_IRQ_EN (0x0 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS0 (0x1 << 2)
+#define TSC2007_ADC_OFF_IRQ_EN (0x2 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS1 (0x3 << 2)
+
+#define TSC2007_12BIT (0x0 << 1)
+#define TSC2007_8BIT (0x1 << 1)
+
+#define MAX_12BIT ((1 << 12) - 1)
+
+#define ADC_ON_12BIT (TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
+
+#define READ_Y (ADC_ON_12BIT | TSC2007_MEASURE_Y)
+#define READ_Z1 (ADC_ON_12BIT | TSC2007_MEASURE_Z1)
+#define READ_Z2 (ADC_ON_12BIT | TSC2007_MEASURE_Z2)
+#define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
+#define PWRDOWN (TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
+
+struct ts_event {
+ u16 x;
+ u16 y;
+ u16 z1, z2;
+};
+
+struct tsc2007 {
+ struct input_dev *input;
+ char phys[32];
+
+ struct i2c_client *client;
+
+ u16 model;
+ u16 x_plate_ohms;
+
+ struct touchscreen_properties prop;
+
+ bool report_resistance;
+ u16 min_x;
+ u16 min_y;
+ u16 max_x;
+ u16 max_y;
+ u16 max_rt;
+ unsigned long poll_period; /* in jiffies */
+ int fuzzx;
+ int fuzzy;
+ int fuzzz;
+
+ unsigned int gpio;
+ int irq;
+
+ wait_queue_head_t wait;
+ bool stopped;
+ bool pendown;
+
+ int (*get_pendown_state)(struct device *);
+ void (*clear_penirq)(void);
+
+ struct mutex mlock;
+ struct iio_dev *iio_dev; /* optional */
+};
+
+int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd);
+u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+ struct ts_event *tc);
+bool tsc2007_is_pen_down(struct tsc2007 *ts);
+
+#ifdef CONFIG_IIO
+
+/* defined in tsc2007_iio.c */
+int tsc2007_iio_configure(struct tsc2007 *ts);
+void tsc2007_iio_unconfigure(struct tsc2007 *ts);
+
+#else /* CONFIG_IIO */
+
+static inline int tsc2007_iio_configure(struct tsc2007 *ts)
+{
+ return 0;
+}
+static inline void tsc2007_iio_unconfigure(struct tsc2007 *ts)
+{
+}
+
+#endif /* CONFIG_IIO */
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007_core.c
similarity index 85%
rename from drivers/input/touchscreen/tsc2007.c
rename to drivers/input/touchscreen/tsc2007_core.c
index 5e3c4bf..72775ae 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -27,80 +27,10 @@
#include <linux/i2c.h>
#include <linux/i2c/tsc2007.h>
#include <linux/of_device.h>
-#include <linux/of.h>
#include <linux/of_gpio.h>
-#include <linux/input/touchscreen.h>
-
-#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
-#define TSC2007_MEASURE_AUX (0x2 << 4)
-#define TSC2007_MEASURE_TEMP1 (0x4 << 4)
-#define TSC2007_ACTIVATE_XN (0x8 << 4)
-#define TSC2007_ACTIVATE_YN (0x9 << 4)
-#define TSC2007_ACTIVATE_YP_XN (0xa << 4)
-#define TSC2007_SETUP (0xb << 4)
-#define TSC2007_MEASURE_X (0xc << 4)
-#define TSC2007_MEASURE_Y (0xd << 4)
-#define TSC2007_MEASURE_Z1 (0xe << 4)
-#define TSC2007_MEASURE_Z2 (0xf << 4)
-
-#define TSC2007_POWER_OFF_IRQ_EN (0x0 << 2)
-#define TSC2007_ADC_ON_IRQ_DIS0 (0x1 << 2)
-#define TSC2007_ADC_OFF_IRQ_EN (0x2 << 2)
-#define TSC2007_ADC_ON_IRQ_DIS1 (0x3 << 2)
-
-#define TSC2007_12BIT (0x0 << 1)
-#define TSC2007_8BIT (0x1 << 1)
-
-#define MAX_12BIT ((1 << 12) - 1)
-
-#define ADC_ON_12BIT (TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
-
-#define READ_Y (ADC_ON_12BIT | TSC2007_MEASURE_Y)
-#define READ_Z1 (ADC_ON_12BIT | TSC2007_MEASURE_Z1)
-#define READ_Z2 (ADC_ON_12BIT | TSC2007_MEASURE_Z2)
-#define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
-#define PWRDOWN (TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
-
-struct ts_event {
- u16 x;
- u16 y;
- u16 z1, z2;
-};
-
-struct tsc2007 {
- struct input_dev *input;
- char phys[32];
-
- struct i2c_client *client;
-
- u16 model;
- u16 x_plate_ohms;
-
- struct touchscreen_properties prop;
-
- bool report_resistance;
- u16 min_x;
- u16 min_y;
- u16 max_x;
- u16 max_y;
- u16 max_rt;
- unsigned long poll_period; /* in jiffies */
- int fuzzx;
- int fuzzy;
- int fuzzz;
+#include "tsc2007.h"
- unsigned gpio;
- int irq;
-
- wait_queue_head_t wait;
- bool stopped;
- bool pendown;
-
- int (*get_pendown_state)(struct device *);
- void (*clear_penirq)(void);
-};
-
-static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
+int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
{
s32 data;
u16 val;
@@ -121,6 +51,7 @@ static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
return val;
}
+EXPORT_SYMBOL(tsc2007_xfer);
static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
{
@@ -138,7 +69,7 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
}
-static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
struct ts_event *tc)
{
u32 rt = 0;
@@ -158,8 +89,9 @@ static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
return rt;
}
+EXPORT_SYMBOL(tsc2007_calculate_resistance);
-static bool tsc2007_is_pen_down(struct tsc2007 *ts)
+bool tsc2007_is_pen_down(struct tsc2007 *ts)
{
/*
* NOTE: We can't rely on the pressure to determine the pen down
@@ -180,6 +112,7 @@ static bool tsc2007_is_pen_down(struct tsc2007 *ts)
return ts->get_pendown_state(&ts->client->dev);
}
+EXPORT_SYMBOL(tsc2007_is_pen_down);
static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
{
@@ -192,7 +125,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(&ts->mlock);
tsc2007_read_values(ts, &tc);
+ mutex_unlock(&ts->mlock);
rt = tsc2007_calculate_resistance(ts, &tc);
@@ -450,7 +386,8 @@ static void tsc2007_call_exit_platform_hw(void *data)
static int tsc2007_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- const struct tsc2007_platform_data *pdata = dev_get_platdata(&client->dev);
+ const struct tsc2007_platform_data *pdata =
+ dev_get_platdata(&client->dev);
struct tsc2007 *ts;
struct input_dev *input_dev;
int err;
@@ -472,7 +409,13 @@ static int tsc2007_probe(struct i2c_client *client,
ts->client = client;
ts->irq = client->irq;
ts->input = input_dev;
+
+ err = tsc2007_iio_configure(ts);
+ if (err < 0)
+ return err;
+
init_waitqueue_head(&ts->wait);
+ mutex_init(&ts->mlock);
snprintf(ts->phys, sizeof(ts->phys),
"%s/input0", dev_name(&client->dev));
@@ -494,7 +437,7 @@ static int tsc2007_probe(struct i2c_client *client,
if (pdata) {
err = tsc2007_probe_pdev(client, ts, pdata, id);
if (err)
- return err;
+ goto probe_err;
input_set_abs_params(input_dev, ABS_X, 0, ts->max_x-ts->min_x,
ts->fuzzx, 0);
input_set_abs_params(input_dev, ABS_Y, 0, ts->max_y-ts->min_y,
@@ -504,7 +447,7 @@ static int tsc2007_probe(struct i2c_client *client,
} else {
err = tsc2007_probe_dt(client, ts);
if (err)
- return err;
+ goto probe_err;
}
if (pdata) {
@@ -516,7 +459,7 @@ static int tsc2007_probe(struct i2c_client *client,
dev_err(&client->dev,
"Failed to register exit_platform_hw action, %d\n",
err);
- return err;
+ goto probe_err;
}
}
@@ -533,7 +476,7 @@ static int tsc2007_probe(struct i2c_client *client,
if (err) {
dev_err(&client->dev, "Failed to request irq %d: %d\n",
ts->irq, err);
- return err;
+ goto probe_err;
}
tsc2007_stop(ts);
@@ -543,17 +486,30 @@ static int tsc2007_probe(struct i2c_client *client,
if (err < 0) {
dev_err(&client->dev,
"Failed to setup chip: %d\n", err);
- return err; /* usually, chip does not respond */
+ goto probe_err; /* chip does not respond */
}
err = input_register_device(input_dev);
if (err) {
dev_err(&client->dev,
"Failed to register input device: %d\n", err);
- return err;
+ goto probe_err;
}
return 0;
+
+probe_err:
+ tsc2007_iio_unconfigure(ts);
+ return err;
+}
+
+static int tsc2007_remove(struct i2c_client *client)
+{
+ struct tsc2007 *ts = i2c_get_clientdata(client);
+
+ tsc2007_iio_unconfigure(ts);
+ input_unregister_device(ts->input);
+ return 0;
}
static const struct i2c_device_id tsc2007_idtable[] = {
@@ -578,6 +534,7 @@ static struct i2c_driver tsc2007_driver = {
},
.id_table = tsc2007_idtable,
.probe = tsc2007_probe,
+ .remove = tsc2007_remove,
};
module_i2c_driver(tsc2007_driver);
diff --git a/drivers/input/touchscreen/tsc2007_iio.c b/drivers/input/touchscreen/tsc2007_iio.c
new file mode 100644
index 0000000..e492bba
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007_iio.c
@@ -0,0 +1,152 @@
+/*
+ * drivers/input/touchscreen/tsc2007_iio.c
+ *
+ * Copyright (c) 2016 Golden Delicious Comp. GmbH&Co. KG
+ * Nikolaus Schaller <hns@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.
+ */
+
+#include <linux/i2c.h>
+#include <linux/iio/iio.h>
+#include "tsc2007.h"
+
+struct tsc2007_iio {
+ struct tsc2007 *ts;
+};
+
+#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, \
+}
+
+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_iio *iio = iio_priv(indio_dev);
+ struct tsc2007 *tsc = iio->ts;
+ 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(&tsc->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, &tc);
+ 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_unlock(&tsc->mlock);
+
+ ret = IIO_VAL_INT;
+
+ return ret;
+}
+
+static const struct iio_info tsc2007_iio_info = {
+ .read_raw = tsc2007_read_raw,
+ .driver_module = THIS_MODULE,
+};
+
+int tsc2007_iio_configure(struct tsc2007 *ts)
+{
+ int err;
+ struct iio_dev *indio_dev;
+ struct tsc2007_iio *iio;
+
+ indio_dev = devm_iio_device_alloc(&ts->client->dev,
+ sizeof(struct tsc2007_iio));
+ if (!indio_dev) {
+ dev_err(&ts->client->dev, "iio_device_alloc failed\n");
+ return -ENOMEM;
+ }
+
+ iio = iio_priv(indio_dev);
+ iio->ts = ts;
+ ts->iio_dev = (void *) indio_dev;
+
+ indio_dev->name = "tsc2007";
+ indio_dev->dev.parent = &ts->client->dev;
+ indio_dev->info = &tsc2007_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = tsc2007_iio_channel;
+ indio_dev->num_channels = ARRAY_SIZE(tsc2007_iio_channel);
+
+ err = iio_device_register(indio_dev);
+ if (err < 0) {
+ dev_err(&ts->client->dev, "iio_device_register() failed: %d\n",
+ err);
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(tsc2007_iio_configure);
+
+void tsc2007_iio_unconfigure(struct tsc2007 *ts)
+{
+ struct iio_dev *indio_dev = ts->iio_dev;
+
+ iio_device_unregister(indio_dev);
+}
+EXPORT_SYMBOL(tsc2007_iio_unconfigure);
--
2.7.3
^ permalink raw reply related
* [PATCH v7 3/9] drivers:input:tsc2007: check for presence and power down tsc2007 during probe
From: H. Nikolaus Schaller @ 2016-11-11 19:02 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed
Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
---
drivers/input/touchscreen/tsc2007.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index e9d5086..5e3c4bf 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -538,6 +538,14 @@ static int tsc2007_probe(struct i2c_client *client,
tsc2007_stop(ts);
+ /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+ err = tsc2007_xfer(ts, PWRDOWN);
+ if (err < 0) {
+ dev_err(&client->dev,
+ "Failed to setup chip: %d\n", err);
+ return err; /* usually, chip does not respond */
+ }
+
err = input_register_device(input_dev);
if (err) {
dev_err(&client->dev,
--
2.7.3
^ permalink raw reply related
* [PATCH v7 2/9] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does
From: H. Nikolaus Schaller @ 2016-11-11 19:01 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
this should reduce unnecessary input events.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/input/touchscreen/tsc2007.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index c1d9593..e9d5086 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
wait_queue_head_t wait;
bool stopped;
+ bool pendown;
int (*get_pendown_state)(struct device *);
void (*clear_penirq)(void);
@@ -227,7 +228,11 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
sx, sy, rt);
/* report event */
- input_report_key(input, BTN_TOUCH, 1);
+ if (!ts->pendown) {
+ input_report_key(input, BTN_TOUCH, 1);
+ ts->pendown = true;
+ }
+
touchscreen_report_pos(ts->input, &ts->prop,
(unsigned int) sx,
(unsigned int) sy,
@@ -250,9 +255,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
dev_dbg(&ts->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.7.3
^ permalink raw reply related
* [PATCH v7 1/9] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
From: H. Nikolaus Schaller @ 2016-11-11 19:01 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel, H. Nikolaus Schaller
In-Reply-To: <cover.1478890925.git.hns@goldelico.com>
commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.
commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.
Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.
A new feature is to introduce scaling the min/max ADC values to the screen
size.
This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.
Please note that the old ti,fuzz properties have been removed since they
are replaced by the common bindings touchscreen-fuzz-x/y/z.
Finally, 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 <hns@goldelico.com>
---
.../bindings/input/touchscreen/tsc2007.txt | 20 ++--
drivers/input/touchscreen/tsc2007.c | 120 +++++++++++++++++----
include/linux/i2c/tsc2007.h | 8 ++
3 files changed, 118 insertions(+), 30 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:
&i2c1 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = <&gpio4 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..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
#include <linux/of_device.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
+#include <linux/input/touchscreen.h>
#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
#define TSC2007_MEASURE_AUX (0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
u16 model;
u16 x_plate_ohms;
+
+ struct touchscreen_properties prop;
+
+ bool report_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(&ts->client->dev, "soft irq %d\n", irq);
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
/* pen is down, continue with the measurement */
tsc2007_read_values(ts, &tc);
- rt = tsc2007_calculate_pressure(ts, &tc);
+ rt = tsc2007_calculate_resistance(ts, &tc);
if (!rt && !ts->get_pendown_state) {
/*
@@ -194,21 +205,41 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
}
if (rt <= ts->max_rt) {
+ int sx, sy;
+
dev_dbg(&ts->client->dev,
"DOWN point(%4d,%4d), pressure (%4u)\n",
tc.x, tc.y, rt);
+ if (!ts->report_resistance)
+ rt = ts->max_rt - rt;
+
+ /* scale ADC values to desired output range */
+ sx = (ts->prop.max_x * (tc.x - ts->min_x))
+ / (ts->max_x - ts->min_x);
+ sy = (ts->prop.max_y * (tc.y - ts->min_y))
+ / (ts->max_y - ts->min_y);
+ rt = (input->absinfo[ABS_PRESSURE].maximum * rt) /
+ ts->max_rt;
+
+ dev_dbg(&ts->client->dev,
+ "Scaled point(%4d,%4d), pressure (%4u)\n",
+ sx, sy, rt);
+
+ /* report event */
input_report_key(input, BTN_TOUCH, 1);
- input_report_abs(input, ABS_X, tc.x);
- input_report_abs(input, ABS_Y, tc.y);
+ touchscreen_report_pos(ts->input, &ts->prop,
+ (unsigned int) sx,
+ (unsigned int) sy,
+ false);
input_report_abs(input, ABS_PRESSURE, rt);
input_sync(input);
} else {
/*
- * Sample found inconsistent by debouncing or pressure is
- * beyond the maximum. Don't report it to user space,
+ * Sample found inconsistent by debouncing or resistance
+ * is beyond the maximum. Don't report it to user space,
* repeat at least once more the measurement.
*/
dev_dbg(&ts->client->dev, "ignored pressure %d\n", rt);
@@ -233,6 +264,7 @@ static irqreturn_t tsc2007_hard_irq(int irq, void *handle)
{
struct tsc2007 *ts = handle;
+ dev_dbg(&ts->client->dev, "hard irq %d\n", irq);
if (tsc2007_is_pen_down(ts))
return IRQ_WAKE_THREAD;
@@ -303,14 +335,24 @@ static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts)
else
ts->max_rt = MAX_12BIT;
- if (!of_property_read_u32(np, "ti,fuzzx", &val32))
- ts->fuzzx = val32;
+ ts->report_resistance =
+ of_property_read_bool(np, "ti,report-resistance");
- if (!of_property_read_u32(np, "ti,fuzzy", &val32))
- ts->fuzzy = val32;
+ touchscreen_parse_properties(ts->input, false, &ts->prop);
- if (!of_property_read_u32(np, "ti,fuzzz", &val32))
- ts->fuzzz = val32;
+ if (!of_property_read_u32(np, "ti,min-x", &val32))
+ ts->min_x = val32;
+ if (!of_property_read_u32(np, "ti,max-x", &val32))
+ ts->max_x = val32;
+ else
+ ts->max_x = MAX_12BIT;
+
+ if (!of_property_read_u32(np, "ti,min-y", &val32))
+ ts->min_y = val32;
+ if (!of_property_read_u32(np, "ti,max-y", &val32))
+ ts->max_y = val32;
+ else
+ ts->max_y = MAX_12BIT;
if (!of_property_read_u64(np, "ti,poll-period", &val64))
ts->poll_period = msecs_to_jiffies(val64);
@@ -332,6 +374,22 @@ static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts)
"GPIO not specified in DT (of_get_gpio returned %d)\n",
ts->gpio);
+ dev_dbg(&client->dev,
+ "min/max_x (%4d,%4d)\n",
+ ts->min_x, ts->max_x);
+ dev_dbg(&client->dev,
+ "min/max_y (%4d,%4d)\n",
+ ts->min_y, ts->max_y);
+ dev_dbg(&client->dev,
+ "max_rt (%4d)\n",
+ ts->max_rt);
+ dev_dbg(&client->dev,
+ "size (%4d,%4d)\n",
+ ts->prop.max_x, ts->prop.max_y);
+ dev_dbg(&client->dev,
+ "ts-gpio: %d\n",
+ ts->gpio);
+
return 0;
}
#else
@@ -349,6 +407,14 @@ static int tsc2007_probe_pdev(struct i2c_client *client, struct tsc2007 *ts,
ts->model = pdata->model;
ts->x_plate_ohms = pdata->x_plate_ohms;
ts->max_rt = pdata->max_rt ? : MAX_12BIT;
+ ts->prop.swap_x_y = pdata->swap_xy;
+ ts->prop.invert_x = pdata->invert_x;
+ ts->prop.invert_y = pdata->invert_y;
+ ts->report_resistance = pdata->report_resistance;
+ ts->min_x = pdata->min_x ? : 0;
+ ts->min_y = pdata->min_y ? : 0;
+ ts->max_x = pdata->max_x ? : MAX_12BIT;
+ ts->max_y = pdata->max_y ? : MAX_12BIT;
ts->poll_period = msecs_to_jiffies(pdata->poll_period ? : 1);
ts->get_pendown_state = pdata->get_pendown_state;
ts->clear_penirq = pdata->clear_penirq;
@@ -388,13 +454,6 @@ static int tsc2007_probe(struct i2c_client *client,
if (!ts)
return -ENOMEM;
- if (pdata)
- err = tsc2007_probe_pdev(client, ts, pdata, id);
- else
- err = tsc2007_probe_dt(client, ts);
- if (err)
- return err;
-
input_dev = devm_input_allocate_device(&client->dev);
if (!input_dev)
return -ENOMEM;
@@ -419,12 +478,25 @@ static int tsc2007_probe(struct i2c_client *client,
input_set_drvdata(input_dev, ts);
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+ input_dev->absbit[0] = BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) |
+ BIT_MASK(ABS_PRESSURE);
input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
- input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0);
- input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
- input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_12BIT,
- ts->fuzzz, 0);
+ if (pdata) {
+ err = tsc2007_probe_pdev(client, ts, pdata, id);
+ if (err)
+ return err;
+ input_set_abs_params(input_dev, ABS_X, 0, ts->max_x-ts->min_x,
+ ts->fuzzx, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0, ts->max_y-ts->min_y,
+ ts->fuzzy, 0);
+ input_set_abs_params(input_dev, ABS_PRESSURE, 0, ts->max_rt,
+ ts->fuzzz, 0);
+ } else {
+ err = tsc2007_probe_dt(client, ts);
+ if (err)
+ return err;
+ }
if (pdata) {
if (pdata->exit_platform_hw) {
@@ -443,6 +515,8 @@ static int tsc2007_probe(struct i2c_client *client,
pdata->init_platform_hw();
}
+ dev_dbg(&client->dev, "request irq %d\n",
+ ts->irq);
err = devm_request_threaded_irq(&client->dev, ts->irq,
tsc2007_hard_irq, tsc2007_soft_irq,
IRQF_ONESHOT,
diff --git a/include/linux/i2c/tsc2007.h b/include/linux/i2c/tsc2007.h
index 4f35b6a..632db20 100644
--- a/include/linux/i2c/tsc2007.h
+++ b/include/linux/i2c/tsc2007.h
@@ -6,6 +6,14 @@
struct tsc2007_platform_data {
u16 model; /* 2007. */
u16 x_plate_ohms; /* must be non-zero value */
+ bool swap_xy; /* swap x and y axis */
+ bool invert_x;
+ bool invert_y;
+ bool report_resistance;
+ u16 min_x; /* min and max values reported by ADC */
+ u16 min_y;
+ u16 max_x;
+ u16 max_y;
u16 max_rt; /* max. resistance above which samples are ignored */
unsigned long poll_period; /* time (in ms) between samples */
int fuzzx; /* fuzz factor for X, Y and pressure axes */
--
2.7.3
^ permalink raw reply related
* [PATCH v7 0/9] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)
From: H. Nikolaus Schaller @ 2016-11-11 19:01 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf, H. Nikolaus Schaller
Changes V7:
* rearranged the include files (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* forward reference struct iio_dev * instead of condition in tsc2007.h (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* add some Acked-by:
2016-10-27 10:44:29: Changes V6:
* iio patch (no changes elsewhere)
- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid test robot)
- tsc2007_core: group error return paths so that tsc2007_iio_unconfigure is called at only one place
- tsc2007_iio: fix copyright (this file is 100% original work)
2016-10-25 21:26:46: Changes V5:
* ads7846: remove an empty line (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
* ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>)
* tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuild test robot)
* refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
2016-10-17 16:00:02: Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* make the iio extension depend on CONFIG_IIO rather than selecting it (suggested by Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>)
* swapped patch 3/n and patch 4/n to remove internal dependency
2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
2015-11-13 21:36:07: 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 ("Input: add common DT binding for touchscreens"):
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 (9):
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: check for presence and power down tsc2007
during probe
drivers:input:tsc2007: add iio interface to read external ADC input
and temperature
DT:omap3+tsc2007: use new common touchscreen bindings
drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
drivers:input:ads7846(+tsc2046): fix spi module table
DT:omap3+ads7846: use new common touchscreen bindings
.../bindings/input/{ => touchscreen}/ads7846.txt | 9 +-
.../bindings/input/touchscreen/tsc2007.txt | 20 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 25 ++-
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 | 3 +-
drivers/input/touchscreen/Makefile | 2 +
drivers/input/touchscreen/ads7846.c | 71 +++++--
drivers/input/touchscreen/tsc2007.h | 118 +++++++++++
.../touchscreen/{tsc2007.c => tsc2007_core.c} | 236 +++++++++++++--------
drivers/input/touchscreen/tsc2007_iio.c | 152 +++++++++++++
include/linux/i2c/tsc2007.h | 8 +
12 files changed, 541 insertions(+), 122 deletions(-)
rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (90%)
create mode 100644 drivers/input/touchscreen/tsc2007.h
rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (70%)
create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
From: H. Nikolaus Schaller @ 2016-11-11 19:01 UTC (permalink / raw)
To: Rob Herring
Cc: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap,
Discussions about the Letux Kernel, linux-iio@vger.kernel.org,
kernel
In-Reply-To: <CAL_JsqLhBwb4eJdrAqLLksovcfP1xm9RGTUQKVvF_WxJaMn4WA@mail.gmail.com>
Hi Rob,
finally I found time to catch up. Sorry for the delay.
> Am 31.10.2016 um 04:39 schrieb Rob Herring <robh+dt@kernel.org>:
>
> On Tue, Oct 18, 2016 at 12:27 PM, H. Nikolaus Schaller
> <hns@goldelico.com> wrote:
>> Hi Rob,
>>
>>> Am 18.10.2016 um 18:22 schrieb Rob Herring <robh+dt@kernel.org>:
>>>
>>> On Mon, Oct 17, 2016 at 8:57 AM, H. Nikolaus Schaller <hns@goldelico.com> 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.
>>>>
>>>> commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / swapped axes")
>>>> added another helper for parsing axis inversion and swapping
>>>> and applying them to x and y coordinates.
>>>>
>>>> Both helpers have been integrated to accommodate any orientation of the
>>>> touch panel in relation to the LCD.
>>>
>>> Please add the explanation of why this is a compatible change here.
>>
>> Can you please describe in more detail what you are missing here?
>
> You stop handling ti,fuzzx for example. So the default driver value
> will be used and this is okay because...
Ok, now I see. Thanks!
>
> Seems like you would have a regression in behavior if the fuzz values
> specified in an existing DT are ignored.
Well, is there any existing DT using this ti,fuzz property for a tsc2007?
I did not find any use of it in arch/arm/boot/dts.
Since we mainly want to fix arch/arm/boot/dts/omap3-gta04.dts we do not
want to introduce the old ti,fuzzx any more. Rather we want to use the
new "touchscreen-fuzz-x".
Therefore, I thought that it is safe to remove them - and forgot to
mention that anywhere.
If someone shows a device where the ti,fuzz is still used, we can still
add code to override what has been parsed by the common bindings. Or he/she
can change the DT of the device.
>
>> The patch simply makes use of the generic helper function introduced by the
>> two patches cited above and is therefore automatically compatible if none of
>> the new properties is defined.
>>
>> The tsc2007 didn't have these features before. So what should we say
>> about compatibility?
>
> It certainly had the fuzz features before.
>
>
>>>> -- 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.
I have now added a note in the commit message that the ti,fuzz properties are
removed as well by this patch.
>>>> +- 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).
>>>
>>> I thought these were going to be common? I think they should be.
>>
>> Yes, we had discussed that before.
>>
>> In a second thought, I found that they are not even existing for the different
>> touch chip drivers that are around. And some chip might not need them (because
>> e.g. min/max are constants or defined my means outside the DT or the chip itself
>> can store them in NV memory).
>>
>> And, since they define ADC raw-values, they are very closely related to the
>> individual chip, so that I am not sure if it is really necessary to make
>> them common. At least if they are properly documented in the bindings for
>> the specific chip they can have different names without disturbing each
>> other.
>
> They wouldn't disturb each other, but then there is no chance to have
> common parsing either.
What do we need common parsing for these, if they are really specific to the
combination of some touch and exactly this chip?
This is different from specifying a touch dimension or fuzz value in pixels.
Those are passed to the input layer and must be common. But these here are
not and it is the purpose of the driver to hide them from user space (unless
they are used as "reasonable" defaults because DT isn't complete or not up
to date).
>
>> So I think it is perfectly reasonable to define common bindings towards
>> the input event layer (e.g. size, fuzz, swapping, inversion) and support
>> them by common code which bakes raw coordinates into input events. The latest
>> helper functions already do most of that fully automatic.
>
> I could argue that size in pixels has no business being in DT.
The touchscreen common bindings define the units as "size in pixels".
> That's a property of the panel the touchscreen is glued to. I guess in some
> cases, the controller is internally scaling the ADC values.
Yes and that scaling is what the tsc2007 driver is doing here because the
controller doesn't internally like for e.g. USB connected touch screens.
>
>> Next, I had simply copied them from the ads7846 driver where they
>> exist for a long time. So this is sort of "common", at least for two different
>> chips now. See also patch 6/8 of this series which adds the common properties
>> to the ads7846 as well.
>>
>> For more reference about the existing bindings:
>>
>> Documentation/devicetree/bindings/input/ads7846.txt
>>
>> (btw I think someone should move them to bindings/input/touchscreen).
>
> Patches welcome.
I have added a patch to [PATCH v7].
>
>> It appears as if there is some overlap of the new generic properties (for x/y
>> swapping) with the old ads7846 properties, but that is something you had
>> already proposed a while ago to make me the driver recognize both properties to
>> stay compatible with older DT files.
>>
>> So if we now rename the min/max-x/y properties for the tsc2007 we have to rename
>> them for the ads7846 (and maybe others) as well, which might break out-of-tree
>> ads7846 devices or leads to more complex code for handling of property aliases.
>
> We don't have to rename them for ads7846. That's already baked.
And the longer I think about it, the more I think it is well baked as it is.
> But there's a trend here.
Which trend do you see?
IMHO these adc-min/max properties are very chip specific and there have not been
many new resistive touch controllers announced recently. So I do not see anything
which could become a trend.
> You're defining the same property. Use a common
> name, so when the 3rd binding comes along needing the same thing, we
> already have a common binding.
Why not take the already existing 1st binding of the ads7846 and let the tsc2007
come along as the 2nd one which needs the same thing?
Then we have a common binding between these two now and don't need to wait for
a 3rd one to come (in some uncertain future).
Therefore, I have not yet touched code or description in this area because I don't
know how to do it really better than proposed in [PATCH v4].
[Patch v7] for the whole series will come right after this mail.
BR and thanks,
Nikolaus
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau @ 2016-11-11 18:16 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: mark.rutland@arm.com, benh@kernel.crashing.org,
catalin.marinas@arm.com, will.deacon@arm.com, Linuxarm,
lorenzo.pieralisi@arm.com, Arnd Bergmann, xuwei (O),
linux-serial@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, minyard@acm.org, John Garry,
zourongrong@gmail.com, robh+dt@kernel.org, bhelgaas@googl e.com,
kantyzc@163.com, zhichang.yuan02@gmail.com, linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8F9909@lhreml507-mbx>
On Fri, Nov 11, 2016 at 03:53:53PM +0000, Gabriele Paoloni wrote:
> Hi Liviu
Hi Gabriele,
>
> > -----Original Message-----
> > From: liviu.dudau@arm.com [mailto:liviu.dudau@arm.com]
> > Sent: 11 November 2016 14:46
> > To: Gabriele Paoloni
> > Cc: Arnd Bergmann; linux-arm-kernel@lists.infradead.org; Yuanzhichang;
> > mark.rutland@arm.com; devicetree@vger.kernel.org;
> > lorenzo.pieralisi@arm.com; minyard@acm.org; linux-pci@vger.kernel.org;
> > benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
> > kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
> > robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
> > catalin.marinas@arm.com; olof@lixom.net; bhelgaas@googl e.com;
> > zhichang.yuan02@gmail.com
> > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > Hip06
> >
> > On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> > > Hi Arnd
> > >
> > > > -----Original Message-----
> > > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > Sent: 10 November 2016 16:07
> > > > To: Gabriele Paoloni
> > > > Cc: linux-arm-kernel@lists.infradead.org; Yuanzhichang;
> > > > mark.rutland@arm.com; devicetree@vger.kernel.org;
> > > > lorenzo.pieralisi@arm.com; minyard@acm.org; linux-
> > pci@vger.kernel.org;
> > > > benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
> > > > kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
> > > > robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
> > > > catalin.marinas@arm.com; olof@lixom.net; liviu.dudau@arm.com;
> > > > bhelgaas@googl e.com; zhichang.yuan02@gmail.com
> > > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > > > Hip06
> > > >
> > > > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni
> > wrote:
> > > > >
> > > > > Where should we get the range from? For LPC we know that it is
> > going
> > > > > Work on anything that is not used by PCI I/O space, and this is
> > > > > why we use [0, PCIBIOS_MIN_IO]
> > > >
> > > > It should be allocated the same way we allocate PCI config space
> > > > segments. This is currently done with the io_range list in
> > > > drivers/pci/pci.c, which isn't perfect but could be extended
> > > > if necessary. Based on what others commented here, I'd rather
> > > > make the differences between ISA/LPC and PCI I/O ranges smaller
> > > > than larger.
> >
> > Gabriele,
> >
> > >
> > > I am not sure this would make sense...
> > >
> > > IMHO all the mechanism around io_range_list is needed to provide the
> > > "mapping" between I/O tokens and physical CPU addresses.
> > >
> > > Currently the available tokens range from 0 to IO_SPACE_LIMIT.
> > >
> > > As you know the I/O memory accessors operate on whatever
> > > __of_address_to_resource sets into the resource (start, end).
> > >
> > > With this special device in place we cannot know if a resource is
> > > assigned with an I/O token or a physical address, unless we forbid
> > > the I/O tokens to be in a specific range.
> > >
> > > So this is why we are changing the offsets of all the functions
> > > handling io_range_list (to make sure that a range is forbidden to
> > > the tokens and is available to the physical addresses).
> > >
> > > We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> > > because this is the maximum physical I/O range that a non PCI device
> > > can operate on and because we believe this does not impose much
> > > restriction on the available I/O token range; that now is
> > > [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> > > So we believe that the chosen forbidden range can accommodate
> > > any special ISA bus device with no much constraint on the rest
> > > of I/O tokens...
> >
> > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> > actually need another variable for "reserving" an area in the I/O space
> > that can be used for physical addresses rather than I/O tokens.
> >
> > The one good example for using PCIBIOS_MIN_IO is when your
> > platform/architecture
> > does not support legacy ISA operations *at all*. In that case someone
> > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> > so that it doesn't get used. With Zhichang's patch you now start
> > forcing
> > those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be used
> by PCI controllers only...
Nope, that is not what it means. It means that PCI devices can see I/O addresses
on the bus that start from 0. There never was any usage for non-PCI controllers
when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and what
I think is not the right thing (and not enough anyway).
> so if you have a special bus device using
> an I/O range in this case should be a PCI controller...
That has always been the case. It is this series that wants to introduce the
new meaning.
> i.e. I would
> expect it to fall back into the case of I/O tokens redirection rather than
> physical addresses redirection (as mentioned below from my previous reply).
> What do you think?
I think you have looked too much at the code *with* Zhichang's patches applied.
Take a step back and look at how PCIBIOS_MIN_IO is used now, before you apply
the patches. It is all about PCI addresses and there is no notion of non-PCI
busses using PCI framework. Only platforms and architectures that try to work
around some legacy standards (ISA) or HW restrictions.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
>
> >
> > For the general case you also have to bear in mind that PCIBIOS_MIN_IO
> > could
> > be zero. In that case, what is your "forbidden" range? [0, 0) ? So it
> > makes
> > sense to add a new #define that should only be defined by those
> > architectures/
> > platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> > where I/O tokens can't be generated for.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > >
> > > > > > Your current version has
> > > > > >
> > > > > > if (arm64_extio_ops->pfout)
> > \
> > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > >devpara,\
> > > > > > addr, value, sizeof(type));
> > \
> > > > > >
> > > > > > Instead, just subtract the start of the range from the logical
> > > > > > port number to transform it back into a bus-local port number:
> > > > >
> > > > > These accessors do not operate on IO tokens:
> > > > >
> > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> > > > > addr is not going to be an I/O token; in fact patch 2/3 imposes
> > that
> > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > PCIBIOS_MIN_IO
> > > > > we have free physical addresses that the accessors can operate
> > on.
> > > >
> > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer
> > to
> > > > the logical I/O tokens, the purpose of that macro is really meant
> > > > for allocating PCI I/O port numbers within the address space of
> > > > one bus.
> > >
> > > As I mentioned above, special devices operate on CPU addresses
> > directly,
> > > not I/O tokens. For them there is no way to distinguish....
> > >
> > > >
> > > > Note that it's equally likely that whichever next platform needs
> > > > non-mapped I/O access like this actually needs them for PCI I/O
> > space,
> > > > and that will use it on addresses registered to a PCI host bridge.
> > >
> > > Ok so here you are talking about a platform that has got an I/O range
> > > under the PCI host controller, right?
> > > And this I/O range cannot be directly memory mapped but needs special
> > > redirections for the I/O tokens, right?
> > >
> > > In this scenario registering the I/O ranges with the forbidden range
> > > implemented by the current patch would still allow to redirect I/O
> > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > >
> > > So effectively the special PCI host controller
> > > 1) knows the physical range that needs special redirection
> > > 2) register such range
> > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > special accessors
> > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
> > >
> > > So to be honest I think this patch can fit well both with
> > > special PCI controllers that need I/O tokens redirection and with
> > > special non-PCI controllers that need non-PCI I/O physical
> > > address redirection...
> > >
> > > Thanks (and sorry for the long reply but I didn't know how
> > > to make the explanation shorter :) )
> > >
> > > Gab
> > >
> > > >
> > > > If we separate the two steps:
> > > >
> > > > a) assign a range of logical I/O port numbers to a bus
> > > > b) register a set of helpers for redirecting logical I/O
> > > > port to a helper function
> > > >
> > > > then I think the code will get cleaner and more flexible.
> > > > It should actually then be able to replace the powerpc
> > > > specific implementation.
> > > >
> > > > Arnd
> >
> > --
> > ====================
> > | I would like to |
> > | fix the world, |
> > | but they're not |
> > | giving me the |
> > \ source code! /
> > ---------------
> > ¯\_(ツ)_/¯
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver
From: Georgi Djakov @ 2016-11-11 17:26 UTC (permalink / raw)
To: Bjorn Andersson, Stephen Boyd
Cc: mturquette, linux-clk, linux-kernel, linux-arm-msm, devicetree,
Rob Herring
In-Reply-To: <20161103182834.GR25787@tuxbot>
On 11/03/2016 08:28 PM, Bjorn Andersson wrote:
> On Wed 02 Nov 15:55 PDT 2016, Stephen Boyd wrote:
>
>> On 11/02, Bjorn Andersson wrote:
>>> On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote:
>>>
>>>> On 10/19, Georgi Djakov wrote:
>>>>> Add a driver for the A53 Clock Controller. It is a hardware block that
>>>>> implements a combined mux and half integer divider functionality. It can
>>>>> choose between a fixed-rate clock or the dedicated A53 PLL. The source
>>>>> and the divider can be set both at the same time.
>>>>>
>>>>> This is required for enabling CPU frequency scaling on platforms like
>>>>> MSM8916.
>>>>>
>>>>
>>>> Please Cc DT reviewers.
>>>>
>>>>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>>>>> ---
>>>>> .../devicetree/bindings/clock/qcom,a53cc.txt | 22 +++
>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>> drivers/clk/qcom/a53cc.c | 155 +++++++++++++++++++++
>>>>> 4 files changed, 186 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
>>>>> create mode 100644 drivers/clk/qcom/a53cc.c
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
>>>>> new file mode 100644
>>>>> index 000000000000..a025f062f177
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
>>>>> @@ -0,0 +1,22 @@
>>>>> +Qualcomm A53 CPU Clock Controller Binding
>>>>> +------------------------------------------------
>>>>> +The A53 CPU Clock Controller is hardware, which provides a combined
>>>>> +mux and divider functionality for the CPU clocks. It can choose between
>>>>> +a fixed rate clock and the dedicated A53 PLL.
>>>>> +
>>>>> +Required properties :
>>>>> +- compatible : shall contain:
>>>>> +
>>>>> + "qcom,a53cc"
>>>>> +
>>>>> +- reg : shall contain base register location and length
>>>>> + of the APCS region
>>>>> +- #clock-cells : shall contain 1
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> + apcs: syscon@b011000 {
>>>>> + compatible = "qcom,a53cc", "syscon";
>>>>
>>>> Why is it a syscon? Is that part used?
>>>>
>>>
>>> I use the register at offset 8 for interrupting the other subsystems, so
>>> this must be available as something I can poke.
>>>
>>> Which makes me think that this should be described as a "simple-mfd" and
>>> "syscon" with the a53cc node as a child - grabbing the regmap of the
>>> syscon parent, rather then ioremapping the same region again.
>>>
>>
>> That's sort of a question for DT reviewers. The register space
>> certainly seems like a free for all with a tilt toward power
>> management of the CPU, similar to how this was done on Krait
>> based designs.
>>
>
> Right. But this kind of mashup blocks was the reason why simple-mfd was
> put in place.
>
Ok, thanks for the comments. Then i will make it look like this:
apcs: syscon@b011000 {
compatible = "syscon", "simple-mfd";
reg = <0x0b011000 0x1000>;
a53mux: clock {
compatible = "qcom,msm8916-a53cc";
#clock-cells = <1>;
};
};
Thanks,
Georgi
>> I wonder why we didn't make up some provider/consumer binding for
>> the "kicking" feature used by SMD/RPM code. Then this could be a
>> clock provider and a "kick" provider (haha #kick-cells) and the
>> usage of syscon/regmap wouldn't be mandatory.
>>
>
> I did consider doing that, but had enough dependencies to put in place
> as it was.
>
> I'm in favour of us inventing a kicker API and it's found outside out
> use cases as well (e.g. virtio/rpmsg).
>
> Regards,
> Bjorn
>
^ permalink raw reply
* Re: [PATCH v8] mtd: nand: add tango NAND flash controller support
From: Boris Brezillon @ 2016-11-11 17:14 UTC (permalink / raw)
To: Mason
Cc: Marc Gonzalez, linux-mtd, Richard Weinberger, DT, Rob Herring,
Mark Rutland, Sebastian Frias
In-Reply-To: <5825EB70.4070406-GANU6spQydw@public.gmane.org>
Hi Marc,
On Fri, 11 Nov 2016 17:01:52 +0100
Mason <slash.tmp-GANU6spQydw@public.gmane.org> wrote:
> On 06/11/2016 23:58, Boris Brezillon wrote:
>
> > Applied after fixing a few coding style issues to make checkpatch happy.
>
> First of all, I want to thank you for all the help you provided
> along the way.
>
> I have to admit that I'm a bit frustrated by some of the changes you made
> to the patch.
>
> Specifically, changing
>
> from: if (ptr_expr == NULL)
> to: if (!ptr_expr)
>
> I dislike the second form, because it "hides" what is being tested.
> I've even seen people use !count to mean count == 0, and I find that
> very unintuitive.
I just fixed checkpatch --strict complaints.
>
> I also have a hard time discerning a '!' after a '('
>
>
> The other change is the chip->options initialization. I thought
> you said on IRC I could keep my preferred formatting.
Hm, I said that you could use one flag per line, and I kept that. I
just moved the 'or' operator which is, IMO, better placed at the end of
the line, and I aligned the following flags with the first one to make
checkpatch happy.
>
>
> In the end, these are tiny issues in the grand scheme of things,
> but it was important for me to point them out.
Some maintainers don't care much, but I think enforcing these rules is
what brings consistency in the kernel code, that's why I try to make
checkpatch happy when I submit new code and ask developers to do so
when they submit code to the NAND subsystem.
I know you often disagree with the Linux coding style rules, but you're
a contributor to this project, and as such, you should commit to
the defined rules (and this includes the coding style rules).
And it appears that, instead of complying to these rules when you're
asked to, you keep arguing endlessly that your own coding style is
better. You'd better spend time on things that really matters.
Note that most of the time, when the contribution is looking good, but
a few coding style issue remain, I'm fixing those issues myself because
I know how annoying it can be to ask someone to post a new version to
fix such minor things.
But since you complain about that, next time I'll ask you to make
"checkpatch --strict" happy before accepting your patch.
On a side note, as I already told you privately, you seem to be a smart
guy (the evolution of the tango NAND driver shows that you're able
to understand how things work, and take comments/reviews into account).
But you have the bad habit of consistently arguing when you're asked to
change something (and especially on minor things that are easy to fix).
This is really the kind of behavior that can upset maintainers (me
included). So please, try to work on that.
Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V8 0/6] thermal: bcm2835: add thermal driver
From: Eric Anholt @ 2016-11-11 17:01 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Lee Jones, Russell King,
Florian Fainelli, Catalin Marinas, Will Deacon, linux-pm,
devicetree, linux-rpi-kernel, linux-arm-kernel
Cc: Martin Sperl
In-Reply-To: <1478081906-12009-1-git-send-email-kernel@martin.sperl.org>
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
kernel@martin.sperl.org writes:
> From: Martin Sperl <kernel@martin.sperl.org>
Since Eduardo seems to be AFK, I've pulled this series to my -next
branches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-11 16:54 UTC (permalink / raw)
To: liviu.dudau@arm.com, Gabriele Paoloni
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
bhelgaas@googl e.com, lorenzo.pieralisi@arm.com,
catalin.marinas@arm.com, minyard@acm.org, Arnd Bergmann,
linux-pci@vger.kernel.org, John Garry, will.deacon@arm.com,
linux-kernel@vger.kernel.org, Yuanzhichang, Linuxarm,
olof@lixom.net, robh+dt@kernel.org, xuwei (O),
linux-serial@vger.kernel.org, benh@kernel.crashing.org,
zourongrong@gmail.com
In-Reply-To: <20161111144539.GL10219@e106497-lin.cambridge.arm.com>
Hi, Liviu,
On 11/11/2016 10:45 PM, liviu.dudau@arm.com wrote:
> On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
>> Hi Arnd
>>
>>> -----Original Message-----
>>> From: Arnd Bergmann [mailto:arnd@arndb.de]
>>> Sent: 10 November 2016 16:07
>>> To: Gabriele Paoloni
>>> Cc: linux-arm-kernel@lists.infradead.org; Yuanzhichang;
>>> mark.rutland@arm.com; devicetree@vger.kernel.org;
>>> lorenzo.pieralisi@arm.com; minyard@acm.org; linux-pci@vger.kernel.org;
>>> benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
>>> kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
>>> robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
>>> catalin.marinas@arm.com; olof@lixom.net; liviu.dudau@arm.com;
>>> bhelgaas@googl e.com; zhichang.yuan02@gmail.com
>>> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
>>> Hip06
>>>
>>> On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
>>>>
>>>> Where should we get the range from? For LPC we know that it is going
>>>> Work on anything that is not used by PCI I/O space, and this is
>>>> why we use [0, PCIBIOS_MIN_IO]
>>>
>>> It should be allocated the same way we allocate PCI config space
>>> segments. This is currently done with the io_range list in
>>> drivers/pci/pci.c, which isn't perfect but could be extended
>>> if necessary. Based on what others commented here, I'd rather
>>> make the differences between ISA/LPC and PCI I/O ranges smaller
>>> than larger.
>
> Gabriele,
>
>>
>> I am not sure this would make sense...
>>
>> IMHO all the mechanism around io_range_list is needed to provide the
>> "mapping" between I/O tokens and physical CPU addresses.
>>
>> Currently the available tokens range from 0 to IO_SPACE_LIMIT.
>>
>> As you know the I/O memory accessors operate on whatever
>> __of_address_to_resource sets into the resource (start, end).
>>
>> With this special device in place we cannot know if a resource is
>> assigned with an I/O token or a physical address, unless we forbid
>> the I/O tokens to be in a specific range.
>>
>> So this is why we are changing the offsets of all the functions
>> handling io_range_list (to make sure that a range is forbidden to
>> the tokens and is available to the physical addresses).
>>
>> We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
>> because this is the maximum physical I/O range that a non PCI device
>> can operate on and because we believe this does not impose much
>> restriction on the available I/O token range; that now is
>> [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
>> So we believe that the chosen forbidden range can accommodate
>> any special ISA bus device with no much constraint on the rest
>> of I/O tokens...
>
> Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> actually need another variable for "reserving" an area in the I/O space
> that can be used for physical addresses rather than I/O tokens.
>
I think selecting PCIBIOS_MIN_IO as the separator of mapped and non-mapped I/O
range probably is not so reasonable.
PCIBIOS_MIN_IN is specific to PCI devices, it seems as the recommended minimal
start I/O address when assigning the pci device I/O region. It is probably not
defined in some platforms/architectures when no PCI is needed there. That is why
my patch caused some compile error on some archs;
But more important thing is that the PCIBIOS_MIN_IO has different value on
different platforms/architectures. On Arm64, it is 4K currently, but in other
archs, it is not true. And the maximum LPC I/O address should be 64K
theoretically, although for compatible ISA, 2K is enough.
So, It means using PCIBIOS_MIN_IO on arm64 can match our I/O reservation
require. But we can not make this indirectIO work well on other architectures.
I am thinking Arnd's suggestion. But I worry about I haven't completely
understood his idea. What about create a new bus host for LPC/ISA whose I/O
range can be 64KB? This LPC/ISA I/O range works similar to PCI host bridge's I/O
window, all the downstream devices under LPC/ISA should request I/O from that
root resource. But it seems Arnd want this root resource registered dynamically,
I am not sure how to do...
Anyway, if we have this root I/O resource, we don't need any new macro or
variable for the LPC/ISA I/O reservation.
Hope my thought is right.
Best,
Zhichang
> The one good example for using PCIBIOS_MIN_IO is when your platform/architecture
> does not support legacy ISA operations *at all*. In that case someone
> sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> so that it doesn't get used. With Zhichang's patch you now start forcing
> those platforms to have a valid address below PCIBIOS_MIN_IO.
>
> For the general case you also have to bear in mind that PCIBIOS_MIN_IO could
> be zero. In that case, what is your "forbidden" range? [0, 0) ? So it makes
> sense to add a new #define that should only be defined by those architectures/
> platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> where I/O tokens can't be generated for.
>
> Best regards,
> Liviu
>
>>
>>>
>>>>> Your current version has
>>>>>
>>>>> if (arm64_extio_ops->pfout) \
>>>>> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>>>>> addr, value, sizeof(type)); \
>>>>>
>>>>> Instead, just subtract the start of the range from the logical
>>>>> port number to transform it back into a bus-local port number:
>>>>
>>>> These accessors do not operate on IO tokens:
>>>>
>>>> If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
>>>> addr is not going to be an I/O token; in fact patch 2/3 imposes that
>>>> the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
>>> PCIBIOS_MIN_IO
>>>> we have free physical addresses that the accessors can operate on.
>>>
>>> Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
>>> the logical I/O tokens, the purpose of that macro is really meant
>>> for allocating PCI I/O port numbers within the address space of
>>> one bus.
>>
>> As I mentioned above, special devices operate on CPU addresses directly,
>> not I/O tokens. For them there is no way to distinguish....
>>
>>>
>>> Note that it's equally likely that whichever next platform needs
>>> non-mapped I/O access like this actually needs them for PCI I/O space,
>>> and that will use it on addresses registered to a PCI host bridge.
>>
>> Ok so here you are talking about a platform that has got an I/O range
>> under the PCI host controller, right?
>> And this I/O range cannot be directly memory mapped but needs special
>> redirections for the I/O tokens, right?
>>
>> In this scenario registering the I/O ranges with the forbidden range
>> implemented by the current patch would still allow to redirect I/O
>> tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
>>
>> So effectively the special PCI host controller
>> 1) knows the physical range that needs special redirection
>> 2) register such range
>> 3) uses pci_pio_to_address() to retrieve the IO tokens for the
>> special accessors
>> 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
>>
>> So to be honest I think this patch can fit well both with
>> special PCI controllers that need I/O tokens redirection and with
>> special non-PCI controllers that need non-PCI I/O physical
>> address redirection...
>>
>> Thanks (and sorry for the long reply but I didn't know how
>> to make the explanation shorter :) )
>>
>> Gab
>>
>>>
>>> If we separate the two steps:
>>>
>>> a) assign a range of logical I/O port numbers to a bus
>>> b) register a set of helpers for redirecting logical I/O
>>> port to a helper function
>>>
>>> then I think the code will get cleaner and more flexible.
>>> It should actually then be able to replace the powerpc
>>> specific implementation.
>>>
>>> Arnd
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: Jonathan Corbet, Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: Mark Rutland, Russell King, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20161111164654.15273-1-icenowy-ymACFijhrKM@public.gmane.org>
Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
Add a device tree file for it.
As there's still no mainline-compatible driver for the SDIO WLAN card on
board (a new card by Allwinner), the mmc1 controller is not enabled yet.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 148 +++++++++++++++++++++++
2 files changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9843fb0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -818,6 +818,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-h2plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
new file mode 100644
index 0000000..581f56e
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
+ *
+ * Based on sun8i-h3-orangepi-one.dts, which is:
+ * Copyright (C) 2016 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h2plus.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi Zero";
+ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus",
+ "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ leds_opi0: led_pins@0 {
+ allwinner,pins = "PA17";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&r_pio {
+ leds_r_opi0: led_pins@0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "disabled";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+ status = "disabled";
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sunxi: add Allwinner H2+ dtsi
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: Jonathan Corbet, Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: Mark Rutland, Russell King, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20161111164654.15273-1-icenowy-ymACFijhrKM@public.gmane.org>
Allwinner H2+ is a SoC so similar with H3 that H3 drivers and memory map
is known to work well on H2+, with both BSP kernel/firmware or the
mainline ones.
So add a dtsi file which only include the H3 dtsi only, so we can add
H2+-specified nodes in the dtsi file when we find any software
difference between H2+ and H3.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-h2plus.dtsi | 43 +++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus.dtsi
diff --git a/arch/arm/boot/dts/sun8i-h2plus.dtsi b/arch/arm/boot/dts/sun8i-h2plus.dtsi
new file mode 100644
index 0000000..76fc3d0
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun8i-h3.dtsi"
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Icenowy Zheng @ 2016-11-11 16:46 UTC (permalink / raw)
To: Jonathan Corbet, Maxime Ripard, Chen-Yu Tsai, Rob Herring
Cc: Mark Rutland, Russell King, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
Allwinner H2+ is a quad-core Cortex-A7 SoC.
It is very like H3, that they share the same SoC ID (0x1680), and H3
memory maps as well as drivers works well on the SoC.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
---
Documentation/arm/sunxi/README | 4 ++++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index cd02433..1fe4d99c 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -63,6 +63,10 @@ SunXi family
+ User Manual
http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
+ - Allwinner H2+ (sun8i)
+ + No document available now, but is known to be working properly with
+ H3 drivers and memory map.
+
- Allwinner H3 (sun8i)
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 3975d0a..0c0f277 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -13,5 +13,6 @@ using one of the following compatible strings:
allwinner,sun8i-a33
allwinner,sun8i-a83t
allwinner,sun8i-h3
+ allwinner,sun8i-h2plus
allwinner,sun9i-a80
nextthing,gr8
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 2e2bde2..3647ad7 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
"allwinner,sun8i-a83t",
+ "allwinner,sun8i-h2plus",
"allwinner,sun8i-h3",
NULL,
};
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] regulator: Add coupled regulator
From: Mark Brown @ 2016-11-11 16:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: Rob Herring, Chen-Yu Tsai, Liam Girdwood, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20161107154738.ewliwzx5plams4ni@lukather>
[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]
On Mon, Nov 07, 2016 at 04:47:38PM +0100, Maxime Ripard wrote:
> Since regulator_get returns a struct regulator pointer, it felt
> logical to try to add the list of parent regulators to it, especially
> as this structure is per-consumer, and different consumers might have
> different combinations of regulators.
> However, this structure embeds a pointer to a struct regulator_dev,
> which seems to model the regulator itself, but will also contain
> pointer to the struct regulator, probably to model its parent? I guess
It'd be a lot easier to follow this if you named the fields... The rdev
in the struct regulator is indeed the physical device. The struct
regulator called supply in struct regulator_dev is indeed the parent
regulator.
> my first question would be do we care about nesting? or having a
> regulator with multiple parents?
Well, it seems that your use case here is multiple parents so I guess we
do care about it. :)
> It also contains the constraints on each regulator, which might or
> might not be different for each of the coupled regulators, but I'm
> guessing the couple might have contraints of its own too I guess. Is
> it something that might happen? Should we care about it?
I can't see how one could physically have constraints that didn't apply
to both parents.
> And finally, my real question is, do we want to aggregate them in
> struct regulator, at the consumer level, which might make the more
> sense, or do we want to create an intermediate regulator internally?
> What is your take on this?
My initial thought without having tried to implement this is that doing
things in an intermediate regulator might do a better job of
encapsulating things it if it works out but I've got a feeling that it's
not going to work out well and that therefore doing it in the consumer
with multiple rdevs will be better. But really either approach is fine
if it doesn't look horrible.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Mark Rutland @ 2016-11-11 16:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Guilherme G. Piccoli, devicetree, marc.zyngier, frowand.list,
robh+dt, linux-pci, linuxppc-dev
In-Reply-To: <1478813443.2592.2.camel@au1.ibm.com>
On Fri, Nov 11, 2016 at 08:30:43AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2016-11-09 at 19:04 +0000, Mark Rutland wrote:
> >
> > If we don't have an interrupt-map on a PCI controller, why don't we
> > instead log a message regarding that being missing, and give up
> > early?
>
> Why ? It's legit to not support LSIs.
Sure; I had envisioned a message like:
pr_info("%s: no interrupt-map, INTx interrupts not possible\n",
pci_controller_name);
... Which tells the user exaclty what we know, and doesn't imply either
an error or the actual absence of HW support.
> > That sounds like a more generically useful error message; it's also
> > possible that a DT author simply forgot to add the map, and the
> > platform has suitable interrupts wired up.
>
> But it's not necessarily an error...
Sure, "error" was a misnomer.
> > > This patch introduces a different message for this specific case,
> > > and it also reduces the level of the message from error to warning.
> > > Before this patch, when an adapter was plugged in a slot without
> > Level
> > > interrupts capabilities, we saw generic error messages like this:
> > >
> > > [54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-
> > 22
> > >
> > > Now, with this applied, we see the following specific message:
> > >
> > > [19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot
> > of this
> > > device has no Level-triggered Interrupts capability.
> >
> > Following my above example, this has gone from opaque to potentially
> > misleading
>
> I'm not sure. At least for some of our platforms this is the correct
> message :-) Our Hypervisor doesn't allow LSIs on some slots.
>
> I think it's not that misleading. It's obvious something is wrong with
> LSIs, which you can easily figure out from there.
As above, I think it's clearer to log that there's no interrupt-map for
the controller.
Orthogonal to that, "INTx" is a more generally understood name for the
legacy wired PCI interrupts, and is probably preferable in generic code.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v3 1/3] ASoC: atmel_ssc_dai: if not provided, default to sensible dividers
From: Mark Brown @ 2016-11-11 16:05 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Rob Herring,
Mark Rutland, Nicolas Ferre, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478863752-10569-2-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Fri, Nov 11, 2016 at 12:29:10PM +0100, Peter Rosin wrote:
> When this driver masters BCLK and/or LRCLK, and noone has stated
> differently, assume that all the bits of a frame are used.
>
> This relieves the cpu dai users from the duty to fill in the dividers for
> the common case.
This looks good and like what I was meaning with my earlier feedback
(you sent a new version before I could reply to that). I'll leave this
for a little while to give others time to review though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox