[Intel-gfx] [RFC 00/15] HDMI Audio support on Atom w/o HDAUdio

Ville Syrjälä ville.syrjala at linux.intel.com
Mon Mar 7 18:29:12 UTC 2016

On Mon, Mar 07, 2016 at 12:12:32PM -0600, Pierre-Louis Bossart wrote:
> >>> 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?
> I don't think the HAS ever mentioned LPE, it's really unrelated to LPE. 

The display cluster HAS calls it LPE. It does say though that it's more
or less just the display controller DMAing stuff in. We should definitely
add a note somewhere explaining that it's not really related to the other
LPE, other than by being enabled at the same time. Or can we actually use
the display engine LPE even if HDA is enabled and the other LPE is

> LPE cannot even get the interrupts or access the registers.
> The audio data is generated by the application, written to a ring buffer 
> and fetch by the DMA before they are inserted in the audio islands
> >
> >> 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?
> it's really an interface to the display controller, not a new hardware 
> part. Everything called LPE should be renamed to avoid this confusion.

Ville Syrjälä
Intel OTC

More information about the Intel-gfx mailing list