linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Ahmet Inan <inan@distec.de>,
	Martin Fuzzey <martin.fuzzey@flowbird.group>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCHv2 4/5] Input: EXC3000: Add support to query model and fw_version
Date: Tue, 19 May 2020 23:31:45 +0200	[thread overview]
Message-ID: <20200519213145.peg2yxzt5n54atmh@earth.universe> (raw)
In-Reply-To: <a1700a82-3fa0-771a-e924-7bdacca71c18@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 7753 bytes --]

Hi,

On Tue, May 19, 2020 at 11:12:16PM +0200, Enric Balletbo i Serra wrote:
> On 19/5/20 20:24, Sebastian Reichel wrote:
> > Expose model and fw_version via sysfs. Also query the model
> > in probe to make sure, that the I2C communication with the
> > device works before successfully probing the driver.
> > 
> > This is a bit complicated, since EETI devices do not have
> > a sync interface. Sending the commands and directly reading
> > does not work. Sending the command and waiting for some time
> > is also not an option, since there might be touch events in
> > the mean time.
> > 
> > Last but not least we do not cache the results, since this
> > interface can be used to check the I2C communication is still
> > working as expected.
> > 
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> > ---
> >  drivers/input/touchscreen/exc3000.c | 138 +++++++++++++++++++++++++++-
> >  1 file changed, 137 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/input/touchscreen/exc3000.c b/drivers/input/touchscreen/exc3000.c
> > index 9622cba514b3..1ae758bbf627 100644
> > --- a/drivers/input/touchscreen/exc3000.c
> > +++ b/drivers/input/touchscreen/exc3000.c
> > @@ -24,6 +24,9 @@
> >  #define EXC3000_LEN_FRAME		66
> >  #define EXC3000_LEN_POINT		10
> >  
> > +#define EXC3000_LEN_MODEL_NAME		16
> > +#define EXC3000_LEN_FW_VERSION		16
> > +
> >  #define EXC3000_MT1_EVENT		0x06
> >  #define EXC3000_MT2_EVENT		0x18
> >  
> > @@ -64,6 +67,11 @@ struct exc3000_data {
> >  	struct touchscreen_properties prop;
> >  	struct timer_list timer;
> >  	u8 buf[2 * EXC3000_LEN_FRAME];
> > +	struct completion wait_event;
> > +	struct mutex query_lock;
> > +	int query_result;
> > +	char model[EXC3000_LEN_MODEL_NAME];
> > +	char fw_version[EXC3000_LEN_FW_VERSION];
> >  };
> >  
> >  static void exc3000_report_slots(struct input_dev *input,
> > @@ -149,6 +157,28 @@ static int exc3000_read_data(struct exc3000_data *data,
> >  	return 0;
> >  }
> >  
> > +static int exc3000_query_interrupt(struct exc3000_data *data)
> > +{
> > +	u8 *buf = data->buf;
> > +	int err;
> > +
> > +	err = i2c_master_recv(data->client, buf, EXC3000_LEN_FRAME);
> > +	if (err < 0)
> > +		return err;
> > +
> > +	if (buf[0] != 0x42)
> > +		return -EPROTO;
> > +
> > +	if (buf[4] == 'E')
> > +		strlcpy(data->model, buf+5, sizeof(data->model));
> > +	else if (buf[4] == 'D')
> > +		strlcpy(data->fw_version, buf+5, sizeof(data->fw_version));
> > +	else
> > +		return -EPROTO;
> > +
> > +	return 0;
> > +}
> > +
> >  static irqreturn_t exc3000_interrupt(int irq, void *dev_id)
> >  {
> >  	struct exc3000_data *data = dev_id;
> > @@ -157,6 +187,12 @@ static irqreturn_t exc3000_interrupt(int irq, void *dev_id)
> >  	int slots, total_slots;
> >  	int error;
> >  
> > +	if (mutex_is_locked(&data->query_lock)) {
> > +		data->query_result = exc3000_query_interrupt(data);
> > +		complete(&data->wait_event);
> > +		goto out;
> > +	}
> > +
> >  	error = exc3000_read_data(data, buf, &total_slots);
> >  	if (error) {
> >  		/* Schedule a timer to release "stuck" contacts */
> > @@ -184,11 +220,94 @@ static irqreturn_t exc3000_interrupt(int irq, void *dev_id)
> >  	return IRQ_HANDLED;
> >  }
> >  
> > +static int fw_version_show(struct device *dev,
> > +			   struct device_attribute *attr, char *buf)
> > +{
> > +	struct exc3000_data *data = dev_get_drvdata(dev);
> > +	static const u8 request[68] = {
> > +		0x67, 0x00, 0x42, 0x00, 0x03, 0x01, 'D', 0x00
> > +	};
> > +	struct i2c_client *client = data->client;
> > +	int err;
> > +
> > +	mutex_lock(&data->query_lock);
> > +
> > +	data->query_result = -ETIMEDOUT;
> > +	reinit_completion(&data->wait_event);
> > +
> > +	err = i2c_master_send(client, request, sizeof(request));
> > +	if (err < 0) {
> > +		mutex_unlock(&data->query_lock);
> > +		return err;
> > +	}
> > +
> > +	wait_for_completion_interruptible_timeout(&data->wait_event, 1*HZ);
> > +	mutex_unlock(&data->query_lock);
> > +
> > +	if (data->query_result < 0)
> > +		return data->query_result;
> > +
> > +	return sprintf(buf, "%s\n", data->fw_version);
> > +}
> > +static DEVICE_ATTR_RO(fw_version);
> > +
> 
> You should probably document the new sysfs entries, although are
> self-explanatory.

I suppose I could create
Documentation/ABI/testing/sysfs-driver-input-exc3000 or is there a
better place for sysfs API documentation of input devices?

> > +static ssize_t exc3000_get_model(struct exc3000_data *data)
> > +{
> > +	static const u8 request[68] = {
> > +		0x67, 0x00, 0x42, 0x00, 0x03, 0x01, 'E', 0x00
> > +	};
> > +	struct i2c_client *client = data->client;
> > +	int err;
> > +
> > +	mutex_lock(&data->query_lock);
> > +	data->query_result = -ETIMEDOUT;
> > +	reinit_completion(&data->wait_event);
> > +
> > +	err = i2c_master_send(client, request, sizeof(request));
> > +	if (err < 0) {
> > +		mutex_unlock(&data->query_lock);
> > +		return err;
> > +	}
> > +
> > +	wait_for_completion_interruptible_timeout(&data->wait_event, 1 * HZ);
> > +	mutex_unlock(&data->query_lock);
> > +
> > +	return data->query_result;
> > +}
> > +
> > +static ssize_t model_show(struct device *dev,
> > +			  struct device_attribute *attr, char *buf)
> > +{
> > +	struct exc3000_data *data = dev_get_drvdata(dev);
> > +	int err = exc3000_get_model(data);
> > +
> > +	if (err < 0)
> > +		return err;
> > +
> > +	return sprintf(buf, "%s\n", data->model);
> > +}
> > +static DEVICE_ATTR_RO(model);
> > +
> > +static struct attribute *sysfs_attrs[] = {
> > +	&dev_attr_fw_version.attr,
> > +	&dev_attr_model.attr,
> > +	NULL
> > +};
> > +
> > +static struct attribute_group exc3000_attribute_group = {
> > +	.attrs = sysfs_attrs
> > +};
> > +
> > +static const struct attribute_group *exc3000_attribute_groups[] = {
> > +	&exc3000_attribute_group,
> > +	NULL
> > +};
> > +
> >  static int exc3000_probe(struct i2c_client *client)
> >  {
> >  	struct exc3000_data *data;
> >  	struct input_dev *input;
> > -	int error, max_xy;
> > +	int error, max_xy, retry;
> >  
> >  	data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
> >  	if (!data)
> > @@ -202,15 +321,19 @@ static int exc3000_probe(struct i2c_client *client)
> >  		data->info = &exc3000_info[eeti_dev_id];
> >  	}
> >  	timer_setup(&data->timer, exc3000_timer, 0);
> > +	init_completion(&data->wait_event);
> > +	mutex_init(&data->query_lock);
> >  
> >  	input = devm_input_allocate_device(&client->dev);
> >  	if (!input)
> >  		return -ENOMEM;
> >  
> >  	data->input = input;
> > +	input_set_drvdata(input, data);
> >  
> >  	input->name = data->info->name;
> >  	input->id.bustype = BUS_I2C;
> > +	input->dev.groups = exc3000_attribute_groups;
> >  
> >  	max_xy = data->info->max_xy;
> >  	input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_xy, 0, 0);
> > @@ -233,6 +356,19 @@ static int exc3000_probe(struct i2c_client *client)
> >  	if (error)
> >  		return error;
> >  
> > +	for (retry = 0; retry < 3; ++retry) {
> 
> Just curious, is it known to fail and need retries?

No, but a single I²C transmission can always go bad and in that case
it makes sense to recover instead of failing to load the driver. Other
buses (e.g. PCI) handle this transparently, but I²C does not.

-- Sebastian

> 
> > +		error = exc3000_get_model(data);
> > +		if (!error)
> > +			break;
> > +		dev_warn(&client->dev, "Retry %d get EETI EXC3000 model: %d\n",
> > +			 retry + 1, error);
> > +	}
> > +
> > +	if (error)
> > +		return error;
> > +
> > +	dev_dbg(&client->dev, "TS Model: %s", data->model);
> > +
> >  	return 0;
> >  }
> >  
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-05-19 21:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 18:24 [PATCHv2 0/5] EXC3000 Updates Sebastian Reichel
2020-05-19 18:24 ` [PATCHv2 1/5] dt-bindings: touchscreen: Convert EETI EXC3000 touchscreen to json-schema Sebastian Reichel
2020-05-19 20:38   ` Enric Balletbo i Serra
2020-05-19 18:24 ` [PATCHv2 2/5] Input: EXC3000: switch to i2c's probe_new API Sebastian Reichel
2020-05-19 18:24 ` [PATCHv2 3/5] Input: EXC3000: add EXC80H60 and EXC80H84 support Sebastian Reichel
2020-05-19 23:52   ` kbuild test robot
2020-05-19 18:24 ` [PATCHv2 4/5] Input: EXC3000: Add support to query model and fw_version Sebastian Reichel
2020-05-19 21:12   ` Enric Balletbo i Serra
2020-05-19 21:31     ` Sebastian Reichel [this message]
2020-05-20  4:38   ` kbuild test robot
2020-05-19 18:24 ` [PATCHv2 5/5] Input: EXC3000: Add reset gpio support Sebastian Reichel
2020-05-19 20:57   ` Enric Balletbo i Serra

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=20200519213145.peg2yxzt5n54atmh@earth.universe \
    --to=sebastian.reichel@collabora.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=enric.balletbo@collabora.com \
    --cc=inan@distec.de \
    --cc=kernel@collabora.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.fuzzey@flowbird.group \
    /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: link
Be 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).