From: Florian Fainelli <florian.fainelli@broadcom.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Markus Mayer <mmayer@broadcom.com>,
Rob Herring <robh+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Device Tree Mailing List <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
Date: Wed, 6 Dec 2023 08:18:02 -0800 [thread overview]
Message-ID: <12f3c515-71cf-46a5-ad92-15bf6c4c2f2c@broadcom.com> (raw)
In-Reply-To: <e63906cf-9f76-4fed-91b0-1a9168b179bd@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 1662 bytes --]
On 12/6/2023 3:10 AM, Krzysztof Kozlowski wrote:
> On 05/12/2023 19:47, Markus Mayer wrote:
>> Add support for version 4 of the DPFE API. This new version is largely
>> identical to version 3. The main difference is that all commands now
>> take the MHS version number as the first argument. Any other arguments
>> have been pushed down by one (i.e. what used to be arg0 in v3 is arg1 in
>> v4).
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
>
> ...
>
>> +
>> static const char *get_error_text(unsigned int i)
>> {
>> static const char * const error_text[] = {
>> @@ -929,8 +954,12 @@ static const struct of_device_id brcmstb_dpfe_of_match[] = {
>> { .compatible = "brcm,dpfe-cpu-v1", .data = &dpfe_api_old_v2 },
>> { .compatible = "brcm,dpfe-cpu-v2", .data = &dpfe_api_new_v2 },
>> { .compatible = "brcm,dpfe-cpu-v3", .data = &dpfe_api_v3 },
>> + { .compatible = "brcm,dpfe-cpu-v4", .data = &dpfe_api_v4 },
>>
>
> No, use SoC specific compatible.
This is not that simple because for a given SoC, the API implemented by
the firmware can change, in fact it has changed over the lifetime of a
given SoC as firmware updates get rolled out. Arguably the dialect
spoken by the firmware should not have changed and we told the firmware
team about that but it basically went nowhere and here we are.
The Device Tree gets populated by the boot loader which figures out
which API is spoken and places one of those compatible strings
accordingly for the kernel to avoid having to do any sort of run-time
detection which is slow and completely unnecessary when we can simply
tell it ahead of time what to use.
--
Florian
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-12-06 16:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 18:47 [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4 Markus Mayer
2023-12-05 18:47 ` [PATCH 1/4] dt-bindings: memory: additional compatible strings for Broadcom DPFE Markus Mayer
2023-12-06 11:09 ` Krzysztof Kozlowski
2023-12-06 16:32 ` Florian Fainelli
2023-12-06 17:29 ` Krzysztof Kozlowski
2023-12-06 17:36 ` Florian Fainelli
2023-12-06 17:42 ` Krzysztof Kozlowski
2023-12-05 18:47 ` [PATCH 2/4] memory: brcmstb_dpfe: introduce version-specific compatible strings Markus Mayer
2023-12-05 19:05 ` Florian Fainelli
2023-12-06 11:09 ` Krzysztof Kozlowski
2023-12-06 16:19 ` Florian Fainelli
2023-12-06 17:33 ` Krzysztof Kozlowski
2023-12-05 18:47 ` [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4 Markus Mayer
2023-12-05 19:05 ` Florian Fainelli
2023-12-06 11:10 ` Krzysztof Kozlowski
2023-12-06 16:18 ` Florian Fainelli [this message]
2023-12-06 17:31 ` Krzysztof Kozlowski
2023-12-06 18:48 ` Markus Mayer
2023-12-05 18:47 ` [PATCH 4/4] memory: brcmstb_dpfe: introduce best-effort API detection Markus Mayer
2023-12-05 19:06 ` Florian Fainelli
2023-12-06 11:13 ` Krzysztof Kozlowski
2023-12-06 16:24 ` Florian Fainelli
2023-12-06 11:14 ` [PATCH 0/4] memory: brcmstb_dpfe: support DPFE API v4 Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12f3c515-71cf-46a5-ad92-15bf6c4c2f2c@broadcom.com \
--to=florian.fainelli@broadcom.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmayer@broadcom.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox