Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1474917 > unrolled thread

Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752 Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-09-02 08:50 +0200
    RE: [PATCH] Input: wdt87xx_i2c - support new body WDT8752 Hn Chen <hn.chen@weidahitech.com> - 2016-09-05 09:40 +0200
      Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752 Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-09-05 16:00 +0200
        RE: [PATCH] Input: wdt87xx_i2c - support new body WDT8752 Hn Chen <hn.chen@weidahitech.com> - 2016-09-06 13:50 +0200

#1474917 — Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752

Hi HN,

On Wed, Aug 3, 2016 at 3:16 AM, HungNien Chen <hn.chen@weidahitech.com> wrote:
>
> Considering to be compatible with i2c-hid, WDT8752 has the same way in
> enumerating device.

If it is a HID device then I think you should write a HID driver for
it (unless existing driver, such as hid-multitouch can already handle
it, possibly with some changes). I'm addng Benjamin to he can comment
as well.

> And also modify the part of FW update to be more
> efficiency. The main modification is that reducing the amount of data
> transmitted and using polling for time comsuming operation.
>
> Flash erase will wait 50ms for the operation complete in last driver.
> Extend it to 200ms since the spec says the typical is 30ms but the max
> is 200ms.

This should be split into a separate patch please.

Thanks.

-- 
Dmitry

[toc] | [next] | [standalone]

#1476160

Hi Dmitry,

>> Considering to be compatible with i2c-hid, WDT8752 has the same way in 
>> enumerating device.
>If it is a HID device then I think you should write a HID driver for it (unless existing driver, such as hid-multitouch can already handle it, possibly >with some changes). I'm addng Benjamin to he can comment as well.
The device can be handled by i2c-hid driver (HID over I2C) already but this proprietary driver still is a must-have for more features.

>> And also modify the part of FW update to be more efficiency. The main 
>> modification is that reducing the amount of data transmitted and using 
>> polling for time comsuming operation.
>>
>> Flash erase will wait 50ms for the operation complete in last driver.
>> Extend it to 200ms since the spec says the typical is 30ms but the max 
>> is 200ms.
>This should be split into a separate patch please.
Ok, I will resubmit the part of possible-issue fixing and then the driver patch for supporting WDT8752 again.
Please ignore this submission.

Hn.chen

[toc] | [prev] | [next] | [standalone]

#1476474

Hi HN,

On Sep 05 2016 or thereabouts, Hn Chen wrote:
> Hi Dmitry,
> 
> >> Considering to be compatible with i2c-hid, WDT8752 has the same way in 
> >> enumerating device.
> >If it is a HID device then I think you should write a HID driver for it (unless existing driver, such as hid-multitouch can already handle it, possibly >with some changes). I'm addng Benjamin to he can comment as well.
> The device can be handled by i2c-hid driver (HID over I2C) already but this proprietary driver still is a must-have for more features.

Then what are those must-have features? From what I can read, only the
reflashing firmware is part of it. Unless there is something else, I
really don't understand why you can't have a hid-weidatech driver that
could handle the specific bits while leaving the rest to i2c-hid.

Also, I am not sure if your driver doesn't interfere with i2c-hid as you
are claiming the device through the ACPI ID "WDHT0001" but there should
be some PNP IDs "PNP0C50" if it were declared as i2c-hid. If both are
set, then the fact your driver is picked up seems to be pure luck: there
will be a race between the probe of your driver and i2c-hid, which is
not something you want.

If there are some issues with i2c-hid, I'd like also to know them
because if we fix them for you there  is a high chance other vendors
will benefit from those fixes too.

Cheers,
Benjamin

> 
> >> And also modify the part of FW update to be more efficiency. The main 
> >> modification is that reducing the amount of data transmitted and using 
> >> polling for time comsuming operation.
> >>
> >> Flash erase will wait 50ms for the operation complete in last driver.
> >> Extend it to 200ms since the spec says the typical is 30ms but the max 
> >> is 200ms.
> >This should be split into a separate patch please.
> Ok, I will resubmit the part of possible-issue fixing and then the driver patch for supporting WDT8752 again.
> Please ignore this submission.
> 
> Hn.chen

[toc] | [prev] | [next] | [standalone]

#1477296

Hi Benjamin,

Sorry for my poor English and leading you misunderstanding.

The FW of WDT8752 can support HIDI2C for Windows products. And then we develop this driver.
So we "borrowed" something from HIDI2C.
What I try to mention here is that this driver utilize a part of existed protocol from HIDI2C.
We thought that the size of FW can be shrunk in that way.

So, basically, this is still a linux i2c driver with some protocols similar to HIDI2C.

BR,
Hn.chen

-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] 
Sent: Monday, September 05, 2016 9:56 PM
To: Hn Chen
Cc: Dmitry Torokhov; linux-input@vger.kernel.org; lkml
Subject: Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752

Hi HN,

On Sep 05 2016 or thereabouts, Hn Chen wrote:
> Hi Dmitry,
> 
> >> Considering to be compatible with i2c-hid, WDT8752 has the same way 
> >> in enumerating device.
> >If it is a HID device then I think you should write a HID driver for it (unless existing driver, such as hid-multitouch can already handle it, possibly >with some changes). I'm addng Benjamin to he can comment as well.
> The device can be handled by i2c-hid driver (HID over I2C) already but this proprietary driver still is a must-have for more features.

Then what are those must-have features? From what I can read, only the reflashing firmware is part of it. Unless there is something else, I really don't understand why you can't have a hid-weidatech driver that could handle the specific bits while leaving the rest to i2c-hid.

Also, I am not sure if your driver doesn't interfere with i2c-hid as you are claiming the device through the ACPI ID "WDHT0001" but there should be some PNP IDs "PNP0C50" if it were declared as i2c-hid. If both are set, then the fact your driver is picked up seems to be pure luck: there will be a race between the probe of your driver and i2c-hid, which is not something you want.

If there are some issues with i2c-hid, I'd like also to know them because if we fix them for you there  is a high chance other vendors will benefit from those fixes too.

Cheers,
Benjamin

> 
> >> And also modify the part of FW update to be more efficiency. The 
> >> main modification is that reducing the amount of data transmitted 
> >> and using polling for time comsuming operation.
> >>
> >> Flash erase will wait 50ms for the operation complete in last driver.
> >> Extend it to 200ms since the spec says the typical is 30ms but the 
> >> max is 200ms.
> >This should be split into a separate patch please.
> Ok, I will resubmit the part of possible-issue fixing and then the driver patch for supporting WDT8752 again.
> Please ignore this submission.
> 
> Hn.chen

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web