search for: config_ppc

...atever transport we chose to use (though capability > exchange sounds like a reasonable one) whether the "server" > implementation is bypassing IOMMUs or not instead on relying on client > side heuristics. > > IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what > is essentially an attribute of the server-side, ie, whether is bypasses > the iommu for the PCI bus it resides on. > I believe all the arguments about whether this should be a bus property > or whether the x86 case can be worked around via ACPI tables etc... are > all moot....

...atever transport we chose to use (though capability > exchange sounds like a reasonable one) whether the "server" > implementation is bypassing IOMMUs or not instead on relying on client > side heuristics. > > IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what > is essentially an attribute of the server-side, ie, whether is bypasses > the iommu for the PCI bus it resides on. > I believe all the arguments about whether this should be a bus property > or whether the x86 case can be worked around via ACPI tables etc... are > all moot....

...non-PPC systems, virtio_pci should use the DMA API. This fixes > virtio_pci on Xen. On PPC, using the DMA API would break things, so > we need to preserve the old behavior. > > The big comment in this patch explains the considerations in more > detail. I still disagree with using CONFIG_PPC as a trigger here. Fundamentally, the qemu implementation today bypasses IOMMUs on all platforms as far as I can tell. If that changes, we'll have a backward compatibility problem. The virtio device should advertise whether it's using that bypass mode of operation and virtio_pci should r...

...non-PPC systems, virtio_pci should use the DMA API. This fixes > virtio_pci on Xen. On PPC, using the DMA API would break things, so > we need to preserve the old behavior. > > The big comment in this patch explains the considerations in more > detail. I still disagree with using CONFIG_PPC as a trigger here. Fundamentally, the qemu implementation today bypasses IOMMUs on all platforms as far as I can tell. If that changes, we'll have a backward compatibility problem. The virtio device should advertise whether it's using that bypass mode of operation and virtio_pci should r...

On Sep 19, 2014 2:33 PM, "Benjamin Herrenschmidt" <benh at kernel.crashing.org> wrote: > > On Wed, 2014-09-17 at 09:07 -0700, Andy Lutomirski wrote: > > It shouldn't. That being said, at some point this problem will need > > solving on PPC, and this patch doesn't help much, other than adding > > the virtio_ring piece. > > > > I'd

On Sep 19, 2014 2:33 PM, "Benjamin Herrenschmidt" <benh at kernel.crashing.org> wrote: > > On Wed, 2014-09-17 at 09:07 -0700, Andy Lutomirski wrote: > > It shouldn't. That being said, at some point this problem will need > > solving on PPC, and this patch doesn't help much, other than adding > > the virtio_ring piece. > > > > I'd

...use the DMA API. This fixes > > virtio_pci on Xen. On PPC, using the DMA API would break things, so > > we need to preserve the old behavior. > > > > The big comment in this patch explains the considerations in more > > detail. > > I still disagree with using CONFIG_PPC as a trigger here. > > Fundamentally, the qemu implementation today bypasses IOMMUs on all > platforms as far as I can tell. > > If that changes, we'll have a backward compatibility problem. > > The virtio device should advertise whether it's using that bypass > m...

...ability > >> exchange sounds like a reasonable one) whether the "server" > >> implementation is bypassing IOMMUs or not instead on relying on client > >> side heuristics. > >> > >> IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what > >> is essentially an attribute of the server-side, ie, whether is bypasses > >> the iommu for the PCI bus it resides on. > > > >> I believe all the arguments about whether this should be a bus property > >> or whether the x86 case can be worked arou...

...ability > >> exchange sounds like a reasonable one) whether the "server" > >> implementation is bypassing IOMMUs or not instead on relying on client > >> side heuristics. > >> > >> IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what > >> is essentially an attribute of the server-side, ie, whether is bypasses > >> the iommu for the PCI bus it resides on. > > > >> I believe all the arguments about whether this should be a bus property > >> or whether the x86 case can be worked arou...

...es >> > virtio_pci on Xen. On PPC, using the DMA API would break things, so >> > we need to preserve the old behavior. >> > >> > The big comment in this patch explains the considerations in more >> > detail. >> >> I still disagree with using CONFIG_PPC as a trigger here. >> >> Fundamentally, the qemu implementation today bypasses IOMMUs on all >> platforms as far as I can tell. >> >> If that changes, we'll have a backward compatibility problem. >> >> The virtio device should advertise whether it's...

