* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven @ 2007-07-16 12:59 UTC (permalink / raw)
To: Jens Axboe
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <20070716121649.GI5195@kernel.dk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1342 bytes --]
On Mon, 16 Jul 2007, Jens Axboe wrote:
> On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > I'll update my patches. Thanks for the comments!
> >
> > Does this look OK?
> > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > (ps3rom))
>
> That looks good.
>
> > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
>
> Hmm, I would have thought a flush_dcache_page() would be more
> appropriate, the backing could be page cache pages.
OK, I'll change it to flush_dcache_page().
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 v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-16 12:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <D575BC2B-0554-4290-A6D0-D4FEEE691C11@kernel.crashing.org>
>>>> Actually I see no good reason to enforce no-exec at all if we
>>>> can't do
>>>> it consistently. And if we're not going to enforce it then
>>>> there is
>>>> no point whinging about it.
>>>
>>>
>>> I have a new patch with just this behaviour, Scott is
>>> testing it on old glibc (I think it succeeded, need
>>> confirmation though),
>>
>> It worked fine on glibc 2.2.5 and 2.3.3 (the former of which failed
>> without the patch).
>
> It sounds like this is a candidate for stable 2.6.22.x as well
Yes, it replaces the previous patch and is a bugfix to it.
> once you release the patch.
The only reason I didn't send it out immediately was to not
confuse things further with a broken patch ;-)
Segher
^ permalink raw reply
* Re: Legacy ISA registers/interrupts in PCI device tree node
From: Segher Boessenkool @ 2007-07-16 12:40 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070716075317.15260@gmx.net>
> I wonder, if there is a recommended way to specify ISA register
> addresses
> and interrupts for a PCI device (unlike for a PCI2ISA bridge)?
The PCI binding describes the required way to do this.
> The device in question is the integrated IDE controller of the VIA686B
> southbridge, which works in compatible/legacy mode and thus uses
> interrupts
> 14 and 15 of the i8259 PIC. Should the fdt contain this information
Yes, it should, even if you don't use this in the Linux
kernel yet.
> or should I hardcode the values in the platform setup code?
No.
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Jens Axboe @ 2007-07-16 12:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707161338230.1072@pademelon.sonytel.be>
On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > I'll update my patches. Thanks for the comments!
>
> Does this look OK?
> - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> (ps3rom))
That looks good.
> - Add a call to flush_kernel_dcache_page() in routines that write to buffers
Hmm, I would have thought a flush_dcache_page() would be more
appropriate, the backing could be page cache pages.
--
Jens Axboe
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Segher Boessenkool @ 2007-07-16 12:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: James Bottomley, Arnd Bergmann, linux-scsi, linux-kernel,
Alessandro Rubini, linuxppc-dev, Paul Mackerras, Jens Axboe,
Geert Uytterhoeven
In-Reply-To: <1184368328.6059.271.camel@localhost.localdomain>
>> I'm pretty sure that no ppc64 machine needs alias resolution in
>> the kernel,
>> although some are VIPT. Last time we discussed this, Segher
>> explained it
>> to me, but I don't remember which way Cell does it. IIRC, it
>> automatically
>> flushes cache lines that are accessed through aliases.
>
> Ah yes, I remember reading about this automatic flushing thing. I
> don't
> know how the caches actually work on most of our PPC's, but the
> fact is,
> we don't have aliasing issues, so I can safely ignore it for a bit
> longer :-)
That is the very short version of the story, yes: some
PowerPC implementations are VIPT physically, but there
are no aliasing issues we have to worry about.
Anyone interested in how this works, can download the
PPC970 UM (or 970FX or 970MP); it has a very detailed
explanation of all this. Cell might be slightly different
but the base idea is the same.
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven @ 2007-07-16 11:43 UTC (permalink / raw)
To: James Bottomley, Jens Axboe
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707132212520.23000@chinchilla.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3186 bytes --]
On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> Ah, that explains it. flush_dcache_page() is used in some drivers.
> I'll update my patches. Thanks for the comments!
Does this look OK?
- Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
interrupt handler, from .request_fn (ps3disk), or from .queuecommand
(ps3rom))
- Add a call to flush_kernel_dcache_page() in routines that write to buffers
If this is OK, I'll fold it into my original patch series and will resend.
Thanks!
---
drivers/block/ps3disk.c | 5 +++--
drivers/scsi/ps3rom.c | 9 +++++----
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -109,13 +109,14 @@ static void ps3disk_scatter_gather(struc
bio_sectors(bio), sector);
bio_for_each_segment(bvec, bio, j) {
size = bio_cur_sectors(bio)*KERNEL_SECTOR_SIZE;
- buf = __bio_kmap_atomic(bio, j, KM_USER0);
+ buf = __bio_kmap_atomic(bio, j, KM_IRQ0);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- __bio_kunmap_atomic(bio, KM_USER0);
+ flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
+ __bio_kunmap_atomic(bio, KM_IRQ0);
}
sectors += bio_sectors(bio);
i++;
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -112,7 +112,7 @@ static int fill_from_dev_buffer(struct s
active = 1;
for (k = 0, req_len = 0, act_len = 0; k < cmd->use_sg; ++k, ++sgpnt) {
if (active) {
- kaddr = kmap_atomic(sgpnt->page, KM_USER0);
+ kaddr = kmap_atomic(sgpnt->page, KM_IRQ0);
if (!kaddr)
return -1;
len = sgpnt->length;
@@ -121,7 +121,8 @@ static int fill_from_dev_buffer(struct s
len = buflen - req_len;
}
memcpy(kaddr + sgpnt->offset, buf + req_len, len);
- kunmap_atomic(kaddr, KM_USER0);
+ flush_kernel_dcache_page(sgpnt->page);
+ kunmap_atomic(kaddr, KM_IRQ0);
act_len += len;
}
req_len += sgpnt->length;
@@ -149,7 +150,7 @@ static int fetch_to_dev_buffer(struct sc
sgpnt = cmd->request_buffer;
for (k = 0, req_len = 0, fin = 0; k < cmd->use_sg; ++k, ++sgpnt) {
- kaddr = kmap_atomic(sgpnt->page, KM_USER0);
+ kaddr = kmap_atomic(sgpnt->page, KM_IRQ0);
if (!kaddr)
return -1;
len = sgpnt->length;
@@ -158,7 +159,7 @@ static int fetch_to_dev_buffer(struct sc
fin = 1;
}
memcpy(buf + req_len, kaddr + sgpnt->offset, len);
- kunmap_atomic(kaddr, KM_USER0);
+ kunmap_atomic(kaddr, KM_IRQ0);
if (fin)
return req_len + len;
req_len += sgpnt->length;
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
* WDT with 82xx
From: Matvejchikov Ilya @ 2007-07-16 11:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
Does anybody use watchdog timer with mpc82xx?
^ permalink raw reply
* Re: [patch] use __attribute__ in asm-powerpc
From: Andreas Schwab @ 2007-07-16 9:30 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Mike Frysinger, linux-kernel, paulus
In-Reply-To: <Pine.LNX.4.62.0707161117150.1072@pademelon.sonytel.be>
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> writes:
> If the code is not exported to userspace (and thus not subject to different
> compilers), I think the preferred form is plain `attribute'.
That does not exist without underscores.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [patch] use __attribute__ in asm-powerpc
From: Robert P. J. Day @ 2007-07-16 9:20 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: paulus, Mike Frysinger, linux-kernel, linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0707161117150.1072@pademelon.sonytel.be>
On Mon, 16 Jul 2007, Geert Uytterhoeven wrote:
> On Sat, 14 Jul 2007, Mike Frysinger wrote:
> > Pretty much everyone uses "__attribute__" or "attribute", no one
> > uses "__attribute". This patch tweaks the three places in asm-powerpc where
> > this comes up. While only asm-powerpc/types.h is interesting (for userspace),
> > I did asm-powerpc/processor.h as well for consistency.
> >
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> > ---
> > diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
> > index d947b16..2ce6ea6 100644
> > --- a/include/asm-powerpc/processor.h
> > +++ b/include/asm-powerpc/processor.h
> > @@ -153,9 +153,9 @@ struct thread_struct {
> > unsigned long dabr; /* Data address breakpoint register */
> > #ifdef CONFIG_ALTIVEC
> > /* Complete AltiVec register set */
> > - vector128 vr[32] __attribute((aligned(16)));
> > + vector128 vr[32] __attribute__((aligned(16)));
>
> If the code is not exported to userspace (and thus not subject to
> different compilers), I think the preferred form is plain
> `attribute'.
compiler-gcc.h also defines the common form of the shortcut:
#define __aligned(x) __attribute__((aligned(x)))
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: [patch] use __attribute__ in asm-powerpc
From: Geert Uytterhoeven @ 2007-07-16 9:18 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <200707142336.10343.vapier@gentoo.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1595 bytes --]
On Sat, 14 Jul 2007, Mike Frysinger wrote:
> Pretty much everyone uses "__attribute__" or "attribute", no one
> uses "__attribute". This patch tweaks the three places in asm-powerpc where
> this comes up. While only asm-powerpc/types.h is interesting (for userspace),
> I did asm-powerpc/processor.h as well for consistency.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> ---
> diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
> index d947b16..2ce6ea6 100644
> --- a/include/asm-powerpc/processor.h
> +++ b/include/asm-powerpc/processor.h
> @@ -153,9 +153,9 @@ struct thread_struct {
> unsigned long dabr; /* Data address breakpoint register */
> #ifdef CONFIG_ALTIVEC
> /* Complete AltiVec register set */
> - vector128 vr[32] __attribute((aligned(16)));
> + vector128 vr[32] __attribute__((aligned(16)));
If the code is not exported to userspace (and thus not subject to different
compilers), I think the preferred form is plain `attribute'.
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: possible dead CONFIG-related content under arch/powerpc
From: Geert Uytterhoeven @ 2007-07-16 9:16 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux PPC Mailing List
In-Reply-To: <Pine.LNX.4.64.0707141816470.9751@localhost.localdomain>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 852 bytes --]
On Sat, 14 Jul 2007, Robert P. J. Day wrote:
> ========== SPE_BASE ==========
> arch/powerpc/mm/hash_utils_64.c:612:#ifdef CONFIG_SPE_BASE
> arch/powerpc/mm/hash_utils_64.c:747:#ifdef CONFIG_SPE_BASE
Interesting, should this one be CONFIG_SPU_BASE?
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 1/1] libata: pata_pdc2027x PLL input clock fix
From: Albert Lee @ 2007-07-16 9:12 UTC (permalink / raw)
To: Mikael Pettersson
Cc: dwm, jeff, linux-ide, bahadir.balban, linuxppc-dev, alan
In-Reply-To: <200707111026.l6BAQ5kh003472@harpo.it.uu.se>
Mikael Pettersson wrote:
> On Wed, 11 Jul 2007 10:45:35 +0800, Albert Lee wrote:
>
>>So, it seems both mdelay(37) and do_gettimeofday() are working properly on PowerMac G3.
>>Maybe the calculated wrong PLL input is due to wrong reading of the counter register?
>>Could you please try the attached debug patch for more clue, thanks.
>
>
> This, supposedly debug-only, patch gives me much better PLL calibration:
>
> pata_pdc2027x 0000:00:0e.0: version 0.9
> bccrh [0] bccrl [0]
> bccrhv[0] bccrlv[0]
> bccrh [7FCF] bccrl [15ED]
> bccrhv[7FCF] bccrlv[15D4]
> start[0] end[1072141805]
> usec_elapsed for mdelay(100) [105500]
> start time: [1184152411]s [689475]us
> end time: [1184152411]s [794975]us
> PLL input clock[-1563248254]Hz
> usec_elapsed for mdelay(37) [35432]
> start time: [1184152411]s [818033]us
> end time: [1184152411]s [853465]us
> bccrh [7FC9] bccrl [1A4B]
> bccrhv[7FC9] bccrlv[1A4B]
> bccrh [7F98] bccrl [3038]
> bccrhv[7F98] bccrlv[301F]
> start[1071946315] end[1070346296]
> usec_elapsed for mdelay(100) [103571]
> start time: [1184152411]s [874717]us
> end time: [1184152411]s [978288]us
> PLL input clock[15440000]Hz
> usec_elapsed for mdelay(37) [35431]
> start time: [1184152411]s [997039]us
> end time: [1184152412]s [32470]us
> pata_pdc2027x 0000:00:0e.0: PLL input clock 15440 kHz
>
> and from then on things are fine.
>
> Weird. I'll try with an older gcc later (been using gcc-4.2.0 so far).
>
Is the problem reproducible with more reload loops? Maybe we could try
something like:
#!/bin/sh
while : ; do
rmmod pata_pdc2027x
sleep 1
modprobe pata_pdc2027x
done
and "tail -f /var/log/messages|grep PLL > pll_test.log" to check the
PLL clock.
--
albert
^ permalink raw reply
* Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
From: Geert Uytterhoeven @ 2007-07-16 9:09 UTC (permalink / raw)
To: Ranulf Doswell
Cc: Cell Broadband Engine OSS Development, Linux/PPC Development
In-Reply-To: <18a15270707130949u44a5b428ia16755b6a268e3d2@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1251 bytes --]
On Fri, 13 Jul 2007, Ranulf Doswell wrote:
> > > > Since 720p is a broadcast mode, I can't make it default to fullscreen,
> > as a
> > > > part of the image will fall off on most monitors.
> >
> > > Do you have any info from the EDID block that would tell you whether the
> > > monitor displays the full picture (typical of flat panels) or not ?
> >
>
> That's not always true anyway. My 1680x1050 panel, for instance, displays
> 1080i/p and 720p as stretched images with the edges slightly off the screen.
> It's great for TV, but *really* irritating with the PS3!
So I guess you're interested in a feature called `configurable black borders'?
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: Legacy ISA registers/interrupts in PCI device tree node
From: Matt Sealey @ 2007-07-16 8:59 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070716075317.15260@gmx.net>
Gerhard,
You could do a LOT worse than check the Pegasos.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Gerhard Pircher wrote:
> Hi,
>
> I wonder, if there is a recommended way to specify ISA register addresses
> and interrupts for a PCI device (unlike for a PCI2ISA bridge)?
> The device in question is the integrated IDE controller of the VIA686B
> southbridge, which works in compatible/legacy mode and thus uses interrupts
> 14 and 15 of the i8259 PIC. Should the fdt contain this information or
> should I hardcode the values in the platform setup code?
>
> Thanks!
>
> Regards,
>
> Gerhard
^ permalink raw reply
* Legacy ISA registers/interrupts in PCI device tree node
From: Gerhard Pircher @ 2007-07-16 7:53 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I wonder, if there is a recommended way to specify ISA register addresses
and interrupts for a PCI device (unlike for a PCI2ISA bridge)?
The device in question is the integrated IDE controller of the VIA686B
southbridge, which works in compatible/legacy mode and thus uses interrupts
14 and 15 of the i8259 PIC. Should the fdt contain this information or
should I hardcode the values in the platform setup code?
Thanks!
Regards,
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Michael Ellerman @ 2007-07-16 7:40 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20070716065144.GH1678@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]
On Mon, 2007-07-16 at 08:51 +0200, Robert Schwebel wrote:
> On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote:
> > Your approach would work I suppose.... though it's a bit ugly.
>
> Speaking of uggly, I'm still wondering why this oftree stuff for powerpc
> must be soooo complicated. If you come from the ARM-linux world like we
> do, the whole powerpc BSP stuff looks like a completely overengineered
> piece of code, introducing complexity where it isn't necessary. But it
> may be that it's just me not knowing powerpc kernel requirements deeply
> enough :)
And I don't know anything about ARM, so let's trade uninformed
opinions ... :)
# cd arch/arm
# du -sk kernel/ mach-* | sort -nk 1
16 mach-l7200
16 mach-s3c2400
24 mach-clps7500
24 mach-s3c2442
32 mach-iop33x
32 mach-rpc
32 mach-shark
36 mach-ebsa110
40 mach-aaec2000
48 mach-h720x
48 mach-ks8695
52 mach-iop32x
56 mach-davinci
60 mach-ixp23xx
60 mach-ns9xxx
60 mach-s3c2443
68 mach-clps711x
68 mach-s3c2412
72 mach-netx
72 mach-realview
72 mach-versatile
76 mach-s3c2440
80 mach-ep93xx
80 mach-imx
88 mach-ixp2000
96 mach-iop13xx
96 mach-lh7a40x
108 mach-pnx4008
124 mach-footbridge
124 mach-integrator
140 mach-ixp4xx
140 mach-s3c2410
252 mach-sa1100
272 mach-omap2
296 mach-omap1
296 mach-pxa
332 mach-at91
428 kernel/
# cd arch/powerpc
# du -sk kernel/ sysdev/ platforms/* | sort -nk 1
8 platforms/prep
12 platforms/4xx
24 platforms/44x
40 platforms/82xx
44 platforms/86xx
52 platforms/8xx
52 platforms/embedded6xx
56 platforms/maple
60 platforms/83xx
64 platforms/85xx
64 platforms/chrp
72 platforms/52xx
72 platforms/pasemi
140 platforms/celleb
212 platforms/ps3
280 platforms/iseries
300 platforms/pseries
412 platforms/powermac
412 sysdev/
544 platforms/cell (spufs shared with ps3 (and celleb?))
1636 kernel/
Not to mention that ~8 of those platforms can be built into a single
vmlinux that will boot on any of the supported machines, including five
different hypervisors.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Benjamin Herrenschmidt @ 2007-07-16 7:29 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20070716071936.GK1678@pengutronix.de>
On Mon, 2007-07-16 at 09:19 +0200, Robert Schwebel wrote:
> I think it is a fundamental thing: the "we just have to wait long
> enough, until oftree definitions have settled" proposal just isn't
> right. It may be right for big irons, being well defined. But for the
> embedded processors, too less people are working on it, plus we have too
> much things which could be defined. Speaking of the MPC5200, look at how
> often device tree names change, e.g. for mpc5200 vs. mpc52xx vs.
> whatever. As long as things change, you have to keep the three locations
> in sync manually, and that's b
I wouldn't expect things to change that much. I think MPC52xx is a bad
example of a worst case scenario. Also, as the core group of people
working on linux/ppc get more familiar with the device-tree, we should
get things right more quickly.
In the end, the problem with the device-tree is also it's strongest
advantage: it's extremely flexible :-) So yes, that causes that sort of
problem, but don't ignore the whole lot of problems that it solves by
not having to hard code knowledge of the gazillion ways a given chip can
be setup in drivers or the ability to pass along ancilliary informations
such as MAC addresses, UUIDs, etc... from the firmware to selected
devices in the tree, or the sane interrupt & address mapping (that's
really the two main reasons in fact).
Ben.
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Robert Schwebel @ 2007-07-16 7:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1184569752.25235.46.camel@localhost.localdomain>
On Mon, Jul 16, 2007 at 05:09:12PM +1000, Benjamin Herrenschmidt wrote:
> As I wrote a couple of times already, it's a perfectly acceptable
> approach to have "constructors" (what you call oftree-interpreter) that
> generate platform devices from the OF tree.
Great!
> > mapping. Is there a reason why there is sooo much interaction of the
> > platform code with the oftree? We usually have the situation that, if
> > something goes wrong, you have to change
> >
> > - the driver
> > - the platform code
> > - the oftree
>
> There should generally be no need to change the platform code.
Well, in reality it is, because for example the MPC52xx PSC SPI
controller we are currently working was obviously never tested with
oftree before it hit the mainline ...
> > and they often contain redundant information (like names of oftree
> > nodes, which change more often than some people's panties).
>
> Well, they aren't supposed to :-) The problem at this point is more due
> to the fact that for things that haven't been specified by official OF
> bindings, people are going all over trying to define their own and
> sometimes conflicting bindings and then changing them.
I think it is a fundamental thing: the "we just have to wait long
enough, until oftree definitions have settled" proposal just isn't
right. It may be right for big irons, being well defined. But for the
embedded processors, too less people are working on it, plus we have too
much things which could be defined. Speaking of the MPC5200, look at how
often device tree names change, e.g. for mpc5200 vs. mpc52xx vs.
whatever. As long as things change, you have to keep the three locations
in sync manually, and that's bad.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Benjamin Herrenschmidt @ 2007-07-16 7:09 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev
In-Reply-To: <20070716065144.GH1678@pengutronix.de>
On Mon, 2007-07-16 at 08:51 +0200, Robert Schwebel wrote:
> On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote:
> > Your approach would work I suppose.... though it's a bit ugly.
>
> Speaking of uggly, I'm still wondering why this oftree stuff for powerpc
> must be soooo complicated. If you come from the ARM-linux world like we
> do, the whole powerpc BSP stuff looks like a completely overengineered
> piece of code, introducing complexity where it isn't necessary. But it
> may be that it's just me not knowing powerpc kernel requirements deeply
> enough :)
>
> For most of the devices on for example the MPC5200B and MPC8260 I would
> just model them as platform devices; there could be a simple
>
> oftree -> oftree-interpreter -> bunch of platform devices
As I wrote a couple of times already, it's a perfectly acceptable
approach to have "constructors" (what you call oftree-interpreter) that
generate platform devices from the OF tree.
Since any struct device in the system can be associated with an OF
device node, it's actually not that interesting anymore to use something
such as of_platform_device or in general, subclasses of of_device unless
this is a platform native bus (such as sbus on sparc, or ebus on power)
that makes no sense to use without OF.
One of the idea I have for the long term but didn't have time to
implement is typically to have a bunch of generic constructors that
register to match against device name/type/compatible triplets, and are
called as part a boot time initial device-tree walk, generating the
various linux devices on the fly. This could also generate PCI devices,
thus replacing the separate walk path done by ppc64, but it could be
used to generate any type of linux device, not necessarily OF-derivative
ones, but platform devices too etc...
I just haven't had time to work on that yet. You are welcome to beat me
to it.
Note that a lot of the complexity is mostly perceived complexity due to
some of the stupid endless debates we've been having on this list. For
things like interrupt mapping, for example, the OF tree is a very useful
and very flexible representation that makes things a lot simpler on the
kernel side when you start having multiple levels of cascaded interrupt
controllers.
> mapping. Is there a reason why there is sooo much interaction of the
> platform code with the oftree? We usually have the situation that, if
> something goes wrong, you have to change
>
> - the driver
> - the platform code
> - the oftree
There should generally be no need to change the platform code.
> and they often contain redundant information (like names of oftree
> nodes, which change more often than some people's panties).
Well, they aren't supposed to :-) The problem at this point is more due
to the fact that for things that haven't been specified by official OF
bindings, people are going all over trying to define their own and
sometimes conflicting bindings and then changing them.
Ben.
^ permalink raw reply
* Re: How to add platform specific data to a of_device
From: Robert Schwebel @ 2007-07-16 6:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1184446133.6059.284.camel@localhost.localdomain>
On Sun, Jul 15, 2007 at 06:48:53AM +1000, Benjamin Herrenschmidt wrote:
> Your approach would work I suppose.... though it's a bit ugly.
Speaking of uggly, I'm still wondering why this oftree stuff for powerpc
must be soooo complicated. If you come from the ARM-linux world like we
do, the whole powerpc BSP stuff looks like a completely overengineered
piece of code, introducing complexity where it isn't necessary. But it
may be that it's just me not knowing powerpc kernel requirements deeply
enough :)
For most of the devices on for example the MPC5200B and MPC8260 I would
just model them as platform devices; there could be a simple
oftree -> oftree-interpreter -> bunch of platform devices
mapping. Is there a reason why there is sooo much interaction of the
platform code with the oftree? We usually have the situation that, if
something goes wrong, you have to change
- the driver
- the platform code
- the oftree
and they often contain redundant information (like names of oftree
nodes, which change more often than some people's panties).
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: XSysAce driver cant mount DOS part
From: urwithsudheer @ 2007-07-16 5:08 UTC (permalink / raw)
To: Robertson, Joseph M.; +Cc: linuxppc-embedded
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A1720A@hsv1dafpew02.das.gov.sanm.corp>
[-- Attachment #1: Type: text/plain, Size: 6767 bytes --]
Hi Joe Robertson,
Thanks for the link.
In the xsa_thread function, can u try changing the hardcoded coded value
"2" to "xsa_cur_req->current_nr_sectors "
The actual code in the given link.
for(i = xsa_cur_req->current_nr_sectors; i > 0; i-=2){
+ xsa_device.req_done = 1;
+ while ((stat = cur_req(&SysAce, sector,
+ 2,
+ buffer)) == XST_DEVICE_BUSY)
+ xsa_short_delay();
Try changing it to ...
for(i = xsa_cur_req->current_nr_sectors; i > 0;
i-=xsa_cur_req->current_nr_sectors ){ xsa_device.req_done = 1;
while ((stat = cur_req(&SysAce, sector,
xsa_cur_req->current_nr_sectors ,
buffer)) == XST_DEVICE_BUSY)
xsa_short_delay();
Due to the hardcoded value, it gave problem while mounting but no issue
with fdisk. It mounts well but generated a kernel BUG. Tried changing
the value to '1' from '2' , fdisk crashed but mount is working well. So
removed the hardcode value and then placed the dynamic variable
xsa_cur_req->current_nr_sectors which is chosen by kernel. And now fdisk
and mount both are working fine.
Pl let me know the results in your setup.
Thanks
Sudheer
Robertson, Joseph M. wrote:
>
> Hi,
>
> Yes, I got it from here.
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>
> The 'official' one, yes?
>
> Thanks,
>
> Joe Robertson
> Joseph.Robertson@sanmina-sci.com
>
>
>
> -----Original Message-----
> From: urwithsudheer [mailto:urwithsudheer@gmail.com]
> Sent: Fri 7/13/2007 4:25 AM
> To: Robertson, Joseph M.
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: XSysAce driver cant mount DOS part
>
> Hi
>
> Robertson, Joseph M. wrote:
> >
> > Hi all,
> >
> > I've been workig with this for a while but have made no progress.
> > Today I got the latest XSysAce patch for kernel 2.6.17.1 and applied
> > it to get clean code.
> > I inherited the previous code from another developer.
> >
> Can you send the link to xsysace driver source code from where you
> obtained.
>
>
> Thanks
> Sudheer
>
>
> >
> > My problem is that mounting the DOS partition always fails in a short
> > time with a kernel oops.
> >
> > ECAU-9999:# Oops: kernel access of bad area, sig: 11
> > [#1]
> >
> PREEMPT
> > NIP: C00701C8 LR: C0070C18 CTR:
> > 00000000
> > REGS: c0391dd0 TRAP: 0300 Not tainted
> > (2.6.17.1)
> > MSR: 00021030 <ME,IR,DR> CR: 22028082 XER:
> > 0000000B
> > DAR: 00000000, DSISR:
> > 00800000
> > TASK = c0373030[4] 'events/0' THREAD:
> > c0390000
> > GPR00: 00000080 C0391E80 C0373030 C02CAC00 C0E03000 C0E03154 00000000
> > C02CAC00
> > GPR08: 00200200 00000000 00100100 00000000 00051A4B FFFFDE60 03BD4900
> > 007FFF3B
> > GPR16: 00400000 00000001 FFFFFFFF 03BCDC58 00000000 007FFF00 00000002
> > C0280000
> > GPR24: C0363A10 0000000B 00000000 00000000 00000000 C02CAC00 C035ED20
> > C0E03000
> > NIP [C00701C8]
> > free_block+0x8c/0x138
> > LR [C0070C18]
> > drain_array+0xb8/0x124
> > Call Trace:
> >
> > The setup:
> > My own build system.
> > Kernel 2.6.17.1 with lots of xilinx stuff, eth, i2c, xsysace.
> > Crosscompiled for PPC405.
> > Latest, clean XSysAce code. mods: major hardcoded to = 125. Polled
> > mode.
> > CF: 3 partitions,
> > 1: DOS FAT16
> > 2: Ext2 main
> > 3: Ext2 rescue
> >
> > This build boots up fine, mounts a ext2 as root fine. I can also
> > mount the rescue partition with no problems.
> >
> > Does anyone have any pointers of where I should look for problems?
> >
> > My next step is to go and set it up for interrupt service and see if
> > that changes anything.
> >
> > Thanks,
> >
> > Joe Robertson
> > Joseph.Robertson@sanmina-sci.com
> >
> >
> > CONFIDENTIALITY
> > This e-mail message and any attachments thereto, is intended only for
> > use by the addressee(s) named herein and may contain legally
> > privileged and/or confidential information. If you are not the
> > intended recipient of this e-mail message, you are hereby notified
> > that any dissemination, distribution or copying of this e-mail
> > message, and any attachments thereto, is strictly prohibited. If you
> > have received this e-mail message in error, please immediately notify
> > the sender and permanently delete the original and any copies of this
> > email and any prints thereof.
> > ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
> > IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
> > Uniform Electronic Transactions Act or the applicability of any other
> > law of similar substance and effect, absent an express statement to
> > the contrary hereinabove, this e-mail message its contents, and any
> > attachments hereto are not intended to represent an offer or
> > acceptance to enter into a contract and are not otherwise intended to
> > bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
> > or any other person or entity.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for
> use by the addressee(s) named herein and may contain legally
> privileged and/or confidential information. If you are not the
> intended recipient of this e-mail message, you are hereby notified
> that any dissemination, distribution or copying of this e-mail
> message, and any attachments thereto, is strictly prohibited. If you
> have received this e-mail message in error, please immediately notify
> the sender and permanently delete the original and any copies of this
> email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
> Uniform Electronic Transactions Act or the applicability of any other
> law of similar substance and effect, absent an express statement to
> the contrary hereinabove, this e-mail message its contents, and any
> attachments hereto are not intended to represent an offer or
> acceptance to enter into a contract and are not otherwise intended to
> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
> or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 10945 bytes --]
^ permalink raw reply
* Re: Tickless Hz/hrtimers/etc. on PowerPC
From: Tony Breeds @ 2007-07-16 0:45 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, Michael Neuling
In-Reply-To: <4696197E.9010002@genesi-usa.com>
On Thu, Jul 12, 2007 at 01:07:26PM +0100, Matt Sealey wrote:
Hi Matt,
> What does "isn't quite right yet" mean? Broken, acts funny, or just
> a messy patch?
If you compile with CONFIG_NO_HZ=y, the kernel is broken.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] the wrong variable checked after request_irq()
From: Benjamin Herrenschmidt @ 2007-07-15 22:07 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, torvalds, linux-kernel
In-Reply-To: <20070715220216.GF21668@ftp.linux.org.uk>
On Sun, 2007-07-15 at 23:02 +0100, Al Viro wrote:
> On Mon, Jul 16, 2007 at 07:40:38AM +1000, Benjamin Herrenschmidt wrote:
> > On Sun, 2007-07-15 at 20:59 +0100, Al Viro wrote:
> > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > Out of curiosity, how did you pick it up ? You have some automated tool
> > to catch that (or sparse changes) or you just did -lots- of code
> > inspection ?
>
> While testing sparse changes, actually (comparing pointers to null
> pointer constant spelled without a cast to void *)... That gave several
> hundred hits, most of them being immediately obvious (picking the lines
> by file and line number and looking through the list had eliminated all
> but about a dozen or two). Several were not...
Ok. In fact, it would have been nice if gcc had been able to pick it up
for another reason. The old code is:
if (cascade == NULL)
return;
cascade_irq = irq_of_parse_and_map(cascade, 0);
if (cascade == NO_IRQ) {
printk(KERN_ERR "mpic: failed to map cascade interrupt");
return;
}
And NO_IRQ is 0 on powerpc nowadays. Thus the test can never be true :-)
But it looks like gcc doesn't pick that up.
Ben.
^ permalink raw reply
* Re: [PATCH] the wrong variable checked after request_irq()
From: Al Viro @ 2007-07-15 22:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, torvalds, linux-kernel
In-Reply-To: <1184535638.25235.15.camel@localhost.localdomain>
On Mon, Jul 16, 2007 at 07:40:38AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2007-07-15 at 20:59 +0100, Al Viro wrote:
> > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Out of curiosity, how did you pick it up ? You have some automated tool
> to catch that (or sparse changes) or you just did -lots- of code
> inspection ?
While testing sparse changes, actually (comparing pointers to null
pointer constant spelled without a cast to void *)... That gave several
hundred hits, most of them being immediately obvious (picking the lines
by file and line number and looking through the list had eliminated all
but about a dozen or two). Several were not...
^ permalink raw reply
* Re: [PATCH] the wrong variable checked after request_irq()
From: Benjamin Herrenschmidt @ 2007-07-15 21:40 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, torvalds, linux-kernel
In-Reply-To: <E1IAAFp-00053g-Ti@ZenIV.linux.org.uk>
On Sun, 2007-07-15 at 20:59 +0100, Al Viro wrote:
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Out of curiosity, how did you pick it up ? You have some automated tool
to catch that (or sparse changes) or you just did -lots- of code
inspection ?
Cheers,
Ben.
> ---
> arch/powerpc/platforms/pseries/setup.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index 470db6e..a031d99 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -176,7 +176,7 @@ static void __init pseries_mpic_init_IRQ(void)
> return;
>
> cascade_irq = irq_of_parse_and_map(cascade, 0);
> - if (cascade == NO_IRQ) {
> + if (cascade_irq == NO_IRQ) {
> printk(KERN_ERR "mpic: failed to map cascade interrupt");
> return;
> }
^ 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