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
next prev parent reply other threads:[~2018-05-16 18:53 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 ` [Intel-gfx] " Ville Syrjälä
2018-05-16 7:31 ` Neil Armstrong
2018-05-16 7:40 ` Neil Armstrong
2018-05-16 14:07 ` Ville Syrjälä
2018-05-16 18:53 ` Neil Armstrong [this message]
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 ` [Intel-gfx] " 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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome