* [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature
@ 2024-05-06 1:30 Zhang Lixu
2024-05-06 1:30 ` [PATCH 1/5] Documentation: hid: intel-ish-hid: remove section numbering Zhang Lixu
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: Zhang Lixu @ 2024-05-06 1:30 UTC (permalink / raw
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
This patch series is comprised of 5 patches. The first two patches are to add documentation
for firmware loading. The third and fourth patches introduce support for the 'Load Main
Firmware from Host' feature in the ISHTP driver, applicable to Lunar Lake and subsequent
platforms. The last patch enhances the firmware reset handler in the ISH driver. This
addresses an issue where the driver receives two MNG_RESET_NOTIFY messages upon implementing
the 'Load Main Firmware from Host' feature.
This patch series is based on the following 3 commits, which have already been included in the linux-next/master branch.
- HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc
- HID: intel-ish-hid: Use PCI_VDEVICE() and rename device ID macros
- HID: intel-ish-hid: ipc: Add Lunar Lake-M PCI device ID
Qianru Huang (2):
Documentation: hid: intel-ish-hid: remove section numbering
Documentation: hid: intel-ish-hid: add section for firmware loading
Zhang Lixu (3):
HID: intel-ish-hid: Add driver_data for specifying the firmware
filename
HID: intel-ish-hid: Implement loading firmware from host feature
HID: intel-ish-hid: handler multiple MNG_RESET_NOTIFY messages
Documentation/hid/intel-ish-hid.rst | 137 +++++++---
drivers/hid/intel-ish-hid/Makefile | 1 +
drivers/hid/intel-ish-hid/ipc/ipc.c | 7 +-
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 18 +-
drivers/hid/intel-ish-hid/ishtp/hbm.c | 21 ++
drivers/hid/intel-ish-hid/ishtp/init.c | 8 +
drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h | 28 ++
drivers/hid/intel-ish-hid/ishtp/loader.c | 275 ++++++++++++++++++++
drivers/hid/intel-ish-hid/ishtp/loader.h | 226 ++++++++++++++++
9 files changed, 681 insertions(+), 40 deletions(-)
create mode 100644 drivers/hid/intel-ish-hid/ishtp/loader.c
create mode 100644 drivers/hid/intel-ish-hid/ishtp/loader.h
base-commit: 9221b2819b8a4196eecf5476d66201be60fbcf29
--
2.34.1
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/5] Documentation: hid: intel-ish-hid: remove section numbering
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
@ 2024-05-06 1:30 ` Zhang Lixu
2024-05-06 1:30 ` [PATCH 2/5] Documentation: hid: intel-ish-hid: add section for firmware loading Zhang Lixu
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Zhang Lixu @ 2024-05-06 1:30 UTC (permalink / raw
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
From: Qianru Huang <qianru.huang@intel.com>
Remove section numbering from the Intel Integrated Sensor Hub (ISH)
documentation to simplify the structure, making it easier to maintain
and update in the future.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Qianru Huang <qianru.huang@intel.com>
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
Documentation/hid/intel-ish-hid.rst | 72 ++++++++++++++---------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 42dc77b7b10f..12613cb2be43 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -18,8 +18,8 @@ These ISH also comply to HID sensor specification, but the difference is the
transport protocol used for communication. The current external sensor hubs
mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
-1. Overview
-===========
+Overview
+========
Using a analogy with a usbhid implementation, the ISH follows a similar model
for a very high speed communication::
@@ -58,8 +58,8 @@ implemented as a bus. Each client application executing in the ISH processor
is registered as a device on this bus. The driver, which binds each device
(ISH HID driver) identifies the device type and registers with the HID core.
-2. ISH Implementation: Block Diagram
-====================================
+ISH Implementation: Block Diagram
+=================================
::
@@ -96,27 +96,27 @@ is registered as a device on this bus. The driver, which binds each device
| ISH Hardware/Firmware(FW) |
----------------------------
-3. High level processing in above blocks
-========================================
+High level processing in above blocks
+=====================================
-3.1 Hardware Interface
-----------------------
+Hardware Interface
+------------------
The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI
product and vendor IDs are changed from different generations of processors. So
the source code which enumerates drivers needs to update from generation to
generation.
-3.2 Inter Processor Communication (IPC) driver
-----------------------------------------------
+Inter Processor Communication (IPC) driver
+------------------------------------------
Location: drivers/hid/intel-ish-hid/ipc
The IPC message uses memory mapped I/O. The registers are defined in
hw-ish-regs.h.
-3.2.1 IPC/FW message types
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+IPC/FW message types
+^^^^^^^^^^^^^^^^^^^^
There are two types of messages, one for management of link and another for
messages to and from transport layers.
@@ -142,20 +142,20 @@ register has the following format::
Bit 31: doorbell trigger (signal H/W interrupt to the other side)
Other bits are reserved, should be 0.
-3.2.2 Transport layer interface
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Transport layer interface
+^^^^^^^^^^^^^^^^^^^^^^^^^
To abstract HW level IPC communication, a set of callbacks is registered.
The transport layer uses them to send and receive messages.
Refer to struct ishtp_hw_ops for callbacks.
-3.3 ISH Transport layer
------------------------
+ISH Transport layer
+-------------------
Location: drivers/hid/intel-ish-hid/ishtp/
-3.3.1 A Generic Transport Layer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A Generic Transport Layer
+^^^^^^^^^^^^^^^^^^^^^^^^^
The transport layer is a bi-directional protocol, which defines:
- Set of commands to start, stop, connect, disconnect and flow control
@@ -166,8 +166,8 @@ This protocol resembles bus messages described in the following document:
http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer"
-3.3.2 Connection and Flow Control Mechanism
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Connection and Flow Control Mechanism
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Each FW client and a protocol is identified by a UUID. In order to communicate
to a FW client, a connection must be established using connect request and
@@ -181,8 +181,8 @@ before receiving the next flow control credit.
Either side can send disconnect request bus message to end communication. Also
the link will be dropped if major FW reset occurs.
-3.3.3 Peer to Peer data transfer
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Peer to Peer data transfer
+^^^^^^^^^^^^^^^^^^^^^^^^^^
Peer to Peer data transfer can happen with or without using DMA. Depending on
the sensor bandwidth requirement DMA can be enabled by using module parameter
@@ -217,8 +217,8 @@ In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once
Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC
fragments and via IPC otherwise.
-3.3.4 Ring Buffers
-^^^^^^^^^^^^^^^^^^
+Ring Buffers
+^^^^^^^^^^^^
When a client initiates a connection, a ring of RX and TX buffers is allocated.
The size of ring can be specified by the client. HID client sets 16 and 32 for
@@ -228,8 +228,8 @@ bus message protocol. These buffers are required because the FW may have not
have processed the last message and may not have enough flow control credits
to send. Same thing holds true on receive side and flow control is required.
-3.3.5 Host Enumeration
-^^^^^^^^^^^^^^^^^^^^^^
+Host Enumeration
+^^^^^^^^^^^^^^^^
The host enumeration bus command allows discovery of clients present in the FW.
There can be multiple sensor clients and clients for calibration function.
@@ -252,8 +252,8 @@ Enumeration sequence of messages:
- Once host received properties for that last discovered client, it considers
ISHTP device fully functional (and allocates DMA buffers)
-3.4 HID over ISH Client
------------------------
+HID over ISH Client
+-------------------
Location: drivers/hid/intel-ish-hid
@@ -265,16 +265,16 @@ The ISHTP client driver is responsible for:
- Process Get/Set feature request
- Get input reports
-3.5 HID Sensor Hub MFD and IIO sensor drivers
----------------------------------------------
+HID Sensor Hub MFD and IIO sensor drivers
+-----------------------------------------
The functionality in these drivers is the same as an external sensor hub.
Refer to
Documentation/hid/hid-sensor.rst for HID sensor
Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space.
-3.6 End to End HID transport Sequence Diagram
----------------------------------------------
+End to End HID transport Sequence Diagram
+-----------------------------------------
::
@@ -339,16 +339,16 @@ Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space.
| | | |
-3.7 ISH Debugging
------------------
+ISH Debugging
+-------------
To debug ISH, event tracing mechanism is used. To enable debug logs::
echo 1 > /sys/kernel/tracing/events/intel_ish/enable
cat /sys/kernel/tracing/trace
-3.8 ISH IIO sysfs Example on Lenovo thinkpad Yoga 260
------------------------------------------------------
+ISH IIO sysfs Example on Lenovo thinkpad Yoga 260
+-------------------------------------------------
::
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/5] Documentation: hid: intel-ish-hid: add section for firmware loading
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
2024-05-06 1:30 ` [PATCH 1/5] Documentation: hid: intel-ish-hid: remove section numbering Zhang Lixu
@ 2024-05-06 1:30 ` Zhang Lixu
2024-05-06 1:30 ` [PATCH 3/5] HID: intel-ish-hid: Add driver_data for specifying the firmware filename Zhang Lixu
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Zhang Lixu @ 2024-05-06 1:30 UTC (permalink / raw
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
From: Qianru Huang <qianru.huang@intel.com>
Add a section to describe the ISH firmware loading process for Lunar Lake
and later generations.
Signed-off-by: Qianru Huang <qianru.huang@intel.com>
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
Documentation/hid/intel-ish-hid.rst | 65 +++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 12613cb2be43..55cbaa719a79 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -339,6 +339,71 @@ End to End HID transport Sequence Diagram
| | | |
+ISH Firmware Loading from Host Flow
+-----------------------------------
+
+Starting from the Lunar Lake generation, the ISH firmware has been divided into two components for better space optimization and increased flexibility. These components include a bootloader that is integrated into the BIOS, and a main firmware that is stored within the operating system's file system.
+
+The process works as follows:
+
+- Initially, the ISHTP driver sends a command, HOST_START_REQ_CMD, to the ISH bootloader. In response, the bootloader sends back a HOST_START_RES_CMD. This response includes the ISHTP_SUPPORT_CAP_LOADER bit. Subsequently, the ISHTP driver checks if this bit is set. If it is, the firmware loading process from the host begins.
+
+- During this process, the ISHTP driver first invokes the request_firmware() function, followed by sending a LOADER_CMD_XFER_QUERY command. Upon receiving a response from the bootloader, the ISHTP driver sends a LOADER_CMD_XFER_FRAGMENT command. After receiving another response, the ISHTP driver sends a LOADER_CMD_START command. The bootloader responds and then proceeds to the Main Firmware.
+
+- After the process concludes, the ISHTP driver calls the release_firmware() function.
+
+For more detailed information, please refer to the flow descriptions provided below:
+
+::
+
+ +---------------+ +-----------------+
+ | ISHTP Driver | | ISH Bootloader |
+ +---------------+ +-----------------+
+ | |
+ |~~~Send HOST_START_REQ_CMD~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send HOST_START_RES_CMD(Includes ISHTP_SUPPORT_CAP_LOADER bit)----|
+ | |
+ ****************************************************************************************
+ * if ISHTP_SUPPORT_CAP_LOADER bit is set *
+ ****************************************************************************************
+ | |
+ |~~~start loading firmware from host process~~~+ |
+ | | |
+ |<---------------------------------------------+ |
+ | |
+ --------------------------- |
+ | Call request_firmware() | |
+ --------------------------- |
+ | |
+ |~~~Send LOADER_CMD_XFER_QUERY~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send response-----------------------------------------------------|
+ | |
+ |~~~Send LOADER_CMD_XFER_FRAGMENT~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send response-----------------------------------------------------|
+ | |
+ |~~~Send LOADER_CMD_START~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
+ | |
+ |<--Send response-----------------------------------------------------|
+ | |
+ | |~~~Jump to Main Firmware~~~+
+ | | |
+ | |<--------------------------+
+ | |
+ --------------------------- |
+ | Call release_firmware() | |
+ --------------------------- |
+ | |
+ ****************************************************************************************
+ * end if *
+ ****************************************************************************************
+ | |
+ +---------------+ +-----------------+
+ | ISHTP Driver | | ISH Bootloader |
+ +---------------+ +-----------------+
+
ISH Debugging
-------------
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 3/5] HID: intel-ish-hid: Add driver_data for specifying the firmware filename
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
2024-05-06 1:30 ` [PATCH 1/5] Documentation: hid: intel-ish-hid: remove section numbering Zhang Lixu
2024-05-06 1:30 ` [PATCH 2/5] Documentation: hid: intel-ish-hid: add section for firmware loading Zhang Lixu
@ 2024-05-06 1:30 ` Zhang Lixu
2024-05-06 1:30 ` [PATCH 4/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Zhang Lixu @ 2024-05-06 1:30 UTC (permalink / raw
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
Introduces a new structure, ishtp_driver_data, to hold driver-specific
data, including the firmware filename for different hardware variants of
the Intel Integrated Sensor Hub (ISH).
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 18 +++++++++++++++++-
drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h | 17 +++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index e79d72f7db2a..d487227085b2 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -23,6 +23,19 @@
#include "ishtp-dev.h"
#include "hw-ish.h"
+enum ishtp_driver_data_index {
+ ISHTP_DRIVER_DATA_NONE,
+ ISHTP_DRIVER_DATA_LNL_M,
+};
+
+#define ISH_FW_FILENAME_LNL_M "intel/ish/ish_lnlm.bin"
+
+static struct ishtp_driver_data ishtp_driver_data[] = {
+ [ISHTP_DRIVER_DATA_LNL_M] = {
+ .fw_filename = ISH_FW_FILENAME_LNL_M,
+ },
+};
+
static const struct pci_device_id ish_pci_tbl[] = {
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_CHV)},
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_BXT_Ax)},
@@ -46,7 +59,7 @@ static const struct pci_device_id ish_pci_tbl[] = {
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_MTL_P)},
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_ARL_H)},
{PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_ARL_S)},
- {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_LNL_M)},
+ {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ISH_LNL_M), .driver_data = ISHTP_DRIVER_DATA_LNL_M},
{}
};
MODULE_DEVICE_TABLE(pci, ish_pci_tbl);
@@ -167,6 +180,7 @@ static int ish_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
hw = to_ish_hw(ishtp);
ishtp->print_log = ish_event_tracer;
+ ishtp->driver_data = &ishtp_driver_data[ent->driver_data];
/* mapping IO device memory */
hw->mem_addr = pcim_iomap_table(pdev)[0];
@@ -377,3 +391,5 @@ MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>");
MODULE_DESCRIPTION("Intel(R) Integrated Sensor Hub PCI Device Driver");
MODULE_LICENSE("GPL");
+
+MODULE_FIRMWARE(ISH_FW_FILENAME_LNL_M);
diff --git a/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h b/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
index 32142c7d9a04..ed294bf0bc8f 100644
--- a/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
+++ b/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
@@ -122,12 +122,29 @@ struct ishtp_hw_ops {
bool (*dma_no_cache_snooping)(struct ishtp_device *dev);
};
+/**
+ * struct ishtp_driver_data - Driver-specific data for ISHTP devices
+ *
+ * This structure holds driver-specific data that can be associated with each
+ * ISHTP device instance. It allows for the storage of data that is unique to
+ * a particular driver or hardware variant.
+ *
+ * @fw_filename: The firmware filename associated with a specific hardware
+ * variant of the Intel Integrated Sensor Hub (ISH). This allows
+ * the driver to load the correct firmware based on the device's
+ * hardware variant.
+ */
+struct ishtp_driver_data {
+ char *fw_filename;
+};
+
/**
* struct ishtp_device - ISHTP private device struct
*/
struct ishtp_device {
struct device *devc; /* pointer to lowest device */
struct pci_dev *pdev; /* PCI device to get device ids */
+ struct ishtp_driver_data *driver_data; /* pointer to driver-specific data */
/* waitq for waiting for suspend response */
wait_queue_head_t suspend_wait;
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 4/5] HID: intel-ish-hid: Implement loading firmware from host feature
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
` (2 preceding siblings ...)
2024-05-06 1:30 ` [PATCH 3/5] HID: intel-ish-hid: Add driver_data for specifying the firmware filename Zhang Lixu
@ 2024-05-06 1:30 ` Zhang Lixu
2024-05-06 1:30 ` [PATCH 5/5] HID: intel-ish-hid: handler multiple MNG_RESET_NOTIFY messages Zhang Lixu
2024-05-06 21:34 ` [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Jiri Kosina
5 siblings, 0 replies; 7+ messages in thread
From: Zhang Lixu @ 2024-05-06 1:30 UTC (permalink / raw
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
Starting from the Lunar Lake generation, the ISH firmware has been
divided into two components for better space optimization and increased
flexibility. These components include a bootloader that is integrated
into the BIOS, and a main firmware that is stored within the operating
system's file system.
Introduce support for loading ISH main firmware from host. This feature is
applicable for Lunar Lake and later generation.
Current intel-ishtp-loader, is designed for Chrome OS based systems which
uses core boot and has different firmware loading method. For non chrome
systems the ISH firmware loading uses different method.
Key differences include:
1. The new method utilizes ISHTP capability/fixed client to enumerate the
firmware loader function. It does not require a connection or flow control,
unlike the method used in Chrome OS, which is enumerated as an ISHTP
dynamic client driver, necessitating connect/disconnect operations and flow
control.
2. The new method employs a table to describe firmware fragments, which are
sent to ISH in a single operation. Conversely, the Chrome OS method sends
firmware fragments in multiple operations within a loop, sending only one
fragment at a time.
Additionally, address potential error scenarios to ensure graceful failure
handling.
- Firmware Not Found: Triggers if request_firmware() fails, leaving ISH in
a waiting state.
Recovery: Re-insmod the ISH drivers to retry.
- DMA Buffer Allocation Failure: Occurs during prepare_dma_bufs(), leading
to ISH waiting state. Allocated resources are released.
Recovery: Re-insmod the ISH drivers to retry.
- Incorrect Firmware Image: Causes ISH to refuse loading after three failed
attempts.
Recovery: A platform reset is required.
Please refer to the [Documentation](Documentation/hid/intel-ish-hid.rst)
for the details on flows.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/Makefile | 1 +
drivers/hid/intel-ish-hid/ishtp/hbm.c | 21 ++
drivers/hid/intel-ish-hid/ishtp/init.c | 8 +
drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h | 11 +
drivers/hid/intel-ish-hid/ishtp/loader.c | 275 ++++++++++++++++++++
drivers/hid/intel-ish-hid/ishtp/loader.h | 226 ++++++++++++++++
6 files changed, 542 insertions(+)
create mode 100644 drivers/hid/intel-ish-hid/ishtp/loader.c
create mode 100644 drivers/hid/intel-ish-hid/ishtp/loader.h
diff --git a/drivers/hid/intel-ish-hid/Makefile b/drivers/hid/intel-ish-hid/Makefile
index f0a82b1c7cb9..a927b224cd44 100644
--- a/drivers/hid/intel-ish-hid/Makefile
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -11,6 +11,7 @@ intel-ishtp-objs += ishtp/client.o
intel-ishtp-objs += ishtp/bus.o
intel-ishtp-objs += ishtp/dma-if.o
intel-ishtp-objs += ishtp/client-buffers.o
+intel-ishtp-objs += ishtp/loader.o
obj-$(CONFIG_INTEL_ISH_HID) += intel-ish-ipc.o
intel-ish-ipc-objs := ipc/ipc.o
diff --git a/drivers/hid/intel-ish-hid/ishtp/hbm.c b/drivers/hid/intel-ish-hid/ishtp/hbm.c
index 9c031a06e4c4..8ee5467127d8 100644
--- a/drivers/hid/intel-ish-hid/ishtp/hbm.c
+++ b/drivers/hid/intel-ish-hid/ishtp/hbm.c
@@ -13,6 +13,7 @@
#include "ishtp-dev.h"
#include "hbm.h"
#include "client.h"
+#include "loader.h"
/**
* ishtp_hbm_fw_cl_allocate() - Allocate FW clients
@@ -570,6 +571,10 @@ void ishtp_hbm_dispatch(struct ishtp_device *dev,
return;
}
+ /* Start firmware loading process if it has loader capability */
+ if (version_res->host_version_supported & ISHTP_SUPPORT_CAP_LOADER)
+ schedule_work(&dev->work_fw_loader);
+
dev->version.major_version = HBM_MAJOR_VERSION;
dev->version.minor_version = HBM_MINOR_VERSION;
if (dev->dev_state == ISHTP_DEV_INIT_CLIENTS &&
@@ -864,6 +869,20 @@ void recv_hbm(struct ishtp_device *dev, struct ishtp_msg_hdr *ishtp_hdr)
return;
}
+/**
+ * ishtp_loader_recv_msg() - Receive a message from the ISHTP device
+ * @dev: The ISHTP device
+ * @buf: The buffer containing the message
+ */
+static void ishtp_loader_recv_msg(struct ishtp_device *dev, void *buf)
+{
+ if (dev->fw_loader_rx_buf)
+ memcpy(dev->fw_loader_rx_buf, buf, dev->fw_loader_rx_size);
+
+ dev->fw_loader_received = true;
+ wake_up_interruptible(&dev->wait_loader_recvd_msg);
+}
+
/**
* recv_fixed_cl_msg() - Receive fixed client message
* @dev: ISHTP device instance
@@ -890,6 +909,8 @@ void recv_fixed_cl_msg(struct ishtp_device *dev,
else
dev_err(dev->devc, "unknown fixed client msg [%02X]\n",
msg_hdr->cmd);
+ } else if (ishtp_hdr->fw_addr == ISHTP_LOADER_CLIENT_ADDR) {
+ ishtp_loader_recv_msg(dev, rd_msg_buf);
}
}
diff --git a/drivers/hid/intel-ish-hid/ishtp/init.c b/drivers/hid/intel-ish-hid/ishtp/init.c
index 02a00cc2dd11..07fdd52e4c5e 100644
--- a/drivers/hid/intel-ish-hid/ishtp/init.c
+++ b/drivers/hid/intel-ish-hid/ishtp/init.c
@@ -5,12 +5,14 @@
* Copyright (c) 2003-2016, Intel Corporation.
*/
+#include <linux/devm-helpers.h>
#include <linux/export.h>
#include <linux/slab.h>
#include <linux/sched.h>
#include "ishtp-dev.h"
#include "hbm.h"
#include "client.h"
+#include "loader.h"
/**
* ishtp_dev_state_str() -Convert to string format
@@ -51,6 +53,8 @@ const char *ishtp_dev_state_str(int state)
*/
void ishtp_device_init(struct ishtp_device *dev)
{
+ int ret;
+
dev->dev_state = ISHTP_DEV_INITIALIZING;
INIT_LIST_HEAD(&dev->cl_list);
INIT_LIST_HEAD(&dev->device_list);
@@ -59,6 +63,7 @@ void ishtp_device_init(struct ishtp_device *dev)
spin_lock_init(&dev->rd_msg_spinlock);
init_waitqueue_head(&dev->wait_hbm_recvd_msg);
+ init_waitqueue_head(&dev->wait_loader_recvd_msg);
spin_lock_init(&dev->read_list_spinlock);
spin_lock_init(&dev->device_lock);
spin_lock_init(&dev->device_list_lock);
@@ -76,6 +81,9 @@ void ishtp_device_init(struct ishtp_device *dev)
INIT_LIST_HEAD(&dev->read_list.list);
+ ret = devm_work_autocancel(dev->devc, &dev->work_fw_loader, ishtp_loader_work);
+ if (ret)
+ dev_err_probe(dev->devc, ret, "Failed to initialise FW loader work\n");
}
EXPORT_SYMBOL(ishtp_device_init);
diff --git a/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h b/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
index ed294bf0bc8f..181838c3d7ac 100644
--- a/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
+++ b/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
@@ -164,6 +164,17 @@ struct ishtp_device {
struct hbm_version version;
int transfer_path; /* Choice of transfer path: IPC or DMA */
+ /* work structure for scheduling firmware loading tasks */
+ struct work_struct work_fw_loader;
+ /* waitq for waiting for command response from the firmware loader */
+ wait_queue_head_t wait_loader_recvd_msg;
+ /* indicating whether a message from the firmware loader has been received */
+ bool fw_loader_received;
+ /* pointer to a buffer for receiving messages from the firmware loader */
+ void *fw_loader_rx_buf;
+ /* size of the buffer pointed to by fw_loader_rx_buf */
+ int fw_loader_rx_size;
+
/* ishtp device states */
enum ishtp_dev_state dev_state;
enum ishtp_hbm_state hbm_state;
diff --git a/drivers/hid/intel-ish-hid/ishtp/loader.c b/drivers/hid/intel-ish-hid/ishtp/loader.c
new file mode 100644
index 000000000000..993f8b390e57
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ishtp/loader.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ISHTP firmware loader function
+ *
+ * Copyright (c) 2024, Intel Corporation.
+ *
+ * This module implements the functionality to load the main ISH firmware from the host, starting
+ * with the Lunar Lake generation. It leverages a new method that enhances space optimization and
+ * flexibility by dividing the ISH firmware into a bootloader and main firmware.
+ *
+ * Please refer to the [Documentation](Documentation/hid/intel-ish-hid.rst) for the details on
+ * flows.
+ *
+ * Additionally, address potential error scenarios to ensure graceful failure handling.
+ * - Firmware Image Not Found:
+ * Occurs when `request_firmware()` cannot locate the firmware image. The ISH firmware will
+ * remain in a state awaiting firmware loading from the host, with no further action from
+ * the ISHTP driver.
+ * Recovery: Re-insmod the ISH drivers allows for a retry of the firmware loading from the host.
+ *
+ * - DMA Buffer Allocation Failure:
+ * This happens if allocating a DMA buffer during `prepare_dma_bufs()` fails. The ISH firmware
+ * will stay in a waiting state, and the ISHTP driver will release any allocated DMA buffers and
+ * firmware without further actions.
+ * Recovery: Re-insmod the ISH drivers allows for a retry of the firmware loading from the host.
+ *
+ * - Incorrect Firmware Image:
+ * Using an incorrect firmware image will initiate the firmware loading process but will
+ * eventually be refused by the ISH firmware after three unsuccessful attempts, indicated by
+ * returning an error code. The ISHTP driver will stop attempting after three tries.
+ * Recovery: A platform reset is required to retry firmware loading from the host.
+ */
+
+#define dev_fmt(fmt) "ISH loader: " fmt
+
+#include <linux/cacheflush.h>
+#include <linux/container_of.h>
+#include <linux/dev_printk.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
+#include <linux/firmware.h>
+#include <linux/gfp_types.h>
+#include <linux/math.h>
+#include <linux/module.h>
+#include <linux/pfn.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/wait.h>
+
+#include "hbm.h"
+#include "loader.h"
+
+/**
+ * loader_write_message() - Write a message to the ISHTP device
+ * @dev: The ISHTP device
+ * @buf: The buffer containing the message
+ * @len: The length of the message
+ *
+ * Return: 0 on success, negative error code on failure
+ */
+static int loader_write_message(struct ishtp_device *dev, void *buf, int len)
+{
+ struct ishtp_msg_hdr ishtp_hdr = {
+ .fw_addr = ISHTP_LOADER_CLIENT_ADDR,
+ .length = len,
+ .msg_complete = 1,
+ };
+
+ dev->fw_loader_received = false;
+
+ return ishtp_write_message(dev, &ishtp_hdr, buf);
+}
+
+/**
+ * loader_xfer_cmd() - Transfer a command to the ISHTP device
+ * @dev: The ISHTP device
+ * @req: The request buffer
+ * @req_len: The length of the request
+ * @resp: The response buffer
+ * @resp_len: The length of the response
+ *
+ * Return: 0 on success, negative error code on failure
+ */
+static int loader_xfer_cmd(struct ishtp_device *dev, void *req, int req_len,
+ void *resp, int resp_len)
+{
+ struct loader_msg_header *req_hdr = req;
+ struct loader_msg_header *resp_hdr = resp;
+ struct device *devc = dev->devc;
+ int rv;
+
+ dev->fw_loader_rx_buf = resp;
+ dev->fw_loader_rx_size = resp_len;
+
+ rv = loader_write_message(dev, req, req_len);
+ if (rv < 0) {
+ dev_err(devc, "write cmd %u failed:%d\n", req_hdr->command, rv);
+ return rv;
+ }
+
+ /* Wait the ACK */
+ wait_event_interruptible_timeout(dev->wait_loader_recvd_msg, dev->fw_loader_received,
+ ISHTP_LOADER_TIMEOUT);
+ dev->fw_loader_rx_size = 0;
+ dev->fw_loader_rx_buf = NULL;
+ if (!dev->fw_loader_received) {
+ dev_err(devc, "wait response of cmd %u timeout\n", req_hdr->command);
+ return -ETIMEDOUT;
+ }
+
+ if (!resp_hdr->is_response) {
+ dev_err(devc, "not a response for %u\n", req_hdr->command);
+ return -EBADMSG;
+ }
+
+ if (req_hdr->command != resp_hdr->command) {
+ dev_err(devc, "unexpected cmd response %u:%u\n", req_hdr->command,
+ resp_hdr->command);
+ return -EBADMSG;
+ }
+
+ if (resp_hdr->status) {
+ dev_err(devc, "cmd %u failed %u\n", req_hdr->command, resp_hdr->status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+/**
+ * release_dma_bufs() - Release the DMA buffer for transferring firmware fragments
+ * @dev: The ISHTP device
+ * @fragment: The ISHTP firmware fragment descriptor
+ * @dma_bufs: The array of DMA fragment buffers
+ * @fragment_size: The size of a single DMA fragment
+ */
+static void release_dma_bufs(struct ishtp_device *dev,
+ struct loader_xfer_dma_fragment *fragment,
+ void **dma_bufs, u32 fragment_size)
+{
+ int i;
+
+ for (i = 0; i < FRAGMENT_MAX_NUM; i++) {
+ if (dma_bufs[i]) {
+ dma_free_coherent(dev->devc, fragment_size, dma_bufs[i],
+ fragment->fragment_tbl[i].ddr_adrs);
+ dma_bufs[i] = NULL;
+ }
+ }
+}
+
+/**
+ * prepare_dma_bufs() - Prepare the DMA buffer for transferring firmware fragments
+ * @dev: The ISHTP device
+ * @ish_fw: The ISH firmware
+ * @fragment: The ISHTP firmware fragment descriptor
+ * @dma_bufs: The array of DMA fragment buffers
+ * @fragment_size: The size of a single DMA fragment
+ *
+ * Return: 0 on success, negative error code on failure
+ */
+static int prepare_dma_bufs(struct ishtp_device *dev,
+ const struct firmware *ish_fw,
+ struct loader_xfer_dma_fragment *fragment,
+ void **dma_bufs, u32 fragment_size)
+{
+ u32 offset = 0;
+ int i;
+
+ for (i = 0; i < fragment->fragment_cnt && offset < ish_fw->size; i++) {
+ dma_bufs[i] = dma_alloc_coherent(dev->devc, fragment_size,
+ &fragment->fragment_tbl[i].ddr_adrs, GFP_KERNEL);
+ if (!dma_bufs[i])
+ return -ENOMEM;
+
+ fragment->fragment_tbl[i].length = clamp(ish_fw->size - offset, 0, fragment_size);
+ fragment->fragment_tbl[i].fw_off = offset;
+ memcpy(dma_bufs[i], ish_fw->data + offset, fragment->fragment_tbl[i].length);
+ clflush_cache_range(dma_bufs[i], fragment_size);
+
+ offset += fragment->fragment_tbl[i].length;
+ }
+
+ return 0;
+}
+
+/**
+ * ishtp_loader_work() - Load the ISHTP firmware
+ * @work: The work structure
+ *
+ * The ISH Loader attempts to load firmware by sending a series of commands
+ * to the ISH device. If a command fails to be acknowledged by the ISH device,
+ * the loader will retry sending the command, up to a maximum of
+ * ISHTP_LOADER_RETRY_TIMES.
+ *
+ * After the maximum number of retries has been reached without success, the
+ * ISH bootloader will return an error status code and will no longer respond
+ * to the driver's commands. This behavior indicates that the ISH Loader has
+ * encountered a critical error during the firmware loading process.
+ *
+ * In such a case, where the ISH bootloader is unresponsive after all retries
+ * have been exhausted, a platform reset is required to restore communication
+ * with the ISH device and to recover from this error state.
+ */
+void ishtp_loader_work(struct work_struct *work)
+{
+ DEFINE_RAW_FLEX(struct loader_xfer_dma_fragment, fragment, fragment_tbl, FRAGMENT_MAX_NUM);
+ struct ishtp_device *dev = container_of(work, struct ishtp_device, work_fw_loader);
+ struct loader_xfer_query query = {
+ .header.command = LOADER_CMD_XFER_QUERY,
+ };
+ struct loader_start start = {
+ .header.command = LOADER_CMD_START,
+ };
+ union loader_recv_message recv_msg;
+ char *filename = dev->driver_data->fw_filename;
+ const struct firmware *ish_fw;
+ void *dma_bufs[FRAGMENT_MAX_NUM] = {};
+ u32 fragment_size;
+ int retry = ISHTP_LOADER_RETRY_TIMES;
+ int rv;
+
+ rv = request_firmware(&ish_fw, filename, dev->devc);
+ if (rv < 0) {
+ dev_err(dev->devc, "request firmware %s failed:%d\n", filename, rv);
+ return;
+ }
+
+ fragment->fragment.header.command = LOADER_CMD_XFER_FRAGMENT;
+ fragment->fragment.xfer_mode = LOADER_XFER_MODE_DMA;
+ fragment->fragment.is_last = 1;
+ fragment->fragment.size = ish_fw->size;
+ /* Calculate the size of a single DMA fragment */
+ fragment_size = PFN_ALIGN(DIV_ROUND_UP(ish_fw->size, FRAGMENT_MAX_NUM));
+ /* Calculate the count of DMA fragments */
+ fragment->fragment_cnt = DIV_ROUND_UP(ish_fw->size, fragment_size);
+
+ rv = prepare_dma_bufs(dev, ish_fw, fragment, dma_bufs, fragment_size);
+ if (rv) {
+ dev_err(dev->devc, "prepare DMA buffer failed.\n");
+ goto out;
+ }
+
+ do {
+ query.image_size = ish_fw->size;
+ rv = loader_xfer_cmd(dev, &query, sizeof(query), recv_msg.raw_data,
+ sizeof(struct loader_xfer_query_ack));
+ if (rv)
+ continue; /* try again if failed */
+
+ dev_dbg(dev->devc, "ISH Version %u.%u.%u.%u\n",
+ recv_msg.query_ack.version_major,
+ recv_msg.query_ack.version_minor,
+ recv_msg.query_ack.version_hotfix,
+ recv_msg.query_ack.version_build);
+
+ rv = loader_xfer_cmd(dev, fragment,
+ struct_size(fragment, fragment_tbl, fragment->fragment_cnt),
+ recv_msg.raw_data, sizeof(struct loader_xfer_fragment_ack));
+ if (rv)
+ continue; /* try again if failed */
+
+ rv = loader_xfer_cmd(dev, &start, sizeof(start), recv_msg.raw_data,
+ sizeof(struct loader_start_ack));
+ if (rv)
+ continue; /* try again if failed */
+
+ dev_info(dev->devc, "firmware loaded. size:%zu\n", ish_fw->size);
+ break;
+ } while (--retry);
+
+out:
+ release_dma_bufs(dev, fragment, dma_bufs, fragment_size);
+ release_firmware(ish_fw);
+}
diff --git a/drivers/hid/intel-ish-hid/ishtp/loader.h b/drivers/hid/intel-ish-hid/ishtp/loader.h
new file mode 100644
index 000000000000..7aa45ebc3f7b
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ishtp/loader.h
@@ -0,0 +1,226 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * ISHTP firmware loader header
+ *
+ * Copyright (c) 2024, Intel Corporation.
+ */
+
+#ifndef _ISHTP_LOADER_H_
+#define _ISHTP_LOADER_H_
+
+#include <linux/bits.h>
+#include <linux/jiffies.h>
+#include <linux/types.h>
+
+#include "ishtp-dev.h"
+
+struct work_struct;
+
+#define LOADER_MSG_SIZE \
+ (IPC_PAYLOAD_SIZE - sizeof(struct ishtp_msg_hdr))
+
+/*
+ * ISHTP firmware loader protocol definition
+ */
+#define LOADER_CMD_XFER_QUERY 0 /* SW -> FW */
+#define LOADER_CMD_XFER_FRAGMENT 1 /* SW -> FW */
+#define LOADER_CMD_START 2 /* SW -> FW */
+
+/* Only support DMA mode */
+#define LOADER_XFER_MODE_DMA BIT(0)
+
+/**
+ * struct loader_msg_header - ISHTP firmware loader message header
+ * @command: Command type
+ * @is_response: Indicates if the message is a response
+ * @has_next: Indicates if there is a next message
+ * @reserved: Reserved for future use
+ * @status: Status of the message
+ */
+struct loader_msg_header {
+ __le32 command:7;
+ __le32 is_response:1;
+ __le32 has_next:1;
+ __le32 reserved:15;
+ __le32 status:8;
+};
+
+/**
+ * struct loader_xfer_query - ISHTP firmware loader transfer query packet
+ * @header: Header of the message
+ * @image_size: Size of the image
+ */
+struct loader_xfer_query {
+ struct loader_msg_header header;
+ __le32 image_size;
+};
+
+/**
+ * struct loader_version - ISHTP firmware loader version
+ * @value: Value of the version
+ * @major: Major version
+ * @minor: Minor version
+ * @hotfix: Hotfix version
+ * @build: Build version
+ */
+struct loader_version {
+ union {
+ __le32 value;
+ struct {
+ __u8 major;
+ __u8 minor;
+ __u8 hotfix;
+ __u8 build;
+ };
+ };
+};
+
+/**
+ * struct loader_capability - ISHTP firmware loader capability
+ * @max_fw_image_size: Maximum firmware image size
+ * @support_mode: Support mode
+ * @reserved: Reserved for future use
+ * @platform: Platform
+ * @max_dma_buf_size: Maximum DMA buffer size, multiples of 4096
+ */
+struct loader_capability {
+ __le32 max_fw_image_size;
+ __le16 support_mode;
+ __u8 reserved;
+ __u8 platform;
+ __le32 max_dma_buf_size;
+};
+
+/**
+ * struct loader_xfer_query_ack - ISHTP firmware loader transfer query acknowledgment
+ * @header: Header of the message
+ * @version_major: ISH Major version
+ * @version_minor: ISH Minor version
+ * @version_hotfix: ISH Hotfix version
+ * @version_build: ISH Build version
+ * @protocol_version: Protocol version
+ * @loader_version: Loader version
+ * @capability: Loader capability
+ */
+struct loader_xfer_query_ack {
+ struct loader_msg_header header;
+ __le16 version_major;
+ __le16 version_minor;
+ __le16 version_hotfix;
+ __le16 version_build;
+ __le32 protocol_version;
+ struct loader_version loader_version;
+ struct loader_capability capability;
+};
+
+/**
+ * struct loader_xfer_fragment - ISHTP firmware loader transfer fragment
+ * @header: Header of the message
+ * @xfer_mode: Transfer mode
+ * @offset: Offset
+ * @size: Size
+ * @is_last: Is last
+ */
+struct loader_xfer_fragment {
+ struct loader_msg_header header;
+ __le32 xfer_mode;
+ __le32 offset;
+ __le32 size;
+ __le32 is_last;
+};
+
+/**
+ * struct loader_xfer_fragment_ack - ISHTP firmware loader transfer fragment acknowledgment
+ * @header: Header of the message
+ */
+struct loader_xfer_fragment_ack {
+ struct loader_msg_header header;
+};
+
+/**
+ * struct fragment_dscrpt - ISHTP firmware loader fragment descriptor
+ * @ddr_adrs: The address in host DDR
+ * @fw_off: The offset of the fragment in the fw image
+ * @length: The length of the fragment
+ */
+struct fragment_dscrpt {
+ __le64 ddr_adrs;
+ __le32 fw_off;
+ __le32 length;
+};
+
+#define FRAGMENT_MAX_NUM \
+ ((LOADER_MSG_SIZE - sizeof(struct loader_xfer_dma_fragment)) / \
+ sizeof(struct fragment_dscrpt))
+
+/**
+ * struct loader_xfer_dma_fragment - ISHTP firmware loader transfer DMA fragment
+ * @fragment: Fragment
+ * @fragment_cnt: How many descriptors in the fragment_tbl
+ * @fragment_tbl: Fragment table
+ */
+struct loader_xfer_dma_fragment {
+ struct loader_xfer_fragment fragment;
+ __le32 fragment_cnt;
+ struct fragment_dscrpt fragment_tbl[] __counted_by(fragment_cnt);
+};
+
+/**
+ * struct loader_start - ISHTP firmware loader start
+ * @header: Header of the message
+ */
+struct loader_start {
+ struct loader_msg_header header;
+};
+
+/**
+ * struct loader_start_ack - ISHTP firmware loader start acknowledgment
+ * @header: Header of the message
+ */
+struct loader_start_ack {
+ struct loader_msg_header header;
+};
+
+union loader_recv_message {
+ struct loader_xfer_query_ack query_ack;
+ struct loader_xfer_fragment_ack fragment_ack;
+ struct loader_start_ack start_ack;
+ __u8 raw_data[LOADER_MSG_SIZE];
+};
+
+/*
+ * ISHTP firmware loader internal use
+ */
+/* ISHTP firmware loader command timeout */
+#define ISHTP_LOADER_TIMEOUT msecs_to_jiffies(100)
+
+/* ISHTP firmware loader retry times */
+#define ISHTP_LOADER_RETRY_TIMES 3
+
+/**
+ * struct ish_firmware_variant - ISH firmware variant
+ * @device: PCI Device ID
+ * @filename: The firmware file name
+ */
+struct ish_firmware_variant {
+ unsigned short device;
+ const char *filename;
+};
+
+/*
+ * ISHTP firmware loader API for ISHTP hbm
+ */
+
+/* ISHTP capability bit for firmware loader */
+#define ISHTP_SUPPORT_CAP_LOADER BIT(4)
+
+/* Firmware loader address */
+#define ISHTP_LOADER_CLIENT_ADDR 16
+
+/**
+ * ishtp_loader_work - The work function to start the firmware loading process
+ * @work: The work structure
+ */
+void ishtp_loader_work(struct work_struct *work);
+
+#endif /* _ISHTP_LOADER_H_ */
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 5/5] HID: intel-ish-hid: handler multiple MNG_RESET_NOTIFY messages
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
` (3 preceding siblings ...)
2024-05-06 1:30 ` [PATCH 4/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
@ 2024-05-06 1:30 ` Zhang Lixu
2024-05-06 21:34 ` [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Jiri Kosina
5 siblings, 0 replies; 7+ messages in thread
From: Zhang Lixu @ 2024-05-06 1:30 UTC (permalink / raw
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires; +Cc: lixu.zhang
This patch enhances the firmware reset handler in the Intel Integrated
Sensor Hub (ISH) driver. Previously, the ISH firmware would send a
MNG_RESET_NOTIFY message in response to an empty IPC message from the
ish_wakeup function. With the introduction of the feature to load ISH
firmware from the host on the LunarLake platform, the ISH bootloader
now involves the IPC function. This results in an additional
MNG_RESET_NOTIFY message being sent by ISH bootloader after power on.
Consequently, the driver receives two MNG_RESET_NOTIFY messages during
system boot up. This can disrupt the dev->dev_state during the first
reset flow due to the subsequent reset notify message.
To address this, the patch modifies the fw_reset_work_fn function to skip
the execution of ishtp_reset_compl_handler during the first reset flow if
a reset is pending. The ishtp_reset_compl_handler will then be executed
during the second reset flow, ensuring the dev->dev_state is not disrupted.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index adce30f8ebff..3cd53fc80634 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -546,11 +546,11 @@ static int ish_fw_reset_handler(struct ishtp_device *dev)
/**
* fw_reset_work_fn() - FW reset worker function
- * @unused: not used
+ * @work: Work item
*
* Call ish_fw_reset_handler to complete FW reset
*/
-static void fw_reset_work_fn(struct work_struct *unused)
+static void fw_reset_work_fn(struct work_struct *work)
{
int rv;
@@ -562,7 +562,8 @@ static void fw_reset_work_fn(struct work_struct *unused)
wake_up_interruptible(&ishtp_dev->wait_hw_ready);
/* ISHTP notification in IPC_RESET sequence completion */
- ishtp_reset_compl_handler(ishtp_dev);
+ if (!work_pending(work))
+ ishtp_reset_compl_handler(ishtp_dev);
} else
dev_err(ishtp_dev->devc, "[ishtp-ish]: FW reset failed (%d)\n",
rv);
--
2.34.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
` (4 preceding siblings ...)
2024-05-06 1:30 ` [PATCH 5/5] HID: intel-ish-hid: handler multiple MNG_RESET_NOTIFY messages Zhang Lixu
@ 2024-05-06 21:34 ` Jiri Kosina
5 siblings, 0 replies; 7+ messages in thread
From: Jiri Kosina @ 2024-05-06 21:34 UTC (permalink / raw
To: Zhang Lixu; +Cc: linux-input, srinivas.pandruvada, benjamin.tissoires
On Mon, 6 May 2024, Zhang Lixu wrote:
> This patch series is comprised of 5 patches. The first two patches are to add documentation
> for firmware loading. The third and fourth patches introduce support for the 'Load Main
> Firmware from Host' feature in the ISHTP driver, applicable to Lunar Lake and subsequent
> platforms. The last patch enhances the firmware reset handler in the ISH driver. This
> addresses an issue where the driver receives two MNG_RESET_NOTIFY messages upon implementing
> the 'Load Main Firmware from Host' feature.
>
> This patch series is based on the following 3 commits, which have already been included in the linux-next/master branch.
> - HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized dev->devc
> - HID: intel-ish-hid: Use PCI_VDEVICE() and rename device ID macros
> - HID: intel-ish-hid: ipc: Add Lunar Lake-M PCI device ID
>
> Qianru Huang (2):
> Documentation: hid: intel-ish-hid: remove section numbering
> Documentation: hid: intel-ish-hid: add section for firmware loading
>
> Zhang Lixu (3):
> HID: intel-ish-hid: Add driver_data for specifying the firmware
> filename
> HID: intel-ish-hid: Implement loading firmware from host feature
> HID: intel-ish-hid: handler multiple MNG_RESET_NOTIFY messages
This is now queued in hid.git#for-6.10/intel-ish.
Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-05-06 21:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-06 1:30 [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
2024-05-06 1:30 ` [PATCH 1/5] Documentation: hid: intel-ish-hid: remove section numbering Zhang Lixu
2024-05-06 1:30 ` [PATCH 2/5] Documentation: hid: intel-ish-hid: add section for firmware loading Zhang Lixu
2024-05-06 1:30 ` [PATCH 3/5] HID: intel-ish-hid: Add driver_data for specifying the firmware filename Zhang Lixu
2024-05-06 1:30 ` [PATCH 4/5] HID: intel-ish-hid: Implement loading firmware from host feature Zhang Lixu
2024-05-06 1:30 ` [PATCH 5/5] HID: intel-ish-hid: handler multiple MNG_RESET_NOTIFY messages Zhang Lixu
2024-05-06 21:34 ` [PATCH 0/5] HID: intel-ish-hid: Implement loading firmware from host feature Jiri Kosina
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).