Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver

From: Mark Brown <broonie@kernel.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Ughreja, Rakesh A" <rakesh.a.ughreja@intel.com>
Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver
Date: Thu, 15 Dec 2016 11:44:04 +0000	[thread overview]
Message-ID: <20161215114404.i7svjnrg3cb3l2yq@sirena.org.uk> (raw)
In-Reply-To: <s5htwa5bg15.wl-tiwai@suse.de>

[-- Attachment #1.1: Type: text/plain, Size: 695 bytes --]

On Thu, Dec 15, 2016 at 12:14:30PM +0100, Takashi Iwai wrote:

> The interaction between i915 and audio is simple, yes, it just exposes
> a few things, mmio ptr, irq, etc.  But still I don't understand why
> multiple layers of indirect accesses are needed *inside* lpe audio
> driver itself.  For example, suspend/resume action is cascaded to yet
> another ops.

> I would understand if this "shell" provides a few thin accessors to
> the raw i915 registers.  But another layering over a single driver
> implementation makes little sense in regard of abstraction.  (If there
> were multiple class inherits, it's a different story, of course.)

We saw the same thing with the DSP code as well...

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx