Re: [PATCH 2/2] Input: add MStar msg26xx touchscreen driver

Vincent Knecht
2021-01-21T11:34:39Z

Hi Dmitry!

Le mercredi 20 janvier 2021 à 23:03 -0800, Dmitry Torokhov a écrit :
> Hi Vincent,
>
> On Wed, Jan 20, 2021 at 07:01:08PM +0100, Vincent Knecht wrote:
> > +struct packet {
> > +       u8      y_high : 4;
> > +       u8      x_high : 4;
>
> This will not work on big endian devices as order of bitfields changes.
> I'd recommended treating contact packet as sequence of bytes and parse,
> i.e.
>
>         x = ((buf[0] & 0x0f) << 8) | buf[1];
>         x = ((buf[0] & 0xf0) << 4) | buf[2];
>         ...

Ok, will change in v2

> > +       u8      x_low;
> > +       u8      y_low;
> > +       u8      pressure;
> > +};
> > +
> > +
> > +static void mstar_power_on(struct msg26xx_ts_data *msg26xx)
> > +{
> > +       gpiod_set_value(msg26xx->reset_gpiod, 0);
> > +       mdelay(10);
> > +       gpiod_set_value(msg26xx->reset_gpiod, 1);
> > +       mdelay(FIRMWARE_ON_DELAY);
>
> I am pretty sure this is incorrect. You are saying that you release the
> reset line, wait a bit, and then assert it. gpiod is a logical API, with
> 0 being inactive and 1 being active, and here you want to activate the
> reset line, wait appropriate time, release it, and wait for the device
> to initialize. What does the datasheet say about reset GPIO polarity?
>
> Thanks.

I don't have any datasheet, only downstream code and dts for my device...
After changing this function to assert then deassert and also the reset gpio
polarity in my dts, it works as intended.
I'll send a v2 shortly, also changing the example section in bindings to
reflect the dts change I had to make (plus a minor change in title).

Thank you for the review!