linux-kernel - Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

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]

Date:   Sun, 30 Oct 2016 07:16:26 +0100
From:   Jean-Francois Moine <moinejf@...e.fr>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Mark Rutland <mark.rutland@....com>,
        Linux-ALSA <alsa-devel@...a-project.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mike Turquette <mturquette@...libre.com>,
        Takashi Iwai <tiwai@...e.com>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Lee Jones <lee.jones@...aro.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        Vinod Koul <vinod.koul@...el.com>,
        Mylène Josserand 
        <mylene.josserand@...e-electrons.com>,
        devicetree <devicetree@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>, dmaengine@...r.kernel.org
Subject: Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

On Sun, 30 Oct 2016 10:06:20 +0800
Chen-Yu Tsai <wens@...e.org> wrote:

> >> Yes, I know that the burst size is always a power of 2.
> >> The best way to check it would be to change the {src,dts}_maxburst to a
> >> bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
> >> asks for a lot of changes...
> >
> > To be honest, I'm not really a big fan of those tree wide changes
> > without any way to maintain compatibility. It ends up in a single,
> > huge patch if we want to maintain bisectability that just isn't
> > reviewable.
> 
> Looking at the dmaengine API, I believe we got it wrong.
> 
> max_burst in dma_slave_config denotes the largest amount of data
> a single transfer should be, as described in dmaengine.h:
> 
>  * @src_maxburst: the maximum number of words (note: words, as in
>  * units of the src_addr_width member, not bytes) that can be sent
>  * in one burst to the device. Typically something like half the
>  * FIFO depth on I/O peripherals so you don't overflow it. This
>  * may or may not be applicable on memory sources.
>  * @dst_maxburst: same as src_maxburst but for destination target
>  * mutatis mutandis.
> 
> The DMA engine driver should be free to select whatever burst size
> that doesn't exceed this. So for max_burst = 4, the driver can select
> burst = 4 for controllers that do support it, or burst = 1 for those
> that don't, and do more bursts.
> 
> This also means we can increase max_burst for the audio codec, as
> the FIFO is 64 samples deep for stereo, or 128 samples for mono.
> 
> 
> If we agree on the above I can send some patches for this.

That's fine to me, but this does not solve the main problem which is
how/where are defined the possible bursts of a SoC.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/