From: Jani Nikula <jani.nikula@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Lyude <lyude@redhat.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Imre Deak <imre.deak@intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Simona Vetter <simona.vetter@ffwll.ch>,
David Airlie <airlied@linux.ie>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel@lists.freedesktop.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"Syrjala, Ville" <ville.syrjala@intel.com>
Subject: Re: [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2)
Date: Fri, 23 May 2025 12:28:11 +0300 [thread overview]
Message-ID: <87sekvsml0.fsf@intel.com> (raw)
In-Reply-To: <20210817215201.795062-6-hdegoede@redhat.com>
Resurrecting an old thread because I am clueless and I have
questions. :)
On Tue, 17 Aug 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>
> On Intel platforms we know that the ACPI connector device
> node order will follow the order the driver (i915) decides.
> The decision is made using the custom Intel ACPI OpRegion
> (intel_opregion.c), though the driver does not actually know
> that the values it sends to ACPI there are used for
> associating a device node for the connectors, and assigning
> address for them.
Is this referring to intel_didl_outputs()?
First, it's curious that intel_didl_outputs() is only called on the
resume paths, not at probe. I don't think the DIDL is set when
intel_acpi_assign_connector_fwnodes() is called. But is it only the
order that matters? Should we do intel_didl_outputs() at probe too?
Currently, we register all connectors first, move panel (as opposed to
external) connectors in front, and that's the fixed connector order
we'll use.
I am wondering if it would be possible to do what this patch does as we
register each connector, not afterwards.
It would involve something like this:
- Figure out intel_connector->acpi_device_id at connector register time
- Figure out the index for DIDL at connector register time
- Figure out connector->fwnode at connector register time
What could possibly go wrong...?
> In reality that custom Intel ACPI OpRegion actually violates
> ACPI specification (we supply dynamic information to objects
> that are defined static, for example _ADR), however, it
> makes assigning correct connector node for a connector entry
> straightforward (it's one-on-one mapping).
Could someone elaborate, please?
> Changes in v2 (Hans de goede):
> - Take a reference on the fwnode which we assign to the connector,
> for ACPI nodes this is a no-op but in the future we may see
> software-fwnodes assigned to connectors which are ref-counted.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c | 46 ++++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_acpi.h | 3 ++
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> 3 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 7cfe91fc05f2..72cac55c0f0f 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -282,3 +282,49 @@ void intel_acpi_device_id_update(struct drm_i915_private *dev_priv)
> }
> drm_connector_list_iter_end(&conn_iter);
> }
> +
> +/* NOTE: The connector order must be final before this is called. */
> +void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct drm_device *drm_dev = &i915->drm;
> + struct fwnode_handle *fwnode = NULL;
> + struct drm_connector *connector;
> + struct acpi_device *adev;
> +
> + drm_connector_list_iter_begin(drm_dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + /* Always getting the next, even when the last was not used. */
> + fwnode = device_get_next_child_node(drm_dev->dev, fwnode);
> + if (!fwnode)
> + break;
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_LVDS:
> + case DRM_MODE_CONNECTOR_eDP:
> + case DRM_MODE_CONNECTOR_DSI:
> + /*
> + * Integrated displays have a specific address 0x1f on
> + * most Intel platforms, but not on all of them.
> + */
> + adev = acpi_find_child_device(ACPI_COMPANION(drm_dev->dev),
> + 0x1f, 0);
> + if (adev) {
> + connector->fwnode =
> + fwnode_handle_get(acpi_fwnode_handle(adev));
> + break;
> + }
> + fallthrough;
> + default:
> + connector->fwnode = fwnode_handle_get(fwnode);
Is it possible to get the struct acpi_device for all fwnodes? Does one
exist?
Specifically, I think I need a struct device that's also an ACPI device
to pass to devm_drm_panel_alloc(), so that a subsequent
drm_panel_add_follower() can use ACPI to look up the panel/connector.
BR,
Jani.
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> + /*
> + * device_get_next_child_node() takes a reference on the fwnode, if
> + * we stopped iterating because we are out of connectors we need to
> + * put this, otherwise fwnode is NULL and the put is a no-op.
> + */
> + fwnode_handle_put(fwnode);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h b/drivers/gpu/drm/i915/display/intel_acpi.h
> index 9f197401c313..4a760a2baed9 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -13,6 +13,7 @@ void intel_register_dsm_handler(void);
> void intel_unregister_dsm_handler(void);
> void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
> void intel_acpi_device_id_update(struct drm_i915_private *i915);
> +void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
> #else
> static inline void intel_register_dsm_handler(void) { return; }
> static inline void intel_unregister_dsm_handler(void) { return; }
> @@ -20,6 +21,8 @@ static inline
> void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915) { return; }
> static inline
> void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> +static inline
> +void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) { return; }
> #endif /* CONFIG_ACPI */
>
> #endif /* __INTEL_ACPI_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index a257e5dc381c..88e5fff64b8c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12561,6 +12561,7 @@ int intel_modeset_init_nogem(struct drm_i915_private *i915)
>
> drm_modeset_lock_all(dev);
> intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
> + intel_acpi_assign_connector_fwnodes(i915);
> drm_modeset_unlock_all(dev);
>
> for_each_intel_crtc(dev, crtc) {
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-05-23 9:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-17 21:51 [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend) Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2021-08-17 21:51 ` [Intel-gfx] [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2021-08-18 21:35 ` [Intel-gfx] " Lyude Paul
2021-08-18 21:35 ` Lyude Paul
2021-08-17 21:51 ` [Intel-gfx] [PATCH 2/8] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2) Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2021-08-17 21:51 ` [Intel-gfx] [PATCH 3/8] drm/connector: Add drm_connector_find_by_fwnode() function (v3) Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2021-08-17 21:51 ` [Intel-gfx] [PATCH 4/8] drm/connector: Add support for out-of-band hotplug notification (v3) Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2021-08-17 21:51 ` [Intel-gfx] [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2) Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2025-05-23 9:28 ` Jani Nikula [this message]
2025-05-23 14:52 ` Heikki Krogerus
2025-05-26 10:24 ` Jani Nikula
2021-08-17 21:51 ` [Intel-gfx] [PATCH 6/8] drm/i915/dp: Add support for out-of-bound hotplug events Hans de Goede
2021-08-17 21:51 ` Hans de Goede
2021-08-17 21:52 ` [Intel-gfx] [PATCH 7/8] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic Hans de Goede
2021-08-17 21:52 ` Hans de Goede
2021-08-17 21:52 ` [Intel-gfx] [PATCH 8/8] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events Hans de Goede
2021-08-17 21:52 ` Hans de Goede
2021-09-16 3:20 ` [Intel-gfx] " Stephen Boyd
2021-09-16 3:20 ` Stephen Boyd
2021-09-16 13:17 ` [Intel-gfx] " Hans de Goede
2021-09-16 13:17 ` Hans de Goede
2021-09-24 23:29 ` [Intel-gfx] " Stephen Boyd
2021-09-24 23:29 ` Stephen Boyd
2021-08-17 22:08 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm + usb-type-c: Add support for out-of-band hotplug notification (v4 resend) Patchwork
2021-08-17 22:35 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-08-18 0:08 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-08-18 19:54 ` Hans de Goede
2021-08-18 22:03 ` [Intel-gfx] [PATCH 0/8] " Lyude Paul
2021-08-18 22:03 ` Lyude Paul
-- strict thread matches above, loose matches on Subject: below --
2021-06-04 19:48 [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4) Hans de Goede
2021-06-04 19:48 ` [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2) Hans de Goede
2021-06-04 19:48 ` Hans de Goede
2021-05-05 16:24 [Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v3) Hans de Goede
2021-05-05 16:24 ` [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2) Hans de Goede
2021-05-05 16:24 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sekvsml0.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona.vetter@ffwll.ch \
--cc=ville.syrjala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.