[PATCH] drm/tegra: sor: Support for audio over HDMI

[Thierry Reding]

On Tue, Dec 04, 2018 at 04:50:44PM +0300, Dmitry Osipenko wrote:
> On 04.12.2018 16:08, Thierry Reding wrote:
> > On Tue, Dec 04, 2018 at 02:09:07PM +0300, Dmitry Osipenko wrote:
> >> On 03.12.2018 18:36, Thierry Reding wrote:
> >>> From: Thierry Reding <treding at nvidia.com>
> >>>
> >>> This code is very similar to the audio over HDMI support on older chips.
> >>> Interoperation with the audio codec is done via a pair of codec scratch
> >>> registers and an interrupt that is raised at the SOR when the codec has
> >>> written those registers.
> >>>
> >>> Signed-off-by: Thierry Reding <treding at nvidia.com>
> >>> ---
> >>
> >> Do you have any plans to implement integration with the sound
> >> subsystem? Indeed, there is HDMI audio configuration code for older
> >> chips in the Tegra's DRM driver that was added years ago.. but IIUC
> >> it's a kinda "dead code" without the integration.
> > 
> > The integration all lives in sound/pci/hda/hda_tegra.c for the HDA
> > controller driver and sound/pci/hda/patch_hdmi.c for the HDMI codec
> > driver. The way that this works is that the HDMI codec driver writes
> > information about the audio format to so-called scratch registers via
> > HDA verbs. These HDA verbs are accessible in the SORs (or the HDMI on
> > older Tegra) which basically represent the HDMI codec. Writes to these
> > registers are detected and an interrupt is raised in the SOR (or HDMI)
> > controller, upon which the interrupt handler will configure the output
> > as needed for playback (i.e. program some registers, send out audio
> > infoframe, ...).
> > 
> > From a userspace point of view you can simply access the HDMI codec as
> > an ALSA sound card. For example I use the speaker-test utility (from
> > alsa-utils) to test output like this:
> > 
> > 	$ speaker-test -D hw:0,8 -c -F S16_LE -r 48000 -t sine -f 250 -l 1
> > 
> > The same code that works from Tegra30 to Tegra210 also works on Tegra186
> > and Tegra194, though I have patches (which I plan to send out later
> > today) which add the HDA_CODEC_ENTRY entries as well as the necessary
> > device tree nodes to make all this work.
> > 
> > Does that clarify things?
> 
> Yes, that sounds like a nice way to integrate HW. I was also thinking
> from a good-old T20 perspective which AFAIK doesn't have that kind of
> HW integration, so was curious how it works for later Tegra's. Thank
> you very much for the explanation. Though it shouldn't be difficult to
> add SW integration with the audio codec.. but probably there was just
> no much need for it ever. It's good to know that it works for T30+,
> please keep up the good work :)

Yeah, downstream was (and still is I think) using a pure SW integration,
but it requires a custom API and then complicated code to look up the
correct SOR for a given HDMI codec and vice versa. Doing it via the HDA
codec scratch registers is what was originally intended from the design
teams and removes the need for any hacks.

For Tegra20 the situation is completely different because it doesn't
even have HDA, so we'd need to hook up one of the SPDIF outputs to HDMI
if we wanted to support HDMI audio there. I suspect that there must be
existing mechanisms to do this for platform devices, given that there
must be other devices that support HDMI audio and that don't integrate
tightly with an HDA codec.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20181204/bb6a6ca7/attachment.sig>