* Re: [PATCH] Fake NUMA emulation for PowerPC
From: Balbir Singh @ 2007-12-08 4:32 UTC (permalink / raw)
To: David Rientjes; +Cc: linuxppc-dev, Nathan Lynch, LKML
In-Reply-To: <alpine.DEB.0.9999.0712071510370.27689@chino.kir.corp.google.com>
David Rientjes wrote:
> On Sat, 8 Dec 2007, Balbir Singh wrote:
>
>> Yes, they all appear on node 0. We could have tweaks to distribute CPU's
>> as well.
>>
>
> You're going to want to distribute the cpu's based on how they match up
> physically with the actual platform that you're running on. x86_64 does
Could you explain this better, how does it match up CPU's with fake NUMA
memory? Is there some smartness there? I'll try and look at the code and
also see what I can do for PowerPC
> this already and it makes fake NUMA more useful because it matches the
> real-life case more often.
Yes, I agree, but I don't want that to be the first step for fake NUMA
nodes on PowerPC. I think we can incrementally add features.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: David Rientjes @ 2007-12-08 4:45 UTC (permalink / raw)
To: Balbir Singh; +Cc: linuxppc-dev, Nathan Lynch, LKML
In-Reply-To: <475A1E6E.3010303@linux.vnet.ibm.com>
On Sat, 8 Dec 2007, Balbir Singh wrote:
> > You're going to want to distribute the cpu's based on how they match up
> > physically with the actual platform that you're running on. x86_64 does
>
> Could you explain this better, how does it match up CPU's with fake NUMA
> memory? Is there some smartness there? I'll try and look at the code and
> also see what I can do for PowerPC
>
numa_cpumask_lookup_table[] would return the correct cpumask for the fake
node index. Then all the code that uses node_to_cpumask() in generic
kernel code like the scheduler and VM still preserve their true NUMA
affinity that matches the underlying hardware. I tried to make x86_64
fake NUMA as close to the real thing as possible.
You also probably want to make all you changes dependent on
CONFIG_NUMA_EMU like the x86_64 case. That'll probably be helpful as you
extend this tool more and more.
David
^ permalink raw reply
* Please pull linux-2.6-8xx.git for-paulus branch
From: Vitaly Bordug @ 2007-12-08 10:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org
Paul,
please do
git-pull git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git for-paulus
to receive the following updates:
Jochen Friedrich (4):
powerpc: fix typo #ifdef -> #ifndef
powerpc: kill non-existent symbols from ksyms and commproc.h
powerpc: Add support for PORTA and PORTB odr registers
powerpc: Move CPM command handling into the cpm drivers
Scott Wood (1):
8xx: Convert mpc866ads to the new device binding.
arch/powerpc/boot/dts/mpc866ads.dts | 156 +++++++++------
arch/powerpc/kernel/ppc_ksyms.c | 12 -
arch/powerpc/platforms/8xx/Kconfig | 1 +
arch/powerpc/platforms/8xx/mpc86xads.h | 44 ----
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 289 +++++++-------------------
arch/powerpc/sysdev/commproc.c | 47 ++++-
arch/powerpc/sysdev/cpm2_common.c | 25 +++
drivers/net/fs_enet/mac-fcc.c | 10 +-
drivers/net/fs_enet/mac-scc.c | 13 +-
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6 +-
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 8 +-
include/asm-powerpc/commproc.h | 3 -
include/asm-powerpc/cpm.h | 1 +
13 files changed, 250 insertions(+), 365 deletions(-)
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Vitaly Bordug @ 2007-12-08 10:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20071208130025.09021cb0@kernel.crashing.org>
On Sat, 8 Dec 2007 13:00:25 +0300
Vitaly Bordug wrote:
> Paul,
>
> please do
> git-pull
> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git
> for-paulus
>
> to receive the following updates:
>
Forgot to tell that this is .25 material...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [DTC][PATCH] Fix cross-compile building
From: Stuart Hughes @ 2007-12-08 12:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20071208003604.GH566@localhost.localdomain>
On Sat, 2007-12-08 at 11:36 +1100, David Gibson wrote:
> On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
> > From: Stuart Hughes <stuarth@freescale.com>
> >
> > This patch allows you to build the DTC source without making the
> > tests directory. This is necessary when cross compiling as the
> > dumptest (and other) files cannot be run/used on the host system.
> > To use this use: 'make TESTS='
>
> I think this is a silly way of doing this. Instead create a new
> target which builds everything but the tests.
>
> Say,
>
> all: cross tests
>
> cross: dtc ftdump libfdt
>
Works for me.
Regards, Stuart
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Kumar Gala @ 2007-12-08 15:17 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071208130934.093d80f9@kernel.crashing.org>
On Dec 8, 2007, at 4:09 AM, Vitaly Bordug wrote:
> On Sat, 8 Dec 2007 13:00:25 +0300
> Vitaly Bordug wrote:
>
>> Paul,
>>
>> please do
>> git-pull
>> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git
>> for-paulus
>>
>> to receive the following updates:
>>
> Forgot to tell that this is .25 material...
Vitaly, if you don't mind I'll pull these into my tree for Paul to
collect all the FSL stuff in one place.
- k
^ permalink raw reply
* mmap + segfaults on MPC8349E
From: R. Ebersole (VTI - new) @ 2007-12-09 2:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
Hi.
We've run into an .... interesting (and frustrating) occurance recently
while testing
out a new board (and BSP). We were wondering if anybody has seen anything
like this.
A description follows:
We wrote some simple drivers/modules to mmap() FPGA registers to user space.
At the moment, for testing, we reserve the upper x-MB of RAM, and mmap()
there, instead.
We open 4 such devices, and mmap() 64KB of space (memory, in this case)
for each.
Accessing the first device opened & mmapped was fine. But accesssing
the 2nd device
yielded some odd behavior. We could read and write the first and 3rd 4K
regions fine, but
if we read from the 2nd one (at offset 0x1000) before we wrote to it, we
get a segmentation
fault. If, however, we wrote first (to the 2nd region), then things
were OK.
Addendum: With the real device, this same behavior happens at the 10th
4-KB region of the device.
Without any of the others mmap()-ed. If we mmap() just that 4-KB
region, things are fine. We
can access the region with ioremap() in the driver w/o issues.
We are running on an MPC8349-E.
Any thoughts or ideas?
vti
--
This message contains confidential information and is intended only for the
individual named. If you are not the intended recipient you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
[-- Attachment #2: Type: text/html, Size: 1987 bytes --]
^ permalink raw reply
* Re: mmap + segfaults on MPC8349E
From: David Hawkins @ 2007-12-09 4:01 UTC (permalink / raw)
To: R. Ebersole (VTI - new); +Cc: linuxppc-embedded
In-Reply-To: <475B5680.30303@valleytech.com>
Hi,
You haven't really provided enough information.
> We wrote some simple drivers/modules to mmap() FPGA registers to user space.
> At the moment, for testing, we reserve the upper x-MB of RAM, and mmap()
> there, instead.
1. The FPGA is located where? The local bus, or the PCI bus?
What frequency are you trying to operate at?
2. If its on the local bus, do you access it using GPCM or UPM?
Have you setup either correctly?
Have you confirmed the bus timing with a logic analyzer?
3. Have you created a bus functional model of the processor bus
that you have then run with your FPGA bus in ModelSim to
confirm that your FPGA performs correctly.
4. Have you tried burst and non-burst access by either using
DMA, or treating the memory area as cacheable or non-cacheable?
Have you checked those cases with simulation and then
with a scope or logic analyzer?
5. Did you try running stand-alone tests in U-Boot, to go for a
more bare-metal debug approach?
No point in debugging software if you have no idea whether the
hardware behaves. So confirm that you have tested your hardware
first.
My board design uses the MPC8349EA, I have an Altera Stratix II
FPGA on the local bus. I use GPCM to access flash on the local
bus via the FPGA, and UPM to access FPGA registers. I don't
have boards yet, but I've got a pretty good handle on how the
interface should work.
Cheers,
Dave
^ permalink raw reply
* Stupid git question: adding acked-by
From: Jerry Van Baren @ 2007-12-09 5:21 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
OK git gurus, this is something I have not figured out: the best way to
add acked-by (or additional signed-off-by) lines to git patches.
What I'm talking about is when I've applied a patch to my repo and
published the change on the list and get an "acked-by" back. By the
time I get the ack, the acked patch may be several patches deep. My
current technique is to reset the repo, edit the patch(es) to add the
"acked-by" lines, and then re-apply the patches. PITA and probably the
stupidest way.
Stacked git should work (effectively does the same thing but more
gracefully), but I have not gone that route yet.
There must be a better way, if only I could find the right (of 137)
git-* command...
Hints, please?
Thanks,
gvb
^ permalink raw reply
* Xilinx ML310 Linux 2.6 PCI bridge
From: Jean-Samuel Chenard @ 2007-12-09 5:51 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]
Hi,
Thanks to the valuable information provided by this discussion group and
particularly by Grant Likely from Secret Lab Technologies, I was able to
setup and run Linux 2.6 on my ML-310 development platform.
On the ML-310, if I want to use the Ethernet port and some other
peripherals, I need to go through the PCI bus via the opb_pci core on the
FPGA.
However, when I enable PCI support in the kernel, I get the following error
messages:
arch/ppc/syslib/ppc4xx_setup.c: In function `ppc4xx_map_io':
arch/ppc/syslib/ppc4xx_setup.c:118: error: `PPC4xx_PCI_IO_VADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:118: error: (Each undeclared identifier is
reported only once
arch/ppc/syslib/ppc4xx_setup.c:118: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_PADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:119: error: `PPC4xx_PCI_IO_SIZE' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:120: error: `PPC4xx_PCI_CFG_VADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_PADDR' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:121: error: `PPC4xx_PCI_CFG_SIZE' undeclared
(first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:122: error: `PPC4xx_PCI_LCFG_VADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_PADDR'
undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_setup.c:123: error: `PPC4xx_PCI_LCFG_SIZE' undeclared
(first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_setup.o] Error 1
My Xilinx Platform Studio has the proper PCI bridge component, but the
exported constants in xparameters_ml300.h are not helping me figure out the
mapping that I should give to those PPC4xx values (the parameters contain a
lot of XPAR_PCI32_BRIDGE_* constants). I'm guessing that the address
mappings must be set from some of those for the PCI range to appear in the
PowerPC address space. Please correct me if I'm misunderstanding something
here...
I only saw one mention of this error related to the ML-310 in a discussion
dating in 2005 and the answer was that the 2.6 kernel was not supporting the
Virtex-II Pro too well at the time. Has this changed and does anyone have
had success using the PCI bridge in Linux 2.6 on an ML-310 development
platform ?
Thanks,
Jean-Samuel
--
Integrated Microsystems Laboratory
McGill University, Montréal, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
[-- Attachment #2: Type: text/html, Size: 2814 bytes --]
^ permalink raw reply
* Re: Stupid git question: adding acked-by
From: Geoff Levand @ 2007-12-09 6:04 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <475B7B41.4000505@gmail.com>
On 12/08/2007 09:21 PM, Jerry Van Baren wrote:
> OK git gurus, this is something I have not figured out: the best way to
> add acked-by (or additional signed-off-by) lines to git patches.
>
> What I'm talking about is when I've applied a patch to my repo and
> published the change on the list and get an "acked-by" back. By the
> time I get the ack, the acked patch may be several patches deep. My
> current technique is to reset the repo, edit the patch(es) to add the
> "acked-by" lines, and then re-apply the patches. PITA and probably the
> stupidest way.
>
> Stacked git should work (effectively does the same thing but more
> gracefully), but I have not gone that route yet.
>
> There must be a better way, if only I could find the right (of 137)
> git-* command...
I keep patches in a repo. I just update the patch header and commit.
-Geoff
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Grant Likely @ 2007-12-09 6:18 UTC (permalink / raw)
To: Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <169c03cb0712082151k74e504bvc6e21bb57534ef28@mail.gmail.com>
On 12/8/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> Hi,
>
> Thanks to the valuable information provided by this discussion group and
> particularly by Grant Likely from Secret Lab Technologies, I was able to
> setup and run Linux 2.6 on my ML-310 development platform.
Congratulations. If you had to make any changes to get it to work
then please send me your patches.
>
> On the ML-310, if I want to use the Ethernet port and some other
> peripherals, I need to go through the PCI bus via the opb_pci core on the
> FPGA.
>
> However, when I enable PCI support in the kernel, I get the following error
> messages:
You'll have to go back into the mailing list archives to find a patch
for adding PCI support for a Virtex platform. I don't have any of
that in my tree. It probably only exists for the 2.4 kernel. You'll
need to port forward to use it on 2.6 (I'm more than willing to help
you with this)
However, word of warning. The Xilinx PCI bridge is badly broken.
Xilinx is not supporting the PCI core and it is missing the ability to
do certain types of transfers. Last I heard, Xilinx has no plans to
fix their PCI core either.
Best of luck,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Stupid git question: adding acked-by
From: Grant Likely @ 2007-12-09 6:22 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <475B7B41.4000505@gmail.com>
On 12/8/07, Jerry Van Baren <gvb.linuxppc.dev@gmail.com> wrote:
> Stacked git should work (effectively does the same thing but more
> gracefully), but I have not gone that route yet.
This is my preferred solution, but you don't have to do it this way.
>
> There must be a better way, if only I could find the right (of 137)
> git-* command...
Try git-cherry-pick. Get a list of the SHA-1 patch ids and reset your
branch. Then cherry pick each patch with the -e flag. Git will pull
up an editor and let you edit the commit message before applying so
you can add the Acked-by line.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Stupid git question: adding acked-by
From: Stephen Rothwell @ 2007-12-09 6:43 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <475B7B41.4000505@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Sun, 09 Dec 2007 00:21:05 -0500 Jerry Van Baren <gvb.linuxppc.dev@gmail.com> wrote:
>
> OK git gurus, this is something I have not figured out: the best way to
> add acked-by (or additional signed-off-by) lines to git patches.
Have a look at "git rebase -i"
--
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 16/25] powerpc: EP405 boards support for arch/powerpc
From: Benjamin Herrenschmidt @ 2007-12-09 6:57 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071206210550.520e5131@zod.rchland.ibm.com>
On Thu, 2007-12-06 at 21:05 -0600, Josh Boyer wrote:
> On Thu, 06 Dec 2007 19:00:15 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> > Index: linux-work/arch/powerpc/boot/dts/ep405.dts
> > ===================================================================
> > --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-work/arch/powerpc/boot/dts/ep405.dts 2007-12-03 12:58:45.000000000 +1100
> > @@ -0,0 +1,221 @@
> > +/*
> > + * Device Tree Source for EP405
> > + *
> > + * Copyright 2007 IBM Corp.
> > + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> I still don't think I wrote this ;)
Yeah, right, I'll fix that, easy enough.
.../...
> > + if (!machine_is(ep405))
> > + return 0;
> > +
> > + /* FIXME: do bus probe here */
>
> I should really remove this stupid FIXME from my files so people stop
> copying it into theirs ;)
Yup :-) Your fault ;-)
.../...
> > + /* Find the bloody thing & map it */
> > + bcsr_node = of_find_compatible_node(NULL, NULL, "ep405-bcsr");
> > + if (bcsr_node == NULL) {
> > + printk(KERN_ERR "EP405 BCSR not found !\n");
> > + return;
> > + }
> > + bcsr_regs = of_iomap(bcsr_node, 0);
> > + if (bcsr_regs == NULL) {
> > + printk(KERN_ERR "EP405 BCSR failed to map !\n");
> > + return;
> > + }
>
> Is there a reason you have bcsr_node and bcsr_regs as static globals
> and leave the mapping present? I can't see another use of them outside
> of this function, which only gets called once.
For future use mostly. There's truckloads of things on this board going
trough this FPGA and It's likely that a more complete port will need to
use this things. In fact, the CPLD can more/less be used as a cascaded
IRQ on the PCI interrupts on that thing.
Ben.
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-12-09 7:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071206211758.6f086161@zod.rchland.ibm.com>
> > +config TAISHAN
> > + bool "Taishan"
> > + depends on 44x
> > + default n
> > + select 440GX
> > + help
> > + This option enables support for the IBM PPC440GX "Taishan" evaluation board.
>
> AMCC Taishan board.
Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
he's the author).
> > + /* Ebony has all 4 IRQ pins tied together per slot */
>
> This isn't an Ebony board. Does Taishan do the same?
The comment is bogus, the mapping is correct (and doesn't match the
comment, I just forgot to remove it after copy/pasting :-)
Ben.
^ permalink raw reply
* Re: [PATCH 19/25] powerpc: Wire up PCI on Bamboo board
From: Benjamin Herrenschmidt @ 2007-12-09 7:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071206211906.2e1c099f@zod.rchland.ibm.com>
> > + /* Walnut has all 4 IRQ pins tied together per slot */
>
> Not a Walnut board.
Right, though the IRQ routing is similar (the comment is correct)
> > + interrupt-map-mask = <f800 0 0 0>;
> > + interrupt-map = <
> > + /* IDSEL 1 */
> > + 0800 0 0 0 &UIC0 1c 8
> > +
> > + /* IDSEL 2 */
> > + 1000 0 0 0 &UIC0 1b 8
> > +
> > + /* IDSEL 3 */
> > + 1800 0 0 0 &UIC0 1a 8
> > +
> > + /* IDSEL 4 */
> > + 2000 0 0 0 &UIC0 19 8
> > + >;
> > + };
> > };
> >
> > chosen {
> > linux,stdout-path = "/plb/opb/serial@ef600300";
> > - bootargs = "console=ttyS0,115200";
>
> Did you remove that for a reason?
Yes, and I want to do a pass removing all the occurences of bootargs in
the .dts file, it has absolutely nothing to do there (in theory nothing
in /chosen though linux,stdout-path can probably be argued and happens
to be handy but not bootargs).
Ben.
^ permalink raw reply
* Re: [PATCH 21/25] powerpc: Adds decoding of 440SPE memory size to boot wrapper library
From: Benjamin Herrenschmidt @ 2007-12-09 7:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071206212235.4ff38139@zod.rchland.ibm.com>
On Thu, 2007-12-06 at 21:22 -0600, Josh Boyer wrote:
> On Thu, 06 Dec 2007 19:00:20 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > This adds a function to the bootwrapper 4xx library to decode memory
> > size on 440SPE processors.
>
> Why did you rename the fixup_memsize function? Could you add that to
> the changelog, and perhaps a bit about adding the SDRAM0_{READ,WRITE}
> macros
Because there's 3 fixup_*_memsize functions, felt it would be better
that they all have distinctive names no ? I don't see the need of
altering the changelog tho... If you don't know what those macros stand
for you probably should stay clear from those registers anyway.
Ben.
^ permalink raw reply
* Re: [PATCH 11/25] powerpc: 4xx PLB to PCI Express support
From: Benjamin Herrenschmidt @ 2007-12-09 7:07 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200712070802.01126.sr@denx.de>
On Fri, 2007-12-07 at 08:02 +0100, Stefan Roese wrote:
>
> > Ah... crap ! Do you think we should put that in the boot wrapper and
> > fixup the device-tree or should we put it in the PCIe code proper ?
>
> How about this: We change the compatible node to "plb-pciex-440spe"
> (without "A" and "B) and make a PVR runtime detection in the 4xx-pci
> driver.
>
> What do you think? Should I prepare a patch for this?
I suppose that's the best way though we should do the detection the
other way around form the old code, that is detect rev A explicitely and
consider everything else rev B (just in case some new rev ever
appears..)
Yes, I would appreciate a patch, thanks.
Ben.
^ permalink raw reply
* Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Benjamin Herrenschmidt @ 2007-12-09 7:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <4759A870.8030900@pobox.com>
On Fri, 2007-12-07 at 15:09 -0500, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > From: Stefan Roese <sr@denx.de>
> >
> > This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 39 insertions(+)
>
> applied 1-11 #upstream-fixes
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 23/25] powerpc: Rework 4xx clock probing in boot wrapper
From: Benjamin Herrenschmidt @ 2007-12-09 7:05 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071206212744.7257f1a2@zod.rchland.ibm.com>
On Thu, 2007-12-06 at 21:27 -0600, Josh Boyer wrote:
> On Thu, 06 Dec 2007 19:00:22 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Index: linux-work/arch/powerpc/boot/reg.h
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/boot/reg.h 2007-12-03 14:26:09.000000000 +1100
> > +++ linux-work/arch/powerpc/boot/reg.h 2007-12-03 14:26:09.000000000 +1100
> > @@ -24,6 +24,14 @@ static inline u32 mfpvr(void)
> > : "=r" (rval)); rval; })
> > #define mtspr(rn, v) asm volatile("mtspr " __stringify(rn) ",%0" : : "r" (v))
> >
> > +#define __stringify_1(x) #x
> > +#define __stringify(x) __stringify_1(x)
> > +
> > +#define mfspr(rn) ({unsigned long rval; \
> > + asm volatile("mfspr %0," __stringify(rn) \
> > + : "=r" (rval)); rval; })
> > +#define mtspr(rn, v) asm volatile("mtspr " __stringify(rn) ",%0" : : "r" (v))
> > +
>
> You felt like duplicating this? It was added in the previous patch. :)
Ah yes, it's a typical mistake when splitting patches, sometimes, it
doesn't complain when the same hunk is applied multiple times. I'll fix
that up.
Ben.
^ permalink raw reply
* Re: [PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
From: Benjamin Herrenschmidt @ 2007-12-09 7:16 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-pci, linux-kernel
In-Reply-To: <20071207010001.GA23575@kroah.com>
On Thu, 2007-12-06 at 17:00 -0800, Greg KH wrote:
> But that is how we already handle this today, in numerous places in
> the
> kernel for this very type.
>
> So, you can disagree that this is what we need to do, and if so, feel
> free to fix up a whole lot of files in the tree :)
Heh, ok, allright, I'll respin with the casts.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 19/19] [POWERPC] pci_controller->arch_data really is a struct device_node *
From: Benjamin Herrenschmidt @ 2007-12-09 7:27 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20071207020542.577bbfe8.sfr@canb.auug.org.au>
On Fri, 2007-12-07 at 02:05 +1100, Stephen Rothwell wrote:
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
Ah excellent, I had that on my to-do list for some time. However, we
should also rename it as I'm getting more and more pressure to put a
real void * arch_data in here for use by a specific PCI host bridge
implementation...
Cheers,
Ben.
^ permalink raw reply
* Re: Powerpc PCI cleanups (mainly iSeries)
From: Benjamin Herrenschmidt @ 2007-12-09 7:29 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <20071206094448.4de7967a@zod.rchland.ibm.com>
On Thu, 2007-12-06 at 09:44 -0600, Josh Boyer wrote:
> On Fri, 7 Dec 2007 02:07:26 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > On Thu, 6 Dec 2007 18:00:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > I started out looking for ways to remove our dependencies on pci_dn and
> > > got sidetracked into clening up the iSeries PCI code. The intention of
> > > the following set of patches is that there be no semantic changes
> > > (mostly).
> >
> > Some of these will clearly conflict with Benh's PCI work. We will sot
> > that out between us. :-)
>
> In the meantime...
>
> My tree is going to carry BenH's patches since they're obviously
> important to 4xx. If these conflicts get sorted out soon, that would
> be good :). At some point I'm going to start sending stuff to Paul.
The PCI merge serie of my patches shoudn't go through your tree (it's a
separate serie from my 4xx stuff and isn't quite ready just yet...).
I'll sync with Stephen.
Cheers,
Ben.
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Vitaly Bordug @ 2007-12-09 8:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <CF849773-F9A6-45D1-A36E-9A350BE5FB6D@kernel.crashing.org>
On Sat, 8 Dec 2007 09:17:06 -0600
Kumar Gala wrote:
>
> On Dec 8, 2007, at 4:09 AM, Vitaly Bordug wrote:
>
> > On Sat, 8 Dec 2007 13:00:25 +0300
> > Vitaly Bordug wrote:
> >
> >> Paul,
> >>
> >> please do
> >> git-pull
> >> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git
> >> for-paulus
> >>
> >> to receive the following updates:
> >>
> > Forgot to tell that this is .25 material...
>
> Vitaly, if you don't mind I'll pull these into my tree for Paul to
> collect all the FSL stuff in one place.
>
I'm ok with either way.
--
Sincerely, Vitaly
^ 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