[Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

[Pierre-Louis Bossart]

On 11/9/16 7:19 AM, Mark Brown wrote:
> On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote:
>
>> I am all for convergence when it makes sense but I don't see how
>> hdmi-codec.h provides equivalent functionality for BYT/CHT with what was
>> suggested in this patchset -derived from VED patches- and discussed earlier
>> with intel-gfx folks, specifically how LPE pipe interrupts are
>> masked/unmasked and passed to the audio driver? The BYT/CHT HDMI
>
> Without knowing what these things are it's hard to comment but it does
> seem that if Intel has a reasonable use case for them then so too will
> other vendors at some point.
>
>> functionality is also not modeled as an ASoC codec - which seems a
>> dependency from the comments in hdmi-codec.h - since it's really part of the
>> i915 hardware and exposed only as a set of registers+DMA, without any serial
>> link interface typically needed for an external device or the internal
>> HDAudio-display link.
>
> None of which is at all unusal.  The Intel hardware really doesn't seem
> like the sort of special snowflake that people appear to believe it to
> be.

I am not sure if this reply was British humor, sarcasm or a proposal? 
Again the hardware for Baytrail and Cherrytrail is very simple, the 
display subsystem exposes a DMA interface with a 4 descriptors pointing 
to buffers in system memory and a window of registers to enable DMA 
transfers and signal interrupts for DMA events. Rather than adding ALSA 
related code in the i915 driver, the proposal is to create a subdevice 
that is given access to the relevant register window and a matching 
driver in sound/x86 that would take care of creating a card and 
implementing ALSA-related initializations and buffer/periods management. 
The interaction between the two gfx and audio parts is based on a very 
limited set of pdata variables and callbacks. From the gfx perspective 
this minimizes the code changes and dependencies on ALSA.
The hdmi-codec interface seems to assume an ASoC implementation which 
seems over-engineered in this case. There is no specific power 
management issues, no real need for cpu- or codec-dai and not physical 
link such as I2S/SPDIF. The only thing that seems directly useful if the 
pdata part which I already had. If I missed anything I am all ears.

Note that I am not trying to solve HDAudio-gfx interaction, just to get 
audio support for baytrail and cherrytrail compute sticks in the 
mainline. I've been porting patches to help users since 4.4, starting 
from the work Canonical did and internal patches, and it gets tiring. At 
this point I am looking for either agreement to proceed with the 
solution suggested in these patches which works fine with minimal 
impacts to either the drm or alsa domains, or an actual useful/pragmatic 
counter-proposal. If there is a grand plan of transition to a unified 
TBD interface for all HDMI cases then I would ask that this is done in a 
second step after the audio functionality is added.