* [PATCH] fixes probe issue and hangup in spi_mpc8xxx.c for data bigger than PAGE_SIZE
From: LEROY Christophe @ 2010-09-15 13:29 UTC (permalink / raw)
To: David Brownell, Grant Likely
Cc: spi-devel-general, LinuxPPC-dev, linux-kernel
This patch applies to 2.6.34.7. It also applies to 2.6.35.4 althought
part of it is already included in 2.6.35.4
It fixed a problem with spi_mpc8xxx.c when transmitting or receiving
data bigger than PAGE_SIZE when doing a read only or write only operation
It also fixed an issue with the init probe when fetching the information
on parameter RAM from the DTB.
Signed-off-by: christophe leroy <christophe.leroy@c-s.fr>
Index: trunk/drivers/spi/spi_mpc8xxx.c
===================================================================
--- trunk/drivers/spi/spi_mpc8xxx.c (révision 963)
+++ trunk/drivers/spi/spi_mpc8xxx.c (copie de travail)
@@ -393,11 +393,17 @@
xfer_ofs = mspi->xfer_in_progress->len - mspi->count;
- out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs);
+ if (mspi->rx_dma == mspi->dma_dummy_rx)
+ out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma);
+ else
+ out_be32(&rx_bd->cbd_bufaddr, mspi->rx_dma + xfer_ofs);
out_be16(&rx_bd->cbd_datlen, 0);
out_be16(&rx_bd->cbd_sc, BD_SC_EMPTY | BD_SC_INTRPT | BD_SC_WRAP);
- out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs);
+ if (mspi->tx_dma == mspi->dma_dummy_tx)
+ out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma);
+ else
+ out_be32(&tx_bd->cbd_bufaddr, mspi->tx_dma + xfer_ofs);
out_be16(&tx_bd->cbd_datlen, xfer_len);
out_be16(&tx_bd->cbd_sc, BD_SC_READY | BD_SC_INTRPT | BD_SC_WRAP |
BD_SC_LAST);
@@ -438,7 +444,7 @@
dev_err(dev, "unable to map tx dma\n");
return -ENOMEM;
}
- } else {
+ } else if (t->tx_buf) {
mspi->tx_dma = t->tx_dma;
}
@@ -449,7 +455,7 @@
dev_err(dev, "unable to map rx dma\n");
goto err_rx_dma;
}
- } else {
+ } else if (t->rx_buf) {
mspi->rx_dma = t->rx_dma;
}
@@ -822,7 +828,7 @@
if (!iprop || size != sizeof(*iprop) * 4)
return -ENOMEM;
- spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
+ spi_base_ofs = iprop[2];
if (IS_ERR_VALUE(spi_base_ofs))
return -ENOMEM;
@@ -844,7 +850,6 @@
return spi_base_ofs;
}
- cpm_muram_free(spi_base_ofs);
return pram_ofs;
}
^ permalink raw reply
* RE: [PATCH v2 06/10] RapidIO: Modify sysfs initialization for switches
From: Bounine, Alexandre @ 2010-09-15 13:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100914151026.4d9599b4.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
=20
> This is also a non-back compatible userspace-visible change?
This should be a safe change because endpoints do not have a routing
table.
RapidIO differentiates devices by using naming templates for switches
and endpoints (":s:" and ":e:") and this indicates which device features
are available to a userspace application. =20
^ permalink raw reply
* RE: [PATCH v2 01/10] RapidIO: Fix RapidIO sysfs hierarchy
From: Bounine, Alexandre @ 2010-09-15 14:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100914150429.6256b311.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
=20
> Non-backward compatible change? What is the risk of breaking existing
> setups with this change?
I think that risk is very low. Assuming that this change brings sysfs
entries
to their intended hierarchy, it has sense to do it now (at relatively
early stage).
^ permalink raw reply
* Re: Generating elf kernel ?
From: Guillaume Dargaud @ 2010-09-15 14:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4C90835E.4050803@windriver.com>
> Please use simpleImage.<your target dts name>.elf.
Great, that seems to be it...
Except that nothing happens when I jump to 0x40000, no message from the
kernel, nothing.
I'm a bit stumped here as my old kernel worked fine.
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH] fixes probe issue and hangup in spi_mpc8xxx.c for data bigger than PAGE_SIZE
From: Joakim Tjernlund @ 2010-09-15 15:08 UTC (permalink / raw)
To: LEROY Christophe
Cc: spi-devel-general, David Brownell, LinuxPPC-dev, linux-kernel
In-Reply-To: <4C90CA4D.2020902@c-s.fr>
>
> This patch applies to 2.6.34.7. It also applies to 2.6.35.4 althought
> part of it is already included in 2.6.35.4
> It fixed a problem with spi_mpc8xxx.c when transmitting or receiving
> data bigger than PAGE_SIZE when doing a read only or write only operation
> It also fixed an issue with the init probe when fetching the information
> on parameter RAM from the DTB.
I think you need to break this up into 3 patches. It can't go into Linus
tree as is and it can't go into stable before it is in Linus tree.
Jocke
^ permalink raw reply
* RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
From: Bounine, Alexandre @ 2010-09-15 15:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100914152049.8d42783f.akpm@linux-foundation.org>
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.). =20
> 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=20
may be configured by usermode apps. This capability may be implemented=20
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).
^ permalink raw reply
* 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
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