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 12B7BC77B73 for ; Tue, 25 Apr 2023 17:03:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234874AbjDYRDY (ORCPT ); Tue, 25 Apr 2023 13:03:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234583AbjDYRDY (ORCPT ); Tue, 25 Apr 2023 13:03:24 -0400 Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBB083A9E; Tue, 25 Apr 2023 10:03:22 -0700 (PDT) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-1881333ac1cso4484388fac.1; Tue, 25 Apr 2023 10:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682442202; x=1685034202; 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 :message-id:reply-to; bh=+ZDfXI7hMbqGi7E82l8vWt9jneZ/T4Uui2TLcBQz+KM=; b=kXfx2b3L4bnge026GVI+Baha9Pm8eGEVPhWVcu3AxXkOsXy1eSP2CQdX2VR/CO6omc H2O0kgDR1dJ17ftcLQ2jNq8eZMjZGp5gL+eKSsuKR+qAzGQRfUVu3Rr5/AmoKjHw8PnZ kObEHSvcxYWMoZDWIUp2NCORTWmg8TaXrlzucj8UUugkHcUjlaLJDCKpXdvjxReY/7/j fUBqz/zq2bLC6VP/UB/n6Bfc4F5qBMgx4X2/wsEGouSAs0gu+LoP5mjY2zi2Y9Dn1fg8 z0pPLLOvSCh9DL26TIzb6PUhILB4gsASxscZ5sofjo9njdGSzAMpQx6rFvYTOXqU3WdT acww== X-Gm-Message-State: AAQBX9fY16/235yO43rt2YP33pxb2jglwYRgX2ZKnyax0UvoIE+43bbR bJhafSRXbGS54M2lcz1ByA== X-Google-Smtp-Source: AKy350Yul7/EEVvrMD/ABdCsLr9ode6pBn2tmtKnE0Rjjz8gJcwSoneSAZlS17HOt1THyFiTOOIaeQ== X-Received: by 2002:a05:6870:63a4:b0:17e:6eaa:945f with SMTP id t36-20020a05687063a400b0017e6eaa945fmr12199364oap.8.1682442201994; Tue, 25 Apr 2023 10:03:21 -0700 (PDT) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id b1-20020a056870b24100b0018045663fc5sm5678632oam.48.2023.04.25.10.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Apr 2023 10:03:21 -0700 (PDT) Received: (nullmailer pid 1948453 invoked by uid 1000); Tue, 25 Apr 2023 17:03:20 -0000 Date: Tue, 25 Apr 2023 12:03:20 -0500 From: Rob Herring To: Konrad Dybcio Cc: Rob Clark , Abhinav Kumar , Dmitry Baryshkov , Sean Paul , David Airlie , Daniel Vetter , Krzysztof Kozlowski , Krishna Manikandan , Will Deacon , Robin Murphy , Joerg Roedel , Marijn Suijten , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev Subject: Re: [PATCH v2 03/13] dt-bindings: display/msm: Add SM6350 DPU Message-ID: <20230425170320.GA1931576-robh@kernel.org> References: <20230411-topic-straitlagoon_mdss-v2-0-5def73f50980@linaro.org> <20230411-topic-straitlagoon_mdss-v2-3-5def73f50980@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411-topic-straitlagoon_mdss-v2-3-5def73f50980@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote: > Document the SM6350 DPU. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94 ++++++++++++++++++++++ > 1 file changed, 94 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml > new file mode 100644 > index 000000000000..979fcf81afc9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml > @@ -0,0 +1,94 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-dpu.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Display DPU dt properties for SM6350 target > + > +maintainers: > + - Konrad Dybcio > + > +$ref: /schemas/display/msm/dpu-common.yaml# > + > +properties: > + compatible: > + items: > + - const: qcom,sm6350-dpu > + > + reg: > + items: > + - description: Address offset and size for mdp register set > + - description: Address offset and size for vbif register set > + > + reg-names: > + items: > + - const: mdp > + - const: vbif > + > + clocks: > + items: > + - description: Display axi clock > + - description: Display ahb clock > + - description: Display rot clock > + - description: Display lut clock > + - description: Display core clock > + - description: Display vsync clock > + > + clock-names: > + items: > + - const: bus > + - const: iface > + - const: rot > + - const: lut > + - const: core > + - const: vsync Is there some reason the clocks are in different order? They appear to be the same minus the 'throttle' clock. Is there really no 'throttle' clock? Maybe this platform just tied it to one of the same clocks in the above? I really hate the mess that is clocks. We have the same or related blocks with just totally different names and order. The result is if/then schemas or separate schemas like this. Neither option is great, but at least the if/then schemas provides some motivation to not have pointless variations like this. As it seems the only difference between these 2 bindings is 1 extra clock, can't they be shared? Rob 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 3D60FC6FD18 for ; Tue, 25 Apr 2023 17:04:21 +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=Nlr9+XUtBLyhSB0+Mdxy0p9X/wkTE4pKvHEPXREqhPw=; b=SXFL7V3VzUtpJX 0Die5zt3Lu+FQJL3MesC17L9oF/dpMw0N16u4ZskhXclIVQfrAz7N82F2jpbsRR0vb3pwLfqXaO1X +/lrUCmoviyDSUgRhFZZ6zxET1MHJ0US2vmjz7DO4pmLILEPrrvKmQWrGf4Qrb1k3wTi8mnmnzQw1 2bedzTASAqUfoEpD+p3j/Gj0ORuH443b3X15ahxKuUxWgJB6EdhIruDBxlDYxPVQgRc4R4H9ZvolE 0DUV8vsfBI5Q86URyWt+SVuVXf2AE/qOJz+GfT2Vc+vz30b6/u1qopH8794ghGBBNNuVQtCXWJDjj l4fuiwBUAa0d5caF8G+w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1prM4e-001lAw-1z; Tue, 25 Apr 2023 17:03:28 +0000 Received: from mail-oa1-f43.google.com ([209.85.160.43]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1prM4b-001l9C-0M for linux-arm-kernel@lists.infradead.org; Tue, 25 Apr 2023 17:03:26 +0000 Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-18665c1776dso4474250fac.2 for ; Tue, 25 Apr 2023 10:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682442202; x=1685034202; 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 :message-id:reply-to; bh=+ZDfXI7hMbqGi7E82l8vWt9jneZ/T4Uui2TLcBQz+KM=; b=BUgASEn4x+X0hCrIAbGv8XpZ0Bl4MuXv5n84GMciIxxd5EiDhzwHCuBdvGrcucPJJO hSxznn7prXFAxeoOqS6YfRN/AhqLKfjw9Cduay6p8DcpkLpJFkyFG6k347Q/BL9F6JbH cG88XEpclwshPeFgcSONfqih1ZwN6bvHA5bEeCccgNt207Vi1Bb4Y6pUh7YzzsHNNZQp 3SFZRUTZMhYfXplZp6Vzw2+9m76a1VyDAk7tagiOgk13p3o+nGyOl9grCDsP2ZSriBcQ xNOj2WPzvGOt6uwGQc9fKJhFSDMbsois4kDdaJlAmwzlzD/XR2LpAeNUmS5mv4K6+UIs +DGg== X-Gm-Message-State: AAQBX9dgWWrgtUTAW8p2kCxZ8QxJ3CP226ZikI3u9nRyPGpWjlRyHnWe R2ODhYExD31aQrjkRBqu63Xp6ygfGw== X-Google-Smtp-Source: AKy350Yul7/EEVvrMD/ABdCsLr9ode6pBn2tmtKnE0Rjjz8gJcwSoneSAZlS17HOt1THyFiTOOIaeQ== X-Received: by 2002:a05:6870:63a4:b0:17e:6eaa:945f with SMTP id t36-20020a05687063a400b0017e6eaa945fmr12199364oap.8.1682442201994; Tue, 25 Apr 2023 10:03:21 -0700 (PDT) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id b1-20020a056870b24100b0018045663fc5sm5678632oam.48.2023.04.25.10.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Apr 2023 10:03:21 -0700 (PDT) Received: (nullmailer pid 1948453 invoked by uid 1000); Tue, 25 Apr 2023 17:03:20 -0000 Date: Tue, 25 Apr 2023 12:03:20 -0500 From: Rob Herring To: Konrad Dybcio Cc: Rob Clark , Abhinav Kumar , Dmitry Baryshkov , Sean Paul , David Airlie , Daniel Vetter , Krzysztof Kozlowski , Krishna Manikandan , Will Deacon , Robin Murphy , Joerg Roedel , Marijn Suijten , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev Subject: Re: [PATCH v2 03/13] dt-bindings: display/msm: Add SM6350 DPU Message-ID: <20230425170320.GA1931576-robh@kernel.org> References: <20230411-topic-straitlagoon_mdss-v2-0-5def73f50980@linaro.org> <20230411-topic-straitlagoon_mdss-v2-3-5def73f50980@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230411-topic-straitlagoon_mdss-v2-3-5def73f50980@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230425_100325_144491_9E304331 X-CRM114-Status: GOOD ( 20.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 Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote: > Document the SM6350 DPU. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94 ++++++++++++++++++++++ > 1 file changed, 94 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml > new file mode 100644 > index 000000000000..979fcf81afc9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml > @@ -0,0 +1,94 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-dpu.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Display DPU dt properties for SM6350 target > + > +maintainers: > + - Konrad Dybcio > + > +$ref: /schemas/display/msm/dpu-common.yaml# > + > +properties: > + compatible: > + items: > + - const: qcom,sm6350-dpu > + > + reg: > + items: > + - description: Address offset and size for mdp register set > + - description: Address offset and size for vbif register set > + > + reg-names: > + items: > + - const: mdp > + - const: vbif > + > + clocks: > + items: > + - description: Display axi clock > + - description: Display ahb clock > + - description: Display rot clock > + - description: Display lut clock > + - description: Display core clock > + - description: Display vsync clock > + > + clock-names: > + items: > + - const: bus > + - const: iface > + - const: rot > + - const: lut > + - const: core > + - const: vsync Is there some reason the clocks are in different order? They appear to be the same minus the 'throttle' clock. Is there really no 'throttle' clock? Maybe this platform just tied it to one of the same clocks in the above? I really hate the mess that is clocks. We have the same or related blocks with just totally different names and order. The result is if/then schemas or separate schemas like this. Neither option is great, but at least the if/then schemas provides some motivation to not have pointless variations like this. As it seems the only difference between these 2 bindings is 1 extra clock, can't they be shared? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 7557BC6FD18 for ; Tue, 25 Apr 2023 17:03:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8F40C10E2EB; Tue, 25 Apr 2023 17:03:25 +0000 (UTC) Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) by gabe.freedesktop.org (Postfix) with ESMTPS id 08D7A10E0AE; Tue, 25 Apr 2023 17:03:22 +0000 (UTC) Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-18e26c08349so3332059fac.0; Tue, 25 Apr 2023 10:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682442202; x=1685034202; 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 :message-id:reply-to; bh=+ZDfXI7hMbqGi7E82l8vWt9jneZ/T4Uui2TLcBQz+KM=; b=c3+edCJCof7Y73VgpJEKPyP7Qbi406dKWuZaphQ1/imhzUI8gwAxbjKCdC1nxumTf3 qsdhAroOolZRE/o5xa/zKVPXrO8c7DnsUX5b/j0Wd1X7n64VRq0xkSgHpXWv2B3YiblM bhMUZR7daUGGfYs7HuALw4Gwii6c+hwArl5ENzAQFv5hA3z/N7nSswK65qpxHn3MA37g MLw/yx8qww6n3b7K0nwQ5GwTV5kqQZUdO6319D8Oj0reT/CbfU01xeU8i5OdzIZzWQeb rEcqvPh1BAcO+BufRoV7cHhYHdL7uOzp40jmpDhyHuP7YxjDnoPLAdSFSxBLZqBakHfU /VOg== X-Gm-Message-State: AAQBX9cxh6mIKIHwPL+SuD4WBUPGdW1tpsPrtGhWSLrEDQSOZRZZ6Vpj SWubNMY/ArsGk9ntJ55xMQ== X-Google-Smtp-Source: AKy350Yul7/EEVvrMD/ABdCsLr9ode6pBn2tmtKnE0Rjjz8gJcwSoneSAZlS17HOt1THyFiTOOIaeQ== X-Received: by 2002:a05:6870:63a4:b0:17e:6eaa:945f with SMTP id t36-20020a05687063a400b0017e6eaa945fmr12199364oap.8.1682442201994; Tue, 25 Apr 2023 10:03:21 -0700 (PDT) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id b1-20020a056870b24100b0018045663fc5sm5678632oam.48.2023.04.25.10.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Apr 2023 10:03:21 -0700 (PDT) Received: (nullmailer pid 1948453 invoked by uid 1000); Tue, 25 Apr 2023 17:03:20 -0000 Date: Tue, 25 Apr 2023 12:03:20 -0500 From: Rob Herring To: Konrad Dybcio Subject: Re: [PATCH v2 03/13] dt-bindings: display/msm: Add SM6350 DPU Message-ID: <20230425170320.GA1931576-robh@kernel.org> References: <20230411-topic-straitlagoon_mdss-v2-0-5def73f50980@linaro.org> <20230411-topic-straitlagoon_mdss-v2-3-5def73f50980@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411-topic-straitlagoon_mdss-v2-3-5def73f50980@linaro.org> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: freedreno@lists.freedesktop.org, iommu@lists.linux.dev, Krzysztof Kozlowski , Will Deacon , devicetree@vger.kernel.org, Sean Paul , Joerg Roedel , Abhinav Kumar , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Krishna Manikandan , linux-arm-msm@vger.kernel.org, Dmitry Baryshkov , Marijn Suijten , linux-arm-kernel@lists.infradead.org, Robin Murphy Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote: > Document the SM6350 DPU. > > Signed-off-by: Konrad Dybcio > --- > .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94 ++++++++++++++++++++++ > 1 file changed, 94 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml > new file mode 100644 > index 000000000000..979fcf81afc9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6350-dpu.yaml > @@ -0,0 +1,94 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm6350-dpu.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm Display DPU dt properties for SM6350 target > + > +maintainers: > + - Konrad Dybcio > + > +$ref: /schemas/display/msm/dpu-common.yaml# > + > +properties: > + compatible: > + items: > + - const: qcom,sm6350-dpu > + > + reg: > + items: > + - description: Address offset and size for mdp register set > + - description: Address offset and size for vbif register set > + > + reg-names: > + items: > + - const: mdp > + - const: vbif > + > + clocks: > + items: > + - description: Display axi clock > + - description: Display ahb clock > + - description: Display rot clock > + - description: Display lut clock > + - description: Display core clock > + - description: Display vsync clock > + > + clock-names: > + items: > + - const: bus > + - const: iface > + - const: rot > + - const: lut > + - const: core > + - const: vsync Is there some reason the clocks are in different order? They appear to be the same minus the 'throttle' clock. Is there really no 'throttle' clock? Maybe this platform just tied it to one of the same clocks in the above? I really hate the mess that is clocks. We have the same or related blocks with just totally different names and order. The result is if/then schemas or separate schemas like this. Neither option is great, but at least the if/then schemas provides some motivation to not have pointless variations like this. As it seems the only difference between these 2 bindings is 1 extra clock, can't they be shared? Rob