linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Vokáč" <michal.vokac@ysoft.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Fabio Estevam <festevam@gmail.com>
Subject: Re: [PATCH] Input: pixcir_i2c_ts - add support for one-time total calibration
Date: Wed, 19 Nov 2025 11:23:35 +0100	[thread overview]
Message-ID: <0e5eb4c0-bc63-4ca7-9ba2-985afa237d67@ysoft.com> (raw)
In-Reply-To: <5uyos6zu74jfro7zsfup4zbkrywf5odi4ytfuwuttslgrus2of@fmopwef7fkme>

Hi Dmitry,

On 18. 11. 25 20:26, Dmitry Torokhov wrote:
> Hi Michal,
> 
> On Wed, Nov 12, 2025 at 02:00:19PM +0100, Michal Vokáč wrote:
>> The Pixcir Tango controller has support for a one-time total calibration
>> (manual calibration) procedure. Its purpose is to measure the capacitance
>> offsets of the electrode system and to store these values into EEPROM.
>>
>> During normal operation this calibration data is subtracted from the values
>> measured. This calibration should be necessary only once in the product
>> lifetime. It should be performed as part of the final adjustment after
>> the panel is mounted in the product.
>>
>> Add support for the calibration with sysfs interface.
>>
>> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
>> ---
>>   drivers/input/touchscreen/pixcir_i2c_ts.c | 34 +++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index dad5786e82a4..2215e56b1458 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -24,6 +24,7 @@
>>    */
>>   #define PIXCIR_REG_POWER_MODE	51
>>   #define PIXCIR_REG_INT_MODE	52
>> +#define PIXCIR_REG_SPECOP	58
>>   
>>   /*
>>    * Power modes:
>> @@ -82,6 +83,7 @@ struct pixcir_i2c_ts_data {
>>   	const struct pixcir_i2c_chip_data *chip;
>>   	struct touchscreen_properties prop;
>>   	bool running;
>> +	struct mutex sysfs_mutex;
>>   };
>>   
>>   struct pixcir_report_data {
>> @@ -462,6 +464,35 @@ static int pixcir_i2c_ts_resume(struct device *dev)
>>   static DEFINE_SIMPLE_DEV_PM_OPS(pixcir_dev_pm_ops,
>>   				pixcir_i2c_ts_suspend, pixcir_i2c_ts_resume);
>>   
>> +static ssize_t calibrate_store(struct device *dev,
>> +			       struct device_attribute *attr,
>> +			       const char *buf, size_t count)
>> +{
>> +	struct i2c_client *client = to_i2c_client(dev);
>> +	struct pixcir_i2c_ts_data *ts = i2c_get_clientdata(client);
>> +	static const u8 cmd = 0x03;
>> +	int error;
>> +
>> +	error = mutex_lock_interruptible(&ts->sysfs_mutex);
>> +	if (error)
>> +		return error;
> 
> Why do we need this mutex? i2c_smbus_write_byte_data() does take adapter
> lock, why do we need this additional locking?

Honestly I was not sure about usefulness of the lock.
I originally have not it there when the patch was in our downstream tree.
When I was rewriting it for mainline I realized there are other touchscreen
drivers that already have this calibration feature implemented and that
they have the lock in place. See raydium_i2c_ts.c or elants_i2c.c.
So I got inspired and used it as well for the case I missed something.

Now after a second look at the mentioned drivers I see that these also
have a sysfs interface for FW update. So it make sense to use the lock
to assure the whole fw transfer is finished before someone else can
access the device.

That is not our case. The mutex can safely be removed. I will send v2.

Thank you,
Michal




      reply	other threads:[~2025-11-19 10:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12 13:00 [PATCH] Input: pixcir_i2c_ts - add support for one-time total calibration Michal Vokáč
2025-11-18 19:26 ` Dmitry Torokhov
2025-11-19 10:23   ` Michal Vokáč [this message]

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=0e5eb4c0-bc63-4ca7-9ba2-985afa237d67@ysoft.com \
    --to=michal.vokac@ysoft.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=festevam@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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: 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).