From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B269C43334 for ; Wed, 15 Jun 2022 23:24:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348658AbiFOXYq (ORCPT ); Wed, 15 Jun 2022 19:24:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242403AbiFOXYp (ORCPT ); Wed, 15 Jun 2022 19:24:45 -0400 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC99710FD8 for ; Wed, 15 Jun 2022 16:24:44 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id z17so7085146wmi.1 for ; Wed, 15 Jun 2022 16:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oh0CzsBK6XYUSBqF1cQtOHLaqbDSnG4wCRRP0RL1GWY=; b=fwryWYy1j3kluVUxxG5tFQ3vYHpbqs9hgx4Jdj1WImsyQmO4FTGFa4hM1VabxWcMms WojO6BK3Hsd5ZpJMYnTmbFv4nRhloIV5aNQRFeEz0P1QQaZ3IO8tgbpGhzb7hee9RpiY 76/9VoY0DBWkGkLyYJ7Ja5vJIarHTKlwS1eUY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oh0CzsBK6XYUSBqF1cQtOHLaqbDSnG4wCRRP0RL1GWY=; b=CHxCmV1o5CELXK2SbddwdFlqdgXXH6nSvgVcQWRvVi9MHE6k2VaVGBK2e9yrfk/hGO GmoqphmDOgL5moJzrJGvEcSLjcBLhO/utFQa8YO16oXabyQYBAMRnlB2T9vv1Mj9ufjC nlD3J33xECaGVMMxxU1G1NmzTi07kVb4ghWqmIcCvgCbRhlMHMxtwfVAIxaetuVxKVjs jlm9BLVDhbiGJKFk8nDjWOrSTxambNjWD9EgAI7RODyFrae/OBgVZ3pIm2aounG39GRQ qAQI8j5K4w14RDC2eZ5lG34HgE8HVUvz4lKt5FlsappohIS1DPT8N4nNOFN0/2LNsgiE v26w== X-Gm-Message-State: AJIora+/4gkcwJj+ni/Z0EZ9vOyaE5sFfaTEApYo2LxHW4ys76fyyioZ +xAsla0uoUdcLw4DGV+tbAhks587tiCM+6enrz0z8Q== X-Google-Smtp-Source: AGRyM1uj+gBu25gwQLFPBOZ5+Eln6z2RnmnhA3J7SVFKR/uvc0t7ylrZdMgeetRsu5LbUjgJ+JRDWKcrmpPXtYwXnNw= X-Received: by 2002:a05:600c:3792:b0:39c:6667:202 with SMTP id o18-20020a05600c379200b0039c66670202mr1876308wmr.104.1655335483162; Wed, 15 Jun 2022 16:24:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Julius Werner Date: Wed, 15 Jun 2022 16:24:29 -0700 Message-ID: Subject: Re: [RFC] Correct memory layout reporting for "jedec,lpddr2" and related bindings To: Doug Anderson Cc: Julius Werner , Krzysztof Kozlowski , Dmitry Osipenko , Jian-Jia Su , Rob Herring , LKML , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Nikola Milosavljevic Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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.