Re: pci in arch/powerpc vs arch/ppc

Alexandros Kostopoulos writes: > In mpc8272ads.dts, the ranges property for pci is: > > ranges = <4200 0 8000 8000 0 2000 > 0200 0 a000 a000 0 2000 > 0100 0 f600 0 0200>; > > The third obviously corresponds to IO space. So,

[PATCH v2] Handle alignment faults on new FP load/store instructions

This adds code to handle alignment traps generated by the following new floating-point load/store instructions, by emulating the instruction in the kernel (as is done for other instructions that generate alignment traps): lfiwax load floating-point as integer word algebraic indexed stfiwx store

Re: [PATCH] Use 1TB segments

> +static int __init htab_dt_scan_seg_sizes(unsigned long node, > + const char *uname, int depth, > + void *data) > +{ > + char *type = of_get_flat_dt_prop(node, "device_type", NULL); > + u32 *prop; > + unsigned l

Re: DTC 1.0.0 Release

On Fri, 2007-08-10 at 11:25 +1000, David Gibson wrote: > On Thu, Aug 09, 2007 at 08:01:33PM -0500, Jon Loeliger wrote: > > Hey guys, > > > > Well, I tagged and released an official DTC v1.0.0 Release > > and pushed it out to jdl.com just now. You can grab the > > git repo directly: > > > > g

Re: DTC 1.0.0 Release Coming?

On Thu, Aug 09, 2007 at 08:37:54PM -0500, Josh Boyer wrote: > On Fri, 10 Aug 2007 11:30:01 +1000 > David Gibson <[EMAIL PROTECTED]> wrote: > > > > Except didn't you say you were going to work with Stephen to get DTC > > > into the kernel source itself? Keeping things similar to Kbuild might > > >

Re: DTC 1.0.0 Release Coming?

David Gibson wrote: >> Except didn't you say you were going to work with Stephen to get DTC >> into the kernel source itself? Keeping things similar to Kbuild might >> help in that effort. > > Actually, after discussions with Stephen and Paulus, we decided not to > take this route. Could you pl

Re: DTC 1.0.0 Release Coming?

On Fri, 10 Aug 2007 11:30:01 +1000 David Gibson <[EMAIL PROTECTED]> wrote: > > Except didn't you say you were going to work with Stephen to get DTC > > into the kernel source itself? Keeping things similar to Kbuild might > > help in that effort. > > Actually, after discussions with Stephen and

Re: DTC 1.0.0 Release Coming?

On Mon, Aug 06, 2007 at 08:48:13AM -0500, Josh Boyer wrote: > On Fri, 27 Jul 2007 11:33:31 +1000 > David Gibson <[EMAIL PROTECTED]> wrote: > > > On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote: > > > So, like, the other day David Gibson mumbled: > > > > > > > > > Only thing I'm not r

Re: DTC 1.0.0 Release

On Thu, Aug 09, 2007 at 08:01:33PM -0500, Jon Loeliger wrote: > Hey guys, > > Well, I tagged and released an official DTC v1.0.0 Release > and pushed it out to jdl.com just now. You can grab the > git repo directly: > > git://www.jdl.com/software/dtc.git > > or download a tarball here: > >

Re: [PATCH v2] cell: move SPU affinity init to spu_management_of_ops

Geoff Levand wrote: > Arnd Bergmann wrote: >> On Saturday 04 August 2007, Geoff Levand wrote: >>> >>> From: Andre Detsch <[EMAIL PROTECTED]> >>> >>> This patch moves affinity initialization code from spu_base.c to a >>> new spu_management_of_ops function (init_affinity), which is empty >>> in the

Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

On Thu, Aug 09, 2007 at 10:00:47PM +0200, Segher Boessenkool wrote: > >> For the JEDEC chips, we need a "vendor-id" and "device-id" > >> property at least (or similar names -- whatever is general > >> practice for this); both are a single byte, encoded as with > >> encode-int. > > > > Ok... should

Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

On Thu, Aug 09, 2007 at 09:53:41PM +0200, Segher Boessenkool wrote: > I haven't heard or thought of anything better either. Using > "ranges" > is conceptually wrong, even ignoring the technical problems that > come > with it. > >>> > >>> Why is "ranges" conceptually wron

Re: [PATCH v3 1/2] [POWERPC] MPC832x_RDB: update dts to use spi, register mmc_spi stub

On Thu, Aug 09, 2007 at 10:15:44PM +0200, Segher Boessenkool wrote: > > Hrm... Freescale is using these 'fsl,device-id' properties, I'm > > guessing they're basically the same thing as the 'cell-index' used in > > the EMAC binding. > > > > We should co-ordinate better on this, if it's to become a >

DTC 1.0.0 Release

Hey guys, Well, I tagged and released an official DTC v1.0.0 Release and pushed it out to jdl.com just now. You can grab the git repo directly: git://www.jdl.com/software/dtc.git or download a tarball here: http://www.jdl.com/software/dtc-1.0.0.tgz As usual, please let me know of any

[PATCH 2/2] pseries: remove dead eeh video code

Remove dead code, and a misleading comment about EEH checking for video devices. The removed code is a left-over from the olden days where there was concern over how video devices worked in Linux. We are never going to go that way again, so kill this. Signed-off-by: Linas Vepstas <[EMAIL PROTE

[PATCH 1/2] pseries: device node status can be "ok" or "okay"

It seems that some versions of firmware will report a device node status as the string "okay". As we are not expecting this string, the device node will be ignored by the EEH subsystem. Which means EEH will not be enabled. When EEH is not enabled, PCI errors will be converted into Machine Check

[PATCH] remove gratuitous reads from powermac pci config space methods

The powermac pci configuration space write methods read the written location immediately after the write is performed, presumably in order to flush the write. However, configuration space writes are not allowed to be posted, making these reads gratuitous. Furthermore, this behavior potentially ca

[PATCH] remove gratuitous reads from pasemi pci config space methods

The pasemi pci configuration space write method reads the written location immediately after the write is performed, presumably in order to flush the write. However, configuration space writes are not allowed to be posted, making these reads gratuitous. Furthermore, this behavior potentially caus

Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods

Segher Boessenkool wrote: > >>It might be worth checking that there isn't a particular reason for > >>these. Just because posting writes are forbidden doesn't mean a > >>particular bridge won't screw it up... > > > >Well, I had already checked with Ben, who wrote the code, and my > >understanding

[PATCH 1/6 v2] pseries: avoid excess rtas calls

We don't need to look up the rtas event token once per cpu per second. This avoids some misc device-tree lookups and string ops and so provides some minor performance improvement. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Revised commit-log message. arch/powerpc/platforms/pseries

[PATCH 6/6 v2] pseries: eliminate global var

Eliminate the use of error_log_cnt as a global var shared across differnt directories. Pass it as a subroutine arg instead. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Respin of earlier patch, with the CONFIG_PSERIES junk removed from the header file. arch/powerpc/kernel/nvram_64.c

Re: [PATCH] powerpc: fix i2c device string format

On Thu, 9 Aug 2007, Segher Boessenkool wrote: > > > strncpy() won't put a terminating zero on there, is everything > > > that uses the resulting string okay with that? Also, if the > > > name gets cut short, it might match some _other_ expected name. > > > > On Wed, 1 Aug 2007, Scott Wood wrote:

Re: [PATCH v3 0/2] SPI support for fsl_soc and mpc832x_rdb

> - cosmetic cleanups (@01 -> @1); That's a correctness fix, not just cosmetics. > - other non-mandatory (device-id, device_type, compatible, ...) > properties removed from mmc node, today board file is using > of_find_node_by_name(), instead of of_find_compatible_node(); That's the

Re: [PATCH v3 1/2] [POWERPC] MPC832x_RDB: update dts to use spi, register mmc_spi stub

> Hrm... Freescale is using these 'fsl,device-id' properties, I'm > guessing they're basically the same thing as the 'cell-index' used in > the EMAC binding. > > We should co-ordinate better on this, if it's to become a > convention... That means we shouldn't coordinate on this, right? Segher _

Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

>> For the JEDEC chips, we need a "vendor-id" and "device-id" >> property at least (or similar names -- whatever is general >> practice for this); both are a single byte, encoded as with >> encode-int. > > Ok... should those really be separate properties, or should that go in > compatible, i.e. som

Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

I haven't heard or thought of anything better either. Using "ranges" is conceptually wrong, even ignoring the technical problems that come with it. >>> >>> Why is "ranges" conceptually wrong? >> >> The flash partitions aren't separate devices sitting on a >> "flash bus",

Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods

On Wed, Aug 08, 2007 at 08:04:32PM -0500, Nathan Lynch wrote: > Benjamin Herrenschmidt wrote: > > On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote: > > > > > > Remove the gratuitous reads from u3_agp_write_config, > > > u3_ht_write_config, and u4_pcie_write_config. > > > > > > Signed-off-by:

Re: [PATCH] powerpc: fix i2c device string format

>> strncpy() won't put a terminating zero on there, is everything >> that uses the resulting string okay with that? Also, if the >> name gets cut short, it might match some _other_ expected name. > > On Wed, 1 Aug 2007, Scott Wood wrote: > >> You could use strlcpy() instead, which always leaves a

Re: [PATCH 05/11] pa_pxp_ops: use named structure member initializers

On Thu, Aug 09, 2007 at 02:18:40PM -0500, Nathan Lynch wrote: > Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> Acked-by: Olof Johansson <[EMAIL PROTECTED]> Thanks! -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman

[PATCH 11/11] tsi108_direct_pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/tsi108_pci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c index 90db8a7..cf0bfbd 100644 --- a/arch/powerpc/sysdev/tsi108_pci.c

[PATCH 10/11] indirect_pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/indirect_pci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c index 5294560..b5d0682 100644 --- a/arch/powerpc/sysdev/indire

[PATCH 09/11] chrp pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/chrp/pci.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/chrp/pci.c b/arch/powerpc/platforms/chrp/pci.c index 28d1647..0c6dba9 100644 --- a/arch/powerpc/platforms/ch

[PATCH 08/11] efika rtas_pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/52xx/efika.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/52xx/efika.c b/arch/powerpc/platforms/52xx/efika.c index 4be6e7a..4263158 100644 --- a/arch/powerpc/platforms/

[PATCH 07/11] null_pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/kernel/pci_32.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c index 04a3109..0e2bee4 100644 --- a/arch/powerpc/kernel/pci_32.c +++ b/arch/power

[PATCH 06/11] powermac pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/powermac/pci.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c index 92586db..69d67ff 100644 --- a/arch/

[PATCH 05/11] pa_pxp_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/pasemi/pci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c index ab1f5f6..882b571 100644 --- a/arch/powerpc/platforms/

[PATCH 04/11] maple pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/maple/pci.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c index 2542403..6247f94 100644 --- a/arch/powerpc/platf

[PATCH 03/11] celleb_epci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/celleb/scc_epci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/celleb/scc_epci.c b/arch/powerpc/platforms/celleb/scc_epci.c index c4b0110..7506acc 100644 --- a/arch/pow

[PATCH 02/11] celleb_fake_pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/platforms/celleb/pci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c index e9ac19c..de8038b 100644 --- a/arch/powerpc/platforms/

[PATCH 01/11] rtas_pci_ops: use named structure member initializers

Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]> --- arch/powerpc/kernel/rtas_pci.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c index a5de621..21f14e5 100644 --- a/arch/powerpc/kernel/rtas_pci.c +++ b/ar

[trivial] use named structure member initializers for pci_ops structures

This series converts all pci_ops structures in arch/powerpc to named member initializers, in accordance with prevailing practice in the kernel. No behavioral or otherwise stylistic changes. arch/powerpc/kernel/pci_32.c |4 ++-- arch/powerpc/kernel/rtas_pci.c |4 ++

Re: [PATCH] powerpc: Pegasos keyboard detection

Segher Boessenkool wrote: >> Would you guys rather we shipped a boot script that ran the OS, fixed >> all these issues in-place in-firmware, so Linux did not have to have >> these >> workarounds, > > Sure, if you can do that, that would be great. Right, so don't accept that keyboard fix, and we

Re: Sequoia 440EPx patches not working

Jerone Young wrote: > So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest > git). I am using Uboot version 1.2.0-gc0c292b2. This is the version > that came with the board. It still appears to hang during early boot on > my Sequoia. > > Trying the cuImage.sequoia.bin.gz just resu

