* [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
@ 2017-04-27 12:22 ` Martin Kepplinger
0 siblings, 0 replies; 13+ messages in thread
From: Martin Kepplinger @ 2017-04-27 12:22 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Martin Kepplinger
The device could as well be in command mode, in which this driver cannot
handle the device. When opening the device, let's make sure the device
will be in the mode we expect it to be for this driver.
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
drivers/input/touchscreen/ar1021_i2c.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
index 1a94d8b..2a76231 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -18,6 +18,12 @@
#define AR1021_MAX_X 4095
#define AR1021_MAX_Y 4095
+#define AR1021_CMD 0x55
+#define AR1021_TOUCH 0x80
+
+#define AR1021_CMD_ENABLE_TOUCH 0x12
+#define AR1021_CMD_DISABLE_TOUCH 0x13
+
struct ar1021_i2c {
struct i2c_client *client;
struct input_dev *input;
@@ -58,6 +64,15 @@ static int ar1021_i2c_open(struct input_dev *dev)
{
struct ar1021_i2c *ar1021 = input_get_drvdata(dev);
struct i2c_client *client = ar1021->client;
+ int error;
+ u8 cmd_enable_touch[3] = {AR1021_CMD,
+ 0x01, /* number of bytes after this */
+ AR1021_CMD_ENABLE_TOUCH };
+
+ error = i2c_master_send(ar1021->client, cmd_enable_touch,
+ sizeof(cmd_enable_touch));
+ if (error < 0)
+ return error;
enable_irq(client->irq);
--
2.1.4
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2] input: touchscreen: ar1021_i2c: replace magic number with definition
2017-04-27 12:22 ` Martin Kepplinger
@ 2017-04-27 12:22 ` Martin Kepplinger
-1 siblings, 0 replies; 13+ messages in thread
From: Martin Kepplinger @ 2017-04-27 12:22 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Martin Kepplinger
We now have a few of this device's definitions. Let's avoid magic numbers
and use them.
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
drivers/input/touchscreen/ar1021_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
index 2a76231..edd5268 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -44,7 +44,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
goto out;
/* sync bit set ? */
- if ((data[0] & 0x80) == 0)
+ if ((data[0] & AR1021_TOUCH) == 0)
goto out;
button = data[0] & BIT(0);
--
2.1.4
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2] input: touchscreen: ar1021_i2c: replace magic number with definition
@ 2017-04-27 12:22 ` Martin Kepplinger
0 siblings, 0 replies; 13+ messages in thread
From: Martin Kepplinger @ 2017-04-27 12:22 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Martin Kepplinger
We now have a few of this device's definitions. Let's avoid magic numbers
and use them.
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
drivers/input/touchscreen/ar1021_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
index 2a76231..edd5268 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -44,7 +44,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
goto out;
/* sync bit set ? */
- if ((data[0] & 0x80) == 0)
+ if ((data[0] & AR1021_TOUCH) == 0)
goto out;
button = data[0] & BIT(0);
--
2.1.4
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] input: touchscreen: ar1021_i2c: replace magic number with definition
2017-04-27 12:22 ` Martin Kepplinger
(?)
@ 2017-04-28 17:06 ` Dmitry Torokhov
-1 siblings, 0 replies; 13+ messages in thread
From: Dmitry Torokhov @ 2017-04-28 17:06 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: linux-input, linux-kernel
On Thu, Apr 27, 2017 at 02:22:36PM +0200, Martin Kepplinger wrote:
> We now have a few of this device's definitions. Let's avoid magic numbers
> and use them.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
> ---
> drivers/input/touchscreen/ar1021_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
> index 2a76231..edd5268 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -44,7 +44,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
> goto out;
>
> /* sync bit set ? */
> - if ((data[0] & 0x80) == 0)
> + if ((data[0] & AR1021_TOUCH) == 0)
I'd rather have it as "(data & BIT(7))". This constant does not provide
any better meaning than number 0x80. At least the latter shows that we
test the MSB or the first byte, while the former obfuscates it.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/2 v2] input: touchscreen: ar1021_i2c: use BIT to check for a bit
2017-04-27 12:22 ` Martin Kepplinger
(?)
(?)
@ 2017-04-30 19:38 ` Martin Kepplinger
2017-05-01 19:39 ` Dmitry Torokhov
-1 siblings, 1 reply; 13+ messages in thread
From: Martin Kepplinger @ 2017-04-30 19:38 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Martin Kepplinger
The MSB for the first byte of touch data transmission is always 1. Make
it a little more obvious we're testing this bit by using BIT(7).
Signed-off-by: Martin Kepplinger <martink@posteo.de>
---
I'd still use the definition :) but otherwise I'd write the following.
It really doesn't matter though.
thanks for the quick support Dmitry,
martin
drivers/input/touchscreen/ar1021_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
index eb1874fe52c2..8c76aa435903 100644
--- a/drivers/input/touchscreen/ar1021_i2c.c
+++ b/drivers/input/touchscreen/ar1021_i2c.c
@@ -44,7 +44,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
goto out;
/* sync bit set ? */
- if ((data[0] & 0x80) == 0)
+ if (!(data[0] & BIT(7)))
goto out;
button = data[0] & BIT(0);
--
2.11.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 v2] input: touchscreen: ar1021_i2c: use BIT to check for a bit
2017-04-30 19:38 ` [PATCH 2/2 v2] input: touchscreen: ar1021_i2c: use BIT to check for a bit Martin Kepplinger
@ 2017-05-01 19:39 ` Dmitry Torokhov
0 siblings, 0 replies; 13+ messages in thread
From: Dmitry Torokhov @ 2017-05-01 19:39 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: linux-input, linux-kernel
On Sun, Apr 30, 2017 at 09:38:53PM +0200, Martin Kepplinger wrote:
> The MSB for the first byte of touch data transmission is always 1. Make
> it a little more obvious we're testing this bit by using BIT(7).
>
> Signed-off-by: Martin Kepplinger <martink@posteo.de>
Applied, thank you.
> ---
>
> I'd still use the definition :) but otherwise I'd write the following.
> It really doesn't matter though.
>
> thanks for the quick support Dmitry,
>
> martin
>
>
> drivers/input/touchscreen/ar1021_i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
> index eb1874fe52c2..8c76aa435903 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -44,7 +44,7 @@ static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
> goto out;
>
> /* sync bit set ? */
> - if ((data[0] & 0x80) == 0)
> + if (!(data[0] & BIT(7)))
> goto out;
>
> button = data[0] & BIT(0);
> --
> 2.11.0
>
--
Dmitry
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
2017-04-27 12:22 ` Martin Kepplinger
(?)
(?)
@ 2017-04-28 17:02 ` Dmitry Torokhov
-1 siblings, 0 replies; 13+ messages in thread
From: Dmitry Torokhov @ 2017-04-28 17:02 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: linux-input, linux-kernel
On Thu, Apr 27, 2017 at 02:22:35PM +0200, Martin Kepplinger wrote:
> The device could as well be in command mode, in which this driver cannot
> handle the device. When opening the device, let's make sure the device
> will be in the mode we expect it to be for this driver.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
> ---
> drivers/input/touchscreen/ar1021_i2c.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
> index 1a94d8b..2a76231 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -18,6 +18,12 @@
> #define AR1021_MAX_X 4095
> #define AR1021_MAX_Y 4095
>
> +#define AR1021_CMD 0x55
> +#define AR1021_TOUCH 0x80
> +
> +#define AR1021_CMD_ENABLE_TOUCH 0x12
> +#define AR1021_CMD_DISABLE_TOUCH 0x13
> +
> struct ar1021_i2c {
> struct i2c_client *client;
> struct input_dev *input;
> @@ -58,6 +64,15 @@ static int ar1021_i2c_open(struct input_dev *dev)
> {
> struct ar1021_i2c *ar1021 = input_get_drvdata(dev);
> struct i2c_client *client = ar1021->client;
> + int error;
> + u8 cmd_enable_touch[3] = {AR1021_CMD,
> + 0x01, /* number of bytes after this */
> + AR1021_CMD_ENABLE_TOUCH };
Changed to static const and applied, thank you.
> +
> + error = i2c_master_send(ar1021->client, cmd_enable_touch,
> + sizeof(cmd_enable_touch));
> + if (error < 0)
> + return error;
>
> enable_irq(client->irq);
>
> --
> 2.1.4
>
--
Dmitry
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
2017-04-27 12:22 ` Martin Kepplinger
` (2 preceding siblings ...)
(?)
@ 2018-02-05 10:07 ` Christian Gmeiner
2018-02-05 10:40 ` Martin Kepplinger
2018-02-06 1:20 ` Dmitry Torokhov
-1 siblings, 2 replies; 13+ messages in thread
From: Christian Gmeiner @ 2018-02-05 10:07 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: Dmitry Torokhov, linux-input, LKML
Hi all.
2017-04-27 14:22 GMT+02:00 Martin Kepplinger <martin.kepplinger@ginzinger.com>:
> The device could as well be in command mode, in which this driver cannot
> handle the device. When opening the device, let's make sure the device
> will be in the mode we expect it to be for this driver.
>
I run into issues caused by this change. It turns out that the device
is non-functional
after some warm-reboots and as a result I am not able to use xorg's
evdev driver.
So I have some questions about this change:
* Should we enable irq before calling i2c_master_send(..) as the chip raises an
irq if the command was processed?
* Would it be enough to send this command only once during driver
lifetime? I can
see that on my system open gets called 3 times during boot-up.
* What are the circumstances the touch device would be in an other state? In the
official kernel driver the userspace can send commands via sysfs.
Also the driver
does set the touch enable mode as this patch does.
> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
> ---
> drivers/input/touchscreen/ar1021_i2c.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
> index 1a94d8b..2a76231 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -18,6 +18,12 @@
> #define AR1021_MAX_X 4095
> #define AR1021_MAX_Y 4095
>
> +#define AR1021_CMD 0x55
> +#define AR1021_TOUCH 0x80
> +
> +#define AR1021_CMD_ENABLE_TOUCH 0x12
> +#define AR1021_CMD_DISABLE_TOUCH 0x13
> +
> struct ar1021_i2c {
> struct i2c_client *client;
> struct input_dev *input;
> @@ -58,6 +64,15 @@ static int ar1021_i2c_open(struct input_dev *dev)
> {
> struct ar1021_i2c *ar1021 = input_get_drvdata(dev);
> struct i2c_client *client = ar1021->client;
> + int error;
> + u8 cmd_enable_touch[3] = {AR1021_CMD,
> + 0x01, /* number of bytes after this */
> + AR1021_CMD_ENABLE_TOUCH };
> +
> + error = i2c_master_send(ar1021->client, cmd_enable_touch,
> + sizeof(cmd_enable_touch));
> + if (error < 0)
> + return error;
>
> enable_irq(client->irq);
>
> --
> 2.1.4
>
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
2018-02-05 10:07 ` Christian Gmeiner
@ 2018-02-05 10:40 ` Martin Kepplinger
2018-02-16 16:38 ` Christian Gmeiner
2018-02-06 1:20 ` Dmitry Torokhov
1 sibling, 1 reply; 13+ messages in thread
From: Martin Kepplinger @ 2018-02-05 10:40 UTC (permalink / raw)
To: Christian Gmeiner; +Cc: Dmitry Torokhov, linux-input, LKML
Martin Kepplinger | Entwicklung Software
GINZINGER ELECTRONIC SYSTEMS GMBH
Tel.: +43 7723 5422 157
Mail: martin.kepplinger@ginzinger.com
Web: www.ginzinger.com
On 2018-02-05 11:07, Christian Gmeiner wrote:
> Hi all.
>
> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger <martin.kepplinger@ginzinger.com>:
>> The device could as well be in command mode, in which this driver cannot
>> handle the device. When opening the device, let's make sure the device
>> will be in the mode we expect it to be for this driver.
>>
>
> I run into issues caused by this change. It turns out that the device
> is non-functional
> after some warm-reboots and as a result I am not able to use xorg's
> evdev driver.
> So I have some questions about this change:
>
> * Should we enable irq before calling i2c_master_send(..) as the chip raises an
> irq if the command was processed?
>
> * Would it be enough to send this command only once during driver
> lifetime? I can
> see that on my system open gets called 3 times during boot-up.
It would. See below for my thought on this change.
>
> * What are the circumstances the touch device would be in an other state? In the
> official kernel driver the userspace can send commands via sysfs.
> Also the driver
> does set the touch enable mode as this patch does.
I did this change as the device was once non-functional unexpectedly
because it wasn't in touch mode. We can set touch mode during open() or
probe() but I figured during open() would keep the driver working even
when others would use the device in command mode.
Does your problem go away when you revert this change or put it into
probe()?
martin
________________________________________
Ginzinger electronic systems GmbH
Gewerbegebiet Pirath 16
4952 Weng im Innkreis
www.ginzinger.com
Firmenbuchnummer: FN 364958d
Firmenbuchgericht: Ried im Innkreis
UID-Nr.: ATU66521089
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
2018-02-05 10:40 ` Martin Kepplinger
@ 2018-02-16 16:38 ` Christian Gmeiner
0 siblings, 0 replies; 13+ messages in thread
From: Christian Gmeiner @ 2018-02-16 16:38 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: Dmitry Torokhov, linux-input, LKML
2018-02-05 11:40 GMT+01:00 Martin Kepplinger <martin.kepplinger@ginzinger.com>:
>
>
>
>
> Martin Kepplinger | Entwicklung Software
>
> GINZINGER ELECTRONIC SYSTEMS GMBH
>
> Tel.: +43 7723 5422 157
> Mail: martin.kepplinger@ginzinger.com
> Web: www.ginzinger.com
>
>
>
>
> On 2018-02-05 11:07, Christian Gmeiner wrote:
>> Hi all.
>>
>> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger <martin.kepplinger@ginzinger.com>:
>>> The device could as well be in command mode, in which this driver cannot
>>> handle the device. When opening the device, let's make sure the device
>>> will be in the mode we expect it to be for this driver.
>>>
>>
>> I run into issues caused by this change. It turns out that the device
>> is non-functional
>> after some warm-reboots and as a result I am not able to use xorg's
>> evdev driver.
>> So I have some questions about this change:
>>
>> * Should we enable irq before calling i2c_master_send(..) as the chip raises an
>> irq if the command was processed?
>>
>> * Would it be enough to send this command only once during driver
>> lifetime? I can
>> see that on my system open gets called 3 times during boot-up.
>
> It would. See below for my thought on this change.
>
>>
>> * What are the circumstances the touch device would be in an other state? In the
>> official kernel driver the userspace can send commands via sysfs.
>> Also the driver
>> does set the touch enable mode as this patch does.
>
> I did this change as the device was once non-functional unexpectedly
> because it wasn't in touch mode. We can set touch mode during open() or
> probe() but I figured during open() would keep the driver working even
> when others would use the device in command mode.
>
> Does your problem go away when you revert this change or put it into
> probe()?
I needed to postprone further research and reverted this commit locally as
a new software release gets releases soon. The good this that I have
an automated way to run a test to trigger this issue quite easily.
Will have a deeper look after release time.
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
2018-02-05 10:07 ` Christian Gmeiner
2018-02-05 10:40 ` Martin Kepplinger
@ 2018-02-06 1:20 ` Dmitry Torokhov
2018-02-16 16:46 ` Christian Gmeiner
1 sibling, 1 reply; 13+ messages in thread
From: Dmitry Torokhov @ 2018-02-06 1:20 UTC (permalink / raw)
To: Christian Gmeiner; +Cc: Martin Kepplinger, linux-input, LKML
On Mon, Feb 05, 2018 at 11:07:08AM +0100, Christian Gmeiner wrote:
> Hi all.
>
> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger <martin.kepplinger@ginzinger.com>:
> > The device could as well be in command mode, in which this driver cannot
> > handle the device. When opening the device, let's make sure the device
> > will be in the mode we expect it to be for this driver.
> >
>
> I run into issues caused by this change. It turns out that the device
> is non-functional
> after some warm-reboots and as a result I am not able to use xorg's
> evdev driver.
> So I have some questions about this change:
>
> * Should we enable irq before calling i2c_master_send(..) as the chip raises an
> irq if the command was processed?
Well, we do not care about the response... However, what is your
interrupt trigger settings? Are you using edge by chance? If so, please
try switching to level.
>
> * Would it be enough to send this command only once during driver
> lifetime? I can
> see that on my system open gets called 3 times during boot-up.
>
> * What are the circumstances the touch device would be in an other state? In the
> official kernel driver the userspace can send commands via sysfs.
> Also the driver
> does set the touch enable mode as this patch does.
What is "the official kernel driver"?
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
2018-02-06 1:20 ` Dmitry Torokhov
@ 2018-02-16 16:46 ` Christian Gmeiner
0 siblings, 0 replies; 13+ messages in thread
From: Christian Gmeiner @ 2018-02-16 16:46 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Martin Kepplinger, linux-input, LKML
2018-02-06 2:20 GMT+01:00 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Mon, Feb 05, 2018 at 11:07:08AM +0100, Christian Gmeiner wrote:
>> Hi all.
>>
>> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger <martin.kepplinger@ginzinger.com>:
>> > The device could as well be in command mode, in which this driver cannot
>> > handle the device. When opening the device, let's make sure the device
>> > will be in the mode we expect it to be for this driver.
>> >
>>
>> I run into issues caused by this change. It turns out that the device
>> is non-functional
>> after some warm-reboots and as a result I am not able to use xorg's
>> evdev driver.
>> So I have some questions about this change:
>>
>> * Should we enable irq before calling i2c_master_send(..) as the chip raises an
>> irq if the command was processed?
>
> Well, we do not care about the response... However, what is your
> interrupt trigger settings? Are you using edge by chance? If so, please
> try switching to level.
>
We may should take care of the response. I have seen strange responses
after the third open of the device.
&i2c2 {
ar1021@4d {
compatible = "microchip,ar1021-i2c";
reg = <0x4d>;
interrupt-parent = <&gpio3>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
};
};
I am not sure if this is really the cause of the problem! As without this commit
my device survives one week of a automated touch-press-test done with some
mechanical gear and with the help of an SPS.
>>
>> * Would it be enough to send this command only once during driver
>> lifetime? I can
>> see that on my system open gets called 3 times during boot-up.
>>
>> * What are the circumstances the touch device would be in an other state? In the
>> official kernel driver the userspace can send commands via sysfs.
>> Also the driver
>> does set the touch enable mode as this patch does.
>
> What is "the official kernel driver"?
>
http://ww1.microchip.com/downloads/en/DeviceDoc/AR1020-AR1021-LINUX-SPI-I2C-V102.tar.gz
As it is release time at my company I had to stop finding the root
cause but will look into the issue
again in 2-3 weeks.
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
^ permalink raw reply [flat|nested] 13+ messages in thread