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