Re: [PATCH 4/9] arm64: dts: qcom: msm8916: Reserve firmware memory dynamically

From: Konrad Dybcio
Date: Fri Sep 15 2023 - 09:52:43 EST


On 14.09.2023 16:09, Stephan Gerhold wrote:
> On Wed, Sep 13, 2023 at 09:39:50PM +0200, Konrad Dybcio wrote:
>> On 13.09.2023 12:14, Stephan Gerhold wrote:
>>> On Wed, Sep 13, 2023 at 10:12:12AM +0100, Bryan O'Donoghue wrote:
>>>> On 13/09/2023 10:06, Konrad Dybcio wrote:
>>>>> On 11.09.2023 19:41, Stephan Gerhold wrote:
>>>>>> Most of the reserved firmware memory on MSM8916 can be relocated when
>>>>>> respecting the required alignment. To avoid having to precompute the
>>>>>> reserved memory regions in every board DT, describe the actual
>>>>>> requirements (size, alignment, alloc-ranges) using the dynamic reserved
>>>>>> memory allocation.
>>>>>>
>>>>>> This approach has several advantages:
>>>>>>
>>>>>> 1. We can define "templates" for the reserved memory regions in
>>>>>> msm8916.dtsi and keep only device-specific details in the board DT.
>>>>>> This is useful for the "mpss" region size for example, which varies
>>>>>> from device to device. It is no longer necessary to redefine all
>>>>>> firmware regions to shift their addresses.
>>>>>>
>>>>>> 2. When some of the functionality (e.g. WCNSS, Modem, Venus) is not
>>>>>> enabled or needed for a device, the reserved memory can stay
>>>>>> disabled, freeing up the unused reservation for Linux.
>>>>>>
>>>>>> 3. Devices with special requirements for one of the firmware regions
>>>>>> are handled automatically. For example, msm8916-longcheer-l8150
>>>>>> has non-relocatable "wcnss" firmware that must be loaded exactly
>>>>>> at address 0x8b600000. When this is defined as a static region,
>>>>>> the other dynamic allocations automatically adjust to a different
>>>>>> place with suitable alignment.
>>>>>>
>>>>>> All in all this approach significantly reduces the boilerplate necessary
>>>>>> to define the different firmware regions, and makes it easier to enable
>>>>>> functionality on the different devices.
>>>>>>
>>>>>> Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx>
>>>>>> ---
>>>>> [...]
>>>>>
>>>>>> mpss_mem: mpss@86800000 {
>>>>>> + /*
>>>>>> + * The memory region for the mpss firmware is generally
>>>>>> + * relocatable and could be allocated dynamically.
>>>>>> + * However, many firmware versions tend to fail when
>>>>>> + * loaded to some special addresses, so it is hard to
>>>>>> + * define reliable alloc-ranges.
>>>>>> + *
>>>>>> + * alignment = <0x0 0x400000>;
>>>>>> + * alloc-ranges = <0x0 0x86800000 0x0 0x8000000>;
>>>>>> + */
>>>>> Do we know of any devices that this would actually work on?
>> [...]
>>> - On DB410c it works just fine. All addresses I tried work without any
>>> problems.
>>>
>>> - On longcheer-l8150 the modem firmare works fine when the memory
>>> region starts somewhere between 0x86800000 and 0x8a800000. It also
>>> works again after 0x8e800000. But on anything between 0x8a800000 and
>>> 0x8e800000 it's broken for who knows what reason.
>>> [...]
>> Were you able to find a phone (likely a very reference-design-based
>> one) that this worked on, btw?
>
> Actually I would count the Longcheer devices (l8150 = Wileyfox Swift and
> l8910 = BQ Aquaris X5) to the category of close-to-QRD-based devices.
> Based on quick tests both behave like described above (only
> 0x8a800000-0x8e800000 is broken). Same for wingtech-wt88047.
>
> In other words, for those using the dynamic allocation would work fine,
> because the alloc-ranges = <0x0 0x86800000 0x0 0x8000000>; only includes
> working start addresses from 0x86800000 to ~0x89800000 (with a size of
> 0x5000000).
>
> I guess I could use it for them and only make other devices use a fixed
> address. But I also don't quite have the capacity to test every device
> to see if relocating the region works or not.
>
> I think it's still easiest to allocate mpss on a fixed address
> everywhere. The only real disadvantage is that overriding "reg", e.g.
>
> &mpss_mem {
> reg = <0x0 0x86800000 0x0 0x5100000>;
> };
>
> is a bit more ugly than overriding size:
>
> &mpss_mem {
> size = <0x0 0x5100000>;
> };
>
> but well, this is a very minor disadvantage.
So in other words, this only *really* works on apq8016?

Konrad