leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid

Browse Source 
Pull HID updates from Jiri Kosina:

 - AMD SFH (Sensor Fusion Hub) support (Sandeep Singh)

 - increase of maximum HID report size to 16KB in order to support some
   of the modern devices (Dean Camera)

 - control interface support for hidraw (Dean Camera)

 - Sony DS4 power and firmware reporting fixes (Roderick Colenbrander)

 - support for ghlive PS3/WII U dongles (Pascal Giard)

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: (27 commits)
  HID: i2c-hid: add Vero K147 to descriptor override
  HID: ite: Add support for Acer S1002 keyboard-dock
  HID: sony: support for ghlive ps3/wii u dongles
  HID: hidraw: Add additional hidraw input/output report ioctls.
  HID: Increase HID maximum report size to 16KB
  HID: elecom: drop stray comment
  HID: mf: add support for 0079:1846 Mayflash/Dragonrise USB Gamecube Adapter
  HID: elecom: add support for EX-G M-XGL20DLBK wireless mouse
  HID: elecom: rewrite report based on model specific parameters
  HID: wacom: Constify attribute_groups
  HID: input: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: logitech-hidpp: Add hid_device_id for V470 bluetooth mouse
  HID: intel-ish-hid: Remove unnecessary assignment to variable rv
  HID: sony: Workaround for DS4 dongle hotplug kernel crash.
  HID: sony: Don't use fw_version/hw_version for sysfs cleanup.
  HID: sony: Report more accurate DS4 power status.
  SFH: fix error return check for -ERESTARTSYS
  HID: SFH: Add documentation
  HID: hid-input: occasionally report stylus battery even if not changed
  ...
This commit is contained in:
Linus Torvalds
2020-12-16 15:44:44 -08:00
parent 62746f92b1 85a694738f
commit de925e2fbb
34 changed files with 2360 additions and 95 deletions
Download Patch File Download Diff File Expand all files Collapse all files

145
Documentation/hid/amd-sfh-hid.rst Normal file
View File

@@ -0,0 +1,145 @@
.. SPDX-License-Identifier: GPL-2.0
AMD Sensor Fusion Hub
=====================
AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen based platforms.
The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus.
In terms of architecture it resembles ISH, however the major difference is all
the HID reports are generated as part of the kernel driver.
1. Block Diagram
================
::
---------------------------------
| HID User Space Applications |
- -------------------------------
---------------------------------------------
---------------------------------
| HID Core |
---------------------------------
---------------------------------
| AMD HID Transport |
---------------------------------
--------------------------------
| AMD HID Client |
| with HID Report Generator|
--------------------------------
--------------------------------
| AMD MP2 PCIe Driver |
--------------------------------
OS
---------------------------------------------
Hardware + Firmware
--------------------------------
| SFH MP2 Processor |
--------------------------------
AMD HID Transport Layer
-----------------------
AMD SFH transport is also implemented as a bus. Each client application executing in the AMD MP2 is
registered as a device on this bus. Here: MP2 which is an ARM core connected to x86 for processing
sensor data. The layer, which binds each device (AMD SFH HID driver) identifies the device type and
registers with the hid core. Transport layer attach a constant "struct hid_ll_driver" object with
each device. Once a device is registered with HID core, the callbacks provided via this struct are
used by HID core to communicate with the device. AMD HID Transport layer implements the synchronous calls.
AMD HID Client Layer
--------------------
This layer is responsible to implement HID request and descriptors. As firmware is OS agnostic, HID
client layer fills the HID request structure and descriptors. HID client layer is complex as it is
interface between MP2 PCIe layer and HID. HID client layer initialized the MP2 PCIe layer and holds
the instance of MP2 layer. It identifies the number of sensors connected using MP2-PCIe layer. Base
on that allocates the DRAM address for each and every sensor and pass it to MP2-PCIe driver.On
enumeration of each the sensor, client layer fills the HID Descriptor structure and HID input repor
structure. HID Feature report structure is optional. The report descriptor structure varies from
sensor to sensor.
AMD MP2 PCIe layer
------------------
MP2 PCIe Layer is responsible for making all transactions with the firmware over PCIe.
The connection establishment between firmware and PCIe happens here.
The communication between X86 and MP2 is split into three parts.
1. Command transfer via the C2P mailbox registers.
2. Data transfer via DRAM.
3. Supported sensor info via P2C registers.
Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message registers generate
interrupt to MP2. The client layer allocates the physical memory and the same is sent to MP2 via
the PCI layer. MP2 firmware writes the command output to the access DRAM memory which the client
layer has allocated. Firmware always writes minimum of 32 bytes into DRAM. So as a protocol driver
shall allocate minimum of 32 bytes DRAM space.
Enumeration and Probing flow
----------------------------
::
HID AMD AMD AMD -PCIe MP2
Core Transport Client layer layer FW
| | | | |
| | | on Boot Driver Loaded |
| | | | |
| | | MP2-PCIe Int |
| | | | |
| | |---Get Number of sensors-> | |
| | | Read P2C |
| | | Register |
| | | | |
| | | Loop(for No of Sensors) | |
| | |----------------------| | |
| | | Create HID Descriptor| | |
| | | Create Input report | | |
| | | Descriptor Map | | |
| | | the MP2 FW Index to | | |
| | | HID Index | | |
| | | Allocate the DRAM | Enable |
| | | address | Sensors |
| | |----------------------| | |
| | HID transport| | Enable |
| |<--Probe------| |---Sensor CMD--> |
| | Create the | | |
| | HID device | | |
| | (MFD) | | |
| | by Populating| | |
| | the HID | | |
| | ll_driver | | |
| HID | | | |
| add | | | |
|Device | | | |
|<------------- | | | |
Data Flow from Application to the AMD SFH Driver
------------------------------------------------
::
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
|HID_req | | | |
|get_report | | | |
|------------->| | | |
| | HID_get_input| | |
| | report | | |
| |------------->|------------------------| | |
| | | Read the DRAM data for| | |
| | | requested sensor and | | |
| | | create the HID input | | |
| | | report | | |
| | |------------------------| | |
| |Data received | | |
| | in HID report| | |
To |<-------------|<-------------| | |
Applications| | | | |
<-------| | | | |

