devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Nicolas Saenz Julienne <nsaenz@kernel.org>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	bcm-kernel-feedback-list@broadcom.com, dmaengine@vger.kernel.org,
	Phil Elwell <phil@raspberrypi.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Lukas Wunner <lukas@wunner.de>,
	linux-rpi-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 00/11] dmaengine: bcm2835: add BCM2711 40-bit DMA support
Date: Tue, 15 Feb 2022 16:50:57 +0530	[thread overview]
Message-ID: <YguMmSMnh6G121HP@matsya> (raw)
In-Reply-To: <d4242317-711d-23ce-c63e-7d355c8c0e41@i2se.com>

On 23-01-22, 15:08, Stefan Wahren wrote:
> Hi,
> 
> Am 27.12.21 um 13:05 schrieb Stefan Wahren:
> > The BCM2711 has 4 DMA channels with a 40-bit address range, allowing them
> > to access the full 4GB of memory on a Pi 4. This patch series serves as a
> > basis for a discussion (just compile tested, so don't expect anything working)
> > which include the following points:
> >
> > * correct DT binding and representation for BCM2711
> >
> > According to the vendor DTS [1] the 4 DMA channels are connected to SCB.
> > I'm not sure how this is properly adapted to the mainline DT.
> >
> > * general implementation approach
> >
> > The vendor approach mapped all the BCM2835 control block bits to the BCM2711
> > layout and the rest of the differences are handled by a lot of is_40bit_channel
> > conditions. An advantage of this is the small amount of changes to the driver.
> > But on the down side the code is now much harder to understand and maintain.
> >
> > This series tries to implement this feature in a more cleaner way
> > while keeping it in the bcm2835-dma driver. Before this series the driver
> > has ~ 1000 lines and after that ~ 1500 lines.
> >
> > So the question is this approach acceptable?
> >
> > Patches 1 - 3 are just clean-ups.
> >
> > Disclaimer: my knowledge about the DMA controller is very limited
> >
> > More information:
> >
> > https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf
> >
> > [1] - https://github.com/raspberrypi/linux/blob/561deffcf471ba0f7bd48541d06a79d5aa38d297/arch/arm/boot/dts/bcm2711-rpi-ds.dtsi#L47
> > [2] - https://github.com/raspberrypi/linux/commit/44364bd140b0bc9187c881fbdc4ee358961059d5
> would be nice to get some input aka gentle ping.

Somehow patch 10/11 is appearing split from rest of the series. The
series looks fairly okay, dts needs more polishing as Rob indicated

-- 
~Vinod

  reply	other threads:[~2022-02-15 11:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27 12:05 [PATCH RFC 00/11] dmaengine: bcm2835: add BCM2711 40-bit DMA support Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 01/11] ARM: dts: bcm283x: Update DMA node name per DT schema Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 02/11] dt-bindings: dma: Convert brcm,bcm2835-dma to json-schema Stefan Wahren
2022-01-04 22:50   ` Rob Herring
2021-12-27 12:05 ` [PATCH RFC 03/11] dmaengine: bcm2835: Support common dma-channel-mask Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 04/11] dmaengine: bcm2835: move CB info generation into separate function Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 05/11] dmaengine: bcm2835: move CB final extra info generation into function Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 06/11] dmaengine: bcm2835: make address increment platform independent Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 07/11] dmaengine: bcm2385: drop info parameters Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 08/11] dmaengine: bcm2835: pass dma_chan to generic functions Stefan Wahren
2021-12-27 12:05 ` [PATCH RFC 09/11] dmaengine: bcm2835: introduce multi platform support Stefan Wahren
2022-01-23 14:08 ` [PATCH RFC 00/11] dmaengine: bcm2835: add BCM2711 40-bit DMA support Stefan Wahren
2022-02-15 11:20   ` Vinod Koul [this message]
2023-06-18 19:43 ` Shengyu Qu
2023-06-18 21:14   ` Stefan Wahren

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=YguMmSMnh6G121HP@matsya \
    --to=vkoul@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=lukas@wunner.de \
    --cc=nsaenz@kernel.org \
    --cc=phil@raspberrypi.com \
    --cc=rjui@broadcom.com \
    --cc=robh+dt@kernel.org \
    --cc=sbranden@broadcom.com \
    --cc=stefan.wahren@i2se.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;
as well as URLs for NNTP newsgroup(s).