All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Yodel Eldar <yodel.eldar@yodel.dev>
Cc: qemu-devel@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"open list:Raspberry Pi" <qemu-arm@nongnu.org>,
	"Florian Meier" <florian.meier@koalo.de>,
	"Florian Fainelli" <florian.fainelli@broadcom.com>
Subject: Re: [RFC PATCH] hw/dma: don't allow weird transfer lengths for bcm2835
Date: Fri, 14 Nov 2025 16:43:16 +0000	[thread overview]
Message-ID: <87wm3so997.fsf@draig.linaro.org> (raw)
In-Reply-To: <4d6d7e9d-0952-4158-9ef4-6093a16e9dd9@yodel.dev> (Yodel Eldar's message of "Fri, 14 Nov 2025 10:05:58 -0600")

Yodel Eldar <yodel.eldar@yodel.dev> writes:

(add Florians to CC)

> On 11/11/2025 04:54, Alex Bennée wrote:
>> The datasheet doesn't explicitly say that TXFR_LEN has to be word
>> aligned but the fact there is a DMA_D_WIDTH flag to select between 32
>> bit and 128 bit strongly implies that is how it works. The downstream
>
> At the bottom of page 38, the datasheet [1] states "the DMA can deal
> with byte aligned transfers and will minimise bus traffic by buffering
> and packing misaligned accesses."
>
> IIUC, the *_WIDTH info fields are implied as maxima.
>
> [1] https://datasheets.raspberrypi.com/bcm2835/bcm2835-peripherals.pdf

That reads ambiguously - you could start a misaligned n*WIDTH transfer
and the hardware will write bytes until aligned?

If it does indeed work with byte accesses maybe we can just do:

  if (xlen & 0x3) {
    .. do one byte ..
    xlen -= 1;
  } else {
    .. existing 32 bit code ..
  }

but I guess we need to handle unaligned accesses as well.

Florian,

Can you help clarify what the datasheet means here?

Thanks,

<snip>

>> rpi kernel also goes to efforts to not write sub-4 byte lengths so
>> lets:

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro


  parent reply	other threads:[~2025-11-14 16:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 10:54 [RFC PATCH] hw/dma: don't allow weird transfer lengths for bcm2835 Alex Bennée
2025-11-11 11:24 ` Peter Maydell
2025-11-14 16:05 ` Yodel Eldar
2025-11-14 16:15   ` Peter Maydell
2025-11-14 16:43   ` Alex Bennée [this message]
2025-11-14 16:51     ` Florian Kauer
2025-11-16 13:48     ` Yodel Eldar
2025-11-16 18:43       ` REVOLVE via

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=87wm3so997.fsf@draig.linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=farosas@suse.de \
    --cc=florian.fainelli@broadcom.com \
    --cc=florian.meier@koalo.de \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=yodel.eldar@yodel.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.