* Re: Raising list size limit
From: Olof Johansson @ 2007-12-18 16:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <2420E261-C9AB-49B8-8F99-C24C7A865044@kernel.crashing.org>
On Tue, Dec 18, 2007 at 09:54:15AM -0600, Kumar Gala wrote:
>
> On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote:
>
> > On Tue, 18 Dec 2007 14:36:27 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi,
> >>
> >> I am considering raising the limit on the size of postings to
> >> 400k. Does
> >> anyone have a real problem with this? Limiting message size was
> >> done to
> >> limit the damage of larges spams (and we don;t get very many of
> >> those on
> >> the list) and to ease the pain for people downloading emails over a
> >> slow
> >> (like dialup) link (and are there many of those left?).
> >
> > Fine by me!
>
> Do you really have patches that are 400k?
I'm guessing stuff such as "dtc merge" could reach those sizes?
Since it's somewhat common to cross-post patches (especially some of the
@de.ibm.com guys seem to post to 2-5 lists at a time), having a limit
higher than other lists could mean we see the same (large) patches several
times in case they bounce from other lists and get reposted. But it should
be a small fraction of the traffic no matter what.
-Olof
^ permalink raw reply
* Re: [PATCH v2 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Scott Wood @ 2007-12-18 16:09 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071218004329.GB9489@localhost.localdomain>
David Gibson wrote:
> On Mon, Dec 17, 2007 at 09:15:17AM -0600, Scott Wood wrote:
>> Enh. That can get icky as well, and the bootwrapper isn't necessarily
>> even used for u-boot, and I'd rather not require it be used just for this.
>
> So make the template in the u-boot form, and poke it as necessary from
> the redboot wrapper.
I'd rather not, given that I have limited access to a board with redboot
to test on, and that it's just a cosmetic change. Separate device trees
are fine for now, and hopefully will motivate work on dtc templates.
-Scott
^ permalink raw reply
* Re: [PATCH 03/10] powerpc: Add kexec support for PPC_85xx platforms
From: Dale Farnsworth @ 2007-12-18 16:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1197699385.6696.43.camel@pasglop>
On Sat, Dec 15, 2007 at 05:16:25PM +1100, Benjamin Herrenschmidt wrote:
> > index 8b642ab..db0e749 100644
> > --- a/arch/powerpc/kernel/misc_32.S
> > +++ b/arch/powerpc/kernel/misc_32.S
> > @@ -816,6 +816,75 @@ relocate_new_kernel:
> > /* r4 = reboot_code_buffer */
> > /* r5 = start_address */
> >
> > +#ifdef CONFIG_E500
> > + /*
> > + * Since we can't turn off the MMU, we must create an identity
> > + * map for kernel low memory. We start by invalidating the
> > + * TLB entries we don't need.
> > + *
> > + * First, invalidate the TLB0 entries
> > + */
> > + li r6, 0x04
> > + tlbivax 0, r6
> > +#ifdef CONFIG_SMP
> > + tlbsync
> > +#endif
> > + msync
> > +
>
> This is really E500 specific or should it be CONFIG_FSL_BOOKE ?
>
> Ben.
I agree that CONFIG_FSL_BOOKE is more appropriate. I'll reflect that
in the next respin.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH v2 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-18 16:15 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071218005348.GC9489@localhost.localdomain>
David Gibson wrote:
> I mean, obviously the MDIO bus is accessed via some of the
> board-control registers. What I'm questioning is whether it makes
> sense to have a distinct node to represent the mdio bus, or whether
> the phys should just hang straight of the bcsr node.
Ah, I see. I think it does make sense, because it's a bus; if there
were another bus-like thing on the bcsr, there'd be conflicts over what
the children mean.
>>>> + soc@f0000000 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + device_type = "soc";
>>> Ditch the device_type.
>> No, it's used by the bootwrapper. I'll get rid of it if you want to
>> write a find_node_by_compatible() function. :-)
>
> Well, now that libfdt is merged, there is one :-p.
OK, it just needs exporting via ops. I'll put it on my to-do list, but
I don't think it should hold up board support patches.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Scott Wood @ 2007-12-18 16:16 UTC (permalink / raw)
To: Scott Wood, Anton Vorontsov, Kumar Gala, Stephen Rothwell,
linuxppc-dev, Kim Phillips
In-Reply-To: <20071218035108.GA10212@localhost.localdomain>
David Gibson wrote:
> In this case the driver and binding have been developed together and
> for the time being it does require PHY nodes, obviously. I'm saying
> that maybe that requirement ought to be changed.
I don't see why.
> Well, phandle is only used to find the phy node itself, so it doesn't
> count. The only piece of information there is the reg - the PHY id.
> Following a phandle to another node is a fairly complex way of finding
> a single integer.
>
> Eh, I guess it's ok, but just directly giving the PHY id or a probe
> mask in the MAC node would also be fine (we do this for 4xx EMAC).
It's not just a simple integer -- it also tells you which mdio bus it's on.
-Scott
^ permalink raw reply
* Re: [PATCH 07/10] powerpc: Implement kmap_atomic_pfn on powerpc
From: Dale Farnsworth @ 2007-12-18 16:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1197699461.6696.45.camel@pasglop>
On Sat, Dec 15, 2007 at 05:17:41PM +1100, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-11-22 at 08:46 -0700, Dale Farnsworth wrote:
> > This is needed for the ppc32 /dev/oldmem driver of crash dump.
>
> Kumar's working (well, last I heard he was) on a fixmap mechanism
> so we can do that sort of thing without CONFIG_HIGHMEM, you may
> want to sync with him here, that would allow to shrink the crash
> kernel by not having highmem selected.
>
> Cheers,
> Ben.
Kumar, are you close to posting something that would make the
patch below unnecessary (or change it significantly)? If so,
I'll hold off.
-Dale
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > ---
> > include/asm-powerpc/highmem.h | 18 ++++++++++++++++++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
> > index f7b21ee..88d9e05 100644
> > --- a/include/asm-powerpc/highmem.h
> > +++ b/include/asm-powerpc/highmem.h
> > @@ -117,6 +117,24 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type type)
> > pagefault_enable();
> > }
> >
> > +/* This is the same as kmap_atomic() but can map memory that doesn't
> > + * have a struct page associated with it.
> > + */
> > +static inline void *kmap_atomic_pfn(unsigned long pfn, enum km_type type)
> > +{
> > + unsigned int idx;
> > + unsigned long vaddr;
> > +
> > + pagefault_disable();
> > +
> > + idx = type + KM_TYPE_NR * smp_processor_id();
> > + vaddr = KMAP_FIX_BEGIN + idx * PAGE_SIZE;
> > + set_pte_at(&init_mm, vaddr, kmap_pte+idx, pfn_pte(pfn, kmap_prot));
> > + flush_tlb_page(NULL, vaddr);
> > +
> > + return (void*) vaddr;
> > +}
> > +
> > static inline struct page *kmap_atomic_to_page(void *ptr)
> > {
> > unsigned long idx, vaddr = (unsigned long) ptr;
^ permalink raw reply
* Re: USB configuration
From: Scott Wood @ 2007-12-18 16:19 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <14389002.post@talk.nabble.com>
Misbah khan wrote:
> hi ...
>
> The montavista version we are using is " 2.6.10_mvl401-8272ads "
>
> Montavista people says that they are supporting USB host interface ....
If MV claims that they support the MPC82xx USB host controller, then you
should be talking to MV... it's not supported in the mainline kernel.
-Scott
^ permalink raw reply
* Re: Raising list size limit
From: Josh Boyer @ 2007-12-18 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <2420E261-C9AB-49B8-8F99-C24C7A865044@kernel.crashing.org>
On Tue, 18 Dec 2007 09:54:15 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote:
>
> > On Tue, 18 Dec 2007 14:36:27 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Hi,
> >>
> >> I am considering raising the limit on the size of postings to
> >> 400k. Does
> >> anyone have a real problem with this? Limiting message size was
> >> done to
> >> limit the damage of larges spams (and we don;t get very many of
> >> those on
> >> the list) and to ease the pain for people downloading emails over a
> >> slow
> >> (like dialup) link (and are there many of those left?).
> >
> > Fine by me!
>
> Do you really have patches that are 400k?
Nope. But I don't really care if I get them.
josh
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Dale Farnsworth @ 2007-12-18 16:38 UTC (permalink / raw)
To: Dale Farnsworth, Linuxppc-dev
In-Reply-To: <20071216064056.GH21311@localhost.localdomain>
On Sun, Dec 16, 2007 at 05:40:56PM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 02:18:16PM -0700, Dale Farnsworth wrote:
> > David Gibson wrote:
> > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > > > Device tree source file for the Emerson Katana Qp board
> >
> > [snip]
> >
> > > > + mv64x60@f8100000 { /* Marvell Discovery */
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + model = "mv64460"; /* Default */
> > > > + compatible = "marvell,mv64x60";
> >
> > [snip]
> >
> > > > + mdio {
> > >
> > > There must be some way of actuall accessing the mdio bus, so this node
> > > ought to have a 'reg' property and unit address.
> >
> > There is no way for the cpu to directly access the mdio bus. The
> > mdio bus is internally accessed by the ethernet MAC. That being the
> > case, maybe it makes more sense to move the mdio node inside of the
> > multiethernet node, as follows, but I don't see how we can give it
> > a reg property or a unit address.
>
> Ah, I see. If the mdio interface isn't distinct from the other
> pieces, then it probably shouldn't get a device node at all. Having
> an explicit mdio bus with the phys hanging off it is convenient for
> hardware which actually works that way, but it doesn't have to be done
> like that.
>
> Of course, then the question is where to hang the phy nodes, which
> look like they have information you need. Since you already have a
> local addressing scheme for the MACs under the multiethernet, what
> probably makes sense would be to hang the phys directly under the
> multiethernet, using an encoding scheme for the reg properties so that
> the MACs and PHYs aren't confused (say, MACs are 0x0, 0x1, 0x2, PHYs
> are 0x80000000, 0x80000001, 0x80000002).
Ugh. They really are two separate address spaces. One is an
intra-register index, and the other really is an mdio address,
even though it's only indirectly addressable. Combining them would
obfuscate. I'm proceding with an mdio node under the multiethernet
node as I posted below. Let me know if you feel strongly that that
should be changed.
> Incidentally, although I suggested it, I'm not all that fond of the
> "multiethernet" name, it was just the first thing that occurred to me.
I'm not fond of it either. Sometimes, naming is hard. :)
I'll see if we can come up with something better.
Thanks,
-Dale
> >
> > multiethernet@2000 {
> > reg = <0x2000 0x2000>;
> > ethernet@0 {
> > device_type = "network";
> > compatible = "marvell,mv64360-eth";
> > reg = <0>;
> > interrupts = <32>;
> > interrupt-parent = <&PIC>;
> > phy = <&PHY0>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > };
> > ethernet@1 {
> > device_type = "network";
> > compatible = "marvell,mv64360-eth";
> > reg = <1>;
> > interrupts = <33>;
> > interrupt-parent = <&PIC>;
> > phy = <&PHY1>;
> > local-mac-address = [ 00 00 00 00 00 00 ];
> > };
> > mdio {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > device_type = "mdio";
> > compatible = "marvell,mv64360-mdio";
> > PHY0: ethernet-phy@1 {
> > device_type = "ethernet-phy";
> > compatible = "broadcom,bcm5421";
> > interrupts = <76>; /* GPP 12 */
> > interrupt-parent = <&PIC>;
> > reg = <1>;
> > };
> > PHY1: ethernet-phy@3 {
> > device_type = "ethernet-phy";
> > compatible = "broadcom,bcm5421";
> > interrupts = <76>; /* GPP 12 */
> > interrupt-parent = <&PIC>;
> > reg = <3>;
> > };
> > };
> > };
^ permalink raw reply
* Re: [PATCH 07/10] powerpc: Implement kmap_atomic_pfn on powerpc
From: Kumar Gala @ 2007-12-18 16:42 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071218162032.GB28931@xyzzy.farnsworth.org>
On Dec 18, 2007, at 10:20 AM, Dale Farnsworth wrote:
> On Sat, Dec 15, 2007 at 05:17:41PM +1100, Benjamin Herrenschmidt
> wrote:
>>
>> On Thu, 2007-11-22 at 08:46 -0700, Dale Farnsworth wrote:
>>> This is needed for the ppc32 /dev/oldmem driver of crash dump.
>>
>> Kumar's working (well, last I heard he was) on a fixmap mechanism
>> so we can do that sort of thing without CONFIG_HIGHMEM, you may
>> want to sync with him here, that would allow to shrink the crash
>> kernel by not having highmem selected.
>>
>> Cheers,
>> Ben.
>
> Kumar, are you close to posting something that would make the
> patch below unnecessary (or change it significantly)? If so,
> I'll hold off.
My plan is to get the fixmap stuff posted this week.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-18 16:51 UTC (permalink / raw)
To: Scott Wood; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <4767F271.4090703@freescale.com>
On Tue, Dec 18, 2007 at 10:16:49AM -0600, Scott Wood wrote:
> David Gibson wrote:
> >In this case the driver and binding have been developed together and
> >for the time being it does require PHY nodes, obviously. I'm saying
> >that maybe that requirement ought to be changed.
>
> I don't see why.
>
> >Well, phandle is only used to find the phy node itself, so it doesn't
> >count. The only piece of information there is the reg - the PHY id.
> >Following a phandle to another node is a fairly complex way of finding
> >a single integer.
> >
> >Eh, I guess it's ok, but just directly giving the PHY id or a probe
> >mask in the MAC node would also be fine (we do this for 4xx EMAC).
>
> It's not just a simple integer -- it also tells you which mdio bus it's on.
Exactly. And at least one board (MPC8568E-MDS) using this feature:
UECs are using PHYs placed on the TSEC's MDIO bus. This is hardware
configurable, and could be contrariwise: TSECs can use PHYs that
are under control of UEC MDIO bus controller.
That's why we're naming PHYs as bus:phyid.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [POWERPC 12/18] cell: export force_sig_info()
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20071218174852.112644000@arndb.de>
Export force_sig_info to allow signals to be sent from a modular spufs.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_base.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
@@ -47,6 +47,13 @@ struct cbe_spu_info cbe_spu_info[MAX_NUM
EXPORT_SYMBOL_GPL(cbe_spu_info);
/*
+ * The spufs fault-handling code needs to call force_sig_info to raise signals
+ * on DMA errors. Export it here to avoid general kernel-wide access to this
+ * function
+ */
+EXPORT_SYMBOL_GPL(force_sig_info);
+
+/*
* Protects cbe_spu_info and spu->number.
*/
static DEFINE_SPINLOCK(spu_lock);
--
^ permalink raw reply
* [POWERPC 13/18] cell: safer of_has_vicinity routine
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: Jeremy Kerr, linuxppc-dev, Arnd Bergmann, Andre Detsch
In-Reply-To: <20071218174852.112644000@arndb.de>
This patch changes the way we check for the existence of
vicinity property in spe device nodes.
The new implementation does not depend on having an initialized
cbe_spu_info[0].spus, and checks for presence of vicinity in all
nodes, not only in the first one.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_manage.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_manage.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_manage.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_manage.c
@@ -422,10 +422,15 @@ static void init_affinity_qs20_harcoded(
static int of_has_vicinity(void)
{
- struct spu* spu;
+ struct device_node *dn;
- spu = list_first_entry(&cbe_spu_info[0].spus, struct spu, cbe_list);
- return of_find_property(spu_devnode(spu), "vicinity", NULL) != NULL;
+ for_each_node_by_type(dn, "spe") {
+ if (of_find_property(dn, "vicinity", NULL)) {
+ of_node_put(dn);
+ return 1;
+ }
+ }
+ return 0;
}
static struct spu *devnode_spu(int cbe, struct device_node *dn)
--
^ permalink raw reply
* [POWERPC 14/18] cell: handle kernel SLB setup in spu_base.c
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20071218174852.112644000@arndb.de>
Currently, the SPU context switch code (spufs/switch.c) sets up the
SPU's SLBs directly, which requires some low-level mm stuff.
This change moves the kernel SLB setup to spu_base.c, by exposing
a function spu_setup_kernel_slbs() to do this setup. This allows us
to remove the low-level mm code from switch.c, making it possible
to later move switch.c to the spufs module.
Also, add a struct spu_slb for the cases where we need to deal with
SLB entries.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_base.c | 49 ++++++++++++++++++++++++++++
arch/powerpc/platforms/cell/spufs/switch.c | 33 +------------------
include/asm-powerpc/spu.h | 4 ++
3 files changed, 54 insertions(+), 32 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
@@ -34,6 +34,7 @@
#include <linux/linux_logo.h>
#include <asm/spu.h>
#include <asm/spu_priv1.h>
+#include <asm/spu_csa.h>
#include <asm/xmon.h>
#include <asm/prom.h>
@@ -73,6 +74,10 @@ static LIST_HEAD(spu_full_list);
static DEFINE_SPINLOCK(spu_full_list_lock);
static DEFINE_MUTEX(spu_full_list_mutex);
+struct spu_slb {
+ u64 esid, vsid;
+};
+
void spu_invalidate_slbs(struct spu *spu)
{
struct spu_priv2 __iomem *priv2 = spu->priv2;
@@ -150,6 +155,18 @@ static void spu_restart_dma(struct spu *
out_be64(&priv2->mfc_control_RW, MFC_CNTL_RESTART_DMA_COMMAND);
}
+static inline void spu_load_slb(struct spu *spu, int slbe, struct spu_slb *slb)
+{
+ struct spu_priv2 __iomem *priv2 = spu->priv2;
+
+ pr_debug("%s: adding SLB[%d] 0x%016lx 0x%016lx\n",
+ __func__, slbe, slb->vsid, slb->esid);
+
+ out_be64(&priv2->slb_index_W, slbe);
+ out_be64(&priv2->slb_vsid_RW, slb->vsid);
+ out_be64(&priv2->slb_esid_RW, slb->esid);
+}
+
static int __spu_trap_data_seg(struct spu *spu, unsigned long ea)
{
struct spu_priv2 __iomem *priv2 = spu->priv2;
@@ -239,6 +256,38 @@ static int __spu_trap_data_map(struct sp
return 0;
}
+static void __spu_kernel_slb(void *addr, struct spu_slb *slb)
+{
+ unsigned long ea = (unsigned long)addr;
+ u64 llp;
+
+ if (REGION_ID(ea) == KERNEL_REGION_ID)
+ llp = mmu_psize_defs[mmu_linear_psize].sllp;
+ else
+ llp = mmu_psize_defs[mmu_virtual_psize].sllp;
+
+ slb->vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M) << SLB_VSID_SHIFT) |
+ SLB_VSID_KERNEL | llp;
+ slb->esid = (ea & ESID_MASK) | SLB_ESID_V;
+}
+
+/**
+ * Setup the SPU kernel SLBs, in preparation for a context save/restore. We
+ * need to map both the context save area, and the save/restore code.
+ */
+void spu_setup_kernel_slbs(struct spu *spu, struct spu_lscsa *lscsa, void *code)
+{
+ struct spu_slb code_slb, lscsa_slb;
+
+ __spu_kernel_slb(lscsa, &lscsa_slb);
+ __spu_kernel_slb(code, &code_slb);
+
+ spu_load_slb(spu, 0, &lscsa_slb);
+ if (lscsa_slb.esid != code_slb.esid)
+ spu_load_slb(spu, 1, &code_slb);
+}
+EXPORT_SYMBOL_GPL(spu_setup_kernel_slbs);
+
static irqreturn_t
spu_irq_class_0(int irq, void *data)
{
Index: linux-2.6-new/arch/powerpc/platforms/cell/spufs/switch.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spufs/switch.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spufs/switch.c
@@ -691,35 +691,8 @@ static inline void resume_mfc_queue(stru
out_be64(&priv2->mfc_control_RW, MFC_CNTL_RESUME_DMA_QUEUE);
}
-static inline void get_kernel_slb(u64 ea, u64 slb[2])
-{
- u64 llp;
-
- if (REGION_ID(ea) == KERNEL_REGION_ID)
- llp = mmu_psize_defs[mmu_linear_psize].sllp;
- else
- llp = mmu_psize_defs[mmu_virtual_psize].sllp;
- slb[0] = (get_kernel_vsid(ea, MMU_SEGSIZE_256M) << SLB_VSID_SHIFT) |
- SLB_VSID_KERNEL | llp;
- slb[1] = (ea & ESID_MASK) | SLB_ESID_V;
-}
-
-static inline void load_mfc_slb(struct spu *spu, u64 slb[2], int slbe)
-{
- struct spu_priv2 __iomem *priv2 = spu->priv2;
-
- out_be64(&priv2->slb_index_W, slbe);
- eieio();
- out_be64(&priv2->slb_vsid_RW, slb[0]);
- out_be64(&priv2->slb_esid_RW, slb[1]);
- eieio();
-}
-
static inline void setup_mfc_slbs(struct spu_state *csa, struct spu *spu)
{
- u64 code_slb[2];
- u64 lscsa_slb[2];
-
/* Save, Step 47:
* Restore, Step 30.
* If MFC_SR1[R]=1, write 0 to SLB_Invalidate_All
@@ -735,11 +708,7 @@ static inline void setup_mfc_slbs(struct
* translation is desired by OS environment).
*/
spu_invalidate_slbs(spu);
- get_kernel_slb((unsigned long)&spu_save_code[0], code_slb);
- get_kernel_slb((unsigned long)csa->lscsa, lscsa_slb);
- load_mfc_slb(spu, code_slb, 0);
- if ((lscsa_slb[0] != code_slb[0]) || (lscsa_slb[1] != code_slb[1]))
- load_mfc_slb(spu, lscsa_slb, 1);
+ spu_setup_kernel_slbs(spu, csa->lscsa, &spu_save_code);
}
static inline void set_switch_active(struct spu_state *csa, struct spu *spu)
Index: linux-2.6-new/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6-new.orig/include/asm-powerpc/spu.h
+++ linux-2.6-new/include/asm-powerpc/spu.h
@@ -104,6 +104,7 @@
struct spu_context;
struct spu_runqueue;
+struct spu_lscsa;
struct device_node;
enum spu_utilization_state {
@@ -200,6 +201,9 @@ int spu_irq_class_0_bottom(struct spu *s
int spu_irq_class_1_bottom(struct spu *spu);
void spu_irq_setaffinity(struct spu *spu, int cpu);
+void spu_setup_kernel_slbs(struct spu *spu,
+ struct spu_lscsa *lscsa, void *code);
+
#ifdef CONFIG_KEXEC
void crash_register_spus(struct list_head *list);
#else
--
^ permalink raw reply
* [POWERPC 15/18] cell: use spu_load_slb for SLB setup
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20071218174852.112644000@arndb.de>
Now that we have a helper function to setup a SPU SLB, use it for
__spu_trap_data_seq.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_base.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
@@ -169,9 +169,8 @@ static inline void spu_load_slb(struct s
static int __spu_trap_data_seg(struct spu *spu, unsigned long ea)
{
- struct spu_priv2 __iomem *priv2 = spu->priv2;
struct mm_struct *mm = spu->mm;
- u64 esid, vsid, llp;
+ struct spu_slb slb;
int psize;
pr_debug("%s\n", __FUNCTION__);
@@ -183,7 +182,7 @@ static int __spu_trap_data_seg(struct sp
printk("%s: invalid access during switch!\n", __func__);
return 1;
}
- esid = (ea & ESID_MASK) | SLB_ESID_V;
+ slb.esid = (ea & ESID_MASK) | SLB_ESID_V;
switch(REGION_ID(ea)) {
case USER_REGION_ID:
@@ -192,21 +191,21 @@ static int __spu_trap_data_seg(struct sp
#else
psize = mm->context.user_psize;
#endif
- vsid = (get_vsid(mm->context.id, ea, MMU_SEGSIZE_256M) << SLB_VSID_SHIFT) |
- SLB_VSID_USER;
+ slb.vsid = (get_vsid(mm->context.id, ea, MMU_SEGSIZE_256M)
+ << SLB_VSID_SHIFT) | SLB_VSID_USER;
break;
case VMALLOC_REGION_ID:
if (ea < VMALLOC_END)
psize = mmu_vmalloc_psize;
else
psize = mmu_io_psize;
- vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M) << SLB_VSID_SHIFT) |
- SLB_VSID_KERNEL;
+ slb.vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M)
+ << SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
break;
case KERNEL_REGION_ID:
psize = mmu_linear_psize;
- vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M) << SLB_VSID_SHIFT) |
- SLB_VSID_KERNEL;
+ slb.vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M)
+ << SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
break;
default:
/* Future: support kernel segments so that drivers
@@ -215,11 +214,9 @@ static int __spu_trap_data_seg(struct sp
pr_debug("invalid region access at %016lx\n", ea);
return 1;
}
- llp = mmu_psize_defs[psize].sllp;
+ slb.vsid |= mmu_psize_defs[psize].sllp;
- out_be64(&priv2->slb_index_W, spu->slb_replace);
- out_be64(&priv2->slb_vsid_RW, vsid | llp);
- out_be64(&priv2->slb_esid_RW, esid);
+ spu_load_slb(spu, spu->slb_replace, &slb);
spu->slb_replace++;
if (spu->slb_replace >= 8)
--
^ permalink raw reply
* [POWERPC 16/18] cell: add spu_64k_pages_available() check
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20071218174852.112644000@arndb.de>
Add a function spu_64k_pages_available(), so that we can abstract the
explicity use of mmu_psize_defs() in lssca_alloc.c
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_base.c | 6 ++++++
arch/powerpc/platforms/cell/spufs/lscsa_alloc.c | 2 +-
include/asm-powerpc/spu.h | 1 +
3 files changed, 8 insertions(+), 1 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
@@ -126,6 +126,12 @@ void spu_associate_mm(struct spu *spu, s
}
EXPORT_SYMBOL_GPL(spu_associate_mm);
+int spu_64k_pages_available(void)
+{
+ return mmu_psize_defs[MMU_PAGE_64K].shift != 0;
+}
+EXPORT_SYMBOL_GPL(spu_64k_pages_available);
+
static int __spu_trap_invalid_dma(struct spu *spu)
{
pr_debug("%s\n", __FUNCTION__);
Index: linux-2.6-new/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spufs/lscsa_alloc.c
@@ -73,7 +73,7 @@ int spu_alloc_lscsa(struct spu_state *cs
int i, j, n_4k;
/* Check availability of 64K pages */
- if (mmu_psize_defs[MMU_PAGE_64K].shift == 0)
+ if (!spu_64k_pages_available())
goto fail;
csa->use_big_pages = 1;
Index: linux-2.6-new/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6-new.orig/include/asm-powerpc/spu.h
+++ linux-2.6-new/include/asm-powerpc/spu.h
@@ -214,6 +214,7 @@ static inline void crash_register_spus(s
extern void spu_invalidate_slbs(struct spu *spu);
extern void spu_associate_mm(struct spu *spu, struct mm_struct *mm);
+int spu_64k_pages_available(void);
/* Calls from the memory management to the SPU */
struct mm_struct;
--
^ permalink raw reply
* [POWERPC 17/18] cell: handle SPE kernel mappings that cross segment boundaries
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20071218174852.112644000@arndb.de>
Currently, we have a possibilty that the SLBs setup during context
switch don't cover the entirety of the necessary lscsa and code
regions, if these regions cross a segment boundary.
This change checks the start and end of each region, and inserts a SLB
entry for each, if unique. We also remove the assumption that the
spu_save_code and spu_restore_code reside in the same segment, by using
the specific code array for save and restore.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_base.c | 50 ++++++++++++++++++++++++----
arch/powerpc/platforms/cell/spufs/switch.c | 11 ++++--
include/asm-powerpc/spu.h | 4 +-
3 files changed, 52 insertions(+), 13 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
@@ -275,19 +275,55 @@ static void __spu_kernel_slb(void *addr,
}
/**
+ * Given an array of @nr_slbs SLB entries, @slbs, return non-zero if the
+ * address @new_addr is present.
+ */
+static inline int __slb_present(struct spu_slb *slbs, int nr_slbs,
+ void *new_addr)
+{
+ unsigned long ea = (unsigned long)new_addr;
+ int i;
+
+ for (i = 0; i < nr_slbs; i++)
+ if (!((slbs[i].esid ^ ea) & ESID_MASK))
+ return 1;
+
+ return 0;
+}
+
+/**
* Setup the SPU kernel SLBs, in preparation for a context save/restore. We
* need to map both the context save area, and the save/restore code.
+ *
+ * Because the lscsa and code may cross segment boundaires, we check to see
+ * if mappings are required for the start and end of each range. We currently
+ * assume that the mappings are smaller that one segment - if not, something
+ * is seriously wrong.
*/
-void spu_setup_kernel_slbs(struct spu *spu, struct spu_lscsa *lscsa, void *code)
+void spu_setup_kernel_slbs(struct spu *spu, struct spu_lscsa *lscsa,
+ void *code, int code_size)
{
- struct spu_slb code_slb, lscsa_slb;
+ struct spu_slb slbs[4];
+ int i, nr_slbs = 0;
+ /* start and end addresses of both mappings */
+ void *addrs[] = {
+ lscsa, (void *)lscsa + sizeof(*lscsa) - 1,
+ code, code + code_size - 1
+ };
- __spu_kernel_slb(lscsa, &lscsa_slb);
- __spu_kernel_slb(code, &code_slb);
+ /* check the set of addresses, and create a new entry in the slbs array
+ * if there isn't already a SLB for that address */
+ for (i = 0; i < ARRAY_SIZE(addrs); i++) {
+ if (__slb_present(slbs, nr_slbs, addrs[i]))
+ continue;
+
+ __spu_kernel_slb(addrs[i], &slbs[nr_slbs]);
+ nr_slbs++;
+ }
- spu_load_slb(spu, 0, &lscsa_slb);
- if (lscsa_slb.esid != code_slb.esid)
- spu_load_slb(spu, 1, &code_slb);
+ /* Add the set of SLBs */
+ for (i = 0; i < nr_slbs; i++)
+ spu_load_slb(spu, i, &slbs[i]);
}
EXPORT_SYMBOL_GPL(spu_setup_kernel_slbs);
Index: linux-2.6-new/arch/powerpc/platforms/cell/spufs/switch.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spufs/switch.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spufs/switch.c
@@ -691,7 +691,8 @@ static inline void resume_mfc_queue(stru
out_be64(&priv2->mfc_control_RW, MFC_CNTL_RESUME_DMA_QUEUE);
}
-static inline void setup_mfc_slbs(struct spu_state *csa, struct spu *spu)
+static inline void setup_mfc_slbs(struct spu_state *csa, struct spu *spu,
+ unsigned int *code, int code_size)
{
/* Save, Step 47:
* Restore, Step 30.
@@ -708,7 +709,7 @@ static inline void setup_mfc_slbs(struct
* translation is desired by OS environment).
*/
spu_invalidate_slbs(spu);
- spu_setup_kernel_slbs(spu, csa->lscsa, &spu_save_code);
+ spu_setup_kernel_slbs(spu, csa->lscsa, code, code_size);
}
static inline void set_switch_active(struct spu_state *csa, struct spu *spu)
@@ -1835,7 +1836,8 @@ static void save_lscsa(struct spu_state
*/
resume_mfc_queue(prev, spu); /* Step 46. */
- setup_mfc_slbs(prev, spu); /* Step 47. */
+ /* Step 47. */
+ setup_mfc_slbs(prev, spu, spu_save_code, sizeof(spu_save_code));
set_switch_active(prev, spu); /* Step 48. */
enable_interrupts(prev, spu); /* Step 49. */
save_ls_16kb(prev, spu); /* Step 50. */
@@ -1940,7 +1942,8 @@ static void restore_lscsa(struct spu_sta
setup_spu_status_part1(next, spu); /* Step 27. */
setup_spu_status_part2(next, spu); /* Step 28. */
restore_mfc_rag(next, spu); /* Step 29. */
- setup_mfc_slbs(next, spu); /* Step 30. */
+ /* Step 30. */
+ setup_mfc_slbs(next, spu, spu_restore_code, sizeof(spu_restore_code));
set_spu_npc(next, spu); /* Step 31. */
set_signot1(next, spu); /* Step 32. */
set_signot2(next, spu); /* Step 33. */
Index: linux-2.6-new/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6-new.orig/include/asm-powerpc/spu.h
+++ linux-2.6-new/include/asm-powerpc/spu.h
@@ -201,8 +201,8 @@ int spu_irq_class_0_bottom(struct spu *s
int spu_irq_class_1_bottom(struct spu *spu);
void spu_irq_setaffinity(struct spu *spu, int cpu);
-void spu_setup_kernel_slbs(struct spu *spu,
- struct spu_lscsa *lscsa, void *code);
+void spu_setup_kernel_slbs(struct spu *spu, struct spu_lscsa *lscsa,
+ void *code, int code_size);
#ifdef CONFIG_KEXEC
void crash_register_spus(struct list_head *list);
--
^ permalink raw reply
* [POWERPC 18/18] cell: catch errors from sysfs_create_group()
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20071218174852.112644000@arndb.de>
We're currently getting a warning from not checking the result of
sysfs_create_group, which is declared as __must_check.
This change introduces appropriate error-handling for
spu_add_sysdev_attr_group()
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spu_base.c | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/spu_base.c
@@ -574,13 +574,27 @@ EXPORT_SYMBOL_GPL(spu_add_sysdev_attr);
int spu_add_sysdev_attr_group(struct attribute_group *attrs)
{
struct spu *spu;
+ int rc = 0;
mutex_lock(&spu_full_list_mutex);
- list_for_each_entry(spu, &spu_full_list, full_list)
- sysfs_create_group(&spu->sysdev.kobj, attrs);
+ list_for_each_entry(spu, &spu_full_list, full_list) {
+ rc = sysfs_create_group(&spu->sysdev.kobj, attrs);
+
+ /* we're in trouble here, but try unwinding anyway */
+ if (rc) {
+ printk(KERN_ERR "%s: can't create sysfs group '%s'\n",
+ __func__, attrs->name);
+
+ list_for_each_entry_continue_reverse(spu,
+ &spu_full_list, full_list)
+ sysfs_remove_group(&spu->sysdev.kobj, attrs);
+ break;
+ }
+ }
+
mutex_unlock(&spu_full_list_mutex);
- return 0;
+ return rc;
}
EXPORT_SYMBOL_GPL(spu_add_sysdev_attr_group);
--
^ permalink raw reply
* [POWERPC 01/18] perfmon2: make pm_interval register read/write
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Kevin Corry, Carl Love
In-Reply-To: <20071218174852.112644000@arndb.de>
The pm_interval register in the Cell PMU is read/write, but was implemented in
the kernel as write-only. Previously, the written value was saved in a "shadow"
copy so calls to cbe_read_pm() could return the value.
Perfmon2 needs to be able to read the current values of pm_interval, so change
cbe_read_pm() to read the actual register instead of the "shadow" copy. There
is currently no code in the kernel that tries to read the pm_interval register
with cbe_read_pm() (expecting to receive the "shadow" value), so this should
not break any existing code.
Signed-off-by: Kevin Corry <kevcorry@us.ibm.com>
Signed-off-by: Carl Love <carll@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/pmu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/pmu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/pmu.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/pmu.c
@@ -213,7 +213,7 @@ u32 cbe_read_pm(u32 cpu, enum pm_reg_nam
break;
case pm_interval:
- READ_SHADOW_REG(val, pm_interval);
+ READ_MMIO_UPPER32(val, pm_interval);
break;
case pm_start_stop:
--
^ permalink raw reply
* [POWERPC 00/18] cell patches for 2.6.25
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
These are the patches I have collected for 2.6.25. It's been a bit since
the first call-for-patches for that version, but as it seems that 2.6.24
isn't imminent yet, I hope it's not too late for them.
Everyone, if there is some cell related patch that is not yet in
powerpc.git, in cell-2.6.git#spufs or in this series, it probably fell under
the table and you should resend it.
Paul, if there are no objections to these patches, please pull them from
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
Thanks,
Arnd <><
--
^ permalink raw reply
* [POWERPC 02/18] OProfile: fix cbe pm signal routing problem
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Bob Nelson
In-Reply-To: <20071218174852.112644000@arndb.de>
Fix debug_bus_control and group_control PMU register values set up in
set_pm_event(). Initialize variables before calling set_pm_event().
Delete unused static array and code that initialized it.
Rename constant to better reflect usage.
Signed-off-by: Bob Nelson <rrnelson@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/oprofile/op_model_cell.c | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
Index: linux-2.6-new/arch/powerpc/oprofile/op_model_cell.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/oprofile/op_model_cell.c
+++ linux-2.6-new/arch/powerpc/oprofile/op_model_cell.c
@@ -61,7 +61,7 @@ static unsigned int spu_cycle_reset;
#define NUM_THREADS 2 /* number of physical threads in
* physical processor
*/
-#define NUM_TRACE_BUS_WORDS 4
+#define NUM_DEBUG_BUS_WORDS 4
#define NUM_INPUT_BUS_WORDS 2
#define MAX_SPU_COUNT 0xFFFFFF /* maximum 24 bit LFSR value */
@@ -169,7 +169,6 @@ static DEFINE_SPINLOCK(virt_cntr_lock);
static u32 ctr_enabled;
-static unsigned char trace_bus[NUM_TRACE_BUS_WORDS];
static unsigned char input_bus[NUM_INPUT_BUS_WORDS];
/*
@@ -298,7 +297,7 @@ static void set_pm_event(u32 ctr, int ev
p->signal_group = event / 100;
p->bus_word = bus_word;
- p->sub_unit = (unit_mask & 0x0000f000) >> 12;
+ p->sub_unit = GET_SUB_UNIT(unit_mask);
pm_regs.pm07_cntrl[ctr] = 0;
pm_regs.pm07_cntrl[ctr] |= PM07_CTR_COUNT_CYCLES(count_cycles);
@@ -334,16 +333,16 @@ static void set_pm_event(u32 ctr, int ev
p->bit = signal_bit;
}
- for (i = 0; i < NUM_TRACE_BUS_WORDS; i++) {
+ for (i = 0; i < NUM_DEBUG_BUS_WORDS; i++) {
if (bus_word & (1 << i)) {
pm_regs.debug_bus_control |=
- (bus_type << (31 - (2 * i) + 1));
+ (bus_type << (30 - (2 * i)));
for (j = 0; j < NUM_INPUT_BUS_WORDS; j++) {
if (input_bus[j] == 0xff) {
input_bus[j] = i;
pm_regs.group_control |=
- (i << (31 - i));
+ (i << (30 - (2 * j)));
break;
}
@@ -450,6 +449,12 @@ static void cell_virtual_cntr(unsigned l
hdw_thread = 1 ^ hdw_thread;
next_hdw_thread = hdw_thread;
+ pm_regs.group_control = 0;
+ pm_regs.debug_bus_control = 0;
+
+ for (i = 0; i < NUM_INPUT_BUS_WORDS; i++)
+ input_bus[i] = 0xff;
+
/*
* There are some per thread events. Must do the
* set event, for the thread that is being started
@@ -619,9 +624,6 @@ static int cell_reg_setup(struct op_coun
pmc_cntrl[1][i].vcntr = i;
}
- for (i = 0; i < NUM_TRACE_BUS_WORDS; i++)
- trace_bus[i] = 0xff;
-
for (i = 0; i < NUM_INPUT_BUS_WORDS; i++)
input_bus[i] = 0xff;
--
^ permalink raw reply
* [POWERPC 10/18] Remove bogus comment in dma_direct_alloc_coherent()
From: arnd @ 2007-12-18 17:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use
node local allocations) went in this comment makes no sense.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/kernel/dma_64.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
Index: linux-2.6-new/arch/powerpc/kernel/dma_64.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/kernel/dma_64.c
+++ linux-2.6-new/arch/powerpc/kernel/dma_64.c
@@ -137,7 +137,6 @@ static void *dma_direct_alloc_coherent(s
void *ret;
int node = dev->archdata.numa_node;
- /* TODO: Maybe use the numa node here too ? */
page = alloc_pages_node(node, flag, get_order(size));
if (page == NULL)
return NULL;
--
^ permalink raw reply
* [POWERPC 06/18] Use archdata.dma_data in dma_direct_ops
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
Now that all platforms using dma_direct_offset setup the archdata.dma_data
correctly, we can change the dma_direct_ops to retrieve the offset from
the dma_data, rather than directly from the global.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/kernel/dma_64.c | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
Index: linux-2.6-new/arch/powerpc/kernel/dma_64.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/kernel/dma_64.c
+++ linux-2.6-new/arch/powerpc/kernel/dma_64.c
@@ -117,6 +117,18 @@ EXPORT_SYMBOL(dma_iommu_ops);
*/
unsigned long dma_direct_offset;
+static unsigned long get_dma_direct_offset(struct device *dev)
+{
+ unsigned long *offset;
+
+ offset = dev->archdata.dma_data;
+
+ if (offset)
+ return *offset;
+
+ return 0;
+}
+
static void *dma_direct_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
@@ -130,7 +142,7 @@ static void *dma_direct_alloc_coherent(s
return NULL;
ret = page_address(page);
memset(ret, 0, size);
- *dma_handle = virt_to_abs(ret) | dma_direct_offset;
+ *dma_handle = virt_to_abs(ret) | get_dma_direct_offset(dev);
return ret;
}
@@ -145,7 +157,7 @@ static dma_addr_t dma_direct_map_single(
size_t size,
enum dma_data_direction direction)
{
- return virt_to_abs(ptr) | dma_direct_offset;
+ return virt_to_abs(ptr) | get_dma_direct_offset(dev);
}
static void dma_direct_unmap_single(struct device *dev, dma_addr_t dma_addr,
@@ -161,7 +173,7 @@ static int dma_direct_map_sg(struct devi
int i;
for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = sg_phys(sg) | dma_direct_offset;
+ sg->dma_address = sg_phys(sg) | get_dma_direct_offset(dev);
sg->dma_length = sg->length;
}
--
^ permalink raw reply
* [POWERPC 07/18] Have cell use its own dma_direct_offset variable
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
Rather than using the global variable, have cell use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/iommu.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/cell/iommu.c
@@ -490,6 +490,8 @@ static struct cbe_iommu *cell_iommu_for_
return NULL;
}
+static unsigned long cell_dma_direct_offset;
+
static void cell_dma_dev_setup(struct device *dev)
{
struct iommu_window *window;
@@ -497,7 +499,7 @@ static void cell_dma_dev_setup(struct de
struct dev_archdata *archdata = &dev->archdata;
if (get_pci_dma_ops() == &dma_direct_ops) {
- archdata->dma_data = &dma_direct_offset;
+ archdata->dma_data = &cell_dma_direct_offset;
return;
}
@@ -655,7 +657,7 @@ static int __init cell_iommu_init_disabl
/* If we have no Axon, we set up the spider DMA magic offset */
if (of_find_node_by_name(NULL, "axon") == NULL)
- dma_direct_offset = SPIDER_DMA_OFFSET;
+ cell_dma_direct_offset = SPIDER_DMA_OFFSET;
/* Now we need to check to see where the memory is mapped
* in PCI space. We assume that all busses use the same dma
@@ -689,10 +691,10 @@ static int __init cell_iommu_init_disabl
return -ENODEV;
}
- dma_direct_offset += base;
+ cell_dma_direct_offset += base;
printk("iommu: disabled, direct DMA offset is 0x%lx\n",
- dma_direct_offset);
+ cell_dma_direct_offset);
return 0;
}
--
^ permalink raw reply
* [POWERPC 05/18] Add celleb_dma_dev_setup()
From: arnd @ 2007-12-18 17:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071218174852.112644000@arndb.de>
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
should set dma_data to dma_direct_offset.
Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/celleb/iommu.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
Index: linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
===================================================================
--- linux-2.6-new.orig/arch/powerpc/platforms/celleb/iommu.c
+++ linux-2.6-new/arch/powerpc/platforms/celleb/iommu.c
@@ -72,6 +72,17 @@ static void __init celleb_init_direct_ma
dma_direct_offset = dma_base;
}
+static void celleb_dma_dev_setup(struct device *dev)
+{
+ dev->archdata.dma_ops = get_pci_dma_ops();
+ dev->archdata.dma_data = &dma_direct_offset;
+}
+
+static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
+{
+ celleb_dma_dev_setup(&pdev->dev);
+}
+
static int celleb_of_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -81,7 +92,7 @@ static int celleb_of_bus_notify(struct n
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;
- dev->archdata.dma_ops = get_pci_dma_ops();
+ celleb_dma_dev_setup(dev);
return 0;
}
@@ -97,6 +108,7 @@ 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(&of_platform_bus_type, &celleb_of_bus_notifier);
return 0;
--
^ 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