How to check the HDMI TMDS clock frequency and DP link symbol clock frequency, on HSW/BDW/VLV?

[Lin, Mengdong]

Hi,

Could someone clarify how to check HDMI TMDS clock frequency and DisplayPort 
link symbol clock frequency?

-  Is there some registers which can dump the clock frequency?

-  Is 'clock' field in 'struct drm_display_mode' reflect the this clock?

My platform is Haswell, Broadwell and Baytrail (Valleyview).

I want to check

-  TMDS clock frequency for HDMI

-  Link Symbol clock for DP

One test monitor has problem to play 48khz audio. So I want to make sure 
N/M/CTS values are right for the display clock and audio sample rate.

Thanks
Mengdong

-- next part --
An HTML attachment was scrubbed...
URL: 

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Lin, Mengdong]

> -Original Message-
> From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> Sent: Wednesday, February 19, 2014 7:30 PM

> > > > Is there a 1:1 mapping between these connector nodes and ports of
> > > > Gfx
> > > display engine?
> > > > Eg. For Haswell Ultrabook, under
> > > > /sys/devices/pci:00/:00:02.0/drm/card0/
> > > > There are four connector nodes,
> > > > card0-DP-1  -> DDI port B
> > > > card0-eDP-1/-> DDI port A
> > > > card0-HDMI-A-1/ -> DDI Port C
> > > > card0-HDMI-A-2/ -> Which DDI port ?  Haswell-ULT does not
> > > support port D, and I think port E is for VGA.
> > >
> > > There's no fixed mapping with the port and the connector name. The
> > > number in the connector name is basically just a running number per
> > > connector type. However I do believe we do register the connectors
> > > in the order of the ports more or less always, so you can
> > > *sometimes* deduce the port name from the connector.
> > >
> > > I suppose in this example HDMI-A-1 is port B, HDMI-A-2 is port C,
> > > and
> > > DP-1 can be either port B or port C. DP++ is the reason why we have
> > > overlapping DP and HDMI connectors for the same port.
> >
> > Thanks for clarification, Ville!
> >
> > Does Haswell support DP++ on port B/C/D?
> 
> Yes.
> 
> > And will the name of these connector node change after system boot,
> e.g. after S3/S4 cycles or hot-plug?
> 
> The connector names can't change, except if you unload+reload the driver.

It seems okay. We could let the gfx driver notify the audio driver when the 
connector nodes are destroyed or recreated.
And the audio driver can always know the connector names no matter they change 
or not.

> But I suppose DP MST might change this. Or maybe we'll just expose three
> new fixed DP connectors per DDI port. One for each potential stream.

It would be fine.

> > As long as the connector name is constant, it can help to find out the
> screen status no matter the port works in HDMI or DP mode.
> >
> > There is 1:1 mapping between audio output pins and DDI ports.
> 
> So I guess we need to expose the port->connector mapping somehow to
> the audio driver.

When the gfx driver enables audio, the mapping between 
transcoder/port/connector is established.
And the gfx driver can notify audio the connector name, to help the user space 
to know the audio could be output to which screen.

> How does this work with DP MST? On the display side the audio stuff
> happens in the transcoder, not the DDI port, AFAICS. For DP MST each
> transcoder can provide a single stream.

DP MST is not supported in the audio driver atm. But it could support in the 
future.
E.g. for Haswell, audio driver can know the device index of a monitor connected 
to a port through HW unsolicited event, 
when the gfx driver establishes mapping between a transcoder and a monitor and 
enables audio on the transcoder. 
Different monitors connected to a same port simultaneously have different 
device index. 
Then the audio driver will specify the device index for an audio stream that 
flows to the right transcoder. 
And we're planning to replace the HW unsolicited event notification by SW 
notification between the gfx and audio driver.

Thanks
Mengdong

