* 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
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: Pavel Machek @ 2007-12-09 13:16 UTC (permalink / raw)
To: Balbir Singh; +Cc: LKML, linuxppc-dev, David Rientjes, Olof Johansson
In-Reply-To: <475A1BEE.2050109@linux.vnet.ibm.com>
On Sat 2007-12-08 09:52:06, Balbir Singh wrote:
> David Rientjes wrote:
> > On Sat, 8 Dec 2007, Balbir Singh wrote:
> >
> >> To be able to test the memory controller under NUMA, I use fake NUMA
> >> nodes. x86-64 has a similar feature, the code I have here is the
> >> simplest I could come up with for PowerPC.
> >>
> >
> > Magnus Damm had patches from over a year ago that, I believe, made much of
> > the x86_64 fake NUMA code generic so that it could be extended for
> > architectures such as i386. Perhaps he could resurrect those patches if
> > there is wider interest in such a tool.
>
> That would be a very interesting patch, but what I have here is the
> simplest patch and we could build on it incrementally. The interface is
> non-standard but it does amazing things for 59 lines of code change.
Well, maybe it is amazing, but having non-standard interface is also
wrong...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: Balbir Singh @ 2007-12-09 13:20 UTC (permalink / raw)
To: Pavel Machek; +Cc: Olof Johansson, linuxppc-dev, LKML, David Rientjes
In-Reply-To: <20071209131636.GF4381@ucw.cz>
Pavel Machek wrote:
> On Sat 2007-12-08 09:52:06, Balbir Singh wrote:
>> David Rientjes wrote:
>>> On Sat, 8 Dec 2007, Balbir Singh wrote:
>>>
>>>> To be able to test the memory controller under NUMA, I use fake NUMA
>>>> nodes. x86-64 has a similar feature, the code I have here is the
>>>> simplest I could come up with for PowerPC.
>>>>
>>> Magnus Damm had patches from over a year ago that, I believe, made much of
>>> the x86_64 fake NUMA code generic so that it could be extended for
>>> architectures such as i386. Perhaps he could resurrect those patches if
>>> there is wider interest in such a tool.
>> That would be a very interesting patch, but what I have here is the
>> simplest patch and we could build on it incrementally. The interface is
>> non-standard but it does amazing things for 59 lines of code change.
>
> Well, maybe it is amazing, but having non-standard interface is also
> wrong...
>
I tend to agree with you, but in this case it's mostly debug
infrastructure that is architecture specific.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: Powerpc PCI cleanups (mainly iSeries)
From: Josh Boyer @ 2007-12-09 14:40 UTC (permalink / raw)
To: benh; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <1197185366.6572.43.camel@pasglop>
On Sun, 09 Dec 2007 18:29:26 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> 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 wasn't talking about your series of 10 patches. You'll have
conflicts in your series of 25 too, though those should be fairly minor.
josh
^ permalink raw reply
* Re: Kernel symbol version history
From: David H. Lynch Jr. @ 2007-12-09 16:41 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <200712051807.36357.jcd@tribudubois.net>
Thank you.
I made use of one of the linux cross reference sites.
Though unless I don't know how to effectively use them trying to
track the history of a function, typdef, define, ..
is not particularly easy using lxr.
Grant's sugestion with git was closer to what I was looking for -
except that in some instances
needed to go back farther than it would take me..
Jean-Christophe Dubois wrote:
> Hi David,
>
> You could try the various "linux cross reference" web site out there. It is
> not necessarily complete (some linux version might be missing) but it can be
> usefull to lookup if some symbols/define/typedef were available in a
> particular Linux version.
>
> Have a look there.
>
> http://free-electrons.com/community/kernel/lxr
>
> Regards
>
> JC
>
> On Wednesday 05 December 2007 17:17:25 David H. Lynch Jr. wrote:
>
>> This might be slightly OT here, but would anyone know where there
>> might be a reference that indicates at precisely what version a given
>> symbol either appeared or disappeared within the Linux kernel ?
>>
>> As an example if a driver is supposed to work for 2.6 and 2.4 and
>> uses sysfs, or cdev, or alloc_chr_dev_region or ...
>> How can one tell at what point that api or symbol appeared so that
>> the proper conditionals appear within the driver.
>>
>> The last one that bit me was I made a collection of casting changes
>> to address 64bit vs. 32bit targets, and found that using the C99 fixed
>> size types - uint32_t, ... made life much more pleasant, after putting
>> them I nobody else could build because uintptr_t did not appear until
>> 2.6.24, and I still have not figured out exactly when uint32_t etc.
>> appeared.
>>
>> I would think there ought to be some resource besides group memory
>> to look this up ?
>> Is there a way to use git to look back through the history of a
>> symbol rather than a file.
>>
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Olof Johansson @ 2007-12-09 17:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <1197183715.6572.8.camel@pasglop>
On Sun, Dec 09, 2007 at 06:01:55PM +1100, Benjamin Herrenschmidt wrote:
> Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
> he's the author).
I didn't see him Cc:d on the patch submission, and I'm guessing Josh did
a reply-all. Seems as if the mailing list manager strips Cc fields of
people already subscribed to the list, I've seen it before.
-Olof
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Jean-Samuel Chenard @ 2007-12-09 17:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40712082218k7e520e45q1266ecb4692b7dbb@mail.gmail.com>
On Dec 9, 2007 1:18 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 12/8/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> > Thanks to the valuable information provided by this discussion group an=
d
> > particularly by Grant Likely from Secret Lab Technologies, I was able t=
o
> > 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.
Thank you for the quick reply.
I will directly update Secret Lab's Wiki pages. Those pages are the
ones that got me going really quickly, so I will add a few of my
observations directly on your pages so everyone can benefit.
I ended up using Secret Lab's GIT tree as my source archive, so I'll
let you know if I need to fix some code.
> 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)
Hmmm... I'm not really ready to invest that much time into the PCI for ML-3=
10.
My real target is the control FPGA on a BEE2 box
(http://bee2.eecs.berkeley.edu) and on that particular setup, the
control FPGA is directly connected to an LXT971A Ethernet PHY, so I'll
use the ethernet MAC from Xilinx.
I use the ML-310 as a stepping stone for quickly prototyping some of
my FPGA changes since the VirtexII-Pro in the ML-310 is much smaller
and doesn't eat up all my workstation resources when re-compiling the
FPGA.
> 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.
Ok, its nice to know the status of that module. Too bad Xilinx is
dropping the support for it.
In that case, it would probably be more beneficial for all to adapt an
"open core" project such as this PCI bridge:
http://www.opencores.org/projects.cgi/web/pci/home
Along with the help of an OPB to Wishbone wrapper like that one:
http://www.opencores.org/projects.cgi/web/opb_wb_wrapper/overview
With some work (and ideally some PCI expertise) one could get an open
implementation of a PCI bridge that can integrate in the Xilinx EDK
flow and could be repaired or adapted as time goes... I am a complete
newbie to PCI, so I'll leave that to some willing "hacker".
I'll continue on my quest to run Linux 2.6 on the BEE2 control FPGA.
There is no PCI bus involved in that architecture. Just raw buses and
a sea of FPGA logic.
Regards,
Jean-Samuel
--=20
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Josh Boyer @ 2007-12-09 18:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071209172404.GA26651@lixom.net>
On Sun, 9 Dec 2007 11:24:04 -0600
Olof Johansson <olof@lixom.net> wrote:
> On Sun, Dec 09, 2007 at 06:01:55PM +1100, Benjamin Herrenschmidt wrote:
>
> > Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
> > he's the author).
>
> I didn't see him Cc:d on the patch submission, and I'm guessing Josh did
> a reply-all. Seems as if the mailing list manager strips Cc fields of
> people already subscribed to the list, I've seen it before.
Yeah, I just did Reply-to-all. I've never seen CC's be stripped
though. Anyway, I'll try to remember in the future.
josh
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-12-09 19:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <20071209172404.GA26651@lixom.net>
On Sun, 2007-12-09 at 11:24 -0600, Olof Johansson wrote:
> On Sun, Dec 09, 2007 at 06:01:55PM +1100, Benjamin Herrenschmidt wrote:
>
> > Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
> > he's the author).
>
> I didn't see him Cc:d on the patch submission, and I'm guessing Josh did
> a reply-all. Seems as if the mailing list manager strips Cc fields of
> people already subscribed to the list, I've seen it before.
Yeah, my script for mailing quilt series doesn't do the selective CC
thingy... Bah, mpe wrote it, I suppose I can either nag him to fix it or
start learning perl :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Olof Johansson @ 2007-12-09 20:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071209122408.40d8a865@vader.jdub.homelinux.org>
On Sun, Dec 09, 2007 at 12:24:08PM -0600, Josh Boyer wrote:
> Yeah, I just did Reply-to-all. I've never seen CC's be stripped
> though. Anyway, I'll try to remember in the future.
Actually, my mail that you replied to had your address stripped off the
Cc list when it came out on the list (at least for me). :-)
It was on it when I sent it though.
-Olof
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Grant Likely @ 2007-12-09 20:23 UTC (permalink / raw)
To: Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <169c03cb0712090932y52cb2744p245cdeb0cccc2ff2@mail.gmail.com>
On 12/9/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> On Dec 9, 2007 1:18 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 12/8/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> > > 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.
>
> Thank you for the quick reply.
No problem.
>
> I will directly update Secret Lab's Wiki pages. Those pages are the
> ones that got me going really quickly, so I will add a few of my
> observations directly on your pages so everyone can benefit.
Much appreciated; thank you!
> My real target is the control FPGA on a BEE2 box
> (http://bee2.eecs.berkeley.edu) and on that particular setup, the
> control FPGA is directly connected to an LXT971A Ethernet PHY, so I'll
> use the ethernet MAC from Xilinx.
Cool platform. Yes, you should have much better luck with the EMAC
core. The driver needs some work to be acceptable for mainline, but
it should be functional.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 20:24 UTC (permalink / raw)
To: i2c, linuxppc-dev, Jean Delvare
In-Reply-To: <20071203212032.23543.3453.stgit@terra.home>
What is the status of this series, is there anything I can do to help
get this into the i2c subsystem?
On 12/3/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> The following series implements standard linux module aliasing for i2c modules
> It then converts the mpc i2c driver from being a platform driver to an open
> firmware one. I2C device names are picked up from the device tree. Module
> aliasing is used to translate from device tree names into to linux kernel
> names. Several i2c drivers are updated to use the new aliasing.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
> _______________________________________________
> i2c mailing list
> i2c@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-09 20:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <9e4733910712091224mcb43f0ci69f578d221505ba7@mail.gmail.com>
On Sun, Dec 09, 2007 at 03:24:55PM -0500, Jon Smirl wrote:
> What is the status of this series, is there anything I can do to help
> get this into the i2c subsystem?
I never saw the comments about whitespace cleanups being addressed. If
you run them through checkpatch you'll see quite a few things that needs
fixups. Care to do the round of cleanups and repost the series?
Besides that I'm fine with the approach of moving the matching to the
i2c layer, it does seem like a reasonable thing to do.
-Olof
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Benjamin Herrenschmidt @ 2007-12-09 20:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <9e4733910712091224mcb43f0ci69f578d221505ba7@mail.gmail.com>
On Sun, 2007-12-09 at 15:24 -0500, Jon Smirl wrote:
> What is the status of this series, is there anything I can do to help
> get this into the i2c subsystem?
I think there were a few comments such as whitespace issues and Scott
had a comment about a tag to differenciate matching type.
Thus the expectation is that you'll respin the serie with those
addressed.
Ben.
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 20:57 UTC (permalink / raw)
To: benh; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <1197233208.6563.14.camel@pasglop>
On 12/9/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-12-09 at 15:24 -0500, Jon Smirl wrote:
> > What is the status of this series, is there anything I can do to help
> > get this into the i2c subsystem?
>
> I think there were a few comments such as whitespace issues and Scott
> had a comment about a tag to differenciate matching type.
Are there technical concerns with this series? The white space can be
fixed in a few minutes.
Adding a tag to differentiate matching types has implications that are
broader than just i2c. Shouldn't we do this first with the existing
scheme and then change the tagging process with later patches?
>
> Thus the expectation is that you'll respin the serie with those
> addressed.
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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