...es >> > virtio_pci on Xen. On PPC, using the DMA API would break things, so >> > we need to preserve the old behavior. >> > >> > The big comment in this patch explains the considerations in more >> > detail. >> >> I still disagree with using CONFIG_PPC as a trigger here. >> >> Fundamentally, the qemu implementation today bypasses IOMMUs on all >> platforms as far as I can tell. >> >> If that changes, we'll have a backward compatibility problem. >> >> The virtio device should advertise whether it's...

...ably emulated and ignores the IOMMU. Unfortunately, we > + * can't tell whether we're talking to an emulated device or to > + * a physical device that really lives behind the IOMMU. That > + * means that we're stuck with ignoring the DMA API. > + */ > + > +#ifdef CONFIG_PPC > + return false; > +#else > + /* > + * Minor optimization: if the platform promises to have physical > + * PCI DMA, we turn off DMA mapping in virtio_ring. If the > + * platform's DMA API implementation is well optimized, this > + * should have almost no effect, but w...

...ably emulated and ignores the IOMMU. Unfortunately, we > + * can't tell whether we're talking to an emulated device or to > + * a physical device that really lives behind the IOMMU. That > + * means that we're stuck with ignoring the DMA API. > + */ > + > +#ifdef CONFIG_PPC > + return false; > +#else > + /* > + * Minor optimization: if the platform promises to have physical > + * PCI DMA, we turn off DMA mapping in virtio_ring. If the > + * platform's DMA API implementation is well optimized, this > + * should have almost no effect, but w...

..., 1 deletion(-) diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c index 81a8faedbba6..991d9dc82749 100644 --- a/drivers/media/platform/fsl-viu.c +++ b/drivers/media/platform/fsl-viu.c @@ -34,7 +34,7 @@ /* Allow building this driver with COMPILE_TEST */ #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) -#define in_be32(a) ioread32be((void __iomem *)a) +#define in_be32(a) ioread32be((const void __iomem *)a) #endif #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ -- 2.17.1

..., 1 deletion(-) diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c index 81a8faedbba6..991d9dc82749 100644 --- a/drivers/media/platform/fsl-viu.c +++ b/drivers/media/platform/fsl-viu.c @@ -34,7 +34,7 @@ /* Allow building this driver with COMPILE_TEST */ #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) -#define in_be32(a) ioread32be((void __iomem *)a) +#define in_be32(a) ioread32be((const void __iomem *)a) #endif #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ -- 2.17.1

...o device to expose via whatever transport we chose to use (though capability exchange sounds like a reasonable one) whether the "server" implementation is bypassing IOMMUs or not instead on relying on client side heuristics. IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what is essentially an attribute of the server-side, ie, whether is bypasses the iommu for the PCI bus it resides on. I believe all the arguments about whether this should be a bus property or whether the x86 case can be worked around via ACPI tables etc... are all moot. Today, qemu implementatio...

...chose to use (though capability >> exchange sounds like a reasonable one) whether the "server" >> implementation is bypassing IOMMUs or not instead on relying on client >> side heuristics. >> >> IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what >> is essentially an attribute of the server-side, ie, whether is bypasses >> the iommu for the PCI bus it resides on. > >> I believe all the arguments about whether this should be a bus property >> or whether the x86 case can be worked around via ACPI tables etc......

...chose to use (though capability >> exchange sounds like a reasonable one) whether the "server" >> implementation is bypassing IOMMUs or not instead on relying on client >> side heuristics. >> >> IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what >> is essentially an attribute of the server-side, ie, whether is bypasses >> the iommu for the PCI bus it resides on. > >> I believe all the arguments about whether this should be a bus property >> or whether the x86 case can be worked around via ACPI tables etc......

...;> exchange sounds like a reasonable one) whether the "server" >> >> implementation is bypassing IOMMUs or not instead on relying on client >> >> side heuristics. >> >> >> >> IE. Basically, we are trying to "guess" with an ifdef CONFIG_PPC, what >> >> is essentially an attribute of the server-side, ie, whether is bypasses >> >> the iommu for the PCI bus it resides on. >> > >> >> I believe all the arguments about whether this should be a bus property >> >> or whether the x86 cas...

...tio_pci on Xen. On PPC, using the DMA API would break things, so >>>> we need to preserve the old behavior. >>>> >>>> The big comment in this patch explains the considerations in more >>>> detail. >>> >>> I still disagree with using CONFIG_PPC as a trigger here. >>> >>> Fundamentally, the qemu implementation today bypasses IOMMUs on all >>> platforms as far as I can tell. >>> >>> If that changes, we'll have a backward compatibility problem. >>> >>> The virtio device shoul...