Message ID | 20230314115644.3775169-8-gerald.loacker@wolfvision.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1720680wrd; Tue, 14 Mar 2023 05:15:49 -0700 (PDT) X-Google-Smtp-Source: AK7set/xJO4qBx48KpCuz20+Z16swCXxvY1S+L4rArHO9xq053+OoB8hBw9mEjAmg6N6mjytxNVw X-Received: by 2002:a17:90b:3911:b0:237:9cc7:28a6 with SMTP id ob17-20020a17090b391100b002379cc728a6mr37350915pjb.26.1678796148960; Tue, 14 Mar 2023 05:15:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1678796148; cv=pass; d=google.com; s=arc-20160816; b=ls7Bm3CfFQp/Q/h6amOqGXNyTPftr++9tF9j1OtKkq8zZDAoQyPOfvOScK3Yd0d/bO iHhNFc6hdReUHoBhQV6ZORvILCPgWRqHN6ydDV494OuUWewJE5su4CtR6xzCiCcfyeVh Kp8dFh4pitg1/pnHm0xcs5B2OuDQb2ZFGoMy2kED4Ve54UIeg19+KMRzW5LUIpxfMDI3 kxNv69i3ze5KPwuGuuNaHsLY5y5bm3sF6yRRUGYChsPmoeLlP4nxnvivo8ZBNGJSHGR9 yoLnG71cE2ePFKHgnCfjZSDXTvusWdNZA8ERU/lOCi5GKDuhpPI2PGam4MhNmt9k/qAx HM0Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=iyzrg9ClFD1gCBL4xDfxIUxvo3lZIeCuT3Bu0s0q6mU=; b=iE9F/oNNODYv1c3T+WQAinQ6oALLoi7vR7gQ1eIWD48ry+iv9iYcYdUnPQbQqdhtOC 54IboMYu2t6bSSpPq4t7vskZtulf/UyBt6BauybJzHxYMB4F5vWON0rJsJBBcYmG314J vYYHFWydMpZUTKFbi5WnOrZ663gT5nEFklwg4TSSECsJGbVZd490ImSm6M7n+D0qS9jI BDAi/hJP6tbNiEmVC0rUD6ZKttas3bIOjrw6XEoPMRFzmFXiAK8tDF64pqeIGjT/CaVI lGtmtPhWPcKLCrGKO349E3OHegTYrGy7MU5amcjFMJ6TCy6nLnHt5WDDHtBpxK5Vr5dd S0sA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@wolfvision.net header.s=selector2 header.b=vt8NrAGk; arc=pass (i=1 spf=pass spfdomain=wolfvision.net dkim=pass dkdomain=wolfvision.net dmarc=pass fromdomain=wolfvision.net); 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=wolfvision.net Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp11-20020a17090b190b00b0022c24bf1810si2336169pjb.29.2023.03.14.05.15.35; Tue, 14 Mar 2023 05:15:48 -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=@wolfvision.net header.s=selector2 header.b=vt8NrAGk; arc=pass (i=1 spf=pass spfdomain=wolfvision.net dkim=pass dkdomain=wolfvision.net dmarc=pass fromdomain=wolfvision.net); 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=wolfvision.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231641AbjCNMAC (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Tue, 14 Mar 2023 08:00:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231685AbjCNL7j (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Mar 2023 07:59:39 -0400 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on062a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3C2824BE0; Tue, 14 Mar 2023 04:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R0tCS4oKu9QJJDI7tHLwdkD6SNm3QAeh5NULYq7hFZRIn4MGyXGil0jqNGoUmDR/+XzaCLZMGwvGTnkpz8knmpUI8d3ncGMm7RsPRaNX7RorepkD1jCtY9vU22pBl6mPBQk6D9n4AOwCRVbxX7j1G/ptK7s7x8fzdFtKVm8MrMUH2/xkVEhABBuHQPDjVp8LKtNjCRp5u/zKEtJTWPbfrP/2oyMwu9D8x8twjgQLEncuv742H5zqTDySa57O7IM3WxLa0XMommjBcF25yFaMD3mVQF63WEhsjfuk13Tvvo+yHZK71zSxvLowVSvnXUl7ysVi1T9ndn26MlF1peKOeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iyzrg9ClFD1gCBL4xDfxIUxvo3lZIeCuT3Bu0s0q6mU=; b=QP0ctOr3Cb1VKxwtbx7wps8H60qffAgt9PecI6wp9T+MKFG/1oZuPcqgVXgP6iHjR/CvLz3yGSz8QA8bH5Z51ZCtlKx8JsqeJFH3icgROUKQ0P6jP4w3hYr0yVuGHJ3nj8PYlesneGfPIbr9/WW049EX+v6DdDxUL8lNwnHIukgnXoHRJZwHfryVy0ET0m6QvztTXnSMeUKPoLDnyPDy24b5kTw5iNrKIDj+4GtId1QmAdX1gIRdcs7p44zJPXhMElfuZGp3flxvoAJGev3c6SThP1hVe2ENIaz9IBy/hGcOH+a/FMyZZ5gCZUuDEDm7VzSEUN37I6ot/3lCJz+o5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wolfvision.net; dmarc=pass action=none header.from=wolfvision.net; dkim=pass header.d=wolfvision.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfvision.net; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iyzrg9ClFD1gCBL4xDfxIUxvo3lZIeCuT3Bu0s0q6mU=; b=vt8NrAGk+0Wqp3Rv34iMA0/IojGkrm3ZsCofXbZBouj8x0N9KTbAKWxk4ZbWhPNSGuoGb0GXZ785l42Rd+LiumA5d4GlfN4SYtmQGl0GeEbqNXA+FAVin53iSW66UtRhJ5VunE+UY/tLhvlCKE9PKAxp/gf2hXwHdxjqrAP7eM0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=wolfvision.net; Received: from VI1PR08MB4544.eurprd08.prod.outlook.com (2603:10a6:803:100::13) by AS8PR08MB9313.eurprd08.prod.outlook.com (2603:10a6:20b:5a4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.26; Tue, 14 Mar 2023 11:57:10 +0000 Received: from VI1PR08MB4544.eurprd08.prod.outlook.com ([fe80::b094:4fd2:abe3:9f08]) by VI1PR08MB4544.eurprd08.prod.outlook.com ([fe80::b094:4fd2:abe3:9f08%4]) with mapi id 15.20.6178.024; Tue, 14 Mar 2023 11:57:10 +0000 From: Gerald Loacker <gerald.loacker@wolfvision.net> To: dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Thierry Reding <thierry.reding@gmail.com>, Sam Ravnborg <sam@ravnborg.org>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Maxime Ripard <mripard@kernel.org>, Michael Riesch <michael.riesch@wolfvision.net>, Gerald Loacker <gerald.loacker@wolfvision.net> Subject: [PATCH 7/7] dt-bindings: display: add panel-timing property to sitronix,st7789v Date: Tue, 14 Mar 2023 12:56:44 +0100 Message-Id: <20230314115644.3775169-8-gerald.loacker@wolfvision.net> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20230314115644.3775169-1-gerald.loacker@wolfvision.net> References: <20230314115644.3775169-1-gerald.loacker@wolfvision.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: VI1PR0802CA0032.eurprd08.prod.outlook.com (2603:10a6:800:a9::18) To VI1PR08MB4544.eurprd08.prod.outlook.com (2603:10a6:803:100::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR08MB4544:EE_|AS8PR08MB9313:EE_ X-MS-Office365-Filtering-Correlation-Id: 6eec2d57-fdf5-4ff9-e4f9-08db24833df3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: r+jPk7yndMG9zzFLnHGquYyUAgIc1hPKRTcDaSbJJ+GQ7Q4lgs1FDJJmssgFtkQchAJIfCoxSl0xMPYnL8xsh7jYg6nVmV9S9x9L7RwD2pdfk8zBUtlQPBybL+mPkFP0QCByIVcnfWPrAcjKeOXVB2/9Or2rV1Z6RsDTZIOrEykQ3ybZ1xXy4xxt/dFYytyNjYIqkUq7I5XV93zl3Wbxh+csmmrDzmi9LcCOfNMpkGxEYKHmaK+kZX7pZBpE70eTbizuc1A0YZzqyGY6of7Ic3DAg6b2pWvVg+z/iBeccxu7WSrSnoPBLzNOBMbHxJ0h6/fgocEIQjxeCR5S6H3QazZYRpNFP/TlMw6U2LoiUy7A9RpMtkIXjxFHZYzCkz0vc7jFrtz0kOV0JnWLzH7soH/vKefi+dQrbch1YRYEjXPm1tRufVdzzoLQbsLM9+XrtP3PlJORq92sPMy7TEL1/6y+m1MlxRMfNVXjp8xHF71sFxKyqhyDSVghQg1kfLNFnfSWaO9ORrnCiW5xbmPy/JqwjyeJdjBhHspqbycV2HADUuvtHPqTXfUgwxzY4Ap+m0kRlYFFEGYQVWs0V+IILRM5A4GwpjpCKeniv/6X5G4hshojbi9FGt5Uce5pcHt3qdMpaH5KChW+0nZ5Y7xC2TBX7WXLR70D7ucBxNFn2121mOlOni5by8KiwNDekcumQR7NgzvejxiMIs4BVylyXg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB4544.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(366004)(346002)(376002)(396003)(39850400004)(136003)(451199018)(478600001)(52116002)(186003)(26005)(83380400001)(107886003)(6666004)(6486002)(66556008)(54906003)(66476007)(316002)(6506007)(2616005)(66946007)(6512007)(8676002)(41300700001)(4326008)(1076003)(8936002)(44832011)(5660300002)(7416002)(38100700002)(38350700002)(2906002)(36756003)(86362001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ZIctTdp6IT9lGQeUfXGsx6aBI0Tgtitqz2Q68KPYZdkg4sVD0zqPyU6Z6DiPawEk0eifs/XQatH513JwT44Aog9O6oEbk0S4Itad1fmB1YKmwS+iuhaTMM5QgIw8NnjYxuX6xrQww+TToO3DaBJbJI3kGa9yfJ8hTgiXGpGG9oGrwKDI6vbcAyc6mCAIMc5YZGINwHZabUjpiN5xDACJJkeNRCHk2gWq3txd/9x2odFOeaMdv4BL/Y8gKY07gnbqmGicpImsM4VM/3f9aUWK/1yNKttvpY1357twYJ7ZBwQQN2a93TpQk4RuUbnjJS971PR3goQua26yKvSnd76qT7VNmnVDFM8L2HOQS+H3aEKnMLohG+YpbKOnWJrtwehE9zlCnjc1fzvqgb/ixgiaprWu62ADLvsvMjl7J7zXp50pJuAri9SgqyMSrI3vNrLhC6vqucCmE4BNH309U+tyfM7/Bmiip70gVmD4Hu5EtThiMs6rXH/rWGn7f1LGWZW/wkOFeuj/v38MY6Ni//yXK9fpIzAs+vCJYgp6a3x86EK8hHFieEWC1+q5sscUrCLaQ/SPqTyW6J6IAyW628LKRAxkZqL810kkPehmNFcSaS0SVOH4gbmE2KgKGH8F2BVR2bZStbks7KFMsZsx9eaj45+a4Q13jU5H7L3Z7dsRew+FU3owSYR0qHifOg9wQfAK4gYfstz0+h9fwcBWpkv1e7ewysxfdvW1+WnvJ0w52rvAMOahHNshCZsbygjF1tYbDpBIf2kMLYJ6YvB6Gs0+BcRiW9+6WR18hCVCczCMmDySvdtwHR693ZRuLlfMOGF1GANg1OgLCuZ6kswEymFDMD3lQhEnWTSZ9T16k1Ugq8k5woaIThJ7VVR/USZ+e73dKo+6EtexKl3x3rBGY11TALbYeLde1cQRAsXuP/siR9m1UB3s3TcG+hGh67DAt88/PLFkRXLYDhrzww1cu+5S5xCEItInGuK72Y85uKyPr7uI8P2XGeOXVRIVIp2sYTGCbOljJqIww0VZ28o8qAKvrFBvvvNq2es6HF4dMHm45FcCMTXM5WA4olU3xT2+VcmDheN8IyzjLLPM9aRI25qro04EKQtKLX4GpQtBxAMkeyOg1mLrTcCEhJc0Bn2jIHLxXN32KRwtuIZfv7aoIqR/79eyCrSkn25kzW9txhfMAK/X6x5fohLtQVT0q653AYFlKESBN5BVh9H2uI977gB2sQW1MXVZsGSNS0m+UuuWNh8KXdrWW5PwqwpEL1ACwDeWhxNHJJ3ovXV0gyLq83FGI7V4vm6APo0aYrc4d4+CQBNJ+ihF1CivU20EIpNAb0VbYFD8P9mzBeJiroYJJftr74U4ALXn5cfMDaMek7r7SXKjw+jMuqSX4poiKUIQkDV9IyvTNJ3TNt2vjGb/0oSUcX6MJOqZqdHhlOYvuMrPd4lTOufXze+L7IniE0EtmediRzH6hHp9LX2Vlye3ptRC0kjnHe97OEdvFUXFrcTZcfqR1Dq/M4gM21jl0c3ycQUdGBTahLWQIv6N2kKntwnzuHV6Y45H8Al95V9cobClU5oyXZy45MDjob26oz+T0DRgLC2cyDRENXGUllUWdmltrKQk7vEETSPh7o9IBUVl364= X-OriginatorOrg: wolfvision.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6eec2d57-fdf5-4ff9-e4f9-08db24833df3 X-MS-Exchange-CrossTenant-AuthSource: VI1PR08MB4544.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2023 11:57:10.3173 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e94ec9da-9183-471e-83b3-51baa8eb804f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vuII/TWDWdLnvurTZb7qisEo1xLTwo4zuvUB8qIcs4NdleyUHgy0b6D0m0yqidC97B0KWEnfavRLCeLBHWTodXOHpFJxwMSBDQTkLPRRm2Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9313 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, URIBL_BLOCKED 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?1760345350518352089?= X-GMAIL-MSGID: =?utf-8?q?1760345350518352089?= |
Series |
Add timing override to sitronix,st7789v
|
|
Commit Message
Gerald Loacker
March 14, 2023, 11:56 a.m. UTC
The sitronix-st7789v driver now considers the panel-timing property.
Add the property to the documentation.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
.../display/panel/sitronix,st7789v.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Comments
On 14/03/2023 12:56, Gerald Loacker wrote: > The sitronix-st7789v driver now considers the panel-timing property. > Add the property to the documentation. > > Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: > The sitronix-st7789v driver now considers the panel-timing property. I read the patch for that and still don't know 'why'. Commit messages should answer why. > Add the property to the documentation. We generally don't put timings in DT for panels. Why is this one special? > > Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> > --- > .../display/panel/sitronix,st7789v.yaml | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml > index ed942cd3620f..8810f123dedf 100644 > --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml > +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml > @@ -21,6 +21,7 @@ properties: > reset-gpios: true > power-supply: true > backlight: true > + panel-timing: true > port: true > rotation: true > > @@ -54,6 +55,22 @@ examples: > spi-cpol; > spi-cpha; > > + panel-timing { > + clock-frequency = <7000000>; > + hactive = <240>; > + vactive = <320>; > + hfront-porch = <38>; > + hback-porch = <10>; > + hsync-len = <10>; > + vfront-porch = <8>; > + vback-porch = <4>; > + vsync-len = <4>; > + hsync-active = <1>; > + vsync-active = <1>; > + de-active = <1>; > + pixelclk-active = <1>; > + }; > + > port { > panel_input: endpoint { > remote-endpoint = <&tcon0_out_panel>; > -- > 2.37.2 >
Hi Rob, On 3/16/23 22:57, Rob Herring wrote: > On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: >> The sitronix-st7789v driver now considers the panel-timing property. > > I read the patch for that and still don't know 'why'. Commit messages > should answer why. > >> Add the property to the documentation. > > We generally don't put timings in DT for panels. Why is this one > special? For now, having the timings in the device tree allows for setting the hsync/vsync/de polarity. As a next step, we aim to implement the partial mode feature of this panel. It is possible to use only a certain region of the panel, which is helpful e.g., when a part of the panel is occluded and should not be considered by DRM. We thought that this could be specified as timing in DT. (The hactive and vactive properties serve as dimensions of this certain region, of course. We still need to specify somehow the position of the region. Maybe with additional properties hactive-start and vactive-start?) What do you think about that? Thanks and best regards, Michael > >> >> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net> >> --- >> .../display/panel/sitronix,st7789v.yaml | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml >> index ed942cd3620f..8810f123dedf 100644 >> --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml >> +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml >> @@ -21,6 +21,7 @@ properties: >> reset-gpios: true >> power-supply: true >> backlight: true >> + panel-timing: true >> port: true >> rotation: true >> >> @@ -54,6 +55,22 @@ examples: >> spi-cpol; >> spi-cpha; >> >> + panel-timing { >> + clock-frequency = <7000000>; >> + hactive = <240>; >> + vactive = <320>; >> + hfront-porch = <38>; >> + hback-porch = <10>; >> + hsync-len = <10>; >> + vfront-porch = <8>; >> + vback-porch = <4>; >> + vsync-len = <4>; >> + hsync-active = <1>; >> + vsync-active = <1>; >> + de-active = <1>; >> + pixelclk-active = <1>; >> + }; >> + >> port { >> panel_input: endpoint { >> remote-endpoint = <&tcon0_out_panel>; >> -- >> 2.37.2 >>
On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote: > Hi Rob, > > On 3/16/23 22:57, Rob Herring wrote: > > On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: > >> The sitronix-st7789v driver now considers the panel-timing property. > > > > I read the patch for that and still don't know 'why'. Commit messages > > should answer why. > > > >> Add the property to the documentation. > > > > We generally don't put timings in DT for panels. Why is this one > > special? > > For now, having the timings in the device tree allows for setting the > hsync/vsync/de polarity. > > As a next step, we aim to implement the partial mode feature of this > panel. It is possible to use only a certain region of the panel, which > is helpful e.g., when a part of the panel is occluded and should not be > considered by DRM. We thought that this could be specified as timing in DT. > > (The hactive and vactive properties serve as dimensions of this certain > region, of course. We still need to specify somehow the position of the > region. Maybe with additional properties hactive-start and vactive-start?) > > What do you think about that? I don't see why we would need the device tree to support that. What you described is essentially what overscan is for HDMI/analog output, and we already have everything to deal with overscan properly in KMS. Maxime
Hi Maxime, On 3/29/23 11:16, Maxime Ripard wrote: > On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote: >> Hi Rob, >> >> On 3/16/23 22:57, Rob Herring wrote: >>> On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: >>>> The sitronix-st7789v driver now considers the panel-timing property. >>> >>> I read the patch for that and still don't know 'why'. Commit messages >>> should answer why. >>> >>>> Add the property to the documentation. >>> >>> We generally don't put timings in DT for panels. Why is this one >>> special? >> >> For now, having the timings in the device tree allows for setting the >> hsync/vsync/de polarity. >> >> As a next step, we aim to implement the partial mode feature of this >> panel. It is possible to use only a certain region of the panel, which >> is helpful e.g., when a part of the panel is occluded and should not be >> considered by DRM. We thought that this could be specified as timing in DT. >> >> (The hactive and vactive properties serve as dimensions of this certain >> region, of course. We still need to specify somehow the position of the >> region. Maybe with additional properties hactive-start and vactive-start?) >> >> What do you think about that? > > I don't see why we would need the device tree to support that. What you > described is essentially what overscan is for HDMI/analog output, and we > already have everything to deal with overscan properly in KMS. Thanks for your response, but I am afraid I don't quite follow. How are we supposed to expose control over the hsync/vsync/data enable polarity? I only know that the display controller and the panel need to agree on a setting that works for both. What is the canonical way to do this? A different question is the partial mode, for which (IIUC) you suggest the overscan feature. As I have never heard of this before, it would be very nice if you could point me to some examples. Where would the effective resolution be set in this case? We thought that this should enter the device tree as in our case the display is partially occluded due to hardware constraints. For the user there is only one reasonable configuration. Alternatively, we could follow a different approach and handle a separate compatible in the panel driver. Would this be acceptable for mainline inclusion? Best regards, Michael
On Wed, Mar 29, 2023 at 12:08:50PM +0200, Michael Riesch wrote: > On 3/29/23 11:16, Maxime Ripard wrote: > > On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote: > >> Hi Rob, > >> > >> On 3/16/23 22:57, Rob Herring wrote: > >>> On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: > >>>> The sitronix-st7789v driver now considers the panel-timing property. > >>> > >>> I read the patch for that and still don't know 'why'. Commit messages > >>> should answer why. > >>> > >>>> Add the property to the documentation. > >>> > >>> We generally don't put timings in DT for panels. Why is this one > >>> special? > >> > >> For now, having the timings in the device tree allows for setting the > >> hsync/vsync/de polarity. > >> > >> As a next step, we aim to implement the partial mode feature of this > >> panel. It is possible to use only a certain region of the panel, which > >> is helpful e.g., when a part of the panel is occluded and should not be > >> considered by DRM. We thought that this could be specified as timing in DT. > >> > >> (The hactive and vactive properties serve as dimensions of this certain > >> region, of course. We still need to specify somehow the position of the > >> region. Maybe with additional properties hactive-start and vactive-start?) > >> > >> What do you think about that? > > > > I don't see why we would need the device tree to support that. What you > > described is essentially what overscan is for HDMI/analog output, and we > > already have everything to deal with overscan properly in KMS. > > Thanks for your response, but I am afraid I don't quite follow. > > How are we supposed to expose control over the hsync/vsync/data enable > polarity? I only know that the display controller and the panel need to > agree on a setting that works for both. What is the canonical way to do > this? So typically, it would come from the panel datasheet and would thus be exposed by the panel driver. st7789v is not a panel itself but a (pretty flexible) panel controller so it's not fixed and I don't think we have a good answer to that (yet). > A different question is the partial mode, for which (IIUC) you suggest > the overscan feature. As I have never heard of this before, it would be > very nice if you could point me to some examples. Where would the > effective resolution be set in this case? So, back when CRT were a thing the edges of the tube were masked by the plastic case. HDMI inherited from that and that's why you still have some UI on some devices (like consoles) to setup the active area of the display. The underlying issue is exactly what you describe: the active area is larger than what the plastic case allows to see. I don't think anyone ever had the usecase you have, but it would be the right solution to me to solve essentially the same issue the same way we do on other output types. Maxime
Hi Maxime, On 3/30/23 16:58, Maxime Ripard wrote: > On Wed, Mar 29, 2023 at 12:08:50PM +0200, Michael Riesch wrote: >> On 3/29/23 11:16, Maxime Ripard wrote: >>> On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote: >>>> Hi Rob, >>>> >>>> On 3/16/23 22:57, Rob Herring wrote: >>>>> On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: >>>>>> The sitronix-st7789v driver now considers the panel-timing property. >>>>> >>>>> I read the patch for that and still don't know 'why'. Commit messages >>>>> should answer why. >>>>> >>>>>> Add the property to the documentation. >>>>> >>>>> We generally don't put timings in DT for panels. Why is this one >>>>> special? >>>> >>>> For now, having the timings in the device tree allows for setting the >>>> hsync/vsync/de polarity. >>>> >>>> As a next step, we aim to implement the partial mode feature of this >>>> panel. It is possible to use only a certain region of the panel, which >>>> is helpful e.g., when a part of the panel is occluded and should not be >>>> considered by DRM. We thought that this could be specified as timing in DT. >>>> >>>> (The hactive and vactive properties serve as dimensions of this certain >>>> region, of course. We still need to specify somehow the position of the >>>> region. Maybe with additional properties hactive-start and vactive-start?) >>>> >>>> What do you think about that? >>> >>> I don't see why we would need the device tree to support that. What you >>> described is essentially what overscan is for HDMI/analog output, and we >>> already have everything to deal with overscan properly in KMS. >> >> Thanks for your response, but I am afraid I don't quite follow. >> >> How are we supposed to expose control over the hsync/vsync/data enable >> polarity? I only know that the display controller and the panel need to >> agree on a setting that works for both. What is the canonical way to do >> this? > > So typically, it would come from the panel datasheet and would thus be > exposed by the panel driver. st7789v is not a panel itself but a (pretty > flexible) panel controller so it's not fixed and I don't think we have a > good answer to that (yet). Then it seems to me that creating a panel driver (= st8879v panel controller driver with a new compatible) would make sense. By coincidence Sebastian Reichel has come up with this approach recently, see https://lore.kernel.org/dri-devel/20230317232355.1554980-1-sre@kernel.org/ We just need a way to resolve the conflicts between the two series. Cc: Sebastian >> A different question is the partial mode, for which (IIUC) you suggest >> the overscan feature. As I have never heard of this before, it would be >> very nice if you could point me to some examples. Where would the >> effective resolution be set in this case? > > So, back when CRT were a thing the edges of the tube were masked by the > plastic case. HDMI inherited from that and that's why you still have > some UI on some devices (like consoles) to setup the active area of the > display. > > The underlying issue is exactly what you describe: the active area is > larger than what the plastic case allows to see. I don't think anyone > ever had the usecase you have, but it would be the right solution to me > to solve essentially the same issue the same way we do on other output > types. OK, we'll look into the overscan feature. But still the information about the active area should come from the driver, right? Thanks and best regards, Michael
On Fri, Mar 31, 2023 at 11:36:43AM +0200, Michael Riesch wrote: > On 3/30/23 16:58, Maxime Ripard wrote: > > On Wed, Mar 29, 2023 at 12:08:50PM +0200, Michael Riesch wrote: > >> On 3/29/23 11:16, Maxime Ripard wrote: > >>> On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote: > >>>> Hi Rob, > >>>> > >>>> On 3/16/23 22:57, Rob Herring wrote: > >>>>> On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: > >>>>>> The sitronix-st7789v driver now considers the panel-timing property. > >>>>> > >>>>> I read the patch for that and still don't know 'why'. Commit messages > >>>>> should answer why. > >>>>> > >>>>>> Add the property to the documentation. > >>>>> > >>>>> We generally don't put timings in DT for panels. Why is this one > >>>>> special? > >>>> > >>>> For now, having the timings in the device tree allows for setting the > >>>> hsync/vsync/de polarity. > >>>> > >>>> As a next step, we aim to implement the partial mode feature of this > >>>> panel. It is possible to use only a certain region of the panel, which > >>>> is helpful e.g., when a part of the panel is occluded and should not be > >>>> considered by DRM. We thought that this could be specified as timing in DT. > >>>> > >>>> (The hactive and vactive properties serve as dimensions of this certain > >>>> region, of course. We still need to specify somehow the position of the > >>>> region. Maybe with additional properties hactive-start and vactive-start?) > >>>> > >>>> What do you think about that? > >>> > >>> I don't see why we would need the device tree to support that. What you > >>> described is essentially what overscan is for HDMI/analog output, and we > >>> already have everything to deal with overscan properly in KMS. > >> > >> Thanks for your response, but I am afraid I don't quite follow. > >> > >> How are we supposed to expose control over the hsync/vsync/data enable > >> polarity? I only know that the display controller and the panel need to > >> agree on a setting that works for both. What is the canonical way to do > >> this? > > > > So typically, it would come from the panel datasheet and would thus be > > exposed by the panel driver. st7789v is not a panel itself but a (pretty > > flexible) panel controller so it's not fixed and I don't think we have a > > good answer to that (yet). > > Then it seems to me that creating a panel driver (= st8879v panel > controller driver with a new compatible) would make sense. I don't see why? The entire controller is the same except (maybe) for some initialization data. Doing a new driver for it seems like taking the easy way out? > By coincidence Sebastian Reichel has come up with this approach > recently, see > https://lore.kernel.org/dri-devel/20230317232355.1554980-1-sre@kernel.org/ > We just need a way to resolve the conflicts between the two series. > > Cc: Sebastian That's not a new driver though? That approach looks sane to me. > >> A different question is the partial mode, for which (IIUC) you suggest > >> the overscan feature. As I have never heard of this before, it would be > >> very nice if you could point me to some examples. Where would the > >> effective resolution be set in this case? > > > > So, back when CRT were a thing the edges of the tube were masked by the > > plastic case. HDMI inherited from that and that's why you still have > > some UI on some devices (like consoles) to setup the active area of the > > display. > > > > The underlying issue is exactly what you describe: the active area is > > larger than what the plastic case allows to see. I don't think anyone > > ever had the usecase you have, but it would be the right solution to me > > to solve essentially the same issue the same way we do on other output > > types. > > OK, we'll look into the overscan feature. But still the information > about the active area should come from the driver, right? No, the userspace is in charge there. Maxime
Hi Maxime, On 4/4/23 18:04, Maxime Ripard wrote: > On Fri, Mar 31, 2023 at 11:36:43AM +0200, Michael Riesch wrote: >> On 3/30/23 16:58, Maxime Ripard wrote: >>> On Wed, Mar 29, 2023 at 12:08:50PM +0200, Michael Riesch wrote: >>>> On 3/29/23 11:16, Maxime Ripard wrote: >>>>> On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote: >>>>>> Hi Rob, >>>>>> >>>>>> On 3/16/23 22:57, Rob Herring wrote: >>>>>>> On Tue, Mar 14, 2023 at 12:56:44PM +0100, Gerald Loacker wrote: >>>>>>>> The sitronix-st7789v driver now considers the panel-timing property. >>>>>>> >>>>>>> I read the patch for that and still don't know 'why'. Commit messages >>>>>>> should answer why. >>>>>>> >>>>>>>> Add the property to the documentation. >>>>>>> >>>>>>> We generally don't put timings in DT for panels. Why is this one >>>>>>> special? >>>>>> >>>>>> For now, having the timings in the device tree allows for setting the >>>>>> hsync/vsync/de polarity. >>>>>> >>>>>> As a next step, we aim to implement the partial mode feature of this >>>>>> panel. It is possible to use only a certain region of the panel, which >>>>>> is helpful e.g., when a part of the panel is occluded and should not be >>>>>> considered by DRM. We thought that this could be specified as timing in DT. >>>>>> >>>>>> (The hactive and vactive properties serve as dimensions of this certain >>>>>> region, of course. We still need to specify somehow the position of the >>>>>> region. Maybe with additional properties hactive-start and vactive-start?) >>>>>> >>>>>> What do you think about that? >>>>> >>>>> I don't see why we would need the device tree to support that. What you >>>>> described is essentially what overscan is for HDMI/analog output, and we >>>>> already have everything to deal with overscan properly in KMS. >>>> >>>> Thanks for your response, but I am afraid I don't quite follow. >>>> >>>> How are we supposed to expose control over the hsync/vsync/data enable >>>> polarity? I only know that the display controller and the panel need to >>>> agree on a setting that works for both. What is the canonical way to do >>>> this? >>> >>> So typically, it would come from the panel datasheet and would thus be >>> exposed by the panel driver. st7789v is not a panel itself but a (pretty >>> flexible) panel controller so it's not fixed and I don't think we have a >>> good answer to that (yet). >> >> Then it seems to me that creating a panel driver (= st8879v panel >> controller driver with a new compatible) would make sense. > > I don't see why? The entire controller is the same except (maybe) for > some initialization data. Doing a new driver for it seems like taking > the easy way out? > >> By coincidence Sebastian Reichel has come up with this approach >> recently, see >> https://lore.kernel.org/dri-devel/20230317232355.1554980-1-sre@kernel.org/ >> We just need a way to resolve the conflicts between the two series. >> >> Cc: Sebastian > > That's not a new driver though? That approach looks sane to me. Sorry for the ambiguity. The plan is now to add a new compatible to the st8879v panel controller driver. >>>> A different question is the partial mode, for which (IIUC) you suggest >>>> the overscan feature. As I have never heard of this before, it would be >>>> very nice if you could point me to some examples. Where would the >>>> effective resolution be set in this case? >>> >>> So, back when CRT were a thing the edges of the tube were masked by the >>> plastic case. HDMI inherited from that and that's why you still have >>> some UI on some devices (like consoles) to setup the active area of the >>> display. >>> >>> The underlying issue is exactly what you describe: the active area is >>> larger than what the plastic case allows to see. I don't think anyone >>> ever had the usecase you have, but it would be the right solution to me >>> to solve essentially the same issue the same way we do on other output >>> types. >> >> OK, we'll look into the overscan feature. But still the information >> about the active area should come from the driver, right? > > No, the userspace is in charge there. I'd prefer not to have the hardware description in user space. But we can continue this discussing once our v2 is out. Best regards, Michael
On Tue, Apr 04, 2023 at 06:26:25PM +0200, Michael Riesch wrote: > >>>> A different question is the partial mode, for which (IIUC) you suggest > >>>> the overscan feature. As I have never heard of this before, it would be > >>>> very nice if you could point me to some examples. Where would the > >>>> effective resolution be set in this case? > >>> > >>> So, back when CRT were a thing the edges of the tube were masked by the > >>> plastic case. HDMI inherited from that and that's why you still have > >>> some UI on some devices (like consoles) to setup the active area of the > >>> display. > >>> > >>> The underlying issue is exactly what you describe: the active area is > >>> larger than what the plastic case allows to see. I don't think anyone > >>> ever had the usecase you have, but it would be the right solution to me > >>> to solve essentially the same issue the same way we do on other output > >>> types. > >> > >> OK, we'll look into the overscan feature. But still the information > >> about the active area should come from the driver, right? > > > > No, the userspace is in charge there. > > I'd prefer not to have the hardware description in user space. But we > can continue this discussing once our v2 is out. I'm not sure if it's worth doing something if you don't agree with it :) At the end of the day, "the hardware" is a matter of semantics, and you would argue that it's only the (user) visible part of the display, and I would argue that it's the whole panel and we would both be somewhat right. The thing is: having the margins definition allows the userspace to be aware that there's overscan to deal with, and for example setup the scaler to properly display whatever you put in there. If you just report a weird mode that doesn't match any kind of standard, well, you could still do that, but you would need to tell the compositor which mode you would need to scale down from. In both case the userspace is involved. One is generic, the other isn't and probably requires some extra development. Maxime
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index ed942cd3620f..8810f123dedf 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -21,6 +21,7 @@ properties: reset-gpios: true power-supply: true backlight: true + panel-timing: true port: true rotation: true @@ -54,6 +55,22 @@ examples: spi-cpol; spi-cpha; + panel-timing { + clock-frequency = <7000000>; + hactive = <240>; + vactive = <320>; + hfront-porch = <38>; + hback-porch = <10>; + hsync-len = <10>; + vfront-porch = <8>; + vback-porch = <4>; + vsync-len = <4>; + hsync-active = <1>; + vsync-active = <1>; + de-active = <1>; + pixelclk-active = <1>; + }; + port { panel_input: endpoint { remote-endpoint = <&tcon0_out_panel>;