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

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@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 11:54:28 -0600	[thread overview]
Message-ID: <56DDC054.9000305@linux.intel.com> (raw)
In-Reply-To: <20160305134215.GZ10446@intel.com>

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.
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).

>> 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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx