On Thu, Oct 29, 2015 at 03:42:59PM +, Damien Horsley wrote:
> For the I2S In, there is another issue with flushing on stream close. If
> the stream is stopped, then reconfigured to use a larger number of
> channels (without the stream being closed), then the per-channel fifos
> will become
On 28/10/15 23:43, Mark Brown wrote:
> On Wed, Oct 28, 2015 at 09:18:20PM +, 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
On 28/10/15 23:43, Mark Brown wrote:
> On Wed, Oct 28, 2015 at 09:18:20PM +, 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
On Thu, Oct 29, 2015 at 03:42:59PM +, Damien Horsley wrote:
> For the I2S In, there is another issue with flushing on stream close. If
> the stream is stopped, then reconfigured to use a larger number of
> channels (without the stream being closed), then the per-channel fifos
> will become
On Wed, Oct 28, 2015 at 09:18:20PM +, 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
On 28/10/15 01:04, Mark Brown wrote:
> On Tue, Oct 27, 2015 at 01:55:27PM +, Damien Horsley wrote:
>> On 23/10/15 23:57, Mark Brown wrote:
>
>>> Shouldn't we be doing that flush on stream close instead? If nothing
>>> else the flush is going to discard a bit of data if the stream is just
>>>
On 28/10/15 01:04, Mark Brown wrote:
> On Tue, Oct 27, 2015 at 01:55:27PM +, Damien Horsley wrote:
>> On 23/10/15 23:57, Mark Brown wrote:
>
>>> Shouldn't we be doing that flush on stream close instead? If nothing
>>> else the flush is going to discard a bit of data if the stream is just
>>>
On Wed, Oct 28, 2015 at 09:18:20PM +, 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
On Tue, Oct 27, 2015 at 01:55:27PM +, Damien Horsley wrote:
> On 23/10/15 23:57, Mark Brown wrote:
> > Shouldn't we be doing that flush on stream close instead? If nothing
> > else the flush is going to discard a bit of data if the stream is just
> > paused.
> The FIFOs are only 8 frames in
On 23/10/15 23:57, Mark Brown wrote:
> On Thu, Oct 22, 2015 at 08:09:38PM +0100, Damien Horsley wrote:
>> On 19/10/15 18:47, Mark Brown wrote:
>>> On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
>
>>> The APIs here all seem a bit odd - for example the enable API taking a
>>>
On Tue, Oct 27, 2015 at 01:55:27PM +, Damien Horsley wrote:
> On 23/10/15 23:57, Mark Brown wrote:
> > Shouldn't we be doing that flush on stream close instead? If nothing
> > else the flush is going to discard a bit of data if the stream is just
> > paused.
> The FIFOs are only 8 frames in
On 23/10/15 23:57, Mark Brown wrote:
> On Thu, Oct 22, 2015 at 08:09:38PM +0100, Damien Horsley wrote:
>> On 19/10/15 18:47, Mark Brown wrote:
>>> On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
>
>>> The APIs here all seem a bit odd - for example the enable API taking a
>>>
On Thu, Oct 22, 2015 at 08:09:38PM +0100, Damien Horsley wrote:
> On 19/10/15 18:47, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
> > The APIs here all seem a bit odd - for example the enable API taking a
> > register value as an argument (normally reg is
On Thu, Oct 22, 2015 at 08:09:38PM +0100, Damien Horsley wrote:
> On 19/10/15 18:47, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
> > The APIs here all seem a bit odd - for example the enable API taking a
> > register value as an argument (normally reg is
On 19/10/15 18:47, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
>
>> +static inline u32 img_i2s_in_ch_disable(struct img_i2s_in *i2s, u32 chan)
>> +{
>> +u32 reg;
>> +
>> +reg = img_i2s_in_ch_readl(i2s, chan, IMG_I2S_IN_CH_CTL);
>> +reg &=
On 19/10/15 18:47, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
>
>> +static inline u32 img_i2s_in_ch_disable(struct img_i2s_in *i2s, u32 chan)
>> +{
>> +u32 reg;
>> +
>> +reg = img_i2s_in_ch_readl(i2s, chan, IMG_I2S_IN_CH_CTL);
>> +reg &=
On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
> +static inline u32 img_i2s_in_ch_disable(struct img_i2s_in *i2s, u32 chan)
> +{
> + u32 reg;
> +
> + reg = img_i2s_in_ch_readl(i2s, chan, IMG_I2S_IN_CH_CTL);
> + reg &= ~IMG_I2S_IN_CH_CTL_ME_MASK;
> +
On Mon, Oct 12, 2015 at 01:40:29PM +0100, Damien Horsley wrote:
> +static inline u32 img_i2s_in_ch_disable(struct img_i2s_in *i2s, u32 chan)
> +{
> + u32 reg;
> +
> + reg = img_i2s_in_ch_readl(i2s, chan, IMG_I2S_IN_CH_CTL);
> + reg &= ~IMG_I2S_IN_CH_CTL_ME_MASK;
> +
18 matches
Mail list logo
