From: Krzysztof Kozlowski <krzk@kernel.org>
To: Doug Anderson <dianders@chromium.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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: Thu, 28 Jul 2022 09:35:49 +0200 [thread overview]
Message-ID: <8aa6228e-e6a2-b1f7-688e-8b4aa614c882@kernel.org> (raw)
In-Reply-To: <CAD=FV=U8rgxuymX6hurS96rg1fjDUfh60b0X4UbpPp+TA+ck5g@mail.gmail.com>
On 27/07/2022 16:07, Doug Anderson wrote:
> Hi,
>
> On Wed, Jul 27, 2022 at 1:47 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.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.
This makes sense. I would still argue that number of vendors is small
thus strings could be translated (there is like 20 of them in JEP166D -
JC-42.6), but for device ID this would work.
>
>
>>> 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?
True, I thought memory controllers could provide such information, but
now I checked Exynos5422 DMC and it does not expose such register.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-07-28 7:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-15 2:25 [RFC] Correct memory layout reporting for "jedec,lpddr2" and related bindings Julius Werner
2022-06-15 2:28 ` Julius Werner
2022-06-15 19:33 ` Doug Anderson
2022-06-15 21:27 ` Julius Werner
2022-06-15 22:33 ` Doug Anderson
2022-06-15 23:24 ` Julius Werner
2022-06-18 2:17 ` Krzysztof Kozlowski
2022-06-24 9:45 ` Krzysztof Kozlowski
2022-06-30 1:03 ` Julius Werner
2022-06-30 8:05 ` Krzysztof Kozlowski
2022-07-01 0:52 ` Julius Werner
2022-07-01 6:57 ` Krzysztof Kozlowski
2022-07-08 1:20 ` Julius Werner
2022-07-10 15:06 ` Krzysztof Kozlowski
2022-07-20 23:42 ` Julius Werner
2022-07-27 8:47 ` Krzysztof Kozlowski
2022-07-27 14:07 ` Doug Anderson
2022-07-28 7:35 ` Krzysztof Kozlowski [this message]
2022-07-28 0:22 ` Julius Werner
2022-07-28 7:38 ` Krzysztof Kozlowski
2022-07-04 8:22 ` Dmitry Osipenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8aa6228e-e6a2-b1f7-688e-8b4aa614c882@kernel.org \
--to=krzk@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=digetx@gmail.com \
--cc=jjsu@google.com \
--cc=jwerner@chromium.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mnidza@outlook.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).