* [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
* Re: [PATCH 13/15] ppc/pseries: iommu cleanup
From: Grant Likely @ 2010-09-15 18:34 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: devicetree-discuss, Milton Miller, Paul Mackerras,
Anton Blanchard, linuxppc-dev
In-Reply-To: <1284573958-8397-14-git-send-email-nacc@us.ibm.com>
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wro=
te:
> 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>
Also looks correct.
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
g.
> ---
> =A0arch/powerpc/platforms/pseries/iommu.c | =A0 =A09 ++-------
> =A01 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platfo=
rms/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 *tb=
l, long tcenum,
> =A0 =A0 =A0 =A0return ret;
> =A0}
>
> -static DEFINE_PER_CPU(u64 *, tce_page) =3D NULL;
> +static DEFINE_PER_CPU(u64 *, tce_page);
>
> =A0static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcen=
um,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 l=
ong npages, unsigned long uaddr,
> @@ -589,13 +589,8 @@ static struct notifier_block iommu_reconfig_nb =3D {
> =A0/* These are called very early. */
> =A0void iommu_init_early_pSeries(void)
> =A0{
> - =A0 =A0 =A0 if (of_chosen && of_get_property(of_chosen, "linux,iommu-of=
f", NULL)) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Direct I/O, IOMMU off */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppc_md.pci_dma_dev_setup =3D NULL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppc_md.pci_dma_bus_setup =3D NULL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 set_pci_dma_ops(&dma_direct_ops);
> + =A0 =A0 =A0 if (of_chosen && of_get_property(of_chosen, "linux,iommu-of=
f", NULL))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
> - =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0if (firmware_has_feature(FW_FEATURE_LPAR)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (firmware_has_feature(FW_FEATURE_MULTIT=
CE)) {
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 15/15] ppc/vio: ensure dma_coherent_mask is set
From: Grant Likely @ 2010-09-15 18:37 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Brian King, Paul Mackerras, linuxppc-dev, Milton Miller
In-Reply-To: <1284573958-8397-16-git-send-email-nacc@us.ibm.com>
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wro=
te:
> Without this change drivers, such as ibmvscsi, fail to load with the
> previous change.
Shouldn't this patch be ordered before the previous change then to
preserve bisectability?
Also, patch descriptions should be explicit about what the "previous
change" refers to. Once this is committed, git log may very well
insert other changes from other branches between this commit and
whatever "previous change" refers to.
g.
> ---
> =A0arch/powerpc/kernel/vio.c | =A0 =A03 +++
> =A01 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 dev=
ice_node *of_node)
> =A0 =A0 =A0 =A0viodev->dev.parent =3D &vio_bus_device.dev;
> =A0 =A0 =A0 =A0viodev->dev.bus =3D &vio_bus_type;
> =A0 =A0 =A0 =A0viodev->dev.release =3D vio_dev_release;
> + =A0 =A0 =A0 =A0/* needed to ensure proper operation of coherent allocat=
ions
> + =A0 =A0 =A0 =A0 * later, in case driver doesn't set it explicitly */
> + =A0 =A0 =A0 =A0dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64));
>
> =A0 =A0 =A0 =A0/* register with generic device framework */
> =A0 =A0 =A0 =A0if (device_register(&viodev->dev)) {
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Question on of_address_to_resource() with offset != 0
From: Grant Likely @ 2010-09-15 18:43 UTC (permalink / raw)
To: Stefan Roese; +Cc: devicetree-discuss, linuxppc-dev, Detlev Zundel
In-Reply-To: <201009151459.43087.sr@denx.de>
On Wed, Sep 15, 2010 at 02:59:42PM +0200, Stefan Roese wrote:
> 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.
:-)
g.
^ permalink raw reply
* Re: [PATCH 15/15] ppc/vio: ensure dma_coherent_mask is set
From: Nishanth Aravamudan @ 2010-09-15 18:44 UTC (permalink / raw)
To: Grant Likely; +Cc: Brian King, Paul Mackerras, linuxppc-dev, Milton Miller
In-Reply-To: <AANLkTi=K+KudbVAqZGA9fXXWq-vXirh9SuSTEHSh=kgC@mail.gmail.com>
On 15.09.2010 [12:37:58 -0600], Grant Likely wrote:
> On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> > Without this change drivers, such as ibmvscsi, fail to load with the
> > previous change.
>
> Shouldn't this patch be ordered before the previous change then to
> preserve bisectability?
You are probably right. I wasn't sure if I should fold it in or keep it
separate. I should have changed the order, though. Sorry about that!
> Also, patch descriptions should be explicit about what the "previous
> change" refers to. Once this is committed, git log may very well
> insert other changes from other branches between this commit and
> whatever "previous change" refers to.
Yep -- what's the best way to make the reference? By subject from the
patch? Obviously I don't have the SHA1 with which the commit will go
upstream.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 15/15] ppc/vio: ensure dma_coherent_mask is set
From: Grant Likely @ 2010-09-15 18:49 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Brian King, Paul Mackerras, linuxppc-dev, Milton Miller
In-Reply-To: <20100915184456.GC3683@us.ibm.com>
On Wed, Sep 15, 2010 at 11:44:56AM -0700, Nishanth Aravamudan wrote:
> On 15.09.2010 [12:37:58 -0600], Grant Likely wrote:
> > On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> > > Without this change drivers, such as ibmvscsi, fail to load with the
> > > previous change.
> >
> > Shouldn't this patch be ordered before the previous change then to
> > preserve bisectability?
>
> You are probably right. I wasn't sure if I should fold it in or keep it
> separate. I should have changed the order, though. Sorry about that!
It's such a small patch I would just fold it in.
>
> > Also, patch descriptions should be explicit about what the "previous
> > change" refers to. Once this is committed, git log may very well
> > insert other changes from other branches between this commit and
> > whatever "previous change" refers to.
>
> Yep -- what's the best way to make the reference? By subject from the
> patch? Obviously I don't have the SHA1 with which the commit will go
> upstream.
By name should be good. As long as a reader doesn't need background
information from your head to figure out why the change was made then
it should be okay.
g.
^ permalink raw reply
* RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
From: Bounine, Alexandre @ 2010-09-15 18:52 UTC (permalink / raw)
To: Anderson, Trevor, Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Thomas Moll
In-Reply-To: <1682399277683944B902B3657D2FCE216544F4A1F0@CAREXCLUSTER03.ATL.CW.LOCAL>
Anderson, Trevor <tanderson@curtisswright.com> wrote:
>=20
> Keep it in please. We lurkers in the embedded community do use the
per-port routing tables.
> One of the problems with SRIO switch tables is that access to routes
is not atomic; we can use
> restricted access to per-port routing tables to reduce the risk of
interference. And we still use
> the Global table during enumeration.
>=20
Will it help if I add sysfs attribute(s) to handle per-port routes?
^ permalink raw reply
* RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
From: Anderson, Trevor @ 2010-09-15 19:13 UTC (permalink / raw)
To: Bounine, Alexandre, Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Thomas Moll
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E5520130332B@CORPEXCH1.na.ads.idt.com>
> -----Original Message-----
> From: Bounine, Alexandre [mailto:Alexandre.Bounine@idt.com]
> Sent: Wednesday, September 15, 2010 11:53 AM
> To: Anderson, Trevor; 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
>
> Anderson, Trevor <tanderson@curtisswright.com> wrote:
> >
> > Keep it in please. We lurkers in the embedded community do use the
> per-port routing tables.
> > One of the problems with SRIO switch tables is that access to routes
> is not atomic; we can use
> > restricted access to per-port routing tables to reduce the risk of
> interference. And we still use
> > the Global table during enumeration.
> >
> Will it help if I add sysfs attribute(s) to handle per-port routes?
I don't think so - not from my perspective, at least. All of our routes
are programmed using the broadcast table; but we use the private tables
as a safer method of reading the routes that have been programmed, when we=
need to know that.
_______________________________________________________________________
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 v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Bounine, Alexandre @ 2010-09-15 19:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100914151219.5d92c6f9.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
=20
> What is the locking for rdev? In other patches I see pointer chases
> with no obvious locking against concurrent changes?
This rdev should be safe because it is intended for use only by
rio_switch
attached to the same rdev. Therefore rio_global_list_lock will work
here.
I will check for safe locking in all my patches - this set and earlier.
^ permalink raw reply
* [PATCH -v4] memblock: Fix section mismatch warnings
From: Yinghai Lu @ 2010-09-15 20:05 UTC (permalink / raw)
To: Ingo Molnar, Stephen Rothwell
Cc: Peter Zijlstra, linux-kernel, linux-next, H. Peter Anvin,
Thomas Gleixner, ppc-dev
In-Reply-To: <20100915092532.GH16593@elte.hu>
Stephen found bunch of section mismatch warnings with memblock new changes.
Use __init_memblock to replace __init in memblock.c and remove __init in memblock.h.
We should not use __init in header files.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Yinghai Lu <Yinghai@kernel.org>
---
include/linux/memblock.h | 24 ++++++++++++------------
mm/memblock.c | 14 +++++++-------
2 files changed, 19 insertions(+), 19 deletions(-)
Index: linux-2.6/mm/memblock.c
===================================================================
--- linux-2.6.orig/mm/memblock.c
+++ linux-2.6/mm/memblock.c
@@ -125,8 +125,8 @@ static phys_addr_t __init memblock_find_
return MEMBLOCK_ERROR;
}
-static phys_addr_t __init memblock_find_base(phys_addr_t size, phys_addr_t align,
- phys_addr_t start, phys_addr_t end)
+static phys_addr_t __init_memblock memblock_find_base(phys_addr_t size,
+ phys_addr_t align, phys_addr_t start, phys_addr_t end)
{
long i;
@@ -439,12 +439,12 @@ long __init_memblock memblock_remove(phy
return __memblock_remove(&memblock.memory, base, size);
}
-long __init memblock_free(phys_addr_t base, phys_addr_t size)
+long __init_memblock memblock_free(phys_addr_t base, phys_addr_t size)
{
return __memblock_remove(&memblock.reserved, base, size);
}
-long __init memblock_reserve(phys_addr_t base, phys_addr_t size)
+long __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
{
struct memblock_type *_rgn = &memblock.reserved;
@@ -671,12 +671,12 @@ int __init memblock_is_reserved(phys_add
return memblock_search(&memblock.reserved, addr) != -1;
}
-int memblock_is_memory(phys_addr_t addr)
+int __init_memblock memblock_is_memory(phys_addr_t addr)
{
return memblock_search(&memblock.memory, addr) != -1;
}
-int memblock_is_region_memory(phys_addr_t base, phys_addr_t size)
+int __init_memblock memblock_is_region_memory(phys_addr_t base, phys_addr_t size)
{
int idx = memblock_search(&memblock.reserved, base);
@@ -693,7 +693,7 @@ int __init_memblock memblock_is_region_r
}
-void __init memblock_set_current_limit(phys_addr_t limit)
+void __init_memblock memblock_set_current_limit(phys_addr_t limit)
{
memblock.current_limit = limit;
}
Index: linux-2.6/include/linux/memblock.h
===================================================================
--- linux-2.6.orig/include/linux/memblock.h
+++ linux-2.6/include/linux/memblock.h
@@ -51,39 +51,39 @@ u64 memblock_find_in_range(u64 start, u6
int memblock_free_reserved_regions(void);
int memblock_reserve_reserved_regions(void);
-extern void __init memblock_init(void);
-extern void __init memblock_analyze(void);
+extern void memblock_init(void);
+extern void memblock_analyze(void);
extern long memblock_add(phys_addr_t base, phys_addr_t size);
extern long memblock_remove(phys_addr_t base, phys_addr_t size);
-extern long __init memblock_free(phys_addr_t base, phys_addr_t size);
-extern long __init memblock_reserve(phys_addr_t base, phys_addr_t size);
+extern long memblock_free(phys_addr_t base, phys_addr_t size);
+extern long memblock_reserve(phys_addr_t base, phys_addr_t size);
/* The numa aware allocator is only available if
* CONFIG_ARCH_POPULATES_NODE_MAP is set
*/
-extern phys_addr_t __init memblock_alloc_nid(phys_addr_t size, phys_addr_t align,
+extern phys_addr_t memblock_alloc_nid(phys_addr_t size, phys_addr_t align,
int nid);
-extern phys_addr_t __init memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align,
+extern phys_addr_t memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align,
int nid);
-extern phys_addr_t __init memblock_alloc(phys_addr_t size, phys_addr_t align);
+extern phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align);
/* Flags for memblock_alloc_base() amd __memblock_alloc_base() */
#define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0)
#define MEMBLOCK_ALLOC_ACCESSIBLE 0
-extern phys_addr_t __init memblock_alloc_base(phys_addr_t size,
+extern phys_addr_t memblock_alloc_base(phys_addr_t size,
phys_addr_t align,
phys_addr_t max_addr);
-extern phys_addr_t __init __memblock_alloc_base(phys_addr_t size,
+extern phys_addr_t __memblock_alloc_base(phys_addr_t size,
phys_addr_t align,
phys_addr_t max_addr);
-extern phys_addr_t __init memblock_phys_mem_size(void);
+extern phys_addr_t memblock_phys_mem_size(void);
extern phys_addr_t memblock_end_of_DRAM(void);
-extern void __init memblock_enforce_memory_limit(phys_addr_t memory_limit);
+extern void memblock_enforce_memory_limit(phys_addr_t memory_limit);
extern int memblock_is_memory(phys_addr_t addr);
extern int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
-extern int __init memblock_is_reserved(phys_addr_t addr);
+extern int memblock_is_reserved(phys_addr_t addr);
extern int memblock_is_region_reserved(phys_addr_t base, phys_addr_t size);
extern void memblock_dump_all(void);
^ permalink raw reply
* [PATCH] powerpc/5121: pdm360ng: fix touch irq if 8xxx gpio driver is enabled
From: Anatolij Gustschin @ 2010-09-15 20:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin
Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
breaks touch screen support on this board since the GPIO
interrupt will be mapped to 8xxx GPIO irq host resulting in
a not requestable interrupt in the touch screen driver. Fix
it by mapping the touch interrupt on 8xxx GPIO irq host.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/platforms/512x/pdm360ng.c | 26 ++++++++++++++++++++++----
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c
index 0575e85..558eb9e 100644
--- a/arch/powerpc/platforms/512x/pdm360ng.c
+++ b/arch/powerpc/platforms/512x/pdm360ng.c
@@ -27,6 +27,7 @@
#include <linux/spi/ads7846.h>
#include <linux/spi/spi.h>
#include <linux/notifier.h>
+#include <asm/gpio.h>
static void *pdm360ng_gpio_base;
@@ -50,7 +51,7 @@ static struct ads7846_platform_data pdm360ng_ads7846_pdata = {
.irq_flags = IRQF_TRIGGER_LOW,
};
-static int __init pdm360ng_penirq_init(void)
+static int pdm360ng_penirq_init(void)
{
struct device_node *np;
@@ -73,6 +74,9 @@ static int __init pdm360ng_penirq_init(void)
return 0;
}
+#define GPIO_NR(x) (ARCH_NR_GPIOS - 32 + (x))
+#define PENDOWN_GPIO GPIO_NR(25)
+
static int pdm360ng_touchscreen_notifier_call(struct notifier_block *nb,
unsigned long event, void *__dev)
{
@@ -80,7 +84,24 @@ static int pdm360ng_touchscreen_notifier_call(struct notifier_block *nb,
if ((event == BUS_NOTIFY_ADD_DEVICE) &&
of_device_is_compatible(dev->of_node, "ti,ads7846")) {
+ struct spi_device *spi = to_spi_device(dev);
+ int gpio = PENDOWN_GPIO;
+
dev->platform_data = &pdm360ng_ads7846_pdata;
+ if (pdm360ng_penirq_init())
+ return NOTIFY_DONE;
+
+ if (gpio_request_one(gpio, GPIOF_IN, "ads7845_pen_down") < 0) {
+ pr_err("Failed to request GPIO %d for "
+ "ads7845 pen down IRQ\n", gpio);
+ return NOTIFY_DONE;
+ }
+ spi->irq = gpio_to_irq(gpio);
+ if (spi->irq < 0) {
+ pr_err("Can't map GPIO IRQ\n");
+ gpio_free(gpio);
+ return NOTIFY_DONE;
+ }
return NOTIFY_OK;
}
return NOTIFY_DONE;
@@ -92,9 +113,6 @@ static struct notifier_block pdm360ng_touchscreen_nb = {
static void __init pdm360ng_touchscreen_init(void)
{
- if (pdm360ng_penirq_init())
- return;
-
bus_register_notifier(&spi_bus_type, &pdm360ng_touchscreen_nb);
}
#else
--
1.7.0.4
^ permalink raw reply related
* Re: Generating elf kernel ?
From: tiejun.chen @ 2010-09-16 2:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <20100915114912.06bc7ed1@schlenkerla.am.freescale.net>
Scott Wood wrote:
> 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.
Maybe you misunderstand what I mean.
Although you can change entry point of vmlinux
1> can you load the Linux vmlinux directly to the physical address '0' on
current bootloader?
2> additionally you have to find a way to pass dtb to the native vmlinux.
I believe the hypervisor can boot vmlinux directly. But your so-called vmlinux
should be guest OS. And the hypervisor will handle/assit TLB exception for the
guest OS on MMU. Right? So you can use the hypervisor to load vmlinux to any
physical address as you expect. But the guest OS should not be same as the
native Linux.
>
> 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.
Sure.
>
>> 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.
Absolutely.
Tiejun
>
> -Scott
>
>
^ 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