| Message ID | 20190302141704.32547-2-marex@denx.de (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/2] Input: ili210x - Add DT binding for the Ilitek ILI2117 touch controller | expand |
Hi Marek, On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: > Add support for ILI2117 touch controller. This controller is similar > to the ILI210x and ILI251x, except for the following differences: > - Reading out of touch data must happen at most 300 mS after the > interrupt line was asserted. No command must be sent, the data > are returned upon pure I2C read of 43 bytes long. > - Supports 10 simultaneous touch inputs. > - Touch data format is slightly different. So with this and also I see there is another ili2117a submission, I do believe that we need to switch to using function pointers instead of if/else if/else style cheking of the model. Please try the patch below and see if it works for you and please rebase this one on to of it. Thanks.
On 8/10/19 6:41 PM, Dmitry Torokhov wrote: > Hi Marek, Hi, > On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: >> Add support for ILI2117 touch controller. This controller is similar >> to the ILI210x and ILI251x, except for the following differences: >> - Reading out of touch data must happen at most 300 mS after the >> interrupt line was asserted. No command must be sent, the data >> are returned upon pure I2C read of 43 bytes long. >> - Supports 10 simultaneous touch inputs. >> - Touch data format is slightly different. > > So with this and also I see there is another ili2117a submission, I do > believe that we need to switch to using function pointers instead of > if/else if/else style cheking of the model. How about we add tested functionality in first and only then do bigger untested changes ? I think that would work better for everyone.
On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: > On 8/10/19 6:41 PM, Dmitry Torokhov wrote: > > Hi Marek, > > Hi, > > > On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: > >> Add support for ILI2117 touch controller. This controller is similar > >> to the ILI210x and ILI251x, except for the following differences: > >> - Reading out of touch data must happen at most 300 mS after the > >> interrupt line was asserted. No command must be sent, the data > >> are returned upon pure I2C read of 43 bytes long. > >> - Supports 10 simultaneous touch inputs. > >> - Touch data format is slightly different. > > > > So with this and also I see there is another ili2117a submission, I do > > believe that we need to switch to using function pointers instead of > > if/else if/else style cheking of the model. > > How about we add tested functionality in first and only then do bigger > untested changes ? I think that would work better for everyone. Sorry, I would really prefer to do what is right and build additional functionality on top of the good foundation. I asked to switch to the function pointers before, but you did not want to citing performance (even though we are using function pointers everywhere in the kernel), now I gave a draft implementation, I hope you can use it. Thanks.
On 8/10/19 7:44 PM, Dmitry Torokhov wrote: > On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: >> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: >>> Hi Marek, >> >> Hi, >> >>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: >>>> Add support for ILI2117 touch controller. This controller is similar >>>> to the ILI210x and ILI251x, except for the following differences: >>>> - Reading out of touch data must happen at most 300 mS after the >>>> interrupt line was asserted. No command must be sent, the data >>>> are returned upon pure I2C read of 43 bytes long. >>>> - Supports 10 simultaneous touch inputs. >>>> - Touch data format is slightly different. >>> >>> So with this and also I see there is another ili2117a submission, I do >>> believe that we need to switch to using function pointers instead of >>> if/else if/else style cheking of the model. >> >> How about we add tested functionality in first and only then do bigger >> untested changes ? I think that would work better for everyone. > > Sorry, I would really prefer to do what is right and build additional > functionality on top of the good foundation. I asked to switch to the > function pointers before, but you did not want to citing performance > (even though we are using function pointers everywhere in the kernel), > now I gave a draft implementation, I hope you can use it. So why can't we add tested code in first and then add new huge untested patch on top and start testing it ? I think doing it in reverse is actually not helpful, if there is a problem in this massive new patch, it could be reverted without losing functionality.
On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: > On 8/10/19 7:44 PM, Dmitry Torokhov wrote: > > On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: > >> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: > >>>> Add support for ILI2117 touch controller. This controller is similar > >>>> to the ILI210x and ILI251x, except for the following differences: > >>>> - Reading out of touch data must happen at most 300 mS after the > >>>> interrupt line was asserted. No command must be sent, the data > >>>> are returned upon pure I2C read of 43 bytes long. > >>>> - Supports 10 simultaneous touch inputs. > >>>> - Touch data format is slightly different. > >>> > >>> So with this and also I see there is another ili2117a submission, I do > >>> believe that we need to switch to using function pointers instead of > >>> if/else if/else style cheking of the model. > >> > >> How about we add tested functionality in first and only then do bigger > >> untested changes ? I think that would work better for everyone. > > > > Sorry, I would really prefer to do what is right and build additional > > functionality on top of the good foundation. I asked to switch to the > > function pointers before, but you did not want to citing performance > > (even though we are using function pointers everywhere in the kernel), > > now I gave a draft implementation, I hope you can use it. > > So why can't we add tested code in first and then add new huge untested > patch on top and start testing it ? I think doing it in reverse is > actually not helpful, if there is a problem in this massive new patch, > it could be reverted without losing functionality. We still have 4 weeks till merge window + stabilization time past it. Thanks.
On 8/10/19 9:05 PM, Dmitry Torokhov wrote: > On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: >> On 8/10/19 7:44 PM, Dmitry Torokhov wrote: >>> On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: >>>> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: >>>>> Hi Marek, >>>> >>>> Hi, >>>> >>>>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: >>>>>> Add support for ILI2117 touch controller. This controller is similar >>>>>> to the ILI210x and ILI251x, except for the following differences: >>>>>> - Reading out of touch data must happen at most 300 mS after the >>>>>> interrupt line was asserted. No command must be sent, the data >>>>>> are returned upon pure I2C read of 43 bytes long. >>>>>> - Supports 10 simultaneous touch inputs. >>>>>> - Touch data format is slightly different. >>>>> >>>>> So with this and also I see there is another ili2117a submission, I do >>>>> believe that we need to switch to using function pointers instead of >>>>> if/else if/else style cheking of the model. >>>> >>>> How about we add tested functionality in first and only then do bigger >>>> untested changes ? I think that would work better for everyone. >>> >>> Sorry, I would really prefer to do what is right and build additional >>> functionality on top of the good foundation. I asked to switch to the >>> function pointers before, but you did not want to citing performance >>> (even though we are using function pointers everywhere in the kernel), >>> now I gave a draft implementation, I hope you can use it. >> >> So why can't we add tested code in first and then add new huge untested >> patch on top and start testing it ? I think doing it in reverse is >> actually not helpful, if there is a problem in this massive new patch, >> it could be reverted without losing functionality. > > We still have 4 weeks till merge window + stabilization time past it. Sure, but this patch was posted 5 months ago and was in real world deployment since, so it has 5 months of practical testing. I don't want to throw that away. The patch you want me to test can easily be rebased on the ILI2117 support and then we retain those months of testing, which I think is much better.
On Sat, Aug 10, 2019 at 11:30:29PM +0200, Marek Vasut wrote: > On 8/10/19 9:05 PM, Dmitry Torokhov wrote: > > On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: > >> On 8/10/19 7:44 PM, Dmitry Torokhov wrote: > >>> On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: > >>>> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: > >>>>> Hi Marek, > >>>> > >>>> Hi, > >>>> > >>>>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: > >>>>>> Add support for ILI2117 touch controller. This controller is similar > >>>>>> to the ILI210x and ILI251x, except for the following differences: > >>>>>> - Reading out of touch data must happen at most 300 mS after the > >>>>>> interrupt line was asserted. No command must be sent, the data > >>>>>> are returned upon pure I2C read of 43 bytes long. > >>>>>> - Supports 10 simultaneous touch inputs. > >>>>>> - Touch data format is slightly different. > >>>>> > >>>>> So with this and also I see there is another ili2117a submission, I do > >>>>> believe that we need to switch to using function pointers instead of > >>>>> if/else if/else style cheking of the model. > >>>> > >>>> How about we add tested functionality in first and only then do bigger > >>>> untested changes ? I think that would work better for everyone. > >>> > >>> Sorry, I would really prefer to do what is right and build additional > >>> functionality on top of the good foundation. I asked to switch to the > >>> function pointers before, but you did not want to citing performance > >>> (even though we are using function pointers everywhere in the kernel), > >>> now I gave a draft implementation, I hope you can use it. > >> > >> So why can't we add tested code in first and then add new huge untested > >> patch on top and start testing it ? I think doing it in reverse is > >> actually not helpful, if there is a problem in this massive new patch, > >> it could be reverted without losing functionality. > > > > We still have 4 weeks till merge window + stabilization time past it. > > Sure, but this patch was posted 5 months ago and was in real world > deployment since, so it has 5 months of practical testing. I don't want > to throw that away. > > The patch you want me to test can easily be rebased on the ILI2117 > support and then we retain those months of testing, which I think is > much better. OK, fine, I rebased the patch[es] on top of this one and uploaded to: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git iili2xxx-touchscreen Please give it a try and if it works I'll merge into next. Thanks.
On 8/11/19 6:42 PM, Dmitry Torokhov wrote: > On Sat, Aug 10, 2019 at 11:30:29PM +0200, Marek Vasut wrote: >> On 8/10/19 9:05 PM, Dmitry Torokhov wrote: >>> On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: >>>> On 8/10/19 7:44 PM, Dmitry Torokhov wrote: >>>>> On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: >>>>>> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: >>>>>>> Hi Marek, >>>>>> >>>>>> Hi, >>>>>> >>>>>>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: >>>>>>>> Add support for ILI2117 touch controller. This controller is similar >>>>>>>> to the ILI210x and ILI251x, except for the following differences: >>>>>>>> - Reading out of touch data must happen at most 300 mS after the >>>>>>>> interrupt line was asserted. No command must be sent, the data >>>>>>>> are returned upon pure I2C read of 43 bytes long. >>>>>>>> - Supports 10 simultaneous touch inputs. >>>>>>>> - Touch data format is slightly different. >>>>>>> >>>>>>> So with this and also I see there is another ili2117a submission, I do >>>>>>> believe that we need to switch to using function pointers instead of >>>>>>> if/else if/else style cheking of the model. >>>>>> >>>>>> How about we add tested functionality in first and only then do bigger >>>>>> untested changes ? I think that would work better for everyone. >>>>> >>>>> Sorry, I would really prefer to do what is right and build additional >>>>> functionality on top of the good foundation. I asked to switch to the >>>>> function pointers before, but you did not want to citing performance >>>>> (even though we are using function pointers everywhere in the kernel), >>>>> now I gave a draft implementation, I hope you can use it. >>>> >>>> So why can't we add tested code in first and then add new huge untested >>>> patch on top and start testing it ? I think doing it in reverse is >>>> actually not helpful, if there is a problem in this massive new patch, >>>> it could be reverted without losing functionality. >>> >>> We still have 4 weeks till merge window + stabilization time past it. >> >> Sure, but this patch was posted 5 months ago and was in real world >> deployment since, so it has 5 months of practical testing. I don't want >> to throw that away. >> >> The patch you want me to test can easily be rebased on the ILI2117 >> support and then we retain those months of testing, which I think is >> much better. > > OK, fine, I rebased the patch[es] on top of this one and uploaded to: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git iili2xxx-touchscreen > > Please give it a try and if it works I'll merge into next. Sorry for the delay. I had to revert Input: ili210x - define and use chip operations structure as with ^ I get no events. The Input: ili210x - switch to using threaded IRQ seems to work. Note that you forgot to apply Input: ili210x - Add DT binding for the Ilitek ILI2117 touch controller
On Fri, Aug 23, 2019 at 12:34:29PM +0200, Marek Vasut wrote: > On 8/11/19 6:42 PM, Dmitry Torokhov wrote: > > On Sat, Aug 10, 2019 at 11:30:29PM +0200, Marek Vasut wrote: > >> On 8/10/19 9:05 PM, Dmitry Torokhov wrote: > >>> On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: > >>>> On 8/10/19 7:44 PM, Dmitry Torokhov wrote: > >>>>> On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: > >>>>>> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: > >>>>>>> Hi Marek, > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: > >>>>>>>> Add support for ILI2117 touch controller. This controller is similar > >>>>>>>> to the ILI210x and ILI251x, except for the following differences: > >>>>>>>> - Reading out of touch data must happen at most 300 mS after the > >>>>>>>> interrupt line was asserted. No command must be sent, the data > >>>>>>>> are returned upon pure I2C read of 43 bytes long. > >>>>>>>> - Supports 10 simultaneous touch inputs. > >>>>>>>> - Touch data format is slightly different. > >>>>>>> > >>>>>>> So with this and also I see there is another ili2117a submission, I do > >>>>>>> believe that we need to switch to using function pointers instead of > >>>>>>> if/else if/else style cheking of the model. > >>>>>> > >>>>>> How about we add tested functionality in first and only then do bigger > >>>>>> untested changes ? I think that would work better for everyone. > >>>>> > >>>>> Sorry, I would really prefer to do what is right and build additional > >>>>> functionality on top of the good foundation. I asked to switch to the > >>>>> function pointers before, but you did not want to citing performance > >>>>> (even though we are using function pointers everywhere in the kernel), > >>>>> now I gave a draft implementation, I hope you can use it. > >>>> > >>>> So why can't we add tested code in first and then add new huge untested > >>>> patch on top and start testing it ? I think doing it in reverse is > >>>> actually not helpful, if there is a problem in this massive new patch, > >>>> it could be reverted without losing functionality. > >>> > >>> We still have 4 weeks till merge window + stabilization time past it. > >> > >> Sure, but this patch was posted 5 months ago and was in real world > >> deployment since, so it has 5 months of practical testing. I don't want > >> to throw that away. > >> > >> The patch you want me to test can easily be rebased on the ILI2117 > >> support and then we retain those months of testing, which I think is > >> much better. > > > > OK, fine, I rebased the patch[es] on top of this one and uploaded to: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git iili2xxx-touchscreen > > > > Please give it a try and if it works I'll merge into next. > > Sorry for the delay. > > I had to revert > Input: ili210x - define and use chip operations structure > as with ^ I get no events. Any more details? Does the driver bind to the device? Is there data coming form the wire and it is being consumed but not parsed properly? Something else? Thanks.
On 9/17/19 5:28 AM, Dmitry Torokhov wrote: > On Fri, Aug 23, 2019 at 12:34:29PM +0200, Marek Vasut wrote: >> On 8/11/19 6:42 PM, Dmitry Torokhov wrote: >>> On Sat, Aug 10, 2019 at 11:30:29PM +0200, Marek Vasut wrote: >>>> On 8/10/19 9:05 PM, Dmitry Torokhov wrote: >>>>> On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: >>>>>> On 8/10/19 7:44 PM, Dmitry Torokhov wrote: >>>>>>> On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: >>>>>>>> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: >>>>>>>>> Hi Marek, >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: >>>>>>>>>> Add support for ILI2117 touch controller. This controller is similar >>>>>>>>>> to the ILI210x and ILI251x, except for the following differences: >>>>>>>>>> - Reading out of touch data must happen at most 300 mS after the >>>>>>>>>> interrupt line was asserted. No command must be sent, the data >>>>>>>>>> are returned upon pure I2C read of 43 bytes long. >>>>>>>>>> - Supports 10 simultaneous touch inputs. >>>>>>>>>> - Touch data format is slightly different. >>>>>>>>> >>>>>>>>> So with this and also I see there is another ili2117a submission, I do >>>>>>>>> believe that we need to switch to using function pointers instead of >>>>>>>>> if/else if/else style cheking of the model. >>>>>>>> >>>>>>>> How about we add tested functionality in first and only then do bigger >>>>>>>> untested changes ? I think that would work better for everyone. >>>>>>> >>>>>>> Sorry, I would really prefer to do what is right and build additional >>>>>>> functionality on top of the good foundation. I asked to switch to the >>>>>>> function pointers before, but you did not want to citing performance >>>>>>> (even though we are using function pointers everywhere in the kernel), >>>>>>> now I gave a draft implementation, I hope you can use it. >>>>>> >>>>>> So why can't we add tested code in first and then add new huge untested >>>>>> patch on top and start testing it ? I think doing it in reverse is >>>>>> actually not helpful, if there is a problem in this massive new patch, >>>>>> it could be reverted without losing functionality. >>>>> >>>>> We still have 4 weeks till merge window + stabilization time past it. >>>> >>>> Sure, but this patch was posted 5 months ago and was in real world >>>> deployment since, so it has 5 months of practical testing. I don't want >>>> to throw that away. >>>> >>>> The patch you want me to test can easily be rebased on the ILI2117 >>>> support and then we retain those months of testing, which I think is >>>> much better. >>> >>> OK, fine, I rebased the patch[es] on top of this one and uploaded to: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git iili2xxx-touchscreen >>> >>> Please give it a try and if it works I'll merge into next. >> >> Sorry for the delay. >> >> I had to revert >> Input: ili210x - define and use chip operations structure >> as with ^ I get no events. > > Any more details? Does the driver bind to the device? Is there data > coming form the wire and it is being consumed but not parsed properly? > Something else? The driver bound, there were just no data coming out of the /dev/input/event device at all. But if I reverted this patch "Input: ili210x - define and use chip operations structure", then I was getting data again. So that patch is likely wrong.
diff --git a/drivers/input/touchscreen/ili210x.c b/drivers/input/touchscreen/ili210x.c index 9169aa03958a..b8537e0e499b 100644 --- a/drivers/input/touchscreen/ili210x.c +++ b/drivers/input/touchscreen/ili210x.c @@ -12,6 +12,7 @@ #include <asm/unaligned.h> #define ILI210X_TOUCHES 2 +#define ILI211X_TOUCHES 10 #define ILI251X_TOUCHES 10 #define DEFAULT_POLL_PERIOD 20 @@ -29,6 +30,7 @@ struct firmware_version { enum ili2xxx_model { MODEL_ILI210X, + MODEL_ILI211X, MODEL_ILI251X, }; @@ -117,6 +119,27 @@ static bool ili210x_touchdata_to_coords(struct ili210x *priv, u8 *touchdata, return true; } +static bool ili211x_touchdata_to_coords(struct ili210x *priv, u8 *touchdata, + unsigned int finger, + unsigned int *x, unsigned int *y) +{ + u32 data; + + if (finger >= ILI211X_TOUCHES) + return false; + + data = get_unaligned_be32(touchdata + 1 + (finger * 4) + 0); + if (data == 0xffffffff) /* Finger up */ + return false; + + *x = ((touchdata[1 + (finger * 4) + 0] & 0xf0) << 4) | + touchdata[1 + (finger * 4) + 1]; + *y = ((touchdata[1 + (finger * 4) + 0] & 0x0f) << 8) | + touchdata[1 + (finger * 4) + 2]; + + return true; +} + static bool ili251x_touchdata_to_coords(struct ili210x *priv, u8 *touchdata, unsigned int finger, unsigned int *x, unsigned int *y) @@ -145,6 +168,9 @@ static bool ili210x_report_events(struct ili210x *priv, u8 *touchdata) if (priv->model == MODEL_ILI210X) { touch = ili210x_touchdata_to_coords(priv, touchdata, i, &x, &y); + } else if (priv->model == MODEL_ILI211X) { + touch = ili211x_touchdata_to_coords(priv, touchdata, + i, &x, &y); } else if (priv->model == MODEL_ILI251X) { touch = ili251x_touchdata_to_coords(priv, touchdata, i, &x, &y); @@ -175,12 +201,26 @@ static void ili210x_work(struct work_struct *work) dwork.work); struct i2c_client *client = priv->client; u8 touchdata[64] = { 0 }; + s16 sum = 0; bool touch; - int error = -EINVAL; + int i, error = -EINVAL; if (priv->model == MODEL_ILI210X) { error = ili210x_read_reg(client, REG_TOUCHDATA, touchdata, sizeof(touchdata)); + } else if (priv->model == MODEL_ILI211X) { + error = ili210x_read(client, touchdata, 43); + if (!error) { + /* This chip uses custom checksum at the end of data */ + for (i = 0; i <= 41; i++) + sum = (sum + touchdata[i]) & 0xff; + if ((-sum & 0xff) != touchdata[42]) { + dev_err(&client->dev, + "CRC error (crc=0x%02x expected=0x%02x)\n", + sum, touchdata[42]); + return; + } + } } else if (priv->model == MODEL_ILI251X) { error = ili210x_read_reg(client, REG_TOUCHDATA, touchdata, 31); @@ -310,6 +350,8 @@ static int ili210x_i2c_probe(struct i2c_client *client, priv->model = model; if (model == MODEL_ILI210X) priv->max_touches = ILI210X_TOUCHES; + if (model == MODEL_ILI211X) + priv->max_touches = ILI211X_TOUCHES; if (model == MODEL_ILI251X) priv->max_touches = ILI251X_TOUCHES; @@ -394,6 +436,7 @@ static SIMPLE_DEV_PM_OPS(ili210x_i2c_pm, static const struct i2c_device_id ili210x_i2c_id[] = { { "ili210x", MODEL_ILI210X }, + { "ili2117", MODEL_ILI211X }, { "ili251x", MODEL_ILI251X }, { } }; @@ -401,6 +444,7 @@ MODULE_DEVICE_TABLE(i2c, ili210x_i2c_id); static const struct of_device_id ili210x_dt_ids[] = { { .compatible = "ilitek,ili210x", .data = (void *)MODEL_ILI210X }, + { .compatible = "ilitek,ili2117", .data = (void *)MODEL_ILI211X }, { .compatible = "ilitek,ili251x", .data = (void *)MODEL_ILI251X }, { }, };
Add support for ILI2117 touch controller. This controller is similar to the ILI210x and ILI251x, except for the following differences: - Reading out of touch data must happen at most 300 mS after the interrupt line was asserted. No command must be sent, the data are returned upon pure I2C read of 43 bytes long. - Supports 10 simultaneous touch inputs. - Touch data format is slightly different. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Henrik Rydberg <rydberg@bitmath.org> Cc: Olivier Sobrie <olivier@sobrie.be> Cc: Philipp Puschmann <pp@emlix.com> To: linux-input@vger.kernel.org --- drivers/input/touchscreen/ili210x.c | 46 ++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-)