* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01 1:48 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20080301001632.BA47B2476B@gemini.denx.de>
At 07:16 PM 2/29/2008, Wolfgang Denk wrote:
>In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
> >
> > I assumed that because I've always needed a debugger when
> > implementing kernel level components. Since you've implemented kernel
> > level support for several 44x processors, I just assumed that you
> > needed kdbg at some point. So you're saying that your additions
> > worked right out of the gate and you never needed a
> debugger? You're my hero!
>
>Many people working on this stuff use a BDI2000 / BDI3000. Makes life
>much easier...
Wolfgang, you hit the nail on the head. Trying to debug a target
without a JTAG debugger is a pain.
^ permalink raw reply
* [PATCH 3/3] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stefan Richter @ 2008-03-01 1:50 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ac97915a5b51e35b@s5r6.in-berlin.de>
Shut up two "may be used uninitialised in this function" warnings due to
PPC32's implementation of dma_alloc_coherent().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Wasn't there a macro somewhere for this?
Also, could this be better done in PPC32's dma_alloc_coherent()?
At least this kind of workaround here doesn't add anything to the
compiled result.
drivers/firewire/fw-ohci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -544,7 +544,7 @@ static int
context_add_buffer(struct context *ctx)
{
struct descriptor_buffer *desc;
- dma_addr_t bus_addr;
+ dma_addr_t bus_addr = bus_addr;
int offset;
/*
@@ -1334,7 +1334,7 @@ ohci_set_config_rom(struct fw_card *card
unsigned long flags;
int retval = -EBUSY;
__be32 *next_config_rom;
- dma_addr_t next_config_rom_bus;
+ dma_addr_t next_config_rom_bus = next_config_rom_bus;
ohci = fw_ohci(card);
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Stefan Richter @ 2008-03-01 2:04 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.7e8e04e66a38dcd6@s5r6.in-berlin.de>
I wrote:
> + struct device_node* ofn = pci_device_to_OF_node(dev);
-ECOPYANDWASTE: struct device_node *ofn
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Josh Boyer @ 2008-03-01 2:30 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <200803010023.m210NHwr011345@e2.ny.us.ibm.com>
On Fri, 29 Feb 2008 19:23:40 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
Putting the list back on CC because I'm sure you won't be the only
person to have this issue.
> poor man's debugging works fine if a serial port is available, but my
> Sequoia platform doesn't get that far! I use u-boot to download and
> boot my image, and I don't get any serial output after the boot completes:
By "poking characters out the serial port" I meant I literally coded up
assembly functions to setup MMU translations and poke hex values at hard
coded addresses. That's why it's "poor man's". If you had a working
serial port out of the box, that would be a luxury ;).
> => bootm 0x500000
> ## Booting image at 00500000 ...
> Image Name: Kernel and Ramdisk
> Created: 2008-03-01 0:09:57 UTC
> Image Type: PowerPC Linux Multi-File Image (gzip compressed)
> Data Size: 2430248 Bytes = 2.3 MB
> Load Address: 00000000
> Entry Point: 00000000
> Contents:
> Image 0: 1471523 Bytes = 1.4 MB
> Image 1: 958712 Bytes = 936.2 kB
> Verifying Checksum ... OK
> Uncompressing Multi-File Image ... OK
> Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
> ------
> console port is now dead.
> ------
What image type are you using? If this is an older U-Boot, you'll need
to use the cuImage.sequoia file that is produced when you compile your
kernel with 'make zImage'. Sequoia (and I'm assuming you mean the
AMCC Sequoia Eval Board, not some custom hardware that's based on it)
has been working fine for a long time.
It seems you have some kind of other uImage, so try using the one
that's built with the kernel and go from there.
josh
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Stephen Rothwell @ 2008-03-01 2:51 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <1204307236.10146.1.camel@dyn9047017100.beaverton.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Fri, 29 Feb 2008 09:47:16 -0800 Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> Here is the latest for review. (just to make sure I didn't miss
> anything).
Sorry I didn't review the previous ones ... just a small thing.
> + type = of_get_property(np, "device_type", NULL);
To use the of_ accessors, you need to include linux/of.h (currently
asm/prom.h include linux/of.h, but that may not always be true). In
fact, I think you don't even need asm/prom.h.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01 2:55 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080229203015.0ada459e@zod.rchland.ibm.com>
At 09:30 PM 2/29/2008, Josh Boyer wrote:
>On Fri, 29 Feb 2008 19:23:40 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
>Putting the list back on CC because I'm sure you won't be the only
>person to have this issue.
>
> > poor man's debugging works fine if a serial port is available, but my
> > Sequoia platform doesn't get that far! I use u-boot to download and
> > boot my image, and I don't get any serial output after the boot completes:
>
>By "poking characters out the serial port" I meant I literally coded up
>assembly functions to setup MMU translations and poke hex values at hard
>coded addresses. That's why it's "poor man's". If you had a working
>serial port out of the box, that would be a luxury ;).
>
> > => bootm 0x500000
> > ## Booting image at 00500000 ...
> > Image Name: Kernel and Ramdisk
> > Created: 2008-03-01 0:09:57 UTC
> > Image Type: PowerPC Linux Multi-File Image (gzip compressed)
> > Data Size: 2430248 Bytes = 2.3 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Contents:
> > Image 0: 1471523 Bytes = 1.4 MB
> > Image 1: 958712 Bytes = 936.2 kB
> > Verifying Checksum ... OK
> > Uncompressing Multi-File Image ... OK
> > Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
> > ------
> > console port is now dead.
> > ------
>
>What image type are you using? If this is an older U-Boot, you'll need
>to use the cuImage.sequoia file that is produced when you compile your
>kernel with 'make zImage'. Sequoia (and I'm assuming you mean the
>AMCC Sequoia Eval Board, not some custom hardware that's based on it)
>has been working fine for a long time.
>
>It seems you have some kind of other uImage, so try using the one
>that's built with the kernel and go from there.
>
>josh
thank you so much for your helpful reply. No, I don't have a serial
port that works "out of the box", and your hint of setting up the MMU
translations and poking characters at hard coded addresses, is a big help.
My hardware is NOT a Sequoia eval, it is a custom board derived from
the Sequoia platform back at 2.6.14. In a previous message when you
said that ECC should be handled by the NAND driver, I figured out
that our AMCC-440EPx board was not a standard Sequoia. Ours has DDR
ECC and the setup code writes to several registers to enable it. I
still offer this code to you.
I've used the zImage, the uImage, and the vmlinux image, all with the
same results. My last attempt was a uImage, so I'll switch to the
zImage and try again.
thanks so much for your help,
Steve
^ permalink raw reply
* Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Benjamin Herrenschmidt @ 2008-03-01 2:59 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <tkrat.7e8e04e66a38dcd6@s5r6.in-berlin.de>
> +#ifdef CONFIG_PPC_PMAC
> + /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
> + if (machine_is(powermac)) {
> + struct device_node *ofn = pci_device_to_OF_node(dev);
> +
> + if (ofn) {
> + pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
> + }
> + }
> +#endif /* CONFIG_PPC_PMAC */
I -think- that the hunk above can be removed if you just call
pci_enable_device(). I have a hook in the arch pcibios_enable_device()
that detects the internal firewire and does the calls. Can you verify it
works ?
> +#ifdef CONFIG_PPC_PMAC
> + /* On UniNorth, power down the cable and turn off the chip clock
> + * to save power on laptops */
> + if (machine_is(powermac)) {
> + struct device_node* ofn = pci_device_to_OF_node(dev);
> +
> + if (ofn) {
> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
> + pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
> + }
> + }
> +#endif /* CONFIG_PPC_PMAC */
Unfortunately, I don't have the pending hook here for disable so you
need to keep that one for now.
> kfree(&ohci->card);
>
> fw_notify("Removed fw-ohci device.\n");
> @@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
> if (err)
> fw_error("pci_set_power_state failed with %d\n", err);
>
> +/* PowerMac suspend code comes last */
> +#ifdef CONFIG_PPC_PMAC
> + if (machine_is(powermac)) {
> + struct device_node *ofn = pci_device_to_OF_node(pdev);
> +
> + if (ofn)
> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
> + }
> +#endif /* CONFIG_PPC_PMAC */
I wonder why we don't do the cable power thingy here...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Badari Pulavarty @ 2008-03-01 3:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080301135123.262bfdb0.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Fri, 29 Feb 2008 09:47:16 -0800 Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
>> Here is the latest for review. (just to make sure I didn't miss
>> anything).
>>
>
> Sorry I didn't review the previous ones ... just a small thing.
>
>
>> + type = of_get_property(np, "device_type", NULL);
>>
>
> To use the of_ accessors, you need to include linux/of.h (currently
> asm/prom.h include linux/of.h, but that may not always be true). In
> fact, I think you don't even need asm/prom.h.
>
>
Yes. linux/of.h is enough. Thank you for pointing it out.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Benjamin Herrenschmidt @ 2008-03-01 3:04 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, paulus, LKML
In-Reply-To: <1204301097.14759.6.camel@localhost.localdomain>
On Fri, 2008-02-29 at 11:04 -0500, Steven Rostedt wrote:
> strncmp is defined in assembly for bootup, but it is not defined in the
> normal running kernel. This patch takes the strncmp code from the bootup
> and copies it to the kernel proper.
>
> Signed-off-by: Steven Rostedt <srostedt@redhat.com>
> ---
Do we have any indication that it performs better than the C one ?
Ben.
> arch/powerpc/kernel/ppc_ksyms.c | 1 +
> arch/powerpc/lib/string.S | 12 ++++++++++++
> include/asm-powerpc/string.h | 2 ++
> 3 files changed, 15 insertions(+)
>
> Index: linux-sched-devel.git/arch/powerpc/kernel/ppc_ksyms.c
> ===================================================================
> --- linux-sched-devel.git.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-02-27 14:01:38.000000000 -0800
> +++ linux-sched-devel.git/arch/powerpc/kernel/ppc_ksyms.c 2008-02-29 07:24:22.000000000 -0800
> @@ -78,6 +78,7 @@ EXPORT_SYMBOL(strncpy);
> EXPORT_SYMBOL(strcat);
> EXPORT_SYMBOL(strlen);
> EXPORT_SYMBOL(strcmp);
> +EXPORT_SYMBOL(strncmp);
>
> EXPORT_SYMBOL(csum_partial);
> EXPORT_SYMBOL(csum_partial_copy_generic);
> Index: linux-sched-devel.git/arch/powerpc/lib/string.S
> ===================================================================
> --- linux-sched-devel.git.orig/arch/powerpc/lib/string.S 2008-02-27 14:01:38.000000000 -0800
> +++ linux-sched-devel.git/arch/powerpc/lib/string.S 2008-02-29 07:24:22.000000000 -0800
> @@ -75,6 +75,18 @@ _GLOBAL(strcmp)
> beq 1b
> blr
>
> +_GLOBAL(strncmp)
> + mtctr r5
> + addi r5,r3,-1
> + addi r4,r4,-1
> +1: lbzu r3,1(r5)
> + cmpwi 1,r3,0
> + lbzu r0,1(r4)
> + subf. r3,r0,r3
> + beqlr 1
> + bdnzt eq,1b
> + blr
> +
> _GLOBAL(strlen)
> addi r4,r3,-1
> 1: lbzu r0,1(r4)
> Index: linux-sched-devel.git/include/asm-powerpc/string.h
> ===================================================================
> --- linux-sched-devel.git.orig/include/asm-powerpc/string.h 2008-02-27 14:01:58.000000000 -0800
> +++ linux-sched-devel.git/include/asm-powerpc/string.h 2008-02-29 07:24:22.000000000 -0800
> @@ -7,6 +7,7 @@
> #define __HAVE_ARCH_STRNCPY
> #define __HAVE_ARCH_STRLEN
> #define __HAVE_ARCH_STRCMP
> +#define __HAVE_ARCH_STRNCMP
> #define __HAVE_ARCH_STRCAT
> #define __HAVE_ARCH_MEMSET
> #define __HAVE_ARCH_MEMCPY
> @@ -18,6 +19,7 @@ extern char * strcpy(char *,const char *
> extern char * strncpy(char *,const char *, __kernel_size_t);
> extern __kernel_size_t strlen(const char *);
> extern int strcmp(const char *,const char *);
> +extern int strncmp(const char *,const char *,__kernel_size_t);
> extern char * strcat(char *, const char *);
> extern void * memset(void *,int,__kernel_size_t);
> extern void * memcpy(void *,const void *,__kernel_size_t);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] updating lmb.memory information for hot mem add/remove
From: Badari Pulavarty @ 2008-03-01 3:06 UTC (permalink / raw)
To: David Miller; +Cc: paulus, anton, ntl, linuxppc-dev
In-Reply-To: <20080229.174434.216640668.davem@davemloft.net>
David Miller wrote:
> From: Badari Pulavarty <pbadari@us.ibm.com>
> Date: Fri, 29 Feb 2008 17:12:44 -0800
>
>
>> Here is what I cooked up and it seems to work fine.
>> It may be easier to review the code (against my earlier patches).
>>
>
> BTW, the lmb code now lives under lib/ (sparc64 will be using it too)
> and has several bug fixes applied to it in Paulus's current upstream
> tree.
>
Yes. I noticed that earlier. But it was easy for me to test against
mainline/-mm.
I can easily update it against Paul's tree, if every one is okay with
the changes
I am proposing.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 3/3] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stephen Rothwell @ 2008-03-01 3:17 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <tkrat.ee238048a5a50184@s5r6.in-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
On Sat, 1 Mar 2008 02:50:44 +0100 (CET) Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> Shut up two "may be used uninitialised in this function" warnings due to
> PPC32's implementation of dma_alloc_coherent().
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
>
> Wasn't there a macro somewhere for this?
Yes, uninitialized_var() in linux/compiler*.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Steven Rostedt @ 2008-03-01 3:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, LKML
In-Reply-To: <1204340690.15052.457.camel@pasglop>
On Sat, 1 Mar 2008, Benjamin Herrenschmidt wrote:
>
> Do we have any indication that it performs better than the C one ?
See below.
>
> Ben.
>
> >
> > +_GLOBAL(strncmp)
> > + mtctr r5
> > + addi r5,r3,-1
> > + addi r4,r4,-1
> > +1: lbzu r3,1(r5)
> > + cmpwi 1,r3,0
> > + lbzu r0,1(r4)
> > + subf. r3,r0,r3
> > + beqlr 1
> > + bdnzt eq,1b
> > + blr
> > +
And here's the objdump of the C version:
0000000000000080 <.strncmp>:
80: fb e1 ff f0 std r31,-16(r1)
84: f8 21 ff c1 stdu r1,-64(r1)
88: 7c 69 1b 78 mr r9,r3
8c: 7c a0 2b 79 mr. r0,r5
90: 38 60 00 00 li r3,0
94: 7c 09 03 a6 mtctr r0
98: 7c 3f 0b 78 mr r31,r1
9c: 41 82 00 68 beq- 104 <.strncmp+0x84>
a0: 89 69 00 00 lbz r11,0(r9)
a4: 88 04 00 00 lbz r0,0(r4)
a8: 7c 00 58 50 subf r0,r0,r11
ac: 78 00 06 20 clrldi r0,r0,56
b0: 2f a0 00 00 cmpdi cr7,r0,0
b4: 7c 00 07 74 extsb r0,r0
b8: 7c 03 03 78 mr r3,r0
bc: 40 9e 00 48 bne- cr7,104 <.strncmp+0x84>
c0: 2f ab 00 00 cmpdi cr7,r11,0
c4: 41 9e 00 40 beq- cr7,104 <.strncmp+0x84>
c8: 38 84 00 01 addi r4,r4,1
cc: 38 69 00 01 addi r3,r9,1
d0: 42 40 00 30 bdz- 100 <.strncmp+0x80>
d4: 88 03 00 00 lbz r0,0(r3)
d8: 89 24 00 00 lbz r9,0(r4)
dc: 38 63 00 01 addi r3,r3,1
e0: 38 84 00 01 addi r4,r4,1
e4: 2f 20 00 00 cmpdi cr6,r0,0
e8: 7c 09 00 50 subf r0,r9,r0
ec: 78 00 06 20 clrldi r0,r0,56
f0: 2f a0 00 00 cmpdi cr7,r0,0
f4: 7c 00 07 74 extsb r0,r0
f8: 40 9e 00 08 bne- cr7,100 <.strncmp+0x80>
fc: 40 9a ff d4 bne+ cr6,d0 <.strncmp+0x50>
100: 7c 03 03 78 mr r3,r0
104: e8 21 00 00 ld r1,0(r1)
108: eb e1 ff f0 ld r31,-16(r1)
10c: 4e 80 00 20 blr
I'll let you decide ;-)
Even if it was logically faster (which I still doubt) it's a hell of a lot
of cache lines to waste.
-- Steve
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Olof Johansson @ 2008-03-01 5:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: Steve Heflin, linuxppc-embedded
In-Reply-To: <20080229203015.0ada459e@zod.rchland.ibm.com>
On Fri, Feb 29, 2008 at 08:30:15PM -0600, Josh Boyer wrote:
> > poor man's debugging works fine if a serial port is available, but my
> > Sequoia platform doesn't get that far! I use u-boot to download and
> > boot my image, and I don't get any serial output after the boot completes:
>
> By "poking characters out the serial port" I meant I literally coded up
> assembly functions to setup MMU translations and poke hex values at hard
> coded addresses. That's why it's "poor man's". If you had a working
> serial port out of the box, that would be a luxury ;).
Does 4xx have support for udbg and xmon? That would be a good first step
in getting an in-kernel debugger facility going.
-Olof
^ permalink raw reply
* Re: [PATCH 0/2] firewire: endinaness warnings (was Re: sparse - make __CHECK_ENDIAN__ default enabled?)
From: Jarod Wilson @ 2008-03-01 5:23 UTC (permalink / raw)
To: Stefan Richter
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <tkrat.e2bfb30f2c0ae70a@s5r6.in-berlin.de>
On Saturday 23 February 2008 06:23:30 am Stefan Richter wrote:
> On 20 Feb, Harvey Harrison wrote on LKML:
> > On Wed, 2008-02-20 at 23:03 +0100, Sam Ravnborg wrote:
> >> Hi Harvey.
> >>
> >> Can I ask you to look into the worst offenders so we
> >> can make -D__CHECK_ENDIAN__ enabled per default
> >> in the kernel.
> >> Or maybe we should do it anyway?
> >
> > Well, I've got the worst of fs and drivers/ata done so far, still
> > weeping over the 5500 warnings in drivers. (X86_32 allyesconfig).
> > People ignore the existing warnings anyway, why not toss a few more
> > on the pile?
> >
> > I'll look them over tonight and see how bad it would be.
>
> I looked into drivers/firewire and drivers/ieee1394. As expected, there
> are quite a lot endianess related warnings in the latter because this is
> code from way before sparse was regularly used.
>
> There are also a few warnings in the former, even though sparse checks
> were run before submission of the whole drivers/firewire stack. I will
> follow up with two patches:
> 1/2 firewire: endianess fix
> 2/2 firewire: endianess annotations
> Whether the "fix" is really a fix remains to be seen; I don't have a big
> endian Linux box myself.
Doesn't hurt anything on my end, spb2 devices work, they survive bus resets
and so on. The funky uninorth controller definitely doesn't work, but it
didn't before the patch either, and the fix is being chased in another patch
series.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
--
Jarod Wilson
jwilson@redhat.com
^ permalink raw reply
* Re: [PATCH 0/4] Add Emerson KSI8560 board support
From: Paul Mackerras @ 2008-03-01 7:51 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080229171114.GA14325@ru.mvista.com>
Alexandr Smirnov writes:
> I've fixed the code according to your comments.
None of the patches you sent have any patch description or commentary,
and that's not good enough. Yes, it all might be completely clear and
obvious in your head as to what the KSI8560 is and why you have made
the various design decisions you have, but it isn't necessarily
obvious to other people, and you yourself probably won't remember in
two years' time. So write a paragraph or two for each patch telling
us those sort of things.
I concede that patches that just add a defconfig or a dts often don't
need much of a description, although even then there may be choices
made where you could usefully give us a rationale in the patch
description.
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Stefan Richter @ 2008-03-01 8:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <1204340392.15052.455.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> +#ifdef CONFIG_PPC_PMAC
>> + /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
>> + if (machine_is(powermac)) {
>> + struct device_node *ofn = pci_device_to_OF_node(dev);
>> +
>> + if (ofn) {
>> + pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
>> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
>> + }
>> + }
>> +#endif /* CONFIG_PPC_PMAC */
>
> I -think- that the hunk above can be removed if you just call
> pci_enable_device(). I have a hook in the arch pcibios_enable_device()
> that detects the internal firewire and does the calls. Can you verify it
> works ?
The first test I did was
# modprobe ohci1394 # this has the same four feature call blocks
# modprobe -r ohci1394
# modprobe firewire-ohci
<boom>
Tried the same now again (actually modprobe -r firewire-ohci (patched);
modprobe firewire-ohci (unpatched)):
Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PowerMac
Modules linked in: firewire_ohci(+) firewire_core crc_itu_t af_packet
apm_emu apm_emulation usbhid sungem sungem_phy yenta_socket
rsrc_nonstatic ohci_hcd pcmcia_core usbcore ide_cd_mod cdrom evdev [last
unloaded: crc_itu_t]
NIP: e18ee3dc LR: e18ee32c CTR: c0065178
REGS: d7c01c40 TRAP: 0200 Not tainted (2.6.25-rc3)
MSR: 00049030 <EE,ME,IR,DR> CR: 84004428 XER: 00000000
TASK = dedae6d0[5376] 'modprobe' THREAD: d7c00000
GPR00: e18e61c0 d7c01cf0 dedae6d0 defcf000 00000000 00000385 c06c09f8
00001000
GPR08: ffffec0f 00000000 e18e6000 dfafd000 24004428 1001e354 00000000
00000000
GPR16: 0000007a 0000007a 00000000 e18e9bf4 00000124 00000000 e18e6000
c0050280
GPR24: 00000019 e18e9cc4 c0290630 dfb61420 df85b800 dfafdcf8 00000000
dfafdcf8
NIP [e18ee3dc] ar_context_add_page+0xd0/0xf4 [firewire_ohci]
LR [e18ee32c] ar_context_add_page+0x20/0xf4 [firewire_ohci]
Call Trace:
[d7c01cf0] [e18ee32c] ar_context_add_page+0x20/0xf4 [firewire_ohci]
(unreliable)
[d7c01d00] [e18ee440] ar_context_init+0x40/0x70 [firewire_ohci]
[d7c01d50] [e18f0004] pci_probe+0x118/0x70c [firewire_ohci]
[d7c01d70] [c010e0ac] pci_device_probe+0x80/0xa0
[d7c01d90] [c0146230] driver_probe_device+0xb8/0x1cc
[d7c01db0] [c0146528] __driver_attach+0xd4/0x104
[d7c01dd0] [c0144d78] bus_for_each_dev+0x58/0x94
[d7c01e00] [c0145f60] driver_attach+0x24/0x34
[d7c01e10] [c0145d48] bus_add_driver+0xb0/0x250
[d7c01e30] [c0146a18] driver_register+0x48/0x130
[d7c01e50] [c010dcb0] __pci_register_driver+0x48/0x94
[d7c01e70] [e101e028] fw_ohci_init+0x28/0x48 [firewire_ohci]
[d7c01e80] [c00516e8] sys_init_module+0xd4/0x1754
[d7c01f40] [c0013d98] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff7325c
LR = 0x10003b50
Instruction dump:
90690010 817f0000 907f0008 814b04b4 813f0010 7c0a4a14 7c0004ac 7ce0052c
817f0000 812b04b4 7c0004ac 7d204c2c <0c090000> 4c00012c 38000000 7c030378
---[ end trace a3cf91a5f7d45355 ]---
BTW, ohci1394 had traditionally only 3 of the blocks; I added the block
by commit 48cfae44b4d6c7ca843d611a93ed2f94b59bcb38 in November 2006.
This fixed http://bugzilla.kernel.org/show_bug.cgi?id=7431 .
[...]
>> @@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
>> if (err)
>> fw_error("pci_set_power_state failed with %d\n", err);
>>
>> +/* PowerMac suspend code comes last */
>> +#ifdef CONFIG_PPC_PMAC
>> + if (machine_is(powermac)) {
>> + struct device_node *ofn = pci_device_to_OF_node(pdev);
>> +
>> + if (ofn)
>> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
>> + }
>> +#endif /* CONFIG_PPC_PMAC */
>
> I wonder why we don't do the cable power thingy here...
I don't know.
I tested with a bus powered device now. Actually, suspend to RAM
switches off cable power nevertheless, but resume does not switch it on
anymore...
Of course the same is true with ohci1394. Why did nobody ever complain?
I suppose the last two users of FireWire + Linux + UniNorth rev01 don't
use cable power or don't suspend and resume.
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 3/3] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stefan Richter @ 2008-03-01 8:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <20080301141741.172013ba.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Sat, 1 Mar 2008 02:50:44 +0100 (CET) Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Wasn't there a macro somewhere for this?
>
> Yes, uninitialized_var() in linux/compiler*.h
Right. I actually did look into compiler.h and compiler-gcc.h but
somehow didn't make it down into -gcc?.h. Thanks,
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [dtc] breaking out libfdt from dtc so other progs can use it
From: Fathi Boudra @ 2008-03-01 9:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, David Gibson
In-Reply-To: <Pine.LNX.4.64.0802290930020.25557@vixen.sonytel.be>
> I think people are confusing source and binary packages.
>
> E.g. on Debian, the openssl source package is used to build 3 binary
> packages: openssl, libssl0.9.8, and libssl-dev. Hence to install
> applications that use libssl, you don't have to install all 3, just
> libssl0.9.8.
That make sense.
Just ask downstream (distros) to ship libfdt binaries packages.
cheers,
Fathi
^ permalink raw reply
* [PATCH 3/3 update] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stefan Richter @ 2008-03-01 11:21 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel, Stephen Rothwell
In-Reply-To: <47C90F83.3030700@s5r6.in-berlin.de>
Shut up two "may be used uninitialised in this function" warnings due to
PPC32's implementation of dma_alloc_coherent().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/fw-ohci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -544,7 +544,7 @@ static int
context_add_buffer(struct context *ctx)
{
struct descriptor_buffer *desc;
- dma_addr_t bus_addr;
+ dma_addr_t uninitialized_var(bus_addr);
int offset;
/*
@@ -1334,7 +1334,7 @@ ohci_set_config_rom(struct fw_card *card
unsigned long flags;
int retval = -EBUSY;
__be32 *next_config_rom;
- dma_addr_t next_config_rom_bus;
+ dma_addr_t uninitialized_var(next_config_rom_bus);
ohci = fw_ohci(card);
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] [POWERPC] 40X: Add Default Restart Machdep Method to 40X Platforms
From: Stefan Roese @ 2008-03-01 11:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Grant Erickson
In-Reply-To: <C3E49AAC.D8E4%erick205@umn.edu>
On Saturday 23 February 2008, Grant Erickson wrote:
> This patch restores the reset on restart functionality to 40x-based
> platforms that was formerly provided--but not used in arch/powerpc--by
> abort() in head_40x.S. This functionality is now provided by
> ppc40x_reset_system(char *) in a fashion similar to that of the 44x-based
> platforms.
>
> Compiled, linked and tested against the AMCC Haleakala board.
Instead of duplicating this code in platform/40x/ which is already present in
platforms/44x/misc_44x.S, why not move this misc_44x.S code into a common
place for all 4xx (40x and 44x) PPC's? There seems to be nothing 44x
specific.
I suggest to introduce platforms/4xx/misc.S or sysdev/ppc4xx_misc.S with these
functions and change the code referencing it accordingly.
Comments/thoughts?
Best regards,
Stefan
^ permalink raw reply
* [PATCH 0/4] firewire, ieee1394: bus power lost after resume (PPC PMac)
From: Stefan Richter @ 2008-03-01 11:33 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <47C90E81.7050603@s5r6.in-berlin.de>
I wrote:
> Benjamin Herrenschmidt wrote:
> [...]
>>> @@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
>>> if (err)
>>> fw_error("pci_set_power_state failed with %d\n", err);
>>>
>>> +/* PowerMac suspend code comes last */
>>> +#ifdef CONFIG_PPC_PMAC
>>> + if (machine_is(powermac)) {
>>> + struct device_node *ofn = pci_device_to_OF_node(pdev);
>>> +
>>> + if (ofn)
>>> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
>>> + }
>>> +#endif /* CONFIG_PPC_PMAC */
>>
>> I wonder why we don't do the cable power thingy here...
>
> I don't know.
>
> I tested with a bus powered device now. Actually, suspend to RAM
> switches off cable power nevertheless, but resume does not switch it on
> anymore...
>
> Of course the same is true with ohci1394. Why did nobody ever complain?
> I suppose the last two users of FireWire + Linux + UniNorth rev01 don't
> use cable power or don't suspend and resume.
At least this is what the 1st generation PowerBook G4 does. I don't
know if other PPC_PMAC are affected.
I suggest we explicitly switch cable power on in .resume() but also
explicitly switch cable power off in .suspend(), so that we don't get
any surprises. (Hardware bugs related to these platform features
excepted.) Patches follow:
1/4 firewire: fw-ohci: switch on bus power after resume on PPC PMac
2/4 firewire: fw-ohci: refactor probe, remove, suspend, resume
3/4 ieee1394: ohci1394: switch on bus power after resume on PPC PMac
4/4 ieee1394: ohci1394: refactor probe, remove, suspend, resume
drivers/firewire/fw-ohci.c | 96 +++++++++++++------------------
drivers/ieee1394/ohci1394.c | 109 ++++++++++++++++--------------------
2 files changed, 91 insertions(+), 114 deletions(-)
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 2/4] firewire: fw-ohci: refactor probe, remove, suspend, resume
From: Stefan Richter @ 2008-03-01 11:35 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ffa17a046c55daa9@s5r6.in-berlin.de>
Clean up shared code and variable names.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/fw-ohci.c | 100 ++++++++++++++++++---------------------------
1 file changed, 42 insertions(+), 58 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -2061,17 +2061,9 @@ static const struct fw_card_driver ohci_
.stop_iso = ohci_stop_iso,
};
-static int __devinit
-pci_probe(struct pci_dev *dev, const struct pci_device_id *ent)
-{
- struct fw_ohci *ohci;
- u32 bus_options, max_receive, link_speed;
- u64 guid;
- int err;
- size_t size;
-
#ifdef CONFIG_PPC_PMAC
- /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
+static void ohci_pmac_on(struct pci_dev *dev)
+{
if (machine_is(powermac)) {
struct device_node *ofn = pci_device_to_OF_node(dev);
@@ -2080,8 +2072,35 @@ pci_probe(struct pci_dev *dev, const str
pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
}
}
+}
+
+static void ohci_pmac_off(struct pci_dev *dev)
+{
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(dev);
+
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
+ }
+ }
+}
+#else
+#define ohci_pmac_on(dev)
+#define ohci_pmac_off(dev)
#endif /* CONFIG_PPC_PMAC */
+static int __devinit
+pci_probe(struct pci_dev *dev, const struct pci_device_id *ent)
+{
+ struct fw_ohci *ohci;
+ u32 bus_options, max_receive, link_speed;
+ u64 guid;
+ int err;
+ size_t size;
+
+ ohci_pmac_on(dev);
+
ohci = kzalloc(sizeof(*ohci), GFP_KERNEL);
if (ohci == NULL) {
fw_error("Could not malloc fw_ohci data.\n");
@@ -2218,77 +2237,42 @@ static void pci_remove(struct pci_dev *d
pci_iounmap(dev, ohci->registers);
pci_release_region(dev, 0);
pci_disable_device(dev);
-
-#ifdef CONFIG_PPC_PMAC
- /* On UniNorth, power down the cable and turn off the chip clock
- * to save power on laptops */
- if (machine_is(powermac)) {
- struct device_node *ofn = pci_device_to_OF_node(dev);
-
- if (ofn) {
- pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
- pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
- }
- }
-#endif /* CONFIG_PPC_PMAC */
-
+ ohci_pmac_off(dev);
kfree(&ohci->card);
fw_notify("Removed fw-ohci device.\n");
}
#ifdef CONFIG_PM
-static int pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int pci_suspend(struct pci_dev *dev, pm_message_t state)
{
- struct fw_ohci *ohci = pci_get_drvdata(pdev);
+ struct fw_ohci *ohci = pci_get_drvdata(dev);
int err;
software_reset(ohci);
- free_irq(pdev->irq, ohci);
- err = pci_save_state(pdev);
+ free_irq(dev->irq, ohci);
+ err = pci_save_state(dev);
if (err) {
fw_error("pci_save_state failed\n");
return err;
}
- err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ err = pci_set_power_state(dev, pci_choose_state(dev, state));
if (err)
fw_error("pci_set_power_state failed with %d\n", err);
-
-/* PowerMac suspend code comes last */
-#ifdef CONFIG_PPC_PMAC
- if (machine_is(powermac)) {
- struct device_node *ofn = pci_device_to_OF_node(pdev);
-
- if (ofn) {
- pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
- pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
- }
- }
-#endif /* CONFIG_PPC_PMAC */
+ ohci_pmac_off(dev);
return 0;
}
-static int pci_resume(struct pci_dev *pdev)
+static int pci_resume(struct pci_dev *dev)
{
- struct fw_ohci *ohci = pci_get_drvdata(pdev);
+ struct fw_ohci *ohci = pci_get_drvdata(dev);
int err;
-/* PowerMac resume code comes first */
-#ifdef CONFIG_PPC_PMAC
- if (machine_is(powermac)) {
- struct device_node *ofn = pci_device_to_OF_node(pdev);
-
- if (ofn) {
- pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
- pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
- }
- }
-#endif /* CONFIG_PPC_PMAC */
-
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- err = pci_enable_device(pdev);
+ ohci_pmac_on(dev);
+ pci_set_power_state(dev, PCI_D0);
+ pci_restore_state(dev);
+ err = pci_enable_device(dev);
if (err) {
fw_error("pci_enable_device failed\n");
return err;
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 1/4] firewire: fw-ohci: switch on bus power after resume on PPC PMac
From: Stefan Richter @ 2008-03-01 11:34 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.bc4ca3408428a60b@s5r6.in-berlin.de>
The platform feature calls in the suspend method switched off cable
power, but the calls in the resume method did not switch it back on.
Add the necessary feature call to .resume. Also add the corresponding
call to .suspend to make .suspend's behavior explicitly the same on all
PMacs.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/fw-ohci.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -2259,8 +2259,10 @@ static int pci_suspend(struct pci_dev *p
if (machine_is(powermac)) {
struct device_node *ofn = pci_device_to_OF_node(pdev);
- if (ofn)
+ if (ofn) {
pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
+ }
}
#endif /* CONFIG_PPC_PMAC */
@@ -2277,8 +2279,10 @@ static int pci_resume(struct pci_dev *pd
if (machine_is(powermac)) {
struct device_node *ofn = pci_device_to_OF_node(pdev);
- if (ofn)
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+ }
}
#endif /* CONFIG_PPC_PMAC */
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 3/4] ieee1394: ohci1394: switch on bus power after resume on PPC PMac
From: Stefan Richter @ 2008-03-01 11:36 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ff90a1c61d90de61@s5r6.in-berlin.de>
The platform feature calls in the suspend method switched off cable
power, but the calls in the resume method did not switch it back on.
Add the necessary feature call to .resume. Also add the corresponding
call to .suspend to make .suspend's behavior explicitly the same on all
PMacs.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/ohci1394.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: linux/drivers/ieee1394/ohci1394.c
===================================================================
--- linux.orig/drivers/ieee1394/ohci1394.c
+++ linux/drivers/ieee1394/ohci1394.c
@@ -3340,8 +3340,10 @@ static int ohci1394_pci_suspend(struct p
if (machine_is(powermac)) {
struct device_node *ofn = pci_device_to_OF_node(pdev);
- if (ofn)
+ if (ofn) {
pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
+ }
}
#endif /* CONFIG_PPC_PMAC */
@@ -3365,8 +3367,10 @@ static int ohci1394_pci_resume(struct pc
if (machine_is(powermac)) {
struct device_node *ofn = pci_device_to_OF_node(pdev);
- if (ofn)
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+ }
}
#endif /* CONFIG_PPC_PMAC */
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 4/4] ieee1394: ohci1394: refactor probe, remove, suspend, resume
From: Stefan Richter @ 2008-03-01 11:36 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.cc6eff0684655cd0@s5r6.in-berlin.de>
Clean up shared code and variable names.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/ieee1394/ohci1394.c | 113 +++++++++++++++++++-------------------------
1 file changed, 49 insertions(+), 64 deletions(-)
Index: linux/drivers/ieee1394/ohci1394.c
===================================================================
--- linux.orig/drivers/ieee1394/ohci1394.c
+++ linux/drivers/ieee1394/ohci1394.c
@@ -2993,15 +2993,9 @@ do { \
return err; \
} while (0)
-static int __devinit ohci1394_pci_probe(struct pci_dev *dev,
- const struct pci_device_id *ent)
-{
- struct hpsb_host *host;
- struct ti_ohci *ohci; /* shortcut to currently handled device */
- resource_size_t ohci_base;
-
#ifdef CONFIG_PPC_PMAC
- /* Necessary on some machines if ohci1394 was loaded/ unloaded before */
+static void ohci1394_pmac_on(struct pci_dev *dev)
+{
if (machine_is(powermac)) {
struct device_node *ofn = pci_device_to_OF_node(dev);
@@ -3010,8 +3004,32 @@ static int __devinit ohci1394_pci_probe(
pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
}
}
+}
+
+static void ohci1394_pmac_off(struct pci_dev *dev)
+{
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(dev);
+
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
+ }
+ }
+}
+#else
+#define ohci1394_pmac_on(dev)
+#define ohci1394_pmac_off(dev)
#endif /* CONFIG_PPC_PMAC */
+static int __devinit ohci1394_pci_probe(struct pci_dev *dev,
+ const struct pci_device_id *ent)
+{
+ struct hpsb_host *host;
+ struct ti_ohci *ohci; /* shortcut to currently handled device */
+ resource_size_t ohci_base;
+
+ ohci1394_pmac_on(dev);
if (pci_enable_device(dev))
FAIL(-ENXIO, "Failed to enable OHCI hardware");
pci_set_master(dev);
@@ -3203,16 +3221,16 @@ static int __devinit ohci1394_pci_probe(
#undef FAIL
}
-static void ohci1394_pci_remove(struct pci_dev *pdev)
+static void ohci1394_pci_remove(struct pci_dev *dev)
{
struct ti_ohci *ohci;
- struct device *dev;
+ struct device *device;
- ohci = pci_get_drvdata(pdev);
+ ohci = pci_get_drvdata(dev);
if (!ohci)
return;
- dev = get_device(&ohci->host->device);
+ device = get_device(&ohci->host->device);
switch (ohci->init_state) {
case OHCI_INIT_DONE:
@@ -3246,7 +3264,7 @@ static void ohci1394_pci_remove(struct p
/* Soft reset before we start - this disables
* interrupts and clears linkEnable and LPS. */
ohci_soft_reset(ohci);
- free_irq(ohci->dev->irq, ohci);
+ free_irq(dev->irq, ohci);
case OHCI_INIT_HAVE_TXRX_BUFFERS__MAYBE:
/* The ohci_soft_reset() stops all DMA contexts, so we
@@ -3257,12 +3275,12 @@ static void ohci1394_pci_remove(struct p
free_dma_trm_ctx(&ohci->at_resp_context);
case OHCI_INIT_HAVE_SELFID_BUFFER:
- pci_free_consistent(ohci->dev, OHCI1394_SI_DMA_BUF_SIZE,
+ pci_free_consistent(dev, OHCI1394_SI_DMA_BUF_SIZE,
ohci->selfid_buf_cpu,
ohci->selfid_buf_bus);
case OHCI_INIT_HAVE_CONFIG_ROM_BUFFER:
- pci_free_consistent(ohci->dev, OHCI_CONFIG_ROM_LEN,
+ pci_free_consistent(dev, OHCI_CONFIG_ROM_LEN,
ohci->csr_config_rom_cpu,
ohci->csr_config_rom_bus);
@@ -3270,35 +3288,24 @@ static void ohci1394_pci_remove(struct p
iounmap(ohci->registers);
case OHCI_INIT_HAVE_MEM_REGION:
- release_mem_region(pci_resource_start(ohci->dev, 0),
+ release_mem_region(pci_resource_start(dev, 0),
OHCI1394_REGISTER_SIZE);
-#ifdef CONFIG_PPC_PMAC
- /* On UniNorth, power down the cable and turn off the chip clock
- * to save power on laptops */
- if (machine_is(powermac)) {
- struct device_node* ofn = pci_device_to_OF_node(ohci->dev);
-
- if (ofn) {
- pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
- pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
- }
- }
-#endif /* CONFIG_PPC_PMAC */
+ ohci1394_pmac_off(dev);
case OHCI_INIT_ALLOC_HOST:
- pci_set_drvdata(ohci->dev, NULL);
+ pci_set_drvdata(dev, NULL);
}
- if (dev)
- put_device(dev);
+ if (device)
+ put_device(device);
}
#ifdef CONFIG_PM
-static int ohci1394_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int ohci1394_pci_suspend(struct pci_dev *dev, pm_message_t state)
{
int err;
- struct ti_ohci *ohci = pci_get_drvdata(pdev);
+ struct ti_ohci *ohci = pci_get_drvdata(dev);
if (!ohci) {
printk(KERN_ERR "%s: tried to suspend nonexisting host\n",
@@ -3326,34 +3333,23 @@ static int ohci1394_pci_suspend(struct p
ohci_devctl(ohci->host, RESET_BUS, LONG_RESET_NO_FORCE_ROOT);
ohci_soft_reset(ohci);
- err = pci_save_state(pdev);
+ err = pci_save_state(dev);
if (err) {
PRINT(KERN_ERR, "pci_save_state failed with %d", err);
return err;
}
- err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ err = pci_set_power_state(dev, pci_choose_state(dev, state));
if (err)
DBGMSG("pci_set_power_state failed with %d", err);
-
-/* PowerMac suspend code comes last */
-#ifdef CONFIG_PPC_PMAC
- if (machine_is(powermac)) {
- struct device_node *ofn = pci_device_to_OF_node(pdev);
-
- if (ofn) {
- pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
- pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
- }
- }
-#endif /* CONFIG_PPC_PMAC */
+ ohci1394_pmac_off(dev);
return 0;
}
-static int ohci1394_pci_resume(struct pci_dev *pdev)
+static int ohci1394_pci_resume(struct pci_dev *dev)
{
int err;
- struct ti_ohci *ohci = pci_get_drvdata(pdev);
+ struct ti_ohci *ohci = pci_get_drvdata(dev);
if (!ohci) {
printk(KERN_ERR "%s: tried to resume nonexisting host\n",
@@ -3362,21 +3358,10 @@ static int ohci1394_pci_resume(struct pc
}
DBGMSG("resume called");
-/* PowerMac resume code comes first */
-#ifdef CONFIG_PPC_PMAC
- if (machine_is(powermac)) {
- struct device_node *ofn = pci_device_to_OF_node(pdev);
-
- if (ofn) {
- pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
- pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
- }
- }
-#endif /* CONFIG_PPC_PMAC */
-
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- err = pci_enable_device(pdev);
+ ohci1394_pmac_on(dev);
+ pci_set_power_state(dev, PCI_D0);
+ pci_restore_state(dev);
+ err = pci_enable_device(dev);
if (err) {
PRINT(KERN_ERR, "pci_enable_device failed with %d", err);
return err;
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ 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