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