Re: Fwd: Hid over I2C and ACPI interaction

[Zhang Rui]

> -------- Original Message --------
> Subject: Hid over I2C and ACPI interaction
> Date: Wed, 4 Jul 2012 15:46:35 +0200
> From: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxx>
> To: Jean Delvare <khali@xxxxxxxxxxxx>, Ben Dooks <ben-linux@xxxxxxxxx>, Wolfram 
> Sang <w.sang@xxxxxxxxxxxxxx>, Len Brown <lenb@xxxxxxxxxx>, 
> <linux-acpi@xxxxxxxxxxxxxxx>, <linux-i2c@xxxxxxxxxxxxxxx>, 
> <linux-kernel@xxxxxxxxxxxxxxx>
> CC: Jiri Kosina <jkosina@xxxxxxx>, StÃphane Chatty <chatty@xxxxxxx>, JJ Ding 
> <jj_ding@xxxxxxxxxx>
> 
> Hi Guys,
> 
> I'm the co-author and the maintainer of the hid-multitouch driver. To
> support even more devices, I started the implementation of the HID
> over I2C protocol specification which is introduced by Win8. I'm quite
> comfortable with the hid and the I2C part, but I'm blocked with the
> interaction with the ACPI for the pnp part.
> 
> I wanted to have your advice/help on this problem. I've add in the
> recipients list the maintainers of i2c and ACPI, sorry for the noise
> if you don't feel concerned about this.
> 
> So, let's go deeper in the problem ;-)
> Microsoft's spec asks the OEM to fill the ACPI DSDT to provide the
> following scope in the ASL layout:
> 
> >>>>>>>>> begin of ASL
> Scope (\_SB) {
> //--------------------
> //  General Purpose I/O, ports 0...127
> //--------------------
> 
> Device(HIDI2C_DEVICE1) {
>      Name(_ADR,0)
>      Name (_HID, "MSFT1234â)
>      Name (_CID, "PNP0C50")
>      Name (_UID, 3)
> 
>      Method(_CRS, 0x0, NotSerialized)
>      {
>          Name (RBUF, ResourceTemplate ()
>          {
>          // Address 0x07 on I2C-X (OEM selects this address)
>         //IHV SPECIFIC I2C3 = I2C Controller; TGD0 = GPIO Controller;
>          I2CSerialBus (0x07, ControllerInitiated,
> 100000,AddressingMode7Bit, "\\_SB.I2C3",,,,)
>          GpioInt(Level, ActiveLow, Exclusive, PullUp, 0, "\\_SB. TGD0",
> 0 , ResourceConsumer, , ) {40}
>          })
>       Return(RBUF)
>       }
> 
>       Method(_DSM, 0x4, NotSerialized)
>       {
>          // BreakPoint
>          Store ("Method _DSM begin", Debug)
> 
>          // DSM UUID
>          switch(ToBuffer(Arg0))
>          {		
>              // ACPI DSM UUID for HIDI2C
>              case(ToUUID("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
>              {
>                   // DSM function which returns the HID Descriptor
> Address (skipped)
>              }
> 
>              default
>              {
>                  // No other GUIDs supported
>                  Return(Buffer(One) { 0x00 })
>              }
>          }
>      }
> }
> <<<<<<<<< end of ASL
> 
yep, this is an ACPI enumerated I2C controller.

> Summary:
> - a HID over I2C device has to present the Compatibility ID "PNP0C50"
> - in the _CRS block, the address, the adapter and the gpioInt are
> defined (or referenced)
> - it presents a Device Specific Method (_DSM) which returns the HID
> Descriptor register address. This register is our entry point for
> retrieving the information about our hid device (so it's mandatory to
> obtain it).
> 
> Where am I:
> - I've written a first layer on top of i2c that retrieves the hid
> register (currently the address 0x0001 is hardcoded), then get the
> report desccriptors and the input events, and forward all this stuff
> to the hid layer.
> - It's working with a custom emulated HID over i2c touchpad, while
> waiting for the one a manufacturer should send to me.
> - The detection and the addition to the adapter is done by adding the
> address in the lists and the name through the i2c "->detect" callback
> (which is not very good, because I don't have the interrupt line
> there).
> - I've written a first acpi implementation that rely on the
> DEVICE_ACPI_HANDLE macro to get the ACPI handle of the device (if
> available).
> - I'm not able to do some tests with the ACPI, as I don't know how to
> implement this DSDT on my computer (I'm missing the I2C part), and the
> manufacturer returned the mainboard with the right DSDT to the OEM.
> 
> My questions:
> - will the current acpi implementation handle I2C devices?

you still need to write your own device driver for the device.

> - it seems to me that the .archdata field is left blank during the i2c
> device initialization in all paths I've seen. Is that true?
> - who puts the name int the struct i2c_board_info? (for hot-plugged
> i2c devices).
> 
> - finally, what is the best way of handling ACPI for those I2C devices:
>    1) everything is fine, I should have the ACPI handle in .archdata.
>    2) someone has to implement the handling of I2C in the pnpACPI layer
> (by adding I2CSerialBus handling and creating there the i2c slave).
>    3) I should create an acpi driver which handles "PNP0C50" and which
> creates the i2c slaves.
> 
exactly.

As this I2C controller uses the GPIO interrupt, we need an ACPI GPIO
controller driver for interrupts first.
I already have such a patch in hand, but have not release it for some
reason.
Second, you need to write your own PNP I2C controller driver, to
enumerate the I2C controller via ACPI, AND enumerate the I2C slave
devices under this controller to I2C bus. I also have a similar driver
for SPI controller and SD/MMC controller.
Third, you need a I2C slave device driver to handle the I2C slave device
in I2C bus.

here is a BKM I wrote, hope it helps.

And also any comments are welcome. :)