Re: [PATCH] powerpc: Pegasos keyboard detection

>> That's hardly the only reason. But yeah, that's one way to >> implement the workaround, but _we_ (the Linux community) cannot >> do it like that (easily) for all users. > > But you're the guy who told us our firmware sucks and we should fix our > firmware Yes, and? You _should_ fix your firmw

Re: Sequoia 440EPx patches not working

Josh Boyer wrote: > On Thu, 09 Aug 2007 14:58:55 +0400 > Valentine Barshak <[EMAIL PROTECTED]> wrote: > >> David Gibson wrote: >>> On Wed, Aug 08, 2007 at 01:45:10PM -0500, Jerone Young wrote: Using the Sequoia (AMCC 440EPx) patches recently submitted to the list I am unable to boot to f

Re: pci in arch/powerpc vs arch/ppc

> It means the bus on which legacy I/O ports can be found. It's a fairly > broken concept; each host bridge should really be treated as a > completely separate entity, and if something like a VGA card has legacy > I/O ports that need to be used, they should be looked for on the same > PCI bus as t

Re: pci in arch/powerpc vs arch/ppc

Alexandros Kostopoulos wrote: > Hi Scott, > > please allow me to insist a little bit more on this. No problem. :-) > 1. As far as the device tree is concerned, it is defined that the first 3 > numbers in every line of the ranges property (for our case, with #address- > cells=3) is the PCI addr

Re: Sequoia 440EPx patches not working

So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest git). I am using Uboot version 1.2.0-gc0c292b2. This is the version that came with the board. It still appears to hang during early boot on my Sequoia. Trying the cuImage.sequoia.bin.gz just result in Uboot giving "Bad Magic Nu

