From: "Noralf Trønnes" <noralf@tronnes.org>
To: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Cc: Martin Sperl <martin@sperl.org>,
dmaengine@vger.kernel.org, vinod.koul@intel.com,
linux-kernel@vger.kernel.org, jonathan@raspberrypi.org,
linux-rpi-kernel@lists.infradead.org, dan.j.williams@intel.com,
Dom Cobley <dom@raspberrypi.org>
Subject: Re: [PATCH] dmaengine: bcm2835: Add slave dma support
Date: Thu, 16 Apr 2015 19:28:25 +0200 [thread overview]
Message-ID: <552FF139.9020007@tronnes.org> (raw)
In-Reply-To: <20150416063055.GH23239@bitwizard.nl>
Den 16.04.2015 08:30, skrev Rogier Wolff:
> On Wed, Apr 15, 2015 at 08:53:07PM +0200, Noralf Trønnes wrote:
>
>> A 16-bit register can't hold a value of 65536.
>> Either the max value is 65535 or the register is 17-bits wide.
> It is common for hardware registers to have the value "0" mean 65536
> in case of a 16-bit register.
>
> The hardware would then FIRST decrement the register and THEN check
> for zero. This results in the behaviour that "1" requires one cycle to
> complete, "10" requires ten cycles, and "0" means the same as the
> total number of bitpatterns possible in the register. (256 for an
> 8-bit register, 65536 for a 16-bit register).
>
> Another way to implement such a register in hardware would "check for
> zero" first, and not do antyhing if the register equals zero. This
> results in differnet behaviour for the "0" value.
>
> That said: IMHO, the overhead of setting up 2 transfers for each 64k
> block as opposed to only one results in such a small performance
> penalty that I'd prefer to play it safe unless you're very sure you
> can adequately test it. (Another option would be to set the maximum
> transfer size to 0xf000: 60kbytes. Less than 10% extra transfers in
> the long run than when aiming for the edge...)
Dom Cobley (Raspberry Pi) has just been in contact with
the hardware designer. He said:
65535 is the maximum transfer length of a LITE channel.
65536 will be treated as zero which is undefined
(it will actually do one transfer then stop)
Additional info from the datasheet about Lite channels:
The internal data structure is 128 bits instead of 256 bits.
This means that if you do a 128 bit wide read burst of more
than 1 beat, the DMA input register will be full and the read
bus will be stalled. The normal DMA engine can accept a read
burst of 2 without stalling. If you do a narrow 32 bit read
burst from the peripherals then the lite engine can cope with
a burst of 4 as opposed to a burst of 8 for the normal engine.
This suggest to me that we could go as far as the last 128-bit
boundary like this: (SZ_64K - 16)
next prev parent reply other threads:[~2015-04-16 17:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 9:56 [PATCH] dmaengine: bcm2835: Add slave dma support Noralf Trønnes
2015-04-15 14:37 ` Martin Sperl
2015-04-15 18:53 ` Noralf Trønnes
2015-04-16 6:30 ` Rogier Wolff
2015-04-16 17:28 ` Noralf Trønnes [this message]
2015-04-15 19:00 ` Stefan Wahren
2015-04-16 19:06 ` Alexander Stein
2015-04-16 22:03 ` Noralf Trønnes
2015-04-16 22:09 ` Noralf Trønnes
2015-04-17 17:08 ` Stefan Wahren
2015-04-17 17:19 ` Martin Sperl
2015-04-17 17:20 ` Noralf Trønnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=552FF139.9020007@tronnes.org \
--to=noralf@tronnes.org \
--cc=R.E.Wolff@bitwizard.nl \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=dom@raspberrypi.org \
--cc=jonathan@raspberrypi.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=martin@sperl.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox