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 CE6D5ECAAD5 for ; Thu, 8 Sep 2022 09:47:43 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=alDWnhFMZa2RxNNDzXvZ7Fe9xDjA0eo8cYPcweQh3WQ=; b=OkEir9uM8LDyku 0h4Xx6vtUQdY3UgoGO7jw/COg9/qyDDxPv2sVfcu/zxj55XTyBzJYuS97W/fP1CF9LsKJaecWmItz uF5z47xK4N45BAzTQIQOS+hPKvjA4bgbWoX93pDCTkXrlw/iF68LSMQ+8jMyRyhIx+oi9lxvxUgLM QcMunGn0pnIfe4iXpWJIZgvm3MnaqsfOnT7SRK3S2k7NJ4tx1eYcFzaWRiqfMu42rpU/+3OKq4XA9 t/fehUHspZNthQr0Ho7QB4K1YVqQmAd57GN2VQcJYZJgGuj7Z1ypo2tIqnil8KKreBGAIEqH7nDlY Sp/l11HviuvRaAZA55jQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWE7O-001mTd-HJ; Thu, 08 Sep 2022 09:46:42 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWE7J-001mR0-93 for linux-arm-kernel@lists.infradead.org; Thu, 08 Sep 2022 09:46:38 +0000 Received: by mail-lj1-x22a.google.com with SMTP id x10so19223778ljq.4 for ; Thu, 08 Sep 2022 02:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=ALmjZmyHYM2cBn/xj7Tq1X/P8kH0HgKp0PnkmVdAnGg=; b=j1Jo9160KpsbW5XlguQb+WQNfHvsekgXu5cyZotOz4HClvYMJWiEBtRDIJ1PGCy8Ef VxSL0VqEUUX4fdBLlnYiwsnd4d3rU2evaNeIYLOahRM2jEVgArNwprC2ud+4KMBCPPX9 G+9xC9IJU75UnrsFpZQCd1aqmJRo41ZYOzjYSkiTMUWQs+5YFrKq2aw0MkQgAB5OiT7+ C5xFn/tCbE5uxCTKinaAmUHCBcCjyJYJXnHDDsfIW708PrfLQgl3SF4ndjvbG7whCm69 /ha//j5vgJnO9rKZRMoFd0BRWzoFDV/U9jCWAXMrnY74WbRrwTXFOqRLRqOjLK51/z+q W8xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=ALmjZmyHYM2cBn/xj7Tq1X/P8kH0HgKp0PnkmVdAnGg=; b=wdOpnoo2FqAz3CK6CGxKeNuk3WhfIze/M6Kvi/DDxRw1lFykTkI1Dnt3+et2ghUFWz sLUEAjLmFf0dq2Byxk0uhjyTZQxhaGy3zP7w0oMU6hZU7Ql0Ip1NOWwwXmUTRjVj6Pao 5lviLuW54ynMPar+TsQ8HctfZDd0Xv+t5KuPX60eueDUW9yYJAdMbzOJryaA+Pw+X21H Ih32nvrVYHmywoqgAPVqhVaCQooD0vtzggPmDp0B680MGJUcc58ArmGYZmITRsmalGGO RFzfOBQuFgFHW3bBVnzTkH2Lxle0qgq46CGTZYgBqXZcQgikGfRKjAOCiKZWoeQBLi4p jByA== X-Gm-Message-State: ACgBeo2zOCNdMEzVdBA3uP1rYn3sgFGDGYMMbHTGDPSoUsFRWUB5dkIn VbB3NBm6tLWb9FCe64XTvCk= X-Google-Smtp-Source: AA6agR6Ppq3bQoSo0/8/xUsMzq2EiG98pBKlGXNy6y2LP2oWAwPLoZWiwDUG+MlQW8IKMT1qKIk7vA== X-Received: by 2002:a2e:a99b:0:b0:25e:be66:72f2 with SMTP id x27-20020a2ea99b000000b0025ebe6672f2mr2120184ljq.27.1662630394842; Thu, 08 Sep 2022 02:46:34 -0700 (PDT) Received: from mobilestation (89-109-47-111.dynamic.mts-nn.ru. [89.109.47.111]) by smtp.gmail.com with ESMTPSA id m16-20020a056512359000b004978e51b691sm1571799lfr.266.2022.09.08.02.46.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 02:46:34 -0700 (PDT) Date: Thu, 8 Sep 2022 12:46:31 +0300 From: Serge Semin To: Krzysztof Kozlowski 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 Subject: Re: [PATCH 02/13] dt-bindings: memory: snps: Add Baikal-T1 DDRC support Message-ID: <20220908094307.civtqiwxadas3ys3@mobilestation> 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> <36b2b6d9-9ab4-a4bc-6476-bd5b5d3ef77e@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <36b2b6d9-9ab4-a4bc-6476-bd5b5d3ef77e@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220908_024637_363947_61EFA4A4 X-CRM114-Status: GOOD ( 32.39 ) 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 Mon, Sep 05, 2022 at 12:14:21PM +0200, Krzysztof Kozlowski wrote: > 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. Ok. But note in such case the compatible string constraints will get to be opened for any non-common string. Like this: + properties: + compatible: + oneOf: + - const: snps,ddrc-3.80a + - {} It's required for the DT-schemas referencing the common one, otherwise they will fail DT-nodes evaluation due to the "compatible" property missing the vendor-specific string. > > > > + > > +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. Right. I'll add a separate DT-schema for my device. -Sergey > > Best regards, > Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel