* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geert Uytterhoeven @ 2008-01-27 11:15 UTC (permalink / raw)
To: Andrew Morton, Geoff Levand
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Cell Broadband Engine OSS Development, Antonino Daplas
In-Reply-To: <20080127021659.fb6c72a1.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1621 bytes --]
Hi Andrew,
On Sun, 27 Jan 2008, Andrew Morton wrote:
> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > > Hare are the ps3av/fb patches for 2.6.25:
> > >
> > > I would have to say: it's a bit late to be submitting things of this nature
> > > for 2.6.25. Given the mess everyone has made of everything there's little
> > > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > > into mainline without public testing.
> >
> > I beg to disagree (of course :-)
> >
> > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> > you at that time, so they slipped under your radar.
> > But the patches did receive public testing even before that, when they entered
> > Geoff's ps3-linux.git tree.
>
> Should that git tree be in the -mm lineup?
That may be a good idea! Geoff?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Paul Mackerras @ 2008-01-27 11:55 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, LKML
In-Reply-To: <20080126071339.GA25328@balbir.in.ibm.com>
Balbir Singh writes:
> Here's a better and more complete fix for the problem. Could you
> please see if it works for you? I tested it on a real NUMA box and it
> seemed to work fine there.
There are a couple of other changes in behaviour that your patch
introduces, and I'd like to understand them better before taking the
patch. First, with your patch we don't set nodes online if they end
up having no memory in them because of the memory limit, whereas
previously we did. Secondly, in the case where we don't have NUMA
information, we now set node 0 online after adding each LMB, whereas
previously we only set it online once.
If in fact these changes are benign, then your patch description
should mention them and explain why they are benign.
Paul.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Jochen Friedrich @ 2008-01-27 13:42 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Arnd Bergmann, linuxppc-dev, David Gibson
In-Reply-To: <20080108184525.GC18445@localhost.localdomain>
Hi Anton,
> +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct port_regs *regs = mm_gc->regs;
> + u32 pin_mask;
> + u32 tmp_val;
> +
> + /* calculate pin location */
> + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> +
> + tmp_val = in_be32(®s->cpdata);
> +
> + if (val == 0)
> + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> + else
> + out_be32(®s->cpdata, pin_mask | tmp_val);
> +}
I see a possible problem with this (and in the corresponding call in CPM1, as well):
if there is a pin configured as open drain, you might accidently switch this pin to 0
while switching a different pin, if an external device is pulling the pin to 0.
i2c-gpio.c and w1-gpio.c (in -mm) are examples of drivers which use open drain pins
and which would fail if another pin on the same port would be set during a transfer.
Thanks,
Jochen
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Josh Boyer @ 2008-01-27 13:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Frame Buffer Device Development, Antonino Daplas, Cell,
Linux/PPC Development, Andrew Morton, Development
In-Reply-To: <Pine.LNX.4.64.0801271215120.10514@vixen.sonytel.be>
On Sun, 27 Jan 2008 12:15:28 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hi Andrew,
>
> On Sun, 27 Jan 2008, Andrew Morton wrote:
> > > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > > > Hare are the ps3av/fb patches for 2.6.25:
> > > >
> > > > I would have to say: it's a bit late to be submitting things of this nature
> > > > for 2.6.25. Given the mess everyone has made of everything there's little
> > > > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > > > into mainline without public testing.
> > >
> > > I beg to disagree (of course :-)
> > >
> > > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> > > you at that time, so they slipped under your radar.
> > > But the patches did receive public testing even before that, when they entered
> > > Geoff's ps3-linux.git tree.
> >
> > Should that git tree be in the -mm lineup?
>
> That may be a good idea! Geoff?
There are lots of powerpc sub-trees. Kumar's, Geoff's, mine, Olof's,
Grant's, Vitaly's are just the ones I can think of the top of my head.
Shouldn't we just ask Paul to sync up more often rather than have
Andrew track X number of trees that eventually all merge into Paul's
anyway?
josh
^ permalink raw reply
* [ppc] Disparity between sys_clock_getres and vdso implementation
From: Sripathi Kodi @ 2008-01-27 14:02 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel, john stultz
Hi Paul,
On PPC, I see a disparity between clock_getres implementations in the
vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
with CONFIG_HIGH_RES_TIMERS=y.
clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
to be returning some pre-defined (incorrect) variables.
Could you please let me know the reason for this? Is it something that
should be fixed in vdso?
Thanks,
Sripathi.
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-27 15:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, LKML
In-Reply-To: <18332.28991.658933.763115@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> [2008-01-27 22:55:43]:
> Balbir Singh writes:
>
> > Here's a better and more complete fix for the problem. Could you
> > please see if it works for you? I tested it on a real NUMA box and it
> > seemed to work fine there.
>
> There are a couple of other changes in behaviour that your patch
> introduces, and I'd like to understand them better before taking the
> patch. First, with your patch we don't set nodes online if they end
> up having no memory in them because of the memory limit, whereas
> previously we did. Secondly, in the case where we don't have NUMA
> information, we now set node 0 online after adding each LMB, whereas
> previously we only set it online once.
>
> If in fact these changes are benign, then your patch description
> should mention them and explain why they are benign.
>
Yes, they are. I'll try and justify the changes with a good detailed
changelog. If people prefer it, I can hide fake NUMA nodes under a
config option, so that it does not come enabled by default.
Thanks for keeping me honest.
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Michel Dänzer @ 2008-01-27 16:13 UTC (permalink / raw)
To: vatsa; +Cc: Ingo Molnar, Peter Zijlstra, linuxppc-dev
In-Reply-To: <20080126050757.GB14177@linux.vnet.ibm.com>
On Sat, 2008-01-26 at 10:39 +0530, Srivatsa Vaddagiri wrote:
> On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
>
> > > Also were the dd process and the niced processes running under
> > > different user ids? If so, that is expected behavior, that we divide
> > > CPU equally among users first and then among the processes within each user.
Note that in my test case, the niced infinite loop constantly burns
significantly more than 50% of the cycles; X and its clients never need
more than 20% (high estimate) each to move windows smoothly. So even
under the premise above, it should be possible to have smooth
interaction with X while there is a CPU hog in another group, shouldn't
it?
> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
>
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.
FWIW, -1 or 0 for X doesn't seem to make any difference for this
problem.
(I've had X at -1 because a long time ago, when it was at 0 some 3D
games could starve it to the point that their input would be delayed)
> Michel,
> You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> was the cause for this bad behavior.
Well, it may not be the cause, but that's where the hickups with
CONFIG_FAIR_USER_SCHED disabled first manifest themselves, yes.
> Do you see behavior change (from good->bad) immediately after applying that patch
> during your bisect process?
Yes, confirmed by trying that commit and its parent again.
> > > 1. Run niced tasks as root. This would bring X and niced tasks in the
> > > same "scheduler group" domain, which would give X much more CPU power
> > > when compared to niced tasks.
Running the niced CPU hog as root or my user instead of as nobody didn't
seem to make a difference, maybe because the X session requires
interaction between processes having different uids, and disturbing
either is sufficient.
> > > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > > cpu share.
> > > # echo 8192 > /sys/kernel/uids/0/cpu_share
> > >
> > > This should bump up root user's priority for running on CPU and also
> > > give a better desktop experience.
I didn't try 8192, but bumping the shares of root and my user up to 4096
didn't seem to help much if at all. Decreasing the share of the user
running the niced CPU hog to 1 resulted in more or less the same
behaviour as with CONFIG_FAIR_USER_SCHED disabled.
> > > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > > could be. sched-devel has a better load balancer, which I am presuming
> > > will go into 2.6.25 soon.
FWIW, the scheduler changes merged after 2.6.24 don't seem to help at
all for my test:
With CONFIG_FAIR_USER_SCHED enabled, X still becomes unusable.
With CONFIG_FAIR_USER_SCHED disabled, X remains mostly usable, but there
are still hickups that weren't there with 2.6.23. (BTW, the hickups seem
related to top running in the terminal window I'm trying to move;
without top running, there are no hickups when moving the window. With
2.6.23, there are no hickups even with top running)
Note that my test case is an exaggerated example constructed from worse
(than with 2.6.23) interactive behaviour I've been seeing with my
day-to-day X session. This isn't just a theoretical problem.
> > > In this case, I suspect that's not the issue. If X and the niced processes are
> > > running under different uids, this (niced processes getting more cpu power) is
> > > on expected lines. Will wait for Ben to confirm this.
> >
> > I would suggest turning the fair group scheduler to default n in stable
> > for now.
>
> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?
Seems to be the same as with CONFIG_FAIR_GROUP_SCHED disabled
completely.
In summary, there are two separate problems with similar symptoms, which
had me confused at times:
* With CONFIG_FAIR_USER_SCHED disabled, there are severe
interactivity hickups with a niced CPU hog and top running. This
started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8.
* With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
unusable with a niced CPU hog, with or without top running. I
don't know when this started, possibly when this option was
first introduced.
I don't personally care too much about the latter problem - I can live
well without that option. But it would be nice if the former problem
could be fixed (and the default changed from CONFIG_FAIR_USER_SCHED to
CONFIG_FAIR_CGROUP_SCHED) in 2.6.24.x.
FWIW, the patch below (which reverts commit
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8) restores 2.6.24 interactivity
to the same level as 2.6.23 here with CONFIG_FAIR_USER_SCHED disabled
(my previous report to the contrary was with CONFIG_FAIR_USER_SCHED
enabled because I didn't yet realize the difference it makes), but I
don't know if that's the real fix.
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
struct task_struct *curr = rq->curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = &curr->se, *pse = &p->se;
- unsigned long gran;
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se->load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, &se->load);
- if (pse->vruntime + gran < se->vruntime)
+ if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
resched_task(curr);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Jon Loeliger @ 2008-01-27 16:15 UTC (permalink / raw)
To: Josh Boyer
Cc: Linux Frame Buffer Device Development, Antonino Daplas,
Linux/PPC Development, Geert Uytterhoeven, Andrew Morton, Cell,
Development
In-Reply-To: <20080127074230.00adf79d@zod.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
>
> There are lots of powerpc sub-trees. Kumar's, Geoff's, mine, Olof's,
> Grant's, Vitaly's are just the ones I can think of the top of my head.
>
> Shouldn't we just ask Paul to sync up more often rather than have
> Andrew track X number of trees that eventually all merge into Paul's
> anyway?
I think that is an excellent notion.
jdl
^ permalink raw reply
* Linux boot on a ppc 405
From: Ricardo Severo @ 2008-01-27 16:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am working with a Xilinx Virtex II Pro evaluation board, wich has two
PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
Until now I've manged to make it uncompress the kernel, but it doesn't boot.
My question is how the initial execution (the one who uncompresses the
kernel image) transfers the processor to the kernel itself. I've looked
in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
0x0 after uncompressing, is it right? The kernel is uncompressed at that
position?
Thanks,
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Anton Vorontsov @ 2008-01-27 16:08 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <479C8A34.2000701@scram.de>
On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> Hi Anton,
>
> > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > +{
> > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > + struct port_regs *regs = mm_gc->regs;
> > + u32 pin_mask;
> > + u32 tmp_val;
> > +
> > + /* calculate pin location */
> > + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > +
> > + tmp_val = in_be32(®s->cpdata);
> > +
> > + if (val == 0)
> > + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> > + else
> > + out_be32(®s->cpdata, pin_mask | tmp_val);
> > +}
>
> I see a possible problem with this (and in the corresponding call in CPM1, as well):
>
> if there is a pin configured as open drain, you might accidently switch this pin to 0
> while switching a different pin, if an external device is pulling the pin to 0.
Unfortunately I can't think out any workaround for this, except
implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
start using it in the drivers that might care about this issue. Though,
looking into i2c-gpio.c I don't clearly see were we can insert these
locks, there should be "start/end transaction" handlers or something,
but it seems that it's in the bitbanging code, not in the i2c-gpio
driver..
Actually, I see this as a hardware limitation. For example, on ARMs
PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
not all-in-one data register.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: David Baird @ 2008-01-27 18:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <479CAF56.30306@gmail.com>
On Jan 27, 2008 9:20 AM, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> Hi all,
>
> I am working with a Xilinx Virtex II Pro evaluation board, wich has two
> PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> My question is how the initial execution (the one who uncompresses the
> kernel image) transfers the processor to the kernel itself. I've looked
> in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> position?
>
> Thanks,
It should branch to the beginning of arch/ppc/kernel/head_4xx.S, which
I think was 0x0.
Some things to check are:
- Comment/remove the weak embed_config in arch/ppc/boot/simple/misc-embedded.c
- Did you use ttyUL0 or ttyS0 as your console?
If that fails, you can use XMD to set a breakpoint at 0x0 and then
read the memory to see if it matches up with an objdump of vmlinux.
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: David Brownell @ 2008-01-27 18:40 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Linux I2C
In-Reply-To: <20080121114139.3aaa111a@hyperion.delvare>
General comment: if you're going to index arrays by enum
values, it's best to initialize them that way too. Else
you're expecting a particular optional policy for how the
enums get grown...
- Dave
On Monday 21 January 2008, Jean Delvare wrote:
> --- linux-2.6.24-rc8.orig/drivers/rtc/rtc-ds1307.c 2008-01-20 17:26:58.000000000 +0100
> +++ linux-2.6.24-rc8/drivers/rtc/rtc-ds1307.c 2008-01-20 19:03:48.000000000 +0100
> @@ -102,42 +102,36 @@ struct chip_desc {
> char name[9];
> unsigned nvram56:1;
> unsigned alarm:1;
> - enum ds_type type;
> };
>
> static const struct chip_desc chips[] = { {
> .name = "ds1307",
> - .type = ds_1307,
> .nvram56 = 1,
> }, {
So tables like this would become
[ds1307] = { ... },
[ds1337] = { ... },
> .name = "ds1337",
> - .type = ds_1337,
> .alarm = 1,
> }, {
> .name = "ds1338",
> - .type = ds_1338,
> .nvram56 = 1,
> }, {
> .name = "ds1339",
> - .type = ds_1339,
> .alarm = 1,
> }, {
> .name = "ds1340",
> - .type = ds_1340,
> }, {
> .name = "m41t00",
> - .type = m41t00,
> }, };
>
> -static inline const struct chip_desc *find_chip(const char *s)
> -{
> - unsigned i;
> -
> - for (i = 0; i < ARRAY_SIZE(chips); i++)
> - if (strnicmp(s, chips[i].name, sizeof chips[i].name) == 0)
> - return &chips[i];
> - return NULL;
> -}
> +static const struct i2c_device_id ds1307_id[] = {
> + { "ds1307", ds_1307 },
> + { "ds1337", ds_1337 },
> + { "ds1338", ds_1338 },
> + { "ds1339", ds_1339 },
> + { "ds1340", ds_1340 },
> + { "m41t00", m41t00 },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ds1307_id);
>
> static int ds1307_get_time(struct device *dev, struct rtc_time *t)
> {
> @@ -335,12 +329,7 @@ static int __devinit ds1307_probe(struct
> const struct chip_desc *chip;
> struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
>
> - chip = find_chip(client->name);
> - if (!chip) {
> - dev_err(&client->dev, "unknown chip type '%s'\n",
> - client->name);
> - return -ENODEV;
> - }
> + chip = &chips[id->driver_data];
... and that would *ensure* such lines always work right,
no matter how the enum values grow.
>
> if (!i2c_check_functionality(adapter,
> I2C_FUNC_I2C | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: Jon Smirl @ 2008-01-27 19:21 UTC (permalink / raw)
To: David Brownell; +Cc: Jean Delvare, linuxppc-dev, Linux I2C
In-Reply-To: <200801271040.20248.david-b@pacbell.net>
On 1/27/08, David Brownell <david-b@pacbell.net> wrote:
> General comment: if you're going to index arrays by enum
> values, it's best to initialize them that way too. Else
> you're expecting a particular optional policy for how the
> enums get grown...
Even better is the way the m41t80 driver does it. Can we get the base
patch set in first and then do driver clean up in later patches?
>
> - Dave
>
>
> On Monday 21 January 2008, Jean Delvare wrote:
> > --- linux-2.6.24-rc8.orig/drivers/rtc/rtc-ds1307.c 2008-01-20 17:26:58.000000000 +0100
> > +++ linux-2.6.24-rc8/drivers/rtc/rtc-ds1307.c 2008-01-20 19:03:48.000000000 +0100
> > @@ -102,42 +102,36 @@ struct chip_desc {
> > char name[9];
> > unsigned nvram56:1;
> > unsigned alarm:1;
> > - enum ds_type type;
> > };
> >
> > static const struct chip_desc chips[] = { {
> > .name = "ds1307",
> > - .type = ds_1307,
> > .nvram56 = 1,
> > }, {
>
> So tables like this would become
>
> [ds1307] = { ... },
> [ds1337] = { ... },
>
> > .name = "ds1337",
> > - .type = ds_1337,
> > .alarm = 1,
> > }, {
> > .name = "ds1338",
> > - .type = ds_1338,
> > .nvram56 = 1,
> > }, {
> > .name = "ds1339",
> > - .type = ds_1339,
> > .alarm = 1,
> > }, {
> > .name = "ds1340",
> > - .type = ds_1340,
> > }, {
> > .name = "m41t00",
> > - .type = m41t00,
> > }, };
> >
> > -static inline const struct chip_desc *find_chip(const char *s)
> > -{
> > - unsigned i;
> > -
> > - for (i = 0; i < ARRAY_SIZE(chips); i++)
> > - if (strnicmp(s, chips[i].name, sizeof chips[i].name) == 0)
> > - return &chips[i];
> > - return NULL;
> > -}
> > +static const struct i2c_device_id ds1307_id[] = {
> > + { "ds1307", ds_1307 },
> > + { "ds1337", ds_1337 },
> > + { "ds1338", ds_1338 },
> > + { "ds1339", ds_1339 },
> > + { "ds1340", ds_1340 },
> > + { "m41t00", m41t00 },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(i2c, ds1307_id);
> >
> > static int ds1307_get_time(struct device *dev, struct rtc_time *t)
> > {
> > @@ -335,12 +329,7 @@ static int __devinit ds1307_probe(struct
> > const struct chip_desc *chip;
> > struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> >
> > - chip = find_chip(client->name);
> > - if (!chip) {
> > - dev_err(&client->dev, "unknown chip type '%s'\n",
> > - client->name);
> > - return -ENODEV;
> > - }
> > + chip = &chips[id->driver_data];
>
> ... and that would *ensure* such lines always work right,
> no matter how the enum values grow.
>
> >
> > if (!i2c_check_functionality(adapter,
> > I2C_FUNC_I2C | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geoff Levand @ 2008-01-27 20:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Andrew Morton,
Linux Frame Buffer Device Development,
Cell Broadband Engine OSS Development, Antonino Daplas
In-Reply-To: <Pine.LNX.4.64.0801271215120.10514@vixen.sonytel.be>
On 01/27/2008 03:15 AM, Geert Uytterhoeven wrote:
> On Sun, 27 Jan 2008, Andrew Morton wrote:
>> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>> > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
>> > you at that time, so they slipped under your radar.
>> > But the patches did receive public testing even before that, when they entered
>> > Geoff's ps3-linux.git tree.
>>
>> Should that git tree be in the -mm lineup?
>
> That may be a good idea! Geoff?
Sounds good.
ps3-linux.git is used by a lot of active PS3 developers, so
already gets some good testing on PS3, but I think if we get
the stable patches into -mm, then we will get more testing on
non-PS3 platforms, which is something I think we need.
As a start, I'll work toward getting patches from ps3-stable
into -mm. I think it is too late now for the 2.6.25 patches,
so the 'for 2.6.26' ones. To make this work, we (PS3
maintainers) need to get our patches moved from ps3-wip to
ps3-stable in a timely manner. As of late, it seems patches
have lingered in ps3-wip too long.
-Geoff
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Nish Aravamudan @ 2008-01-27 20:22 UTC (permalink / raw)
To: balbir, Paul Mackerras, linuxppc-dev, LKML; +Cc: Mel Gorman
In-Reply-To: <20080127150147.GA10914@balbir.in.ibm.com>
On 1/27/08, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> * Paul Mackerras <paulus@samba.org> [2008-01-27 22:55:43]:
>
> > Balbir Singh writes:
> >
> > > Here's a better and more complete fix for the problem. Could you
> > > please see if it works for you? I tested it on a real NUMA box and it
> > > seemed to work fine there.
> >
> > There are a couple of other changes in behaviour that your patch
> > introduces, and I'd like to understand them better before taking the
> > patch. First, with your patch we don't set nodes online if they end
> > up having no memory in them because of the memory limit, whereas
> > previously we did. Secondly, in the case where we don't have NUMA
> > information, we now set node 0 online after adding each LMB, whereas
> > previously we only set it online once.
> >
> > If in fact these changes are benign, then your patch description
> > should mention them and explain why they are benign.
> >
>
> Yes, they are. I'll try and justify the changes with a good detailed
> changelog. If people prefer it, I can hide fake NUMA nodes under a
> config option, so that it does not come enabled by default.
Sigh, there already *is* a fake NUMA config option: CONFIG_NUMA_EMU.
"CONFIG_NUMA_EMU:
Enable NUMA emulation. A flat machine will be split
into virtual nodes when booted with "numa=fake=N", where N is the
number of nodes. This is only useful for debugging."
I have to assume your patch is implementing the same feature for
powerpc (really just extending the x86_64 one), and thus should share
the config option.
Any chance you can just make some of that code common? Maybe as a
follow-on patch. I expect that some of Mel's (added to Cc) work to
allow NUMA to be set on x86 more easily will flow quite simply into
adding fake NUMA support there as well. So moving the code to a common
place (at least the parsing) makes sense.
I also feel like you want to be able to online memoryless nodes --
that's where we've been hitting a number of bugs lately in the VM. I
can't tell from Paul's comment if your patch prevents that from being
faked or not.
Thanks,
Nish
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Grant Likely @ 2008-01-27 20:59 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <20080127160818.GA25859@zarina>
On 1/27/08, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> > Hi Anton,
> >
> > > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > > +{
> > > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > > + struct port_regs *regs = mm_gc->regs;
> > > + u32 pin_mask;
> > > + u32 tmp_val;
> > > +
> > > + /* calculate pin location */
> > > + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > > +
> > > + tmp_val = in_be32(®s->cpdata);
> > > +
> > > + if (val == 0)
> > > + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> > > + else
> > > + out_be32(®s->cpdata, pin_mask | tmp_val);
> > > +}
> >
> > I see a possible problem with this (and in the corresponding call in CPM1, as well):
> >
> > if there is a pin configured as open drain, you might accidently switch this pin to 0
> > while switching a different pin, if an external device is pulling the pin to 0.
>
> Unfortunately I can't think out any workaround for this, except
> implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
> start using it in the drivers that might care about this issue. Though,
> looking into i2c-gpio.c I don't clearly see were we can insert these
> locks, there should be "start/end transaction" handlers or something,
> but it seems that it's in the bitbanging code, not in the i2c-gpio
> driver..
>
> Actually, I see this as a hardware limitation. For example, on ARMs
> PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
> not all-in-one data register.
I've run into this exact issue on other GPIO hardware too. It's not
uncommon behaviour in GPIO hardware.
The solution is to not depend on the hardware to remember what the
output pin values should be. Add a shadow register in the driver
private data. Set the pin state for each output pin in the shadow
register and then write that value to the hardware. That way input
state doesn't interfere with the output values.
Also, you do still need spinlocks around the manipulation of the
shared registers; otherwise you'll have very hard to debug race
conditions. Probably one spin lock per bank.
Here's what I did for a Xilinx GPIO block driver (but ignore the fact
that I'm not using driver private data so only one GPIO block can be
supported; that will be fixed before I post this driver)
+void gpio_set_value(unsigned gpio, int value)
+{
+ unsigned long flags;
+
+ if (!gpio_regs)
+ return;
+
+ spin_lock_irqsave(&gpio_spinlock, flags);
+ if (value)
+ gpio_output_state |= 1<<gpio;
+ else
+ gpio_output_state &= ~(1<<gpio);
+ out_be32(gpio_regs, gpio_output_state);
+ spin_unlock_irqrestore(&gpio_spinlock, flags);
+}
+EXPORT_SYMBOL_GPL(gpio_set_value);
Cheers,
g.
>
> --
> Anton Vorontsov
> email: cbou@mail.ru
> backup email: ya-cbou@yandex.ru
> irc://irc.freenode.net/bd2
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Load Kernel 2.6 using U-boot on ML403
From: Grant Likely @ 2008-01-27 21:13 UTC (permalink / raw)
To: Yedu Jathavedan; +Cc: linuxppc-embedded
In-Reply-To: <20080126231047.y3lm7epb0gw4cog8@webmail.cecs.pdx.edu>
On 1/27/08, Yedu Jathavedan <yeduj@ece.pdx.edu> wrote:
>
> 1)Downloaded(sourceforge.net) & compiled the U-boot 1.1.6 files to get
> u-boot, u-boot.srec & u-boot.bin (I didn't find ml403 board config for the
> uboot. So used ml300_config).
U-boot 1.1.6 is ancient. The u-boot project has moved off of
sourceforge to denx.de
> After this, I tried to convert the u-boot (README says that this is an ELF
> file) into an ace file. But, it gave me the error saying unable to read elf
> file. Is it because ML403 board is not supported or is it possible that the
> u-boot image that I created is corrupted?
I don't know; but personally I don't weld u-boot into an ace file. I
use a 1st stage bootloader to load the u-boot image off the cf card
(but unfortunately I'm not able to post that loader at this time).
Try again with a recent u-boot version.
> 2) Since generating ace files failed, I tried to search the net for an
> u-boot ace file that could run on ML403 & found it at
> http://88.191.24.164/docenligne/projets/samba/2006/linux-embarque-sur-ml-403/u-boot-ml403.ace/view
>
> I copied this ace file (u-boot-ml403.ace) along with the kernel 2.6 image
> (uImage) onto my CF card & booted the board. After loading the kernel, it
> fails to read the correct root device. I tried changing the "bootargs" env
> variable root = /dev/xsysace/disc0/part2 rw to root = /dev/xsysace2 rw &
> root = /dev/xsda2 rw.
>
> But, it failed in both cases. (There was a previous post on Problem2 a year
> ago & he solved it by giving root =/dev/xsysace2)
Looking at your bootlog, it doesn't look like you've got the systemace
driver built into the kernel.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: Grant Likely @ 2008-01-27 21:15 UTC (permalink / raw)
To: Ricardo Severo; +Cc: linuxppc-embedded
In-Reply-To: <479CAF56.30306@gmail.com>
On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> Hi all,
>
> I am working with a Xilinx Virtex II Pro evaluation board, wich has two
> PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> My question is how the initial execution (the one who uncompresses the
> kernel image) transfers the processor to the kernel itself. I've looked
> in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> position?
Post your output log please.
If your getting a message that the kernel is uncompressing, but you
don't have any output beyond that then most likely your console is not
setup correctly. If you've got a debugger, look at memory at the
__log_buf location to see if there are any boot logs there.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Anton Vorontsov @ 2008-01-27 21:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <fa686aa40801271259k5fd3340bg1b7f29da774be85b@mail.gmail.com>
On Sun, Jan 27, 2008 at 01:59:51PM -0700, Grant Likely wrote:
a> On 1/27/08, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> > > Hi Anton,
> > >
> > > > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > > > +{
> > > > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > > > + struct port_regs *regs = mm_gc->regs;
> > > > + u32 pin_mask;
> > > > + u32 tmp_val;
> > > > +
> > > > + /* calculate pin location */
> > > > + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > > > +
> > > > + tmp_val = in_be32(®s->cpdata);
> > > > +
> > > > + if (val == 0)
> > > > + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> > > > + else
> > > > + out_be32(®s->cpdata, pin_mask | tmp_val);
> > > > +}
> > >
> > > I see a possible problem with this (and in the corresponding call in CPM1, as well):
> > >
> > > if there is a pin configured as open drain, you might accidently switch this pin to 0
> > > while switching a different pin, if an external device is pulling the pin to 0.
> >
> > Unfortunately I can't think out any workaround for this, except
> > implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
> > start using it in the drivers that might care about this issue. Though,
> > looking into i2c-gpio.c I don't clearly see were we can insert these
> > locks, there should be "start/end transaction" handlers or something,
> > but it seems that it's in the bitbanging code, not in the i2c-gpio
> > driver..
> >
> > Actually, I see this as a hardware limitation. For example, on ARMs
> > PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
> > not all-in-one data register.
>
> I've run into this exact issue on other GPIO hardware too. It's not
> uncommon behaviour in GPIO hardware.
>
> The solution is to not depend on the hardware to remember what the
> output pin values should be. Add a shadow register in the driver
> private data. Set the pin state for each output pin in the shadow
> register and then write that value to the hardware. That way input
> state doesn't interfere with the output values.
Great idea, much thanks. Would be easy to implement also.
> Also, you do still need spinlocks around the manipulation of the
> shared registers; otherwise you'll have very hard to debug race
> conditions. Probably one spin lock per bank.
With GPIO LIB we already have per bank spinlock, so it isn't
a problem.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Steve Heflin @ 2008-01-27 23:05 UTC (permalink / raw)
To: linuxppc-embedded
The Sequoia board (AMCC-440EPx processor) is missing from the new
arch/powerpc. The Sequoia board is also missing from arch/ppc , but
there is support for integrated devices on the AMCC part inside
arch/ppc that needs to be incorporated into arch/powerpc. In
addition, there needs to be a "sequoia.c" file added to the
arch/powerpc/44x directory. I have a good start on the missing
pieces and a test platform, is this contribution desired?
- Steve Heflin
New Age Micro
CEO & Software Engineer
At 11:55 AM 1/25/2008, you wrote:
>Just a reminder that the plan is to remove arch/ppc this summer (June
>2008). The following boards still existing over in arch/ppc. Some of
>them have been ported over to arch/powerpc. If you care about one of
>these boards and its not ported speak up (it helps if you have access
>to the board). Also, if you know a given board is free to die of
>bitrot let us know so we know not to worry about it:
>
> PREP
> PQ2ADS
> TQM8260
> CPCI690
> EV64260
> CHESTNUT
> LOPEC
> KATANA
> HDPU
> MVME5100
> PAL4
> POWERPMC250
> PPLUS
> PRPMC750
> PRPMC800
> RADSTONE_PPC7D
> SANDPOINT
> SBC82xx
> SPRUCE
> LITE5200
> EV64360
> MPC86XADS
> MPC885ADS
> ADS8272
>
>4xx:
> BAMBOO
> CPCI405
> EBONY
> EP405
> BUBINGA
> LUAN
> YUCCA
> OCOTEA
> REDWOOD_5
> REDWOOD_6
> SYCAMORE
> TAISHAN
> WALNUT
> XILINX_ML300
> XILINX_ML403
>
>- k
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Olof Johansson @ 2008-01-27 23:39 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080127231214.1F50ADDDE9@ozlabs.org>
Hi,
On Sun, Jan 27, 2008 at 06:05:06PM -0500, Steve Heflin wrote:
> The Sequoia board (AMCC-440EPx processor) is missing from the new
> arch/powerpc. The Sequoia board is also missing from arch/ppc , but
> there is support for integrated devices on the AMCC part inside
> arch/ppc that needs to be incorporated into arch/powerpc. In
> addition, there needs to be a "sequoia.c" file added to the
> arch/powerpc/44x directory. I have a good start on the missing
> pieces and a test platform, is this contribution desired?
2.6.24 already has sequoia support in arch/powerpc. Are you looking at
an older tree?
olof@quad:~/work/linux/k.org $ head arch/powerpc/platforms/44x/sequoia.c
/*
* Sequoia board specific routines
*
* Valentine Barshak <vbarshak@ru.mvista.com>
* Copyright 2007 MontaVista Software Inc.
*
* Based on the Bamboo code by
* Josh Boyer <jwboyer@linux.vnet.ibm.com>
* Copyright 2007 IBM Corporation
*
...
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Steve Heflin @ 2008-01-27 23:37 UTC (permalink / raw)
To: Olof Johansson, linuxppc-embedded
In-Reply-To: <20080127233923.GA5550@lixom.net>
Hello!
Yes! I'm looking at 2.6.23.14 as I thought that was the newest
version. I completely missed seeing the 2.6.24 kit, thank you so much!!
- Steve
At 06:39 PM 1/27/2008, you wrote:
>Hi,
>
>On Sun, Jan 27, 2008 at 06:05:06PM -0500, Steve Heflin wrote:
> > The Sequoia board (AMCC-440EPx processor) is missing from the new
> > arch/powerpc. The Sequoia board is also missing from arch/ppc , but
> > there is support for integrated devices on the AMCC part inside
> > arch/ppc that needs to be incorporated into arch/powerpc. In
> > addition, there needs to be a "sequoia.c" file added to the
> > arch/powerpc/44x directory. I have a good start on the missing
> > pieces and a test platform, is this contribution desired?
>
>2.6.24 already has sequoia support in arch/powerpc. Are you looking at
>an older tree?
>
>olof@quad:~/work/linux/k.org $ head arch/powerpc/platforms/44x/sequoia.c
>/*
> * Sequoia board specific routines
> *
> * Valentine Barshak <vbarshak@ru.mvista.com>
> * Copyright 2007 MontaVista Software Inc.
> *
> * Based on the Bamboo code by
> * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> * Copyright 2007 IBM Corporation
> *
>...
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* PATCH[1/1] 8xx: Add clock-frequency to .dts brg entries
From: Bryan O'Donoghue @ 2008-01-28 1:53 UTC (permalink / raw)
To: linuxppc-dev, scottwood
cpm_uart_core has a dependency on fsl,cpm-brg/clock-frequency, this
means that a .dts that uses the cpm uart driver needs to supply a
clock-frequency entry for get_brgfreq to return a meaningful number.
Included is a patchset which adds the correct brgclk to the adder port -
@ 50Mhz and also adds an entry for mpc885ads - which I've noticed is
missing a clock-frequency entry.
Without an entry for clock-frequency in the .dts you'd get -1 as the
return value brgclk !
Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
---
diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts
b/arch/powerpc/boot/dts/adder875-redboot.dts
index 7c25d96..975f3d4 100644
--- a/arch/powerpc/boot/dts/adder875-redboot.dts
+++ b/arch/powerpc/boot/dts/adder875-redboot.dts
@@ -149,6 +149,7 @@
compatible = "fsl,mpc875-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0x2faf080>;
reg = <0x9f0 0x10>;
};
diff --git a/arch/powerpc/boot/dts/adder875-uboot.dts
b/arch/powerpc/boot/dts/adder875-uboot.dts
index 605202f..18d6dd6 100644
--- a/arch/powerpc/boot/dts/adder875-uboot.dts
+++ b/arch/powerpc/boot/dts/adder875-uboot.dts
@@ -148,6 +148,7 @@
compatible = "fsl,mpc875-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0x2faf080>;
reg = <0x9f0 0x10>;
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 8848e63..f2a437b 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -166,6 +166,7 @@
compatible = "fsl,mpc885-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0>;
reg = <9f0 10>;
};
^ permalink raw reply related
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Josh Boyer @ 2008-01-28 2:00 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080127233751.A6F9EDDDF0@ozlabs.org>
On Sun, 27 Jan 2008 18:37:22 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> Hello!
>
> Yes! I'm looking at 2.6.23.14 as I thought that was the newest
> version. I completely missed seeing the 2.6.24 kit, thank you so much!!
FYI, 2.6.24 is considered fairly old relatively speaking. With so much
activity going on for the embedded boards for arch/powerpc, you're sort
of missing out if you aren't running from the latest git trees.
Yes, I realize how ridiculous it sounds to say a kernel that was just
released 3 days ago is old, but that's reality.
josh
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Steve Heflin @ 2008-01-28 3:37 UTC (permalink / raw)
To: Josh Boyer, linuxppc-embedded
In-Reply-To: <20080127200044.148982a6@zod.rchland.ibm.com>
At 09:00 PM 1/27/2008, Josh wrote:
>On Sun, 27 Jan 2008 18:37:22 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > Hello!
> >
> > Yes! I'm looking at 2.6.23.14 as I thought that was the newest
> > version. I completely missed seeing the 2.6.24 kit, thank you so much!!
>
>FYI, 2.6.24 is considered fairly old relatively speaking. With so much
>activity going on for the embedded boards for arch/powerpc, you're sort
>of missing out if you aren't running from the latest git trees.
>
>Yes, I realize how ridiculous it sounds to say a kernel that was just
>released 3 days ago is old, but that's reality.
>
>josh
Hey Josh, thank you so much for the pointer to the git trees. I've
been using Linus' kernel.org tree, as that's where I was pointed to
by the powerpc web site about 2 months ago. I sure do appreciate your
updated pointer to the git tree, I will now locate it and stay tuned
and participate.
steve
^ 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