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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5C0D8ECAAD3 for ; Mon, 5 Sep 2022 11:34:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vG1Bv2Uzlno6uM9lP0E1TYuW9GXvUcPP9XuA6pZXj7E=; b=AqXmzuE0h7Tdut a1OXT3ahb31U2cOVgGU5MNxBuq1s+ohYbhrhDfD2AJiWBfcPcmdwlG+UFeaI66abyeLsOxogzkdm8 w3ww7g42wHKGxpitPydiCkD9vYDODd18CqlFBy0G5PFMD9iwu5dwxdbLZkZI6S/hAVvrntAHDkjHf XuG5+e3Pe1XyepUqlbhm9vAiyb01/MUARDcanMD/raGNW6y7am+HhzBleBHDc7PqmJwRlwTvJqT3E Dbanu1MYHTOUvx4jumIKEIIMjgtWx1pPWU8uFYjNeEu7P7oaNc0AnOrdR9h4s/n2M7/zukNmRrZlE Da4CArykUPl9mxDsx4kw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVALD-001LAo-NZ; Mon, 05 Sep 2022 11:32:41 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oV97a-00HY90-9K for linux-arm-kernel@lists.infradead.org; Mon, 05 Sep 2022 10:14:34 +0000 Received: by mail-lj1-x235.google.com with SMTP id by6so8698348ljb.11 for ; Mon, 05 Sep 2022 03:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=krr00gq+2rnnQjH2jiDEWmx4uGy3f7Je/Uzv5Nqwo9w=; b=mwaIK5ucn4NK+Emo4I4RNSP1OMgJjPAaZkgPI3hgHJCCTZ57pDEdIghsHLA4ob2pVz fFG4DNOJAG50HsaiGoG2bEZEj36GRNNjqjxs36+pJfqMbomer3i83S6HPkhFzrQnRXWj x9Tu425Of/dPX4NXWV/3M6zftLrzDebI2zELrjMDuLF+N/a3WV7sLsV5eedFhSwCQQLS kNkMc58C4a+iKeXiSnvVKjknTcVAnD5NBM9AdbqGEGAKeyOXVVa1iQ5R/Dffz5Ch8YNY Um2ZwaojYKOQM/oG/gEObStXDB5F8zS4m2E3JdCExsMLf5MpQt5uyahpe3mLfySt80L1 MrXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=krr00gq+2rnnQjH2jiDEWmx4uGy3f7Je/Uzv5Nqwo9w=; b=ZgL+bvFIViZ1jgYGYsHaCjA5NXy9oYLVX7XLErgDUzJJ7AJ3ARViiVhE6bCOX9X1Zg lqPCaeXDPXPxVrNLKzEWweDN0z6Zk6GzecU//PZi/1KmHXSQHjrjN61e8Zq0Q9tWNLD6 yEAAFPRAFLwOvzpzkqTXvlFKcjZ0/Gd2c9ZGMR2WB2OY3LbFWBWMM5+ZpHEaaH54FP4+ STY4jYwOXQQtrbmNsT2N4UH1zneIwsWKbU+J7Y6pFingGfEkhiHj5V+cIOcYi+BbuXB0 XtvURL6Ubio6XYUAy1npD7FZY7nRjCygNHgT3unT2Mcpht3v4l0lZhtrpMIJUs+fLF7X Jzgg== X-Gm-Message-State: ACgBeo0kajE+WWEDg6hnVASv6Kp6UoTBQzBtC4p1FR5YzE2OMOWvIAHW 9vyImvp5hfTQ932mjHOoKOn+7L/yMp0/I5eT X-Google-Smtp-Source: AA6agR5Tinz3xo5jyO3I/Zhphm/crNPOKhfBViyw+9BkJpLbm7ZmZ00WF7qaieTcY+4S8GnLTFbEqg== X-Received: by 2002:a2e:a9a0:0:b0:268:5e62:acfb with SMTP id x32-20020a2ea9a0000000b002685e62acfbmr7929456ljq.326.1662372863427; Mon, 05 Sep 2022 03:14:23 -0700 (PDT) Received: from [192.168.0.21] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id y10-20020a05651c106a00b0025e42f8e771sm1353110ljm.34.2022.09.05.03.14.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Sep 2022 03:14:22 -0700 (PDT) Message-ID: <36b2b6d9-9ab4-a4bc-6476-bd5b5d3ef77e@linaro.org> Date: Mon, 5 Sep 2022 12:14:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH 02/13] dt-bindings: memory: snps: Add Baikal-T1 DDRC support Content-Language: en-US To: Serge Semin Cc: Serge Semin , Michal Simek , Borislav Petkov , Mauro Carvalho Chehab , Tony Luck , Rob Herring , Manish Narani , Alexey Malahov , Michail Ivanov , Pavel Parkhomenko , Punnaiah Choudary Kalluri , Dinh Nguyen , James Morse , Robert Richter , Krzysztof Kozlowski , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220822191957.28546-1-Sergey.Semin@baikalelectronics.ru> <20220822191957.28546-3-Sergey.Semin@baikalelectronics.ru> <0bda4ff9-fc08-77f2-0e06-7469dcaec6d8@linaro.org> <20220826095447.qxfvty6xq4tufe75@mobilestation> From: Krzysztof Kozlowski In-Reply-To: <20220826095447.qxfvty6xq4tufe75@mobilestation> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220905_031432_527049_3BC5EBCB X-CRM114-Status: GOOD ( 25.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 26/08/2022 11:54, Serge Semin wrote: > On Tue, Aug 23, 2022 at 11:12:28AM +0300, Krzysztof Kozlowski wrote: >> On 22/08/2022 22:19, Serge Semin wrote: >>> Baikal-T1 DDR controller is based on the DW uMCTL2 DDRC IP-core v2.51a >>> with up to DDR3 protocol capability and 32-bit data bus + 8-bit ECC. There >>> are individual IRQs for each ECC and DFI events.The dedicated scrubber >> > >> Missing space before "The". > > Ok. Thanks. > >> >>> clock source is absent since it's fully synchronous to the core clock. >> > >> You need allOf:if-then restricting this per variant. > > I really don't like the allOf-if-if-etc pattern because it gets to be > very bulky if all the vendor-specific and generic platform > peculiarities are placed in there. I am more keen of having a > generic DT-schema which would be then allOf-ed by the vendor-specific > device bindings. What do you think I'd provide such design in this > case too? Sure, it would work. > > But I'll need to move the compatible property definition to the > "select" property. Like this: > > Documentation/devicetree/bindings/memory-controllers/snps,dw-umctl2-ddrc.yaml: > +[...] > +# Please create a separate DT-schema for your DW uMCTL2 DDR controller > +# and make sure it's assigned with the vendor-specific compatible string. > +select: > + properties: > + compatible: > + oneOf: > + - deprecated: true > + description: Synopsys DW uMCTL2 DDR controller v3.80a > + const: snps,ddrc-3.80a > + - description: Synopsys DW uMCTL2 DDR controller > + const: snps,dw-umctl2-ddrc > + - description: Xilinx ZynqMP DDR controller v2.40a > + const: xlnx,zynqmp-ddrc-2.40a > + required: > + - compatible Not entirely. If you need select, then add it with compatibles, but all descriptions and deprecated are staying in properties. > + > +properties: > + compatible: true > +[...] > +required: > + - compatible > + - reg > + - interrupts > + > +additionalProperties: true > > After that the "snps,dw-umctl2-ddrc.yaml" schema can be referenced in the > allOf composition. Like this: > > Documentation/devicetree/bindings/memory-controllers/baikal,bt1-ddrc.yaml: > +[...] > +allOf: > + - $ref: /schemas/memory-controllers/snps,dw-umctl2-ddrc.yaml# > +[...] > > At the same time the generic DT-schema will be used to evaluate the > "snps,ddrc-3.80a", "snps,dw-umctl2-ddrc" and "xlnx,zynqmp-ddrc-2.40a" > device nodes as before. What do you think about that? > > One big positive side of this that even though the generic schema > can't define the IRQ/resets/clocks phandlers order because various > platforms may have different external signals setup, the > vendor-specific schema can and should. So I'll be able to describe the > Baikal-T1 DDRC specific properties (clocks, clock-names, interrupts, > interrupt-names, etc) in much more details including the reference > signals order what you asked in the previous patch review. It's ok. You need then second schema for your device, because something must end with additional/unevaluatedProperties false. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel