Message-ID: <CAODwPW-GDkfyFaNSnEngpSfz8LSXRetu+xwp3QrFHP1rH1O06w@mail.gmail.com>
Date:   Wed, 20 Jul 2022 16:42:46 -0700
From:   Julius Werner <jwerner@...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>,
        Doug Anderson <dianders@...omium.org>,
        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

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.
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.

The existing bindings seem to have clearly been designed for platforms
that only ever use a single specific LPDDR part, and in those cases
these issues don't come up, so I assume this choice had just been made
without much thought. But now I would like to reuse them on platforms
where this is a problem, and that's why I would like to either expand
or change the binding to (also) allow a generic compatible string to
solve it. (Whether that means moving all platforms to only use this
generic compatible string, or allowing it side-by-side with the
existing part-specific compatible strings is up to you -- I don't want
to preclude other platforms from doing what they prefer, I just want
to make sure there's some form of workable solution for my platform.
But if you would prefer this to be an all-or-nothing thing, we could
change everything over to a generic compatible string too if you
want.)

> > Of course there may always be mistakes and broken
> > devices that need custom handling, and if someone has a platform with
> > such a case I of course don't want to preclude them from tying special
> > behavior to a custom compatible string. But why would that mean we
> > need to make this mandatory for all platforms even if it's not
> > relevant (and not practically feasible) for them? Why not allow both?
>
> Depends. If generic compatible is not enough (works only for your case)
> then it should have never been added alone.

No, I don't think it would work only for my case -- in fact I think
it's pretty unlikely that we'll ever find a case where this doesn't
work. LPDDR is a very rigid standard that generally needs to be able
to interoperate (at the memory controller and firmware training code
level) without any vendor-specific software quirks. I was just trying
to say that I wouldn't want to stop anybody from adding
vendor-specific quirks for a platform if they really needed to -- but
I don't know of any such case in practice and I doubt it actually
exists. The few existing uses of this binding don't use the compatible
string for anything more than to parse out the manufacturer ID, which
I think would make much more sense to model as a property.

Powered by blists - more mailing lists