linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* DMA Remapping and Marvell 88SE9172, 88SE9128 SATA controllers
@ 2012-08-27 16:05 Andrew Cooks
       [not found] ` <CAJtEV7aGSvRvyevveysWkDn18Oz3n3qF6EpPtgvwC4dsJU41HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cooks @ 2012-08-27 16:05 UTC (permalink / raw)
  To: linux-acpi-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
  Cc: jgarzik-e+AXbWqSrlAAvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
	pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w

There's a problem relating to DMA Remapping which affects systems with
Marvell SATA controllers. It was first reported on 2012-01-28 on
bugzilla.kernel.org[1] and is best described by Don Dutile: "...the
lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as
the source of any of its DMA packets, the IOMMU will fault on it,
since 0b:00.1 didn't request DMA mappings (0b:00.0 did)."[2]

Is this kind of problem caused by a missing/incorrect entry in an ACPI
table? Is it feasible to introduce a fake device for the missing
function using a pci quirk?

Thanks,

ac.

1. https://bugzilla.kernel.org/show_bug.cgi?id=42679
2. https://lists.linux-foundation.org/pipermail/iommu/2012-January/003552.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: DMA Remapping and Marvell 88SE9172, 88SE9128 SATA controllers
       [not found] ` <CAJtEV7aGSvRvyevveysWkDn18Oz3n3qF6EpPtgvwC4dsJU41HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-09-10 14:25   ` Alex Williamson
  0 siblings, 0 replies; 2+ messages in thread
From: Alex Williamson @ 2012-09-10 14:25 UTC (permalink / raw)
  To: Andrew Cooks
  Cc: pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	jgarzik-e+AXbWqSrlAAvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ

On Tue, 2012-08-28 at 00:05 +0800, Andrew Cooks wrote:
> There's a problem relating to DMA Remapping which affects systems with
> Marvell SATA controllers. It was first reported on 2012-01-28 on
> bugzilla.kernel.org[1] and is best described by Don Dutile: "...the
> lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
> so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as
> the source of any of its DMA packets, the IOMMU will fault on it,
> since 0b:00.1 didn't request DMA mappings (0b:00.0 did)."[2]
> 
> Is this kind of problem caused by a missing/incorrect entry in an ACPI
> table? Is it feasible to introduce a fake device for the missing
> function using a pci quirk?

We've added pci_get_dma_source() to help with such devices, but it's
only used by the IOMMU grouping code and requires a struct pci_dev for
the actual DMA source.  I think for this device we're going to need to
run a quirk when we scan it that creates a fake device, add it to
pci_get_dma_source(), then make use of it in the dma mapping path.  I
think the only other alternative would be to disable hardware IOMMUs
when this device is found in the system.  Thanks,

Alex

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-09-10 14:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-27 16:05 DMA Remapping and Marvell 88SE9172, 88SE9128 SATA controllers Andrew Cooks
     [not found] ` <CAJtEV7aGSvRvyevveysWkDn18Oz3n3qF6EpPtgvwC4dsJU41HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-10 14:25   ` Alex Williamson

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).