dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: felixe@google.com, seanpaul@google.com, airlied@linux.ie,
	sadolfsson@google.com, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	fparent@baylibre.com, hans.verkuil@cisco.com, bleung@google.com,
	darekm@google.com, lee.jones@linaro.org,
	linux-media@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
Date: Wed, 16 May 2018 17:07:20 +0300	[thread overview]
Message-ID: <20180516140720.GD23723@intel.com> (raw)
In-Reply-To: <e0f99123-1463-c082-122e-67cf0d106e25@baylibre.com>

On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
> On 16/05/2018 09:31, Neil Armstrong wrote:
> > Hi Ville,
> > 
> > On 15/05/2018 17:35, Ville Syrjälä wrote:
> >> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
> >>> This patchs adds the cec_notifier feature to the intel_hdmi part
> >>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> >>> between each HDMI ports.
> >>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> >>> to an eventual CEC adapter.
> >>>
> >>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >>> ---
> >>>  drivers/gpu/drm/i915/Kconfig      |  1 +
> >>>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> >>>  drivers/gpu/drm/i915/intel_hdmi.c | 12 ++++++++++++
> >>>  3 files changed, 15 insertions(+)
> >>>
> > 
> > [..]
> > 
> >>>  }
> >>>  
> >>> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder *encoder,
> >>>  
> >>>  static void intel_hdmi_destroy(struct drm_connector *connector)
> >>>  {
> >>> +	if (intel_attached_hdmi(connector)->notifier)
> >>> +		cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> >>>  	kfree(to_intel_connector(connector)->detect_edid);
> >>>  	drm_connector_cleanup(connector);
> >>>  	kfree(connector);
> >>> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> >>>  		u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> >>>  		I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> >>>  	}
> >>> +
> >>> +	intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> >>
> >> What are we doing with the connector name here? Those are not actually
> >> guaranteed to be stable, and any change in the connector probe order
> >> may cause the name to change.
> > 
> > The i915 driver can expose multiple HDMI connectors, but each connected will
> > have a different EDID and CEC physical address, so we will need a different notifier
> > for each connector.
> > 
> > The connector name is DRM dependent, but user-space actually uses this name for
> > operations, so I supposed it was kind of stable.
> > 
> > Anyway, is there another stable id/name/whatever that can be used to make a name to
> > distinguish the HDMI connectors ?
> 
> Would "HDMI %c", port_name(port) be OK to use ?

Yeah, something like seems like a reasonable approach. That does mean
we have to be a little careful with changing enum port or port_name()
in the future, but I guess we could just add a small function to
generated the name/id specifically for this thing.

We're also going to have to think what to do with enum port and
port_name() on ICL+ though. There we won't just have A-F but also
TC1-TC<n>. Hmm. Looks like what we have for those ports in our
codebase ATM is a bit wonky since we haven't even changed
port_name() to give us the TC<n> type names.

Also we might not want "HDMI" in the identifier since the physical
port is not HDMI specific. There are different things we could call
these but I think we could just go with a generic "Port A-F" and
"Port TC1-TC<n>" approach. I think something like that should work
fine for current and upcoming hardware. And in theory that could
then be used for other things as well which need a stable
identifier.

Oh, and now I recall that input subsystem at least has some kind
of "physical path" property on devices. So I guess what we're
dicussing is a somewhat similar idea. I think input drivers
generally include the pci/usb/etc. device in the path as well.
Even though we currently only ever have the one pci device it
would seem like decent idea to include that information in our
identifiers as well. Or what do you think?

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-05-16 14:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15 14:42 [PATCH v2 0/5] Add ChromeOS EC CEC Support Neil Armstrong
2018-05-15 14:42 ` [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name Neil Armstrong
2018-05-15 15:22   ` Hans Verkuil
2018-05-15 16:10     ` Neil Armstrong
2018-05-15 14:42 ` [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi Neil Armstrong
2018-05-15 15:23   ` Hans Verkuil
2018-05-15 15:35   ` Ville Syrjälä
2018-05-16  7:31     ` Neil Armstrong
2018-05-16  7:40       ` [Intel-gfx] " Neil Armstrong
2018-05-16 14:07         ` Ville Syrjälä [this message]
2018-05-16 18:53           ` Neil Armstrong
2018-05-15 14:42 ` [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions Neil Armstrong
2018-05-15 15:28   ` Hans Verkuil
2018-05-16  7:45     ` Neil Armstrong
2018-05-15 14:42 ` [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration Neil Armstrong
2018-05-15 15:29   ` Hans Verkuil
2018-05-15 16:40     ` Enric Balletbo Serra
2018-05-16  7:42       ` Neil Armstrong
2018-05-15 14:42 ` [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver Neil Armstrong
2018-05-15 15:35   ` Hans Verkuil
2018-05-17 19:59   ` kbuild test robot

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=20180516140720.GD23723@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=bleung@google.com \
    --cc=darekm@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felixe@google.com \
    --cc=fparent@baylibre.com \
    --cc=hans.verkuil@cisco.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=sadolfsson@google.com \
    --cc=seanpaul@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).