On 9/17/19 5:28 AM, Dmitry Torokhov wrote: > On Fri, Aug 23, 2019 at 12:34:29PM +0200, Marek Vasut wrote: >> On 8/11/19 6:42 PM, Dmitry Torokhov wrote: >>> On Sat, Aug 10, 2019 at 11:30:29PM +0200, Marek Vasut wrote: >>>> On 8/10/19 9:05 PM, Dmitry Torokhov wrote: >>>>> On Sat, Aug 10, 2019 at 08:00:14PM +0200, Marek Vasut wrote: >>>>>> On 8/10/19 7:44 PM, Dmitry Torokhov wrote: >>>>>>> On Sat, Aug 10, 2019 at 06:50:08PM +0200, Marek Vasut wrote: >>>>>>>> On 8/10/19 6:41 PM, Dmitry Torokhov wrote: >>>>>>>>> Hi Marek, >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>> On Sat, Mar 02, 2019 at 03:17:04PM +0100, Marek Vasut wrote: >>>>>>>>>> Add support for ILI2117 touch controller. This controller is similar >>>>>>>>>> to the ILI210x and ILI251x, except for the following differences: >>>>>>>>>> - Reading out of touch data must happen at most 300 mS after the >>>>>>>>>> interrupt line was asserted. No command must be sent, the data >>>>>>>>>> are returned upon pure I2C read of 43 bytes long. >>>>>>>>>> - Supports 10 simultaneous touch inputs. >>>>>>>>>> - Touch data format is slightly different. >>>>>>>>> >>>>>>>>> So with this and also I see there is another ili2117a submission, I do >>>>>>>>> believe that we need to switch to using function pointers instead of >>>>>>>>> if/else if/else style cheking of the model. >>>>>>>> >>>>>>>> How about we add tested functionality in first and only then do bigger >>>>>>>> untested changes ? I think that would work better for everyone. >>>>>>> >>>>>>> Sorry, I would really prefer to do what is right and build additional >>>>>>> functionality on top of the good foundation. I asked to switch to the >>>>>>> function pointers before, but you did not want to citing performance >>>>>>> (even though we are using function pointers everywhere in the kernel), >>>>>>> now I gave a draft implementation, I hope you can use it. >>>>>> >>>>>> So why can't we add tested code in first and then add new huge untested >>>>>> patch on top and start testing it ? I think doing it in reverse is >>>>>> actually not helpful, if there is a problem in this massive new patch, >>>>>> it could be reverted without losing functionality. >>>>> >>>>> We still have 4 weeks till merge window + stabilization time past it. >>>> >>>> Sure, but this patch was posted 5 months ago and was in real world >>>> deployment since, so it has 5 months of practical testing. I don't want >>>> to throw that away. >>>> >>>> The patch you want me to test can easily be rebased on the ILI2117 >>>> support and then we retain those months of testing, which I think is >>>> much better. >>> >>> OK, fine, I rebased the patch[es] on top of this one and uploaded to: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git iili2xxx-touchscreen >>> >>> Please give it a try and if it works I'll merge into next. >> >> Sorry for the delay. >> >> I had to revert >> Input: ili210x - define and use chip operations structure >> as with ^ I get no events. > > Any more details? Does the driver bind to the device? Is there data > coming form the wire and it is being consumed but not parsed properly? > Something else? The driver bound, there were just no data coming out of the /dev/input/event device at all. But if I reverted this patch "Input: ili210x - define and use chip operations structure", then I was getting data again. So that patch is likely wrong.