> > And the new ALSA PCM 'screen' control for a pin can reflect the
> connector name in right mode. E.g. for pin/port B, it can return HDMI-A-1
> or DP-1 depending on what kind of monitor is connected.
> >
> > Thanks
> > Mengdong
> >
> > > >
> > > > Hi Takashi,
> > > >
> > > > To make user space figure out which audio output is connected to
> > > > which
> > > screen (connector), maybe we can define a new ALSA control for each
> > > HDMI/DP PCM device:
> > > > e.g. numid=x,iface=PCM,name='Screen',device=3
> > > > Reading the control will return the name of the DRM connector
> > > > nodes
> > > like ' card0-DP-1'. The audio driver can get the connector name from
> > > the gfx driver.
> > > >
> > > > For DP1.2 Multi-stream transport, it's not supported by i915 and
> > > > HD-A
> > > driver now. But probably there will be sub-nodes for the DP
> > > connector node in the future and an index in their name can be used
> > > distinguish monitors connected to the same DP port, like
> > > card0-DP-1.1, card0-DP-1.2,
> > > card0-DP-1.3 ... These names can be used by the above ALSA PCM
> 'Screen'
> > > control, so we can still know which audio output is to which monitor.
> > > >
> > > > Thanks
> > > > Mengdong
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx at lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Ville Syrj?l?
> > > Intel OTC
> 
> --
> Ville Syrj?l?
> Intel OTC

[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Lin, Mengdong]

> -Original Message-
> From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> Sent: Tuesday, February 18, 2014 10:23 PM
> To: Lin, Mengdong
> Cc: Daniel Vetter; Takashi Iwai; alsa-devel at alsa-project.org; Barnes, 
> Jesse;
> Zanoni, Paulo R; dri-devel; intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] Need your advice: Add a new communication
> inteface between HD-Audio and Gfx drivers for hotplug notification/ELD
> update
> 
> On Tue, Feb 18, 2014 at 01:58:22PM +, Lin, Mengdong wrote:
> > Sorry to pick up this thread after a long time.
> >
> > > -Original Message-
> > > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On
> > > Behalf Of Daniel Vetter
> > > Sent: Thursday, January 23, 2014 4:27 PM
> > > To: Takashi Iwai
> >
> > > On Thu, Jan 23, 2014 at 8:57 AM, Takashi Iwai  wrote:
> > > >> Thanks for clarification!
> > > >> Maybe we can add output info (eg. display port number) to the eld
> > > >> entries
> > > under /proc/asound/cardx. Is it okay?
> > > >
> > > > It's possible, but the proc file is just a help.  It can't be the API.
> > > > For accessing the information, we'll need some new API, or let
> > > > inform via sysfs of the new device.
> > >
> > > Links in sysfs sound like the best approach. drm already has nodes
> > > for each connector, so on the gfx side there's a natural endpoint
> already.
> > > sysfs links also avoids any naming issues from the start, e.g. the
> > > above DP connector id might lead to clashes with multiple cards.
> >
> > Hi Daniel,
> >
> > Is there a 1:1 mapping between these connector nodes and ports of Gfx
> display engine?
> > Eg. For Haswell Ultrabook, under
> > /sys/devices/pci:00/:00:02.0/drm/card0/
> > There are four connector nodes,
> > card0-DP-1  -> DDI port B
> > card0-eDP-1/-> DDI port A
> > card0-HDMI-A-1/ -> DDI Port C
> > card0-HDMI-A-2/ -> Which DDI port ?  Haswell-ULT does not
> support port D, and I think port E is for VGA.
> 
> There's no fixed mapping with the port and the connector name. The
> number in the connector name is basically just a running number per
> connector type. However I do believe we do register the connectors in the
> order of the ports more or less always, so you can
> *sometimes* deduce the port name from the connector.
> 
> I suppose in this example HDMI-A-1 is port B, HDMI-A-2 is port C, and
> DP-1 can be either port B or port C. DP++ is the reason why we have
> overlapping DP and HDMI connectors for the same port.