Re: Sequoia 440EPx patches not working

Nope definitely using a uImage. I'll try a fresh source and try again .. I did base it on kernel.org git tree so I'll try instead with 2.6.23-rc2 and see what happens. n Thu, 2007-08-09 at 16:56 +0400, Vitaly Bordug wrote: > On Wed, 08 Aug 2007 13:45:10 -0500 > Jerone Young wrote: > > > Using the

Re: Sequoia 440EPx patches not working

On Thu, 09 Aug 2007 14:58:55 +0400 Valentine Barshak <[EMAIL PROTECTED]> wrote: > David Gibson wrote: > > On Wed, Aug 08, 2007 at 01:45:10PM -0500, Jerone Young wrote: > >> Using the Sequoia (AMCC 440EPx) patches recently submitted to the > >> list I am unable to boot to fully boot a uImage built

Re: Fix small race in 44x tlbie function

On Thu, 09 Aug 2007 23:05:36 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Thu, 2007-08-09 at 07:04 -0500, Josh Boyer wrote: > > > > > We don't have critical wired to anything, I don't expect watchdog > > to > > > cause another fault.. so just wondering. > > > > We being who? I

Re: Fix small race in 44x tlbie function

On Thu, 2007-08-09 at 07:04 -0500, Josh Boyer wrote: > > > We don't have critical wired to anything, I don't expect watchdog > to > > cause another fault.. so just wondering. > > We being who? I'm slightly confused here. I think Kumar doesn't know that we are talking about the BG kernel whic