45
Documentation/hid/hidraw.rst
View File

@@ -123,8 +123,49 @@ HIDIOCGFEATURE(len):
This ioctl will request a feature report from the device using the control
endpoint. The first byte of the supplied buffer should be set to the report
number of the requested report. For devices which do not use numbered
reports, set the first byte to 0. The report will be returned starting at
the first byte of the buffer (ie: the report number is not returned).
reports, set the first byte to 0. The returned report buffer will contain the
report number in the first byte, followed by the report data read from the
device. For devices which do not use numbered reports, the report data will
begin at the first byte of the returned buffer.
HIDIOCSINPUT(len):
Send an Input Report
This ioctl will send an input report to the device, using the control endpoint.
In most cases, setting an input HID report on a device is meaningless and has
no effect, but some devices may choose to use this to set or reset an initial
state of a report. The format of the buffer issued with this report is identical
to that of HIDIOCSFEATURE.
HIDIOCGINPUT(len):
Get an Input Report
This ioctl will request an input report from the device using the control
endpoint. This is slower on most devices where a dedicated In endpoint exists
for regular input reports, but allows the host to request the value of a
specific report number. Typically, this is used to request the initial states of
an input report of a device, before an application listens for normal reports via
the regular device read() interface. The format of the buffer issued with this report
is identical to that of HIDIOCGFEATURE.
HIDIOCSOUTPUT(len):
Send an Output Report
This ioctl will send an output report to the device, using the control endpoint.
This is slower on most devices where a dedicated Out endpoint exists for regular
output reports, but is added for completeness. Typically, this is used to set
the initial states of an output report of a device, before an application sends
updates via the regular device write() interface. The format of the buffer issued
with this report is identical to that of HIDIOCSFEATURE.
HIDIOCGOUTPUT(len):
Get an Output Report
This ioctl will request an output report from the device using the control
endpoint. Typically, this is used to retrive the initial state of
an output report of a device, before an application updates it as necessary either
via a HIDIOCSOUTPUT request, or the regular device write() interface. The format
of the buffer issued with this report is identical to that of HIDIOCGFEATURE.
Example
-------

1
Documentation/hid/index.rst
View File

@@ -16,3 +16,4 @@ Human Interface Devices (HID)
hid-alps
intel-ish-hid
amd-sfh-hid