Message ID | 20231030192846.27934-1-a-bhatia1@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp2458128vqb; Mon, 30 Oct 2023 12:29:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IET1GBWzOaH4+yngygH3xTR6lRxotUKMXcbhSUZUf7lPzX9d0MEZ8tajhbGBt1muqWSSJib X-Received: by 2002:a17:902:ec88:b0:1cc:5306:e8a3 with SMTP id x8-20020a170902ec8800b001cc5306e8a3mr918078plg.3.1698694197681; Mon, 30 Oct 2023 12:29:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698694197; cv=none; d=google.com; s=arc-20160816; b=caim1Za/RafME/zQZEb5Ior6B3UkDI5y86Tp8QNTSyJ/poxGCAvLKUvpWJMoYGzX/m 3jzC96g+nD94intoGwD3j00ttwi/W0H+A2hdHr3b3uTD98Q4aFnVoccacgND9yQryZSi pVzgMG98wtWkjKVS1IdzeAz9AzupfFHQ+x9cXiVNS27JRQFeXadNmeAE85pX097y13pv SHWLnFRHVXkzxlHkoTuliYV/urQBn80L5RDGmfLvH/rwcq/MLUuXBxKzzbP9xMs/rCVd l7Dwn4pWeNqKvNiC2JR7MgY5oa/bM3pAjVywIVhflx5OELkgtZEh1Q6C68FRccdwQr09 2FRw== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=dmgtTJaq9wvJAB+uUOddVab2zm5yVAqq7CEhc68g0vA=; fh=TlS5PpL6elOTttZHu5yzmqNk5MGcxDngd2XOFA+0LpY=; b=xQCHjxT6NXTVRwUOv8cpEspOFrq+1Jxv1cmsjQb1Z85ftaYQQOVwj0Fg7+0fgrznkw MxPAoaq7w8fIO/XXE85zz0bVuNej5MydLQecdMCh1OjXPYwU5iWJs7lzE8jNo8Oxxrp1 zckLlTL1k3mo5CdgBmzW+00+PqqQ2l4OHTEV8vdIrUZPFHQBGDf/NepptVO6qgMhV44F oBPMDClqW7Rc4Jm0BIyxahrn9WB6zsseCRCFRMl577XQNKFrCRw3vigKt/m9aDP4ZYSt E+03v5yOuNeRvBigiUx0hdFNyfG3Cf/qNM1ClWD6hxIkgiMt2PXgzADmC9Owt5uxEJnr woFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=yxctoWir; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id u10-20020a17090282ca00b001c9e75f87edsi5360992plz.152.2023.10.30.12.29.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 12:29:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=yxctoWir; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id D7AE78047563; Mon, 30 Oct 2023 12:29:54 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229626AbjJ3T3j (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 32 others); Mon, 30 Oct 2023 15:29:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229735AbjJ3T3h (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Oct 2023 15:29:37 -0400 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73523DB for <linux-kernel@vger.kernel.org>; Mon, 30 Oct 2023 12:29:34 -0700 (PDT) Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 39UJSlsJ052235; Mon, 30 Oct 2023 14:28:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1698694127; bh=dmgtTJaq9wvJAB+uUOddVab2zm5yVAqq7CEhc68g0vA=; h=From:To:CC:Subject:Date; b=yxctoWireIpdlVDftZ8syS/0DiCdAkWsjzIaGp7A0w1uyEIagLw9wtxO/yi/i9UQT 0cqY6t3Iegob92/DXnsEt+VfpNQLRTK9gbiqJ5l/v4U6QaqFNBKe9JFPdyR3Ky9lwt +q3g6ME0C7yV0q7xDiPFRVmTtqpzmdoOXCq8w+t0= Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 39UJSlR7027257 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 30 Oct 2023 14:28:47 -0500 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 30 Oct 2023 14:28:47 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 30 Oct 2023 14:28:47 -0500 Received: from localhost (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 39UJSk5J053179; Mon, 30 Oct 2023 14:28:47 -0500 From: Aradhya Bhatia <a-bhatia1@ti.com> To: Tomi Valkeinen <tomba@kernel.org>, Jyri Sarha <jyri.sarha@iki.fi>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Boris Brezillon <boris.brezillon@collabora.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, Francesco Dolcini <francesco@dolcini.it>, Jan Kiszka <jan.kiszka@siemens.com>, Sam Ravnborg <sam@ravnborg.org> CC: DRI Development List <dri-devel@lists.freedesktop.org>, Linux Kernel List <linux-kernel@vger.kernel.org>, Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>, Devarsh Thakkar <devarsht@ti.com>, Jayesh Choudhary <j-choudhary@ti.com>, Aradhya Bhatia <a-bhatia1@ti.com> Subject: [PATCH] drm/bridge: tc358767: Support input format negotiation hook Date: Tue, 31 Oct 2023 00:58:46 +0530 Message-ID: <20231030192846.27934-1-a-bhatia1@ti.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 30 Oct 2023 12:29:54 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781209967090757686 X-GMAIL-MSGID: 1781209967090757686 |
Series |
drm/bridge: tc358767: Support input format negotiation hook
|
|
Commit Message
Aradhya Bhatia
Oct. 30, 2023, 7:28 p.m. UTC
With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.
Add the missing input-format negotiation hook in the
drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.
Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
the case with older model.
Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
---
Notes:
* Since I do not have hardware with me, this was just build tested. I would
appreciate it if someone could test and review it, especically somebody, who
uses the bridge for DPI/DSI to eDP format conversion.
* The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default,
when it should be. Hence, I sent a quick patch[0] earlier.
[0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/
drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
base-commit: c503e3eec382ac708ee7adf874add37b77c5d312
Comments
On 30.10.23 20:28, Aradhya Bhatia wrote: > With new connector model, tc358767 will not create the connector, when > DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will > rely on format negotiation to setup the encoder format. > > Add the missing input-format negotiation hook in the > drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. > > Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is > the case with older model. > > Reported-by: Jan Kiszka <jan.kiszka@siemens.com> > Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> > --- > > Notes: > > * Since I do not have hardware with me, this was just build tested. I would > appreciate it if someone could test and review it, especically somebody, who > uses the bridge for DPI/DSI to eDP format conversion. > > * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default, > when it should be. Hence, I sent a quick patch[0] earlier. > > [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ > > drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c > index ef2e373606ba..0affcefdeb1c 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > return input_fmts; > } > > +static u32 * > +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > + struct drm_bridge_state *bridge_state, > + struct drm_crtc_state *crtc_state, > + struct drm_connector_state *conn_state, > + u32 output_fmt, > + unsigned int *num_input_fmts) > +{ > + u32 *input_fmts; > + > + *num_input_fmts = 0; > + > + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), > + GFP_KERNEL); > + if (!input_fmts) > + return NULL; > + > + /* This is the DSI/DPI-end bus format */ > + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; > + *num_input_fmts = 1; > + > + return input_fmts; > +} > + > static const struct drm_bridge_funcs tc_dpi_bridge_funcs = { > .attach = tc_dpi_bridge_attach, > .mode_valid = tc_dpi_mode_valid, > @@ -1777,6 +1801,7 @@ static const struct drm_bridge_funcs tc_edp_bridge_funcs = { > .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state, > .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, > .atomic_reset = drm_atomic_helper_bridge_reset, > + .atomic_get_input_bus_fmts = tc_edp_atomic_get_input_bus_fmts, > }; > > static bool tc_readable_reg(struct device *dev, unsigned int reg) > > base-commit: c503e3eec382ac708ee7adf874add37b77c5d312 Doesn't help, callback is never invoked. There must be more missing. Regarding test setup: Maybe your colleague Preneeth can help to give you access, he just received some devices from us. Otherwise, drop me instrumentation patches. Jan
Hi Jan, On 31/10/2023 08:24, Jan Kiszka wrote: > On 30.10.23 20:28, Aradhya Bhatia wrote: >> With new connector model, tc358767 will not create the connector, when >> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will >> rely on format negotiation to setup the encoder format. >> >> Add the missing input-format negotiation hook in the >> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. >> >> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is >> the case with older model. >> >> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> >> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >> --- >> >> Notes: >> >> * Since I do not have hardware with me, this was just build tested. I would >> appreciate it if someone could test and review it, especically somebody, who >> uses the bridge for DPI/DSI to eDP format conversion. >> >> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default, >> when it should be. Hence, I sent a quick patch[0] earlier. >> >> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ >> >> drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c >> index ef2e373606ba..0affcefdeb1c 100644 >> --- a/drivers/gpu/drm/bridge/tc358767.c >> +++ b/drivers/gpu/drm/bridge/tc358767.c >> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >> return input_fmts; >> } >> >> +static u32 * >> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >> + struct drm_bridge_state *bridge_state, >> + struct drm_crtc_state *crtc_state, >> + struct drm_connector_state *conn_state, >> + u32 output_fmt, >> + unsigned int *num_input_fmts) >> +{ >> + u32 *input_fmts; >> + >> + *num_input_fmts = 0; >> + >> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), >> + GFP_KERNEL); >> + if (!input_fmts) >> + return NULL; >> + >> + /* This is the DSI/DPI-end bus format */ >> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; >> + *num_input_fmts = 1; >> + >> + return input_fmts; >> +} >> + >> static const struct drm_bridge_funcs tc_dpi_bridge_funcs = { >> .attach = tc_dpi_bridge_attach, >> .mode_valid = tc_dpi_mode_valid, >> @@ -1777,6 +1801,7 @@ static const struct drm_bridge_funcs tc_edp_bridge_funcs = { >> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state, >> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, >> .atomic_reset = drm_atomic_helper_bridge_reset, >> + .atomic_get_input_bus_fmts = tc_edp_atomic_get_input_bus_fmts, >> }; >> >> static bool tc_readable_reg(struct device *dev, unsigned int reg) >> >> base-commit: c503e3eec382ac708ee7adf874add37b77c5d312 > > Doesn't help, callback is never invoked. There must be more missing. > > Regarding test setup: Maybe your colleague Preneeth can help to give you > access, he just received some devices from us. Otherwise, drop me > instrumentation patches. Can you try with this change: diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 0affcefdeb1c..137a9f5e3cad 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1579,6 +1579,13 @@ static struct edid *tc_get_edid(struct drm_bridge *bridge, struct drm_connector *connector) { struct tc_data *tc = bridge_to_tc(bridge); + int ret; + + ret = tc_get_display_props(tc); + if (ret < 0) { + dev_err(tc->dev, "failed to read display props: %d\n", ret); + return 0; + } return drm_get_edid(connector, &tc->aux.ddc); } Tomi
On 31.10.23 11:53, Tomi Valkeinen wrote: > Hi Jan, > > On 31/10/2023 08:24, Jan Kiszka wrote: >> On 30.10.23 20:28, Aradhya Bhatia wrote: >>> With new connector model, tc358767 will not create the connector, when >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will >>> rely on format negotiation to setup the encoder format. >>> >>> Add the missing input-format negotiation hook in the >>> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. >>> >>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is >>> the case with older model. >>> >>> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> >>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >>> --- >>> >>> Notes: >>> >>> * Since I do not have hardware with me, this was just build >>> tested. I would >>> appreciate it if someone could test and review it, especically >>> somebody, who >>> uses the bridge for DPI/DSI to eDP format conversion. >>> >>> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by >>> default, >>> when it should be. Hence, I sent a quick patch[0] earlier. >>> >>> [0]: >>> https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ >>> >>> drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ >>> 1 file changed, 25 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/bridge/tc358767.c >>> b/drivers/gpu/drm/bridge/tc358767.c >>> index ef2e373606ba..0affcefdeb1c 100644 >>> --- a/drivers/gpu/drm/bridge/tc358767.c >>> +++ b/drivers/gpu/drm/bridge/tc358767.c >>> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct >>> drm_bridge *bridge, >>> return input_fmts; >>> } >>> +static u32 * >>> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >>> + struct drm_bridge_state *bridge_state, >>> + struct drm_crtc_state *crtc_state, >>> + struct drm_connector_state *conn_state, >>> + u32 output_fmt, >>> + unsigned int *num_input_fmts) >>> +{ >>> + u32 *input_fmts; >>> + >>> + *num_input_fmts = 0; >>> + >>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), >>> + GFP_KERNEL); >>> + if (!input_fmts) >>> + return NULL; >>> + >>> + /* This is the DSI/DPI-end bus format */ >>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; >>> + *num_input_fmts = 1; >>> + >>> + return input_fmts; >>> +} >>> + >>> static const struct drm_bridge_funcs tc_dpi_bridge_funcs = { >>> .attach = tc_dpi_bridge_attach, >>> .mode_valid = tc_dpi_mode_valid, >>> @@ -1777,6 +1801,7 @@ static const struct drm_bridge_funcs >>> tc_edp_bridge_funcs = { >>> .atomic_duplicate_state = >>> drm_atomic_helper_bridge_duplicate_state, >>> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, >>> .atomic_reset = drm_atomic_helper_bridge_reset, >>> + .atomic_get_input_bus_fmts = tc_edp_atomic_get_input_bus_fmts, >>> }; >>> static bool tc_readable_reg(struct device *dev, unsigned int reg) >>> >>> base-commit: c503e3eec382ac708ee7adf874add37b77c5d312 >> >> Doesn't help, callback is never invoked. There must be more missing. >> >> Regarding test setup: Maybe your colleague Preneeth can help to give you >> access, he just received some devices from us. Otherwise, drop me >> instrumentation patches. > > Can you try with this change: > > diff --git a/drivers/gpu/drm/bridge/tc358767.c > b/drivers/gpu/drm/bridge/tc358767.c > index 0affcefdeb1c..137a9f5e3cad 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -1579,6 +1579,13 @@ static struct edid *tc_get_edid(struct drm_bridge > *bridge, > struct drm_connector *connector) > { > struct tc_data *tc = bridge_to_tc(bridge); > + int ret; > + > + ret = tc_get_display_props(tc); > + if (ret < 0) { > + dev_err(tc->dev, "failed to read display props: %d\n", > ret); > + return 0; > + } > > return drm_get_edid(connector, &tc->aux.ddc); > } > > Tomi > Yep, that does the trick. Thanks, Jan PS: Your mail client is mangling tabs - was already suspecting our server would reformat again.
On 31/10/2023 14:18, Jan Kiszka wrote: > On 31.10.23 11:53, Tomi Valkeinen wrote: >> Hi Jan, >> >> On 31/10/2023 08:24, Jan Kiszka wrote: >>> On 30.10.23 20:28, Aradhya Bhatia wrote: >>>> With new connector model, tc358767 will not create the connector, when >>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will >>>> rely on format negotiation to setup the encoder format. >>>> >>>> Add the missing input-format negotiation hook in the >>>> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. >>>> >>>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is >>>> the case with older model. >>>> >>>> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> >>>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >>>> --- >>>> >>>> Notes: >>>> >>>> * Since I do not have hardware with me, this was just build >>>> tested. I would >>>> appreciate it if someone could test and review it, especically >>>> somebody, who >>>> uses the bridge for DPI/DSI to eDP format conversion. >>>> >>>> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by >>>> default, >>>> when it should be. Hence, I sent a quick patch[0] earlier. >>>> >>>> [0]: >>>> https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ >>>> >>>> drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ >>>> 1 file changed, 25 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/bridge/tc358767.c >>>> b/drivers/gpu/drm/bridge/tc358767.c >>>> index ef2e373606ba..0affcefdeb1c 100644 >>>> --- a/drivers/gpu/drm/bridge/tc358767.c >>>> +++ b/drivers/gpu/drm/bridge/tc358767.c >>>> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct >>>> drm_bridge *bridge, >>>> return input_fmts; >>>> } >>>> +static u32 * >>>> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >>>> + struct drm_bridge_state *bridge_state, >>>> + struct drm_crtc_state *crtc_state, >>>> + struct drm_connector_state *conn_state, >>>> + u32 output_fmt, >>>> + unsigned int *num_input_fmts) >>>> +{ >>>> + u32 *input_fmts; >>>> + >>>> + *num_input_fmts = 0; >>>> + >>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), >>>> + GFP_KERNEL); >>>> + if (!input_fmts) >>>> + return NULL; >>>> + >>>> + /* This is the DSI/DPI-end bus format */ >>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; >>>> + *num_input_fmts = 1; >>>> + >>>> + return input_fmts; >>>> +} >>>> + >>>> static const struct drm_bridge_funcs tc_dpi_bridge_funcs = { >>>> .attach = tc_dpi_bridge_attach, >>>> .mode_valid = tc_dpi_mode_valid, >>>> @@ -1777,6 +1801,7 @@ static const struct drm_bridge_funcs >>>> tc_edp_bridge_funcs = { >>>> .atomic_duplicate_state = >>>> drm_atomic_helper_bridge_duplicate_state, >>>> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, >>>> .atomic_reset = drm_atomic_helper_bridge_reset, >>>> + .atomic_get_input_bus_fmts = tc_edp_atomic_get_input_bus_fmts, >>>> }; >>>> static bool tc_readable_reg(struct device *dev, unsigned int reg) >>>> >>>> base-commit: c503e3eec382ac708ee7adf874add37b77c5d312 >>> >>> Doesn't help, callback is never invoked. There must be more missing. >>> >>> Regarding test setup: Maybe your colleague Preneeth can help to give you >>> access, he just received some devices from us. Otherwise, drop me >>> instrumentation patches. >> >> Can you try with this change: >> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c >> b/drivers/gpu/drm/bridge/tc358767.c >> index 0affcefdeb1c..137a9f5e3cad 100644 >> --- a/drivers/gpu/drm/bridge/tc358767.c >> +++ b/drivers/gpu/drm/bridge/tc358767.c >> @@ -1579,6 +1579,13 @@ static struct edid *tc_get_edid(struct drm_bridge >> *bridge, >> struct drm_connector *connector) >> { >> struct tc_data *tc = bridge_to_tc(bridge); >> + int ret; >> + >> + ret = tc_get_display_props(tc); >> + if (ret < 0) { >> + dev_err(tc->dev, "failed to read display props: %d\n", >> ret); >> + return 0; >> + } >> >> return drm_get_edid(connector, &tc->aux.ddc); >> } >> >> Tomi >> > > Yep, that does the trick. Alright, good. I'll send a proper patch. > Thanks, > Jan > > PS: Your mail client is mangling tabs - was already suspecting our > server would reformat again. Nah, the above was just a quick copy paste from my terminal window, and when copying from the terminal it's always just spaces. Tomi
Hi Aradhya, On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote: > With new connector model, tc358767 will not create the connector, when > DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will > rely on format negotiation to setup the encoder format. > > Add the missing input-format negotiation hook in the > drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. > > Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is > the case with older model. > > Reported-by: Jan Kiszka <jan.kiszka@siemens.com> > Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> > --- > > Notes: > > * Since I do not have hardware with me, this was just build tested. I would > appreciate it if someone could test and review it, especically somebody, who > uses the bridge for DPI/DSI to eDP format conversion. > > * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default, > when it should be. Hence, I sent a quick patch[0] earlier. > > [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ > > drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c > index ef2e373606ba..0affcefdeb1c 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > return input_fmts; > } > > +static u32 * > +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > + struct drm_bridge_state *bridge_state, > + struct drm_crtc_state *crtc_state, > + struct drm_connector_state *conn_state, > + u32 output_fmt, > + unsigned int *num_input_fmts) > +{ > + u32 *input_fmts; > + > + *num_input_fmts = 0; > + > + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), > + GFP_KERNEL); > + if (!input_fmts) > + return NULL; > + > + /* This is the DSI/DPI-end bus format */ > + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; > + *num_input_fmts = 1; > + > + return input_fmts; > +} You could benefit from using the helper: drm_atomic_helper_bridge_propagate_bus_fmt() Sam
Hi Sam, Thank you for the suggestion! On 06-Nov-23 18:08, Sam Ravnborg wrote: > Hi Aradhya, > > On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote: >> With new connector model, tc358767 will not create the connector, when >> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will >> rely on format negotiation to setup the encoder format. >> >> Add the missing input-format negotiation hook in the >> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. >> >> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is >> the case with older model. >> >> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> >> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >> --- >> >> Notes: >> >> * Since I do not have hardware with me, this was just build tested. I would >> appreciate it if someone could test and review it, especically somebody, who >> uses the bridge for DPI/DSI to eDP format conversion. >> >> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default, >> when it should be. Hence, I sent a quick patch[0] earlier. >> >> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ >> >> drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c >> index ef2e373606ba..0affcefdeb1c 100644 >> --- a/drivers/gpu/drm/bridge/tc358767.c >> +++ b/drivers/gpu/drm/bridge/tc358767.c >> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >> return input_fmts; >> } >> >> +static u32 * >> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >> + struct drm_bridge_state *bridge_state, >> + struct drm_crtc_state *crtc_state, >> + struct drm_connector_state *conn_state, >> + u32 output_fmt, >> + unsigned int *num_input_fmts) >> +{ >> + u32 *input_fmts; >> + >> + *num_input_fmts = 0; >> + >> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), >> + GFP_KERNEL); >> + if (!input_fmts) >> + return NULL; >> + >> + /* This is the DSI/DPI-end bus format */ >> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; >> + *num_input_fmts = 1; >> + >> + return input_fmts; >> +} > > You could benefit from using the helper: > drm_atomic_helper_bridge_propagate_bus_fmt() You are right! Upon taking a second look, I realize that the bridge chain works with MEDIA_BUS_FMT_FIXED bus format, when tc358767 is being used in DPI/DSI to eDP mode (because the panel-bridge does not have a get_output_bus_fmt hook, and uses the same helper for its get_input_bus_fmt hook). My patch creates a deviation from that, by forcing MEDIA_BUS_FMT_RGB888_1X24 even when eDP is involved. Using the helper here, will certainly address this deviation. However, for the DPI/DSI to DP mode, MEDIA_BUS_FMT_RGB888_1X24 bus format is required, and *just* using the helper as its get_input_bus_fmt hook, might not be enough. Since tc358767 is the last bridge in DPI/DSI to DP mode, the output_fmt parameter get defaulted to MEDIA_BUS_FMT_FIXED too, as there is no get_output_bus_fmt hook present in the driver. If we simply us the helper here, the input_fmt will also get set to MEDIA_BUS_FMT_FIXED. This too is an unwanted deviation. It seems like the right way to address both the cases, would be by adding the get_output_bus_fmt hook that sets output_fmt to MEDIA_BUS_FMT_RGB888_1X24, as well as using the helper as the get_input_bus_fmt hook. If this seems good to you too, I will send a new version of Tomi's series[0] which incorporates this patch. Regards Aradhya [0]: https://lore.kernel.org/all/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard.com/
Hi Aradhya, On Tue, Nov 07, 2023 at 01:17:03AM +0530, Aradhya Bhatia wrote: > Hi Sam, > > Thank you for the suggestion! > > On 06-Nov-23 18:08, Sam Ravnborg wrote: > > Hi Aradhya, > > > > On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote: > >> With new connector model, tc358767 will not create the connector, when > >> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will > >> rely on format negotiation to setup the encoder format. > >> > >> Add the missing input-format negotiation hook in the > >> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. > >> > >> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is > >> the case with older model. > >> > >> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> > >> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> > >> --- > >> > >> Notes: > >> > >> * Since I do not have hardware with me, this was just build tested. I would > >> appreciate it if someone could test and review it, especically somebody, who > >> uses the bridge for DPI/DSI to eDP format conversion. > >> > >> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default, > >> when it should be. Hence, I sent a quick patch[0] earlier. > >> > >> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ > >> > >> drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ > >> 1 file changed, 25 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c > >> index ef2e373606ba..0affcefdeb1c 100644 > >> --- a/drivers/gpu/drm/bridge/tc358767.c > >> +++ b/drivers/gpu/drm/bridge/tc358767.c > >> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > >> return input_fmts; > >> } > >> > >> +static u32 * > >> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, > >> + struct drm_bridge_state *bridge_state, > >> + struct drm_crtc_state *crtc_state, > >> + struct drm_connector_state *conn_state, > >> + u32 output_fmt, > >> + unsigned int *num_input_fmts) > >> +{ > >> + u32 *input_fmts; > >> + > >> + *num_input_fmts = 0; > >> + > >> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), > >> + GFP_KERNEL); > >> + if (!input_fmts) > >> + return NULL; > >> + > >> + /* This is the DSI/DPI-end bus format */ > >> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; > >> + *num_input_fmts = 1; > >> + > >> + return input_fmts; > >> +} > > > > You could benefit from using the helper: > > drm_atomic_helper_bridge_propagate_bus_fmt() > > You are right! > > Upon taking a second look, I realize that the bridge chain works with > MEDIA_BUS_FMT_FIXED bus format, when tc358767 is being used in DPI/DSI > to eDP mode (because the panel-bridge does not have a get_output_bus_fmt > hook, and uses the same helper for its get_input_bus_fmt hook). My patch > creates a deviation from that, by forcing MEDIA_BUS_FMT_RGB888_1X24 even > when eDP is involved. > > Using the helper here, will certainly address this deviation. > > However, for the DPI/DSI to DP mode, MEDIA_BUS_FMT_RGB888_1X24 bus > format is required, and *just* using the helper as its get_input_bus_fmt > hook, might not be enough. > > Since tc358767 is the last bridge in DPI/DSI to DP mode, the > output_fmt parameter get defaulted to MEDIA_BUS_FMT_FIXED too, as there > is no get_output_bus_fmt hook present in the driver. If we simply us > the helper here, the input_fmt will also get set to MEDIA_BUS_FMT_FIXED. > This too is an unwanted deviation. > > It seems like the right way to address both the cases, would be by > adding the get_output_bus_fmt hook that sets output_fmt to > MEDIA_BUS_FMT_RGB888_1X24, as well as using the helper as the > get_input_bus_fmt hook. > > If this seems good to you too, I will send a new version of Tomi's > series[0] which incorporates this patch. I never managed to fully wrap my head around the bus fmt negotiation, and as I am trying to recover from a flu this is not the time to try. Your explanations sounds like you have grasped it so I suggest to move ahead. Sam
Hi Sam, On 07-Nov-23 21:11, Sam Ravnborg wrote: > Hi Aradhya, > > On Tue, Nov 07, 2023 at 01:17:03AM +0530, Aradhya Bhatia wrote: >> Hi Sam, >> >> Thank you for the suggestion! >> >> On 06-Nov-23 18:08, Sam Ravnborg wrote: >>> Hi Aradhya, >>> >>> On Tue, Oct 31, 2023 at 12:58:46AM +0530, Aradhya Bhatia wrote: >>>> With new connector model, tc358767 will not create the connector, when >>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will >>>> rely on format negotiation to setup the encoder format. >>>> >>>> Add the missing input-format negotiation hook in the >>>> drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support. >>>> >>>> Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is >>>> the case with older model. >>>> >>>> Reported-by: Jan Kiszka <jan.kiszka@siemens.com> >>>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> >>>> --- >>>> >>>> Notes: >>>> >>>> * Since I do not have hardware with me, this was just build tested. I would >>>> appreciate it if someone could test and review it, especically somebody, who >>>> uses the bridge for DPI/DSI to eDP format conversion. >>>> >>>> * The Toshiba TC358767 bridge is not enabled in arm64 defconfig by default, >>>> when it should be. Hence, I sent a quick patch[0] earlier. >>>> >>>> [0]: https://lore.kernel.org/all/20231030152834.18450-1-a-bhatia1@ti.com/ >>>> >>>> drivers/gpu/drm/bridge/tc358767.c | 25 +++++++++++++++++++++++++ >>>> 1 file changed, 25 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c >>>> index ef2e373606ba..0affcefdeb1c 100644 >>>> --- a/drivers/gpu/drm/bridge/tc358767.c >>>> +++ b/drivers/gpu/drm/bridge/tc358767.c >>>> @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >>>> return input_fmts; >>>> } >>>> >>>> +static u32 * >>>> +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, >>>> + struct drm_bridge_state *bridge_state, >>>> + struct drm_crtc_state *crtc_state, >>>> + struct drm_connector_state *conn_state, >>>> + u32 output_fmt, >>>> + unsigned int *num_input_fmts) >>>> +{ >>>> + u32 *input_fmts; >>>> + >>>> + *num_input_fmts = 0; >>>> + >>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), >>>> + GFP_KERNEL); >>>> + if (!input_fmts) >>>> + return NULL; >>>> + >>>> + /* This is the DSI/DPI-end bus format */ >>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; >>>> + *num_input_fmts = 1; >>>> + >>>> + return input_fmts; >>>> +} >>> >>> You could benefit from using the helper: >>> drm_atomic_helper_bridge_propagate_bus_fmt() >> >> You are right! >> >> Upon taking a second look, I realize that the bridge chain works with >> MEDIA_BUS_FMT_FIXED bus format, when tc358767 is being used in DPI/DSI >> to eDP mode (because the panel-bridge does not have a get_output_bus_fmt >> hook, and uses the same helper for its get_input_bus_fmt hook). My patch >> creates a deviation from that, by forcing MEDIA_BUS_FMT_RGB888_1X24 even >> when eDP is involved. >> >> Using the helper here, will certainly address this deviation. >> >> However, for the DPI/DSI to DP mode, MEDIA_BUS_FMT_RGB888_1X24 bus >> format is required, and *just* using the helper as its get_input_bus_fmt >> hook, might not be enough. >> >> Since tc358767 is the last bridge in DPI/DSI to DP mode, the >> output_fmt parameter get defaulted to MEDIA_BUS_FMT_FIXED too, as there >> is no get_output_bus_fmt hook present in the driver. If we simply us >> the helper here, the input_fmt will also get set to MEDIA_BUS_FMT_FIXED. >> This too is an unwanted deviation. >> >> It seems like the right way to address both the cases, would be by >> adding the get_output_bus_fmt hook that sets output_fmt to >> MEDIA_BUS_FMT_RGB888_1X24, as well as using the helper as the >> get_input_bus_fmt hook. >> >> If this seems good to you too, I will send a new version of Tomi's >> series[0] which incorporates this patch. > > I never managed to fully wrap my head around the bus fmt negotiation, > and as I am trying to recover from a flu this is not the time to try. > Your explanations sounds like you have grasped it so I suggest to move > ahead. > Sure, I will send a new version. Hope you recover soon! =) Regards Aradhya
diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index ef2e373606ba..0affcefdeb1c 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1751,6 +1751,30 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge, return input_fmts; } +static u32 * +tc_edp_atomic_get_input_bus_fmts(struct drm_bridge *bridge, + struct drm_bridge_state *bridge_state, + struct drm_crtc_state *crtc_state, + struct drm_connector_state *conn_state, + u32 output_fmt, + unsigned int *num_input_fmts) +{ + u32 *input_fmts; + + *num_input_fmts = 0; + + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), + GFP_KERNEL); + if (!input_fmts) + return NULL; + + /* This is the DSI/DPI-end bus format */ + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24; + *num_input_fmts = 1; + + return input_fmts; +} + static const struct drm_bridge_funcs tc_dpi_bridge_funcs = { .attach = tc_dpi_bridge_attach, .mode_valid = tc_dpi_mode_valid, @@ -1777,6 +1801,7 @@ static const struct drm_bridge_funcs tc_edp_bridge_funcs = { .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state, .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, .atomic_reset = drm_atomic_helper_bridge_reset, + .atomic_get_input_bus_fmts = tc_edp_atomic_get_input_bus_fmts, }; static bool tc_readable_reg(struct device *dev, unsigned int reg)