Message ID | 20230526030559.326566-8-aford173@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp198105vqr; Thu, 25 May 2023 20:18:27 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6odUkXc+wCMxLUGwpZngwGbXMVCguJshaUE2VdKGh5o1pERMJsvMwQpg4cHo6tdEs+/r0L X-Received: by 2002:a17:90a:ca88:b0:255:2e48:70b1 with SMTP id y8-20020a17090aca8800b002552e4870b1mr904533pjt.26.1685071107280; Thu, 25 May 2023 20:18:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685071107; cv=none; d=google.com; s=arc-20160816; b=Lm7hnElVKkWdveRyU6hWckUAYxmjnENJ/Z4FinG3r86N/nqBQELOH4KfLn4kfy2Jnk VCUGq6yI7XpY58hTBk3F6+JWJqEkBv2iHCOfMQXXZ/v5/Jt/UyO4SgvHaxwEfe9p1FPa tzhYhAvBuJWILcXoVvkeLgOCTmoh5PgbvVlsCxpiZ8J1WiFdgV8M6SBnGhrTzQZckJVJ i4HhxceL+5Aw7RuXMZqT95meKNWe4fUemSyUQFVPqSF9pOPtK06cLOfAbY8NEuBKLqVn qqiabqQT6sh4eHb24/TSb4x9P+c5siQi7iZwK4agNb5nviGK2DEe+HoyKkr9a/ibKcuX rMTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=DRTsj12b6O33FC+cr8c7BPZ01uR7I3K/mmxNkVF4jws=; b=Gczs/DvdnpP5F6V1QdDhxwBp/d4Ohg7CeLzNI9ypzti+2QGnEgWH1aLWhvsDjgqBN7 xlJgWC1W6oJTUCU1HM5wsv0kJOVLTM832ShW0NVh4GfI3lFblyfZB7PWWto8/tQBwhoj pSBd8HP+XQJ5KkmiJd+csndvO7nTtx94JWQHOQLEK+wNEFK8eoChB5s+nupZSoqDFr5C BbBAmKJTUf2lE/sl9BNzsbCRD5O2AFLtBnElwdvboRP7P5MhzI8BA4uvRkivRUKwZYb7 zCnmqVvy9C9J1kjlApZ1yUPnQX7YvmBIE4iJJiKawaDGsm5Ly1a76bBMffX7Lb9qKN6x 87UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=WmIQ59Di; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p5-20020a637f45000000b00534882d5329si2433957pgn.762.2023.05.25.20.18.13; Thu, 25 May 2023 20:18:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=WmIQ59Di; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241917AbjEZDHM (ORCPT <rfc822;zhanglyra.2023@gmail.com> + 99 others); Thu, 25 May 2023 23:07:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231691AbjEZDGi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 25 May 2023 23:06:38 -0400 Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE27918D; Thu, 25 May 2023 20:06:22 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id ca18e2360f4ac-77491a28035so36039339f.2; Thu, 25 May 2023 20:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685070381; x=1687662381; 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=DRTsj12b6O33FC+cr8c7BPZ01uR7I3K/mmxNkVF4jws=; b=WmIQ59Di4v3M/mXQbgwi2pQoRYZielG4kZCCoqzPisHE+8DjvztO76vbRaQG41IpE/ 95lE0AlZ3kQ+DZ03BU2On7Il7WUetoWIgnXteDV7hCia8s4+hZ/U/lRjylif0+1OhpbU 5zVh0qb6kiwihMfRl36/KV8/loJcBiqqNBhwUSf/509WIfn7wmcbl0/ghiMHvEAE1KMj FE9JvYu75N8ewqC6Y2m8ynZ8eSAVKw/tzQ7JOKFn5l8EBHCduhYVk/s06zw03b/pKn4W VU9ruuT8LlTE7rRxUVzaGWaOLSrc50RqgmJUK6RQpgR9dH9Y/8oFIvuta8ITbhNyDZ/J X05g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685070381; x=1687662381; 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=DRTsj12b6O33FC+cr8c7BPZ01uR7I3K/mmxNkVF4jws=; b=EixwN7lY5lL5wbzBxn8EaX/5UreJlDcC2rPAufy5fC7E0JEWZzFSVW4F4fIs8ZUUXm CYyn8aK744UBQuK164+soc9FLO6nsYf2j7Ja5UeGl7pp9PNIp6XIN9eALsqKlR1xVh19 ufS4AyLVlg9j9LdBIzMzM/au09tdh4lZAaZJMkA18NGfDdQRpsrgWMNIgLZOkkTdoYwW dCpjHb4z2/VWTpr1vQmMjQWHUJP0yg+1SFYQcU8N+BxBxKfSOqsWUdTNDg/2NYkNPwmO syF79mw7+fNosJD6z+zkpUwAFwUynxOnPD/r0gTVrntudRghUAJFNf6sLMHlO61cmkxg hACg== X-Gm-Message-State: AC+VfDyjzjX+9/NSTQ9nvnqG/ugygKaH8VqR/9knKyf/tHgeQ8HjTzvj rv9DV8jaqa4YxJMKId8xct0= X-Received: by 2002:a6b:da0e:0:b0:774:8a30:a928 with SMTP id x14-20020a6bda0e000000b007748a30a928mr162926iob.5.1685070381381; Thu, 25 May 2023 20:06:21 -0700 (PDT) Received: from aford-B741.lan ([2601:447:d001:897f:3dd9:3f6c:9922:6420]) by smtp.gmail.com with ESMTPSA id i2-20020a5e8502000000b007702f55116fsm363189ioj.38.2023.05.25.20.06.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 May 2023 20:06:20 -0700 (PDT) From: Adam Ford <aford173@gmail.com> To: dri-devel@lists.freedesktop.org Cc: aford@beaconembedded.com, Adam Ford <aford173@gmail.com>, Inki Dae <inki.dae@samsung.com>, Jagan Teki <jagan@amarulasolutions.com>, Marek Szyprowski <m.szyprowski@samsung.com>, Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Frieder Schrempf <frieder.schrempf@kontron.de>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH V8 7/7] dt-bindings: bridge: samsung-dsim: Make some flags optional Date: Thu, 25 May 2023 22:05:59 -0500 Message-Id: <20230526030559.326566-8-aford173@gmail.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230526030559.326566-1-aford173@gmail.com> References: <20230526030559.326566-1-aford173@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766925121380087793?= X-GMAIL-MSGID: =?utf-8?q?1766925121380087793?= |
Series |
drm: bridge: samsung-dsim: Support variable clocking
|
|
Commit Message
Adam Ford
May 26, 2023, 3:05 a.m. UTC
In the event a device is connected to the samsung-dsim
controller that doesn't support the burst-clock, the
driver is able to get the requested pixel clock from the
attached device or bridge. In these instances, the
samsung,burst-clock-frequency isn't needed, so remove
it from the required list.
The pll-clock frequency can be set by the device tree entry
for samsung,pll-clock-frequency, but in some cases, the
pll-clock may have the same clock rate as sclk_mipi clock.
If they are equal, this flag is not needed since the driver
will use the sclk_mipi rate as a fallback.
Signed-off-by: Adam Ford <aford173@gmail.com>
---
.../bindings/display/bridge/samsung,mipi-dsim.yaml | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Comments
Adam, Neil, I meant to get to this earlier today, but broken CI got in the way... On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > In the event a device is connected to the samsung-dsim > controller that doesn't support the burst-clock, the > driver is able to get the requested pixel clock from the > attached device or bridge. In these instances, the > samsung,burst-clock-frequency isn't needed, so remove > it from the required list. > > The pll-clock frequency can be set by the device tree entry > for samsung,pll-clock-frequency, but in some cases, the > pll-clock may have the same clock rate as sclk_mipi clock. > If they are equal, this flag is not needed since the driver > will use the sclk_mipi rate as a fallback. > > Signed-off-by: Adam Ford <aford173@gmail.com> > --- > .../bindings/display/bridge/samsung,mipi-dsim.yaml | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > index 9f61ebdfefa8..360fea81f4b6 100644 > --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > @@ -70,7 +70,9 @@ properties: > samsung,burst-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM high speed burst mode frequency. > + DSIM high speed burst mode frequency when connected to devices > + that support burst mode. If absent, the driver will use the pixel > + clock from the attached device or bridge. I'd rather this description did not say anything about drivers. How about: If absent, the pixel clock from the attached device or bridge will be used instead. Or perhaps "must be used"? Ditto below. Description aside, the removal seems to be backwards compatible - but can every device that this binding supports work using an "attached device or bridge", or are these properties going to be required for certain compatibles? Thanks, Conor. > > samsung,esc-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > @@ -80,7 +82,8 @@ properties: > samsung,pll-clock-frequency: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > - DSIM oscillator clock frequency. > + DSIM oscillator clock frequency. If absent, the driver will > + use the clock frequency of sclk_mipi. > > phys: > maxItems: 1 > @@ -134,9 +137,7 @@ required: > - compatible > - interrupts > - reg > - - samsung,burst-clock-frequency > - samsung,esc-clock-frequency > - - samsung,pll-clock-frequency > > allOf: > - $ref: ../dsi-controller.yaml# > -- > 2.39.2 >
On Fri, May 26, 2023 at 1:19 PM Conor Dooley <conor@kernel.org> wrote: > > Adam, Neil, > > I meant to get to this earlier today, but broken CI got in the way... > > On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > > In the event a device is connected to the samsung-dsim > > controller that doesn't support the burst-clock, the > > driver is able to get the requested pixel clock from the > > attached device or bridge. In these instances, the > > samsung,burst-clock-frequency isn't needed, so remove > > it from the required list. > > > > The pll-clock frequency can be set by the device tree entry > > for samsung,pll-clock-frequency, but in some cases, the > > pll-clock may have the same clock rate as sclk_mipi clock. > > If they are equal, this flag is not needed since the driver > > will use the sclk_mipi rate as a fallback. > > > > Signed-off-by: Adam Ford <aford173@gmail.com> > > --- > > .../bindings/display/bridge/samsung,mipi-dsim.yaml | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > index 9f61ebdfefa8..360fea81f4b6 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > @@ -70,7 +70,9 @@ properties: > > samsung,burst-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > - DSIM high speed burst mode frequency. > > + DSIM high speed burst mode frequency when connected to devices > > + that support burst mode. If absent, the driver will use the pixel > > + clock from the attached device or bridge. > > I'd rather this description did not say anything about drivers. > How about: > If absent, the pixel clock from the attached device or bridge > will be used instead. That makes sense. I can do that. "DSIM high speed burst mode frequency (optional). If absent, the pixel clock from the attached device or bridge will be used instead." > Or perhaps "must be used"? Ditto below. "Must be" implies to me that the user needs to set something. Are you ok with the proposed suggestion above? > > Description aside, the removal seems to be backwards compatible - but > can every device that this binding supports work using an "attached > device or bridge", or are these properties going to be required for > certain compatibles? From what I can tell, the assumption is that the DSIM driver was expecting it to attach to panels in the past. With the additional patch series, the DSIM can attach to bridge parts without a hard-coded set of clocks. I don't expect the existing Exynos devices to change, but I also don't know what would preclude those SoC's from attaching to a bridge should someone want to design a new product around them. I'll wait a couple days for more feedback and send patch V2 with just this patch since the rest of the series has been applied to the drm branch. adam > > Thanks, > Conor. > > > > > samsung,esc-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > @@ -80,7 +82,8 @@ properties: > > samsung,pll-clock-frequency: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: > > - DSIM oscillator clock frequency. > > + DSIM oscillator clock frequency. If absent, the driver will > > + use the clock frequency of sclk_mipi. > > > > phys: > > maxItems: 1 > > @@ -134,9 +137,7 @@ required: > > - compatible > > - interrupts > > - reg > > - - samsung,burst-clock-frequency > > - samsung,esc-clock-frequency > > - - samsung,pll-clock-frequency > > > > allOf: > > - $ref: ../dsi-controller.yaml# > > -- > > 2.39.2 > >
On Fri, May 26, 2023 at 02:24:21PM -0500, Adam Ford wrote: > On Fri, May 26, 2023 at 1:19 PM Conor Dooley <conor@kernel.org> wrote: > > On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > > > description: > > > - DSIM high speed burst mode frequency. > > > + DSIM high speed burst mode frequency when connected to devices > > > + that support burst mode. If absent, the driver will use the pixel > > > + clock from the attached device or bridge. > > > > I'd rather this description did not say anything about drivers. > > How about: > > If absent, the pixel clock from the attached device or bridge > > will be used instead. > > That makes sense. I can do that. > > "DSIM high speed burst mode frequency (optional). If absent, the pixel > clock from the attached device or bridge will be used instead." > > > Or perhaps "must be used"? Ditto below. > > "Must be" implies to me that the user needs to set something. Are you > ok with the proposed suggestion above? > > > > Description aside, the removal seems to be backwards compatible - but > > can every device that this binding supports work using an "attached > > device or bridge", or are these properties going to be required for > > certain compatibles? > > From what I can tell, the assumption is that the DSIM driver was > expecting it to attach to panels in the past. With the additional > patch series, the DSIM can attach to bridge parts without a hard-coded > set of clocks. I don't expect the existing Exynos devices to change, > but I also don't know what would preclude those SoC's from attaching > to a bridge should someone want to design a new product around them. Okay, that seems fair. With your revised wording, Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > I'll wait a couple days for more feedback and send patch V2 with just > this patch since the rest of the series has been applied to the drm > branch. Sounds good. Krzysztof will hopefully be able to take a look then too to make sure I am not making a hames of things. Thanks, Conor.
On 26/05/2023 21:30, Conor Dooley wrote: > On Fri, May 26, 2023 at 02:24:21PM -0500, Adam Ford wrote: >> On Fri, May 26, 2023 at 1:19 PM Conor Dooley <conor@kernel.org> wrote: >>> On Thu, May 25, 2023 at 10:05:59PM -0500, Adam Ford wrote: > >>>> description: >>>> - DSIM high speed burst mode frequency. >>>> + DSIM high speed burst mode frequency when connected to devices >>>> + that support burst mode. If absent, the driver will use the pixel >>>> + clock from the attached device or bridge. >>> >>> I'd rather this description did not say anything about drivers. >>> How about: >>> If absent, the pixel clock from the attached device or bridge >>> will be used instead. >> >> That makes sense. I can do that. >> >> "DSIM high speed burst mode frequency (optional). If absent, the pixel >> clock from the attached device or bridge will be used instead." >> >>> Or perhaps "must be used"? Ditto below. >> >> "Must be" implies to me that the user needs to set something. Are you >> ok with the proposed suggestion above? >>> >>> Description aside, the removal seems to be backwards compatible - but >>> can every device that this binding supports work using an "attached >>> device or bridge", or are these properties going to be required for >>> certain compatibles? >> >> From what I can tell, the assumption is that the DSIM driver was >> expecting it to attach to panels in the past. With the additional >> patch series, the DSIM can attach to bridge parts without a hard-coded >> set of clocks. I don't expect the existing Exynos devices to change, >> but I also don't know what would preclude those SoC's from attaching >> to a bridge should someone want to design a new product around them. > > Okay, that seems fair. With your revised wording, > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > >> >> I'll wait a couple days for more feedback and send patch V2 with just >> this patch since the rest of the series has been applied to the drm >> branch. > > Sounds good. Krzysztof will hopefully be able to take a look then too to > make sure I am not making a hames of things. We should avoid references to driver, because bindings are used also in other projects where driver can behave differently. Also "driver" is then ambiguous - which driver do you mean? Please re-phrase. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml index 9f61ebdfefa8..360fea81f4b6 100644 --- a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -70,7 +70,9 @@ properties: samsung,burst-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM high speed burst mode frequency. + DSIM high speed burst mode frequency when connected to devices + that support burst mode. If absent, the driver will use the pixel + clock from the attached device or bridge. samsung,esc-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 @@ -80,7 +82,8 @@ properties: samsung,pll-clock-frequency: $ref: /schemas/types.yaml#/definitions/uint32 description: - DSIM oscillator clock frequency. + DSIM oscillator clock frequency. If absent, the driver will + use the clock frequency of sclk_mipi. phys: maxItems: 1 @@ -134,9 +137,7 @@ required: - compatible - interrupts - reg - - samsung,burst-clock-frequency - samsung,esc-clock-frequency - - samsung,pll-clock-frequency allOf: - $ref: ../dsi-controller.yaml#