[0/4] memory: brcmstb_dpfe: support DPFE API v4

Message

Markus Mayer Dec. 5, 2023, 6:47 p.m. UTC

It has become necessary to distinguish between the various DPFE API
versions by version number. Having just chip-specific compatible strings
and one generic version is no longer meeting our needs.

Also, a new DPFE API version, v4, needs to be supported by the driver.

As a result, an intermediate compatible string format is being
introduced: brcm,dpfe-cpu-v<N> where <N> represents the API version
number. This is more specific than the catch-all "brcm,dpfe-cpu" and
more generic than chip-specific compatible strings, such as
"brcm,bcm7271-dpfe-cpu".

The changes are split into several steps.

First, we update the binding and introduce the versioned compatible
strings.

Secondly, we add support for brcm,dpfe-cpu-v1 through brcm,dpfe-cpu-v3
in the driver to match existing API versions.

Thirdly, we introduce DPFE API v4.

Lastly, there is a change that isn't directly related to the
introduction of the new binding format or DPFE API v4. However, with the
increasing number of API versions, broadening compatibility can be
helpful. If registering the driver using the DT-provided compatible
string fails, the driver will try all DPFE APIs (except for v1) to see
if one might end up working. This can come in handy if the driver moves
on and learns about new API versions while Device Tree cannot be
updated.

Markus Mayer (4):
  dt-bindings: memory: additional compatible strings for Broadcom DPFE
  memory: brcmstb_dpfe: introduce version-specific compatible strings
  memory: brcmstb_dpfe: support DPFE API v4
  memory: brcmstb_dpfe: introduce best-effort API detection

 .../memory-controllers/brcm,dpfe-cpu.yaml     |  8 +-
 drivers/memory/brcmstb_dpfe.c                 | 95 ++++++++++++++++++-
 2 files changed, 100 insertions(+), 3 deletions(-)

Comments

Krzysztof Kozlowski Dec. 6, 2023, 11:14 a.m. UTC | #1

On 05/12/2023 19:47, Markus Mayer wrote:
> It has become necessary to distinguish between the various DPFE API
> versions by version number. Having just chip-specific compatible strings
> and one generic version is no longer meeting our needs.
> 
> Also, a new DPFE API version, v4, needs to be supported by the driver.
> 
> As a result, an intermediate compatible string format is being

Introducing new SoC does not justify this. It's not correlated, not
related. Stop using some fake arguments to introduce something which we
do not want: versions.

> introduced: brcm,dpfe-cpu-v<N> where <N> represents the API version
> number. This is more specific than the catch-all "brcm,dpfe-cpu" and
> more generic than chip-specific compatible strings, such as
> "brcm,bcm7271-dpfe-cpu".

NAK

Best regards,
Krzysztof