All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.