| 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
| ||
|
Date: Mon, 24 Jun 2024 19:27:10 +0100
From: Dave Stevenson <dave.stevenson@...pberrypi.com>
To: Frank Li <Frank.li@....com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>, Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>, Vinod Koul <vkoul@...nel.org>,
Maxime Ripard <mripard@...nel.org>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
Ulf Hansson <ulf.hansson@...aro.org>, Mark Brown <broonie@...nel.org>,
Christoph Hellwig <hch@....de>, Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>, Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Vladimir Murzin <vladimir.murzin@....com>, Phil Elwell <phil@...pberrypi.com>,
Stefan Wahren <wahrenst@....net>, Serge Semin <Sergey.Semin@...kalelectronics.ru>,
devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
dmaengine@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-mmc@...r.kernel.org, linux-spi@...r.kernel.org, iommu@...ts.linux.dev,
linux-sound@...r.kernel.org
Subject: Re: [PATCH 09/18] dmaengine: bcm2835: Add function to handle DMA mapping
On Wed, 5 Jun 2024 at 19:13, Frank Li <Frank.li@....com> wrote:
>
> On Fri, May 24, 2024 at 07:26:53PM +0100, Dave Stevenson wrote:
> > The code handling DMA mapping is currently incorrect and
> > needs a sequence of fixups.
>
> Can you descript what incorrect here?
Clients are passing in DMA addresses, not CPU physical addresses. I'll
update the commit message.
> > Move the mapping out into a separate function and structure
> > to allow for those fixes to be applied more cleanly.
> >
> > Signed-off-by: Dave Stevenson <dave.stevenson@...pberrypi.com>
> > ---
> > drivers/dma/bcm2835-dma.c | 46 ++++++++++++++++++++++++++++++++-------
> > 1 file changed, 38 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> > index aefaa1f01d7f..ef1d95bae84e 100644
> > --- a/drivers/dma/bcm2835-dma.c
> > +++ b/drivers/dma/bcm2835-dma.c
> > @@ -65,6 +65,10 @@ struct bcm2835_cb_entry {
> > dma_addr_t paddr;
> > };
> >
> > +struct bcm2835_dma_chan_map {
> > + dma_addr_t addr;
> > +};
> > +
> > struct bcm2835_chan {
> > struct virt_dma_chan vc;
> >
> > @@ -74,6 +78,7 @@ struct bcm2835_chan {
> > int ch;
> > struct bcm2835_desc *desc;
> > struct dma_pool *cb_pool;
> > + struct bcm2835_dma_chan_map map;
>
> I suppose map should in bcm2835_desc. if put in chan, how about client
> driver create two desc by bcm2835_dma_prep_slave_sg()?
>
> prep_slave_sg()
> submit()
> prep_savle_sg()
> submit()
> issue_pending()
I'm basing this on rcar-dmac.c which has a similar mode of operation.
For devices such as HDMI audio, I2S, SPI, etc, the peripheral's
address is constant. Mapping and unmapping adds an overhead. Retaining
the mapping in the chan structure allows the mapping to be cached
whilst the address remains the same, and is released whenever the
address changes.
If the map is in bcm2835_desc then as the desc is freed after every
transfer you'd have to unmap.
Dave
> Frank
>
> >
> > void __iomem *chan_base;
> > int irq_number;
> > @@ -268,6 +273,19 @@ static inline bool need_dst_incr(enum dma_transfer_direction direction)
> > }
> >
> > return false;
> > +};
> > +
> > +static int bcm2835_dma_map_slave_addr(struct dma_chan *chan,
> > + phys_addr_t dev_addr,
> > + size_t dev_size,
> > + enum dma_data_direction dev_dir)
> > +{
> > + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
> > + struct bcm2835_dma_chan_map *map = &c->map;
> > +
> > + map->addr = dev_addr;
> > +
> > + return 0;
> > }
> >
> > static void bcm2835_dma_free_cb_chain(struct bcm2835_desc *desc)
> > @@ -734,13 +752,19 @@ static struct dma_async_tx_descriptor *bcm2835_dma_prep_slave_sg(
> > }
> >
> > if (direction == DMA_DEV_TO_MEM) {
> > - if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> > + if (bcm2835_dma_map_slave_addr(chan, c->cfg.src_addr,
> > + c->cfg.src_addr_width,
> > + DMA_TO_DEVICE))
> > return NULL;
> > - src = c->cfg.src_addr;
> > +
> > + src = c->map.addr;
> > } else {
> > - if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> > + if (bcm2835_dma_map_slave_addr(chan, c->cfg.dst_addr,
> > + c->cfg.dst_addr_width,
> > + DMA_FROM_DEVICE))
> > return NULL;
> > - dst = c->cfg.dst_addr;
> > +
> > + dst = c->map.addr;
> > }
> >
> > /* count frames in sg list */
> > @@ -795,14 +819,20 @@ static struct dma_async_tx_descriptor *bcm2835_dma_prep_dma_cyclic(
> > __func__, buf_len, period_len);
> >
> > if (direction == DMA_DEV_TO_MEM) {
> > - if (c->cfg.src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> > + if (bcm2835_dma_map_slave_addr(chan, c->cfg.src_addr,
> > + c->cfg.src_addr_width,
> > + DMA_TO_DEVICE))
> > return NULL;
> > - src = c->cfg.src_addr;
> > +
> > + src = c->map.addr;
> > dst = buf_addr;
> > } else {
> > - if (c->cfg.dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> > + if (bcm2835_dma_map_slave_addr(chan, c->cfg.dst_addr,
> > + c->cfg.dst_addr_width,
> > + DMA_FROM_DEVICE))
> > return NULL;
> > - dst = c->cfg.dst_addr;
> > +
> > + dst = c->map.addr;
> > src = buf_addr;
> > }
> >
> > --
> > 2.34.1
> >
Powered by blists - more mailing lists