linux-kernel - Re: [PATCH RFC 1/1] ASoC: fsl_ssi: Make fifo watermark and maxburst settings device tree options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG5mAdy553q4Te5755575WaiLxGRp43h=WVH6QzF7idsaCnhbg@mail.gmail.com>
Date:	Fri, 15 Jan 2016 09:03:28 -0800
From:	Caleb Crome <caleb@...me.org>
To:	Timur Tabi <timur@...i.org>
Cc:	Mark Brown <broonie@...nel.org>,
	Nicolin Chen <nicoleotsuka@...il.com>,
	Xiubo Li <Xiubo.Lee@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Subject: Re: [PATCH RFC 1/1] ASoC: fsl_ssi: Make fifo watermark and maxburst
 settings device tree options

On Fri, Jan 15, 2016 at 5:46 AM, Timur Tabi <timur@...i.org> wrote:
> Mark Brown wrote:
>>>
>>> >I admit it's a grey area, but the hardware doesn't work if you use the
>>> > wrong
>>> >value, and it is a fixed value per device.  A p1022ds would use a
>>> > different
>>> >value than in in i.MX6, and once you pick a value, it's the same no
>>> > matter
>>> >which sample rate, buffer size, etc you choose.
>
>
>> Caleb's original message suggested this was rate dependant.
>

>
> Yeah, I just noticed that.  In that case, I agree that a device tree
> property is inappropriate, unless it's an array that contains tuples of
> sample rates and watermark/maxburst settings.  That would get unwieldy very
> easily, though.

The rate dependance is only a *potential* issue.  I suspect that a
value of 4 should be functional for all rates and chips.  The only
trade off is more DMA requests/bursts.

In a typical 15 word fifo, 48kHz, stereo, single fifo DMA system,  the
old value was 15-2 = 13, which would mean 7385 13-word DMA
bursts/second.    A new value of 4 would mean 24,000 4-word DMA
bursts/second.

Is that consequential for anybody?  It's about the same total
bandwidth on the system, but just broken up into smaller chunks (I
don't know what the overhead is for a DMA burst)

In a high channel count system (16 channels @ 48kHz), the old value
doesn't work, and the new value would mean 192,000 4-word DMA
bursts/second, which works on my MX6.  So given that 192000 works
fine, I'm not sure that the difference in a typical system would
matter at all.

If nobody objects, we can just set the value to 4 and be done with it.

Another question:  is the watermark ever going to be different than
maxburst?  Is there any reason to have them different?

-Caleb