Thanks for clarification, Ville!

Does Haswell support DP++ on port B/C/D?
And will the name of these connector node change after system boot, e.g. after 
S3/S4 cycles or hot-plug?


As long as the connector name is constant, it can help to find out the screen 
status no matter the port works in HDMI or DP mode.

There is 1:1 mapping between audio output pins and DDI ports.
And the new ALSA PCM 'screen' control for a pin can reflect the connector name 
in right mode. E.g. for pin/port B, it can return HDMI-A-1 or DP-1 depending on 
what kind of monitor is connected.

Thanks
Mengdong

> >
> > Hi Takashi,
> >
> > To make user space figure out which audio output is connected to which
> screen (connector), maybe we can define a new ALSA control for each
> HDMI/DP PCM device:
> > e.g. numid=x,iface=PCM,name='Screen',device=3
> > Reading the control will return the name of the DRM connector nodes
> like ' card0-DP-1'. The audio driver can get the connector name from the
> gfx driver.
> >
> > For DP1.2 Multi-stream transport, it's not supported by i915 and HD-A
> driver now. But probably there will be sub-nodes for the DP connector
> node in the future and an index in their name can be used distinguish
> monitors connected to the same DP port, like card0-DP-1.1, card0-DP-1.2,
> card0-DP-1.3 ... These names can be used by the above ALSA PCM 'Screen'
> control, so we can still know which audio output is to which monitor.
> >
> > Thanks
> > Mengdong
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrj?l?
> Intel OTC

Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Lin, Mengdong]

Sorry to pick up this thread after a long time.

> -Original Message-
> From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On Behalf 
> Of
> Daniel Vetter
> Sent: Thursday, January 23, 2014 4:27 PM
> To: Takashi Iwai

> On Thu, Jan 23, 2014 at 8:57 AM, Takashi Iwai  wrote:
> >> Thanks for clarification!
> >> Maybe we can add output info (eg. display port number) to the eld entries
> under /proc/asound/cardx. Is it okay?
> >
> > It's possible, but the proc file is just a help.  It can't be the API.
> > For accessing the information, we'll need some new API, or let inform
> > via sysfs of the new device.
> 
> Links in sysfs sound like the best approach. drm already has nodes for each
> connector, so on the gfx side there's a natural endpoint already.
> sysfs links also avoids any naming issues from the start, e.g. the above DP
> connector id might lead to clashes with multiple cards.

Hi Daniel,

Is there a 1:1 mapping between these connector nodes and ports of Gfx display 
engine?
Eg. For Haswell Ultrabook, under /sys/devices/pci:00/:00:02.0/drm/card0/
There are four connector nodes, 
card0-DP-1  -> DDI port B
card0-eDP-1/-> DDI port A
card0-HDMI-A-1/ -> DDI Port C
card0-HDMI-A-2/ -> Which DDI port ?  Haswell-ULT does not support port D, and I 
think port E is for VGA.

Hi Takashi,

To make user space figure out which audio output is connected to which screen 
(connector), maybe we can define a new ALSA control for each HDMI/DP PCM device:
e.g. numid=x,iface=PCM,name='Screen',device=3
Reading the control will return the name of the DRM connector nodes like ' 
card0-DP-1'. The audio driver can get the connector name from the gfx driver.

For DP1.2 Multi-stream transport, it's not supported by i915 and HD-A driver 
now. But probably there will be sub-nodes for the DP connector node in the 
future and an index in their name can be used distinguish monitors connected to 
the same DP port, like card0-DP-1.1, card0-DP-1.2, card0-DP-1.3 ... These names 
can be used by the above ALSA PCM 'Screen' control, so we can still know which 
audio output is to which monitor.

Thanks
Mengdong

Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Lin, Mengdong]

