Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Message-ID: <9ad1264f-efb5-40b5-bd7a-1477e86501a1@linaro.org>
Date:   Fri, 15 Sep 2023 15:52:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 4/9] arm64: dts: qcom: msm8916: Reserve firmware memory
 dynamically
Content-Language: en-US
To:     Stephan Gerhold <stephan@gerhold.net>
Cc:     Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Andy Gross <agross@kernel.org>, linux-arm-msm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230911-msm8916-rmem-v1-0-b7089ec3e3a1@gerhold.net>
 <20230911-msm8916-rmem-v1-4-b7089ec3e3a1@gerhold.net>
 <912f90ee-0816-43ae-bc6f-a9a9a3e33d8a@linaro.org>
 <9b1beb38-9ec2-4bdb-97f5-fccf98d3b0c3@linaro.org>
 <ZQGLioVhjCK3TRva@gerhold.net>
 <568b4e18-1ade-4a12-9766-d16d8ca9838d@linaro.org>
 <ZQMUDia6cYA0mGmL@gerhold.net>
From:   Konrad Dybcio <konrad.dybcio@linaro.org>
Autocrypt: addr=konrad.dybcio@linaro.org; keydata=
 xsFNBF9ALYUBEADWAhxdTBWrwAgDQQzc1O/bJ5O7b6cXYxwbBd9xKP7MICh5YA0DcCjJSOum
 BB/OmIWU6X+LZW6P88ZmHe+KeyABLMP5s1tJNK1j4ntT7mECcWZDzafPWF4F6m4WJOG27kTJ
 HGWdmtO+RvadOVi6CoUDqALsmfS3MUG5Pj2Ne9+0jRg4hEnB92AyF9rW2G3qisFcwPgvatt7
 TXD5E38mLyOPOUyXNj9XpDbt1hNwKQfiidmPh5e7VNAWRnW1iCMMoKqzM1Anzq7e5Afyeifz
 zRcQPLaqrPjnKqZGL2BKQSZDh6NkI5ZLRhhHQf61fkWcUpTp1oDC6jWVfT7hwRVIQLrrNj9G
 MpPzrlN4YuAqKeIer1FMt8cq64ifgTzxHzXsMcUdclzq2LTk2RXaPl6Jg/IXWqUClJHbamSk
 t1bfif3SnmhA6TiNvEpDKPiT3IDs42THU6ygslrBxyROQPWLI9IL1y8S6RtEh8H+NZQWZNzm
 UQ3imZirlPjxZtvz1BtnnBWS06e7x/UEAguj7VHCuymVgpl2Za17d1jj81YN5Rp5L9GXxkV1
 aUEwONM3eCI3qcYm5JNc5X+JthZOWsbIPSC1Rhxz3JmWIwP1udr5E3oNRe9u2LIEq+wH/toH
 kpPDhTeMkvt4KfE5m5ercid9+ZXAqoaYLUL4HCEw+HW0DXcKDwARAQABzShLb25yYWQgRHli
 Y2lvIDxrb25yYWQuZHliY2lvQGxpbmFyby5vcmc+wsGOBBMBCAA4FiEEU24if9oCL2zdAAQV
 R4cBcg5dfFgFAmQ5bqwCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQR4cBcg5dfFjO
 BQ//YQV6fkbqQCceYebGg6TiisWCy8LG77zV7DB0VMIWJv7Km7Sz0QQrHQVzhEr3trNenZrf
 yy+o2tQOF2biICzbLM8oyQPY8B///KJTWI2khoB8IJSJq3kNG68NjPg2vkP6CMltC/X3ohAo
 xL2UgwN5vj74QnlNneOjc0vGbtA7zURNhTz5P/YuTudCqcAbxJkbqZM4WymjQhe0XgwHLkiH
 5LHSZ31MRKp/+4Kqs4DTXMctc7vFhtUdmatAExDKw8oEz5NbskKbW+qHjW1XUcUIrxRr667V
 GWH6MkVceT9ZBrtLoSzMLYaQXvi3sSAup0qiJiBYszc/VOu3RbIpNLRcXN3KYuxdQAptacTE
 mA+5+4Y4DfC3rUSun+hWLDeac9z9jjHm5rE998OqZnOU9aztbd6zQG5VL6EKgsVXAZD4D3RP
 x1NaAjdA3MD06eyvbOWiA5NSzIcC8UIQvgx09xm7dThCuQYJR4Yxjd+9JPJHI6apzNZpDGvQ
 BBZzvwxV6L1CojUEpnilmMG1ZOTstktWpNzw3G2Gis0XihDUef0MWVsQYJAl0wfiv/0By+XK
 mm2zRR+l/dnzxnlbgJ5pO0imC2w0TVxLkAp0eo0LHw619finad2u6UPQAkZ4oj++iIGrJkt5
 Lkn2XgB+IW8ESflz6nDY3b5KQRF8Z6XLP0+IEdLOOARkOW7yEgorBgEEAZdVAQUBAQdAwmUx
 xrbSCx2ksDxz7rFFGX1KmTkdRtcgC6F3NfuNYkYDAQgHwsF2BBgBCAAgFiEEU24if9oCL2zd
 AAQVR4cBcg5dfFgFAmQ5bvICGwwACgkQR4cBcg5dfFju1Q//Xta1ShwL0MLSC1KL1lXGXeRM
 8arzfyiB5wJ9tb9U/nZvhhdfilEDLe0jKJY0RJErbdRHsalwQCrtq/1ewQpMpsRxXzAjgfRN
 jc4tgxRWmI+aVTzSRpywNahzZBT695hMz81cVZJoZzaV0KaMTlSnBkrviPz1nIGHYCHJxF9r
 cIu0GSIyUjZ/7xslxdvjpLth16H27JCWDzDqIQMtg61063gNyEyWgt1qRSaK14JIH/DoYRfn
 jfFQSC8bffFjat7BQGFz4ZpRavkMUFuDirn5Tf28oc5ebe2cIHp4/kajTx/7JOxWZ80U70mA
 cBgEeYSrYYnX+UJsSxpzLc/0sT1eRJDEhI4XIQM4ClIzpsCIN5HnVF76UQXh3a9zpwh3dk8i
 bhN/URmCOTH+LHNJYN/MxY8wuukq877DWB7k86pBs5IDLAXmW8v3gIDWyIcgYqb2v8QO2Mqx
 YMqL7UZxVLul4/JbllsQB8F/fNI8AfttmAQL9cwo6C8yDTXKdho920W4WUR9k8NT/OBqWSyk
 bGqMHex48FVZhexNPYOd58EY9/7mL5u0sJmo+jTeb4JBgIbFPJCFyng4HwbniWgQJZ1WqaUC
 nas9J77uICis2WH7N8Bs9jy0wQYezNzqS+FxoNXmDQg2jetX8en4bO2Di7Pmx0jXA4TOb9TM
 izWDgYvmBE8=
In-Reply-To: <ZQMUDia6cYA0mGmL@gerhold.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@gerhold.net>
>>>>>> ---
>>>>> [...]
>>>>>
>>>>>>   		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