Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
On Mon, 27 Aug 2007 11:57:19 +1000 David Gibson wrote: > > + * Free Software Foundation; either version 2 of the License, or > > (at your > > + * option) any later version. > > + */ > > Unless there really is something peculiar about the EPx bridge > compared to say the GP, EP and other 4xx bridges, this should have a > more general name. well, I'd rather extend the name once/when it would be validated to work on those GR, EP etc. But, if preferred, it does not hurt to change all the prefixes to ppc4xx_ with such a sole implementation, and fork() if required later. opinions? -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
On Mon, 27 Aug 2007 11:54:17 +1000
David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
> >
> > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> >
> > ---
> >
> > arch/powerpc/boot/dts/sequoia.dts | 26 ++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/sequoia.dts
> > b/arch/powerpc/boot/dts/sequoia.dts index ef6f41c..8eb258f 100644
> > --- a/arch/powerpc/boot/dts/sequoia.dts
> > +++ b/arch/powerpc/boot/dts/sequoia.dts
> > @@ -92,6 +92,32 @@
> > #size-cells = <1>;
> > ranges;
> > clock-frequency = <0>; /* Filled in by zImage */
> > +
> > + pci {
> > + /* irqs are routed to irq67, dependless of
> > devsel/PIRQx */
> > + interrupt-map-mask = <0 0 0 0>;
> > + interrupt-map = <0 0 0 0 &UIC2 3
> > 8>; +
> > + interrupt-parent = <&UIC2>;
> > + interrupts = <3 8>;
> > +
> > + bus-range = <0 0>;
> > +
> > + /*
> > +* mem is at 8000 set up indirectly
> > +* io is at 0001_e800_
> > +*/
> > + ranges = <0200 0 8000 1 8000 0
> > 1000
> > + 0100 0 1 e800 0
> > 0010>; +
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > +
> > + reg = <1 eec0 40 1 ef40
> > 40>; /* phb cfg, phb reg */
> > + compatible = "ibm, 440epx";
> > + device_type = "pci";
>
> I usually put device_type, compatible and reg at the top of the block,
> to announce what the node actually is before giving all the details.
>
ok
> Also, apart from the stray space in the compatible, I'm guessing that
> the 440EPx bridge is actually more-or-less like the PCI bridges on
> other 4xx chips, so we should have a more general compatible string
> too.
>
heh, with a sole PCI impl on 4xx it does not hurt to have more general
stuff here.
what is proposed, "amcc,4xx"?
> Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> should be reflected in the name and compatible as well.
>
"The 32-bit PCI bridge is compatible with he PCI Specification, Version
2.2 (it does not support 5V operation) "
so seems to be vanilla PCI.
> > + };
> >
> > SDRAM0: sdram {
> > device_type = "memory-controller";
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
--
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
On Monday 27 August 2007, David Gibson wrote: > On Mon, Aug 27, 2007 at 08:07:17AM +0200, Stefan Roese wrote: > [snip] > > > > I usually put device_type, compatible and reg at the top of the block, > > > to announce what the node actually is before giving all the details. > > > > > > Also, apart from the stray space in the compatible, I'm guessing that > > > the 440EPx bridge is actually more-or-less like the PCI bridges on > > > other 4xx chips, so we should have a more general compatible string > > > too. > > > > Yes, it is "more-or-less" like any other 4xx PCI core. So it really would > > make sense to define it more generally. Something like: > > > > compatible = "ibm,pci-440epx", "ibm,pci4xx"; > > > > or even: > > > > compatible = "ibm,pci-440epx", "ibm,pci"; > > > > ? > > Hrm.. "xx" is ugly, and "ibm,pci" isn't specific enough. I think > we're better off just using the oldest similar chip. Since this is > vanilla PCI, I think that makes it "ibm,pci-405gp" Fine with me. > > > Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that > > > should be reflected in the name and compatible as well. > > > > It's a vanilla PCI bridge. > > Ok, so it is different from 440GP which is PCI-X. Yes. There are some common parts (IIRC), but there are differences. Perhaps both, IBM-PCI and IBM-PCI-X can be integrated into one source too, but I think we should start with PCI-only right now. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
On Mon, 27 Aug 2007 11:15:16 +1000
David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
> >
> > We are having 2 different instances of
> > pci_process_bridge_OF_ranges(), which makes describing 64-bit
> > physical addresses in non PPC64 case impossible.
> >
> > This approach inherits pci space parsing, but has a new way to
> > behave equally good in both 32bit and 64bit environments. Currently
> > validated with 440EPx (sequoia) and mpc8349-eitx.
> >
> > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
>
> I like the idea, but I don't think this implementation is adequate
> yet.
OK, I'll try to address notes below, thanks for looking at it.
>
> > diff --git a/arch/powerpc/kernel/pci-common.c
> > b/arch/powerpc/kernel/pci-common.c index 083cfbd..57cd039 100644
> > --- a/arch/powerpc/kernel/pci-common.c
> > +++ b/arch/powerpc/kernel/pci-common.c
> > @@ -478,3 +478,162 @@ void pci_resource_to_user(const struct
> > pci_dev *dev, int bar, *start = rsrc->start - offset;
> > *end = rsrc->end - offset;
> > }
> > +
> > +void __devinit pci_process_bridge_OF_ranges(struct pci_controller
> > *hose,
> > + struct device_node
> > *dev, int prim) +{
> > + static unsigned int static_lc_ranges[256];
> > + const unsigned int *ranges;
> > + unsigned int *lc_ranges;
> > + unsigned int pci_space;
> > + unsigned long size = 0;
>
> size can be 64-bit on 32-bit systems, at least in theory.
>
hm, well, but later, we'll call ioremap (at least for IO region) that has size
passed as ulong type. And, such a size could be consumed by the code,only if
resource_size_t is 64bit too. I'll look at it further.
> > + int rlen = 0;
> > + int orig_rlen, ranges_amnt, i;
> > + int memno = 0;
> > + struct resource *res;
> > + int np, na = of_n_addr_cells(dev);
> > + struct ranges_pci64_sz64 *ranges64 = NULL;
> > + struct ranges_pci32_sz64 *ranges32 = NULL;
> > + phys_addr_t pci_addr,
>
> This is wrong: the PCI binding defines the PCI addresses to be 64-bit,
> even if the CPU has 32-bit physical addresses.
>
hmm, ok
> cpu_phys_addr;
> > +
> > + np = na + 5;
> > +
> > + /* From "PCI Binding to 1275"
> z> + * The ranges property is laid out as an array of
> z> elements,
> > +* each of which comprises:
> > +* cells 0 - 2: a PCI address
> > +* cells 3 or 3+4:a CPU physical address
> > +* (size depending on
> > dev->n_addr_cells)
> > +* cells 4+5 or 5+6: the size of the range
> > +*/
> > + ranges = of_get_property(dev, "ranges", &rlen);
> > + if (ranges == NULL)
> > + return;
>
> if (!ranges) would be the usual idiom here.
>
ok
> > + /* Sanity check, though hopefully that never happens */
> > + if (rlen > sizeof(static_lc_ranges)) {
> > + printk(KERN_WARNING "OF ranges property too
> > large !\n");
> > + rlen = sizeof(static_lc_ranges);
> > + }
> > +
> > + /* Let's work on a copy of the "ranges" property instead
> > +* of damaging the device-tree image in memory
> > +*/
> > + lc_ranges = static_lc_ranges;
> > + memcpy(lc_ranges, ranges, rlen);
> > + orig_rlen = rlen;
> > +
> > + ranges = lc_ranges;
>
> You don't ever actually touch the ranges property in place, so there's
> no need for this copy stuff.
>
ok
> > + /* Map ranges to struct according to spec. */
> > + if (na >= 2) {
> > + ranges64 = (void *)ranges;
> > + ranges_amnt = rlen / sizeof(*ranges64);
> > + } else {
> > + ranges32 = (void *)ranges;
> > + ranges_amnt = rlen / sizeof(*ranges32);
> > + }
> > +
> > + hose->io_base_phys = 0;
> > + for (i = 0; i < ranges_amnt; i++) {
> > + res = NULL;
> > + if (ranges64) {
> > + if (ranges64[i].pci_space == 0)
> > + continue;
> > +
> > + pci_space = ranges64[i].pci_space;
> > + pci_addr =
> > + (u64) ranges64[i].pci_addr[0] << 32 |
> > ranges64[i].
> > + pci_addr[1];
>
> Why not just define the pci_addr field in your structures as u64? You
> would have to define the structure with attribute((packed)), I guess.
>
that was in the first approach, but it gets really interesting numbers (and
with contents nothing to do with real stuff),
on platforms that are pure 32bit. I mean,
u32 foo, foo1;
u64 foo64;
foo = bar[1];
foo1 = bar[2];
foo64 = ((u64)foo << 32) | foo1;
does not seem to work on 32bit board. I may need to write a clear testcase and
submit it here, maybe I'm missing something
very obvious.
> > + cpu_phys_addr =
> > + of_translate_address(dev,
> > ranges64[i].phys_addr);
> > + /*
> > +* I haven't observed 2 significant size
> > cells in kernel
> > +* code, so we
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
On Mon, Aug 27, 2007 at 08:07:17AM +0200, Stefan Roese wrote: [snip] > > I usually put device_type, compatible and reg at the top of the block, > > to announce what the node actually is before giving all the details. > > > > Also, apart from the stray space in the compatible, I'm guessing that > > the 440EPx bridge is actually more-or-less like the PCI bridges on > > other 4xx chips, so we should have a more general compatible string > > too. > > Yes, it is "more-or-less" like any other 4xx PCI core. So it really would > make > sense to define it more generally. Something like: > > compatible = "ibm,pci-440epx", "ibm,pci4xx"; > > or even: > > compatible = "ibm,pci-440epx", "ibm,pci"; > > ? Hrm.. "xx" is ugly, and "ibm,pci" isn't specific enough. I think we're better off just using the oldest similar chip. Since this is vanilla PCI, I think that makes it "ibm,pci-405gp" > > Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that > > should be reflected in the name and compatible as well. > > It's a vanilla PCI bridge. Ok, so it is different from 440GP which is PCI-X. -- 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 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
On Monday 27 August 2007, David Gibson wrote: > On Sat, Aug 25, 2007 at 01:30:01PM +0400, Vitaly Bordug wrote: > > In fact, loosely move of arch/ppc bits, though regions are > > set up using values from ranges property. This also adds > > setup_indirect_pci_noremap() function to handle indirect > > PCI without one more ioremap. > > > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > > > --- > > > > arch/powerpc/platforms/44x/44x.h | 28 > > arch/powerpc/platforms/44x/Makefile|4 + > > arch/powerpc/platforms/44x/ppc440epx-pci.c | 192 > > arch/powerpc/platforms/44x/sequoia.c | > > 14 ++ > > arch/powerpc/sysdev/indirect_pci.c | 14 ++ > > include/asm-powerpc/pci-bridge.h |2 > > 6 files changed, 254 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/platforms/44x/44x.h > > b/arch/powerpc/platforms/44x/44x.h index 42eabf8..d3845f9 100644 > > --- a/arch/powerpc/platforms/44x/44x.h > > +++ b/arch/powerpc/platforms/44x/44x.h > > @@ -1,8 +1,36 @@ > > #ifndef __POWERPC_PLATFORMS_44X_44X_H > > #define __POWERPC_PLATFORMS_44X_44X_H > > +#include > > + > > +/* PCI support */ > > +#define PPC4xx_PCI_CFGA_OFFSET 0 > > +#define PPC4xx_PCI_CFGD_OFFSET 0x4 > > + > > +#define PPC4xx_PCIL0_PMM0LA0x000 > > +#define PPC4xx_PCIL0_PMM0MA0x004 > > +#define PPC4xx_PCIL0_PMM0PCILA 0x008 > > +#define PPC4xx_PCIL0_PMM0PCIHA 0x00C > > +#define PPC4xx_PCIL0_PMM1LA0x010 > > +#define PPC4xx_PCIL0_PMM1MA0x014 > > +#define PPC4xx_PCIL0_PMM1PCILA 0x018 > > +#define PPC4xx_PCIL0_PMM1PCIHA 0x01C > > +#define PPC4xx_PCIL0_PMM2LA0x020 > > +#define PPC4xx_PCIL0_PMM2MA0x024 > > +#define PPC4xx_PCIL0_PMM2PCILA 0x028 > > +#define PPC4xx_PCIL0_PMM2PCIHA 0x02C > > +#define PPC4xx_PCIL0_PTM1MS0x030 > > +#define PPC4xx_PCIL0_PTM1LA0x034 > > +#define PPC4xx_PCIL0_PTM2MS0x038 > > +#define PPC4xx_PCIL0_PTM2LA0x03C > > > > extern u8 as1_readb(volatile u8 __iomem *addr); > > extern void as1_writeb(u8 data, volatile u8 __iomem *addr); > > extern void ppc44x_reset_system(char *cmd); > > > > +#ifdef CONFIG_PCI > > +int ppc440epx_exclude_device(struct pci_controller *hose, > > + u_char bus, u_char devfn); > > +int ppc440epx_add_bridge(struct device_node *dev); > > +#endif > > + > > #endif /* __POWERPC_PLATFORMS_44X_44X_H */ > > diff --git a/arch/powerpc/platforms/44x/Makefile > > b/arch/powerpc/platforms/44x/Makefile index 10ce674..d2a5278 100644 > > --- a/arch/powerpc/platforms/44x/Makefile > > +++ b/arch/powerpc/platforms/44x/Makefile > > @@ -2,3 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o > > obj-$(CONFIG_EBONY)+= ebony.o > > obj-$(CONFIG_BAMBOO) += bamboo.o > > obj-$(CONFIG_SEQUOIA) += sequoia.o > > + > > +ifeq ($(CONFIG_PCI),y) > > +obj-$(CONFIG_440EPX) += ppc440epx-pci.o > > +endif > > diff --git a/arch/powerpc/platforms/44x/ppc440epx-pci.c > > b/arch/powerpc/platforms/44x/ppc440epx-pci.c new file mode 100644 > > index 000..bd4a352 > > --- /dev/null > > +++ b/arch/powerpc/platforms/44x/ppc440epx-pci.c > > @@ -0,0 +1,192 @@ > > +/* > > + * PPC44x PCI host support > > + * > > + * Vitaly Bordug <[EMAIL PROTECTED]> > > + * Stefan Roese <[EMAIL PROTECTED]> > > + * > > + * Based on arch/ppc sequoia pci bits, that are > > + * Copyright 2006-2007 DENX Software Engineering, Stefan Roese > > <[EMAIL PROTECTED]> + * > > + * Based on bamboo.c from Wade Farnsworth <[EMAIL PROTECTED]> > > + * Copyright 2004 MontaVista Software Inc. > > + * Copyright 2006 AMCC > > + * 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. > > + */ > > Unless there really is something peculiar about the EPx bridge > compared to say the GP, EP and other 4xx bridges, this should have a > more general name. We originally started naming this file sequoia-pci.c and changed it to be 440EPx specific (just by renaming). But you are right of course. We should make it even more generic for 4xx PCI support. Perhaps we will overlook some problems with other 4xx platforms, but those should be solved when other platforms (Josh: 440ep and 405gp? ;)) will be added. So what should it be called? arch/powerpc/syslib/ppc4xx_pci.c ? Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
On Monday 27 August 2007, David Gibson wrote:
> On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
> > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> >
> > ---
> >
> > arch/powerpc/boot/dts/sequoia.dts | 26 ++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/sequoia.dts
> > b/arch/powerpc/boot/dts/sequoia.dts index ef6f41c..8eb258f 100644
> > --- a/arch/powerpc/boot/dts/sequoia.dts
> > +++ b/arch/powerpc/boot/dts/sequoia.dts
> > @@ -92,6 +92,32 @@
> > #size-cells = <1>;
> > ranges;
> > clock-frequency = <0>; /* Filled in by zImage */
> > +
> > + pci {
> > + /* irqs are routed to irq67, dependless of devsel/PIRQx
> > */
> > + interrupt-map-mask = <0 0 0 0>;
> > + interrupt-map = <0 0 0 0 &UIC2 3 8>;
> > +
> > + interrupt-parent = <&UIC2>;
> > + interrupts = <3 8>;
> > +
> > + bus-range = <0 0>;
> > +
> > + /*
> > +* mem is at 8000 set up indirectly
> > +* io is at 0001_e800_
> > +*/
> > + ranges = <0200 0 8000 1 8000 0 1000
> > + 0100 0 1 e800 0 0010>;
> > +
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > +
> > + reg = <1 eec0 40 1 ef40 40>; /* phb
> > cfg, phb reg */
> > + compatible = "ibm, 440epx";
> > + device_type = "pci";
>
> I usually put device_type, compatible and reg at the top of the block,
> to announce what the node actually is before giving all the details.
>
> Also, apart from the stray space in the compatible, I'm guessing that
> the 440EPx bridge is actually more-or-less like the PCI bridges on
> other 4xx chips, so we should have a more general compatible string
> too.
Yes, it is "more-or-less" like any other 4xx PCI core. So it really would make
sense to define it more generally. Something like:
compatible = "ibm,pci-440epx", "ibm,pci4xx";
or even:
compatible = "ibm,pci-440epx", "ibm,pci";
?
> Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
> should be reflected in the name and compatible as well.
It's a vanilla PCI bridge.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
On Saturday 25 August 2007, Segher Boessenkool wrote: > > + compatible = "ibm, 440epx"; > > Oh, and shouldn't it be "amcc," anyway? Not sure here. It's still the PCI core used on the early 405 and 440 platforms build by IBM. If we use IBM on other core logic like UIC, EMAC etc, then we should use IBM here too. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: issues concerning the next NAPI interface
From: James Chapman <[EMAIL PROTECTED]> Date: Sun, 26 Aug 2007 20:36:20 +0100 > David Miller wrote: > > From: James Chapman <[EMAIL PROTECTED]> > > Date: Fri, 24 Aug 2007 18:16:45 +0100 > > > >> Does hardware interrupt mitigation really interact well with NAPI? > > > > It interacts quite excellently. > > If NAPI disables interrupts and keeps them disabled while there are more > packets arriving or more transmits being completed, why do hardware > interrupt mitigation / coalescing features of the network silicon help? Because if your packet rate is low enough such that the cpu can process the interrupt fast enough and thus only one packet gets processed per NAPI poll, the cost of going into and out of NAPI mode dominates the packet processing costs. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] Add PCI support for AMCC 440EPx (sequoia)
On Sat, Aug 25, 2007 at 01:30:01PM +0400, Vitaly Bordug wrote: > > In fact, loosely move of arch/ppc bits, though regions are > set up using values from ranges property. This also adds > setup_indirect_pci_noremap() function to handle indirect > PCI without one more ioremap. > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > --- > > arch/powerpc/platforms/44x/44x.h | 28 > arch/powerpc/platforms/44x/Makefile|4 + > arch/powerpc/platforms/44x/ppc440epx-pci.c | 192 > > arch/powerpc/platforms/44x/sequoia.c | 14 ++ > arch/powerpc/sysdev/indirect_pci.c | 14 ++ > include/asm-powerpc/pci-bridge.h |2 > 6 files changed, 254 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/platforms/44x/44x.h > b/arch/powerpc/platforms/44x/44x.h > index 42eabf8..d3845f9 100644 > --- a/arch/powerpc/platforms/44x/44x.h > +++ b/arch/powerpc/platforms/44x/44x.h > @@ -1,8 +1,36 @@ > #ifndef __POWERPC_PLATFORMS_44X_44X_H > #define __POWERPC_PLATFORMS_44X_44X_H > +#include > + > +/* PCI support */ > +#define PPC4xx_PCI_CFGA_OFFSET 0 > +#define PPC4xx_PCI_CFGD_OFFSET 0x4 > + > +#define PPC4xx_PCIL0_PMM0LA 0x000 > +#define PPC4xx_PCIL0_PMM0MA 0x004 > +#define PPC4xx_PCIL0_PMM0PCILA 0x008 > +#define PPC4xx_PCIL0_PMM0PCIHA 0x00C > +#define PPC4xx_PCIL0_PMM1LA 0x010 > +#define PPC4xx_PCIL0_PMM1MA 0x014 > +#define PPC4xx_PCIL0_PMM1PCILA 0x018 > +#define PPC4xx_PCIL0_PMM1PCIHA 0x01C > +#define PPC4xx_PCIL0_PMM2LA 0x020 > +#define PPC4xx_PCIL0_PMM2MA 0x024 > +#define PPC4xx_PCIL0_PMM2PCILA 0x028 > +#define PPC4xx_PCIL0_PMM2PCIHA 0x02C > +#define PPC4xx_PCIL0_PTM1MS 0x030 > +#define PPC4xx_PCIL0_PTM1LA 0x034 > +#define PPC4xx_PCIL0_PTM2MS 0x038 > +#define PPC4xx_PCIL0_PTM2LA 0x03C > > extern u8 as1_readb(volatile u8 __iomem *addr); > extern void as1_writeb(u8 data, volatile u8 __iomem *addr); > extern void ppc44x_reset_system(char *cmd); > > +#ifdef CONFIG_PCI > +int ppc440epx_exclude_device(struct pci_controller *hose, > + u_char bus, u_char devfn); > +int ppc440epx_add_bridge(struct device_node *dev); > +#endif > + > #endif /* __POWERPC_PLATFORMS_44X_44X_H */ > diff --git a/arch/powerpc/platforms/44x/Makefile > b/arch/powerpc/platforms/44x/Makefile > index 10ce674..d2a5278 100644 > --- a/arch/powerpc/platforms/44x/Makefile > +++ b/arch/powerpc/platforms/44x/Makefile > @@ -2,3 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o > obj-$(CONFIG_EBONY) += ebony.o > obj-$(CONFIG_BAMBOO) += bamboo.o > obj-$(CONFIG_SEQUOIA)+= sequoia.o > + > +ifeq ($(CONFIG_PCI),y) > +obj-$(CONFIG_440EPX) += ppc440epx-pci.o > +endif > diff --git a/arch/powerpc/platforms/44x/ppc440epx-pci.c > b/arch/powerpc/platforms/44x/ppc440epx-pci.c > new file mode 100644 > index 000..bd4a352 > --- /dev/null > +++ b/arch/powerpc/platforms/44x/ppc440epx-pci.c > @@ -0,0 +1,192 @@ > +/* > + * PPC44x PCI host support > + * > + * Vitaly Bordug <[EMAIL PROTECTED]> > + * Stefan Roese <[EMAIL PROTECTED]> > + * > + * Based on arch/ppc sequoia pci bits, that are > + * Copyright 2006-2007 DENX Software Engineering, Stefan Roese <[EMAIL > PROTECTED]> > + * > + * Based on bamboo.c from Wade Farnsworth <[EMAIL PROTECTED]> > + * Copyright 2004 MontaVista Software Inc. > + * Copyright 2006 AMCC > + * 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. > + */ Unless there really is something peculiar about the EPx bridge compared to say the GP, EP and other 4xx bridges, this should have a more general name. -- 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 2/3] [POWERPC] Add pci node to sequoia dts
On Sun, Aug 26, 2007 at 02:27:50PM +0400, Vitaly Bordug wrote: > On Sat, 25 Aug 2007 11:49:58 +0200 Segher Boessenkool wrote: [snip] > > > + compatible = "ibm, 440epx"; > > > > Stray space. And you need to say it is the PCI host, so something > > like "ibm,440epx-pci". > > > OK, will have "amcc,.440epx-pci" here Uh... now instead of a stray space you have a stray '.' -- 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 2/3] [POWERPC] Add pci node to sequoia dts
On Sat, Aug 25, 2007 at 01:29:54PM +0400, Vitaly Bordug wrote:
>
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
>
> ---
>
> arch/powerpc/boot/dts/sequoia.dts | 26 ++
> 1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/sequoia.dts
> b/arch/powerpc/boot/dts/sequoia.dts
> index ef6f41c..8eb258f 100644
> --- a/arch/powerpc/boot/dts/sequoia.dts
> +++ b/arch/powerpc/boot/dts/sequoia.dts
> @@ -92,6 +92,32 @@
> #size-cells = <1>;
> ranges;
> clock-frequency = <0>; /* Filled in by zImage */
> +
> + pci {
> + /* irqs are routed to irq67, dependless of devsel/PIRQx
> */
> + interrupt-map-mask = <0 0 0 0>;
> + interrupt-map = <0 0 0 0 &UIC2 3 8>;
> +
> + interrupt-parent = <&UIC2>;
> + interrupts = <3 8>;
> +
> + bus-range = <0 0>;
> +
> + /*
> + * mem is at 8000 set up indirectly
> + * io is at 0001_e800_
> + */
> + ranges = <0200 0 8000 1 8000 0 1000
> + 0100 0 1 e800 0 0010>;
> +
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> +
> + reg = <1 eec0 40 1 ef40 40>; /* phb cfg, phb
> reg */
> + compatible = "ibm, 440epx";
> + device_type = "pci";
I usually put device_type, compatible and reg at the top of the block,
to announce what the node actually is before giving all the details.
Also, apart from the stray space in the compatible, I'm guessing that
the 440EPx bridge is actually more-or-less like the PCI bridges on
other 4xx chips, so we should have a more general compatible string
too.
Is the 440EPx a vanilla PCI or a PCI-X bridge? If the later that
should be reflected in the name and compatible as well.
> + };
>
> SDRAM0: sdram {
> device_type = "memory-controller";
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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/3] [POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
On Sat, Aug 25, 2007 at 01:29:47PM +0400, Vitaly Bordug wrote:
>
> We are having 2 different instances of pci_process_bridge_OF_ranges(),
> which makes describing 64-bit physical addresses in non PPC64 case
> impossible.
>
> This approach inherits pci space parsing, but has a new way to behave
> equally good in both 32bit and 64bit environments. Currently validated
> with 440EPx (sequoia) and mpc8349-eitx.
>
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
I like the idea, but I don't think this implementation is adequate
yet.
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel/pci-common.c
> index 083cfbd..57cd039 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -478,3 +478,162 @@ void pci_resource_to_user(const struct pci_dev *dev,
> int bar,
> *start = rsrc->start - offset;
> *end = rsrc->end - offset;
> }
> +
> +void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
> + struct device_node *dev, int prim)
> +{
> + static unsigned int static_lc_ranges[256];
> + const unsigned int *ranges;
> + unsigned int *lc_ranges;
> + unsigned int pci_space;
> + unsigned long size = 0;
size can be 64-bit on 32-bit systems, at least in theory.
> + int rlen = 0;
> + int orig_rlen, ranges_amnt, i;
> + int memno = 0;
> + struct resource *res;
> + int np, na = of_n_addr_cells(dev);
> + struct ranges_pci64_sz64 *ranges64 = NULL;
> + struct ranges_pci32_sz64 *ranges32 = NULL;
> + phys_addr_t pci_addr,
This is wrong: the PCI binding defines the PCI addresses to be 64-bit,
even if the CPU has 32-bit physical addresses.
cpu_phys_addr;
> +
> + np = na + 5;
> +
> + /* From "PCI Binding to 1275"
z> + * The ranges property is laid out as an array of elements,
> + * each of which comprises:
> + * cells 0 - 2: a PCI address
> + * cells 3 or 3+4:a CPU physical address
> + * (size depending on dev->n_addr_cells)
> + * cells 4+5 or 5+6: the size of the range
> + */
> + ranges = of_get_property(dev, "ranges", &rlen);
> + if (ranges == NULL)
> + return;
if (!ranges) would be the usual idiom here.
> + /* Sanity check, though hopefully that never happens */
> + if (rlen > sizeof(static_lc_ranges)) {
> + printk(KERN_WARNING "OF ranges property too large !\n");
> + rlen = sizeof(static_lc_ranges);
> + }
> +
> + /* Let's work on a copy of the "ranges" property instead
> + * of damaging the device-tree image in memory
> + */
> + lc_ranges = static_lc_ranges;
> + memcpy(lc_ranges, ranges, rlen);
> + orig_rlen = rlen;
> +
> + ranges = lc_ranges;
You don't ever actually touch the ranges property in place, so there's
no need for this copy stuff.
> + /* Map ranges to struct according to spec. */
> + if (na >= 2) {
> + ranges64 = (void *)ranges;
> + ranges_amnt = rlen / sizeof(*ranges64);
> + } else {
> + ranges32 = (void *)ranges;
> + ranges_amnt = rlen / sizeof(*ranges32);
> + }
> +
> + hose->io_base_phys = 0;
> + for (i = 0; i < ranges_amnt; i++) {
> + res = NULL;
> + if (ranges64) {
> + if (ranges64[i].pci_space == 0)
> + continue;
> +
> + pci_space = ranges64[i].pci_space;
> + pci_addr =
> + (u64) ranges64[i].pci_addr[0] << 32 | ranges64[i].
> + pci_addr[1];
Why not just define the pci_addr field in your structures as u64? You
would have to define the structure with attribute((packed)), I guess.
> + cpu_phys_addr =
> + of_translate_address(dev, ranges64[i].phys_addr);
> + /*
> + * I haven't observed 2 significant size cells in kernel
> + * code, so we're accounting only LSB of size part
> + * from ranges. -vitb
> + */
> + size = ranges64[i].size[1];
> +#ifdef CONFIG_PPC64
> + if (ranges64[i].size[0])
> + size |= ranges64[i].size[0]<<32;
> +#endif
> + DBG("Observed: pci %llx phys %llx size %x\n", pci_addr,
> + cpu_phys_addr, size);
> + } else {
> + if (ranges32[i].pci_space == 0)
> + continue;
> +
> + pci_space = (unsigned int)ranges32[i].pci_space;
> + pci_addr = (unsigned int)ranges32[i].pci_addr[1];
> + cpu_phys_addr = (unsigned int)ranges32[i].phys_addr[0];
We should really be using of_translate_address() in all cases - tha
Re: [PATCH, RFC] linkstation: implement standby
On Sun, Aug 26, 2007 at 02:03:49AM +0200, Guennadi Liakhovetski wrote:
> Implement suspend/resume for "mpc10x" compatible fsl host PCI controllers,
> use it for linkstation standby.
Hi Guennadi
> +static int __init ls_pm_init(void)
> +{
> + if (!machine_is(linkstation))
> + return 0;
This should probably be -ENODEV.
> +int mpc10x_suspend(suspend_state_t state)
You only seem to call this from ls_pm_enter() where you don't check the
return value, perhaps this should be void ?
> +{
> + struct pci_dev *bridge;
> + u16 pmcr1;
> +
> + bridge = pci_find_slot(0, 0);
> + if (!bridge)
> + return -ENODEV;
I think you want pci_get_bus_and_slot() here instead of pci_find_slot(),
in fact I think it'd be cleaner, if you located the bridge in
ls_pm_enter() and passed it in.
> +int mpc10x_resume(suspend_state_t state)
> +{
> + struct pci_dev *bridge;
> + u16 pmcr1;
> +
> + bridge = pci_find_slot(0, 0);
> + if (!bridge)
> + return -ENODEV;
Same comments ass mpc10x_suspend();
Yours Tony
linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge There are 4 bug fixes for Cell and a cell_defconfig update from Arnd, and a bug fix each from Olof Johansson, Olaf Hering and myself. Thanks, Paul. arch/powerpc/configs/cell_defconfig | 220 ++--- arch/powerpc/mm/slb.c | 36 - arch/powerpc/platforms/cell/cbe_regs.h|8 + arch/powerpc/platforms/cell/cbe_thermal.c |6 - arch/powerpc/platforms/cell/pervasive.c | 26 +++ arch/powerpc/platforms/cell/spu_manage.c |2 arch/powerpc/platforms/pasemi/iommu.c |6 - arch/powerpc/sysdev/axonram.c | 46 +- drivers/macintosh/adb.c |4 - drivers/macintosh/via-pmu.c | 34 ++-- include/linux/pmu.h |2 11 files changed, 172 insertions(+), 218 deletions(-) commit 175587cca7447daf5a13e4a53d32360ed8cba804 Author: Paul Mackerras <[EMAIL PROTECTED]> Date: Sat Aug 25 13:14:28 2007 +1000 [POWERPC] Fix SLB initialization at boot time This partially reverts edd0622bd2e8f755c960827e15aa6908c3c5aa94. It turns out that the part of that commit that aimed to ensure that we created an SLB entry for the kernel stack on secondary CPUs when starting the CPU didn't achieve its aim, and in fact caused a regression, because get_paca()->kstack is not initialized at the point where slb_initialize is called. This therefore just reverts that part of that commit, while keeping the change to slb_flush_and_rebolt, which is correct and necessary. Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> commit e120e8d03a263cf75f2abc0f8b3a03a65cfd3b88 Author: Olaf Hering <[EMAIL PROTECTED]> Date: Sat Aug 25 05:42:01 2007 +1000 [POWERPC] Fix undefined reference to device_power_up/resume Current Linus tree fails to link on pmac32: drivers/built-in.o: In function `pmac_wakeup_devices': via-pmu.c:(.text+0x5bab4): undefined reference to `device_power_up' via-pmu.c:(.text+0x5bb08): undefined reference to `device_resume' drivers/built-in.o: In function `pmac_suspend_devices': via-pmu.c:(.text+0x5c260): undefined reference to `device_power_down' via-pmu.c:(.text+0x5c27c): undefined reference to `device_resume' make[1]: *** [.tmp_vmlinux1] Error 1 changing CONFIG_PM > CONFIG_PM_SLEEP leads to: drivers/built-in.o: In function `pmu_led_set': via-pmu-led.c:(.text+0x5cdca): undefined reference to `pmu_sys_suspended' via-pmu-led.c:(.text+0x5cdce): undefined reference to `pmu_sys_suspended' drivers/built-in.o: In function `pmu_req_done': via-pmu-led.c:(.text+0x5ce3e): undefined reference to `pmu_sys_suspended' via-pmu-led.c:(.text+0x5ce42): undefined reference to `pmu_sys_suspended' drivers/built-in.o: In function `adb_init': (.init.text+0x4c5c): undefined reference to `pmu_register_sleep_notifier' make[1]: *** [.tmp_vmlinux1] Error 1 So change even more places from PM to PM_SLEEP to allow linking. Signed-off-by: Olaf Hering <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> commit b22ddc703c5daa603d8d53881b530da3cab94cd4 Author: Arnd Bergmann <[EMAIL PROTECTED]> Date: Thu Aug 23 03:09:17 2007 +1000 [POWERPC] cell: Update cell_defconfig for 2.6.23 Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> commit b0e81ebb1062eba20fbcbe459662c0a6ec6075f7 Author: Maxim Shchetynin <[EMAIL PROTECTED]> Date: Thu Aug 23 03:01:28 2007 +1000 [POWERPC] axonram: Do not delete gendisks queue in error path On exit do not delete gendisk's queue because this is already done by del_gendisk(). Doing it twice may cause memory damage. Signed-off-by: Maximilian <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> commit fedcd2c53d838e7a69df699ce2a14e45d34d7f7f Author: Maxim Shchetynin <[EMAIL PROTECTED]> Date: Thu Aug 23 03:01:27 2007 +1000 [POWERPC] axonram: Module modification for latest firmware API changes Firmware would not deliver two interrupt numbers in device-tree any more but only one, for correctable ECC, because uncorrectable ECC from now is handled by firmware itself. Changes in the axonram module are necessary because in the old version, if it is not allowed to fetch the second interrupt number from device-tree, it interpretes this as an error case and exits. Signed-off-by: Maximilian <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> commit 3addf55c9415f9da039947b33d064332137e49fe Author: Arnd Bergmann <[EMAIL PROTECTED]> Date: Thu Aug 23 03:01:26 2007 +1000 [POWERPC] cell: Support pinhole-reset on IBM cell blades
Re: Sleep problems with kernels >= 2.6.21 on powerpc
Hi [Adding STR wizards to CC] On 26/08/07, Rogério Brito <[EMAIL PROTECTED]> wrote: > Hi. > > Unfortunately, it seems that kernels later than 2.6.21 have problems > letting my powerpc iBook (G3 processor) going to sleep (suspend to > ram). > > The userland that I am using is a Debian testing (lenny) and the > default kernel that comes with it is 2.6.22, with some patches applied > and pbbuttonsd (as the daemon for making the machine sleep). > > With kernel 2.6.21, from Debian (and other earlier kernels), the > symptoms that I see when I press the power button is that the machine > goes to sleep and the led that indicates that the machine is sleeping > is blinking normally. > > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own > kernel with just the necessary parts for my work (version 2.6.23-rc3 > taken from kernel.org), then I can't make the machine sleep: when I > press the button, it acts like if I had, in sequence, pressed anything > to wake it up (say, like pressing shift). > > I have already grabbed Linus's git tree and I am willing to do some > cycles of "git bisect" to discover the point where it stopped working. > > I just thought that others may have seen such behaviour before or, if > not, that being informative about what I see is of use for debugging > this. > > I would also appreciate any guidance on this as I wish kernel 2.6.23 > to be working again on powerpc machines. > > Please, if any tests are required, don't hesitate to ask me and I will > try to whatever is needed to restore the correct behaviour of sleep > with the Linux kernel. > > I have copied mailing lists that I think that are relevant. If they > aren't, then please let me know. I would also appreciate if I were > kept on carbon copies as I am only subscribed to debian-powerpc at the > moment. > > > Regards, Rogério Brito. > > P.S.: It unfortunately doesn't matter if I switch to a console or if I > am in X when I press the power button with recent kernels. > - Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: issues concerning the next NAPI interface
David Miller wrote: > From: James Chapman <[EMAIL PROTECTED]> > Date: Fri, 24 Aug 2007 18:16:45 +0100 > >> Does hardware interrupt mitigation really interact well with NAPI? > > It interacts quite excellently. If NAPI disables interrupts and keeps them disabled while there are more packets arriving or more transmits being completed, why do hardware interrupt mitigation / coalescing features of the network silicon help? > There was a long saga about this with tg3 and huge SGI numa > systems with large costs for interrupt processing, and the > fix was to do a minimal amount of interrupt mitigation and > this basically cleared up all the problems. > > Someone should reference that thread _now_ before this discussion goes > too far and we repeat a lot of information and people like myself have > to stay up all night correcting the misinformation and > misunderstandings that are basically guarenteed for this topic :) I hope I'm not spreading misinformation. :) The original poster was observing NAPI going in/out of polled mode because the CPU is fast enough to process all work per poll. I've seen the same and I'm suggesting that the NAPI driver keeps itself in polled mode for N polls or M jiffies after it sees workdone=0. This has always worked for me in packet forwarding scenarios to maximize packets/sec and minimize latency. I'm considering putting a patch together to add this as another tuning knob, hence I'm keen to understand what I'm missing. :) -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
>>> + pci {
>>> + reg = <1 eec0 40 1 ef40
>>> 40>; /* phb cfg, phb reg */
>>
>> First component of reg is the unit address, so: [EMAIL PROTECTED] .
>>
>> "phb cfg" is how you access PCI configuration space? It wouldn't
>> hurt to document that, either in a little binding or just here in
>> the code.
>>
> mmm, that was what my poor upper comment about, exactly.
> do you mean that "PCI configuration space _, PCI register at
> _" will look more
> appropriate?
I just mean you should document what the two "reg" regions for this
device are meant to represent. "phb reg" isn't really verbose enough
;-)
>>> + bus-range = <0 0>;
>>
>> Can't you have subordinate PCI busses? Or are there no slots :-)
>>
> Even if there are (and I dunno - Stefan did the HW validation and
> updates, since he has actual target),
> the performance of such a beast would be low, with one shared irq for
> everybody...
Sure, but this is about correctness, not performance.
>>> + /*
>>> +* mem is at 8000 set up indirectly
>>> +* io is at 0001_e800_
>>> +*/
>>> + ranges = <0200 0 8000 1 8000 0
>>> 1000
>>> + 0100 0 1 e800 0
>>> 0010>;
>>
>> Comment doesn't match code for the memory space. What does "set
>> up indirectly" mean here? Oh wait, you want to say that the host
>> addresses 1_8000_..1_8fff_ are translated to PCI addresses
>> 8000_..8fff_.
>>
> Yes, exactly.
Great. Could you please fix the comment to just say this, then?
>> What about PCI DMA, is that identity mapped?
>>
> Not thinking about it atm, should "just work" /*though it never really
> does*/ :)
Okay, if it's identity mapped, you don't need any properties in the
device tree for it. Good :-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC] linkstation: implement standby
On Sun, 26 Aug 2007, Stephen Rothwell wrote:
> On Sun, 26 Aug 2007 02:03:49 +0200 (CEST) Guennadi Liakhovetski <[EMAIL
> PROTECTED]> wrote:
> >
> > +static int ls_pm_enter(suspend_state_t state)
> > +{
> > + char ier;
> > + int ret = 0;
> > + u64 tb;
> > +
> > + if ((ret = mpc10x_suspend(state)) < 0)
> > + return ret;
> > +
> > + /* Get timebase */
> > + tb = get_tb();
> > +
> > + /* put CPU to sleep, re-enabling interrupts */
> > + mpc6xx_enter_sleep();
> > +
> > + local_irq_disable();
> > +
> > + set_tb(tb >> 32, tb & 0xul);
> > +
> > +fail:
>
> Unused label?
Right, will fix in the next version, thanks.
Guennadi
---
Guennadi Liakhovetski
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] xmon: setjmp / longjmp implementation problems
Just for the record: I made a mistake in my userspace test environment regarding the setjmp/longjmp implementation. I defined setjmp/longjmp functions as static ones, which triggered recent compilers to inline. Inlining breaks setjmp/longjmp of course. Further I realized that the NuBus-specific setjmp/longjmp was also defined as static functions. For xmon this was never the case (even defined in a separate file). Thanks to David Gibson and Sergei Shtylyov for answering my questions on #mklinux. Cheers, Florian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] Add pci node to sequoia dts
On Sat, 25 Aug 2007 11:49:58 +0200
Segher Boessenkool wrote:
> > + pci {
> > + reg = <1 eec0 40 1 ef40
> > 40>; /* phb cfg, phb reg */
>
> First component of reg is the unit address, so: [EMAIL PROTECTED] .
>
> "phb cfg" is how you access PCI configuration space? It wouldn't
> hurt to document that, either in a little binding or just here in
> the code.
>
mmm, that was what my poor upper comment about, exactly.
do you mean that "PCI configuration space _, PCI register at _"
will look more
appropriate?
> > + bus-range = <0 0>;
>
> Can't you have subordinate PCI busses? Or are there no slots :-)
>
Even if there are (and I dunno - Stefan did the HW validation and updates,
since he has actual target),
the performance of such a beast would be low, with one shared irq for
everybody...
> > + /*
> > +* mem is at 8000 set up indirectly
> > +* io is at 0001_e800_
> > +*/
> > + ranges = <0200 0 8000 1 8000 0
> > 1000
> > + 0100 0 1 e800 0
> > 0010>;
>
> Comment doesn't match code for the memory space. What does "set
> up indirectly" mean here? Oh wait, you want to say that the host
> addresses 1_8000_..1_8fff_ are translated to PCI addresses
> 8000_..8fff_.
>
Yes, exactly.
> What about PCI DMA, is that identity mapped?
>
Not thinking about it atm, should "just work" /*though it never really does*/ :)
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
>
> The reverse order of these is more conventional. Not that it
> actually matters ;-)
ok, I'll reorder them
>
> > + compatible = "ibm, 440epx";
>
> Stray space. And you need to say it is the PCI host, so something
> like "ibm,440epx-pci".
>
OK, will have "amcc,.440epx-pci" here
--
Sincerely, Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fix pmac_zilog debug arg
drivers/serial/pmac_zilog.c:1590: warning: format '%d' expects type 'int', but
argument 3 has type 'pm_message_t'
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
---
drivers/serial/pmac_zilog.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -1587,7 +1587,7 @@ static int pmz_suspend(struct macio_dev
if (pm_state.event == mdev->ofdev.dev.power.power_state.event)
return 0;
- pmz_debug("suspend, switching to state %d\n", pm_state);
+ pmz_debug("suspend, switching to state %d\n", pm_state.event);
state = pmz_uart_reg.state + uap->port.line;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
