Message ID | 20230920-kms-hdmi-connector-state-v2-0-17932daddd7d@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp4196994vqi; Wed, 20 Sep 2023 07:51:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEmnjrFv969Y/L4GRYz5eayihP6FvSPI6UBNnA5mror1dizaWzUX8Sg8ebmc2paNSvAeLzB X-Received: by 2002:a05:6870:e315:b0:1ba:8307:9a13 with SMTP id z21-20020a056870e31500b001ba83079a13mr2812066oad.11.1695221486662; Wed, 20 Sep 2023 07:51:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695221486; cv=none; d=google.com; s=arc-20160816; b=tQhcTk24qFTVIDYwdu6D9CHGMGquKojotY1CDoj0++pWQcbZeqIVotmupVIKdcfdbf 6Rj6dKGPrRCubB/lmEeIcmAQ6JqBdrdgDJWwX+syaZKhd/uC80uVJi6jXLxkLAZih6w4 TnayH/R6I4WlGLCEyKuKmw2Vec0pdCVqmk253a7JRNtSS+WyThM9PbnL97wla7M8/LG8 0y46+MhpandwBGgNKpM+0Y85USPZLiOsZgtyzE5TLN4WIjHnfWAOss9TmjDSi/CgpXH1 JCZbvBjwoCs/s20ibMiYbWbHyqM8Dn0KWFf+Wxeb32CLNJpWFwsQ1KZYKHIR9jCc/0AP 6yqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=HStNCidRnzdcowQdd74IqFaLchpHeBmgpfucfDhP2A8=; fh=e6/uyeFf2k7v8JUtB6fPyaAS5iN3eSA1hjtg35V2Rzw=; b=Sh31la5D3oLJsoeaPE/db7crrw6JK3Oaxeh136GSL0obkSvebU7CFDPbOsNWHOJofe hVRAwaTpvpxsZG//Ill9bTvb/AhFQcXjrNZf3cJYqUPs5+U8yvGfKegHpXzZGwEwe4Ig ncIAAbfYexPtkdEeu8R3xA09O5uzCv5WBIXP36oa1y4xBpDvBxSOZH4QrBCs5sGWNP+p sU5485nP5Q9AD8u4P92ombiDdL3tjaNsF73+ILABaz04YSpkRhT/rRxFhRU/9EbFJpMP GDb+8n4qszkafxribAI45O3/E+Hla5cLtJY4tLMdLS3bXAuivNwfjpFgNSUfRnCW05Uk N/gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=G+iqEvtI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id m9-20020a654389000000b0057415df29c7si11396323pgp.854.2023.09.20.07.51.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Sep 2023 07:51:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=G+iqEvtI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id D79C682696CF; Wed, 20 Sep 2023 07:36:03 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235086AbjITOft (ORCPT <rfc822;realc9580@gmail.com> + 27 others); Wed, 20 Sep 2023 10:35:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232318AbjITOfr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 20 Sep 2023 10:35:47 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DB20AD; Wed, 20 Sep 2023 07:35:42 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71722C433C7; Wed, 20 Sep 2023 14:35:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695220542; bh=HFDW8UoD5QLd6nTbuqGijlmAZk0/AapjhKvVeBKKueU=; h=From:Subject:Date:To:Cc:From; b=G+iqEvtI91oD9Gvhu+88PxzS8E24ExbtGQ5fcakyWpDsmhiFwhb0RUSjNDOw8GBoY 37EFpMiql+e16zqxJJuPvMkvRKCPmlolTlzAUSznrPjoiDaNbl/UnXmOH4aMFSed4Y CJUh5T/3jVp+BqdeOufDkILWisc2pHuCSHiFSskri3CxtYvRiT1/wRS7fBzCN9sLSp 44pIHJyxK7DutAdStUiI75mJQy4B3LJwM3qgjwrfDA4aIAgKqHbitfqn0NAlVF18dF pI44W4LmbLZg9Bu4qdmblOSTDmWj7y/MxikAEim6JJbFxzfFV3fthz3V5KtLyn/nhu dui7/UIfveZjA== From: Maxime Ripard <mripard@kernel.org> Subject: [PATCH RFC v2 00/37] drm/connector: Create HDMI Connector infrastructure Date: Wed, 20 Sep 2023 16:35:15 +0200 Message-Id: <20230920-kms-hdmi-connector-state-v2-0-17932daddd7d@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIACMDC2UC/4WNQQqDMBBFryKz7pQkxsR2VSj0AN0WF6KjDmpSE pEW8e4NXqDL/z/v/Q0iBaYI12yDQCtH9i4FdcqgGWrXE3KbMiihclFKjeMccWhnxsY7R83iA8a lXgiNNLa0ZOxFWUj4O1DHn0P9gufjDlUqB46J+B53qzym/+ZVokChS1HotstNoW8jBUfT2Yceq n3ff/7/jnPGAAAA To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Emma Anholt <emma@anholt.net>, Jonathan Corbet <corbet@lwn.net>, Sandy Huang <hjc@rock-chips.com>, =?utf-8?q?Heiko_St=C3=BCbner?= <heiko@sntech.de>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org> Cc: Hans Verkuil <hverkuil@xs4all.nl>, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev, Maxime Ripard <mripard@kernel.org> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=5802; i=mripard@kernel.org; h=from:subject:message-id; bh=HFDW8UoD5QLd6nTbuqGijlmAZk0/AapjhKvVeBKKueU=; b=owGbwMvMwCX2+D1vfrpE4FHG02pJDKnczBZcvZvWvvnx9OB3fnaN/W8nFaj9Oz5dIO7b2kjDS baeucd2dJSyMIhxMciKKbLECJsviTs163UnG988mDmsTCBDGLg4BWAiPl8ZGe6lP2ufnP3PYeFl tv7ZBlaV2b6t0usis3xFq2/JeNee9mT4H1tSKODo+Wy7bMD8ZXsip8zcqlN23W1leYiYb7r9yaQ URgA= X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 fry.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 (fry.vger.email [0.0.0.0]); Wed, 20 Sep 2023 07:36:03 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777568565808369209 X-GMAIL-MSGID: 1777568565808369209 |
Series |
drm/connector: Create HDMI Connector infrastructure
|
|
Message
Maxime Ripard
Sept. 20, 2023, 2:35 p.m. UTC
Hi,
Here's a series that creates a subclass of drm_connector specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent boilerplate, with
each driver doing some variation of it.
In parallel, while working on vc4, we ended up converting a lot of i915
logic (mostly around format / bpc selection, and scrambler setup) to
apply on top of a driver that relies only on helpers.
While currently sitting in the vc4 driver, none of that logic actually
relies on any driver or hardware-specific behaviour.
The only missing piece to make it shareable are a bunch of extra
variables stored in a state (current bpc, format, RGB range selection,
etc.).
The initial implementation was relying on some generic subclass of
drm_connector to address HDMI connectors, with a bunch of helpers that
will take care of all the "HDMI Spec" related code. Scrambler setup is
missing at the moment but can easily be plugged in.
The feedback was that creating a connector subclass like was done for
writeback would prevent the adoption of those helpers since it couldn't
be used in all situations (like when the connector driver can implement
multiple output) and required more churn to cast between the
drm_connector and its subclass. The decision was thus to provide a set
of helper and to store the required variables in drm_connector and
drm_connector_state. This what has been implemented now.
Hans Verkuil also expressed interest in implementing a mechanism in v4l2
to retrieve infoframes from HDMI receiver and implementing an
infoframe-decode tool.
This series thus leverages the infoframe generation code to expose it
through debugfs.
This entire series is only build-tested at the moment. Let me know what
you think,
Maxime
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Changes in v2:
- Change from a subclass to a set of helpers for drm_connector and
drm_connector state
- Don't assume that all drivers support RGB, YUV420 and YUV422 but make
them provide a bitfield instead.
- Don't assume that all drivers support the Broadcast RGB property but
make them call the registration helper.
- Document the Broacast RGB property
- Convert the inno_hdmi and sun4i_hdmi driver.
- Link to v1: https://lore.kernel.org/r/20230814-kms-hdmi-connector-state-v1-0-048054df3654@kernel.org
---
Maxime Ripard (37):
drm/connector: Introduce an HDMI connector
drm/connector: hdmi: Create a custom state
drm/connector: hdmi: Add Broadcast RGB property
drm/connector: hdmi: Add helper to get the RGB range
drm/connector: hdmi: Add output BPC to the connector state
drm/connector: hdmi: Add support for output format
drm/connector: hdmi: Add HDMI compute clock helper
drm/connector: hdmi: Calculate TMDS character rate
drm/connector: hdmi: Add custom hook to filter TMDS character rate
drm/connector: hdmi: Compute bpc and format automatically
drm/connector: hdmi: Add Infoframes generation
drm/connector: hdmi: Create Infoframe DebugFS entries
drm/vc4: hdmi: Create destroy state implementation
drm/vc4: hdmi: Switch to HDMI connector
drm/rockchip: inno_hdmi: Remove useless mode_fixup
drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode
drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
drm/rockchip: inno_hdmi: Get rid of mode_set
drm/rockchip: inno_hdmi: no need to store vic
drm/rockchip: inno_hdmi: Remove unneeded has audio flag
drm/rockchip: inno_hdmi: Remove useless input format
drm/rockchip: inno_hdmi: Remove useless output format
drm/rockchip: inno_hdmi: Remove useless colorimetry
drm/rockchip: inno_hdmi: Remove useless enum
drm/rockchip: inno_hdmi: Remove tmds rate from structure
drm/rockchip: inno_hdmi: Remove useless coeff_csc matrix
drm/rockchip: inno_hdmi: Remove useless mode_valid
drm/rockchip: inno_hdmi: Move infoframe disable to separate function
drm/rockchip: inno_hdmi: Create mask retrieval functions
drm/rockchip: inno_hdmi: Switch to infoframe type
drm/rockchip: inno_hdmi: Remove unused drm device pointer
drm/rockchip: inno_hdmi: Switch to HDMI connector
drm/sun4i: hdmi: Convert encoder to atomic
drm/sun4i: hdmi: Move mode_set into enable
drm/sun4i: hdmi: Switch to container_of_const
drm/sun4i: hdmi: Consolidate atomic_check and mode_valid
drm/sun4i: hdmi: Switch to HDMI connector
Documentation/gpu/kms-properties.csv | 1 -
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_atomic.c | 10 +
drivers/gpu/drm/drm_atomic_state_helper.c | 634 ++++++++++++++++++++++++++++++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_connector.c | 196 +++++++++
drivers/gpu/drm/drm_debugfs.c | 110 ++++++
drivers/gpu/drm/rockchip/inno_hdmi.c | 409 +++++++------------
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 203 +++++-----
drivers/gpu/drm/vc4/vc4_hdmi.c | 624 ++++-------------------------
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 6 +-
include/drm/drm_atomic_state_helper.h | 15 +
include/drm/drm_connector.h | 245 ++++++++++++
14 files changed, 1557 insertions(+), 945 deletions(-)
---
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
change-id: 20230814-kms-hdmi-connector-state-616787e67927
Best regards,
Comments
On 20/09/2023 16:35, Maxime Ripard wrote: > Hi, > > Here's a series that creates a subclass of drm_connector specifically > targeted at HDMI controllers. > > The idea behind this series came from a recent discussion on IRC during > which we discussed infoframes generation of i915 vs everything else. > > Infoframes generation code still requires some decent boilerplate, with > each driver doing some variation of it. > > In parallel, while working on vc4, we ended up converting a lot of i915 > logic (mostly around format / bpc selection, and scrambler setup) to > apply on top of a driver that relies only on helpers. > > While currently sitting in the vc4 driver, none of that logic actually > relies on any driver or hardware-specific behaviour. > > The only missing piece to make it shareable are a bunch of extra > variables stored in a state (current bpc, format, RGB range selection, > etc.). > > The initial implementation was relying on some generic subclass of > drm_connector to address HDMI connectors, with a bunch of helpers that > will take care of all the "HDMI Spec" related code. Scrambler setup is > missing at the moment but can easily be plugged in. > > The feedback was that creating a connector subclass like was done for > writeback would prevent the adoption of those helpers since it couldn't > be used in all situations (like when the connector driver can implement > multiple output) and required more churn to cast between the > drm_connector and its subclass. The decision was thus to provide a set > of helper and to store the required variables in drm_connector and > drm_connector_state. This what has been implemented now. > > Hans Verkuil also expressed interest in implementing a mechanism in v4l2 > to retrieve infoframes from HDMI receiver and implementing an > infoframe-decode tool. I'd love to get started on that, but... > > This series thus leverages the infoframe generation code to expose it > through debugfs. > > This entire series is only build-tested at the moment. Let me know what > you think, ...trying this series on my RPi4 gives me this during boot: [ 2.361239] vc4-drm gpu: bound fe400000.hvs (ops 0xffff800080cac6f8) [ 2.367834] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000090 [ 2.376748] Mem abort info: [ 2.379570] ESR = 0x0000000096000044 [ 2.383367] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.388748] SET = 0, FnV = 0 [ 2.391835] EA = 0, S1PTW = 0 [ 2.395011] FSC = 0x04: level 0 translation fault [ 2.399951] Data abort info: [ 2.402864] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 [ 2.408420] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 2.413536] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 2.418916] [0000000000000090] user address but active_mm is swapper [ 2.425353] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP [ 2.431700] Modules linked in: [ 2.434791] CPU: 2 PID: 55 Comm: kworker/u8:3 Not tainted 6.6.0-rc1-hdmi-dbg #245 [ 2.442372] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 2.448278] Workqueue: events_unbound deferred_probe_work_func [ 2.454193] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.461245] pc : drm_connector_attach_max_bpc_property+0x48/0x90 [ 2.467332] lr : drm_connector_attach_max_bpc_property+0x3c/0x90 [ 2.473415] sp : ffff800081d038b0 [ 2.476766] x29: ffff800081d038b0 x28: 0000000000000000 x27: ffff0001041968c0 [ 2.483999] x26: 0000000000000000 x25: ffff00010339d558 x24: ffff000103399000 [ 2.491231] x23: ffff800080caa3e8 x22: ffff800080e96a20 x21: 000000000000000c [ 2.498463] x20: 000000000000000c x19: ffff00010339d558 x18: ffffffffffffffff [ 2.505694] x17: ffff0001008e7650 x16: ffff800080d55500 x15: ffffffffffffffff [ 2.512926] x14: ffff000105dda209 x13: 0000000000000006 x12: 0000000000000001 [ 2.520158] x11: 0101010101010101 x10: ffff00027effe219 x9 : 0000000000000001 [ 2.527389] x8 : ffff000105db8ad4 x7 : 00000000c0c0c0c0 x6 : 00000000c0c0c0c0 [ 2.534620] x5 : 0000000000000000 x4 : ffff00010339d728 x3 : ffff00010339d728 [ 2.541852] x2 : 000000000000000c x1 : 0000000000000000 x0 : 0000000000000000 [ 2.549083] Call trace: [ 2.551554] drm_connector_attach_max_bpc_property+0x48/0x90 [ 2.557285] drmm_connector_hdmi_init+0x114/0x14c [ 2.562048] vc4_hdmi_bind+0x320/0xa40 [ 2.565842] component_bind_all+0x114/0x23c [ 2.570077] vc4_drm_bind+0x148/0x2c0 [ 2.573784] try_to_bring_up_aggregate_device+0x168/0x1d4 [ 2.579253] __component_add+0xa4/0x16c [ 2.583136] component_add+0x14/0x20 [ 2.586754] vc4_hdmi_dev_probe+0x1c/0x28 [ 2.590815] platform_probe+0x68/0xc4 [ 2.594522] really_probe+0x148/0x2b0 [ 2.598228] __driver_probe_device+0x78/0x12c [ 2.602638] driver_probe_device+0xd8/0x15c [ 2.606873] __device_attach_driver+0xb8/0x134 [ 2.611372] bus_for_each_drv+0x80/0xdc [ 2.615254] __device_attach+0x9c/0x188 [ 2.619136] device_initial_probe+0x14/0x20 [ 2.623371] bus_probe_device+0xac/0xb0 [ 2.627253] deferred_probe_work_func+0x88/0xc0 [ 2.631839] process_one_work+0x138/0x244 [ 2.635899] worker_thread+0x320/0x438 [ 2.639692] kthread+0x10c/0x110 [ 2.642957] ret_from_fork+0x10/0x20 [ 2.646576] Code: 94005f8d 12001e94 f9427e61 52800000 (39024034) [ 2.652745] ---[ end trace 0000000000000000 ]--- Regards, Hans > Maxime > > Signed-off-by: Maxime Ripard <mripard@kernel.org> > --- > Changes in v2: > - Change from a subclass to a set of helpers for drm_connector and > drm_connector state > - Don't assume that all drivers support RGB, YUV420 and YUV422 but make > them provide a bitfield instead. > - Don't assume that all drivers support the Broadcast RGB property but > make them call the registration helper. > - Document the Broacast RGB property > - Convert the inno_hdmi and sun4i_hdmi driver. > - Link to v1: https://lore.kernel.org/r/20230814-kms-hdmi-connector-state-v1-0-048054df3654@kernel.org > > --- > Maxime Ripard (37): > drm/connector: Introduce an HDMI connector > drm/connector: hdmi: Create a custom state > drm/connector: hdmi: Add Broadcast RGB property > drm/connector: hdmi: Add helper to get the RGB range > drm/connector: hdmi: Add output BPC to the connector state > drm/connector: hdmi: Add support for output format > drm/connector: hdmi: Add HDMI compute clock helper > drm/connector: hdmi: Calculate TMDS character rate > drm/connector: hdmi: Add custom hook to filter TMDS character rate > drm/connector: hdmi: Compute bpc and format automatically > drm/connector: hdmi: Add Infoframes generation > drm/connector: hdmi: Create Infoframe DebugFS entries > drm/vc4: hdmi: Create destroy state implementation > drm/vc4: hdmi: Switch to HDMI connector > drm/rockchip: inno_hdmi: Remove useless mode_fixup > drm/rockchip: inno_hdmi: Remove useless copy of drm_display_mode > drm/rockchip: inno_hdmi: Switch encoder hooks to atomic > drm/rockchip: inno_hdmi: Get rid of mode_set > drm/rockchip: inno_hdmi: no need to store vic > drm/rockchip: inno_hdmi: Remove unneeded has audio flag > drm/rockchip: inno_hdmi: Remove useless input format > drm/rockchip: inno_hdmi: Remove useless output format > drm/rockchip: inno_hdmi: Remove useless colorimetry > drm/rockchip: inno_hdmi: Remove useless enum > drm/rockchip: inno_hdmi: Remove tmds rate from structure > drm/rockchip: inno_hdmi: Remove useless coeff_csc matrix > drm/rockchip: inno_hdmi: Remove useless mode_valid > drm/rockchip: inno_hdmi: Move infoframe disable to separate function > drm/rockchip: inno_hdmi: Create mask retrieval functions > drm/rockchip: inno_hdmi: Switch to infoframe type > drm/rockchip: inno_hdmi: Remove unused drm device pointer > drm/rockchip: inno_hdmi: Switch to HDMI connector > drm/sun4i: hdmi: Convert encoder to atomic > drm/sun4i: hdmi: Move mode_set into enable > drm/sun4i: hdmi: Switch to container_of_const > drm/sun4i: hdmi: Consolidate atomic_check and mode_valid > drm/sun4i: hdmi: Switch to HDMI connector > > Documentation/gpu/kms-properties.csv | 1 - > drivers/gpu/drm/Kconfig | 1 + > drivers/gpu/drm/drm_atomic.c | 10 + > drivers/gpu/drm/drm_atomic_state_helper.c | 634 ++++++++++++++++++++++++++++++ > drivers/gpu/drm/drm_atomic_uapi.c | 4 + > drivers/gpu/drm/drm_connector.c | 196 +++++++++ > drivers/gpu/drm/drm_debugfs.c | 110 ++++++ > drivers/gpu/drm/rockchip/inno_hdmi.c | 409 +++++++------------ > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 203 +++++----- > drivers/gpu/drm/vc4/vc4_hdmi.c | 624 ++++------------------------- > drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +-- > drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 6 +- > include/drm/drm_atomic_state_helper.h | 15 + > include/drm/drm_connector.h | 245 ++++++++++++ > 14 files changed, 1557 insertions(+), 945 deletions(-) > --- > base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d > change-id: 20230814-kms-hdmi-connector-state-616787e67927 > > Best regards,
Hi Hans, On Thu, Sep 21, 2023 at 06:29:29PM +0200, Hans Verkuil wrote: > On 20/09/2023 16:35, Maxime Ripard wrote: > > Hi, > > > > Here's a series that creates a subclass of drm_connector specifically > > targeted at HDMI controllers. > > > > The idea behind this series came from a recent discussion on IRC during > > which we discussed infoframes generation of i915 vs everything else. > > > > Infoframes generation code still requires some decent boilerplate, with > > each driver doing some variation of it. > > > > In parallel, while working on vc4, we ended up converting a lot of i915 > > logic (mostly around format / bpc selection, and scrambler setup) to > > apply on top of a driver that relies only on helpers. > > > > While currently sitting in the vc4 driver, none of that logic actually > > relies on any driver or hardware-specific behaviour. > > > > The only missing piece to make it shareable are a bunch of extra > > variables stored in a state (current bpc, format, RGB range selection, > > etc.). > > > > The initial implementation was relying on some generic subclass of > > drm_connector to address HDMI connectors, with a bunch of helpers that > > will take care of all the "HDMI Spec" related code. Scrambler setup is > > missing at the moment but can easily be plugged in. > > > > The feedback was that creating a connector subclass like was done for > > writeback would prevent the adoption of those helpers since it couldn't > > be used in all situations (like when the connector driver can implement > > multiple output) and required more churn to cast between the > > drm_connector and its subclass. The decision was thus to provide a set > > of helper and to store the required variables in drm_connector and > > drm_connector_state. This what has been implemented now. > > > > Hans Verkuil also expressed interest in implementing a mechanism in v4l2 > > to retrieve infoframes from HDMI receiver and implementing an > > infoframe-decode tool. > > I'd love to get started on that, but... > > > > > This series thus leverages the infoframe generation code to expose it > > through debugfs. > > > > This entire series is only build-tested at the moment. Let me know what > > you think, > > ...trying this series on my RPi4 gives me this during boot: > > [ 2.361239] vc4-drm gpu: bound fe400000.hvs (ops 0xffff800080cac6f8) > [ 2.367834] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000090 > [ 2.376748] Mem abort info: > [ 2.379570] ESR = 0x0000000096000044 > [ 2.383367] EC = 0x25: DABT (current EL), IL = 32 bits > [ 2.388748] SET = 0, FnV = 0 > [ 2.391835] EA = 0, S1PTW = 0 > [ 2.395011] FSC = 0x04: level 0 translation fault > [ 2.399951] Data abort info: > [ 2.402864] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 > [ 2.408420] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 > [ 2.413536] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 > [ 2.418916] [0000000000000090] user address but active_mm is swapper > [ 2.425353] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP > [ 2.431700] Modules linked in: > [ 2.434791] CPU: 2 PID: 55 Comm: kworker/u8:3 Not tainted 6.6.0-rc1-hdmi-dbg #245 > [ 2.442372] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) > [ 2.448278] Workqueue: events_unbound deferred_probe_work_func > [ 2.454193] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 2.461245] pc : drm_connector_attach_max_bpc_property+0x48/0x90 > [ 2.467332] lr : drm_connector_attach_max_bpc_property+0x3c/0x90 > [ 2.473415] sp : ffff800081d038b0 > [ 2.476766] x29: ffff800081d038b0 x28: 0000000000000000 x27: ffff0001041968c0 > [ 2.483999] x26: 0000000000000000 x25: ffff00010339d558 x24: ffff000103399000 > [ 2.491231] x23: ffff800080caa3e8 x22: ffff800080e96a20 x21: 000000000000000c > [ 2.498463] x20: 000000000000000c x19: ffff00010339d558 x18: ffffffffffffffff > [ 2.505694] x17: ffff0001008e7650 x16: ffff800080d55500 x15: ffffffffffffffff > [ 2.512926] x14: ffff000105dda209 x13: 0000000000000006 x12: 0000000000000001 > [ 2.520158] x11: 0101010101010101 x10: ffff00027effe219 x9 : 0000000000000001 > [ 2.527389] x8 : ffff000105db8ad4 x7 : 00000000c0c0c0c0 x6 : 00000000c0c0c0c0 > [ 2.534620] x5 : 0000000000000000 x4 : ffff00010339d728 x3 : ffff00010339d728 > [ 2.541852] x2 : 000000000000000c x1 : 0000000000000000 x0 : 0000000000000000 > [ 2.549083] Call trace: > [ 2.551554] drm_connector_attach_max_bpc_property+0x48/0x90 > [ 2.557285] drmm_connector_hdmi_init+0x114/0x14c > [ 2.562048] vc4_hdmi_bind+0x320/0xa40 > [ 2.565842] component_bind_all+0x114/0x23c > [ 2.570077] vc4_drm_bind+0x148/0x2c0 > [ 2.573784] try_to_bring_up_aggregate_device+0x168/0x1d4 > [ 2.579253] __component_add+0xa4/0x16c > [ 2.583136] component_add+0x14/0x20 > [ 2.586754] vc4_hdmi_dev_probe+0x1c/0x28 > [ 2.590815] platform_probe+0x68/0xc4 > [ 2.594522] really_probe+0x148/0x2b0 > [ 2.598228] __driver_probe_device+0x78/0x12c > [ 2.602638] driver_probe_device+0xd8/0x15c > [ 2.606873] __device_attach_driver+0xb8/0x134 > [ 2.611372] bus_for_each_drv+0x80/0xdc > [ 2.615254] __device_attach+0x9c/0x188 > [ 2.619136] device_initial_probe+0x14/0x20 > [ 2.623371] bus_probe_device+0xac/0xb0 > [ 2.627253] deferred_probe_work_func+0x88/0xc0 > [ 2.631839] process_one_work+0x138/0x244 > [ 2.635899] worker_thread+0x320/0x438 > [ 2.639692] kthread+0x10c/0x110 > [ 2.642957] ret_from_fork+0x10/0x20 > [ 2.646576] Code: 94005f8d 12001e94 f9427e61 52800000 (39024034) > [ 2.652745] ---[ end trace 0000000000000000 ]--- Well, I guess I'll have to start testing what I'm doing then :) Maxime