Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAODwPW9E8wWwxbYKyf4_-JFb4F-JSmLR3qOF_iudjX0f9ndF0A@mail.gmail.com>
 <CAODwPW8fiFSNehZbZDdR9kjHxohLGiyE7edU=Opy0xV_P8JbEQ@mail.gmail.com>
 <CAD=FV=XAYUx9OKLxThQxYr02ZE+7Rjw0VnSsxg7kfPCBG38FZw@mail.gmail.com>
 <CAODwPW_6A3kcmTLHVnH19bdYKpVBadAcDk5g-qxuju04uPRcMg@mail.gmail.com> <CAD=FV=UzsbwSbTc7LtsTj=wxj8A1MqmkVFt0XBrTdQ8pEhde=A@mail.gmail.com>
In-Reply-To: <CAD=FV=UzsbwSbTc7LtsTj=wxj8A1MqmkVFt0XBrTdQ8pEhde=A@mail.gmail.com>
From:   Julius Werner <jwerner@chromium.org>
Date:   Wed, 15 Jun 2022 16:24:29 -0700
Message-ID: <CAODwPW9DiWF2ffwBnw2rNhcV8rre=BzO9deEY_qXGvkWCPwe4A@mail.gmail.com>
Subject: Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and
 related bindings
To:     Doug Anderson <dianders@chromium.org>
Cc:     Julius Werner <jwerner@chromium.org>,
        Krzysztof Kozlowski <krzk+dt@kernel.org>,
        Dmitry Osipenko <digetx@gmail.com>,
        Jian-Jia Su <jjsu@google.com>,
        Rob Herring <robh+dt@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Nikola Milosavljevic <mnidza@outlook.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> OK, then what you have seems OK. Personally I guess I'd find it a
> little less confusing if we described it as "num-chips" or something
> like that.

Yeah, we can do that too if people prefer that, that just means the
firmware writing the entry needs to do that math. But while it makes
the chips thing more obvious, it makes it less obvious what the actual
memory channel width for the memory controller is, so I think it's
sort of a trade-off either way (I feel like reporting the channel
width would be closer to describing the raw topography as seen by
memory training firmware, and leaving interpretations up to the
kernel/userspace).

> They do have different sets of values valid for each property. The
> properties are annoyingly not sorted consistently with each other, but
> I think there are also different sets of properties aren't there? Like
> I only see tRASmin-min-tck in the LPDDR2 one and not LPDDR3.

Okay, I haven't looked closely into the timing part. If there are
notable differences, let's keep that separate.