> -Original Message-
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Thursday, January 23, 2014 1:19 AM
> To: Daniel Vetter
> Cc: Lin, Mengdong; Barnes, Jesse; Zanoni, Paulo R;
> alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org; dri-devel
> Subject: Re: Need your advice: Add a new communication inteface
> between HD-Audio and Gfx drivers for hotplug notification/ELD update
> 
> At Wed, 22 Jan 2014 15:18:21 +0100,
> Daniel Vetter wrote:
> >
> > On Wed, Jan 22, 2014 at 12:48:04PM +, Lin, Mengdong wrote:
> > > > -Original Message-
> > > > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On
> > > > Behalf Of Daniel Vetter
> > > > Sent: Tuesday, January 21, 2014 9:11 PM
> > > > To: Lin, Mengdong
> > > > Cc: Takashi Iwai (tiwai at suse.de); Barnes, Jesse; Zanoni, Paulo R;
> > > > alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org
> > > > Subject: Re: Need your advice: Add a new communication inteface
> > > > between HD-Audio and Gfx drivers for hotplug notification/ELD
> > > > update
> > > >
> > > > On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong
> > > > 
> > > > wrote:
> > > > > Dear audio and gfx stakeholders,
> > > > >
> > > > >
> > > > >
> > > > > We hope to add a new interface between audio and gfx driver, for
> > > > > gfx driver to notify audio about HDMI/DP hot-plug and ELD update.
> > > > >
> > > > > Would you please share some comments on the proposal below?
> > > > >
> > > > >
> > > > >
> > > > > Background of this issue: On Intel Haswell/Broadwell platforms,
> > > > > there is a HW restriction that after the display HD-Audio
> > > > > controller is in D3,
> > > > >
> > > > > it cannot be waken up by HDMI/DP hot-plug. Consequently,
> > > > > although the gfx driver can still detect the HDMI/DP hot-plug,
> > > > >
> > > > > audio driver has no idea about this and cannot notify user space
> > > > > whether the external HDMI/DP monitor is available for audio
> > > > > playback,
> > > > >
> > > > > because the audio controller cannot wake up to D0 and receive HW
> > > > > unsolicited event about hot-plug from the audio codec.
> > > > >
> > > > > This limitation will affect user space to decide whether we can
> > > > > output audio over HDMI/DP.
> > > > >
> > > > >
> > > > >
> > > > > To solve the above limitation, Takashi suggested to add a new
> > > > > communication interface between audio and gfx driver: create a
> > > > common
> > > > > object
> > > > >
> > > > > containing the ops registered by both graphics and audio
> > > > > drivers, then communicate through it, something like
> vga_switcheroo.
> > > > >
> > > > >
> > > > >
> > > > > Is it okay to create this kernel object in i915 driver?
> > > > >
> > > > >
> > > > >
> > > > > I915 can export an API like "display_register_audio_client" for
> > > > > audio driver to register a client and hot-plug notification ops.
> > > > >
> > > > >
> > > > >
> > > > > I915 can also call some API like "display_register_gfx_client"
> > > > > itself and register ops for audio driver to query monitor
> > > > > presence and ELD info on a specific port.
> > > > >
> > > > > It would be faster for audio driver than quering ELD by
> > > > > command/response over the HD-A bus, thus avoid delay in i915
> > > > > mode
> > > > set.
> > > > >
> > > > > This will also avoid waking up the audio devices unnecessarily
> > > > > if the user space does not really want to use HDMI/DP for audio
> playback.
> > > > >
> > > > >
> > > > >
> > > > > Whenever i195 enables/disables audio on a port in modeset, it
> > > > > can call some API like "display_set_audio_state()" on this
> > > > > kernel object and trigger notifications to the audio driver.
> > > > >
> > > > >
>

Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Lin, Mengdong]

