Message-ID: <CAD=FV=U8rgxuymX6hurS96rg1fjDUfh60b0X4UbpPp+TA+ck5g@mail.gmail.com>
Date:   Wed, 27 Jul 2022 07:07:38 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Julius Werner <jwerner@...omium.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Jian-Jia Su <jjsu@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Nikola Milosavljevic <mnidza@...look.com>
Subject: Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and
 related bindings

Hi,

On Wed, Jul 27, 2022 at 1:47 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 21/07/2022 01:42, Julius Werner wrote:
> > Sorry, got distracted from this for a bit. Sounds like we were pretty
> > much on the same page about how the updated binding should look like
> > here, the remaining question was just about the compatible string.
> >
> >>>> Yes, we can. You still would need to generate the compatible according
> >>>> to the current bindings. Whether we can change it I am not sure. I think
> >>>> it depends how much customization is possible per vendor, according to
> >>>> JEDEC spec. If we never ever have to identify specific part, because
> >>>> JEDEC spec and registers tell us everything, then we could skip it,
> >>>> similarly to lpddr2 and jedec,spi-nor.
> >>>
> >>> Shouldn't that be decided per use case? In general LPDDR is a pretty
> >>> rigid set of standards and memory controllers are generally compatible
> >>> with any vendor without hardcoding vendor-specific behavior, so I
> >>> don't anticipate that this would be likely (particularly since there
> >>> is no "real" kernel device driver that needs to initialize the full
> >>> memory controller, after all, these bindings are mostly
> >>> informational).
> >>
> >> If decided per use case understood as "decided depending how to use the
> >> bindings" then answer is rather not. For example Linux implementation is
> >> usually not the best argument to shape the bindings and usually to such
> >> arguments answer is: "implementation does not matter".
> >>
> >> If by "use case" you mean actual hardware or specification
> >> characteristics, then yes, of course. This is why I wrote "it depends".
> >
> > By "use case" I mean our particular platform and firmware requirements
> > -- or rather, the realities of building devices with widely
> > multi-sourced LPDDR parts. One cannot efficiently build firmware that
> > can pass an exact vendor-and-part-specific compatible string to Linux
> > for this binding for every single LPDDR part used on such a platform.
>
> Why cannot? You want to pass them as numerical values which directly map
> to vendor ID and some part, don't they?

If you really want this to be in the "compatible" string, maybe the
right answer is to follow the lead of USB which encodes the VID/PID in
the compatible string
(Documentation/devicetree/bindings/usb/usb-device.yaml). It's solving
this exact same problem of avoiding needing a table translating from
an ID provided by a probable device to an human-readable string.


> > And I don't see why that should be needed, either... that's kinda the
> > point of having an interoperability standard, after all, that you can
> > just assume the devices all work according to the same spec and don't
> > need to hardcode details about each specific instance.
>
> If we talk about standard, then DT purpose is not for autodetectable
> pieces. These values are autodetectable, so such properties should not
> be encoded in DT.

In the case of DDR, I think that the firmware can auto-detect them but
not the kernel. So from the kernel's point of view the DDR info should
be in DT, right?

-Doug

Powered by blists - more mailing lists