Re: [PATCH 1/2] ARM: tegra: Add Tegra124 HDA support

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 4208 bytes --]

On Wed, Jun 04, 2014 at 01:04:05PM -0600, Stephen Warren wrote:
> On 06/04/2014 11:51 AM, Dylan Reid wrote:
> > On Wed, Jun 4, 2014 at 10:32 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> >> On 05/30/2014 07:45 PM, Dylan Reid wrote:
> >>> On Fri, May 23, 2014 at 1:34 PM, Dylan Reid <dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> >>>> On Fri, May 23, 2014 at 12:05 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >>>>> On 05/22/2014 09:55 PM, Dylan Reid wrote:
> >>>>> ...
> >>>>>>>>>>>>> On Tue, May 20, 2014 at 2:55 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >>>>> ...
> >>>>>>>>>>>>>> Now I have the same results as Thierry; speaker-test looks like it
> >>>>>>>>>>>>>> should be working, yet I don't hear any audio from the monitor. I know
> >>>>>>>>>>>>>> the monitor works, since I've used it extensively for testing GeForce
> >>>>>>>>>>>>>> GPU HDMI audio.
> >>>>> ...
> >>>>>> Took all day, but I did get to try this.
> >>>>>>
> >>>>>> on U-Boot commit d7782d0, flashed with Stephen's u-boot flasher from github.
> >>>>>>
> >>>>>> And kernel at 81d0207 - ARM: tegra: enable HD-Audio controller in defconfig
> >>>>>> plus the addition of the hda node "okay"  to the jetson-tk1 DT.
> >>>>>>
> >>>>>> I can hear the jetson's audio on the TV.  This is currently a sample
> >>>>>> size of one TV, I'll set up the Quantum Data tomorrow and check that
> >>>>>> it works there as well.
> >>>>>
> >>>>> I tried that same U-Boot commit (with a few device-mode USB patches on
> >>>>> top that shouldn't affect anything since I didn't use USB device mode)
> >>>>> and have the same results.
> >>>>>
> >>>>> My monitor is a Dell U2410 with sound bar.
> >>>
> >>> I found one of these.  I also didn't hear any audio.  In fact I
> >>> couldn't get audio out of most monitors, TV sets worked fine.
> >>>
> >>> hdmi.c couldn't configure audio for the pixel clock generated for the
> >>> monitor.  Luckily I found a patch in our downstream tree that fixes
> >>> it.
> >>>
> >>> video: tegra: Calculate HDMI audio CTS/N/AVAL values -- 7/25/11 author
> >>> swarren =)
> >>>
> >>> Thanks for fixing this for me!
> >>>
> >>> I can send this up unless you'd rather send it yourself.
> >>>
> >>> I appended the patch moved to the new location of hdmi.c:
> >>
> >> That wouldn't apply for me since all the TABs were spaces in the email.
> >> I tracked down the original and manually ported it over. You can find it
> >> in my github if you're interested:
> >>
> >> git://github.com/swarren/linux-tegra.git tegra_dev
> >>
> >> That patch does make things a bit better, but there are still some issues.
> >>
> >> When my (Venice2) system boots, the login screen is displayed at native
> >> LCD resolution, and my HDMI monitor displays a 1920x1200 chunk from the
> >> top-left of the LCD. At this point, I can play 44.1KHz audio without
> >> issue. 48KHz doesn't work due to hdmi->audio_freq not being updated, as
> >> I mentioned in my previous mail.
> > 
> > Do you have a good idea how to convey this information from the audio
> > driver over to HDMI?
> > Downstream I see we have a hideous if CONFIG_TEGRA_DC in patch_hdmi.
> 
> The only way of avoiding that would be to create some kind of common
> infra-structure where video drivers can register for notifications from
> arbitrary audio devices. Then, the HDA code could always call this, and
> there'd be no direct references between the two drivers. To be honest
> though, this feels like creating a whole bunch of overhead for something
> that's very simple and likely not a maintenance issue, so I'm not sure
> there's much benefit doing that.

FWIW, there's currently a discussion going on about this on alsa-devel:

	[RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)
	http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076800.html
	http://mailman.alsa-project.org/pipermail/alsa-devel/2014-June/077371.html

Some of the ideas discussed there seem to be overengineered, but in
light of this thread it might be good if you guys could join in and
share some of your insights.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]