> -Original Message-
> From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On Behalf 
> Of
> Daniel Vetter
> Sent: Tuesday, January 21, 2014 9:11 PM
> To: Lin, Mengdong
> Cc: Takashi Iwai (tiwai at suse.de); Barnes, Jesse; Zanoni, Paulo R;
> alsa-devel at alsa-project.org; intel-gfx at lists.freedesktop.org
> Subject: Re: Need your advice: Add a new communication inteface
> between HD-Audio and Gfx drivers for hotplug notification/ELD update
> 
> On Tue, Jan 21, 2014 at 1:35 PM, Lin, Mengdong 
> wrote:
> > Dear audio and gfx stakeholders,
> >
> >
> >
> > We hope to add a new interface between audio and gfx driver, for gfx
> > driver to notify audio about HDMI/DP hot-plug and ELD update.
> >
> > Would you please share some comments on the proposal below?
> >
> >
> >
> > Background of this issue: On Intel Haswell/Broadwell platforms, there
> > is a HW restriction that after the display HD-Audio controller is in
> > D3,
> >
> > it cannot be waken up by HDMI/DP hot-plug. Consequently, although the
> > gfx driver can still detect the HDMI/DP hot-plug,
> >
> > audio driver has no idea about this and cannot notify user space
> > whether the external HDMI/DP monitor is available for audio playback,
> >
> > because the audio controller cannot wake up to D0 and receive HW
> > unsolicited event about hot-plug from the audio codec.
> >
> > This limitation will affect user space to decide whether we can output
> > audio over HDMI/DP.
> >
> >
> >
> > To solve the above limitation, Takashi suggested to add a new
> > communication interface between audio and gfx driver: create a
> common
> > object
> >
> > containing the ops registered by both graphics and audio drivers, then
> > communicate through it, something like vga_switcheroo.
> >
> >
> >
> > Is it okay to create this kernel object in i915 driver?
> >
> >
> >
> > I915 can export an API like "display_register_audio_client" for audio
> > driver to register a client and hot-plug notification ops.
> >
> >
> >
> > I915 can also call some API like "display_register_gfx_client" itself
> > and register ops for audio driver to query monitor presence and ELD
> > info on a specific port.
> >
> > It would be faster for audio driver than quering ELD by
> > command/response over the HD-A bus, thus avoid delay in i915 mode
> set.
> >
> > This will also avoid waking up the audio devices unnecessarily if the
> > user space does not really want to use HDMI/DP for audio playback.
> >
> >
> >
> > Whenever i195 enables/disables audio on a port in modeset, it can call
> > some API like "display_set_audio_state()" on this kernel object and
> > trigger notifications to the audio driver.
> >
> >
> >
> > When the audio driver is probed (in the delayed probe stage), it can
> > request
> > i915 API symbol to register the audio client for this communication
> > kernel object.
> >
> > Since the 1st i915 mode set may happen before audio driver registers
> > the ops, we'll let audio driver check ELD once after registering the
> > audio client ops.
> >
> > And for the platforms which uses this communication interface, we can
> > disable unsolicited event for HDMI/DP hot-plug in the audio driver.
> >
> >
> >
> > We hope to hear your feedback and start to work out more details.

Thanks for your advice, Daniel!

> Yeah, I've discussed this at KS with Takashi and we've agreed that some
> common object to facilitate driver interactions. A few things
> though:
> - This should be common infrastructure useable by all alsa and drm
> drivers, not just i915 and snd-hda. Especially on embedded platforms this
> issue is fairly rampant ...

Agree. Where to put this common object? 
Is it okay to put it under /driver/gpu/drm, similar to vga_switchroo?
Shall we divide clients into audio and gfx categories, and define different ops 
for them? Since different info/request flow in different direction between 
audio and gfx.

> - While at it it should also encompass power management handling of the
> shared hw imo so that we can get rid of the hsw specific hacks for the
> power well code. Or at least we need to rework the power well code to
> reuse this new infrastructure, I don't really want to maintain a few copies
> of the lazy symbol_get logic this kind of stuff requires.

Sounds good.

> - I think the biggest problem is figuring out who should register these
> device nodes. I think