All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <pierre-list@ossman.eu>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: radeon multi-channel lpcm
Date: Wed, 5 Sep 2012 19:22:39 +0200	[thread overview]
Message-ID: <20120905192239.6a212683@mjolnir.ossman.eu> (raw)
In-Reply-To: <s5h4nnczaoq.wl%tiwai@suse.de>


[-- Attachment #1.1: Type: text/plain, Size: 1730 bytes --]

On Wed, 05 Sep 2012 18:39:01 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 5 Sep 2012 18:19:23 +0200,
> Pierre Ossman wrote:
> > 
> > Noone with any insight? I'm ready to do some leg work, but I couldn't
> > find anything in either the HDA specification, or the AMD
> > documentation. :/
> 
> Well, HD-audio HDMI codec driver just extracts the available channel
> setup from the given ELD, and the ELD data is sent from the graphics
> driver.  So, if anything missing in ELD, it's supposed to be in the
> graphics driver side.  In other words, if ELD doesn't give 6 channels,
> HD-audio codec won't follow that channel setup, too.
> 

I see. I got a bit confused by this code though:

	/* Restrict capabilities by ELD if this isn't disabled */
	if (!static_hdmi_pcm && eld->eld_valid) {

Which made me think that the ELD was just used to make sure you didn't
send something the other end couldn't handle. IOW, eld_valid == false
would give you all features the hw was capable off.


Some follow up questions, to confirm I haven't confused things:

 - The ELD really needs to go into the hardware, not just end up in the
   hands of the audio driver? IOW, we cannot override this?

 - The HDA interface only defines reading the ELD, so writing it would
   have to be done by the graphics driver using some GPU interface?

If so, I need to poke the AMD guys as I couldn't find any information
in the public documentation about writing the ELD.

Thanks
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by FRA, a
  Swedish intelligence agency. Make sure your server uses
  encryption for SMTP traffic and consider using PGP for
  end-to-end encryption.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2012-09-05 17:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-31 20:34 radeon multi-channel lpcm Pierre Ossman
2012-09-05 16:19 ` Pierre Ossman
2012-09-05 16:39   ` Takashi Iwai
2012-09-05 17:22     ` Pierre Ossman [this message]
2012-09-06  5:59       ` Takashi Iwai
2012-09-06  7:09         ` Pierre Ossman
2012-09-06  7:28           ` Takashi Iwai
2012-09-06  7:52             ` Pierre Ossman

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=20120905192239.6a212683@mjolnir.ossman.eu \
    --to=pierre-list@ossman.eu \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /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.