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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 14 Nov 2016 10:24:48 +0530
From:   Vinod Koul <vinod.koul@...el.com>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     "maxime.ripard@...e-electrons.com" <maxime.ripard@...e-electrons.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "thomas.petazzoni@...e-electrons.com" 
        <thomas.petazzoni@...e-electrons.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "moinejf@...e.fr" <moinejf@...e.fr>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-sunxi@...glegroups.com" <linux-sunxi@...glegroups.com>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "alexandre.belloni@...e-electrons.com" 
        <alexandre.belloni@...e-electrons.com>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "mylene.josserand@...e-electrons.com" 
        <mylene.josserand@...e-electrons.com>,
        "sboyd@...eaurora.org" <sboyd@...eaurora.org>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

On Tue, Nov 01, 2016 at 10:55:13PM +0800, Chen-Yu Tsai wrote:

> >>  * @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.
> >
> > Nope, the client configures these parameters and dmaengine driver
> > validates and programs
> 
> Shouldn't we just name it "burst_size" then if it's meant to be what
> the client specifically asks for?

Well if for some reason we program lesser than than max it would work
technically. But a larger burst wont work at all, so thats why maxburst is
significant.

> My understanding is that the client configures its own parameters,
> such as the trigger level for the DRQ, like raise DRQ when level < 1/4
> FIFO depth, request maxburst = 1/4 or 1/2 FIFO depth, so as not to
> overrun the FIFO. When the DRQ is raised, the DMA engine will do a
> burst, and after the burst the DRQ would be low again, so the DMA
> engine will wait. So the DMA engine driver should be free to
> program the actual burst size to something less than maxburst, shouldn't
> it?

Yup but not more that max..

> >> 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.
> >
> > Beware that higher bursts means chance of underrun of FIFO. This value
> > is selected with consideration of power and performance required. Lazy
> > allocation would be half of FIFO size..
> 
> You mean underrun if its the source right? So the client setting maxburst
> should take the DRQ trigger level into account for this.

Yes

-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