| Message ID | 20230920-kms-hdmi-connector-state-v2-0-17932daddd7d@kernel.org |
|---|---|
| Headers | show |
| Series | drm/connector: Create HDMI Connector infrastructure | expand |
On Wed, 20 Sep 2023 16:35:18 +0200 Maxime Ripard <mripard@kernel.org> wrote: > The i915 driver has a property to force the RGB range of an HDMI output. > The vc4 driver then implemented the same property with the same > semantics. KWin has support for it, and a PR for mutter is also there to > support it. > > Both drivers implementing the same property with the same semantics, > plus the userspace having support for it, is proof enough that it's > pretty much a de-facto standard now and we can provide helpers for it. > > Let's plumb it into the newly created HDMI connector. > > Signed-off-by: Maxime Ripard <mripard@kernel.org> > --- > Documentation/gpu/kms-properties.csv | 1 - > drivers/gpu/drm/drm_atomic.c | 5 +++ > drivers/gpu/drm/drm_atomic_state_helper.c | 17 +++++++ > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > drivers/gpu/drm/drm_connector.c | 74 +++++++++++++++++++++++++++++++ > include/drm/drm_connector.h | 39 ++++++++++++++++ > 6 files changed, 139 insertions(+), 1 deletion(-) > > diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv > index 0f9590834829..caef14c532d4 100644 > --- a/Documentation/gpu/kms-properties.csv > +++ b/Documentation/gpu/kms-properties.csv > @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De > ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector > ,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector > ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB > -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255." Hi, have a look at this old doc for the property, and... > ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD > ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD > ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD ... > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index d9a7e101e4e5..b45471d540ac 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -1174,6 +1174,29 @@ static const u32 dp_colorspaces = > BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) | > BIT(DRM_MODE_COLORIMETRY_BT2020_YCC); > > +static const struct drm_prop_enum_list broadcast_rgb_names[] = { > + { DRM_HDMI_BROADCAST_RGB_AUTO, "Automatic" }, > + { DRM_HDMI_BROADCAST_RGB_FULL, "Full" }, > + { DRM_HDMI_BROADCAST_RGB_LIMITED, "Limited 16:235" }, > +}; > + > +/* > + * drm_hdmi_connector_get_broadcast_rgb_name - Return a string for HDMI connector RGB broadcast selection > + * @broadcast_rgb: Broadcast RGB selection to compute name of > + * > + * Returns: the name of the Broadcast RGB selection, or NULL if the type > + * is not valid. > + */ > +const char * > +drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_rgb) > +{ > + if (broadcast_rgb > DRM_HDMI_BROADCAST_RGB_LIMITED) > + return NULL; > + > + return broadcast_rgb_names[broadcast_rgb].name; > +} > +EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name); > + > /** > * DOC: standard connector properties > * > @@ -1640,6 +1663,24 @@ EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property); > /** > * DOC: HDMI connector properties > * > + * Broadcast RGB (HDMI Specific): > + * Indicates the RGB Range (Full vs Limited) used. > + * > + * The value of this property can be one of the following: > + * > + * Automatic: > + * RGB Range is selected automatically based on the mode > + * according to the HDMI specifications. > + * > + * Full: > + * Full RGB Range is forced. > + * > + * Limited 16:235: > + * Limited RGB Range is forced. > + * > + * Drivers can set up this property by calling > + * drm_connector_attach_broadcast_rgb_property(). ...compare it to this. There is one crucial detail lost: setting this property does two or three things: it clips conversion input values to [0.0, 1.0] range, programs a conversion matrix to convert full-range RGB to destination RGB, and sends infoframes to indicate the chosen destination RGB. The distinction is important, because use cases like PLUGE calibration (Rec. ITU-R BT.814-4) rely on indicating limited range while pixel values are still able to carry sub-black values. Other procedures might also want to use super-whites. This is impossible with the existing "Broadcast RGB" property, but that is a different matter. The old doc didn't exactly say it sets the infoframe fields either, but I presume it does. I feel the documentation needs to be much more explicit here. > + * > * content type (HDMI specific): > * Indicates content type setting to be used in HDMI infoframes to indicate > * content type for the external device, so that it adjusts its display > @@ -2500,6 +2541,39 @@ int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn > } > EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property); > > +/** > + * drm_connector_attach_broadcast_rgb_property - attach "Broadcast RGB" property > + * @connector: connector to attach max bpc property on. "max bpc" pasta. > + * > + * This is used to add support for forcing the RGB range on a connector > + * > + * Returns: > + * Zero on success, negative errno on failure. > + */ > +int drm_connector_attach_broadcast_rgb_property(struct drm_connector *connector) > +{ > + struct drm_device *dev = connector->dev; > + struct drm_property *prop; > + > + prop = connector->broadcast_rgb_property; > + if (!prop) { > + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, > + "Broadcast RGB", > + broadcast_rgb_names, > + ARRAY_SIZE(broadcast_rgb_names)); > + if (!prop) > + return -EINVAL; > + > + connector->broadcast_rgb_property = prop; > + } > + > + drm_object_attach_property(&connector->base, prop, > + DRM_HDMI_BROADCAST_RGB_AUTO); > + > + return 0; > +} > +EXPORT_SYMBOL(drm_connector_attach_broadcast_rgb_property); > + > /** > * drm_connector_attach_colorspace_property - attach "Colorspace" property > * @connector: connector to attach the property on. > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index 5961f2ad48b1..fdcf64ab91a9 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -368,6 +368,33 @@ enum drm_panel_orientation { > DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, > }; > > +/** > + * enum drm_hdmi_broadcast_rgb - Broadcast RGB Selection for a @drm_hdmi_connector > + * > + * This enum is used to track broadcast RGB selection. There are no > + * separate #defines for the uapi! Why the "no separate defines" comment? That's the norm. The KMS property UAPI works by string names for enum values. Some enum properties might expose C enums for the values, but that is an exception that cannot be fixed due to stable UAPI. Thanks, pq > + */ > +enum drm_hdmi_broadcast_rgb { > + /** > + * @DRM_HDMI_BROADCAST_RGB_AUTO: The RGB range is selected > + * automatically based on the mode. > + */ > + DRM_HDMI_BROADCAST_RGB_AUTO, > + > + /** > + * @DRM_HDMI_BROADCAST_RGB_FULL: Full range RGB is forced. > + */ > + DRM_HDMI_BROADCAST_RGB_FULL, > + > + /** > + * @DRM_HDMI_BROADCAST_RGB_LIMITED: Limited range RGB is forced. > + */ > + DRM_HDMI_BROADCAST_RGB_LIMITED, > +};
On Wed, 20 Sep 2023 16:35:20 +0200 Maxime Ripard <mripard@kernel.org> wrote: > We'll add automatic selection of the output BPC in a following patch, > but let's add it to the HDMI connector state already. > > Signed-off-by: Maxime Ripard <mripard@kernel.org> > --- > drivers/gpu/drm/drm_atomic.c | 4 +++- > drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++++- > drivers/gpu/drm/drm_connector.c | 13 ++++++++++++- > include/drm/drm_connector.h | 13 ++++++++++++- > 4 files changed, 32 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index b1b56dcaa76b..8dce0a2f2ac3 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1143,9 +1143,11 @@ static void drm_atomic_connector_print_state(struct drm_printer *p, > drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace)); > > if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA || > - connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) { > drm_printf(p, "\tbroadcast_rgb=%s\n", > drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb)); > + drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc); > + } > > if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) > if (state->writeback_job && state->writeback_job->fb) > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c > index 0f7e5ba555b8..2c9b52ae1b56 100644 > --- a/drivers/gpu/drm/drm_atomic_state_helper.c > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c > @@ -569,6 +569,9 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset); > void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector, > struct drm_connector_state *new_state) > { > + new_state->max_bpc = 8; > + new_state->max_requested_bpc = 8; > + new_state->hdmi.output_bpc = 8; Hi, will this be forcing all drivers using these helpers to default to max bpc = 8? I believe at least amdgpu would disagree. The defaults were changed in the recent years, IIRC to avoid extra modesets during boot-up when desktops prefer highest possible bpc for a mode. The 'max bpc' property itself is a manual workaround for faulty hardware that does not correctly indicate the max bpc it can handle. It should not default to be a limiting factor. > new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO; > } > EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset); > @@ -651,7 +654,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector, > struct drm_connector_state *new_state = > drm_atomic_get_new_connector_state(state, connector); > > - if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) { > + if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb || > + old_state->hdmi.output_bpc != new_state->hdmi.output_bpc) { > struct drm_crtc *crtc = new_state->crtc; > struct drm_crtc_state *crtc_state; > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index b45471d540ac..f55f5918411c 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -459,6 +459,7 @@ EXPORT_SYMBOL(drmm_connector_init); > * @funcs: callbacks for this connector > * @connector_type: user visible type of the connector > * @ddc: optional pointer to the associated ddc adapter > + * @max_bpc: Maximum bits per char the HDMI connector supports > * > * Initialises a preallocated HDMI connector. Connectors can be > * subclassed as part of driver connector objects. > @@ -475,7 +476,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev, > struct drm_connector *connector, > const struct drm_connector_funcs *funcs, > int connector_type, > - struct i2c_adapter *ddc) > + struct i2c_adapter *ddc, > + unsigned int max_bpc) > { > int ret; > > @@ -487,6 +489,15 @@ int drmm_connector_hdmi_init(struct drm_device *dev, > if (ret) > return ret; > > + if (max_bpc) { > + if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12)) > + return -EINVAL; > + > + drm_connector_attach_hdr_output_metadata_property(connector); > + drm_connector_attach_max_bpc_property(connector, 8, max_bpc); > + connector->max_bpc = max_bpc; > + } > + > return 0; > } > EXPORT_SYMBOL(drmm_connector_hdmi_init); > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index fdcf64ab91a9..d0bcb835c857 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -1056,6 +1056,11 @@ struct drm_connector_state { > * Broadcast RGB selection value. > */ > enum drm_hdmi_broadcast_rgb broadcast_rgb; > + > + /** > + * @output_bpc: Bits per character to output. Is it not bits per channel? > + */ > + unsigned int output_bpc; > } hdmi; > }; > > @@ -1700,6 +1705,11 @@ struct drm_connector { > */ > struct drm_property_blob *path_blob_ptr; > > + /** > + * @max_bpc: Maximum bits per character the connector supports. channel? > + */ > + unsigned int max_bpc; > + > /** > * @max_bpc_property: Default connector property for the max bpc to be > * driven out of the connector. > @@ -1939,7 +1949,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev, > struct drm_connector *connector, > const struct drm_connector_funcs *funcs, > int connector_type, > - struct i2c_adapter *ddc); > + struct i2c_adapter *ddc, > + unsigned int max_bpc); > void drm_connector_attach_edid_property(struct drm_connector *connector); > int drm_connector_register(struct drm_connector *connector); > void drm_connector_unregister(struct drm_connector *connector); > Thanks, pq
On Thu, 21 Sep 2023, Pekka Paalanen <ppaalanen@gmail.com> wrote: > On Wed, 20 Sep 2023 16:35:20 +0200 > Maxime Ripard <mripard@kernel.org> wrote: > >> We'll add automatic selection of the output BPC in a following patch, >> but let's add it to the HDMI connector state already. >> >> Signed-off-by: Maxime Ripard <mripard@kernel.org> >> --- >> drivers/gpu/drm/drm_atomic.c | 4 +++- >> drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++++- >> drivers/gpu/drm/drm_connector.c | 13 ++++++++++++- >> include/drm/drm_connector.h | 13 ++++++++++++- >> 4 files changed, 32 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c >> index b1b56dcaa76b..8dce0a2f2ac3 100644 >> --- a/drivers/gpu/drm/drm_atomic.c >> +++ b/drivers/gpu/drm/drm_atomic.c >> @@ -1143,9 +1143,11 @@ static void drm_atomic_connector_print_state(struct drm_printer *p, >> drm_printf(p, "\tcolorspace=%s\n", drm_get_colorspace_name(state->colorspace)); >> >> if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA || >> - connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) >> + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) { >> drm_printf(p, "\tbroadcast_rgb=%s\n", >> drm_hdmi_connector_get_broadcast_rgb_name(state->hdmi.broadcast_rgb)); >> + drm_printf(p, "\toutput_bpc=%u\n", state->hdmi.output_bpc); >> + } >> >> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK) >> if (state->writeback_job && state->writeback_job->fb) >> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c >> index 0f7e5ba555b8..2c9b52ae1b56 100644 >> --- a/drivers/gpu/drm/drm_atomic_state_helper.c >> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c >> @@ -569,6 +569,9 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset); >> void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector, >> struct drm_connector_state *new_state) >> { >> + new_state->max_bpc = 8; >> + new_state->max_requested_bpc = 8; >> + new_state->hdmi.output_bpc = 8; > > Hi, > > will this be forcing all drivers using these helpers to default to max bpc = 8? > > I believe at least amdgpu would disagree. The defaults were changed in > the recent years, IIRC to avoid extra modesets during boot-up when > desktops prefer highest possible bpc for a mode. > > The 'max bpc' property itself is a manual workaround for faulty > hardware that does not correctly indicate the max bpc it can handle. It > should not default to be a limiting factor. > >> new_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO; >> } >> EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset); >> @@ -651,7 +654,8 @@ int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector, >> struct drm_connector_state *new_state = >> drm_atomic_get_new_connector_state(state, connector); >> >> - if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb) { >> + if (old_state->hdmi.broadcast_rgb != new_state->hdmi.broadcast_rgb || >> + old_state->hdmi.output_bpc != new_state->hdmi.output_bpc) { >> struct drm_crtc *crtc = new_state->crtc; >> struct drm_crtc_state *crtc_state; >> >> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c >> index b45471d540ac..f55f5918411c 100644 >> --- a/drivers/gpu/drm/drm_connector.c >> +++ b/drivers/gpu/drm/drm_connector.c >> @@ -459,6 +459,7 @@ EXPORT_SYMBOL(drmm_connector_init); >> * @funcs: callbacks for this connector >> * @connector_type: user visible type of the connector >> * @ddc: optional pointer to the associated ddc adapter >> + * @max_bpc: Maximum bits per char the HDMI connector supports >> * >> * Initialises a preallocated HDMI connector. Connectors can be >> * subclassed as part of driver connector objects. >> @@ -475,7 +476,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev, >> struct drm_connector *connector, >> const struct drm_connector_funcs *funcs, >> int connector_type, >> - struct i2c_adapter *ddc) >> + struct i2c_adapter *ddc, >> + unsigned int max_bpc) >> { >> int ret; >> >> @@ -487,6 +489,15 @@ int drmm_connector_hdmi_init(struct drm_device *dev, >> if (ret) >> return ret; >> >> + if (max_bpc) { >> + if (!(max_bpc == 8 || max_bpc == 10 || max_bpc == 12)) >> + return -EINVAL; >> + >> + drm_connector_attach_hdr_output_metadata_property(connector); >> + drm_connector_attach_max_bpc_property(connector, 8, max_bpc); >> + connector->max_bpc = max_bpc; >> + } >> + >> return 0; >> } >> EXPORT_SYMBOL(drmm_connector_hdmi_init); >> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h >> index fdcf64ab91a9..d0bcb835c857 100644 >> --- a/include/drm/drm_connector.h >> +++ b/include/drm/drm_connector.h >> @@ -1056,6 +1056,11 @@ struct drm_connector_state { >> * Broadcast RGB selection value. >> */ >> enum drm_hdmi_broadcast_rgb broadcast_rgb; >> + >> + /** >> + * @output_bpc: Bits per character to output. > > Is it not bits per channel? Or component. Or color. Or color channel. ;) But character I've never heard. BR, Jani. > >> + */ >> + unsigned int output_bpc; >> } hdmi; >> }; >> >> @@ -1700,6 +1705,11 @@ struct drm_connector { >> */ >> struct drm_property_blob *path_blob_ptr; >> >> + /** >> + * @max_bpc: Maximum bits per character the connector supports. > > channel? > >> + */ >> + unsigned int max_bpc; >> + >> /** >> * @max_bpc_property: Default connector property for the max bpc to be >> * driven out of the connector. >> @@ -1939,7 +1949,8 @@ int drmm_connector_hdmi_init(struct drm_device *dev, >> struct drm_connector *connector, >> const struct drm_connector_funcs *funcs, >> int connector_type, >> - struct i2c_adapter *ddc); >> + struct i2c_adapter *ddc, >> + unsigned int max_bpc); >> void drm_connector_attach_edid_property(struct drm_connector *connector); >> int drm_connector_register(struct drm_connector *connector); >> void drm_connector_unregister(struct drm_connector *connector); >> > > Thanks, > pq
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
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,