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 29446C433EF for ; Wed, 15 Jun 2022 23:24:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346690AbiFOXYq (ORCPT ); Wed, 15 Jun 2022 19:24:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346367AbiFOXYp (ORCPT ); Wed, 15 Jun 2022 19:24:45 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF26210FEE for ; Wed, 15 Jun 2022 16:24:44 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id m16-20020a7bca50000000b0039c8a224c95so1881866wml.2 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=Adh7PpSfR3CeuOoGNuOc+lCsK+0u3yC5aJqZD1SfzFsmoZ6MzplPdkh21yBFkfmcNq DQypfMiv9KiD836te8GqV+w7pWBU1CY/EOCD1XnzHXyBm1OKhACpyqkkqAUx/eIVcwhn wjhx7nNj50ai2YWZ2K+KilD+Kve4UfO7SUd2WE9Y6Y8yfjXET5+Cc2QLyeBFaOXCJxA1 X24QwLPnG8izo+Gd0hjYJHhU+QBoYGlFtwKivSMEeoW1xzV3Luir9EA4Pn4vFg/Q6wEp bBdeEFMfd4dGzGOwWi4aW0WMYhgTzCKIcCQhGRkrpiIXAfb2yrbShrUGBzl904u2NEb5 JiRQ== X-Gm-Message-State: AJIora82+GEuC/Ovv6dR0QocIdp9IEO3K+EnbKenAMQlz+zyh4msFjKU eYzuhM3+hR6FBz3OgTp09s4auQqu5Q2mvnjghC0o/A== 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: devicetree@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.