* Re: Generating elf kernel ?
From: tiejun.chen @ 2010-09-15 8:27 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201009151007.50706.dargaud@lpsc.in2p3.fr>
Guillaume Dargaud wrote:
>>> How do I generate an elf file ?
>> vmlinux?
>
> Thanks.
>
> The entry point address has change and I can't upload it:
> New (bad) one:
> $ readelf -h vmlinux
> ...
> Entry point address: 0xc0000000
>
> Old (good) one:
> $ readelf -h zImage.elf
> ...
> Entry point address: 0x400000
>
> How can I change the entry point address ?
It's impossible to boot PPC vmlinux format directly if you only change the
original entry point address, 0xc0000000.
For kernel the following is as default:
v:0xc0000000 --> p:0x0
Please use simpleImage.<your target dts name>.elf.
Cheers
Tiejun
^ permalink raw reply
* Re: linux-next: build warnings after merge of the final tree (tip treee related)
From: Ingo Molnar @ 2010-09-15 9:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, ppc-dev, linux-kernel, linux-next, H. Peter Anvin,
Thomas Gleixner, Yinghai Lu
In-Reply-To: <20100915150047.42551e34.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Yinghai,
>
> On Tue, 14 Sep 2010 16:00:06 -0700 Yinghai Lu <yinghai@kernel.org> wrote:
> >
> > Also, we may need to remove all extern and __init and __initdata etc in .h files.
> >
> > please check
> >
> > [PATCH -v3] memblock: Fix section mismatch warning
> >
> > Use __init_memblock to replace __init, and remove __init in memblock.h
> >
> > -v2: more with memblock_is_meory()
> > -v3: remove __init for function declaring in memblock.h. Pointed out by Stephen.
> >
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Signed-off-by: Yinghai Lu <Yinghai@kernel.org>
>
> This version fixes all the warnings for me. So if you put the "extern"s
> back, you can add:
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Yinghai, mind posting the final version of the patch as a standalone
posting, with a proper changelog, and with the extern issue fixed as
well, plus all Reported-by and Tested-by tags added?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 0/7] BKL mass-conversion to mutex
From: Stephen Rothwell @ 2010-09-15 9:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Corey Minyard, Jens Axboe, David Woodhouse, linux-scsi,
Takashi Iwai, linux-kernel, linuxppc-dev, James E.J. Bottomley,
linux-mtd, Ingo Molnar, Linus Torvalds, openipmi-developer
In-Reply-To: <1284494022-7346-1-git-send-email-arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
Hi Arnd,
On Tue, 14 Sep 2010 21:53:35 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> Stephen, please add
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git trivial
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The 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:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 00/15] change default_llseek action
From: Stephen Rothwell @ 2010-09-15 9:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: 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: 1751 bytes --]
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. As
you may know, this is not a judgment of your code. The 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:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Question on of_address_to_resource() with offset != 0
From: Stefan Roese @ 2010-09-15 12:59 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev, Detlev Zundel
In-Reply-To: <201009141629.06825.stefan.roese@gmail.com>
On Tuesday 14 September 2010 16:29:06 Stefan Roese wrote:
> I'm stumbling upon a problem noticed on the Ebony (440GP) eval board.
> Here the first chip-select is connected to 512KiB of SRAM and 512KiB
> NOR flash.
"Brown paper bag" time for me. Problem was located in U-Boot. Sorry for the
noise.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [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
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