Date: Wed, 3 Apr 2024 13:44:58 +0800
From: Qiang Yu <quic_qianyu@...cinc.com>
To: Jeffrey Hugo <quic_jhugo@...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 4/2/2024 11:33 PM, Jeffrey Hugo wrote:
> On 4/2/2024 7:52 AM, Qiang Yu wrote:
>>
>> On 4/2/2024 12:34 PM, Qiang Yu wrote:
>>>
>>> On 1/12/2024 3:08 AM, Jeffrey Hugo wrote:
>>>> 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
>>> Hi Jeff
>>>
>>> Sorry for reply so late. In older versions of the spec, there is no 
>>> description about EDL doorbell. However, in MHI spec v1.2, section 
>>> 13.2,
>>> It explicitly says "To set the EDL cookie, the host writes 
>>> 0xEDEDEDED to channel doorbell 91." So I think every device based on 
>>> MHI spec v1.2
>>> should reserve channel doorbell 91 for EDL mode.
>>>
>>> So can we add another flag called mhi_ver in mhi controller to 
>>> indicate its mhi version and then we can add mhi_ver checking to 
>>> determine if this
>>> device supports EDL sysfs operation?
>>>
>>> Thanks,
>>> Qiang
>>
>> I discussed with internal team, look like devices that reserve 
>> channel doorbell 91 for EDL, thier MHIVER register value can still be 
>> 1.0 instead
>> of 1.2. So even if we add a flag called mhi_ver to store the value 
>> read from the MHIVER register. We still can not do EDL support check 
>> depend on it.
>>
>> But I still think enter EDL mode by writing EDL cookie to channel 
>> doorbell is a standard way. At least it's a standard way from MHI 
>> spec V1.2.
>>
>> In mhi_controller, we have a variable edl_image representing the name 
>> and path of firmware. But We still can not determine if the device 
>> reserve
>> channel doorbell 91 by checking this because some devices may enter 
>> EDL mode in different way. Mayebe we have to add a flag in 
>> mhi_controller
>> called edl_support to do the check.
>
> So, not all devices support EDL mode (even v1.2 devices, which I know 
> of one in development).  Of the devices that support EDL mode, not all 
> of them use the same mechanism to enter EDL mode.
>
> It appears all of this needs to be shoved to the controller.
>
> At best, I think the controller can provide an optional EDL callback. 
> If the callback is provided, then MHI creates a sysfs entry (similar 
> to soc_reset) for the purpose of entering EDL mode.  If the sysfs 
> entry is called, all MHI does is call the controller's callback.
>
> -Jeff


Hi Jeff

This idea looks good. We can add edl call back in mhi_pci_dev_info and 
assgin it to mhi controller during probe.
Meanwhile, we can get edl doorbell address in this callback instead of 
mhi_init_mmio.

Mani, what do you think about it? Can I implement the EDL sysfs entry 
like this?

Powered by blists - more mailing lists