lkml.org 
[lkml]   [2012]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectHid over I2C and ACPI interaction
    From
    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

    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?
    - 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.

    The thing is that I'm not very comfortable with solutions 2 and 3
    (i2c_new_device tells that it must not be called during
    arch_initcall(), how can I get the adapter, shall I blacklist in
    pnpacpi "PNP0C50" ...), so gentlemen, I'm waiting for your advice.

    Many thanks,
    Benjamin
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-07-04 16:21    [W:0.030 / U:62.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site