From: Fredrik Noring <noring-zgYzP9v7iJcdnm+yROfE0A@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: JuergenUrban-Mmb7MZpHnFY@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
"Maciej W. Rozycki"
<macro-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] dma-mapping: Relax warnings for per-device areas
Date: Fri, 6 Jul 2018 22:54:50 +0200 [thread overview]
Message-ID: <20180706205449.GB2313@localhost.localdomain> (raw)
In-Reply-To: <bd63815c-260e-078f-4184-561c8e54e636-5wv7dgnIgG8@public.gmane.org>
Hi Robin,
> > Does dma_set_coherent_mask want a device object representing the IOP? Such
> > a thing is currently not implemented, but can certainly be done.
>
> Nope, just the same OHCI device as the dma_declare_coherent_memory() call.
Ah... and then some kind of dma_ops structure is needed to avoid -EIO?
Possibly using set_dma_ops()?
By the way, the DMA hardware supports executing device->{memory,FIFO},
{memory,FIFO}->device and FIFO<->memory simultaneously, with hardware stall
control, between different devices where memory or FIFOs act as intermediate
buffers. Memory can also be a source or a destination.
That might be a way to have the OHCI efficiently transfer data from/to main
memory. I suppose it would be two simultaneously linked DMA transfers such
as
OHCI <-> SIF <-> main memory
or even three linked DMA transfers as in
OHCI <-> IOP memory <-> SIF <-> main memory
where SIF is the IOP DMA interface, which is a bidirectional hardware FIFO.
Does the kernel DMA subsystem support simultaneously linked DMA transfers?
In addition, the DMA hardware also supports scatter-gather (chaining), so
memory need not be physically continuous.
> > As you noted, the kernel cannot and must not allocate any kind of normal
> > memory for this device. Typical DMA addresses 0-0x200000 are mapped to
> > 0x1c000000-0x1c200000 and is memory managed exclusively by the IOP. What
> > would be a suitable mask for that?
>
> For the sake of accuracy, I guess maybe DMA_BIT_MASK(20) since that's what
> the OHCI's effective addressing capability is, even if it does happen to be
> to remote IOP RAM.
Isn't it 21 for 2 MiB? Hmm... I'm considering raising that to 8 MiB since
there are such devices too.
> Alternatively, there is perhaps some degree of argument
> for deliberately picking a nonzero but useless value like 1, although it
> looks like the MIPS allocator (at least the dma-default one) never actually
> checks whether the page it gets is within range of the device's coherent
> mask, which it probably should do.
Perhaps Maciej knows more about the details of the MIPS allocator?
Fredrik
WARNING: multiple messages have this Message-ID (diff)
From: Fredrik Noring <noring@nocrew.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
"Maciej W. Rozycki" <macro@linux-mips.org>,
JuergenUrban@gmx.de
Subject: Re: [PATCH] dma-mapping: Relax warnings for per-device areas
Date: Fri, 6 Jul 2018 22:54:50 +0200 [thread overview]
Message-ID: <20180706205449.GB2313@localhost.localdomain> (raw)
In-Reply-To: <bd63815c-260e-078f-4184-561c8e54e636@arm.com>
Hi Robin,
> > Does dma_set_coherent_mask want a device object representing the IOP? Such
> > a thing is currently not implemented, but can certainly be done.
>
> Nope, just the same OHCI device as the dma_declare_coherent_memory() call.
Ah... and then some kind of dma_ops structure is needed to avoid -EIO?
Possibly using set_dma_ops()?
By the way, the DMA hardware supports executing device->{memory,FIFO},
{memory,FIFO}->device and FIFO<->memory simultaneously, with hardware stall
control, between different devices where memory or FIFOs act as intermediate
buffers. Memory can also be a source or a destination.
That might be a way to have the OHCI efficiently transfer data from/to main
memory. I suppose it would be two simultaneously linked DMA transfers such
as
OHCI <-> SIF <-> main memory
or even three linked DMA transfers as in
OHCI <-> IOP memory <-> SIF <-> main memory
where SIF is the IOP DMA interface, which is a bidirectional hardware FIFO.
Does the kernel DMA subsystem support simultaneously linked DMA transfers?
In addition, the DMA hardware also supports scatter-gather (chaining), so
memory need not be physically continuous.
> > As you noted, the kernel cannot and must not allocate any kind of normal
> > memory for this device. Typical DMA addresses 0-0x200000 are mapped to
> > 0x1c000000-0x1c200000 and is memory managed exclusively by the IOP. What
> > would be a suitable mask for that?
>
> For the sake of accuracy, I guess maybe DMA_BIT_MASK(20) since that's what
> the OHCI's effective addressing capability is, even if it does happen to be
> to remote IOP RAM.
Isn't it 21 for 2 MiB? Hmm... I'm considering raising that to 8 MiB since
there are such devices too.
> Alternatively, there is perhaps some degree of argument
> for deliberately picking a nonzero but useless value like 1, although it
> looks like the MIPS allocator (at least the dma-default one) never actually
> checks whether the page it gets is within range of the device's coherent
> mask, which it probably should do.
Perhaps Maciej knows more about the details of the MIPS allocator?
Fredrik
next prev parent reply other threads:[~2018-07-06 20:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-03 13:08 [PATCH] dma-mapping: Relax warnings for per-device areas Robin Murphy
2018-07-03 13:08 ` Robin Murphy
[not found] ` <1f8262d206c6886072d04cc93454f6e3f812bd20.1530623284.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
2018-07-03 16:47 ` Fredrik Noring
2018-07-03 16:47 ` Fredrik Noring
2018-07-05 19:36 ` Christoph Hellwig
2018-07-05 19:36 ` Christoph Hellwig
[not found] ` <20180705193613.GA28905-jcswGhMUV9g@public.gmane.org>
2018-07-06 11:57 ` Robin Murphy
2018-07-06 11:57 ` Robin Murphy
[not found] ` <5811ebe5-b2bd-efc1-bf54-a8f05432c4f8-5wv7dgnIgG8@public.gmane.org>
2018-07-06 14:19 ` Fredrik Noring
2018-07-06 14:19 ` Fredrik Noring
[not found] ` <20180706141926.GA2313-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2018-07-06 16:46 ` Robin Murphy
2018-07-06 16:46 ` Robin Murphy
[not found] ` <bd63815c-260e-078f-4184-561c8e54e636-5wv7dgnIgG8@public.gmane.org>
2018-07-06 20:54 ` Fredrik Noring [this message]
2018-07-06 20:54 ` Fredrik Noring
2018-07-06 23:35 ` Aw: " "Jürgen Urban"
2018-07-06 23:35 ` "Jürgen Urban"
2018-07-07 6:32 ` Fredrik Noring
2018-07-07 6:32 ` Fredrik Noring
2018-07-08 20:47 ` Aw: " "Jürgen Urban"
2018-07-15 12:28 ` Fredrik Noring
2018-07-15 12:28 ` Fredrik Noring
2018-07-17 14:57 ` Christoph Hellwig
2018-07-17 16:33 ` Fredrik Noring
2018-07-18 21:55 ` Geoff Levand
2018-07-19 13:16 ` Christoph Hellwig
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=20180706205449.GB2313@localhost.localdomain \
--to=noring-zgyzp9v7ijcdnm+yrofe0a@public.gmane.org \
--cc=JuergenUrban-Mmb7MZpHnFY@public.gmane.org \
--cc=hch-jcswGhMUV9g@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=macro-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
/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.