Re: Sequoia 440EPx patches not working

On Wed, 08 Aug 2007 13:45:10 -0500 Jerone Young wrote: > Using the Sequoia (AMCC 440EPx) patches recently submitted to the > list I am unable to boot to fully boot a uImage built with these > patches under Uboot. It appears to hang in very early boot. > > > Here is the output: > => tftp 40 >

Re: Fix small race in 44x tlbie function

On Thu, Aug 09, 2007 at 12:28:20AM -0500, Kumar Gala wrote: > >>Did you actually see this happen? > > > >Yes. > > When? During some bluegene debug. > We don't have critical wired to anything, I don't expect watchdog to > cause another fault.. so just wondering. We being who? I'm slightly con

Re: Sequoia 440EPx patches not working

David Gibson wrote: > On Wed, Aug 08, 2007 at 01:45:10PM -0500, Jerone Young wrote: >> Using the Sequoia (AMCC 440EPx) patches recently submitted to the list I >> am unable to boot to fully boot a uImage built with these patches under >> Uboot. It appears to hang in very early boot. > > I'm guessi

Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods

>> It might be worth checking that there isn't a particular reason for >> these. Just because posting writes are forbidden doesn't mean a >> particular bridge won't screw it up... > > Well, I had already checked with Ben, who wrote the code, and my > understanding is that the reads are intended to

[PATCH] IB/ehca: Properly report max #SRQs in query_device()

Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]> --- This patch should apply cleanly on top of Stefan's recent patchset. Please review and apply for 2.6.23. Thanks. drivers/infiniband/hw/ehca/ehca_hca.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/in

Re: [PATCH 0/1] lro: Generic Large Receive Offload for TCP traffic

From: Jeff Garzik <[EMAIL PROTECTED]> Date: Thu, 09 Aug 2007 02:31:11 -0400 > Either way, I'll want you to push to Linus before I do, when the next > merge window opens. No problem. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.o

Re: Fix small race in 44x tlbie function

On Thu, 2007-08-09 at 01:35 -0500, Kumar Gala wrote: > Did you actually see this happen? > >>> > >>> Yes. > >> > >> When? > >> > >> We don't have critical wired to anything, I don't expect watchdog to > >> cause another fault.. so just wondering. > > > > On debug (trace) interrupts on blue gen