[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151028234334.GF28319@sirena.org.uk>
Date: Thu, 29 Oct 2015 08:43:34 +0900
From: Mark Brown <broonie@...nel.org>
To: Damien Horsley <Damien.Horsley@...tec.com>
Cc: alsa-devel@...a-project.org,
James Hartley <James.Hartley@...tec.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH V2 02/10] ASoC: img: Add driver for I2S
input controller
On Wed, Oct 28, 2015 at 09:18:20PM +0000, Damien Horsley wrote:
> On 28/10/15 01:04, Mark Brown wrote:
> >> I think it also makes sense to keep the blocks consistent with each
> >> other. The spdif (out and in), and parallel out, all flush automatically
> >> when stopped, and the fifo for the i2s out block is cleared when the
> >> reset is asserted.
> > This seems like an issue that got missed in the other drivers then. I'd
> > expect the trigger operation to be a minimal operation which starts and
> > stops the data transfer, not doing anything else.
> The spdif out, spdif in, and parallel out blocks auto-flush whenever
> they are stopped. It is not possible for software to prevent this behavior.
Oh, so this isn't the drivers doing this? In that case it's fine for
them to do that, if it's what the hardware does it's what the hardware
does. It sounded like you were saying that there was similar code in
the other drivers.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists