- 07 Apr, 2021 10 commits
-
-
Bhaumik Bhatt authored
When clearing up the channel context after client drivers are done using channels, the configuration is currently not being reset entirely. Ensure this is done to appropriately handle issues where clients unaware of the context state end up calling functions which expect a context. Signed-off-by:
Bhaumik Bhatt <bbhatt@codeaurora.org> Reviewed-by:
Hemant Kumar <hemantk@codeaurora.org> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/1617311778-1254-7-git-send-email-bbhatt@codeaurora.orgSigned-off-by:
-
Bhaumik Bhatt authored
MHI host can fail early if device is in a bad state by attempting to assert device wake and holding the runtime PM vote before sending a channel update command instead of performing a wake toggle and waiting for a timeout if the send were to fail. This can help improve the design and enable shorter wait periods for device to respond as votes are already held. Signed-off-by:
-
Bhaumik Bhatt authored
Debug messages dealing with client devices use the generic MHI controller or parent device along with a channel number. It would be better to instead use the client device directly and enable better log messages for channel updates. Suggested-by:
-
Bhaumik Bhatt authored
Improve the channel handling state machine such that all commands go through a common function and a validation process to ensure that the state machine is not violated in any way and adheres to the MHI specification. Using this common function allows MHI to eliminate some unnecessary debug messages and code duplication. Signed-off-by:
-
Bhaumik Bhatt authored
If a channel was explicitly stopped but not reset and a driver remove is issued, clean up the channel context such that it is reflected on the device. This move is useful if a client driver module is unloaded or a device crash occurs with the host having placed the channel in a stopped state. Signed-off-by:
-
Bhaumik Bhatt authored
Add support to allow sending the STOP channel command. If a client driver would like to STOP a channel and have the device retain the channel context instead of issuing a RESET to it and clearing the context, this would provide support for it after the ability to send this command is exposed to clients. Signed-off-by:
-
Bhaumik Bhatt authored
Add generic info for SDX65 based modems. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1617399199-35172-1-git-send-email-bbhatt@codeaurora.orgSigned-off-by:
-
Bhaumik Bhatt authored
Some controllers can choose to skip preparation for power up. In that case, device context is initialized based on the pre_init flag not being set during mhi_prepare_for_power_up(). There is no reason MHI host driver should maintain and provide controllers with two separate paths for preparing MHI. Going forward, all controllers will be required to call the mhi_prepare_for_power_up() API followed by their choice of sync or async power up. This allows MHI host driver to get rid of the pre_init flag and sets up a common way for all controllers to use MHI. This also helps controllers fail early on during preparation phase in some failure cases. Signed-off-by:
-
Loic Poulain authored
Since M3 can be entered/exited quite a lot when used for runtime PM, keep the mhi suspend/resume transitions quiet. Signed-off-by:
-
Loic Poulain authored
This change ensures that PM reference is always get during packet queueing and released either after queuing completion (RX) or once the buffer has been consumed (TX). This guarantees proper update for underlying MHI controller runtime status (e.g. last_busy timestamp) and prevents suspend to be triggered while TX packets are flying, or before we completed update of the RX ring. Signed-off-by:
-
- 31 Mar, 2021 9 commits
-
-
Bhaumik Bhatt authored
In certain devices, it is likely that there is no incoming MHI interrupt for a transition to MHI READY state. One such example is the move from Pass Through to an SBL or AMSS execution environment. In order to facilitate faster bootup times as there is no need to wait until timeout_ms completes, MHI host can poll every 25 milliseconds to check if device has entered MHI READY until a maximum timeout of twice the timeout_ms is reached. Signed-off-by:
-
Bhaumik Bhatt authored
Introduce helper function to allow MHI core driver to poll for a value in a register field. This helps reach a common path to read and poll register values along with a retry time interval. Signed-off-by:
-
Bhaumik Bhatt authored
As of now abbreviations are being used for many state and execution environment strings. Improve and expand those such that debug messages are clear. Signed-off-by:
-
Bhaumik Bhatt authored
When moving from SYS_ERROR transition to a different execution environment, MHI host relies on the BHI register read to spawn the next image download or wait for READY -> M0 states. The device can at times move the execution environment to mission mode when a pass through is expected, which can result in a stall. Initiate a wait for MHI READY and write M0 such that the device can proceed with state change event updates for any new execution environment being entered. This allows us to remove conditionals in handling firmware load for PBL modes and keeps the execution environment out of the picture as it can change at any time. Signed-off-by:
-
Bhaumik Bhatt authored
MHI power up can go through an EDL to Flash Programmer path when the device has a blank NAND. In those cases, mhi_sync_power_up() can timeout waiting for a mission mode execution environment. Allow a successful power up instead by identifying Flash Programmer as a valid mission mode execution environment with a purpose to flash the device image contents. Signed-off-by:
-
Carl Yin authored
MHI WWAN modems support downloading firmware to NAND or eMMC using Firehose protocol with process as follows: 1. Modem boots up, enters AMSS execution environment and the device later enters EDL (Emergency Download) mode through any mechanism host can use such as a diag command. 2. Modem enters SYS_ERROR, MHI host handles SYS_ERROR transition. 3. EDL image for device to enter 'Flash Programmer' execution environment is then flashed via BHI interface from host. 4. Modem enters MHI READY -> M0 and sends the Flash Programmer execution environment change to host. 5. Following that, EDL/FIREHOSE channels (34, 35) are made available from the host. 6. User space tool for downloading firmware image to modem over the EDL channels using Firehose protocol. Link to USB flashing tool: https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/ Make the necessary changes to allow for this sequence to occur and allow using the Flash Programmer execution environment. Signed-off-by:
Carl Yin <carl.yin@quectel.com> Co-developed-by:
-
Bhaumik Bhatt authored
Device entering EDL or Emergency Download Mode will be in a SYS_ERROR MHI state. This requires MHI host to proceed with the EDL image download over BHI before device can enter an MHI READY state and proceed with further bootup. Allow this to be handled by relying on the execution environment check after SYS_ERROR processing to determine whether to wait for an MHI READY or download the EDL image over BHI after moving MHI PM state to Power on Reset internally. This way handling is contained well within the MHI core driver and helps pave the way for Flash Programmer execution environment functionality. Signed-off-by:
-
Bhaumik Bhatt authored
Currently, the firmware load handler returns after the EDL image is downloaded. Wait for an MHI READY transition instead as the specification expects so as to proceed with further bootup such as device entering Flash Programmer execution environment. Signed-off-by:
-
Bhaumik Bhatt authored
Relying on the current execution environment to determine if EDL image was downloaded should not be done as the execution environment can change at this point in error cases and we may misread it. Instead, MHI can rely on the local 'fw_name' variable as a safer alternative. Signed-off-by:
-
- 16 Mar, 2021 2 commits
-
-
Jeffrey Hugo authored
We cannot process a power_down if the power state is DISABLED. There is no valid mhi_ctxt in that case, so attepting to process the power_down will likely result in a null pointer dereference. If the power state is DISABLED, there is nothing to do anyways, so just bail early. Signed-off-by:
Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by:
-
Fan Wu authored
Currently ENOMEM is returned when MHI ring is full. This error code is very misleading. Change to EAGAIN instead. Signed-off-by:
Fan Wu <wufan@codeaurora.org> Signed-off-by:
-
- 15 Mar, 2021 1 commit
-
-
Colin Ian King authored
The variables state and ee are being initialized with values that are never read and are being updated later with a new values. The initializations are redundant and can be removed. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Manivannan Sadhasivam <mani@kernel.org> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20210311111727.8433-1-colin.king@canonical.comSigned-off-by:
-
- 10 Mar, 2021 17 commits
-
-
Bhaumik Bhatt authored
Some controllers can opt to not have MHI download a firmware image to have the device bootup and can find the device in a pass through execution environment, ready to go. Thus, MHI controllers for those devices do not need fw_image defined. Make it optional to accommodate different bootup modes. Suggested-by:
-
Jeffrey Hugo authored
The check to see if we have reset the device after detecting syserr at power_up is inverted. wait_for_event_timeout() returns 0 on failure, and a positive value on success. The check is looking for non-zero as a failure, which is likely to incorrectly cause a device init failure if syserr was detected at power_up. Fix this. Fixes: e18d4e9f ("bus: mhi: core: Handle syserr during power_up") Signed-off-by:
-
Bhaumik Bhatt authored
Update debug prints to include local device in the BHI interrupt handler. This helps show transitions better between MHI states. Signed-off-by:
-
Bhaumik Bhatt authored
In current design, whenever the BHI interrupt is fired, the execution environment is updated. This can cause race conditions and impede ongoing power up/down processing. For example, if a power down is in progress, MHI host updates to a local "disabled" execution environment. If a BHI interrupt fires later, that value gets replaced with one from the BHI EE register. This impacts the controller as it does not expect multiple RDDM execution environment change status callbacks as an example. Another issue would be that the device can enter mission mode and the execution environment is updated, while device creation for SBL channels is still going on due to slower PM state worker thread run, leading to multiple attempts at opening the same channel. Ensure that EE changes are handled only from appropriate places and occur one after another and handle only PBL modes or RDDM EE changes as critical events directly from the interrupt handler. Simplify handling by waiting for SYS ERROR before handling RDDM. This also makes sure that we use the correct execution environment to notify the controller driver when the device resets to one of the PBL execution environments. Signed-off-by:
-
Bhaumik Bhatt authored
During full boot chain firmware download, the PM state worker downloads the AMSS image after a blocking wait for the SBL execution environment change when running in PBL transition itself. Improve this design by having the host download the AMSS image from the SBL transition of PM state worker thread when a DEV_ST_TRANSITION_SBL is queued instead of the blocking wait. Signed-off-by:
-
Bhaumik Bhatt authored
Currently, client devices are created in SBL or AMSS (mission mode) and only destroyed after power down or SYS ERROR. When moving between certain execution environments, such as from SBL to AMSS, no clean-up is required. This presents an issue where SBL-specific channels are left open and client drivers now run in an execution environment where they cannot operate. Fix this by expanding the mhi_destroy_device() to do an execution environment specific clean-up if one is requested. Close the gap and destroy devices in such scenarios that allow SBL client drivers to clean up once device enters mission mode. Signed-off-by:
-
Loic Poulain authored
MHI suspend/resume are symmetric and balanced procedures. If device is not in M3 state on a resume, that means something happened behind our back. In this case resume is aborted and error reported, to let the controller handle the situation. This is mainly requested for system wide suspend-resume operation in PCI context which may lead to power-down/reset of the controller which will then lose its MHI context. In such cases, PCI driver is supposed to recover and reinitialize the device. Signed-off-by:
-
Bhaumik Bhatt authored
As per documentation, fields marked as (required) in an MHI controller structure need to be populated by the controller driver before calling mhi_register_controller(). Ensure all required pointers and non-zero fields are present in the controller before proceeding with the registration. Signed-off-by:
-
Loic Poulain authored
Use MHI controller device name instead of the 'bus' device name as debugfs dir name (e.g. /sys/kernel/debug/mhi0). That aligns with sysfs device name. Signed-off-by:
-
Loic Poulain authored
mhi_queue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update. So, since it's not an error but just delaying of doorbell update, there is no reason to return an error. This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done. Fixes: a8f75cb3 ("mhi: core: Factorize mhi queuing") Signed-off-by:
-
Loic Poulain authored
A recent change created a dedicated workqueue for the state-change work with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags, but the state-change work (mhi_pm_st_worker) does not guarantee forward progress under memory pressure, and will even wait on various memory allocations when e.g. creating devices, loading firmware, etc... The work is then not part of a memory reclaim path... Moreover, this causes a warning in check_flush_dependency() since we end up in code that flushes a non-reclaim workqueue: [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [ 40.969733] Call Trace: [ 40.969740] __flush_work+0x97/0x1d0 [ 40.969745] ? wake_up_process+0x15/0x20 [ 40.969749] ? insert_work+0x70/0x80 [ 40.969750] ? __queue_work+0x14a/0x3e0 [ 40.969753] flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] unregister_netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] device_release_driver_internal+0xf0/0x1d0 [ 40.969778] device_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.969786] device_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi] [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] device_for_each_child+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi] Fixes: 8f703978 ("bus: mhi: core: Move to using high priority workqueue") Signed-off-by:
-
Loic Poulain authored
When the device is idle it is possible to move it into the lowest MHI PM state (M3). In that mode, all MHI operations are suspended and the PCI device can be safely put into PCI D3 state. The device is then resumed from D3/M3 either because of host initiated MHI operation (e.g. buffer TX) or because the device (modem) has triggered wake-up via PME feature (e.g. on incoming data). Same procedures can be used for system wide or runtime suspend/resume. Signed-off-by:
-
Loic Poulain authored
The PCI core can take care of proper PCI suspend/resume operations, but this is discarded when the driver saves PCI state by its own. This currently prevents the PCI core to enable PME (for modem initiated D3 exit) which is requested for proper runtime pm support. This change deletes explicit PCI state-saving and state-set from suspend callback, letting the PCI doing the appropriate work. Signed-off-by:
-
Loic Poulain authored
The wake_db register presence is highly speculative and can fuze MHI devices. Indeed, currently the wake_db register address is defined at entry 127 of the 'Channel doorbell array', thus writing to this address is equivalent to ringing the doorbell for channel 127, causing trouble with some devics (e.g. SDX24 based modems) that get an unexpected channel 127 doorbell interrupt. This change fixes that issue by setting wake get/put as no-op for pci_generic devices. The wake device sideband mechanism seems really specific to each device, and is AFAIK not defined by the MHI spec. It also removes zeroing initialization of wake_db register during MMIO initialization, the register being set via wake_get/put accessors few cycles later during M0 transition. Signed-off-by:
-
Loic Poulain authored
Add generic info for SDX24 based modems. Also add the FIREHOSE channels used by the flash-programmer firmware loaded in EDL mode. Signed-off-by:
-
Loic Poulain authored
Add support for EM1XXGR-L modems, this modem series is based on SDX24 qcom chip. The modem is mainly based on MBIM protocol for both the data and control path. The drivers for these channels (mhi-net-mbim and mhi_uci) are not yet part of the kernel but will be integrated by different series. Signed-off-by:
-
Loic Poulain authored
Not all hardwares need to use the same number of event ring elements. This change makes this parametrable. Signed-off-by:
-
- 06 Mar, 2021 1 commit
-
-
Linus Torvalds authored
-
