2018-02-05 11:40 GMT+01:00 Martin Kepplinger <martin.kepplinger@xxxxxxxxxxxxx>: > > > > > Martin Kepplinger | Entwicklung Software > > GINZINGER ELECTRONIC SYSTEMS GMBH > > Tel.: +43 7723 5422 157 > Mail: martin.kepplinger@xxxxxxxxxxxxx > 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@xxxxxxxxxxxxx>: >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
