linux-kernel - Re: [PATCH 4/4] dt-bindings: memory: Add jedec,lpddrX-channel binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4abfb333-fd68-d752-a140-d15828be2148@linaro.org>
Date:   Thu, 8 Sep 2022 15:56:25 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Julius Werner <jwerner@...omium.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Doug Anderson <dianders@...omium.org>,
        Jian-Jia Su <jjsu@...gle.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] dt-bindings: memory: Add jedec,lpddrX-channel binding

On 01/09/2022 03:11, Julius Werner wrote:
>>> +description:
>>> +  An LPDDR channel is a completely independent set of LPDDR pins (DQ, CA, CS,
>>> +  CK, etc.) that connect one or more LPDDR chips to a host system. The main
>>> +  purpose of this node is to overall LPDDR topology of the system, including the
>>> +  amount of individual LPDDR chips and the ranks per chip.
>>
>> "channel" in this context confuses me a bit, because usually everyone is
>> talking about DDR controller channels, not memory channels. I think this
>> actually maps to a DDR controller channel?
> 
> I'm not really sure what you mean by "memory channel" here (that would
> be different from the DDR controller channel)? According to my
> understanding there's only one kind of "channel" in the context of
> main memory, that's the DDR controller channel (i.e. each separate
> complete set of DDR pins coming out of the controller, as I tried to
> explain in the description).
> 
>>> +    lpddr-channel1 {
>>> +      #address-cells = <1>;
>>> +      #size-cells = <0>;
>>> +      compatible = "jedec,lpddr4-channel";
>>> +      io-width = <32>;
>>
>> I wonder now, how does it exactly work - channel is 32 bits, two ranks
>> each with 32 bit IO bus. Your description said that:
>>
>> total_ram = (rank0 + rank1) * (channel_width / chip_width)
>> so for this case: (4+2)*(32/32) = 6 Mbit
>>
>> If channel io-width = <64>, then memories are stacked in parallel and
>> according to your description total RAM would be: (4+2)*(64/32) = 12 Mbit
>> I wonder why stacking memories in parallel increases their size?
> 
> Well, stacking in parallel just means you have more of them? In the
> original example, you have a single LPDDR chip with two ranks, one
> 4Gbit rank and one 2Gbit rank. That chip is directly hooked up to the
> LPDDR controller and that's the only chip you have, so you have 4+2 =
> 6Gbit total memory in the system.
> 
> In your next example, the LPDDR controller has a 64 bit wide channel,
> but you're still using that same 6Gbit LPDDR chip that only has 32 DQ
> pins. The only way to fill out that 64 bit channel with this kind of
> chip is to have two of them in parallel (one connected to DQ[0:31] and
> one connected to DQ[32:63]). So we infer from the mismatch in io-width
> that we have two chips. Each chip still has 6Gbit of memory, so the
> total system would have 12Gbit.

Two chips so more device nodes? Since there are no DTSes with it, please
provide an additional example in the bindings.

Best regards,
Krzysztof