Add simple fw_version file in debugfs to read the value from 0xa6
which is the firmware version.
Signed-off-by: Martin Kepplinger <[email protected]>
---
Since we got at least 2 different FT firmware version in our controller,
we need to distinguish them.
thanks,
martin
drivers/input/touchscreen/edt-ft5x06.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index bc7fb2c005b5..efb09bba739a 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -51,6 +51,8 @@
#define EV_REGISTER_OFFSET_Y 0x45
#define EV_REGISTER_OFFSET_X 0x46
+#define REG_FW_VERSION 0xa6
+
#define NO_REGISTER 0xff
#define WORK_REGISTER_OPMODE 0x3c
@@ -685,6 +687,22 @@ static int edt_ft5x06_debugfs_mode_set(void *data, u64 mode)
DEFINE_SIMPLE_ATTRIBUTE(debugfs_mode_fops, edt_ft5x06_debugfs_mode_get,
edt_ft5x06_debugfs_mode_set, "%llu\n");
+static int edt_ft5x06_debugfs_fw_version_get(void *data, u64 *version)
+{
+ struct edt_ft5x06_ts_data *tsdata = data;
+ struct i2c_client *client = tsdata->client;
+
+ *version = edt_ft5x06_register_read(tsdata, REG_FW_VERSION);
+ if (*version == 0xff || *version == 0x00)
+ dev_dbg(&client->dev, "failed to get firmware version\n");
+
+ return 0;
+};
+
+DEFINE_SIMPLE_ATTRIBUTE(debugfs_fw_version_fops,
+ edt_ft5x06_debugfs_fw_version_get,
+ NULL, "%llu\n");
+
static ssize_t edt_ft5x06_debugfs_raw_data_read(struct file *file,
char __user *buf, size_t count, loff_t *off)
{
@@ -779,6 +797,9 @@ edt_ft5x06_ts_prepare_debugfs(struct edt_ft5x06_ts_data *tsdata,
debugfs_create_file("mode", S_IRUSR | S_IWUSR,
tsdata->debug_dir, tsdata, &debugfs_mode_fops);
+ debugfs_create_file("fw_version", S_IRUSR,
+ tsdata->debug_dir, tsdata,
+ &debugfs_fw_version_fops);
debugfs_create_file("raw_data", S_IRUSR,
tsdata->debug_dir, tsdata, &debugfs_raw_data_fops);
}
--
2.20.1
On Mon, Mar 16, 2020 at 03:27:56PM +0100, Martin Kepplinger wrote:
> Add simple fw_version file in debugfs to read the value from 0xa6
> which is the firmware version.
If you switch to regmap I?C API you will get this for free for all defined
registers.
So, I highly recommend to consider above.
--
With Best Regards,
Andy Shevchenko
On 16.03.20 15:40, Andy Shevchenko wrote:
> On Mon, Mar 16, 2020 at 03:27:56PM +0100, Martin Kepplinger wrote:
>> Add simple fw_version file in debugfs to read the value from 0xa6
>> which is the firmware version.
>
>
> If you switch to regmap I²C API you will get this for free for all defined
> registers.
>
> So, I highly recommend to consider above.
>
I don't know all the devices and modes well enough if the current raw
read/write buffers always translate to (only) buf[0] being the register
address.
If you tell me I can assume just that, I'm happy to do a larger change
that completely does aways with the current raw buffers.
Otherwise:
Does is make sense to *add* just a few regmap calls but keep the current
i2c_transfer in place for the calls I'm not sure about? I could do that
in any case.
thanks!
martin
On Tue, Mar 17, 2020 at 11:25:39AM +0100, Martin Kepplinger wrote:
> On 16.03.20 15:40, Andy Shevchenko wrote:
> > On Mon, Mar 16, 2020 at 03:27:56PM +0100, Martin Kepplinger wrote:
> >> Add simple fw_version file in debugfs to read the value from 0xa6
> >> which is the firmware version.
> >
> >
> > If you switch to regmap I?C API you will get this for free for all defined
> > registers.
> >
> > So, I highly recommend to consider above.
> >
>
> I don't know all the devices and modes well enough if the current raw
> read/write buffers always translate to (only) buf[0] being the register
> address.
>
> If you tell me I can assume just that, I'm happy to do a larger change
> that completely does aways with the current raw buffers.
I have only one device at hand, so, I can't tell for all neither.
Maybe Dmitry has an opinion on this?
> Otherwise:
>
> Does is make sense to *add* just a few regmap calls but keep the current
> i2c_transfer in place for the calls I'm not sure about? I could do that
> in any case.
I think it's way to the opposite direction, i.e. increasing burden
(for maintainability) and technical debt.
--
With Best Regards,
Andy Shevchenko