Messages in this thread | | | Date | Wed, 3 Apr 2024 13:44:58 +0800 | Subject | Re: [PATCH] bus: mhi: host: Add sysfs entry to force device to enter EDL | From | Qiang Yu <> |
| |
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@quicinc.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?
| |