* Re: [PATCH 00/15] change default_llseek action
From: Valdis.Kletnieks @ 2010-09-15 15:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Samuel Ortiz, David Airlie, netdev,
linux-wireless, linux-kernel, dri-devel, Christoph Hellwig,
linuxppc-dev, Tony Lindgren, Julia Lawall, Jeremy Kerr,
linux-fsdevel, linux-omap, Linus Torvalds, Al Viro
In-Reply-To: <1284495763-7506-1-git-send-email-arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
> This changes *all* instances of struct file_operations in
> the kernel to have a .llseek operation and then changes
> the default to no_llseek, which returns -ESPIPE, which
> is what we had decided some time ago in a discussion
> with Christoph Hellwig.
I don't suppose there's any clean way to throw a build error or a
printk_on_once() or something if we encounter an unconverted 'struct
file_operations', is there? I have this creeping fear that this patch will go
upstream during the merge window - as will 12 new staging/ drivers from authors
who didn't get the memo yet.
Other than the "missed converting a new usage" issue, it looks OK to me.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* DSP in MPC8xx
From: LEROY Christophe @ 2010-09-15 16:02 UTC (permalink / raw)
To: LinuxPPC-dev
Hi,
I accordance with document MPC8xxRMAD the CPM of MPC8xx includes some
DSP functions.
However, it is not real clear if some additional microcode is needed or
not to operate it.
Does anyone know any implementation of that DSP functionality with Linux ?
Regards
C. Leroy
^ permalink raw reply
* Re: [PATCH 00/15] change default_llseek action
From: Luis R. Rodriguez @ 2010-09-15 16:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Samuel Ortiz, Arnd Bergmann, David Airlie, netdev, linux-wireless,
linux-kernel, dri-devel, Christoph Hellwig, linuxppc-dev,
Tony Lindgren, Julia Lawall, Al Viro, linux-fsdevel, linux-omap,
Linus Torvalds, Jeremy Kerr
In-Reply-To: <20100915193926.ae2fe838.sfr@canb.auug.org.au>
On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Arnd,
>
> On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> Stephen, please add
>> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek
>
> Added from today.
>
> Thanks for adding your subsystem tree as a participant of linux-next. =C2=
=A0As
> you may know, this is not a judgment of your code. =C2=A0The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window.
>
> You will need to ensure that the patches/commits in your tree/series have
> been:
> =C2=A0 =C2=A0 * submitted under GPL v2 (or later) and include the Contrib=
utor's
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Signed-off-by,
I should note this should say the code should be GPL-compatible, it
doesn't need to be GPLv2 (or later). Furthermore the contributors of
the subsystem respect the individual licenses of the files through the
Developers Certificate of Origin, which tells the developers what the
meaning of Signed-off-by means.
Luis
^ permalink raw reply
* Re: [PATCH 00/15] change default_llseek action
From: Arnd Bergmann @ 2010-09-15 16:37 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Stephen Rothwell, Samuel Ortiz, David Airlie, netdev,
linux-wireless, linux-kernel, dri-devel, Christoph Hellwig,
linuxppc-dev, Tony Lindgren, Julia Lawall, Jeremy Kerr,
linux-fsdevel, linux-omap, Linus Torvalds, Al Viro
In-Reply-To: <9828.1284565136@localhost>
On Wednesday 15 September 2010, Valdis.Kletnieks@vt.edu wrote:
> Show Details
> On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
>
> > This changes all instances of struct file_operations in
> > the kernel to have a .llseek operation and then changes
> > the default to no_llseek, which returns -ESPIPE, which
> > is what we had decided some time ago in a discussion
> > with Christoph Hellwig.
>
> I don't suppose there's any clean way to throw a build error or a
> printk_on_once() or something if we encounter an unconverted 'struct
> file_operations', is there? I have this creeping fear that this patch will go
> upstream during the merge window - as will 12 new staging/ drivers from authors
> who didn't get the memo yet.
>
> Other than the "missed converting a new usage" issue, it looks OK to me.
One advantage of the scripted approach is that I can run the script
repeatedly, and send a patch after -rc1 fixing up all the new file
operations.
Moreover, any new drivers are by definition not regressions and staging
drivers are expected to have issues. IIRC the most common llseek operation
is 'noop_llseek', which usually means it should have been 'no_llseek' to
start with, but since this has been in a released kernel, some random
user application might expect a seek on that file to succeed without
error.
Arnd
^ permalink raw reply
* Re: Generating elf kernel ?
From: Scott Wood @ 2010-09-15 16:49 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <4C90835E.4050803@windriver.com>
On Wed, 15 Sep 2010 16:27:10 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:
> It's impossible to boot PPC vmlinux format directly if you only change the
> original entry point address, 0xc0000000.
Why? That's pretty much what the bootwrapper does. Our hypervisor has
directly booted vmlinux this way.
Note that in recent kernels physaddr is even set to zero, allowing the
ELF loader to just use that instead of magically knowing the kernel
wants to go at address zero.
> For kernel the following is as default:
> v:0xc0000000 --> p:0x0
That mapping is set up by code at the entry point of vmlinux, not by
the bootwrapper.
-Scott
^ permalink raw reply
* [PATCH 11/15] ppc/cell: beat dma ops cleanup
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: cbe-oss-dev, Arnd Bergmann, Milton Miller, Paul Mackerras,
linuxppc-dev, David S. Miller
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
direct_dma_ops is the default pci dma ops.
No need to call a function to get the pci dma ops, we know they are the
dma_direct_ops.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/cell/beat_iommu.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/beat_iommu.c b/arch/powerpc/platforms/cell/beat_iommu.c
index beec405..3ce6855 100644
--- a/arch/powerpc/platforms/cell/beat_iommu.c
+++ b/arch/powerpc/platforms/cell/beat_iommu.c
@@ -76,7 +76,7 @@ static void __init celleb_init_direct_mapping(void)
static void celleb_dma_dev_setup(struct device *dev)
{
- dev->archdata.dma_ops = get_pci_dma_ops();
+ set_dma_ops(dev, &dma_direct_ops);
set_dma_offset(dev, celleb_dma_direct_offset);
}
@@ -106,7 +106,6 @@ static struct notifier_block celleb_of_bus_notifier = {
static int __init celleb_init_iommu(void)
{
celleb_init_direct_mapping();
- set_pci_dma_ops(&dma_direct_ops);
ppc_md.pci_dma_dev_setup = celleb_pci_dma_dev_setup;
bus_register_notifier(&platform_bus_type, &celleb_of_bus_notifier);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 13/15] ppc/pseries: iommu cleanup
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: devicetree-discuss, Milton Miller, Paul Mackerras,
Anton Blanchard, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
No need to initialize per-cpu pointer to NULL, it is the default.
Direct dma ops and no setup are the defaults, no need to set for
iommu-off.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pseries/iommu.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index a77bcae..9184db3 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -140,7 +140,7 @@ static int tce_build_pSeriesLP(struct iommu_table *tbl, long tcenum,
return ret;
}
-static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
+static DEFINE_PER_CPU(u64 *, tce_page);
static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
long npages, unsigned long uaddr,
@@ -589,13 +589,8 @@ static struct notifier_block iommu_reconfig_nb = {
/* These are called very early. */
void iommu_init_early_pSeries(void)
{
- if (of_chosen && of_get_property(of_chosen, "linux,iommu-off", NULL)) {
- /* Direct I/O, IOMMU off */
- ppc_md.pci_dma_dev_setup = NULL;
- ppc_md.pci_dma_bus_setup = NULL;
- set_pci_dma_ops(&dma_direct_ops);
+ if (of_chosen && of_get_property(of_chosen, "linux,iommu-off", NULL))
return;
- }
if (firmware_has_feature(FW_FEATURE_LPAR)) {
if (firmware_has_feature(FW_FEATURE_MULTITCE)) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 02/15] ppc64: fix dma_iommu_dma_supported compare
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
The table offset is in entries, each of which imply a dma address of
an IOMMU page.
Also, we should check the device can reach the whole IOMMU table.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/kernel/dma-iommu.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 37771a5..6e54a0f 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -74,16 +74,17 @@ static int dma_iommu_dma_supported(struct device *dev, u64 mask)
{
struct iommu_table *tbl = get_iommu_table_base(dev);
- if (!tbl || tbl->it_offset > mask) {
- printk(KERN_INFO
- "Warning: IOMMU offset too big for device mask\n");
- if (tbl)
- printk(KERN_INFO
- "mask: 0x%08llx, table offset: 0x%08lx\n",
- mask, tbl->it_offset);
- else
- printk(KERN_INFO "mask: 0x%08llx, table unavailable\n",
- mask);
+ if (!tbl) {
+ dev_info(dev, "Warning: IOMMU dma not supported: mask 0x%08llx"
+ ", table unavailable\n", mask);
+ return 0;
+ }
+
+ if ((tbl->it_offset + tbl->it_size) > (mask >> IOMMU_PAGE_SHIFT)) {
+ dev_info(dev, "Warning: IOMMU window too big for device mask\n");
+ dev_info(dev, "mask: 0x%08llx, table end: 0x%08lx\n",
+ mask, (tbl->it_offset + tbl->it_size) <<
+ IOMMU_PAGE_SHIFT);
return 0;
} else
return 1;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 04/15] vio: put device on device_register failure
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc; +Cc: Milton Miller, Paul Mackerras, Brian King, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
The kernel doc for device_register (and device_initialize) very clearly
state to call put_device not kfree after calling, even on error.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/kernel/vio.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index fa3469d..72db4b0 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1254,8 +1254,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
if (device_register(&viodev->dev)) {
printk(KERN_ERR "%s: failed to register device %s\n",
__func__, dev_name(&viodev->dev));
- /* XXX free TCE table */
- kfree(viodev);
+ put_device(&viodev->dev);
return NULL;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 07/15] ppc: pci-common cleanup
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: Dominik Brodowski, Milton Miller, Paul Mackerras, Jesse Barnes,
linuxppc-dev, Bjorn Helgaas
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
Use set_dma_ops and remove unused oddly-named temp pointer sd.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/kernel/pci-common.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 9021c4a..10a44e6 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1090,8 +1090,6 @@ void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
bus->number, bus->self ? pci_name(bus->self) : "PHB");
list_for_each_entry(dev, &bus->devices, bus_list) {
- struct dev_archdata *sd = &dev->dev.archdata;
-
/* Cardbus can call us to add new devices to a bus, so ignore
* those who are already fully discovered
*/
@@ -1107,7 +1105,7 @@ void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
/* Hook up default DMA ops */
- sd->dma_ops = pci_dma_ops;
+ set_dma_ops(&dev->dev, pci_dma_ops);
set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
/* Additional platform DMA/iommu setup */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 12/15] ppc/dart: iommu table cleanup
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: Jiri Kosina, Milton Miller, André Goddard Rosa,
Paul Mackerras, H. Peter Anvin, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
No need to set the device tree device_node pci node iommu pointer, its
only used for dlpar remove.
direct_dma_ops are the default, no need to restore them or dma bus ops
if we haven't set them in the error paths.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/sysdev/dart_iommu.c | 18 +-----------------
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 559db2b..64fe9c7 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -302,17 +302,10 @@ static void pci_dma_dev_setup_dart(struct pci_dev *dev)
static void pci_dma_bus_setup_dart(struct pci_bus *bus)
{
- struct device_node *dn;
-
if (!iommu_table_dart_inited) {
iommu_table_dart_inited = 1;
iommu_table_dart_setup();
}
-
- dn = pci_bus_to_OF_node(bus);
-
- if (dn)
- PCI_DN(dn)->iommu_table = &iommu_table_dart;
}
void __init iommu_init_early_dart(void)
@@ -324,7 +317,7 @@ void __init iommu_init_early_dart(void)
if (dn == NULL) {
dn = of_find_compatible_node(NULL, "dart", "u4-dart");
if (dn == NULL)
- goto bail;
+ return; /* use default direct_dma_ops */
dart_is_u4 = 1;
}
@@ -340,16 +333,7 @@ void __init iommu_init_early_dart(void)
/* Setup pci_dma ops */
set_pci_dma_ops(&dma_iommu_ops);
- return;
}
-
- bail:
- /* If init failed, use direct iommu and null setup functions */
- ppc_md.pci_dma_dev_setup = NULL;
- ppc_md.pci_dma_bus_setup = NULL;
-
- /* Setup pci_dma ops */
- set_pci_dma_ops(&dma_direct_ops);
}
#ifdef CONFIG_PM
--
1.7.0.4
^ permalink raw reply related
* [PATCH 05/15] viobus: free TCE table on device release
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc; +Cc: Milton Miller, Paul Mackerras, Brian King, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
Release the TCE table as the XXX suggests, except on FW_FEATURE_ISERIES,
where the tables are allocated globally and reused.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/kernel/vio.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 72db4b0..d692989 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1184,7 +1184,12 @@ EXPORT_SYMBOL(vio_unregister_driver);
/* vio_dev refcount hit 0 */
static void __devinit vio_dev_release(struct device *dev)
{
- /* XXX should free TCE table */
+ struct iommu_table *tbl = get_iommu_table_base(dev);
+
+ /* iSeries uses a common table for all vio devices */
+ if (!firmware_has_feature(FW_FEATURE_ISERIES) && tbl)
+ iommu_free_table(tbl, dev->of_node ?
+ dev->of_node->full_name : dev_name(dev));
of_node_put(dev->of_node);
kfree(to_vio_dev(dev));
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 09/15] ppc/vio: use dma ops helpers
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc; +Cc: Milton Miller, Paul Mackerras, Brian King, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
Use the set_dma_ops helper. Instead of modifying vio_dma_mapping_ops,
just create a trivial wrapper for dma_supported.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/kernel/vio.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index d692989..3c3083f 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -602,6 +602,11 @@ static void vio_dma_iommu_unmap_sg(struct device *dev,
vio_cmo_dealloc(viodev, alloc_size);
}
+static int vio_dma_iommu_dma_supported(struct device *dev, u64 mask)
+{
+ return dma_iommu_ops.dma_supported(dev, mask);
+}
+
struct dma_map_ops vio_dma_mapping_ops = {
.alloc_coherent = vio_dma_iommu_alloc_coherent,
.free_coherent = vio_dma_iommu_free_coherent,
@@ -609,6 +614,7 @@ struct dma_map_ops vio_dma_mapping_ops = {
.unmap_sg = vio_dma_iommu_unmap_sg,
.map_page = vio_dma_iommu_map_page,
.unmap_page = vio_dma_iommu_unmap_page,
+ .dma_supported = vio_dma_iommu_dma_supported,
};
@@ -860,8 +866,7 @@ static void vio_cmo_bus_remove(struct vio_dev *viodev)
static void vio_cmo_set_dma_ops(struct vio_dev *viodev)
{
- vio_dma_mapping_ops.dma_supported = dma_iommu_ops.dma_supported;
- viodev->dev.archdata.dma_ops = &vio_dma_mapping_ops;
+ set_dma_ops(&viodev->dev, &vio_dma_mapping_ops);
}
/**
@@ -1246,7 +1251,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
if (firmware_has_feature(FW_FEATURE_CMO))
vio_cmo_set_dma_ops(viodev);
else
- viodev->dev.archdata.dma_ops = &dma_iommu_ops;
+ set_dma_ops(&viodev->dev, &dma_iommu_ops);
set_iommu_table_base(&viodev->dev, vio_build_iommu_table(viodev));
set_dev_node(&viodev->dev, of_node_to_nid(of_node));
--
1.7.0.4
^ permalink raw reply related
* [PATCH 03/15] ppc64 iommu: fix check for direct DMA support
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: Milton Miller, FUJITA Tomonori, Paul Mackerras, H. Peter Anvin,
Andrew Morton, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
The current check is wrong because it does not take the DMA offset intot
account, and in the case of a driver which doesn't actually support
64bits would falsely report that device as working.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/kernel/dma.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 84d6367..494ab12 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -89,7 +89,7 @@ static int dma_direct_dma_supported(struct device *dev, u64 mask)
/* Could be improved so platforms can set the limit in case
* they have limited DMA windows
*/
- return mask >= (memblock_end_of_DRAM() - 1);
+ return mask >= get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
#else
return 1;
#endif
--
1.7.0.4
^ permalink raw reply related
* [PATCH 10/15] ppc/pasemi: clean up pasemi iommu table initializations
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: linuxppc-dev, Milton Miller, Paul Mackerras, Olof Johansson,
Yinghai Lu
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
No need for empty helpers with iommu off, the ppc_md hooks are optional.
The direct_dma_ops are the default pci_dma_ops, so no need to set in the
them iommu off case.
No need to set the device tree device_node pci node iommu pointer, its
only used for dlpar remove.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pasemi/iommu.c | 19 +------------------
1 files changed, 1 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index 1f9fb2c..14943ef 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -156,20 +156,12 @@ static void iommu_table_iobmap_setup(void)
static void pci_dma_bus_setup_pasemi(struct pci_bus *bus)
{
- struct device_node *dn;
-
pr_debug("pci_dma_bus_setup, bus %p, bus->self %p\n", bus, bus->self);
if (!iommu_table_iobmap_inited) {
iommu_table_iobmap_inited = 1;
iommu_table_iobmap_setup();
}
-
- dn = pci_bus_to_OF_node(bus);
-
- if (dn)
- PCI_DN(dn)->iommu_table = &iommu_table_iobmap;
-
}
@@ -192,9 +184,6 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
set_iommu_table_base(&dev->dev, &iommu_table_iobmap);
}
-static void pci_dma_bus_setup_null(struct pci_bus *b) { }
-static void pci_dma_dev_setup_null(struct pci_dev *d) { }
-
int __init iob_init(struct device_node *dn)
{
unsigned long tmp;
@@ -251,14 +240,8 @@ void __init iommu_init_early_pasemi(void)
iommu_off = of_chosen &&
of_get_property(of_chosen, "linux,iommu-off", NULL);
#endif
- if (iommu_off) {
- /* Direct I/O, IOMMU off */
- ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_null;
- ppc_md.pci_dma_bus_setup = pci_dma_bus_setup_null;
- set_pci_dma_ops(&dma_direct_ops);
-
+ if (iommu_off)
return;
- }
iob_init(NULL);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 06/15] pseries/dlpar: use kmemdup
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc
Cc: Gautham R Shenoy, Milton Miller, Julia Lawall, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
While looking at some code paths I came across this code that zeros
memory then copies over the entire length.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index 72d8054..6004c81 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -55,13 +55,12 @@ static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)
prop->length = ccwa->prop_length;
value = (char *)ccwa + ccwa->prop_offset;
- prop->value = kzalloc(prop->length, GFP_KERNEL);
+ prop->value = kmemdup(value, prop->length, GFP_KERNEL);
if (!prop->value) {
dlpar_free_cc_property(prop);
return NULL;
}
- memcpy(prop->value, value, prop->length);
return prop;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 14/15] ppc64 iommu: use coherent_dma_mask for alloc_coherent
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
The IOMMU code has been passing the dma-mask instead of the
coherent_dma_mask to the iommu allocator. Coherent allocations should
be made using the coherent_dma_mask.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
We currently don't check the mask other than to warn when its being set,
so I don't think this is stable material.
---
arch/powerpc/kernel/dma-iommu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 6e54a0f..e755415 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -19,7 +19,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
- dma_handle, device_to_mask(dev), flag,
+ dma_handle, dev->coherent_dma_mask, flag,
dev_to_node(dev));
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 15/15] ppc/vio: ensure dma_coherent_mask is set
From: Nishanth Aravamudan @ 2010-09-15 18:05 UTC (permalink / raw)
To: nacc; +Cc: Milton Miller, Paul Mackerras, Brian King, linuxppc-dev
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
Without this change drivers, such as ibmvscsi, fail to load with the
previous change.
---
arch/powerpc/kernel/vio.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 3c3083f..e8d73de 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1259,6 +1259,9 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
viodev->dev.parent = &vio_bus_device.dev;
viodev->dev.bus = &vio_bus_type;
viodev->dev.release = vio_dev_release;
+ /* needed to ensure proper operation of coherent allocations
+ * later, in case driver doesn't set it explicitly */
+ dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64));
/* register with generic device framework */
if (device_register(&viodev->dev)) {
--
1.7.0.4
^ permalink raw reply related
* [nacc@us.ibm.com: [PATCH 00/15] ppc iommu cleanups]
From: Nishanth Aravamudan @ 2010-09-15 18:13 UTC (permalink / raw)
To: linuxppc-dev
Clearly need to work on my git-send-mail usage! Apologies...
----- Forwarded message from Nishanth Aravamudan <nacc@us.ibm.com> -----
Date: Wed, 15 Sep 2010 11:05:43 -0700
From: Nishanth Aravamudan <nacc@us.ibm.com>
To: nacc@us.ibm.com
Subject: [PATCH 00/15] ppc iommu cleanups
While working on some upcoming IOMMU-related changes, we found the
following cleanups throughout the ppc code.
Nishanth Aravamudan (15):
ppc: fix return type of BUID_{HI,LO} macros
ppc64: fix dma_iommu_dma_supported compare
ppc64 iommu: fix check for direct DMA support
vio: put device on device_register failure
viobus: free TCE table on device release
pseries/dlpar: use kmemdup
ppc: pci-common cleanup
microblaze: pci-common cleanup
ppc/vio: use dma ops helpers
ppc/pasemi: clean up pasemi iommu table initializations
ppc/cell: beat dma ops cleanup
ppc/dart: iommu table cleanup
ppc/pseries: iommu cleanup
ppc64 iommu: use coherent_dma_mask for alloc_coherent
ppc/vio: ensure dma_coherent_mask is set
arch/microblaze/pci/pci-common.c | 6 ++----
arch/powerpc/include/asm/ppc-pci.h | 4 ++--
arch/powerpc/kernel/dma-iommu.c | 23 ++++++++++++-----------
arch/powerpc/kernel/dma.c | 2 +-
arch/powerpc/kernel/pci-common.c | 4 +---
arch/powerpc/kernel/vio.c | 24 ++++++++++++++++++------
arch/powerpc/platforms/cell/beat_iommu.c | 3 +--
arch/powerpc/platforms/pasemi/iommu.c | 19 +------------------
arch/powerpc/platforms/pseries/dlpar.c | 3 +--
arch/powerpc/platforms/pseries/iommu.c | 9 ++-------
arch/powerpc/sysdev/dart_iommu.c | 18 +-----------------
11 files changed, 42 insertions(+), 73 deletions(-)
---
I used git-send-email for this series, and noticed that
get_maintainer.pl will always pull in LKML to the Cc because of the
following in MAINTAINERS:
THE REST
M: Linus Torvalds <torvalds@linux-foundation.org>
L: linux-kernel@vger.kernel.org
Q: http://patchwork.kernel.org/project/LKML/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
S: Buried alive in reporters
F: *
F: */
Is there any way to exclude that in the script that anyone knows of? Or
am I mis-using the script (as the --cc-cmd option to git-send-email).
Thanks,
Nish
----- End forwarded message -----
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 01/15] ppc: fix return type of BUID_{HI,LO} macros
From: Nishanth Aravamudan @ 2010-09-15 18:13 UTC (permalink / raw)
To: nacc
Cc: Milton Miller, Paul Mackerras, Linas Vepstas, linuxppc-dev,
Breno Leitao
In-Reply-To: <1284573958-8397-1-git-send-email-nacc@us.ibm.com>
BUID_HI and BUID_LO are used to pass data to call_rtas, which expects
ints or u32s. But the macro doesn't cast the return, so the result is
still u64. Use the upper_32_bits and lower_32_bits macros that have been
added to kernel.h.
Found by getting printf format errors trying to debug print the args, no
actual code change for 64 bit kernels where the macros are actually
used.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/include/asm/ppc-pci.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 42fdff0..43268f1 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -28,8 +28,8 @@ extern void find_and_init_phbs(void);
extern struct pci_dev *isa_bridge_pcidev; /* may be NULL if no ISA bus */
/** Bus Unit ID macros; get low and hi 32-bits of the 64-bit BUID */
-#define BUID_HI(buid) ((buid) >> 32)
-#define BUID_LO(buid) ((buid) & 0xffffffff)
+#define BUID_HI(buid) upper_32_bits(buid)
+#define BUID_LO(buid) lower_32_bits(buid)
/* PCI device_node operations */
struct device_node;
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
From: Anderson, Trevor @ 2010-09-15 18:27 UTC (permalink / raw)
To: Bounine, Alexandre, Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Thomas Moll
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E5520130321F@CORPEXCH1.na.ads.idt.com>
Keep it in please. We lurkers in the embedded community do use the per-por=
t routing tables.
One of the problems with SRIO switch tables is that access to routes is no=
t atomic; we can use
restricted access to per-port routing tables to reduce the risk of interfe=
rence. And we still use
the Global table during enumeration.
> -----Original Message-----
> From: linuxppc-dev-bounces+tanderson=3Dcurtisswright.com@lists.ozlabs.or=
g [mailto:linuxppc-dev-
> bounces+tanderson=3Dcurtisswright.com@lists.ozlabs.org] On Behalf Of Bou=
nine, Alexandre
> Sent: Wednesday, September 15, 2010 8:31 AM
> To: Andrew Morton
> Cc: linux-kernel@vger.kernel.org; Thomas Moll; linuxppc-dev@lists.ozlabs=
.org
> Subject: RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 swit=
ches
>
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > The handling of `table' is strange. One would expect the caller of
> > this function to provide the correct table index, and for the caller
> to
> > increment that index at an appropriate time.
>
> Handling of the 'table' parameter is hardware-dependent.
> RIO switches (at least all that I know) have a per-port routing tables
> (RT)
> which can be configured independently. The 'table' parameter is expected=
> to match
> to the port number (or broadcast if GLOBAL).
> The route set/get routines in this file use the standard route setting
> registers
> defined by RapidIO spec, but switches have internal mapping into an
> individual
> port RT or broadcast capability into all port RTs.
> Unfortunately, this HW design uses index 0 as a broadcast option that
> offsets
> per-port RT numbering by +1 (port 0 =3D=3D table index 1, etc.).
>
> > So I take a look around but cannot find any means by which
> > ->add_entry() is called with anything other than RIO_GLOBAL_TABLE.
> > Maybe I missed something. Is this all dead code?
>
> The current RIO enumeration uses only the global routing table concept.
> In the past, I had a temptation to remove the 'table' parameter and make=
> RT settings simpler. But now I see scenarios when per-port routing
> tables
> may be configured by usermode apps. This capability may be implemented
> through sysfs attributes (probably I have to add them to make standard).=
> Example: system that uses dual-port endpoints which can be enumerated by=
> the host through one RIO port (management) and have individual routes
> configured for the second port (data path).
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended=
solely for the use of the individual or entity to whom they are addressed=
. If you have reason to believe that you have received this e-mail in erro=
r, please notify the sender and destroy this email and any attached files.=
Please note that any views or opinions presented in this e-mail are solel=
y those of the author and do not necessarily represent those of the Curtis=
s-Wright Corporation or any of its subsidiaries. Documents attached heret=
o may contain technology subject to government export regulations. Recipie=
nt is solely responsible for ensuring that any re-export, transfer or disc=
losure of this information is in accordance with applicable government exp=
ort regulations. The recipient should check this e-mail and any attachmen=
ts for the presence of viruses. Curtiss-Wright Corporation and its subsidi=
aries accept no liability for any damage caused by any virus transmitted b=
y this e-mail.
^ permalink raw reply
* Re: [PATCH 10/15] ppc/pasemi: clean up pasemi iommu table initializations
From: Olof Johansson @ 2010-09-15 18:29 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: linuxppc-dev, Milton Miller, Paul Mackerras, Yinghai Lu
In-Reply-To: <1284573958-8397-11-git-send-email-nacc@us.ibm.com>
On Wed, Sep 15, 2010 at 11:05:53AM -0700, Nishanth Aravamudan wrote:
> No need for empty helpers with iommu off, the ppc_md hooks are optional.
Not any more, they used to be needed. :-)
> The direct_dma_ops are the default pci_dma_ops, so no need to set in the
> them iommu off case.
>
> No need to set the device tree device_node pci node iommu pointer, its
> only used for dlpar remove.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* Re: [PATCH 04/15] vio: put device on device_register failure
From: Grant Likely @ 2010-09-15 18:29 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Brian King, Paul Mackerras, linuxppc-dev, Milton Miller
In-Reply-To: <1284573958-8397-5-git-send-email-nacc@us.ibm.com>
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wro=
te:
> The kernel doc for device_register (and device_initialize) very clearly
> state to call put_device not kfree after calling, even on error.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0arch/powerpc/kernel/vio.c | =A0 =A03 +--
> =A01 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index fa3469d..72db4b0 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1254,8 +1254,7 @@ struct vio_dev *vio_register_device_node(struct dev=
ice_node *of_node)
> =A0 =A0 =A0 =A0if (device_register(&viodev->dev)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_ERR "%s: failed to register de=
vice %s\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__func__, =
dev_name(&viodev->dev));
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* XXX free TCE table */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 kfree(viodev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 put_device(&viodev->dev);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL;
> =A0 =A0 =A0 =A0}
>
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 07/15] ppc: pci-common cleanup
From: Grant Likely @ 2010-09-15 18:30 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Dominik Brodowski, Milton Miller, Paul Mackerras, Jesse Barnes,
linuxppc-dev, Bjorn Helgaas
In-Reply-To: <1284573958-8397-8-git-send-email-nacc@us.ibm.com>
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wro=
te:
> Use set_dma_ops and remove unused oddly-named temp pointer sd.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0arch/powerpc/kernel/pci-common.c | =A0 =A04 +---
> =A01 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-c=
ommon.c
> index 9021c4a..10a44e6 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1090,8 +1090,6 @@ void __devinit pcibios_setup_bus_devices(struct pci=
_bus *bus)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bus->number, bus->self ? pci_name(bus->se=
lf) : "PHB");
>
> =A0 =A0 =A0 =A0list_for_each_entry(dev, &bus->devices, bus_list) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct dev_archdata *sd =3D &dev->dev.archd=
ata;
> -
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Cardbus can call us to add new devices =
to a bus, so ignore
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * those who are already fully discovered
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> @@ -1107,7 +1105,7 @@ void __devinit pcibios_setup_bus_devices(struct pci=
_bus *bus)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set_dev_node(&dev->dev, pcibus_to_node(dev=
->bus));
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Hook up default DMA ops */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 sd->dma_ops =3D pci_dma_ops;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 set_dma_ops(&dev->dev, pci_dma_ops);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set_dma_offset(&dev->dev, PCI_DRAM_OFFSET)=
;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Additional platform DMA/iommu setup */
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 09/15] ppc/vio: use dma ops helpers
From: Grant Likely @ 2010-09-15 18:33 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Brian King, Paul Mackerras, linuxppc-dev, Milton Miller
In-Reply-To: <1284573958-8397-10-git-send-email-nacc@us.ibm.com>
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wro=
te:
> Use the set_dma_ops helper. Instead of modifying vio_dma_mapping_ops,
> just create a trivial wrapper for dma_supported.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Looks right to me.
> ---
> =A0arch/powerpc/kernel/vio.c | =A0 11 ++++++++---
> =A01 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index d692989..3c3083f 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -602,6 +602,11 @@ static void vio_dma_iommu_unmap_sg(struct device *de=
v,
> =A0 =A0 =A0 =A0vio_cmo_dealloc(viodev, alloc_size);
> =A0}
>
> +static int vio_dma_iommu_dma_supported(struct device *dev, u64 mask)
> +{
> + =A0 =A0 =A0 =A0return dma_iommu_ops.dma_supported(dev, mask);
> +}
> +
> =A0struct dma_map_ops vio_dma_mapping_ops =3D {
> =A0 =A0 =A0 =A0.alloc_coherent =3D vio_dma_iommu_alloc_coherent,
> =A0 =A0 =A0 =A0.free_coherent =A0=3D vio_dma_iommu_free_coherent,
> @@ -609,6 +614,7 @@ struct dma_map_ops vio_dma_mapping_ops =3D {
> =A0 =A0 =A0 =A0.unmap_sg =A0 =A0 =A0 =3D vio_dma_iommu_unmap_sg,
> =A0 =A0 =A0 =A0.map_page =A0 =A0 =A0 =3D vio_dma_iommu_map_page,
> =A0 =A0 =A0 =A0.unmap_page =A0 =A0 =3D vio_dma_iommu_unmap_page,
> + =A0 =A0 =A0 .dma_supported =A0=3D vio_dma_iommu_dma_supported,
>
> =A0};
>
> @@ -860,8 +866,7 @@ static void vio_cmo_bus_remove(struct vio_dev *viodev=
)
>
> =A0static void vio_cmo_set_dma_ops(struct vio_dev *viodev)
> =A0{
> - =A0 =A0 =A0 vio_dma_mapping_ops.dma_supported =3D dma_iommu_ops.dma_sup=
ported;
> - =A0 =A0 =A0 viodev->dev.archdata.dma_ops =3D &vio_dma_mapping_ops;
> + =A0 =A0 =A0 set_dma_ops(&viodev->dev, &vio_dma_mapping_ops);
> =A0}
>
> =A0/**
> @@ -1246,7 +1251,7 @@ struct vio_dev *vio_register_device_node(struct dev=
ice_node *of_node)
> =A0 =A0 =A0 =A0if (firmware_has_feature(FW_FEATURE_CMO))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vio_cmo_set_dma_ops(viodev);
> =A0 =A0 =A0 =A0else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 viodev->dev.archdata.dma_ops =3D &dma_iommu=
_ops;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 set_dma_ops(&viodev->dev, &dma_iommu_ops);
> =A0 =A0 =A0 =A0set_iommu_table_base(&viodev->dev, vio_build_iommu_table(v=
iodev));
> =A0 =A0 =A0 =A0set_dev_node(&viodev->dev, of_node_to_nid(of_node));
>
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox