Re: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
Hi Jeff, > ACK, pass this through paulus? Yes, that's fine for me. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC5200] problem running FEC and ATA
On Sunday 16 December 2007 18:28, Arnon Kaufman wrote: > Robert Schwebel wrote: >> On Sun, Dec 16, 2007 at 03:24:34PM +0200, Arnon Kaufman wrote: >>> does any one succeed running a functional FEC and ATA (pata) running >>> together? >> >> Yes, we do, on the phyCORE-MPC5200B-tiny; you can check our patches here: >> http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/ > > thanks, my kernels are already patched and still observing that kind of > behavior. I'm using Domen's new FEC code and ATA from 2.6.24-rc2. I tried our kernel (see link above) with an external harddisk and NFS. I copied various files from the harddisk to NFS root and vice versa. No data corruption. Can you check our patch stack on your hardware? Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Raising list size limit
On Tue, 18 Dec 2007 14:36:27 +1100 Stephen Rothwell <[EMAIL PROTECTED]> 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! josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix sleep on powerbook 3400
> Sleep on the powerbook 3400 has been broken since the change that made > powerbook_sleep_3400 call pmac_suspend_devices(), which disables > interrupts. There are a couple of loops in powerbook_sleep_3400 that > depend on interrupts being enabled, and in fact it has to have > interrupts enabled at the point of going to sleep since it is an > interrupt from the PMU that wakes it up. Do you want me to rebase my patches on top of this? johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Platform Changes for UCC TDM driver for MPC8323ERDB. Also includes related QE changes.
From: Poonam Aggrwal <[EMAIL PROTECTED]>
This patch makes necessary changes in the QE and UCC framework to support
TDM. It also adds support to configure the BRG properly through device
tree entries. Includes the device tree changes for UCC TDM driver as well.
It also includes device tree entries for UCC TDM driver.
Tested on MPC8323ERDB platform.
Signed-off-by: Poonam Aggrwal <[EMAIL PROTECTED]>
Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
---
Incorporated comments of Stephen and Tabi. Please review if they look
fine.
arch/powerpc/boot/dts/mpc832x_rdb.dts | 58 +++
arch/powerpc/sysdev/qe_lib/qe.c | 205 --
arch/powerpc/sysdev/qe_lib/ucc.c | 265 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 37 +
include/asm-powerpc/qe.h |8 +
include/asm-powerpc/ucc.h |4 +
include/asm-powerpc/ucc_fast.h|4 +
7 files changed, 568 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 388c8a7..c0e6283 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -105,6 +105,17 @@
device_type = "par_io";
num-ports = <7>;
+ ucc1pio:[EMAIL PROTECTED] {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0 e 2 0 1 0/* CLK11 */
+ 3 16 1 0 2 0/* BRG9 */
+ 3 1b 1 0 2 0/* BRG3 */
+ 0 0 3 0 2 0/* TDMATxD0 */
+ 0 4 3 0 2 0/* TDMARxD0 */
+ 3 1b 2 0 1 0>; /* CLK1 */
+ };
+
ucc2pio:[EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -169,6 +180,36 @@
};
};
+ clocks {
+ compatible = "fsl,cpm-clocks";
+ /* clock freqs in Hz(for CLK1~CLK24).
+* CLK11 is 1024KHz,
+* all other clocks unused
+* #clock-cells define number of cells
+* used by the clock-frequency.
+* right now only #clock cells=1 is
+* implemented. Provision is there to
+* handle frequencies >4Gig
+*/
+ #clock-cells = <1>;
+ clock-frequency = <0 0 0 0 0 0
+ 0 0 0 0 d#1024000 0
+ 0 0 0 0 0 0
+ 0 0 0 0 0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,cpm-brg";
+ /* input clock sources for all the 16 BRGs.
+* 1-24 for CLK1 to CLK24.
+* BRG9 uses CLK11,BRG1 and BRG2-8 use
+* the QE clock.
+*/
+ fsl,brg-sources = <0 0 0 0 0 0 0 0
+ b 0 0 0 0 0 0 0>;
+ reg = <640 7f>;
+ };
+
[EMAIL PROTECTED] {
device_type = "spi";
compatible = "fsl_spi";
@@ -187,6 +228,23 @@
mode = "cpu";
};
+ [EMAIL PROTECTED] {
+ device_type = "tdm";
+ compatible = "fsl,ucc-tdm";
+ model = "UCC";
+ device-id = <1>;
+ fsl,tdm-num = <1>;
+ fsl,si-num = <1>;
+ fsl,tdm-tx-clk = "CLK1";
+ fsl,tdm-rx-clk = "CLK1";
+ fsl,tdm-tx-sync = "BRG9";
+ fsl,tdm-rx-sync = "BRG9";
+ reg = <2000 200>;
+ interrupts = <20>;
+ interrupt-parent = <&qeic>;
+ pio-handle = <&ucc1pio>;
+ };
+
[EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 1df3b4a..f1bc902 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -149,20 +149,189 @@ EXPORT_SYMBOL(qe_issue_cmd);
*/
static unsigned
Re: dtc: Remove remaining old-style checks
So, like, the other day David Gibson mumbled: > The remaining old-style tree checking code: check_root(), check_cpus() > and check_memory() really aren't that useful. They mostly check for > the presence of particular nodes and properties. That's inherently > prone to false-positives, because we could be dealing with an > artificial tree (like many of the testcases) or it could be expected > that the missing properties are filled in by a bootloader or other > agent. > > If any of these checks really turns out to be useful, we can > reimplement them later in a better conceived way on top of the new > checking infrastructure. For now, just get rid of them, removing the > last vestiges of the old-style checking code (hoorah). > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] [POWERPC] Add fixed-phy support for fs_enet
On Mon, 17 Dec 2007 18:20:14 -0500 Jeff Garzik wrote: > Jochen Friedrich wrote: > > This patch adds support to use the fixed-link property > > of an ethernet node to fs_enet for the > > CONFIG_PPC_CPM_NEW_BINDING case. > > > > Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> Acked-by: Vitaly Bordug <[EMAIL PROTECTED]> Jochen, will you resend the patch with all acks to paulus? I'll do that if not. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Add fixed-phy support for fs_enet
This patch adds support to use the fixed-link property
of an ethernet node to fs_enet for the
CONFIG_PPC_CPM_NEW_BINDING case.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Vitali Bordug <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..8220c70 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1174,8 +1174,15 @@ static int __devinit find_phy(struct device_node *np,
struct device_node *phynode, *mdionode;
struct resource res;
int ret = 0, len;
+ const u32 *data;
+
+ data = of_get_property(np, "fixed-link", NULL);
+ if (data) {
+ snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data);
+ return 0;
+ }
- const u32 *data = of_get_property(np, "phy-handle", &len);
+ data = of_get_property(np, "phy-handle", &len);
if (!data || len != 4)
return -EINVAL;
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
On Dec 15, 2007, at 10:23 AM, Anton Vorontsov wrote:
>
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <16 8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + };
> +
In addition to David's comments. I've added cell-index:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = ;
interrupt-parent = < &ipic >;
dfsrr;
};
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <3100 100>;
interrupts = ;
interrupt-parent = < &ipic >;
dfsrr;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/7] Copy mpc-i2c to preserve support for ARCH=ppc and allow changes on ARCH=powerpc
On Dec 17, 2007, at 8:39 PM, Jon Smirl wrote: > Temporarily copy the mpc-i2c driver to continue support for the ppc > architecture until it is removed in mid-2008. This file should be > deleted as part of ppc's final removal. > > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> > > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> > > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> > --- > > arch/ppc/configs/TQM8540_defconfig |2 > arch/ppc/configs/TQM8541_defconfig |2 > arch/ppc/configs/TQM8555_defconfig |2 > arch/ppc/configs/TQM8560_defconfig |2 > arch/ppc/configs/mpc834x_sys_defconfig |2 > arch/ppc/configs/mpc8540_ads_defconfig |2 > arch/ppc/configs/mpc8548_cds_defconfig |2 > arch/ppc/configs/mpc8555_cds_defconfig |2 > arch/ppc/configs/mpc8560_ads_defconfig |2 > drivers/i2c/busses/Kconfig | 16 + > drivers/i2c/busses/Makefile|1 > drivers/i2c/busses/i2c-mpc-ppc.c | 418 +++ > + > 12 files changed, 443 insertions(+), 10 deletions(-) > create mode 100644 drivers/i2c/busses/i2c-mpc-ppc.c Nak. Just ifdef the probe functionality in i2c-mpc.c based on CONFIG_PPC_MERGE. Your patch set shows the reason you should do this. You provide fixes to the error path handling, but only for i2c- mpc.c and not i2c-mpc-ppc.c. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Raising list size limit
On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote: > On Tue, 18 Dec 2007 14:36:27 +1100 > Stephen Rothwell <[EMAIL PROTECTED]> 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? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Raising list size limit
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 <[EMAIL PROTECTED]> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] 8xx: Analogue & Micro Adder875 board support.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/10] powerpc: Add kexec support for PPC_85xx platforms
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] mpc82xx: Embedded Planet EP8248E support
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.
+ [EMAIL PROTECTED] {
+ #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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 07/10] powerpc: Implement kmap_atomic_pfn on powerpc
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 <[EMAIL PROTECTED]>
> > ---
> > 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;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Raising list size limit
On Tue, 18 Dec 2007 09:54:15 -0600 Kumar Gala <[EMAIL PROTECTED]> wrote: > > On Dec 18, 2007, at 6:01 AM, Josh Boyer wrote: > > > On Tue, 18 Dec 2007 14:36:27 +1100 > > Stephen Rothwell <[EMAIL PROTECTED]> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
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]
> >
> > > > + [EMAIL PROTECTED] { /* 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 0x8000, 0x8001, 0x8002).
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
> >
> > [EMAIL PROTECTED] {
> > reg = <0x2000 0x2000>;
> > [EMAIL PROTECTED] {
> > 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 ];
> > };
> > [EMAIL PROTECTED] {
> > 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: [EMAIL PROTECTED] {
> > device_type = "ethernet-phy";
> > compatible = "broadcom,bcm5421";
> > interrupts = <76>; /* GPP 12 */
> > interrupt-parent = <&PIC>;
> > reg = <1>;
> > };
> > PHY1: [EMAIL PROTECTED] {
> > device_type = "ethernet-phy";
> > compatible = "broadcom,bcm5421";
> > interrupts = <76>; /* GPP 12 */
> > interrupt-parent = <&PIC>;
> > reg = <3>;
> > };
> > };
> > };
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 07/10] powerpc: Implement kmap_atomic_pfn on powerpc
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
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: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 01/18] perfmon2: make pm_interval register read/write
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 <[EMAIL PROTECTED]> Signed-off-by: Carl Love <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- 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: -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 00/18] cell patches for 2.6.25
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 <>< -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 02/18] OProfile: fix cbe pm signal routing problem
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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 0xFF /* 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 & 0xf000) >> 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;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 10/18] Remove bogus comment in dma_direct_alloc_coherent()
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use node local allocations) went in this comment makes no sense. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- 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; -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 06/18] Use archdata.dma_data in dma_direct_ops
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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;
}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 07/18] Have cell use its own dma_direct_offset variable
Rather than using the global variable, have cell use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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;
}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 05/18] Add celleb_dma_dev_setup()
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 09/18] Remove the global dma_direct_offset
We no longer need the global dma_direct_offset, update the comment to
reflect the new reality.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c |7 ---
include/asm-powerpc/dma-mapping.h |2 --
2 files changed, 4 insertions(+), 5 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
@@ -112,10 +112,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
/*
* Generic direct DMA implementation
*
- * This implementation supports a global offset that can be applied if
- * the address at which memory is visible to devices is not 0.
+ * This implementation supports a per-device offset that can be applied if
+ * the address at which memory is visible to devices is not 0. Platform code
+ * can point archdata.dma_data at an unsigned long holding the offset. By
+ * default no offset is used.
*/
-unsigned long dma_direct_offset;
static unsigned long get_dma_direct_offset(struct device *dev)
{
Index: linux-2.6-new/include/asm-powerpc/dma-mapping.h
===
--- linux-2.6-new.orig/include/asm-powerpc/dma-mapping.h
+++ linux-2.6-new/include/asm-powerpc/dma-mapping.h
@@ -186,8 +186,6 @@ static inline void dma_unmap_sg(struct d
extern struct dma_mapping_ops dma_iommu_ops;
extern struct dma_mapping_ops dma_direct_ops;
-extern unsigned long dma_direct_offset;
-
#else /* CONFIG_PPC64 */
#define dma_supported(dev, mask) (1)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 04/18] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
Store a pointer to the direct_dma_offset in each device's dma_data
in the case where we're using the direct DMA ops.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c |5 +++--
1 files changed, 3 insertions(+), 2 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
@@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct de
struct cbe_iommu *iommu;
struct dev_archdata *archdata = &dev->archdata;
- /* If we run without iommu, no need to do anything */
- if (get_pci_dma_ops() == &dma_direct_ops)
+ if (get_pci_dma_ops() == &dma_direct_ops) {
+ archdata->dma_data = &dma_direct_offset;
return;
+ }
/* Current implementation uses the first window available in that
* node's iommu. We -might- do something smarter later though it may
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 12/18] cell: export force_sig_info()
Export force_sig_info to allow signals to be sent from a modular spufs. Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- 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); -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 08/18] Have celleb use its own dma_direct_offset variable
Rather than using the global variable, have celleb use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/celleb/iommu.c |6 --
1 files changed, 4 insertions(+), 2 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
@@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *i
return 0;
}
+static unsigned long celleb_dma_direct_offset;
+
static void __init celleb_init_direct_mapping(void)
{
u64 lpar_addr, io_addr;
@@ -69,13 +71,13 @@ static void __init celleb_init_direct_ma
ioid, DMA_FLAGS);
}
- dma_direct_offset = dma_base;
+ celleb_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;
+ dev->archdata.dma_data = &celleb_dma_direct_offset;
}
static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 15/18] cell: use spu_load_slb for SLB setup
Now that we have a helper function to setup a SPU SLB, use it for
__spu_trap_data_seq.
Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 14/18] cell: handle kernel SLB setup in spu_base.c
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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
#include
#include
+#include
#include
#include
@@ -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_sl
[POWERPC 16/18] cell: add spu_64k_pages_available() check
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 18/18] cell: catch errors from sysfs_create_group()
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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);
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 11/18] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- arch/powerpc/platforms/cell/cbe_cpufreq.c |3 ++- arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c |3 ++- arch/powerpc/platforms/cell/cbe_regs.c|4 ++-- arch/powerpc/platforms/cell/iommu.c |2 +- arch/powerpc/platforms/cell/setup.c |2 +- arch/powerpc/platforms/celleb/iommu.c |3 +-- arch/powerpc/platforms/celleb/setup.c |2 +- 7 files changed, 10 insertions(+), 9 deletions(-) Index: linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq.c === --- linux-2.6-new.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c +++ linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq.c @@ -21,8 +21,9 @@ */ #include +#include + #include -#include #include #include #include "cbe_cpufreq.h" Index: linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c === --- linux-2.6-new.orig/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c +++ linux-2.6-new/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c @@ -23,7 +23,8 @@ #include #include #include -#include +#include + #include #include #include Index: linux-2.6-new/arch/powerpc/platforms/cell/cbe_regs.c === --- linux-2.6-new.orig/arch/powerpc/platforms/cell/cbe_regs.c +++ linux-2.6-new/arch/powerpc/platforms/cell/cbe_regs.c @@ -9,13 +9,13 @@ #include #include #include +#include +#include #include #include #include #include -#include -#include #include /* 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 @@ -26,13 +26,13 @@ #include #include #include +#include #include #include #include #include #include -#include #include #include #include Index: linux-2.6-new/arch/powerpc/platforms/cell/setup.c === --- linux-2.6-new.orig/arch/powerpc/platforms/cell/setup.c +++ linux-2.6-new/arch/powerpc/platforms/cell/setup.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include @@ -51,7 +52,6 @@ #include #include #include -#include #include #include "interrupt.h" 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 @@ -22,8 +22,8 @@ #include #include #include +#include -#include #include #include "beat_wrapper.h" Index: linux-2.6-new/arch/powerpc/platforms/celleb/setup.c === --- linux-2.6-new.orig/arch/powerpc/platforms/celleb/setup.c +++ linux-2.6-new/arch/powerpc/platforms/celleb/setup.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -52,7 +53,6 @@ #include #include #include -#include #include #include -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 03/18] cell: add missing \n
Two printk() calls were missing the terminating '\n'.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spu_manage.c |4 ++--
1 files changed, 2 insertions(+), 2 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
@@ -345,7 +345,7 @@ static int __init of_create_spu(struct s
}
ret = spu_map_interrupts_old(spu, spe);
if (ret) {
- printk(KERN_ERR "%s: could not map interrupts",
+ printk(KERN_ERR "%s: could not map interrupts\n",
spu->name);
goto out_unmap;
}
@@ -525,7 +525,7 @@ static int __init init_affinity(void)
if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
init_affinity_qs20_harcoded();
else
- printk("No affinity configuration found");
+ printk("No affinity configuration found\n");
}
return 0;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 13/18] cell: safer of_has_vicinity routine
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC 17/18] cell: handle SPE kernel mappings that cross segment boundaries
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 <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
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, s
Re: [POWERPC 04/18] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()
On Tue, 2007-12-18 at 18:48 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment
> (0014-Set-archdata.dma_data-for-direct-DMA-in-cell_dma_dev.patch)
> Store a pointer to the direct_dma_offset in each device's dma_data
> in the case where we're using the direct DMA ops.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Ack.
> ---
> arch/powerpc/platforms/cell/iommu.c |5 +++--
> 1 files changed, 3 insertions(+), 2 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
> @@ -496,9 +496,10 @@ static void cell_dma_dev_setup(struct de
> struct cbe_iommu *iommu;
> struct dev_archdata *archdata = &dev->archdata;
>
> - /* If we run without iommu, no need to do anything */
> - if (get_pci_dma_ops() == &dma_direct_ops)
> + if (get_pci_dma_ops() == &dma_direct_ops) {
> + archdata->dma_data = &dma_direct_offset;
> return;
> + }
>
> /* Current implementation uses the first window available in that
>* node's iommu. We -might- do something smarter later though it may
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 05/18] Add celleb_dma_dev_setup()
On Tue, 2007-12-18 at 18:48 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment (0015-Add-celleb_dma_dev_setup.patch)
> 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 <[EMAIL PROTECTED]>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
> ---
Ack.
> 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;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 06/18] Use archdata.dma_data in dma_direct_ops
On Tue, 2007-12-18 at 18:48 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment
> (0016-Use-archdata.dma_data-in-dma_direct_ops.patch)
> 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 <[EMAIL PROTECTED]>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Ack.
> 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;
> }
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 07/18] Have cell use its own dma_direct_offset variable
On Tue, 2007-12-18 at 18:48 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment
> (0017-Have-cell-use-its-own-dma_direct_offset-variable.patch)
> Rather than using the global variable, have cell use its own variable to
> store the direct DMA offset.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
> ---
Ack.
> 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;
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 08/18] Have celleb use its own dma_direct_offset variable
On Tue, 2007-12-18 at 18:49 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment
> (0018-Have-celleb-use-its-own-dma_direct_offset-variable.patch)
> Rather than using the global variable, have celleb use its own variable to
> store the direct DMA offset.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
> ---
Ack.
> arch/powerpc/platforms/celleb/iommu.c |6 --
> 1 files changed, 4 insertions(+), 2 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
> @@ -52,6 +52,8 @@ static int __init find_dma_window(u64 *i
> return 0;
> }
>
> +static unsigned long celleb_dma_direct_offset;
> +
> static void __init celleb_init_direct_mapping(void)
> {
> u64 lpar_addr, io_addr;
> @@ -69,13 +71,13 @@ static void __init celleb_init_direct_ma
>ioid, DMA_FLAGS);
> }
>
> - dma_direct_offset = dma_base;
> + celleb_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;
> + dev->archdata.dma_data = &celleb_dma_direct_offset;
> }
>
> static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 09/18] Remove the global dma_direct_offset
On Tue, 2007-12-18 at 18:49 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment
> (0019-Remove-the-global-dma_direct_offset.patch)
> We no longer need the global dma_direct_offset, update the comment to
> reflect the new reality.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
> ---
Ack.
> arch/powerpc/kernel/dma_64.c |7 ---
> include/asm-powerpc/dma-mapping.h |2 --
> 2 files changed, 4 insertions(+), 5 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
> @@ -112,10 +112,11 @@ EXPORT_SYMBOL(dma_iommu_ops);
> /*
> * Generic direct DMA implementation
> *
> - * This implementation supports a global offset that can be applied if
> - * the address at which memory is visible to devices is not 0.
> + * This implementation supports a per-device offset that can be applied if
> + * the address at which memory is visible to devices is not 0. Platform code
> + * can point archdata.dma_data at an unsigned long holding the offset. By
> + * default no offset is used.
> */
> -unsigned long dma_direct_offset;
>
> static unsigned long get_dma_direct_offset(struct device *dev)
> {
> Index: linux-2.6-new/include/asm-powerpc/dma-mapping.h
> ===
> --- linux-2.6-new.orig/include/asm-powerpc/dma-mapping.h
> +++ linux-2.6-new/include/asm-powerpc/dma-mapping.h
> @@ -186,8 +186,6 @@ static inline void dma_unmap_sg(struct d
> extern struct dma_mapping_ops dma_iommu_ops;
> extern struct dma_mapping_ops dma_direct_ops;
>
> -extern unsigned long dma_direct_offset;
> -
> #else /* CONFIG_PPC64 */
>
> #define dma_supported(dev, mask) (1)
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 10/18] Remove bogus comment in dma_direct_alloc_coherent()
On Tue, 2007-12-18 at 18:49 +0100, [EMAIL PROTECTED] wrote: > plain text document attachment > (0020-Remove-bogus-comment-in-dma_direct_alloc_coherent.patch) > Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use > node local allocations) went in this comment makes no sense. > > Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > --- Ack. > 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; > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 00/18] cell patches for 2.6.25
On Tuesday 18 December 2007, [EMAIL PROTECTED] wrote: > 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 I just noticed that quilt ate the 'From' lines from the patches when sending them out, so make sure you don't apply them from mail. The git tree is fine, so I can send them out as patches again if necessary. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ppc405 in EDK9.2
The PPC405 in EDK9.2 and beyond has a slightly different set of bus interfaces than before. I've updated the BSP generator to handle it, and added some test cases. The updates are at git://git.xilinx.com/gen-mhs-devtree.git Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix sleep on powerbook 3400
Johannes Berg writes: > Do you want me to rebase my patches on top of this? Don't bother, I'll just tweak your patches, or do a git merge between your changes and mine. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
On Sat, Dec 15, 2007 at 09:03:35AM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 05:37:38PM -0700, Mark A. Greer wrote:
> > From: Mark A. Greer <[EMAIL PROTECTED]>
> >
> > Convert the prpmc2800.dts file to dts-v1. Basically, this means
> > converting the numeric constants to be 'C'-like (e.g., hexadecimal
> > numbers start with '0x').
>
> [snip]
> > interrupt-parent = <&/mv64x60/pic>;
>
> If you're converting to dts-v1, you should also convert any path
> references like this to &{/mv64x60/pic} or else use a label. Yes,
> some early dts-v1 supporting dtc versions supported these as is, but
> the idea is to try to forget that they existed and always require the
> {} quoting in dts-v1.
I did convert to use labels in a later patch but it uses <&label> as
well. I can change them to &{label} that it appears you are suggesting
(I haven't tested to see that they work yet though).
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Raising list size limit
On Tue, Dec 18, 2007 at 10:12:08AM -0600, Olof Johansson wrote: > 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 <[EMAIL PROTECTED]> 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? dtc merge was 224k, if it had stayed together with the libfdt merge it would have been a about 300k. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
On Tue, Dec 18, 2007 at 02:35:06PM -0700, Mark A. Greer wrote:
> On Sat, Dec 15, 2007 at 09:03:35AM +1100, David Gibson wrote:
> > On Mon, Dec 10, 2007 at 05:37:38PM -0700, Mark A. Greer wrote:
> > > From: Mark A. Greer <[EMAIL PROTECTED]>
> > >
> > > Convert the prpmc2800.dts file to dts-v1. Basically, this means
> > > converting the numeric constants to be 'C'-like (e.g., hexadecimal
> > > numbers start with '0x').
> >
> > [snip]
> > > interrupt-parent = <&/mv64x60/pic>;
> >
> > If you're converting to dts-v1, you should also convert any path
> > references like this to &{/mv64x60/pic} or else use a label. Yes,
> > some early dts-v1 supporting dtc versions supported these as is, but
> > the idea is to try to forget that they existed and always require the
> > {} quoting in dts-v1.
>
> I did convert to use labels in a later patch but it uses <&label> as
> well. I can change them to &{label} that it appears you are suggesting
> (I haven't tested to see that they work yet though).
&label is fine, it's just &/full/path that needs changing.
I realised you removed all the &/full/path things in a later patch, so
the series as a whole will work. But this patch alleges to convert to
dts-v1 of itself, but because it fails to requote the path references,
it doesn't.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
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. Ah, good point. Ok, I withdraw my complaints. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Raising list size limit
On Tue, 18 Dec 2007 14:36:27 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > 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?). OK, this is done now. Do your worst :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpHlFL6Ctzkw.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Add missing copyright notice for dumptrees.c
When I released libfdt, I forgot to add a copyright notice to dumptrees.c (probably because the program is so trivial). Apparently the lack causes trouble for Debian, so this patch adds one. I've gone through the git history and double checked that no-one has touched this file except me (and I barely have myself since its initial commit). Signed-off-by: David Gibson <[EMAIL PROTECTED]> Index: dtc/tests/dumptrees.c === --- dtc.orig/tests/dumptrees.c 2007-12-19 10:58:28.0 +1100 +++ dtc/tests/dumptrees.c 2007-12-19 10:59:58.0 +1100 @@ -1,3 +1,24 @@ +/* + * dumptrees - utility for libfdt testing + * + * (C) Copyright David Gibson <[EMAIL PROTECTED]>, IBM Corporation. 2006. + * + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 + * USA + */ #include #include #include -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [POWERPC 00/18] cell patches for 2.6.25
On Tuesday 18 December 2007, [EMAIL PROTECTED] wrote: > 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 > As Michael just told me on IRC, he's still working on a newer version of patches 4-10. I consequently updated my git tree to only contain patches 1-3 and 11-18 of this series. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] ps3: vuart: fix error path locking
On Wed, 12 Dec 2007 18:00:12 -0800
Geoff Levand <[EMAIL PROTECTED]> wrote:
> > This stray down would cause a permanent sleep which doesn't seem correct.
> > The other uses of this semaphore appear fairly mutex like it's even
> > initialized
> > with init_MUTEX() .. So here a patch for removing this one down().
> >
> > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
> >
> > ---
> > drivers/ps3/ps3-vuart.c |1 -
> > 1 file changed, 1 deletion(-)
>
>
> Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
>
>
> Looks, good.
Looks bad to me.
> Andrew, Please apply.
The current code:
if (result) {
dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
__func__, __LINE__);
down(&vuart_bus_priv.probe_mutex);
goto fail_probe;
}
up(&vuart_bus_priv.probe_mutex);
return result;
fail_probe:
ps3_vuart_set_interrupt_mask(dev, 0);
kfree(dev->driver_priv);
dev->driver_priv = NULL;
fail_dev_malloc:
vuart_bus_priv.devices[dev->port_number] = NULL;
fail_busy:
ps3_vuart_bus_interrupt_put();
fail_setup_interrupt:
up(&vuart_bus_priv.probe_mutex);
dev_dbg(&dev->core, "%s:%d: failed\n", __func__, __LINE__);
return result;
}
is correct. Although not exactly a thing of beauty.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] ps3: vuart: fix error path locking
On Tue, 2007-12-18 at 17:10 -0800, Andrew Morton wrote: > is correct. Although not exactly a thing of beauty. This isn't the worst I've seen ;( .. Do you think the ending should fall through instead of having two returns? Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] ps3: vuart: fix error path locking
On 12/18/2007 05:10 PM, Andrew Morton wrote:
> On Wed, 12 Dec 2007 18:00:12 -0800
> Geoff Levand <[EMAIL PROTECTED]> wrote:
>
>> > This stray down would cause a permanent sleep which doesn't seem correct.
>> > The other uses of this semaphore appear fairly mutex like it's even
>> > initialized
>> > with init_MUTEX() .. So here a patch for removing this one down().
>> >
>> > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
>> >
>> > ---
>> > drivers/ps3/ps3-vuart.c |1 -
>> > 1 file changed, 1 deletion(-)
>>
>>
>> Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
>>
>>
>> Looks, good.
>
> Looks bad to me.
Hi Andrew,
Unfortunately there wasn't enough context in the patch to see
that there is a down() earlier in the routine, and that the patch
does indeed remove an incorrectly placed down(). Here is the
entire routine, marked with what the patch removes.
static int ps3_vuart_probe(struct ps3_system_bus_device *dev)
{
int result;
struct ps3_vuart_port_driver *drv;
struct ps3_vuart_port_priv *priv = NULL;
dev_dbg(&dev->core, "%s:%d\n", __func__, __LINE__);
drv = ps3_system_bus_dev_to_vuart_drv(dev);
dev_dbg(&dev->core, "%s:%d: (%s)\n", __func__, __LINE__,
drv->core.core.name);
BUG_ON(!drv);
if (dev->port_number >= PORT_COUNT) {
BUG();
return -EINVAL;
}
down(&vuart_bus_priv.probe_mutex);
result = ps3_vuart_bus_interrupt_get();
if (result)
goto fail_setup_interrupt;
if (vuart_bus_priv.devices[dev->port_number]) {
dev_dbg(&dev->core, "%s:%d: port busy (%d)\n", __func__,
__LINE__, dev->port_number);
result = -EBUSY;
goto fail_busy;
}
vuart_bus_priv.devices[dev->port_number] = dev;
/* Setup dev->driver_priv. */
dev->driver_priv = kzalloc(sizeof(struct ps3_vuart_port_priv),
GFP_KERNEL);
if (!dev->driver_priv) {
result = -ENOMEM;
goto fail_dev_malloc;
}
priv = to_port_priv(dev);
INIT_LIST_HEAD(&priv->tx_list.head);
spin_lock_init(&priv->tx_list.lock);
INIT_LIST_HEAD(&priv->rx_list.head);
spin_lock_init(&priv->rx_list.lock);
INIT_WORK(&priv->rx_list.work.work, NULL);
priv->rx_list.work.trigger = 0;
priv->rx_list.work.dev = dev;
/* clear stale pending interrupts */
ps3_vuart_clear_rx_bytes(dev, 0);
ps3_vuart_set_interrupt_mask(dev, INTERRUPT_MASK_RX);
ps3_vuart_set_triggers(dev, 1, 1);
if (drv->probe)
result = drv->probe(dev);
else {
result = 0;
dev_info(&dev->core, "%s:%d: no probe method\n", __func__,
__LINE__);
}
if (result) {
dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
__func__, __LINE__);
removed >> down(&vuart_bus_priv.probe_mutex); <<<
goto fail_probe;
}
up(&vuart_bus_priv.probe_mutex);
return result;
fail_probe:
ps3_vuart_set_interrupt_mask(dev, 0);
kfree(dev->driver_priv);
dev->driver_priv = NULL;
fail_dev_malloc:
vuart_bus_priv.devices[dev->port_number] = NULL;
fail_busy:
ps3_vuart_bus_interrupt_put();
fail_setup_interrupt:
up(&vuart_bus_priv.probe_mutex);
dev_dbg(&dev->core, "%s:%d: failed\n", __func__, __LINE__);
return result;
}
Thanks for taking the time to scrutinize.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Update TODO files
This patch makes a bunch of updates to the TODO files for dtc and libfdt, some of them rather overdue. Signed-off-by: David Gibson <[EMAIL PROTECTED]> Index: dtc/TODO === --- dtc.orig/TODO 2007-12-19 10:52:12.0 +1100 +++ dtc/TODO2007-12-19 15:50:22.0 +1100 @@ -1,14 +1,8 @@ - Bugfixes: * Proper handling of boot cpu information -- Error handling / reporting - * Better categorization of errors into severity levels - * Don't stop checking for later errors because of earlier ones - whenever possible - Generate mem reserve map * linux,reserve-map property * generating reserve entry for device tree itself * generating reserve entries from tce, rtas etc. properties - - -- Testsuite -- Actually number releases, all that kind of jazz +- Expression support +- Macro system Index: dtc/libfdt/TODO === --- dtc.orig/libfdt/TODO2007-12-19 10:52:12.0 +1100 +++ dtc/libfdt/TODO 2007-12-19 15:58:49.0 +1100 @@ -1,5 +1,3 @@ -- Find node by linux,phandle property - Tree traversal functions - Graft function -- Merge into dtc -- Make fdt_open_into() re-arrange properly +- Complete libfdt.h documenting comments -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
