Re: [RFC 00/15] HDMI Audio support on Atom w/o HDAUdio

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: mengdong.lin@linux.intel.com, tiwai@suse.de,
	intel-gfx@lists.freedesktop.org, liam.r.girdwood@linux.intel.com,
	vinod.koul@intel.com, broonie@kernel.org,
	rakesh.a.ughreja@intel.com
Subject: Re: [RFC 00/15] HDMI Audio support on Atom w/o HDAUdio
Date: Mon, 7 Mar 2016 20:02:47 +0200	[thread overview]
Message-ID: <20160307180247.GG10446@intel.com> (raw)
In-Reply-To: <56DDC054.9000305@linux.intel.com>

On Mon, Mar 07, 2016 at 11:54:28AM -0600, Pierre-Louis Bossart wrote:
> On 3/5/16 7:42 AM, Ville Syrjälä wrote:
> > On Fri, Mar 04, 2016 at 08:50:37PM -0600, Pierre-Louis Bossart wrote:
> >> When HDaudio is not enabled or fused-out, an alternate hardware
> >> interface can be used to provide audio data to the display/HDMI
> >> controller on Atom platforms.  The code to control this interface was
> >> never submitted upstream but has been used extensively in Android
> >> programs on Medfield, Clovertrail, Merrifield, Moorefield, Baytrail-T
> >> and CherryTrail-T, as well as the Baytrail Compute Stick w/ Ubuntu.
> >
> > Not sure why you skirt around calling the thing by its name. It's
> > called LPE isn't it?
> 
> No. LPE aka SST is the path to the audio dsp subsystem.
> This path to HDMI has nothing to do with the audio dsp. Not a single 
> gate is shared.

The why are the interrupt bits called LPE_somethingsomething?
And what generates the audio data then?

> In most Android implementations this driver is probed using a dedicated 
> ACPI _HID different from the LPEA one. For upstream and machines that 
> don't have this specific device in the BIOS we may piggyback on the LPEA 
> device to complete the probe (that's how it's done on Windows apparently).

Hmm. So it's a third audio controller or something? Just someone named
the display related bits as LPE just to confuse people on purpose?

> 
> >> The main feedback expected in this RFC is on the interaction between
> >> audio and display driver, specifically if we can wrap the interface
> >> control with the component framework already used between i915 and
> >> HDaudio. A short documentation was added to help explain how the
> >> hardware works.
> >
> > Yes, using/extending the already existing audio component stuff was
> > my first though when I did a preliminary scan of the patches. I didn't
> > look too closely at what's needed hardware wise, so can't get into
> > details yet.
> >
> > Some other peculiar things that caught my eye:
> > - adds some HDMI live status stuff etc. which we already have
> 
> if we can reuse existing parts we can prune this driver.
> 
> > - missing pipe C for CHV?
> 
> yes, none of the CHT changes are included for now.
> 
> > - no clue what that procfs/rpm patch was about
> 
> it's very likely legacy code, i don't know if it's needed any longer.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx