Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and related bindings

From: Julius Werner <jwerner@chromium.org>
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>
Subject: Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and related bindings
Date: Wed, 15 Jun 2022 16:24:29 -0700	[thread overview]
Message-ID: <CAODwPW9DiWF2ffwBnw2rNhcV8rre=BzO9deEY_qXGvkWCPwe4A@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=UzsbwSbTc7LtsTj=wxj8A1MqmkVFt0XBrTdQ8pEhde=A@mail.gmail.com>

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