Message ID | 20231222111658.832167-2-jbrunet@baylibre.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-9648-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2483:b0:fb:cd0c:d3e with SMTP id q3csp990089dyi; Fri, 22 Dec 2023 03:18:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IGJakHlkOHG3Y871Vw8zNugtOPIalmDo1O6rSoyNV3Y3p7FFxnt/uO01ErFHxpAypcR2UFA X-Received: by 2002:a17:902:da8b:b0:1d3:f43a:a2d4 with SMTP id j11-20020a170902da8b00b001d3f43aa2d4mr980192plx.114.1703243903861; Fri, 22 Dec 2023 03:18:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703243903; cv=none; d=google.com; s=arc-20160816; b=ukt3RPg7nUUYCN/xYY5Frhtoa15zbK2Dlw6WSsJkxp8kCYyjWxz/LFyIucYXBLPeH+ hHbVA6YLqPl7SG1xrYmSEatPkt87923RHiriEBioVuTAftUDELfvUqEz7jy0m9YGJ6EU iAizLx9bHP/46ihsvsSazDlGKgrnhaUDT6OvqaH+aRdpMZchKCGLyAG5Ujg8HwG2Sl7q OfgSrBZhhSEoCLQbj7K7Y7IW1besng/ec/G8P/hXt3Z44tMhM3KihkPpjaqH8gy2JIoA EoTvK6TE6OPAROhSIPt+3weuaA5AkWK7gSBYJmobEtnW0sbetDuvtjgD/kGL6ScyHuKo TEzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=hbdPMPGBWozpmFUaZkCdhiZ0Fh092WlwkYQcWOwj7p8=; fh=c/ChwMkSyybETG2d+XlVO/zL/8FyzyAx+Ps2BkIffAk=; b=exIrDDAHBpj1AQbZTBUIGketgPxGV6zKaAHh22eyFDmlWIWMVWyTgo0U6LIWzqhvk/ siw4KY+xLSwSWtmre0u570AURm+DeCIXx5+xnMvjVU6vQgrJk2MXvRjN5BB6o6Cd6y/D 9a4vCCsOIRN5TChT9paqXkCQmshNWjg3o7fr09VbMRUg9icOT0JeDIP+67Hprg63r2mF LCEfZrX5n52iOPiIvmKhgpHlQsznXWKtsyXUAV17zoomxEL/SZBxzXhJF7dnBI11PZ7X 8924b8Xw+K3OJWaS8qRzBBsuSTcgEqBlnWC7JRfr6ocIZLIz46ThPOethZi2ITWmgCmN dI/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20230601.gappssmtp.com header.s=20230601 header.b=GOCGULr+; spf=pass (google.com: domain of linux-kernel+bounces-9648-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9648-ouuuleilei=gmail.com@vger.kernel.org" Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id iz11-20020a170902ef8b00b001d33a68f2c7si2985287plb.521.2023.12.22.03.18.23 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 03:18:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-9648-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20230601.gappssmtp.com header.s=20230601 header.b=GOCGULr+; spf=pass (google.com: domain of linux-kernel+bounces-9648-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-9648-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 9C9D92877DE for <ouuuleilei@gmail.com>; Fri, 22 Dec 2023 11:18:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E88311A58E; Fri, 22 Dec 2023 11:17:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="GOCGULr+" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DFFD1773E for <linux-kernel@vger.kernel.org>; Fri, 22 Dec 2023 11:17:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2cc61d4e5aeso21576961fa.0 for <linux-kernel@vger.kernel.org>; Fri, 22 Dec 2023 03:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1703243843; x=1703848643; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hbdPMPGBWozpmFUaZkCdhiZ0Fh092WlwkYQcWOwj7p8=; b=GOCGULr+URexeUHbH0I4y/AYzeMKEihRZh15l/7uiER3Is7VjwNTW843oGV4U40cES IyjlAT7+NsDoaU/7Sd/sn66PSHsgUmStZm6Sa4O5KjuN5BSgqProYLKaDEHn+95vUa9E UAH4kXPmHqS+jC20HJHTQpCTYH7II6jJ2n2TUhRv7ghH1mBaGQ4Zwk+HUA+tscVLc+13 mTmwa+GpIfq9yjzY+RJlUT3hL/61tL1hwkMKaAWUxXIAcQ8Bw8ib4YySJkk00HqRuTQo 5FNv7gScHBvMOYSuYyE48cDwtHwz7Ges8870jkmb9uPxT3EuPK4kvjnmOcryr7NioK1F HhNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703243843; x=1703848643; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hbdPMPGBWozpmFUaZkCdhiZ0Fh092WlwkYQcWOwj7p8=; b=v4qdnPjF4EnSxtZ167Q0ECyWbxAgBFg0GHOqE1KAq3u+GadYIEXLRWUUnJ6Nh98Qbs g1qtOLU7+oWZJ89qiobv8gfKSfI24g8CaU2/1RDYQeigaHw7iey9JMHUE175VgYcgGYk 6LOJm2HSIMtNIZA/qq6gy1gTXStdxX15nLmh7EZJhIzFY5uH23Xz+eqHgTNx/ZyRdcgS KyL/9EsGPeEFI5r6iHo7mWe84fk4olPM8E+43MOJzVr9T0lgsVjy96qxAY5K0lsc/c4E OR+h6Ncvou2WJ0s+Y7oYqC+m+0S65nN8yy61SHG84JTRnHiJP8ag4y1ZRKc/xM27kW50 yXeg== X-Gm-Message-State: AOJu0YxjsMKgF8K1DGhHO6/3qr3gSQ1oPYTlkoYIQpzQIdLRW0g8OnZR eucBT06VDD34s+jeOWlXZ2nJKewWk/ZlQQ== X-Received: by 2002:a2e:a499:0:b0:2cc:a253:e72e with SMTP id h25-20020a2ea499000000b002cca253e72emr518179lji.60.1703243842587; Fri, 22 Dec 2023 03:17:22 -0800 (PST) Received: from toaster.lan ([2a01:e0a:3c5:5fb1:c099:e596:3179:b0fa]) by smtp.googlemail.com with ESMTPSA id f8-20020adffcc8000000b003366b500047sm4054069wrs.50.2023.12.22.03.17.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Dec 2023 03:17:22 -0800 (PST) From: Jerome Brunet <jbrunet@baylibre.com> To: Thierry Reding <thierry.reding@gmail.com>, =?utf-8?q?Uwe_Kleine-K=C3=B6n?= =?utf-8?q?ig?= <u.kleine-koenig@pengutronix.de>, Neil Armstrong <neil.armstrong@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> Cc: Jerome Brunet <jbrunet@baylibre.com>, Kevin Hilman <khilman@baylibre.com>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-pwm@vger.kernel.org, JunYi Zhao <junyi.zhao@amlogic.com>, Rob Herring <robh@kernel.org> Subject: [PATCH v4 1/6] dt-bindings: pwm: amlogic: fix s4 bindings Date: Fri, 22 Dec 2023 12:16:49 +0100 Message-ID: <20231222111658.832167-2-jbrunet@baylibre.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231222111658.832167-1-jbrunet@baylibre.com> References: <20231222111658.832167-1-jbrunet@baylibre.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 X-Patchwork-Bot: notify Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785980679666591796 X-GMAIL-MSGID: 1785980679666591796 |
Series |
pwm: meson: dt-bindings fixup
|
|
Commit Message
Jerome Brunet
Dec. 22, 2023, 11:16 a.m. UTC
s4 has been added to the compatible list while converting the Amlogic PWM binding documentation from txt to yaml. However, on the s4, the clock bindings have different meaning compared to the previous SoCs. On the previous SoCs the clock bindings used to describe which input the PWM channel multiplexer should pick among its possible parents. This is very much tied to the driver implementation, instead of describing the HW for what it is. When support for the Amlogic PWM was first added, how to deal with clocks through DT was not as clear as it nowadays. The Linux driver now ignores this DT setting, but still relies on the hard-coded list of clock sources. On the s4, the input multiplexer is gone. The clock bindings actually describe the clock as it exists, not a setting. The property has a different meaning, even if it is still 2 clocks and it would pass the check when support is actually added. Also the s4 cannot work if the clocks are not provided, so the property no longer optional. Finally, for once it makes sense to see the input as being numbered somehow. No need to bother with clock-names on the s4 type of PWM. Fixes: 43a1c4ff3977 ("dt-bindings: pwm: Convert Amlogic Meson PWM binding") Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> --- .../devicetree/bindings/pwm/pwm-amlogic.yaml | 67 ++++++++++++++++--- 1 file changed, 58 insertions(+), 9 deletions(-)
Comments
On Fri, Dec 22, 2023 at 12:16:49PM +0100, Jerome Brunet wrote: > s4 has been added to the compatible list while converting the Amlogic PWM > binding documentation from txt to yaml. > > However, on the s4, the clock bindings have different meaning compared to > the previous SoCs. > > On the previous SoCs the clock bindings used to describe which input the > PWM channel multiplexer should pick among its possible parents. > > This is very much tied to the driver implementation, instead of describing > the HW for what it is. When support for the Amlogic PWM was first added, > how to deal with clocks through DT was not as clear as it nowadays. > The Linux driver now ignores this DT setting, but still relies on the > hard-coded list of clock sources. > > On the s4, the input multiplexer is gone. The clock bindings actually > describe the clock as it exists, not a setting. The property has a > different meaning, even if it is still 2 clocks and it would pass the check > when support is actually added. > > Also the s4 cannot work if the clocks are not provided, so the property no > longer optional. s/no/is no/ > Finally, for once it makes sense to see the input as being numbered > somehow. No need to bother with clock-names on the s4 type of PWM. > > Fixes: 43a1c4ff3977 ("dt-bindings: pwm: Convert Amlogic Meson PWM binding") > Reviewed-by: Rob Herring <robh@kernel.org> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> > --- > .../devicetree/bindings/pwm/pwm-amlogic.yaml | 67 ++++++++++++++++--- > 1 file changed, 58 insertions(+), 9 deletions(-) > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml > index 527864a4d855..a1d382aacb82 100644 > --- a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml > +++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml > @@ -9,9 +9,6 @@ title: Amlogic PWM > maintainers: > - Heiner Kallweit <hkallweit1@gmail.com> > > -allOf: > - - $ref: pwm.yaml# > - > properties: > compatible: > oneOf: > @@ -43,12 +40,8 @@ properties: > maxItems: 2 > > clock-names: > - oneOf: > - - items: > - - enum: [clkin0, clkin1] > - - items: > - - const: clkin0 > - - const: clkin1 > + minItems: 1 > + maxItems: 2 > > "#pwm-cells": > const: 3 > @@ -57,6 +50,55 @@ required: > - compatible > - reg > > +allOf: > + - $ref: pwm.yaml# > + > + - if: > + properties: > + compatible: > + contains: > + enum: > + - amlogic,meson8-pwm > + - amlogic,meson8b-pwm > + - amlogic,meson-gxbb-pwm > + - amlogic,meson-gxbb-ao-pwm > + - amlogic,meson-axg-ee-pwm > + - amlogic,meson-axg-ao-pwm > + - amlogic,meson-g12a-ee-pwm > + - amlogic,meson-g12a-ao-pwm-ab > + - amlogic,meson-g12a-ao-pwm-cd > + then: > + # Historic bindings tied to the driver implementation > + # The clocks provided here are meant to be matched with the input > + # known (hard-coded) in the driver and used to select pwm clock > + # source. Currently, the linux driver ignores this. I admit I didn't understand the relevant difference between the old and the new binding yet. (The driver currently doesn't support the s4, right?) Is it possible to detect if the dt uses the old or the new binding? If yes, I suggest to drop the old one from the binding and only keep it in the driver for legacy systems. > + properties: > + clock-names: > + oneOf: > + - items: > + - enum: [clkin0, clkin1] > + - items: > + - const: clkin0 > + - const: clkin1 > + > + # Newer IP block take a single input per channel, instead of 4 inputs > + # for both channels > + - if: > + properties: > + compatible: > + contains: > + enum: > + - amlogic,meson-s4-pwm The expectation is that this list contains all compatibles that are not included in the "historic" list above, right? Then maybe use "else:" instead of another explicit list? > + then: > + properties: > + clocks: > + items: > + - description: input clock of PWM channel A > + - description: input clock of PWM channel B > + clock-names: false > + required: > + - clocks > + > additionalProperties: false Best regards Uwe
On Wed 17 Jan 2024 at 11:03, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > [[PGP Signed Part:Undecided]] > On Fri, Dec 22, 2023 at 12:16:49PM +0100, Jerome Brunet wrote: >> s4 has been added to the compatible list while converting the Amlogic PWM >> binding documentation from txt to yaml. >> >> However, on the s4, the clock bindings have different meaning compared to >> the previous SoCs. >> >> On the previous SoCs the clock bindings used to describe which input the >> PWM channel multiplexer should pick among its possible parents. >> >> This is very much tied to the driver implementation, instead of describing >> the HW for what it is. When support for the Amlogic PWM was first added, >> how to deal with clocks through DT was not as clear as it nowadays. >> The Linux driver now ignores this DT setting, but still relies on the >> hard-coded list of clock sources. >> >> On the s4, the input multiplexer is gone. The clock bindings actually >> describe the clock as it exists, not a setting. The property has a >> different meaning, even if it is still 2 clocks and it would pass the check >> when support is actually added. >> >> Also the s4 cannot work if the clocks are not provided, so the property no >> longer optional. > > s/no/is no/ > >> Finally, for once it makes sense to see the input as being numbered >> somehow. No need to bother with clock-names on the s4 type of PWM. >> >> Fixes: 43a1c4ff3977 ("dt-bindings: pwm: Convert Amlogic Meson PWM binding") >> Reviewed-by: Rob Herring <robh@kernel.org> >> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> >> --- >> .../devicetree/bindings/pwm/pwm-amlogic.yaml | 67 ++++++++++++++++--- >> 1 file changed, 58 insertions(+), 9 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml >> index 527864a4d855..a1d382aacb82 100644 >> --- a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml >> +++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml >> @@ -9,9 +9,6 @@ title: Amlogic PWM >> maintainers: >> - Heiner Kallweit <hkallweit1@gmail.com> >> >> -allOf: >> - - $ref: pwm.yaml# >> - >> properties: >> compatible: >> oneOf: >> @@ -43,12 +40,8 @@ properties: >> maxItems: 2 >> >> clock-names: >> - oneOf: >> - - items: >> - - enum: [clkin0, clkin1] >> - - items: >> - - const: clkin0 >> - - const: clkin1 >> + minItems: 1 >> + maxItems: 2 >> >> "#pwm-cells": >> const: 3 >> @@ -57,6 +50,55 @@ required: >> - compatible >> - reg >> >> +allOf: >> + - $ref: pwm.yaml# >> + >> + - if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - amlogic,meson8-pwm >> + - amlogic,meson8b-pwm >> + - amlogic,meson-gxbb-pwm >> + - amlogic,meson-gxbb-ao-pwm >> + - amlogic,meson-axg-ee-pwm >> + - amlogic,meson-axg-ao-pwm >> + - amlogic,meson-g12a-ee-pwm >> + - amlogic,meson-g12a-ao-pwm-ab >> + - amlogic,meson-g12a-ao-pwm-cd >> + then: >> + # Historic bindings tied to the driver implementation >> + # The clocks provided here are meant to be matched with the input >> + # known (hard-coded) in the driver and used to select pwm clock >> + # source. Currently, the linux driver ignores this. > > I admit I didn't understand the relevant difference between the old and > the new binding yet. Let's try to explain differently then: * So far each AML PWM IP has 2 pwm. * Up to G12, 4 input PLL/clocks are wired to the HW IP and there mux/div/gate to select which input to take. - The historic bindings just described how to setup each of the 2 internal muxes - 2 optionnal clocks. The actual 4 inputs names from CCF are hard coded in the driver. This is a pretty bad description. The driver has been updated since then to use CCF to figure out the best parent according to pwm rate so this setting is ignored now. - The 'new' bindings (introduced in patch #2) fixes the problem above but the meaning of the clock binding is different. It describes the actual HW parents - 4 clocks, optionnal since some are not wired on some PWM blocks. To avoid breaking the ABI, a new compatible for these SoC is introduced. > (The driver currently doesn't support the s4, right?) Indeed. I know Amlogic is preparing the support. I could do it in this series but I prefer to encourage them to contribute. It should come shortly after this series is merged. Starting from s4 (prbably even a1 - up to people contributing this SoC to say) the mux/div/gate is no longer in the PWM IP. It has moved to the main clock controller. Again the clock binding describes something different. It is the 2 input clocks of each block, they are mandatory this time. > Is it possible to detect if the dt uses the old or the new > binding? Apart from the compatible, no. > If yes, I suggest to drop the old one from the binding and only > keep it in the driver for legacy systems. I don't this would be allowed by the DT maintainers. My understanding is that the old binding doc is here to stay. What could happen after sufficient time has past it remove the support for the old/historic binding in the driver. Driver are not required to support all possible bindings after all, especially if it is not used/tested anymore. > >> + properties: >> + clock-names: >> + oneOf: >> + - items: >> + - enum: [clkin0, clkin1] >> + - items: >> + - const: clkin0 >> + - const: clkin1 >> + >> + # Newer IP block take a single input per channel, instead of 4 inputs >> + # for both channels >> + - if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - amlogic,meson-s4-pwm > > The expectation is that this list contains all compatibles that are not > included in the "historic" list above, right? Then maybe use "else:" > instead of another explicit list? > I suppose if, elseif, else is possible. I've done it this way because is slightly easier for human to read the doc and find what is related to what. If you this is important for you, I can change it. >> + then: >> + properties: >> + clocks: >> + items: >> + - description: input clock of PWM channel A >> + - description: input clock of PWM channel B >> + clock-names: false >> + required: >> + - clocks >> + >> additionalProperties: false > > Best regards > Uwe
On 2024/1/17 18:30, Jerome Brunet wrote: > [ EXTERNAL EMAIL ] > > On Wed 17 Jan 2024 at 11:03, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > >> [[PGP Signed Part:Undecided]] >> On Fri, Dec 22, 2023 at 12:16:49PM +0100, Jerome Brunet wrote: >>> s4 has been added to the compatible list while converting the Amlogic PWM >>> binding documentation from txt to yaml. >>> >>> However, on the s4, the clock bindings have different meaning compared to >>> the previous SoCs. >>> >>> On the previous SoCs the clock bindings used to describe which input the >>> PWM channel multiplexer should pick among its possible parents. >>> >>> This is very much tied to the driver implementation, instead of describing >>> the HW for what it is. When support for the Amlogic PWM was first added, >>> how to deal with clocks through DT was not as clear as it nowadays. >>> The Linux driver now ignores this DT setting, but still relies on the >>> hard-coded list of clock sources. >>> >>> On the s4, the input multiplexer is gone. The clock bindings actually >>> describe the clock as it exists, not a setting. The property has a >>> different meaning, even if it is still 2 clocks and it would pass the check >>> when support is actually added. >>> >>> Also the s4 cannot work if the clocks are not provided, so the property no >>> longer optional. >> >> s/no/is no/ >> >>> Finally, for once it makes sense to see the input as being numbered >>> somehow. No need to bother with clock-names on the s4 type of PWM. >>> >>> Fixes: 43a1c4ff3977 ("dt-bindings: pwm: Convert Amlogic Meson PWM binding") >>> Reviewed-by: Rob Herring <robh@kernel.org> >>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> >>> --- >>> .../devicetree/bindings/pwm/pwm-amlogic.yaml | 67 ++++++++++++++++--- >>> 1 file changed, 58 insertions(+), 9 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml >>> index 527864a4d855..a1d382aacb82 100644 >>> --- a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml >>> +++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml >>> @@ -9,9 +9,6 @@ title: Amlogic PWM >>> maintainers: >>> - Heiner Kallweit <hkallweit1@gmail.com> >>> >>> -allOf: >>> - - $ref: pwm.yaml# >>> - >>> properties: >>> compatible: >>> oneOf: >>> @@ -43,12 +40,8 @@ properties: >>> maxItems: 2 >>> >>> clock-names: >>> - oneOf: >>> - - items: >>> - - enum: [clkin0, clkin1] >>> - - items: >>> - - const: clkin0 >>> - - const: clkin1 >>> + minItems: 1 >>> + maxItems: 2 >>> >>> "#pwm-cells": >>> const: 3 >>> @@ -57,6 +50,55 @@ required: >>> - compatible >>> - reg >>> >>> +allOf: >>> + - $ref: pwm.yaml# >>> + >>> + - if: >>> + properties: >>> + compatible: >>> + contains: >>> + enum: >>> + - amlogic,meson8-pwm >>> + - amlogic,meson8b-pwm >>> + - amlogic,meson-gxbb-pwm >>> + - amlogic,meson-gxbb-ao-pwm >>> + - amlogic,meson-axg-ee-pwm >>> + - amlogic,meson-axg-ao-pwm >>> + - amlogic,meson-g12a-ee-pwm >>> + - amlogic,meson-g12a-ao-pwm-ab >>> + - amlogic,meson-g12a-ao-pwm-cd >>> + then: >>> + # Historic bindings tied to the driver implementation >>> + # The clocks provided here are meant to be matched with the input >>> + # known (hard-coded) in the driver and used to select pwm clock >>> + # source. Currently, the linux driver ignores this. >> >> I admit I didn't understand the relevant difference between the old and >> the new binding yet. > > Let's try to explain differently then: > * So far each AML PWM IP has 2 pwm. > * Up to G12, 4 input PLL/clocks are wired to the HW IP and there > mux/div/gate to select which input to take. > - The historic bindings just described how to setup each of the 2 > internal muxes - 2 optionnal clocks. > The actual 4 inputs names from CCF are hard coded in > the driver. This is a pretty bad description. The driver has been > updated since then to use CCF to figure out the best parent > according to pwm rate so this setting is ignored now. > - The 'new' bindings (introduced in patch #2) fixes the problem above > but the meaning of the clock binding is different. It describes the > actual HW parents - 4 clocks, optionnal since some are not wired on > some PWM blocks. To avoid breaking the ABI, a new compatible for > these SoC is introduced. > >> (The driver currently doesn't support the s4, right?) > > Indeed. I know Amlogic is preparing the support. I could do it in this > series but I prefer to encourage them to contribute. It should come > shortly after this series is merged. Yes. Amlogic is waiting these patches of Jerome. after these merge, we will start to rebase and submit s4 code. - Best Regards Junyi
diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml index 527864a4d855..a1d382aacb82 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml @@ -9,9 +9,6 @@ title: Amlogic PWM maintainers: - Heiner Kallweit <hkallweit1@gmail.com> -allOf: - - $ref: pwm.yaml# - properties: compatible: oneOf: @@ -43,12 +40,8 @@ properties: maxItems: 2 clock-names: - oneOf: - - items: - - enum: [clkin0, clkin1] - - items: - - const: clkin0 - - const: clkin1 + minItems: 1 + maxItems: 2 "#pwm-cells": const: 3 @@ -57,6 +50,55 @@ required: - compatible - reg +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + enum: + - amlogic,meson8-pwm + - amlogic,meson8b-pwm + - amlogic,meson-gxbb-pwm + - amlogic,meson-gxbb-ao-pwm + - amlogic,meson-axg-ee-pwm + - amlogic,meson-axg-ao-pwm + - amlogic,meson-g12a-ee-pwm + - amlogic,meson-g12a-ao-pwm-ab + - amlogic,meson-g12a-ao-pwm-cd + then: + # Historic bindings tied to the driver implementation + # The clocks provided here are meant to be matched with the input + # known (hard-coded) in the driver and used to select pwm clock + # source. Currently, the linux driver ignores this. + properties: + clock-names: + oneOf: + - items: + - enum: [clkin0, clkin1] + - items: + - const: clkin0 + - const: clkin1 + + # Newer IP block take a single input per channel, instead of 4 inputs + # for both channels + - if: + properties: + compatible: + contains: + enum: + - amlogic,meson-s4-pwm + then: + properties: + clocks: + items: + - description: input clock of PWM channel A + - description: input clock of PWM channel B + clock-names: false + required: + - clocks + additionalProperties: false examples: @@ -68,3 +110,10 @@ examples: clock-names = "clkin0", "clkin1"; #pwm-cells = <3>; }; + - | + pwm@1000 { + compatible = "amlogic,meson-s4-pwm"; + reg = <0x1000 0x10>; + clocks = <&pwm_src_a>, <&pwm_src_b>; + #pwm-cells = <3>; + };