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

[Mark Brown]

On Thu, Nov 10, 2016 at 10:35:09AM -0600, Pierre-Louis Bossart wrote:
> On 11/9/16 7:19 AM, Mark Brown wrote:

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

I'm not particularly trying to be funny here, I'm just saying that
without having seen any of the code involved (I got CCed in part way
through this thread...) this sounds like fairly normal HDMI hardware so
it's hard to understand why it can't use the framework code (perhaps
with a bit of extension).  It does seem to be an unfortunate pattern
with HDMI in particular that people seem to see their hardware as
needing to use a separate implementation of everything which gets a bit
frustrating.

> 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

That all sounds totally sensible - I think the only real issue here is
exactly what the ALSA subdevice ends up looking like.

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

Sure, and that's what the hdmi-codec interface was supposed to be doing
as well.

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

If it's doing the same thing as hdmi-codec then simply not adding
another implementation of essentially the same thing ought to be a win.

If the problem is that it's a bit too much work to fill in the dummy
DAIs then let's just make it easier to instantiate them and a
simple-card to tie everything together.

> 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

Like I say I've not seen these patches (if they're not currently ASoC
patches that's not surprising), I don't know why they've not been
accepted so I can't really comment on that.

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

Like I say there's probably room for some helpers for setting this up in
simpler cases but even without them it is very common to end up with
dummy ASoC devices so I'm not sure I'd say they're impractical.  It'd be
good to at least have a concrete assessment of why it's unreasonably
difficult.

I don't have a particularly strong opinion either way on merging the
current code as it is, if there's a commitment to fixing it up then
that's the main thing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20161111/cb5dc027/attachment-0001.sig>