All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neil Armstrong <narmstrong@baylibre.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: airlied@linux.ie, hans.verkuil@cisco.com, lee.jones@linaro.org,
	olof@lixom.net, seanpaul@google.com, sadolfsson@google.com,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, fparent@baylibre.com,
	felixe@google.com, bleung@google.com, darekm@google.com,
	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 20:53:04 +0200	[thread overview]
Message-ID: <8d1abe8f-e18c-9557-6dae-1a82de29375c@baylibre.com> (raw)
In-Reply-To: <20180516140720.GD23723@intel.com>

Hi Ville,

On 16/05/2018 16:07, Ville Syrjälä wrote:
> 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?
> 

Thanks for the clarifications !

Having a "Port <id>" will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.

The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :

const char *port_identifier(struct drm_i915_private *dev_priv,
			    enum port port)
{
	char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);

	if (id)
		return NULL;

	snprintf("Port %c", port_name(port));

	return id;
}

and use the result of this for the cec_notifier connector name ?

Neil

WARNING: multiple messages have this Message-ID (diff)
From: Neil Armstrong <narmstrong@baylibre.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.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, olof@lixom.net,
	bleung@google.com, darekm@google.com, lee.jones@linaro.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
Date: Wed, 16 May 2018 20:53:04 +0200	[thread overview]
Message-ID: <8d1abe8f-e18c-9557-6dae-1a82de29375c@baylibre.com> (raw)
In-Reply-To: <20180516140720.GD23723@intel.com>

Hi Ville,

On 16/05/2018 16:07, Ville Syrjälä wrote:
> 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?
> 

Thanks for the clarifications !

Having a "Port <id>" will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.

The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :

const char *port_identifier(struct drm_i915_private *dev_priv,
			    enum port port)
{
	char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);

	if (id)
		return NULL;

	snprintf("Port %c", port_name(port));

	return id;
}

and use the result of this for the cec_notifier connector name ?

Neil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-16 18:53 UTC|newest]

Thread overview: 44+ 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 ` 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 14:42   ` Neil Armstrong
2018-05-15 15:22   ` Hans Verkuil
2018-05-15 15:22     ` Hans Verkuil
2018-05-15 16:10     ` Neil Armstrong
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 14:42   ` Neil Armstrong
2018-05-15 15:23   ` Hans Verkuil
2018-05-15 15:23     ` Hans Verkuil
2018-05-15 15:35   ` [Intel-gfx] " Ville Syrjälä
2018-05-15 15:35     ` Ville Syrjälä
2018-05-16  7:31     ` [Intel-gfx] " Neil Armstrong
2018-05-16  7:31       ` Neil Armstrong
2018-05-16  7:40       ` [Intel-gfx] " Neil Armstrong
2018-05-16  7:40         ` Neil Armstrong
2018-05-16 14:07         ` Ville Syrjälä
2018-05-16 14:07           ` Ville Syrjälä
2018-05-16 18:53           ` Neil Armstrong [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 14:42   ` Neil Armstrong
2018-05-15 15:28   ` Hans Verkuil
2018-05-15 15:28     ` Hans Verkuil
2018-05-16  7:45     ` Neil Armstrong
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 14:42   ` Neil Armstrong
2018-05-15 15:29   ` Hans Verkuil
2018-05-15 15:29     ` Hans Verkuil
2018-05-15 16:40     ` Enric Balletbo Serra
2018-05-15 16:40       ` Enric Balletbo Serra
2018-05-16  7:42       ` Neil Armstrong
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-15 15:35     ` Hans Verkuil
2018-05-17 19:59   ` [Intel-gfx] " kbuild test robot
2018-05-17 19:59     ` kbuild test robot
2018-05-15 15:20 ` ✗ Fi.CI.CHECKPATCH: warning for Add ChromeOS EC CEC Support (rev3) Patchwork
2018-05-15 15:36 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-16  2:04 ` ✓ Fi.CI.IGT: " Patchwork

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=8d1abe8f-e18c-9557-6dae-1a82de29375c@baylibre.com \
    --to=narmstrong@baylibre.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=olof@lixom.net \
    --cc=sadolfsson@google.com \
    --cc=seanpaul@google.com \
    --cc=ville.syrjala@linux.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.