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