[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a10439f1-0fcd-834c-12a3-677976529cf1@quicinc.com>
Date: Thu, 11 Jan 2024 12:08:20 -0700
From: Jeffrey Hugo <quic_jhugo@...cinc.com>
To: Qiang Yu <quic_qianyu@...cinc.com>,
Manivannan Sadhasivam
<mani@...nel.org>
CC: <mhi@...ts.linux.dev>, <linux-arm-msm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <quic_cang@...cinc.com>,
<quic_mrana@...cinc.com>, Bhaumik Bhatt <quic_bbhatt@...cinc.com>
Subject: Re: [PATCH] bus: mhi: host: Add sysfs entry to force device to enter
EDL
On 1/9/2024 2:20 AM, Qiang Yu wrote:
>
> On 1/3/2024 12:52 AM, Manivannan Sadhasivam wrote:
>> On Tue, Jan 02, 2024 at 08:31:15AM -0700, Jeffrey Hugo wrote:
>>> On 12/25/2023 12:47 AM, Qiang Yu wrote:
>>>> From: Bhaumik Bhatt <quic_bbhatt@...cinc.com>
>>>>
>>>> Forcing the device (eg. SDX75) to enter Emergency Download Mode
>>>> involves
>>>> writing the 0xEDEDEDED cookie to the channel 91 doorbell register and
>>>> forcing an SOC reset afterwards. Allow users of the MHI bus to
>>>> exercise the
>>>> sequence using a sysfs entry.
>>> I don't see this documented in the spec anywhere. Is this standard
>>> behavior
>>> for all MHI devices?
>>>
>>> What about devices that don't support EDL mode?
>>>
>>> How should the host avoid using this special cookie when EDL mode is not
>>> desired?
>>>
>> All points raised by Jeff are valid. I had discussions with Hemant and
>> Bhaumik
>> previously on allowing the devices to enter EDL mode in a generic
>> manner and we
>> didn't conclude on one final approach.
>>
>> Whatever way we come up with, it should be properly described in the
>> MHI spec
>> and _should_ be backwards compatible.
>
> Hi Mani, Jeff. The method of entering EDL mode is documented in MHI spec
> v1.2, Chapter 13.2.
>
> Could you please check once?
I do see it listed there. However that was a FR for SDX55, so devices
prior to that would not support this. AIC100 predates this change and
would not support the functionality. I verified the AIC100
implementation is not aware of this cookie.
Also, that functionality depends on channel 91 being reserved per the
table 9-2, however that table only applies to modem class devices as it
is under chapter 9 "Modem protocols over PCIe". Looking at the ath11k
and ath12k implementations in upstream, it looks like they partially
comply. Other devices have different MHI channel definitions.
Chapter 9 doesn't appear to be in older versions of the spec that I
have, so it is unclear if this functionality is backwards compatible
(was channel 91 used for another purpose in pre-SDX55 modems).
I'm not convinced this belongs in the MHI core. At a minimum, the MHI
controller(s) for the applicable devices needs to opt-in to this.
-Jeff
Powered by blists - more mailing lists