public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Noralf Trønnes" <noralf@tronnes.org>
To: Martin Sperl <martin@sperl.org>
Cc: 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
Subject: Re: [PATCH] dmaengine: bcm2835: Add slave dma support
Date: Wed, 15 Apr 2015 20:53:07 +0200	[thread overview]
Message-ID: <552EB393.4050609@tronnes.org> (raw)
In-Reply-To: <75BEAE20-81A9-4567-8AB2-1C1865A0B72D@sperl.org>


Den 15.04.2015 16:37, skrev Martin Sperl:
>> On 15.04.2015, at 11:56, Noralf Trønnes <noralf@tronnes.org> wrote:
>> +#define MAX_LITE_TRANSFER	(SZ_64K - 1)
>> +#define MAX_NORMAL_TRANSFER	SZ_1G
> ...
>> +	if (c->ch >= 8) /* LITE channel */
>> +		max_size = MAX_LITE_TRANSFER;
>> +	else
>> +		max_size = MAX_NORMAL_TRANSFER;
>> +	period_len = min(period_len, max_size);
>> +	d->frames = (buf_len - 1) / (period_len + 1);
> I wonder if it is wise to split the transfers on 65535 bytes for the
> Lite DMA-channels - especially if you are transferring to word size
> registers (like SPI_FIFO), you still push 16384 words into the register
> and the last word of this transfer (word 16384) still is assumed 4 valid
> bytes by the device and thus gets operated upon - even if the last byte
> contains garbage from the DMA-transfer point of view.
>
> So maybe it is better to separate on SZ_64K-4 or better still SZ_32K to
> be on a power of 2 address boundary.

The datasheet is contradictory:
BCM2835 ARM Peripherals - 4.5 DMA LITE Engines
3. The DMA length register is now 16 bits, limiting the maximum
    transferrable length to 65536 bytes.

A 16-bit register can't hold a value of 65536.
Either the max value is 65535 or the register is 17-bits wide.

There is currently no driver that we can use to test >32k buffers.
Unless someone disagrees, I will change this back to the SZ_32K
value from the original driver (and add a comment to explain that
32k is chosen to stay on the safe side).


  reply	other threads:[~2015-04-15 18:53 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 [this message]
2015-04-16  6:30     ` Rogier Wolff
2015-04-16 17:28       ` Noralf Trønnes
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=552EB393.4050609@tronnes.org \
    --to=noralf@tronnes.org \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.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