LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Andi Shyti <andi@etezian.org> To: Philipp Puschmann <pp@emlix.com> Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, rydberg@bitmath.org, andi@etezian.org, linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Input: ili251x - add support for Ilitek ILI251x touchscreens Date: Wed, 9 May 2018 06:49:09 +0900 [thread overview] Message-ID: <20180508214909.GB4974@jack.zhora.eu> (raw) In-Reply-To: <20180507131823.28800-1-pp@emlix.com> Hi Philipp, I had a fast look to your driver and I have few comments. > .../bindings/input/touchscreen/ili251x.txt | 35 ++ > drivers/input/touchscreen/Kconfig | 12 + > drivers/input/touchscreen/Makefile | 1 + > drivers/input/touchscreen/ili251x.c | 350 ++++++++++++++++++ > 4 files changed, 398 insertions(+) > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ili251x.txt > create mode 100644 drivers/input/touchscreen/ili251x.c Please split the patch, the bindig should be on a separate patch and must come before the driver. > +#define MAX_FINGERS 10 > +#define REG_TOUCHDATA 0x10 > +#define TOUCHDATA_FINGERS 6 > +#define REG_TOUCHDATA2 0x14 > +#define TOUCHDATA2_FINGERS 4 > +#define REG_PANEL_INFO 0x20 > +#define REG_FIRMWARE_VERSION 0x40 > +#define REG_PROTO_VERSION 0x42 > +#define REG_CALIBRATE 0xcc Can you please group and sort these definitions by type? REGs with REGs and others together? Please start the defines names with a unique identifier, ILI251X_REG_* instead of just REG_* > +struct finger { > + u8 x_high:6; > + u8 dummy:1; > + u8 status:1; > + u8 x_low; > + u8 y_high; > + u8 y_low; > + u8 pressure; > +} __packed; > + > +struct touchdata { > + u8 status; > + struct finger fingers[MAX_FINGERS]; > +} __packed; > + > +struct panel_info { > + u8 x_low; > + u8 x_high; > + u8 y_low; > + u8 y_high; > + u8 xchannel_num; > + u8 ychannel_num; > + u8 max_fingers; > +} __packed; > + > +struct firmware_version { > + u8 id; > + u8 major; > + u8 minor; > +} __packed; > + > +struct protocol_version { > + u8 major; > + u8 minor; > +} __packed; panel_info, firmware_version and protocol_version are used very little in the driver (just in probe). Is it really necessary to keep a definition? Is there a way to get rid of them? > +struct ili251x_data { > + struct i2c_client *client; > + struct input_dev *input; > + unsigned int max_fingers; > + bool use_pressure; > + struct gpio_desc *reset_gpio; > +}; Please start also the strct definitions with the unique identifier ili251x_* like you did with ili251x_data. > + > +static int ili251x_read_reg(struct i2c_client *client, u8 reg, void *buf, > + size_t len) > +{ > + struct i2c_msg msg[2] = { > + { > + .addr = client->addr, > + .flags = 0, > + .len = 1, > + .buf = ®, > + }, > + { > + .addr = client->addr, > + .flags = I2C_M_RD, > + .len = len, > + .buf = buf, > + } > + }; > + > + if (i2c_transfer(client->adapter, msg, 2) != 2) { > + dev_err(&client->dev, "i2c transfer failed\n"); > + return -EIO; > + } > + > + return 0; > +} I do not see the need for a ili251x_read_reg function. You are not reading more than 240 bytes per time, am I right? In this case I would use the smbus functions (at least whenever possible in case I miscalculated the 240b), this is ju a duplicated code. > +static void ili251x_report_events(struct ili251x_data *data, > + const struct touchdata *touchdata) > +{ > + struct input_dev *input = data->input; > + unsigned int i; > + bool touch; > + unsigned int x, y; > + const struct finger *finger; > + unsigned int reported_fingers = 0; > + > + /* the touch chip does not count the real fingers but switches between > + * 0, 6 and 10 reported fingers * > + * > + * FIXME: With a tested ili2511 we received only garbage for fingers > + * 6-9. As workaround we add a device tree option to limit the > + * handled number of fingers > + */ > + if (touchdata->status == 1) > + reported_fingers = 6; > + else if (touchdata->status == 2) > + reported_fingers = 10; > + > + for (i = 0; i < reported_fingers && i < data->max_fingers; i++) { > + input_mt_slot(input, i); > + > + finger = &touchdata->fingers[i]; > + > + touch = finger->status; > + input_mt_report_slot_state(input, MT_TOOL_FINGER, touch); > + x = finger->x_low | (finger->x_high << 8); > + y = finger->y_low | (finger->y_high << 8); the x and y calculation can go uinside the if() below, right? > + if (touch) { > + input_report_abs(input, ABS_MT_POSITION_X, x); > + input_report_abs(input, ABS_MT_POSITION_Y, y); > + if (data->use_pressure) > + input_report_abs(input, ABS_MT_PRESSURE, > + finger->pressure); > + > + } just a small nitpick, that is more a matter of preference, with if(!touch) continue; we save a level of indentation.
next prev parent reply other threads:[~2018-05-08 22:05 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-07 13:18 [PATCH] Input: ili251x - add support for Ilitek ILI251x touchscreens Philipp Puschmann 2018-05-08 17:51 ` Rob Herring 2018-05-08 21:49 ` Andi Shyti [this message] 2018-05-09 22:41 ` Dmitry Torokhov 2018-05-15 14:31 ` Philipp Puschmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180508214909.GB4974@jack.zhora.eu \ --to=andi@etezian.org \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.torokhov@gmail.com \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=pp@emlix.com \ --cc=robh+dt@kernel.org \ --cc=rydberg@bitmath.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).