Re: How to add platform specific data to a of_device
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 s 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
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 s 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
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 s 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?)) 1636kernel/ 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Legacy ISA registers/interrupts in PCI device tree node
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Legacy ISA registers/interrupts in PCI device tree node
Gerhard, You could do a LOT worse than check the Pegasos. -- Matt Sealey <[EMAIL PROTECTED]> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] PS3 improved video mode autodetection for HDMI/DVI
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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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 :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[1544]Hz > usec_elapsed for mdelay(37) [35431] > start time: [1184152411]s [997039]us > end time: [1184152412]s [32470]us > pata_pdc2027x :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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: possible dead CONFIG-related content under arch/powerpc
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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] use __attribute__ in asm-powerpc
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 <[EMAIL PROTECTED]>
> ---
> 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: [EMAIL PROTECTED]
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___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] use __attribute__ in asm-powerpc
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 <[EMAIL PROTECTED]>
> > ---
> > 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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] use __attribute__ in asm-powerpc
Geert Uytterhoeven <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
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: [EMAIL PROTECTED]
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___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
>> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Legacy ISA registers/interrupts in PCI device tree node
> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: possible dead CONFIG-related content under arch/powerpc
On Mon, 2007-07-16 at 11:16 +0200, Geert Uytterhoeven wrote: > 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? Yes, ouch. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, Jul 16 2007, Geert Uytterhoeven wrote: > 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(). Then you may add my acked-by as well, if you want. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
>> is this the only fix, I've already applied a version of this to my
>> tree (with the irq sense fix) and just want to make sure there isn't
>> anything else.
> I do not get more.
> I'd like to enroll Segher's suggestion together with VIA chip function
> in next step.
> We need to make basic pcie work on 8548 CDS board first.
If you can, please make the "compatible" properties correct
("pcie" instead of "pciex") before the patch goes in; it'll
be less work total and less confusing in the end.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 16 Jul 2007, Geert Uytterhoeven wrote: > 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(). Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64, flush_dcache_page() isn't. So I'd prefer to not call it if not really needed. And according to James, flush_kernel_dcache_page() should be sufficient... So I'm getting puzzled again... 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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Legacy ISA registers/interrupts in PCI device tree node
Original-Nachricht Datum: Mon, 16 Jul 2007 14:40:48 +0200 Von: Segher Boessenkool <[EMAIL PROTECTED]> An: Gerhard Pircher <[EMAIL PROTECTED]> CC: linuxppc-dev@ozlabs.org Betreff: Re: Legacy ISA registers/interrupts in PCI device tree node > > 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. Hmm, I must reread the PCI binding spec. It didn't seem to contain any information about this. > Yes, it should, even if you don't use this in the Linux > kernel yet. Well, I still have to wire up the IDE interrupts in the platform setup code, right? Gerhard -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, Jul 16 2007, Geert Uytterhoeven wrote: > On Mon, 16 Jul 2007, Geert Uytterhoeven wrote: > > 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(). > > Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64, > flush_dcache_page() isn't. So I'd prefer to not call it if not really needed. > > And according to James, flush_kernel_dcache_page() should be sufficient... > > So I'm getting puzzled again... I'll let James expand on why he thinks flush_kernel_dcache_page() should be sufficient. If the backing is always user memory from get_user_pages(), then the flush_kernel_dcache_page() looks sufficient. For the normal IO paths, it could be that or page cache pages too for instance. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 2007-07-16 at 14:16 +0200, 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. No ... that was the point of flush_kernel_dcache_page(). The page in question is page cache backed and contains user mappings. However, the block layer has already done a flush_dcache_page() in get_user_pages() and the user shouldn't be touching memory under I/O (unless they want self induced aliasing problems) so we're free to assume all the user cachelines are purged, hence all we have to do is flush the kernel alias to bring the page up to date and make the users see it correctly. James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
On Jul 16, 2007, at 8:05 AM, Segher Boessenkool wrote:
>>> is this the only fix, I've already applied a version of this to my
>>> tree (with the irq sense fix) and just want to make sure there isn't
>>> anything else.
>> I do not get more.
>> I'd like to enroll Segher's suggestion together with VIA chip
>> function
>> in next step.
>> We need to make basic pcie work on 8548 CDS board first.
>
> If you can, please make the "compatible" properties correct
> ("pcie" instead of "pciex") before the patch goes in; it'll
> be less work total and less confusing in the end.
I've taken care of that as well.
They are now 'fsl,mpc8548-pcie, and 'fsl,mpc8641-pcie'
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 6/8] Walnut DTS
>>> + #address-cells = <0>; >>> + #size-cells = <0>; >> >> No need for these. > > Isn't a good practice to put #address-cells in interrupt controller > nodes? It is not. > If the device tree has an interrupt map defined the interrupt > parent 'unit interrupt specifier' has to be interpreted according > to the #address-cells of the interrupt parent. And "#address-cells" is defaulted to 0 if it is absent, for the purpose of interrupt mapping (but not for its other purposes). Typically, such interrupt controllers don't have device tree children so it doesn't make sense to give them an "#address-cells" anyway. > It seems like > typical practice in the current DTS files to explicitly define this > in the interrupt controller. That "typical practice" is inspired by the need to explicitly put #address-cells and #size-cells into the device tree if you want Linux to properly parse the device tree, even if the default values would work perfectly (if Linux would work correctly, that is). > Of course this particular device tree doesn't have an interrupt > map... > > #size-cells is not needed. There are no child nodes, and no binding that says there can be any; neither #address-cells not #size-cells should be there. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, Jul 16 2007, James Bottomley wrote: > On Mon, 2007-07-16 at 14:16 +0200, 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. > > No ... that was the point of flush_kernel_dcache_page(). The page in > question is page cache backed and contains user mappings. However, the > block layer has already done a flush_dcache_page() in get_user_pages() > and the user shouldn't be touching memory under I/O (unless they want > self induced aliasing problems) so we're free to assume all the user > cachelines are purged, hence all we have to do is flush the kernel alias > to bring the page up to date and make the users see it correctly. Oh indeed, I missed the flush_dcache_page() in get_user_pages(). -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
> I thought the idea of the dts/of was for the hardware specific boot > loader to tell the kernel about hardware that the kernel couldn't > otherwise know about, because its not detectable by a bus probe > method, > etc. Its not there to tell you how to use the device or arbitrate > which > other devices get to use a device when there are resource conflicts, > etc. > > If the dts/of/boot loader tells the kernel its a fsl soc then it knows > how to work out which one and what level, and therefore knows what > devices, such as the DMA device are present. The device tree describes _all_ hardware in the system, not just the things that are somewhat harder to probe for. Kernel drivers are free to not use all info provided in the device tree and just hardcode some (correct or incorrect) implicit knowledge about the device in question. Whether this is a good idea or not is a different thing. > I'm truly interested in understanding the correct interpretation > because > we are developing a DMA based, rapidio distributed system on fsl 8641 > and from lurking on here and reading the archives etc, all I see is a > constant butting of heads on what the dts/of is and how its > supposed to > work. Really, most of what you see is developing bindings for specific devices, which takes a lot of discussion since it needs to be made future-proof. > Quite why we are using a 20 year old spec, which was never > finished, and > ceased to be a formal spec 10 years ago as the "new" way forward is a > puzzle to me as well. You have some misconceptions about Open Firmware I'm afraid. > Not flame bait, Good, let's drop this then :-) > but if someone could point me to > background material it would be helpful for my education in getting up > to speed (on the rationale for using it going forwards, not all the > old > sites for the spec itself). I'm afraid you'll have to get some experience using the OF device tree to truly appreciate its power and flexibility, and how many problems it solves. Yeah this is a pretty weak answer. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
> It's not that bad in most respects, though unlike some, I don't > think we need to stick dogmatically to the exact way that Open > Firmware(tm) did everything. s/did/does/ And for the record: neither do I. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 16 Jul 2007, Jens Axboe wrote: > On Mon, Jul 16 2007, James Bottomley wrote: > > On Mon, 2007-07-16 at 14:16 +0200, 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. > > > > No ... that was the point of flush_kernel_dcache_page(). The page in > > question is page cache backed and contains user mappings. However, the > > block layer has already done a flush_dcache_page() in get_user_pages() > > and the user shouldn't be touching memory under I/O (unless they want > > self induced aliasing problems) so we're free to assume all the user > > cachelines are purged, hence all we have to do is flush the kernel alias > > to bring the page up to date and make the users see it correctly. > > Oh indeed, I missed the flush_dcache_page() in get_user_pages(). Good, thanks for reaching a consensus, so I can update my patch series. 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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
is this the only fix, I've already applied a version of this to my
tree (with the irq sense fix) and just want to make sure there
isn't
anything else.
>>> I do not get more.
>>> I'd like to enroll Segher's suggestion together with VIA chip
>>> function
>>> in next step.
>>> We need to make basic pcie work on 8548 CDS board first.
>>
>> If you can, please make the "compatible" properties correct
>> ("pcie" instead of "pciex") before the patch goes in; it'll
>> be less work total and less confusing in the end.
>
> I've taken care of that as well.
>
> They are now 'fsl,mpc8548-pcie, and 'fsl,mpc8641-pcie'
Perfect, thanks!
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Legacy ISA registers/interrupts in PCI device tree node
>>> 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. > Hmm, I must reread the PCI binding spec. It didn't seem to contain any > information about this. You can describe address regions in "reg" that aren't corresponding to any PCI BAR. There is also a facility to describe subtractive decoding (though I don't think you need this). >> Yes, it should, even if you don't use this in the Linux >> kernel yet. > Well, I still have to wire up the IDE interrupts in the platform setup > code, right? Sure, if you want those interrupts to work, anyway ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hvc_iseries not working
On Fri, 2007-07-13 at 19:05 +0200, Olaf Hering wrote: > 2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4 > 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on > a i820 with v5r3. > 2.6.22 boots ok with CONFIG_VIOCONS When it works, do you have more than one processor assigned to the partition? I noticed something similar last last week. What I've narrowed down so far, is that it only fails in a single-processor partition, (dedicated or shared doesnt matter). if I assign another proc, the partition boots as expected. turning on initcall_debug, output to the console stops after we get as far as hvc_vio_init(). a small sampling of register dumps show us in these places: put_chars() calling spin_lock_irqsave() put_chars() calling vio_get_event_buffer() put_chars() calling vio_free_event_buffer() spin_unlock_irqrestore() calling local_irq_restore() > > It gets up to this point: > > vio_bus_init: processing c000fbfff570 > vio_bus_init: processing c000fbfff6b0 > vio_bus_init: processing c000fbfff7f0 > vio_bus_init: processing c000fbfff930 > vio_bus_init: processing c000fbfffa70 > vio_bus_init: processing c000fbfffbb0 > audit: initializing netlink socket (disabled) > audit(1184327881.720:1): initialized > io scheduler noop registered > io scheduler anticipatory registered (default) > io scheduler deadline registered > io scheduler cfq registered > viopath: opening connection to partition 0, setting sinst 32778, tinst 32769 > hvc: hosting partition 0 > vio_register_driver: driver hvc_console registering > Generic RTC Driver v1.07 > RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blo > > > with ppc64_defconfig it looks like that: > > > audit: initializing netlink socket (disabled) > audit(1184326841.030:1): initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered (default) > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 > rpadlpar_io_init: partition not DLPAR capable > HVSI: registered 0 devices > viopath: opening connection to partition 0, setting sinst 32774, tinst 32769 > hvc: hosting partition 0 > vio_register_driver: driver hvc_console registering > Generic RTC Driver v1.07 > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
> The eHCA driver can now handle multiple event queues (read: interrupt > sources) instead of one. The number of available EQs is selected via the > nr_eqs module parameter. > CQs are either assigned to the EQs based on the comp_vector index or, if the > dist_eqs module parameter is supplied, using a round-robin scheme. Do you have any data on how well this round-robin assignment works? It seems not quite right to me for the driver to advertise nr_eqs completion vectors, but then if round-robin is turned on to ignore the consumer's decision about which vector to use. Maybe if round-robin is turned on you should report 0 as the number of completion vectors? Or maybe we should allow well-known values for the completion vector passed to ib_create_cq to allow consumers to specify a policy (like round robin) instead of a particular vector? Maybe the whole interface is broken and we should only be exposing policies to consumers instead of the specific vector? I think I would rather hold off on multiple EQs for this merge window and plan on having something really solid and thought-out for 2.6.24. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
>> Hmm, as I stated above: Handling the SPI slave devices is done in >> the SPI >> framework. But including this data into the dts sounds better than >> including >> it into the BSP. Is there some documentation around how to >> describe such a >> SPI bus with its devices in the dts? > > I don't think so, I doubt there's an SPI OF binding. That's correct. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
> Is there a reason why there is sooo much interaction of the > platform code with the oftree? Yes. Since the decision has been made to require a device tree for every platform, arch/powerpc is in the luxury position that we can actually exploit the benefits of _having_ a tree for every platform. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/3] PS3 Storage Drivers for 2.6.23, take 5
Hi, These are the remaining patches of the new PS3 storage drivers series: [1] ps3: Disk Storage Driver [2] ps3: BD/DVD/CD-ROM Storage Driver [3] ps3: FLASH ROM Storage Driver They are based on: - the current Linux kernel source tree, - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev, which are in the for-2.6.23 branch of Paulus' tree, - plus the first 3 patches from the PS3 storage drivers series I submitted before, which are also in the for-2.6.23 branch of Paulus' tree. The only changes compared to the previous submission are the kmap updates, as requested by Jens Axboe and James E.J. Bottomley. I didn't hear anything from the misc device maintainer (for the FLASH ROM Storage Driver). Paulus, please apply. Thanks in advance! 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: [EMAIL PROTECTED] 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/3] ps3: Disk Storage Driver
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
Add a Disk Storage Driver for the PS3:
- Implemented as a block device driver with a dynamic major
- Disk names (and partitions) are of the format ps3d%c(%u)
- Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
doesn't support scatter-gather
CC: Geoff Levand <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Acked-by: Jens Axboe <[EMAIL PROTECTED]>
---
v4:
- Replace KM_USER0 by KM_IRQ0 (all kmap routines are either called from an
interrupt handler or from .request_fn())
- Add a call to flush_kernel_dcache_page() before kunmap in routines that
write to buffers
v3:
- Cleanup #includes
- Kill PS3DISK_MAJOR, always use zero to obtain a dynamic major
- Group LV1 API related stuff
- Kill empty ps3disk_open
- Reset ps3disk_priv(dev) to NULL during cleanup
- Move call to put_disk() down
- Pass the interrupt handler to ps3stor_setup(), so it doesn't have to be
overridden later
- Fold ps3disk_read_write_sectors() into ps3disk_submit_request_sg()
- Identify the hard drive capacity and model name during probing
v2:
- Don't use `default y' in Kconfig
- Remove the thread for handling requests
- Set up sysfs links between block device and PS3 system device:
o /sys/block/ps3da/device -> ../../devices/ps3_system/sb_02
o /sys/devices/ps3_system/sb_02/block:ps3da -> ../../../block/ps3da
- Fix all FIXMEs
- Implement proper barrier support
- Call add_disk_randomness()
- Add a test to verify we are running on a PS3
- Fix error path in ps3disk_init()
- Fix cleanup order in ps3disk_exit()
arch/powerpc/platforms/ps3/Kconfig | 10
drivers/block/Makefile |1
drivers/block/ps3disk.c| 624 +
3 files changed, 635 insertions(+)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -102,4 +102,14 @@ config PS3_STORAGE
depends on PPC_PS3
tristate
+config PS3_DISK
+ tristate "PS3 Disk Storage Driver"
+ depends on PPC_PS3 && BLOCK
+ select PS3_STORAGE
+ help
+ Include support for the PS3 Disk Storage.
+
+ This support is required to access the PS3 hard disk.
+ In general, all users will say Y or M.
+
endmenu
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_VIODASD) += viodasd.o
obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
obj-$(CONFIG_BLK_DEV_UB) += ub.o
+obj-$(CONFIG_PS3_DISK) += ps3disk.o
--- /dev/null
+++ b/drivers/block/ps3disk.c
@@ -0,0 +1,624 @@
+/*
+ * PS3 Disk Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+
+
+#define DEVICE_NAME"ps3disk"
+
+#define BOUNCE_SIZE(64*1024)
+
+#define PS3DISK_MAX_DISKS 16
+#define PS3DISK_MINORS 16
+
+#define KERNEL_SECTOR_SIZE 512
+
+
+#define PS3DISK_NAME "ps3d%c"
+
+
+struct ps3disk_private {
+ spinlock_t lock;/* Request queue spinlock */
+ struct request_queue *queue;
+ struct gendisk *gendisk;
+ unsigned int blocking_factor;
+ struct request *req;
+ u64 raw_capacity;
+ unsigned char model[ATA_ID_PROD_LEN+1];
+};
+#define ps3disk_priv(dev) ((dev)->sbd.core.driver_data)
+
+
+#define LV1_STORAGE_SEND_ATA_COMMAND (2)
+#define LV1_STORAGE_ATA_HDDOUT (0x23)
+
+struct lv1_ata_cmnd_block {
+ u16 features;
+ u16 sector_count;
+ u16 LBA_low;
+ u16 LBA_mid;
+ u16 LBA_high;
+ u8 device;
+ u8 command;
+ u32 is_ext;
+ u32 proto;
+ u32 in_out;
+ u32 size;
+ u64 buffer;
+ u32 arglen;
+};
+
+enum lv1_ata_proto {
+ NON_DATA_PROTO = 0,
+ PIO_DATA_IN_PROTO = 1,
+ PIO_DATA_OUT_PROTO = 2,
+ DMA_PROTO = 3
+};
+
+enum lv1_ata_in_out {
+ DIR_WRITE = 0, /* memory -> device */
+ DIR_READ = 1/* device -> memory */
+};
+
+static int ps3disk_major;
+
+
+static struct block_device_operations ps3disk_fops = {
+
[patch 3/3] ps3: FLASH ROM Storage Driver
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
Add a FLASH ROM Storage Driver for the PS3:
- Implemented as a misc character device driver
- Uses a fixed 256 KiB buffer allocated from boot memory as the hypervisor
requires the writing of aligned 256 KiB blocks
CC: Geoff Levand <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
v3:
- Cleanup #includes
- Allow to disable ps3flash (and the preallocated 256 KiB buffer) using
`ps3flash=off'
- Move selection of write/read strings to error path
- Rename and move ps3stor_interrupt() to ps3flash_interrupt()
- Pass the interrupt handler to ps3stor_setup()
- Reset ps3flash_priv(dev) to NULL during cleanup
v2:
- Don't use `default y' in Kconfig
- #include instead of
- Set up sysfs links between misc character device and PS3 system device:
o /sys/class/misc/ps3flash/device -> ../../../devices/ps3_system/sb_01
o /sys/devices/ps3_system/sb_01/misc:ps3flash ->
../../../class/misc/ps3flash
arch/powerpc/platforms/ps3/Kconfig | 15 +
drivers/char/Makefile |2
drivers/char/ps3flash.c| 429 +
3 files changed, 446 insertions(+)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -123,4 +123,19 @@ config PS3_ROM
In general, all users will say Y or M.
Also make sure to say Y or M to "SCSI CDROM support" later.
+config PS3_FLASH
+ tristate "PS3 FLASH ROM Storage Driver"
+ depends on PPC_PS3
+ select PS3_STORAGE
+ help
+ Include support for the PS3 FLASH ROM Storage.
+
+ This support is required to access the PS3 FLASH ROM, which
+ contains the boot loader and some boot options.
+ In general, all users will say Y or M.
+
+ As this driver needs a fixed buffer of 256 KiB of memory, it can
+ be disabled on the kernel command line using "ps3flash=off", to
+ not allocate this fixed buffer.
+
endmenu
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -104,6 +104,8 @@ obj-$(CONFIG_IPMI_HANDLER) += ipmi/
obj-$(CONFIG_HANGCHECK_TIMER) += hangcheck-timer.o
obj-$(CONFIG_TCG_TPM) += tpm/
+obj-$(CONFIG_PS3_FLASH)+= ps3flash.o
+
# Files generated that shall be removed upon make clean
clean-files := consolemap_deftbl.c defkeymap.c
--- /dev/null
+++ b/drivers/char/ps3flash.c
@@ -0,0 +1,429 @@
+/*
+ * PS3 FLASH ROM Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+
+#define DEVICE_NAME"ps3flash"
+
+#define FLASH_BLOCK_SIZE (256*1024)
+
+
+struct ps3flash_private {
+ struct mutex mutex; /* Bounce buffer mutex */
+};
+#define ps3flash_priv(dev) ((dev)->sbd.core.driver_data)
+
+static struct ps3_storage_device *ps3flash_dev;
+
+static ssize_t ps3flash_read_write_sectors(struct ps3_storage_device *dev,
+ u64 lpar, u64 start_sector,
+ u64 sectors, int write)
+{
+ u64 res = ps3stor_read_write_sectors(dev, lpar, start_sector, sectors,
+write);
+ if (res) {
+ dev_err(&dev->sbd.core, "%s:%u: %s failed 0x%lx\n", __func__,
+ __LINE__, write ? "write" : "read", res);
+ return -EIO;
+ }
+ return sectors;
+}
+
+static ssize_t ps3flash_read_sectors(struct ps3_storage_device *dev,
+u64 start_sector, u64 sectors,
+unsigned int sector_offset)
+{
+ u64 max_sectors, lpar;
+
+ max_sectors = dev->bounce_size / dev->blk_size;
+ if (sectors > max_sectors) {
+ dev_dbg(&dev->sbd.core, "%s:%u Limiting sectors to %lu\n",
+ __func__, __LINE__, max_sectors);
+ sectors = max_sectors;
+ }
+
+ lpar = dev->bounce_lpar + sector_offset * dev->blk_size;
+ return ps3flash_read_write_sectors(dev, lpar, start_sector, sectors,
+ 0);
+}
+
+static ssize_t ps3flash_write_chunk(struct ps3_storage_device *dev,
+
[patch 2/3] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
Add a BD/DVD/CD-ROM Storage Driver for the PS3:
- Implemented as a SCSI device driver
- Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
doesn't support scatter-gather
CC: Geoff Levand <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
v4:
- Replace KM_USER0 by KM_IRQ0 (all kmap routines are either called from an
interrupt handler or from .queuecommand())
- Add a call to flush_kernel_dcache_page() before kunmap in routines that
write to buffers
v3:
- Replace dependency on BLK_DEV_SR by SCSI
- Use `BD/DVD/CD-ROM' instead of `ROM' in driver descriptions
- Inform the user to enable "SCSI CDROM support"
- Cleanup #includes
- Group LV1 API related stuff
- Rename ps3rom_private.cmd to ps3rom_private.curr_cmd
- Use shost_priv() (from scsi-misc)
- Set scsi_device.use_10_for_rw and remove support for {READ,WRITE}_6
- Explain why we prefer to use lv1_storage_{read,write}()
- Pass the interrupt handler to ps3stor_setup(), so it doesn't have to be
overridden later
- Reset ps3rom_priv(dev) to NULL during cleanup
v2:
- Don't use `default y' in Kconfig
- Add missing #include
- Remove ps3rom_private.scsi_done, use scsi_cmnd.scsi_done instead
- Use scsi_device.host.hostdata
- Remove empty ps3rom_slave_{alloc,destroy}()
- Kill superfluous test for command in progress
- Move scsi_host_put() last in cleanup sequence
- Remove scsi_command(), use scsi_print_command() for debugging
- scsi_cmnd.use_sg is always > 0 these days
- Allocate struct ps3rom_private using scsi_host_alloc()
- Remove the thread for handling requests
- Remove unused position parameter enum
- Remove unused NA_PROTO and DIR_NA
- Derive buffer length, data direction, and transfer protocol from the
struct scsi_command, instead of using a big switch() statement
- Kill superfluous spinlock
- Remove manual request sense, as modern hypervisors always do auto sense
- Pass all SCSI commands to the hypervisor as ATAPI commands, except for
READ_*/WRITE_*
- Don't print errors for SCSI commands that are not allowed for an Other OS
by the hypervisor
- Remove superfluous tests for data directions in
{fill_from,fetch_to}_dev_buffer()
- Handle errors in {fill_from,fetch_to}_dev_buffer()
- Reorder routines
- Manually inline ps3rom_send_atapi_command()
- Fix all FIXMEs
arch/powerpc/platforms/ps3/Kconfig | 11
drivers/scsi/Makefile |1
drivers/scsi/ps3rom.c | 538 +
3 files changed, 550 insertions(+)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -112,4 +112,15 @@ config PS3_DISK
This support is required to access the PS3 hard disk.
In general, all users will say Y or M.
+config PS3_ROM
+ tristate "PS3 BD/DVD/CD-ROM Storage Driver"
+ depends on PPC_PS3 && SCSI
+ select PS3_STORAGE
+ help
+ Include support for the PS3 ROM Storage.
+
+ This support is required to access the PS3 BD/DVD/CD-ROM drive.
+ In general, all users will say Y or M.
+ Also make sure to say Y or M to "SCSI CDROM support" later.
+
endmenu
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -132,6 +132,7 @@ obj-$(CONFIG_SCSI_IBMVSCSI) += ibmvscsi/
obj-$(CONFIG_SCSI_IBMVSCSIS) += ibmvscsi/
obj-$(CONFIG_SCSI_HPTIOP) += hptiop.o
obj-$(CONFIG_SCSI_STEX)+= stex.o
+obj-$(CONFIG_PS3_ROM) += ps3rom.o
obj-$(CONFIG_ARM) += arm/
--- /dev/null
+++ b/drivers/scsi/ps3rom.c
@@ -0,0 +1,538 @@
+/*
+ * PS3 BD/DVD/CD-ROM Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+
+#define DEVICE_NAME"ps3rom"
+
+#define BOUNCE_SIZE(64*1024)
+
+#define PS3ROM_MAX_SECTORS (BOUNCE_SIZE / CD_FRAMESIZE)
+
+
+struct ps3rom_private {
+ struct ps3_storage_device *dev;
+ struct scsi_cmnd *curr_cmd;
+};
+#define ps3rom_priv(dev) ((dev)->sbd.core.driver_data)
+
+
+#define LV1_STORAGE_SEND_ATA
Re: How to add platform specific data to a of_device
> 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. Yes, lots of the "glue" code could be made into some helper library. Also, while that glue code might be perceived as being "a lot of stuff", it isn't really, and it is quite simple anyway; it's just a layer that sits there to translate for the impedance mismatch of the device tree on one hand, and the kernel interfaces on the other. Because we do have such a layer, interface changes aren't a big deal; and since the device tree interface is a way flexible, mostly text-based associative array tree thing, we have none of the problems that binary firmware interfaces on other platforms have. Oh, and the Open Firmware device tree works perfectly fine across different architectures, too. >> 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. This is most of the "endless debate", too. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] cell: CONFIG_SPE_BASE is a typo (was: Re: possible dead CONFIG-related content under arch/powerpc)
The config symbol for SPE support is called CONFIG_SPU_BASE, not CONFIG_SPE_BASE. Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 4f2f453..0b25d42 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -609,7 +609,7 @@ static void demote_segment_4k(struct mm_struct *mm, unsigned long addr) mm->context.sllp = SLB_VSID_USER | mmu_psize_defs[MMU_PAGE_4K].sllp; #endif /* CONFIG_PPC_MM_SLICES */ -#ifdef CONFIG_SPE_BASE +#ifdef CONFIG_SPU_BASE spu_flush_all_slbs(mm); #endif } @@ -744,7 +744,7 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap) "to 4kB pages because of " "non-cacheable mapping\n"); psize = mmu_vmalloc_psize = MMU_PAGE_4K; -#ifdef CONFIG_SPE_BASE +#ifdef CONFIG_SPU_BASE spu_flush_all_slbs(mm); #endif } 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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to add platform specific data to a of_device
>> 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. The big problem here is that lots of people got the _basic_ stuff wrong. I feel that this is getting much better the last few months though :-) > It may be right for big irons, being well defined. OF is being successfully used on many many more systems than just "big iron"; and many of those do have really weird quirks. arch/powerpc also deals with many systems that don't get their device trees quite right (*cough* powermac *cough*) and that is doable just fine. The quirks should be separated more from the normal code though, in the Linux OF layer. > But for the > embedded processors, too less people are working on it, plus we > have too > much things which could be defined. For embedded, too often the whole bloody thing is dropped onto the "bigger Linux community" after it has been developed in-house for many many months. And usually, lots of core things are very wrong. This is a problem with "embedded" in general, nothing new for OF. > 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. No, you *do not* have to keep them in synch, that's part of the beauty of the device tree definition. Sure, you have to make sure the consumer is at least as new as the producer, unless people took pains to try to create wrong-way-around compatibility. Nothing new there. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] use __attribute__ in asm-powerpc
On Monday 16 July 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 <[EMAIL PROTECTED]>
> > ---
> > 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'.
i never said asm-powerpc/processor.h was exported to userspace ... i did say
that i changed the file to be consistent with all other files.
-mike
signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add PCI/PCI Express node for 8544DS board]
It looks real good now :-)
One tiny comment...
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc8548-pcie";
I would name the node [EMAIL PROTECTED] instead; generic names
aren't for machine consumption anyway, and most humans
want to know which buses are plain PCI vs. PCI-X vs.
PCI Express.
This could be changed with a follow-up patch of course.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/10] IB/ehca: use common error code mapping instead of specific ones
> @@ -161,8 +161,11 @@ static inline int ehca2ib_return_code(u64 ehca_rc) applied, but as a further cleanup it seems that ehca2ib_return_code() should be moved into a .c file and moved out of line -- I think it would probably shrink the compiled code quite a bit, and as far as I can see it is never used in the data path where the function call overhead would matter at all. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
On Fri, Jul 13, 2007 at 07:06:56PM -0600, Eric W. Biederman wrote:
> > .data = &ipv4_devconf.loop,
> > .maxlen = sizeof(int),
> > .mode = 0644,
> > + .child = 0x0,
> > .proc_handler = &proc_dointvec,
> > },
> Where did this entry above in devinet_sysctl come from?
My bad.
I habitually apply the "send-to-self" patch, since some of the
network testing that I do is easiest if I load up the all of the
adapters in the same box. (If you're not familiar with this patch ...
its great, and I wish it was integratedd into mainline. It allows
one to drive network traffic through the physical devices, even
if they are in the same box. Without it, the network stack is
too clever, and won't allow you to do this.)
> > + {
> > + .ctl_name = 0,
> > + .procname = 0,
> > + },
> I probably would have just done:
> + {},
Yes, in retrospect, this would have been the simplest solution.
> What added the additional entry to devinet_root_dir? I don't see that
> in Linus' tree?
>
> The result may be fine but if it isn't named in a per network device
> manner we are adding duplicate entries to the root /proc/sys directory
> which is wrong.
>
> Actually come to think of it I am concerned that someone added a
> settable entry into /proc/sys/ it should at least be in /proc/sys/net/
> where it won't conflict with other uses of that directory. Especially
> as things like network devices have user controlled names.
Sigh. Silly me. Haste makes waste.
--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Fix Tsi108 ethernet driver performance
I agree that 20 ms is not the best option. But, as you mentioned as well, shorter period may bring more wasted CPU cycles. Using this approach to interrupt moderation I see performance improvement using frame flow that generates about one interrupt per frame. Below are CPU usage numbers reported by top for the current and patched versions of the Tsi108_eth driver. Current version: Cpu(s): 0.0% us, 0.3% sy, 0.0% ni, 14.6% id, 0.0% wa, 14.6% hi, 70.4% si Patched version: Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 35.2% id, 1.2% wa, 2.4% hi, 61.2% si - Alex. -Original Message- From: Scott Wood [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 4:33 PM To: Scott Wood Cc: Alexandre Bounine; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] Fix Tsi108 ethernet driver performance Scott Wood wrote: > Wouldn't this cause latencies of up to a second in responding to > received packets? I'd think that would be considered excessive. > > And shouldn't NAPI be reducing the RX interrupt load anyway? Sorry, I missed that you reduced the interval to 20 ms. Still, a bit on the high side, and a source of wasted CPU cycles when the network isn't heavily loaded. How much of a difference in CPU usage did you see with this patch? -Scott --- Important Notice: This message is intended for the use of the individual to whom it is addressed and may contain information which is privileged, confidential and/or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or is not the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone or return e-mail and delete the original message from your systems. Thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
On Fri, Jul 13, 2007 at 03:47:02PM -0700, David Miller wrote: > From: [EMAIL PROTECTED] (Linas Vepstas) > Date: Fri, 13 Jul 2007 15:05:15 -0500 > > > > > This is a patch (& bug report) for a crash in sysctl_set_parent() > > in 2.6.22-git2. > > > > Problem: 2.6.22-git2 crashes with a stack trace > > > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > Thanks for tracking this down, I'll apply your patch. NAK. As I just explained in another email, this bug was introduced by the "send-to-self" patch I habitually apply -- so habitually, that I forgot I was not working with a "clean" tree. So it goes ... --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix Tsi108 ethernet driver performance
From: Alexandre Bounine <[EMAIL PROTECTED]>
This patch improves performance of the Tsi108 Ethernet driver by
changing interrupt handling for frame receive path. It reduces number of
interrupts generated for received frames and therefore lowers CPU
utilization by the device driver.
Signed-off-by: Alexandre Bounine <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.22-hpc2/drivers/net/tsi108_eth.c
linux-2.6.22-tun/drivers/net/tsi108_eth.c
--- linux-2.6.22-hpc2/drivers/net/tsi108_eth.c 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.22-tun/drivers/net/tsi108_eth.c 2007-07-12
16:55:50.0 -0400
@@ -58,6 +58,7 @@
#define MII_READ_DELAY 1 /* max link wait time in msec */
#define TSI108_RXRING_LEN 256
+#define TSI108_RX_INT_FREQ32
/* NOTE: The driver currently does not support receiving packets
* larger than the buffer size, so don't decrease this (unless you
@@ -69,8 +70,10 @@
#define TSI108_TX_INT_FREQ64
-/* Check the phy status every half a second. */
-#define CHECK_PHY_INTERVAL (HZ/2)
+/* Timer interval to check the RX queue status */
+#define CHECK_RX_INTERVAL (HZ/50)
+/* Timer interval to check the PHY status */
+#define CHECK_PHY_INTERVAL (CHECK_RX_INTERVAL * 10)
static int tsi108_init_one(struct platform_device *pdev);
static int tsi108_ether_remove(struct platform_device *pdev);
@@ -104,6 +107,7 @@ struct tsi108_prv_data {
unsigned int txfree;
unsigned int phy_ok;/* The PHY is currently powered
on. */
+ unsigned int phy_chk_count;
/* PHY status (duplex is 1 for half, 2 for full,
* so that the default 0 indicates that neither has
@@ -823,7 +827,10 @@ static int tsi108_refill_rx(struct net_d
*/
data->rxring[rx].blen = TSI108_RX_SKB_SIZE;
- data->rxring[rx].misc = TSI108_RX_OWN | TSI108_RX_INT;
+ if (rx % TSI108_RX_INT_FREQ)
+ data->rxring[rx].misc = TSI108_RX_OWN;
+ else
+ data->rxring[rx].misc = TSI108_RX_OWN |
TSI108_RX_INT;
data->rxhead = (data->rxhead + 1) % TSI108_RXRING_LEN;
data->rxfree++;
@@ -973,24 +980,22 @@ static void tsi108_rx_int(struct net_dev
}
}
-/* If the RX ring has run out of memory, try periodically
- * to allocate some more, as otherwise poll would never
- * get called (apart from the initial end-of-queue condition).
- *
- * This is called once per second (by default) from the thread.
+/* tsi108_check_rxring() is used to periodically check if the RX ring
has
+ * pending frames that have not been reported by RX interrupt (due to
interrupt
+ * moderation). It is called with CHECK_RX_INTERVAL timer interval.
*/
static void tsi108_check_rxring(struct net_device *dev)
{
struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned int rx = data->rxtail;
- /* A poll is scheduled, as opposed to caling tsi108_refill_rx
-* directly, so as to keep the receive path single-threaded
-* (and thus not needing a lock).
-*/
-
- if (netif_running(dev) && data->rxfree < TSI108_RXRING_LEN / 4)
+ /* Schedule a poll (if required) */
+ if (netif_running(dev) &&
+ 0 == (data->rxring[rx].misc & TSI108_RX_OWN)) {
+ data->rxpending = 1;
tsi108_rx_int(dev);
+ }
}
static void tsi108_tx_int(struct net_device *dev)
@@ -1295,6 +1300,7 @@ static void tsi108_init_phy(struct net_d
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok = 1;
+ data->phy_chk_count = 0;
data->init_media = 1;
spin_unlock_irqrestore(&phy_lock, flags);
}
@@ -1664,9 +1670,12 @@ static void tsi108_timed_checker(unsigne
struct net_device *dev = (struct net_device *)dev_ptr;
struct tsi108_prv_data *data = netdev_priv(dev);
- tsi108_check_phy(dev);
+ /* We assume that RX queue is checked more often than PHY status
*/
+ if (data->phy_chk_count++ == 0)
+ tsi108_check_phy(dev);
tsi108_check_rxring(dev);
- mod_timer(&data->timer, jiffies + CHECK_PHY_INTERVAL);
+ data->phy_chk_count %= (CHECK_PHY_INTERVAL/CHECK_RX_INTERVAL);
+ mod_timer(&data->timer, jiffies + CHECK_RX_INTERVAL);
}
static int tsi108_ether_init(void)
---
Important Notice: This message is intended for the use of the individual to
whom it is addressed and may contain information which is privileged,
confidential and/or exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, or is not the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this communication
in error, please notify the sender immediately by telephone or return e-mail
an
Re: [PATCH 10/10] IB/ehca: Support large page MRs
> Add support for MR pages larger than 4K on eHCA2. This reduces firmware
> memory consumption. If enabled via the mr_largepage module parameter, the MR
> page size will be determined based on the MR length and the hardware
> capabilities - if the MR is >= 16M, 16M pages are used, for example.
Why the module parameter? Is there any reason a user would want to
turn this off? Or conversely, why is it off by default?
Also this patch seems to depend heavily on the multiple EQ patch,
which I am holding off on now. So you may want to rebase to my
current tree, which has all the ehca patches except the EQ one.
> static ssize_t ehca_show_nr_eqs(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> return sprintf(buf, "%d\n", ehca_nr_eqs);
> }
> -
> static DEVICE_ATTR(nr_eqs, S_IRUGO, ehca_show_nr_eqs, NULL);
Although trivial, this chunk doesn't really belong in this patch --
just fix it up in the multiple EQ patch (which I haven't merged yet).
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] 82xx: Add the support for Wind River SBC PowerQUICCII
These 3 patches add the powerpc support of Wind River SBC PowerQUICCII. 1) Currently, some mpc82xx platform hooks in mpc82xx_ads.c are actually not specific to ads board. So the 1st patch makes them be shared by different 82xx boards. 2) The 2nd patch make 'cpm_uart_of_init' be able to parse SMC uart in DTS 3) The 3rd patch is the platform codes, defconfig and dts for Wind River SBC PowerQUICCII 82xx board. Any comment is welcome. Thanks Mark Zhan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
> Update mpc7448hpc2 device tree to be compatible for tsi109 chip. > > Signed-off-by: Roy Zang <[EMAIL PROTECTED]> Looks good, thanks! Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Help needed interpreting weird kOops
Hi, still working on mapping a Mach-O driver to ELF, I'm seeing a weird kOops when insmod'ing the driver : Jul 16 20:16:07 tertius kernel: Oops: Unrecoverable FP Unavailable Exception, sig: 6 [#1] Jul 16 20:16:07 tertius kernel: PREEMPT Jul 16 20:16:07 tertius kernel: Modules linked in: unicorn_pci_atm(P) Jul 16 20:16:07 tertius kernel: NIP: F661CD6C LR: F661CD5C CTR: 00D0 Jul 16 20:16:07 tertius kernel: REGS: ee86db70 TRAP: 0801 Tainted: P (2.6.20-rc3-sjv1-gc6b33cc4-dirty) Jul 16 20:16:07 tertius kernel: MSR: 9032 CR: 24004288 XER: Jul 16 20:16:07 tertius kernel: TASK = effcd790[1397] 'insmod' THREAD: ee86c000 Jul 16 20:16:07 tertius kernel: GPR00: F661CD5C EE86DC20 EFFCD790 0008 F66885B0 0104 EE9D3D60 EE9D269C Jul 16 20:16:07 tertius kernel: GPR08: EE9D23B4 F6684B38 00D0 EE86C000 F664D9CC Jul 16 20:16:07 tertius kernel: NIP [F661CD6C] _ZN19InterruptDispatcher5resetEv+0x3c/0xb4 [unicorn_pci_atm] Jul 16 20:16:07 tertius kernel: LR [F661CD5C] _ZN19InterruptDispatcher5resetEv+0x2c/0xb4 [unicorn_pci_atm] Jul 16 20:16:07 tertius kernel: Call Trace: Jul 16 20:16:07 tertius kernel: [EE86DC20] [F661CD5C] _ZN19InterruptDispatcher5resetEv+0x2c/0xb4 [unicorn_pci_atm] (unreliable) Jul 16 20:16:07 tertius kernel: [EE86DC70] [10019678] 0x10019678 Jul 16 20:16:07 tertius kernel: [EE86DCC0] [F66C] fineGainConversionTable.728+0x664/0xfffc2294 [unicorn_pci_atm] Jul 16 20:16:07 tertius kernel: [EE86DD30] [F6623444] _ZN17ModemSubsystemItfC1EmPtm+0x44/0xd8 [unicorn_pci_atm] Jul 16 20:16:07 tertius kernel: [EE86DD90] [F65EEDA8] AMSW_Modem_SW_Init+0x110/0x1f8 [unicorn_pci_atm] Jul 16 20:16:07 tertius kernel: [EE86DE00] [C002B16C] printk+0x50/0x60 Jul 16 20:16:07 tertius kernel: [EE86DE40] [F105252C] unicorn_pci_init+0x52c/0xb08 [unicorn_pci_atm] Jul 16 20:16:07 tertius kernel: [EE86DE90] [C004E340] sys_init_module+0x16c/0x1610 Jul 16 20:16:07 tertius kernel: [EE86DF40] [C00112B0] ret_from_syscall+0x0/0x38 Jul 16 20:16:07 tertius kernel: --- Exception: c01 at 0xff6cfc8 Jul 16 20:16:07 tertius kernel: LR = 0x1e54 Jul 16 20:16:07 tertius kernel: Instruction dump: Jul 16 20:16:07 tertius kernel: 9421ffb0 7c7f1b78 3c60f669 38630948 4889 7fe3fb78 4871 485d Jul 16 20:16:07 tertius kernel: 394000d0 3d20f668 7d4903a6 39294b38 3960 3804 917f0008 Having learned more PPC assembly than I probably wished, I checked the code until _ZN17ModemSubsystemItfC1EmPtm+0x44, which disassembles to this (arg addresses are relative to the beginning of .text/0xf65c4000): 0xf6623440: 48 00 00 89 bl 0x5f4c8[ branch island, un-optimized from JBSR ] 0xf6623444: 80 61 00 38 l r3,56(r1) [...] [ this is the branch island ] 0xf66234c8: 3d 80 f6 64 liu r12,0xf664 0xf66234cc: 61 8c e1 54 orilr12,r12,0xe154 0xf66234d0: 7d 89 03 a6 mtctr r12 mtctr branches to a memory-allocation function which does seem to behave correctly (it is called multiple times before that). But somehow from this point everything seems corrupted: the stack trace seems to show a jump into the .data section (fineGainConversionTable), which could be explained by a bad relocation, but I didn't see any obvious problems on this side. So I have to assume that the stack is somehow corrupted, but I can't explain how this happens, at least in this portion of code. Any hint ? Simon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] 82xx: Parse SMC serial device node in DTS
This patch makes 'cpm_uart_of_init' be able to parses SMC serial device node in
DTS
Signed-off-by: Mark Zhan <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
Index: linux-powerpc-2.6.x/arch/powerpc/sysdev/fsl_soc.c
===
--- linux-powerpc-2.6.x.orig/arch/powerpc/sysdev/fsl_soc.c 2007-07-16
15:52:17.0 +0800
+++ linux-powerpc-2.6.x/arch/powerpc/sysdev/fsl_soc.c 2007-07-16
16:59:31.0 +0800
@@ -757,8 +757,8 @@
arch_initcall(fs_enet_of_init);
-static const char scc_regs[] = "regs";
-static const char scc_pram[] = "pram";
+static const char cpm_uart_regs[] = "regs";
+static const char cpm_uart_pram[] = "pram";
static int __init cpm_uart_of_init(void)
{
@@ -775,6 +775,7 @@
const int *id;
const char *model;
+ cpm_uart_dev = NULL;
memset(r, 0, sizeof(r));
memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
@@ -782,31 +783,35 @@
if (ret)
goto err;
- r[0].name = scc_regs;
+ r[0].name = cpm_uart_regs;
ret = of_address_to_resource(np, 1, &r[1]);
if (ret)
goto err;
- r[1].name = scc_pram;
+ r[1].name = cpm_uart_pram;
of_irq_to_resource(np, 0, &r[2]);
- cpm_uart_dev =
- platform_device_register_simple("fsl-cpm-scc:uart", i,
&r[0], 3);
-
- if (IS_ERR(cpm_uart_dev)) {
- ret = PTR_ERR(cpm_uart_dev);
- goto err;
- }
-
id = of_get_property(np, "device-id", NULL);
cpm_uart_data.fs_no = *id;
model = of_get_property(np, "model", NULL);
strcpy(cpm_uart_data.fs_type, model);
- cpm_uart_data.uart_clk = ppc_proc_freq;
+ if (strstr(model, "SMC")) {
+ cpm_uart_dev =
platform_device_register_simple("fsl-cpm-smc:uart",
+ i, &r[0], 3);
+ } else if (strstr(model, "SCC")) {
+ cpm_uart_dev =
platform_device_register_simple("fsl-cpm-scc:uart",
+ i, &r[0], 3);
+ }
+ if (IS_ERR(cpm_uart_dev)) {
+ ret = PTR_ERR(cpm_uart_dev);
+ goto err;
+ }
+
+ cpm_uart_data.uart_clk = ppc_proc_freq;
cpm_uart_data.tx_num_fifo = 4;
cpm_uart_data.tx_buf_size = 32;
cpm_uart_data.rx_num_fifo = 4;
@@ -816,10 +821,8 @@
cpm_uart_data.clk_tx = *((u32 *)of_get_property(np,
"tx-clock", NULL));
- ret =
- platform_device_add_data(cpm_uart_dev, &cpm_uart_data,
-sizeof(struct
- fs_uart_platform_info));
+ ret = platform_device_add_data(cpm_uart_dev, &cpm_uart_data,
+ sizeof(struct fs_uart_platform_info));
if (ret)
goto unreg;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] 82xx: some 82xx platform hook functions can be shared by different boards
Some mpc82xx platform hooks in mpc82xx_ads.c are actually not specific to ads
board, they could be shared by different
82xx boards.
Signed-off-by: Mark Zhan <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/82xx/mpc82xx.c | 30 +++
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 38
+++---
arch/powerpc/platforms/82xx/pq2ads.h |2 -
include/asm-powerpc/mpc8260.h |5 +++
4 files changed, 39 insertions(+), 36 deletions(-)
Index: linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/mpc82xx.c
===
--- linux-powerpc-2.6.x.orig/arch/powerpc/platforms/82xx/mpc82xx.c
2007-07-16 15:20:51.0 +0800
+++ linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/mpc82xx.c 2007-07-16
15:52:42.0 +0800
@@ -50,8 +50,6 @@
#include
#include
-#include "pq2ads.h"
-
static int __init get_freq(char *name, unsigned long *val)
{
struct device_node *cpu;
@@ -74,7 +72,7 @@
return found;
}
-void __init m82xx_calibrate_decr(void)
+void __init mpc82xx_calibrate_decr(void)
{
ppc_tb_freq = 12500;
if (!get_freq("bus-frequency", &ppc_tb_freq)) {
@@ -88,7 +86,7 @@
"(not found)\n");
}
-void mpc82xx_ads_show_cpuinfo(struct seq_file *m)
+void mpc82xx_show_cpuinfo(struct seq_file *m)
{
uint pvid, svid, phid1;
uint memsize = total_memory;
@@ -96,7 +94,7 @@
pvid = mfspr(SPRN_PVR);
svid = mfspr(SPRN_SVR);
- seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
+ seq_printf(m, "Vendor\t\t: %s\n", CPUINFO_VENDOR);
seq_printf(m, "Machine\t\t: %s\n", CPUINFO_MACHINE);
seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
seq_printf(m, "SVR\t\t: 0x%x\n", svid);
@@ -108,3 +106,25 @@
/* Display the amount of memory */
seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
}
+
+#define RMR_CSRE 0x0001
+
+void mpc82xx_restart(char *cmd)
+{
+ __volatile__ unsigned char dummy;
+
+ local_irq_disable();
+ ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
+
+ /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
+ mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
+ dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
+ printk("Restart failed\n");
+ while (1) ;
+}
+
+void mpc82xx_halt(void)
+{
+ local_irq_disable();
+ while (1) ;
+}
Index: linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/mpc82xx_ads.c
===
--- linux-powerpc-2.6.x.orig/arch/powerpc/platforms/82xx/mpc82xx_ads.c
2007-07-16 15:20:51.0 +0800
+++ linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/mpc82xx_ads.c
2007-07-16 15:47:04.0 +0800
@@ -606,35 +606,15 @@
return 1;
}
-#define RMR_CSRE 0x0001
-static void m82xx_restart(char *cmd)
-{
- __volatile__ unsigned char dummy;
-
- local_irq_disable();
- ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
-
- /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
- mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
- dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
- printk("Restart failed\n");
- while (1) ;
-}
-
-static void m82xx_halt(void)
-{
- local_irq_disable();
- while (1) ;
-}
-
define_machine(mpc82xx_ads)
{
- .name = "MPC82xx ADS",
- .probe = mpc82xx_ads_probe,
- .setup_arch =mpc82xx_ads_setup_arch,
- .init_IRQ =mpc82xx_ads_pic_init,
- .show_cpuinfo =mpc82xx_ads_show_cpuinfo,
- .get_irq =cpm2_get_irq,
- .calibrate_decr =m82xx_calibrate_decr,
- .restart = m82xx_restart,.halt = m82xx_halt,
+ .name = "MPC82xx ADS",
+ .probe = mpc82xx_ads_probe,
+ .setup_arch = mpc82xx_ads_setup_arch,
+ .init_IRQ = mpc82xx_ads_pic_init,
+ .show_cpuinfo = mpc82xx_show_cpuinfo,
+ .get_irq= cpm2_get_irq,
+ .calibrate_decr = mpc82xx_calibrate_decr,
+ .restart= mpc82xx_restart,
+ .halt = mpc82xx_halt,
};
Index: linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/pq2ads.h
===
--- linux-powerpc-2.6.x.orig/arch/powerpc/platforms/82xx/pq2ads.h
2007-07-16 15:20:51.0 +0800
+++ linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/pq2ads.h2007-07-16
15:47:04.0 +0800
@@ -59,8 +59,6 @@
#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
void m82xx_pci_init_irq(void);
-void mpc82xx_ads_show_cpuinfo(struct seq_file*);
-void m82xx_calibrate_decr(void);
#endif /* __MACH_ADS8260_DEFS */
#endif /* __KERNEL__ */
Index: linux-powerpc-2.6.x/include/asm-powerpc/mpc8260.h
===
[PATCH 3/3] 82xx: SBCPQ2 board platform support
This patch addes the powerpc support to Wind River SBC PowerQUICCII 82xx board.
Signed-off-by: Mark Zhan <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sbcpq2.dts | 191 +++
arch/powerpc/configs/sbcpq2_defconfig | 917
++
arch/powerpc/platforms/82xx/Kconfig | 10
arch/powerpc/platforms/82xx/Makefile |5
arch/powerpc/platforms/82xx/sbcpq2.c | 306 +++
arch/powerpc/platforms/82xx/sbcpq2.h | 118
include/asm-powerpc/mpc8260.h |4
7 files changed, 1549 insertions(+), 2 deletions(-)
Index: linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/Kconfig
===
--- linux-powerpc-2.6.x.orig/arch/powerpc/platforms/82xx/Kconfig
2007-07-16 16:25:11.0 +0800
+++ linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/Kconfig 2007-07-16
16:25:16.0 +0800
@@ -13,6 +13,16 @@
help
This option enables support for the MPC8272 ADS board
+config SBCPQ2
+ bool "Wind River SBC PowerQUICCII 82xx"
+ select DEFAULT_UIMAGE
+ select 8260
+ select CPM2
+ select FSL_SOC
+ help
+ This option enables support for Wind River SBC PowerQUICCII 82xx,
+ which is a single-board computer with MPC82xx CPU.
+
endchoice
config PQ2ADS
Index: linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/Makefile
===
--- linux-powerpc-2.6.x.orig/arch/powerpc/platforms/82xx/Makefile
2007-07-16 16:25:11.0 +0800
+++ linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/Makefile2007-07-16
16:25:16.0 +0800
@@ -1,5 +1,6 @@
#
# Makefile for the PowerPC 82xx linux kernel.
#
-obj-$(CONFIG_PPC_82xx) += mpc82xx.o
-obj-$(CONFIG_MPC82xx_ADS) += mpc82xx_ads.o
+obj-$(CONFIG_PPC_82xx) += mpc82xx.o
+obj-$(CONFIG_MPC82xx_ADS) += mpc82xx_ads.o
+obj-$(CONFIG_SBCPQ2) += sbcpq2.o
Index: linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/sbcpq2.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-powerpc-2.6.x/arch/powerpc/platforms/82xx/sbcpq2.c2007-07-16
16:29:55.0 +0800
@@ -0,0 +1,306 @@
+/*
+ * sbcpq2.c: The platform support for Wind River SBC PowerQUICCII 82xx
+ *
+ * Copyright 2007, Wind River Systems, Inc.
+ *
+ * Author: Mark Zhan <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct resource m48t59_resources[] = {
+ {
+ .start = SBCPQ2_RTC_BASE,
+ .end= SBCPQ2_RTC_BASE + SBCPQ2_RTC_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = SBCPQ2_M48T59_IRQ,
+ .end= SBCPQ2_M48T59_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ { },
+};
+
+static struct platform_device m48t59_rtc = {
+ .name = "rtc-m48t59",
+ .id = 0,
+ .num_resources = 2,
+ .resource = m48t59_resources,
+};
+
+static struct platform_device *sbcpq2_devices[] __initdata = {
+ &m48t59_rtc,
+};
+
+/**
+ * sbcpq2_pdev_init - Register the platform device for sbcpq2 board
+ */
+static int __init sbcpq2_platdev_init(void)
+{
+ struct irq_desc *desc = irq_desc + SBCPQ2_M48T59_IRQ;
+
+ /* Install a dummy irq chip for M48T59 RTC irq */
+ if (desc->chip == &no_irq_chip)
+ set_irq_handler(SBCPQ2_M48T59_IRQ, desc->handle_irq);
+
+ /* Register all platform devices for sbcpq2 */
+ platform_add_devices(sbcpq2_devices, ARRAY_SIZE(sbcpq2_devices));
+ return 0;
+}
+arch_initcall(sbcpq2_platdev_init);
+
+/*
+ * For SBCPQ2 board, the interrupt of M48T59 RTC chip
+ * will generate a machine check exception. We use a
+ * fake irq to give the platform machine_check_exception() hook
+ * a chance to call the driver ISR. If IRQ_HANDLED is returned,
+ * then we will survive from the machine check exception.
+ */
+static int sbcpq2_mach_check(struct pt_regs *regs)
+{
+ int recover = 0;
+ struct irq_desc *desc = irq_desc + SBCPQ2_M48T59_IRQ;
+ struct irqaction *action = desc->action;
+
+ while (action && (action->dev_id != &m48t59_rtc))
+ action = action->next;
+
+ /* Try to call m48t59 RTC driver ISR */
+ if (action && action->handler)
+ recover = action->handler(SBCPQ2_M48T59_IRQ, &m48t59_rtc);
+
+ retu
Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
Roland Dreier <[EMAIL PROTECTED]> wrote on 16.07.2007 18:04:26: > It seems not quite right to me for the driver to advertise nr_eqs > completion vectors, but then if round-robin is turned on to ignore the > consumer's decision about which vector to use. The round-robin feature was primarily meant as a debug/evaluation feature; it is not supposed to be active by default. ULP programmers can, for example, quickly evaluate the performance increase that comp_vectors could give them, without changing their code. Without this debug option, the comp_vector policy is still up to the ULPs. > Maybe if round-robin is turned on you should report 0 as the number of > completion vectors? That sounds like a reasonable idea -- I'll change that right away. > Maybe the whole interface is broken and we should only be exposing > policies to consumers instead of the specific vector? If so, I think the policies should be handled by the IB core code instead of being re-invented by each driver. The IB core would then again pass actual comp_vector values to the driver. > I think I would rather hold off on multiple EQs for this merge window > and plan on having something really solid and thought-out for 2.6.24. It's your call, but the code is there and I don't expect it to change a lot later, so it could be used by others to get a first impression of what's possible using comp_vectors and to gather some experience with them. Regards, Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/10] IB/ehca: use common error code mapping instead of specific ones
Roland Dreier <[EMAIL PROTECTED]> wrote on 16.07.2007 19:14:03: > applied, but as a further cleanup it seems that ehca2ib_return_code() > should be moved into a .c file and moved out of line -- I think it > would probably shrink the compiled code quite a bit, and as far as I > can see it is never used in the data path where the function call > overhead would matter at all. Sounds reasonable; I'll put it in the next patch series. Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
Roland Dreier <[EMAIL PROTECTED]> wrote on 16.07.2007 18:04:26: > Do you have any data on how well this round-robin assignment works? > It seems not quite right to me for the driver to advertise nr_eqs > completion vectors, but then if round-robin is turned on to ignore the > consumer's decision about which vector to use. No, I've no figures to provide here. The background of this dist_eqs option is actually to allow us testing across all event queues without to change the testcases resp consumers to use certain event queue number. Thus, I should comment it as EXPERIMENTAL? > Maybe if round-robin is turned on you should report 0 as the number of > completion vectors? Or maybe we should allow well-known values for > the completion vector passed to ib_create_cq to allow consumers to > specify a policy (like round robin) instead of a particular vector? > Maybe the whole interface is broken and we should only be exposing > policies to consumers instead of the specific vector? Agree in that device driver should not overwrite consumer's policy of event queue assigment. Since dist_eqs is disabled as default, there's no issue, isn't it? Regarding ib_verbs: perhaps we should provide create/destroy_eq() and let upper level protocols or consumers dictate the assignment to cq by passing an event queue pointer to create_cq()... > I think I would rather hold off on multiple EQs for this merge window > and plan on having something really solid and thought-out for 2.6.24. Fair enough. However why don't let us gather experience with this feature now? Should we remove dist_eqs option for more consistency? Thanks Nam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][PATCH] therm_adt746x: fix behaviour on !ADT7460
Hi,
this bug exists since I began using a powerbook 12". When the
system gets hot, therm_adt746x begins to oscillate between two fan
speeds every one or two seconds. The result is very annoying not
optimal: while switching between two speeds, the machine takes a long
time to get cold again. This powerbook doesn't has a ADT7460, so it
only has one fan for both CPU and GPU. The problem happens when one of
the sensors (CPU, GPU) gets hotter than the other:
[172] temp is: 52, limit is: 50, var is 2, new_speed is 91, last_var is 4
[173] temp is: 74, limit is: 70, var is 4, new_speed is 145, last_var is 2
[174] temp is: 52, limit is: 50, var is 2, new_speed is 91, last_var is 4
[175] temp is: 74, limit is: 70, var is 4, new_speed is 145, last_var is 2
[176] temp is: 52, limit is: 50, var is 2, new_speed is 91, last_var is 4
When update_fans_speed() is called, it first finds that the CPU
temperature is over the limit (52/50) and because the variation (2 F) is
different enough from the last (4 F) and sets the fan speed to 91. As it
changed the fan speed, "started" variable is set to 1 and the function
returns. In the next time update_fan_speed() is called, it'll find the
temperature as the same for the CPU (or close to the same) and will go
to the next sensor. On the GPU, the temperature is 74 (70 is the limit),
so the variation is 4 F, different enough from the previous (2 F) to
change the fan speed. The fan speed is changed to 145 and the variation
(4 F) is stored. Next time, CPU sensor is checked and the variation is
2 F, different enough from the previous one, 4 F, so it changes the fan
speed again. And this goes on...
The patch changes update_fans_speed() to first collect the highest
variation for each fan and updates their speed accordingly, instead of
setting the same speed for both fans.
I've been testing this on my powerbook with different loads and it fixes
the problem. I'd like to hear from people with bigger powerbooks (15",
17") if it makes any difference (it should be quieter, since fans will
have different speeds).
Comments?
--- linus-2.6.orig/drivers/macintosh/therm_adt746x.c2007-07-16
12:56:25.0 -0400
+++ linus-2.6/drivers/macintosh/therm_adt746x.c 2007-07-16 14:08:08.0
-0400
@@ -278,26 +278,34 @@
static void update_fans_speed (struct thermostat *th)
{
- int lastvar = 0; /* last variation, for iBook */
- int i = 0;
+ int sensor, fan, adt7460, vars[2] = { -50, -50 };
+
+ adt7460 = (therm_type == ADT7460);
/* we don't care about local sensor, so we start at sensor 1 */
- for (i = 1; i < 3; i++) {
- int started = 0;
- int fan_number = (therm_type == ADT7460 && i == 2);
- int var = th->temps[i] - th->limits[i];
+ for (sensor = 1; sensor < 3; sensor++) {
+ int diff;
+ fan = (adt7460 && sensor == 2);
+ diff = th->temps[sensor] - th->limits[sensor];
+ if (diff > vars[fan])
+ vars[fan] = diff;
+ }
- if (var > -1) {
+ /*
+* here we have the biggest variation for each fan (in cases where
+* a single fan is used for two sensors).
+*/
+ for (fan = 0; fan < (1 + adt7460); fan++) {
+ if (vars[fan] > -1) {
int step = (255 - fan_speed) / 7;
int new_speed = 0;
/* hysteresis : change fan speed only if variation is
* more than two degrees */
- if (abs(var - th->last_var[fan_number]) < 2)
+ if (abs(vars[fan] - th->last_var[fan]) < 2)
continue;
- started = 1;
- new_speed = fan_speed + ((var-1)*step);
+ new_speed = fan_speed + ((vars[fan] - 1) * step);
if (new_speed < fan_speed)
new_speed = fan_speed;
@@ -305,29 +313,19 @@
new_speed = 255;
if (verbose)
- printk(KERN_DEBUG "adt746x: Setting fans speed
to %d "
-"(limit exceeded by %d on %s)
\n",
- new_speed, var,
- sensor_location[fan_number+1]);
- write_both_fan_speed(th, new_speed);
- th->last_var[fan_number] = var;
- } else if (var < -2) {
- /* don't stop fan if sensor2 is cold and sensor1 is not
-* so cold (lastvar >= -1) */
- if (i == 2 && lastvar < -1) {
- if (th->last_speed[fan_number] != 0)
- if (verbose)
- printk(KERN_DEBUG "adt746x:
[PATCH] adbhid: enable KEY_FN key reporting
When a Fn key is used in combination with another key in ADB keyboards
it will generate a Fn event and then a second event that can be a
different key than pressed (Fn + F1 for instance can generate Fn +
brightness down if it's configured like that). This patch enables the
reporting of the Fn key to the input system.
As Fn is a dead key for most purposes, it's useful to report it so
applications can make use of it. One example is apple_mouse
(https://jake.ruivo.org/uinputd/trunk/apple_mouse/) that emulates the
second and third keys using a combination of keyboard keys and the mouse
button. Other applications may use the KEY_FN as a modifier aswell.
I've been updating and using this patch for months without problems.
Signed-off-by: Aristeu Rozanski <[EMAIL PROTECTED]>
--- linus-2.6.orig/drivers/macintosh/adbhid.c 2007-05-11 10:09:13.0
-0400
+++ linus-2.6/drivers/macintosh/adbhid.c2007-05-11 10:09:19.0
-0400
@@ -70,7 +70,7 @@
#define ADB_KEY_POWER_OLD 0x7e
#define ADB_KEY_POWER 0x7f
-u8 adb_to_linux_keycodes[128] = {
+u16 adb_to_linux_keycodes[128] = {
/* 0x00 */ KEY_A, /* 30 */
/* 0x01 */ KEY_S, /* 31 */
/* 0x02 */ KEY_D, /* 32 */
@@ -134,7 +134,7 @@
/* 0x3c */ KEY_RIGHT, /* 106 */
/* 0x3d */ KEY_DOWN,/* 108 */
/* 0x3e */ KEY_UP, /* 103 */
- /* 0x3f */ 0,
+ /* 0x3f */ KEY_FN, /* 0x1d0 */
/* 0x40 */ 0,
/* 0x41 */ KEY_KPDOT, /* 83 */
/* 0x42 */ 0,
@@ -208,7 +208,7 @@
int original_handler_id;
int current_handler_id;
int mouse_kind;
- unsigned char *keycode;
+ u16 *keycode;
char name[64];
char phys[32];
int flags;
@@ -275,7 +275,7 @@
adbhid_input_keycode(int id, int keycode, int repeat)
{
struct adbhid *ahid = adbhid[id];
- int up_flag;
+ int up_flag, key;
up_flag = (keycode & 0x80);
keycode &= 0x7f;
@@ -321,8 +321,7 @@
}
} else
ahid->flags |= FLAG_FN_KEY_PRESSED;
- /* Swallow the key press */
- return;
+ break;
case ADB_KEY_DEL:
/* Emulate Fn+delete = forward delete */
if (ahid->flags & FLAG_FN_KEY_PRESSED) {
@@ -336,9 +335,9 @@
#endif /* CONFIG_PPC_PMAC */
}
- if (adbhid[id]->keycode[keycode]) {
- input_report_key(adbhid[id]->input,
-adbhid[id]->keycode[keycode], !up_flag);
+ key = adbhid[id]->keycode[keycode];
+ if (key) {
+ input_report_key(adbhid[id]->input, key, !up_flag);
input_sync(adbhid[id]->input);
} else
printk(KERN_INFO "Unhandled ADB key (scancode %#02x) %s.\n",
keycode,
@@ -757,8 +756,8 @@
input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_LED) | BIT(EV_REP);
input_dev->ledbit[0] = BIT(LED_SCROLLL) | BIT(LED_CAPSL) |
BIT(LED_NUML);
input_dev->event = adbhid_kbd_event;
- input_dev->keycodemax = 127;
- input_dev->keycodesize = 1;
+ input_dev->keycodemax = KEY_FN;
+ input_dev->keycodesize = sizeof(hid->keycode[0]);
break;
case ADB_MOUSE:
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] adb: make sysrq key configurable at runtime
These two patches make possible to configure the sysrq key on ADB based machines where the default sysrq key (0x69) is not present. The first patch creates a class device for each handled device. The second one adds an attribute to ADB keyboards that makes possible to configure the sysrq key for each keyboard. -- Aristeu ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] adb: create class devices for each adb device
This patch adds a class device for each adb device that has a handler.
The class device contents will be accessible by /sys/class/adb/N
directory. This patch is needed in order to add an class device
attribute to all keyboards that will determine the sysrq key for each
keyboard.
Signed-of-by: Aristeu Rozanski <[EMAIL PROTECTED]>
--- linus-2.6.orig/drivers/macintosh/adb.c 2007-05-11 10:09:13.0
-0400
+++ linus-2.6/drivers/macintosh/adb.c 2007-05-11 10:09:36.0 -0400
@@ -102,11 +102,21 @@
static void adbdev_init(void);
static int try_handler_change(int, int);
+static char *adb_device_id_string[] = {
+ [ADB_DONGLE] = "dongle",
+ [ADB_KEYBOARD] = "keyboard",
+ [ADB_MOUSE] = "mouse",
+ [ADB_TABLET] = "tablet",
+ [ADB_MODEM] = "modem",
+ [ADB_MISC] = "misc",
+};
+
static struct adb_handler {
void (*handler)(unsigned char *, int, int);
int original_address;
int handler_id;
int busy;
+ char name[16];
} adb_handler[16];
/*
@@ -508,6 +518,9 @@
if ((adb_handler[i].original_address == default_id) &&
(!handler_id || (handler_id == adb_handler[i].handler_id)
||
try_handler_change(i, handler_id))) {
+ int rc;
+ struct class_device *cdev;
+
if (adb_handler[i].handler != 0) {
printk(KERN_ERR
"Two handlers for ADB device %d\n",
@@ -517,7 +530,26 @@
write_lock_irq(&adb_handler_lock);
adb_handler[i].handler = handler;
write_unlock_irq(&adb_handler_lock);
- ids->id[ids->nids++] = i;
+
+ snprintf(adb_handler[i].name,
+ sizeof(adb_handler[i].name), "%s%i",
+ adb_device_id_string[default_id], ids->nids);
+
+ cdev = &ids->id[ids->nids].cdev;
+ cdev->class = adb_dev_class;
+ class_device_initialize(cdev);
+ snprintf(cdev->class_id, sizeof(cdev->class_id), "%s",
+adb_handler[i].name);
+ rc = class_device_add(cdev);
+ if (rc) {
+ printk(KERN_WARNING "adb: unable to add class "
+ "device\n");
+ for (i = ids->nids - 1; i >= 0; i--)
+ class_device_del(&ids->id[i].cdev);
+ ids->nids = 0;
+ return 0;
+ }
+ ids->id[ids->nids++].id = i;
}
}
up(&adb_handler_sem);
@@ -525,9 +557,9 @@
}
int
-adb_unregister(int index)
+adb_unregister(int index, struct adb_ids *ids)
{
- int ret = -ENODEV;
+ int i, ret = -ENODEV;
down(&adb_handler_sem);
write_lock_irq(&adb_handler_lock);
@@ -539,6 +571,8 @@
}
ret = 0;
adb_handler[index].handler = NULL;
+ for (i = 0; i < ids->nids; i++)
+ class_device_del(&ids->id[i].cdev);
}
write_unlock_irq(&adb_handler_lock);
up(&adb_handler_sem);
--- linus-2.6.orig/include/linux/adb.h 2007-05-11 10:09:13.0 -0400
+++ linus-2.6/include/linux/adb.h 2007-05-11 10:09:36.0 -0400
@@ -3,6 +3,7 @@
*/
#ifndef __ADB_H
#define __ADB_H
+#include
/* ADB commands */
#define ADB_BUSRESET 0
@@ -57,7 +58,11 @@
struct adb_ids {
int nids;
- unsigned char id[16];
+ struct adb_id {
+ unsigned char id;
+ struct class_device cdev;
+ void *priv;
+ } id[16];
};
/* Structure which encapsulates a low-level ADB driver */
@@ -91,7 +96,7 @@
int flags, int nbytes, ...);
int adb_register(int default_id,int handler_id,struct adb_ids *ids,
void (*handler)(unsigned char *, int, int));
-int adb_unregister(int index);
+int adb_unregister(int index, struct adb_ids *ids);
void adb_poll(void);
void adb_input(unsigned char *, int, int);
int adb_reset_bus(void);
--- linus-2.6.orig/drivers/macintosh/adbhid.c 2007-05-11 10:09:19.0
-0400
+++ linus-2.6/drivers/macintosh/adbhid.c2007-05-11 10:10:15.0
-0400
@@ -875,7 +875,7 @@
adb_register(ADB_MISC, 0, &buttons_ids, adbhid_buttons_input);
for (i = 0; i < keyboard_ids.nids; i++) {
- int id = keyboard_ids.id[i];
+ int id = keyboard_ids.id[i].id;
adb_get_infos(id, &default_id, &org_handler_id);
@@ -902,7 +902,7 @@
}
for (i = 0; i < buttons_ids.nids; i++) {
- int id = buttons_ids.id[i];
+ int id = butto
[PATCH 2/2] adbhid: make sysrq key configurable on adb keyboards
This patch adds an sysfs attribute to each handled ADB keyboard in order
to support runtime sysrq key configuration. This is needed because some
machines don't have the default sysrq key (0x69). The key will be
configurable by /sys/class/adb/keyboard/sysrq_key.
Signed-of-by: Aristeu Rozanski <[EMAIL PROTECTED]>
--- linus-2.6.orig/drivers/macintosh/adbhid.c 2007-05-23 20:39:11.0
-0400
+++ linus-2.6/drivers/macintosh/adbhid.c2007-05-23 20:39:41.0
-0400
@@ -176,7 +176,7 @@
/* 0x66 */ KEY_HANJA, /* 123 */
/* 0x67 */ KEY_F11, /* 87 */
/* 0x68 */ KEY_HANGEUL, /* 122 */
- /* 0x69 */ KEY_SYSRQ, /* 99 */
+ /* 0x69 */ 0,
/* 0x6a */ 0,
/* 0x6b */ KEY_SCROLLLOCK, /* 70 */
/* 0x6c */ 0,
@@ -212,6 +212,7 @@
char name[64];
char phys[32];
int flags;
+ int sysrq_key;
};
#define FLAG_FN_KEY_PRESSED0x0001
@@ -252,6 +253,64 @@
#define ADBMOUSE_MS_A3 8 /* Mouse systems A3 trackball (handler
3) */
#define ADBMOUSE_MACALLY2 9 /* MacAlly 2-button mouse */
+/* SYSRQ support */
+#ifdef CONFIG_MAGIC_SYSRQ
+#define ADBHID_DEFAULT_SYSRQ 0x69
+#define class_device_to_adbhid(x) \
+ ((struct adbhid *)(container_of(x, struct adb_id, cdev))->priv)
+static ssize_t adbhid_show_sysrq_key(struct class_device *dev, char *buf)
+{
+ struct adbhid *hid = class_device_to_adbhid(dev);
+
+ return sprintf(buf, "%#x\n", hid->sysrq_key);
+}
+static ssize_t adbhid_store_sysrq_key(struct class_device *dev,
+ const char *buf, size_t n)
+{
+ int val;
+ struct adbhid *hid = class_device_to_adbhid(dev);
+
+ val = simple_strtol(buf, NULL, 10);
+ if (val > 255)
+ return -EINVAL;
+ hid->sysrq_key = val;
+
+ return n;
+}
+
+static CLASS_DEVICE_ATTR(sysrq_key, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,
+adbhid_show_sysrq_key, adbhid_store_sysrq_key);
+static inline int adbhid_key_is_sysrq(struct adbhid *hid, int keycode)
+{
+ if (unlikely(keycode == hid->sysrq_key))
+ return KEY_SYSRQ;
+ return 0;
+}
+
+static inline void adbhid_register_sysrq_attr(struct adb_id *kbd,
+ struct adbhid *hid)
+{
+ int retval;
+
+ kbd->priv = hid;
+ retval = class_device_create_file(&kbd->cdev,
+ &class_device_attr_sysrq_key);
+ if (retval)
+ printk(KERN_WARNING "adbhid: unable to create class device "
+ "file\n");
+}
+static inline void adbhid_set_default_sysrq(struct adbhid *hid)
+{
+ hid->sysrq_key = ADBHID_DEFAULT_SYSRQ;
+}
+#define adbhid_set_sysrq(x) set_bit(KEY_SYSRQ, (x))
+#else /* !CONFIG_MAGIC_SYSRQ */
+#define adbhid_key_is_sysrq(x, y) (0)
+#define adbhid_register_sysrq_attr(x, y) do { } while(0)
+#define adbhid_set_sysrq(x) do { } while(0)
+#define adbhid_set_default_sysrq(x) do { } while(0)
+#endif /* CONFIG_MAGIC_SYSRQ */
+
static void
adbhid_keyboard_input(unsigned char *data, int nb, int apoll)
{
@@ -275,7 +334,7 @@
adbhid_input_keycode(int id, int keycode, int repeat)
{
struct adbhid *ahid = adbhid[id];
- int up_flag, key;
+ int up_flag, key = 0;
up_flag = (keycode & 0x80);
keycode &= 0x7f;
@@ -335,10 +394,12 @@
#endif /* CONFIG_PPC_PMAC */
}
- key = adbhid[id]->keycode[keycode];
- if (key) {
- input_report_key(adbhid[id]->input, key, !up_flag);
- input_sync(adbhid[id]->input);
+ key = adbhid_key_is_sysrq(ahid, keycode);
+ if (!key)
+ key = ahid->keycode[keycode];
+ if (key) {
+ input_report_key(ahid->input, key, !up_flag);
+ input_sync(ahid->input);
} else
printk(KERN_INFO "Unhandled ADB key (scancode %#02x) %s.\n",
keycode,
up_flag ? "released" : "pressed");
@@ -698,6 +759,7 @@
hid->current_handler_id = current_handler_id;
hid->mouse_kind = mouse_kind;
hid->flags = 0;
+ adbhid_set_default_sysrq(hid);
input_set_drvdata(input_dev, hid);
input_dev->name = hid->name;
input_dev->phys = hid->phys;
@@ -752,6 +814,7 @@
for (i = 0; i < 128; i++)
if (hid->keycode[i])
set_bit(hid->keycode[i], input_dev->keybit);
+ adbhid_set_sysrq(input_dev->keybit);
input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_LED) | BIT(EV_REP);
input_dev->ledbit[0] = BIT(LED_SCROLLL) | BIT(LED_CAPSL) |
BIT(LED_NUML);
@@ -899,6 +962,8 @@
adb_get_infos(id, &default_id, &cur_handler_id);
reg |= adbhid_input_reregister(id, default_id, org_handler_id,
cur_handler_id, 0);
+
Re: [PATCH 10/10] IB/ehca: Support large page MRs
Roland Dreier <[EMAIL PROTECTED]> wrote on 16.07.2007 19:37:09:
> > If enabled via the mr_largepage module parameter,
>
> Why the module parameter? Is there any reason a user would want to
> turn this off? Or conversely, why is it off by default?
We're pretty confident this new feature works, but as with all new and
possibly experimental features, there are chances it might explode your
machine when activated. So, like with the scaling code, we want the user
to make the conscious decision of using this code instead of activating it
by default.
> > static ssize_t ehca_show_nr_eqs(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
> > {
> > return sprintf(buf, "%d\n", ehca_nr_eqs);
> > }
> > -
> > static DEVICE_ATTR(nr_eqs, S_IRUGO, ehca_show_nr_eqs, NULL);
>
> Although trivial, this chunk doesn't really belong in this patch --
> just fix it up in the multiple EQ patch (which I haven't merged yet).
Sure thing.
Regards,
Joachim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
of_flat_dt_is_compatible() scope Q
Hi Just noticed, that of_flat_dt_is_compatible() is only ever used with node = of_get_flat_dt_root(). So, unless we ever plan to use it otherwise, someone might want to simplify it a bit:-) Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Legacy ISA registers/interrupts in PCI device tree node
On Mon, 2007-07-16 at 09:59 +0100, Matt Sealey wrote: > You could do a LOT worse than check the Pegasos. Yes, mimmicing the pegasos will probably work > Matt Sealey <[EMAIL PROTECTED]> > 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? You may need a fixup like pegasos does because that chip seems to use 14/15 even when in native mode, which is somewhat out of spec. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
> Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64, > flush_dcache_page() isn't. So I'd prefer to not call it if not really needed. > > And according to James, flush_kernel_dcache_page() should be sufficient... > > So I'm getting puzzled again... flush_dcache_page() handles icache vs. dcache coherency by clearing the PG_arch_1 bit in the struct page that indicates that the page is cache clean. You -must- call it if you're going to use any form of CPU access to write to the page (basically dirtying the data cache) and that page can be ever mapped into user space and executed from. I don't know what flush_kernel_dcache_page() does and if it needs a similar treatement, it's a new interface, so maybe Jens and or James can tell me more about it.. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 2007-07-16 at 08:47 -0500, James Bottomley wrote: > > No ... that was the point of flush_kernel_dcache_page(). The page in > question is page cache backed and contains user mappings. However, > the > block layer has already done a flush_dcache_page() in get_user_pages() > and the user shouldn't be touching memory under I/O (unless they want > self induced aliasing problems) so we're free to assume all the user > cachelines are purged, hence all we have to do is flush the kernel > alias > to bring the page up to date and make the users see it correctly. Ok. In our case the problem is not aliases though, it's the coherency between instruction and data caches for pages that may be executed from (such as swapped out text pages). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 6/8] Walnut DTS
On Mon, 2007-07-16 at 16:34 +0200, Segher Boessenkool wrote: > >>> + #address-cells = <0>; > >>> + #size-cells = <0>; > >> > >> No need for these. > > > > Isn't a good practice to put #address-cells in interrupt controller > > nodes? > > It is not. Well, that's debatable... but yes, a strict reading of the spec would say that you should put neither #address-cells nor #size-cells in a leaf interrupt controller. > > If the device tree has an interrupt map defined the interrupt > > parent 'unit interrupt specifier' has to be interpreted according > > to the #address-cells of the interrupt parent. > > And "#address-cells" is defaulted to 0 if it is absent, > for the purpose of interrupt mapping (but not for its > other purposes). This is a bit confusing though, which is why I tend to prefer having it explicitely in the interrupt controller node :-) I tend to dislike "magic" defaults, we've had problems with them in the past and will have in the future, I much prefer having things explicit whenever possible. > Typically, such interrupt controllers > don't have device tree children so it doesn't make sense > to give them an "#address-cells" anyway. Somewhat... > > It seems like > > typical practice in the current DTS files to explicitly define this > > in the interrupt controller. > > That "typical practice" is inspired by the need to explicitly > put #address-cells and #size-cells into the device tree if you > want Linux to properly parse the device tree, even if the default > values would work perfectly (if Linux would work correctly, > that is). Linux does handle default values in some areas. The problem with default values is that they are badly defined and the spec contains gray areas and contradictions as to what the default values should be in some circumstances. As a general matter, I dislike default values because they somewhat require background knowledge of what default values should be in different contexts to "read" a device-tree. To be simple, I believe default values are a bad idea. > There are no child nodes, and no binding that says there can > be any; neither #address-cells not #size-cells should be there. You are being way too pedantic here. The interrupt-tree uses those two properties, thus "there is no child node" is open to interpretation. There is no child device node, but there are child interrupt nodes, and since the interrupt-tree uses #address/size-cells, it does make some sense to specify them. Yes, there is a default value when absent, but the simple fact that the default is different depending if you are doing a device walk or an interrupt tree walk is very confusing. As I said above, the default values are a source of more problem than anything else and I tend to think they should be banned. I would personally be inclined to define that whatever spec we come up with always require #address-cells/#size-cells for any node that can have either device children or interrupt children, and ban default values alltogether. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
> No ... that was the point of flush_kernel_dcache_page(). The page in > question is page cache backed and contains user mappings. However, the > block layer has already done a flush_dcache_page() in get_user_pages() > and the user shouldn't be touching memory under I/O (unless they want > self induced aliasing problems) so we're free to assume all the user > cachelines are purged, hence all we have to do is flush the kernel alias > to bring the page up to date and make the users see it correctly. The block layer will have done that even in the swap-out path ? (Just asking... I'm not very familiar with the block layer) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cell: CONFIG_SPE_BASE is a typo (was: Re: possible dead CONFIG-related content under arch/powerpc)
On Mon, 2007-07-16 at 18:35 +0200, Geert Uytterhoeven wrote: > The config symbol for SPE support is called CONFIG_SPU_BASE, not > CONFIG_SPE_BASE. Oops... Arnd, we need to check the distro kernels here. > Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c > index 4f2f453..0b25d42 100644 > --- a/arch/powerpc/mm/hash_utils_64.c > +++ b/arch/powerpc/mm/hash_utils_64.c > @@ -609,7 +609,7 @@ static void demote_segment_4k(struct mm_struct *mm, > unsigned long addr) > mm->context.sllp = SLB_VSID_USER | mmu_psize_defs[MMU_PAGE_4K].sllp; > #endif /* CONFIG_PPC_MM_SLICES */ > > -#ifdef CONFIG_SPE_BASE > +#ifdef CONFIG_SPU_BASE > spu_flush_all_slbs(mm); > #endif > } > @@ -744,7 +744,7 @@ int hash_page(unsigned long ea, unsigned long access, > unsigned long trap) > "to 4kB pages because of " > "non-cacheable mapping\n"); > psize = mmu_vmalloc_psize = MMU_PAGE_4K; > -#ifdef CONFIG_SPE_BASE > +#ifdef CONFIG_SPU_BASE > spu_flush_all_slbs(mm); > #endif > } > > 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: [EMAIL PROTECTED] > 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 > ___ Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 6/8] Walnut DTS
Benjamin Herrenschmidt wrote: > I would personally be inclined to define that whatever spec we come up > with always require #address-cells/#size-cells for any node that can > have either device children or interrupt children, and ban default > values alltogether. When is #size-cells used in the interrupt tree at all? And given the odd behavior of using an interrupt map in an interrupt parent that is not the device parent (you're potentially using keys from different domains that could clash, be a different sizes, etc), if we make any changes in that regard, I'd forbid interrupt maps in interrupt controllers with no device children, and thus #address-cells has no meaning there. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC][PATCH 6/8] Walnut DTS
[snip] > There is no child device node, but there are child interrupt > nodes, and > since the interrupt-tree uses #address/size-cells, it does make some > sense to specify them. > > Yes, there is a default value when absent, but the simple > fact that the > default is different depending if you are doing a device walk or an > interrupt tree walk is very confusing. As I said above, the default > values are a source of more problem than anything else and I tend to > think they should be banned. > > I would personally be inclined to define that whatever spec we come up > with always require #address-cells/#size-cells for any node that can > have either device children or interrupt children, and ban default > values alltogether. Did you really mean #size-cells here? Shouldn't it be #interrupt-cells? Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] crash in 2.6.22-git2 sysctl_set_parent()
From: [EMAIL PROTECTED] (Linas Vepstas) Date: Mon, 16 Jul 2007 12:25:35 -0500 > On Fri, Jul 13, 2007 at 03:47:02PM -0700, David Miller wrote: > > From: [EMAIL PROTECTED] (Linas Vepstas) > > Date: Fri, 13 Jul 2007 15:05:15 -0500 > > > > > > > > This is a patch (& bug report) for a crash in sysctl_set_parent() > > > in 2.6.22-git2. > > > > > > Problem: 2.6.22-git2 crashes with a stack trace > > > > > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > > > Thanks for tracking this down, I'll apply your patch. > > NAK. As I just explained in another email, this bug > was introduced by the "send-to-self" patch I habitually > apply -- so habitually, that I forgot I was not working > with a "clean" tree. So it goes ... I saw all of this, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] eHEA: Introducing support vor DLPAR memory add
Thomas Klein wrote: > This patch adds support for DLPAR memory add to the eHEA driver. To detect > whether memory was added the driver uses its own memory mapping table and > checks for kernel addresses whether they're located in already known memory > sections. If not the function ehea_rereg_mrs() is triggered which performs > a rebuild of the mapping table and a re-registration of the global memory > region. > > Signed-off-by: Thomas Klein <[EMAIL PROTECTED]> > --- > > drivers/net/ehea/ehea.h | 23 +-- > drivers/net/ehea/ehea_main.c | 144 +++ > drivers/net/ehea/ehea_phyp.h |3 + > drivers/net/ehea/ehea_qmr.c | 156 > ++ > drivers/net/ehea/ehea_qmr.h | 14 +++- > 5 files changed, 275 insertions(+), 65 deletions(-) applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Tue, 2007-07-17 at 07:49 +1000, Benjamin Herrenschmidt wrote: > > No ... that was the point of flush_kernel_dcache_page(). The page in > > question is page cache backed and contains user mappings. However, the > > block layer has already done a flush_dcache_page() in get_user_pages() > > and the user shouldn't be touching memory under I/O (unless they want > > self induced aliasing problems) so we're free to assume all the user > > cachelines are purged, hence all we have to do is flush the kernel alias > > to bring the page up to date and make the users see it correctly. > > The block layer will have done that even in the swap-out path ? (Just > asking... I'm not very familiar with the block layer) Er ... not really, this is the I/O path for user initiated I/O. The page out path, by definition, can't have any extant user mappings. For page out, the relevant page is flushed before its mapping is detached, and then it can be paged to the backing store (or for anonymous pages to the swap device) when no mappings remain. James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 6/8] Walnut DTS
On Mon, 2007-07-16 at 16:55 -0500, Scott Wood wrote: > Benjamin Herrenschmidt wrote: > > I would personally be inclined to define that whatever spec we come up > > with always require #address-cells/#size-cells for any node that can > > have either device children or interrupt children, and ban default > > values alltogether. > > When is #size-cells used in the interrupt tree at all? It's not, sorry, my fingers typed a bit too fast :-) > And given the odd behavior of using an interrupt map in an interrupt > parent that is not the device parent (you're potentially using keys from > different domains that could clash, be a different sizes, etc), if we > make any changes in that regard, I'd forbid interrupt maps in interrupt > controllers with no device children, and thus #address-cells has no > meaning there. No, interrupt maps are useful in devices with no children in some corner cases. Remember that a map doesnt need to use the address part of the source specifier, thus it can be used to do a pure domain->domain conversion of the irq numbers, what sort of thing. The map has the added advantage that today, it's the only mechanism that allows you to specify different interrupt-parents through the same nexus, which is useful for 4xx. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC][PATCH 6/8] Walnut DTS
> > I would personally be inclined to define that whatever spec we come up > > with always require #address-cells/#size-cells for any node that can > > have either device children or interrupt children, and ban default > > values alltogether. > > Did you really mean #size-cells here? Shouldn't it be #interrupt-cells? Yup, as I said, my fingers got a bit too fast on the keyboard. I means #interrupt-cells. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 2007-07-16 at 17:03 -0500, James Bottomley wrote: > On Tue, 2007-07-17 at 07:49 +1000, Benjamin Herrenschmidt wrote: > > > No ... that was the point of flush_kernel_dcache_page(). The page in > > > question is page cache backed and contains user mappings. However, the > > > block layer has already done a flush_dcache_page() in get_user_pages() > > > and the user shouldn't be touching memory under I/O (unless they want > > > self induced aliasing problems) so we're free to assume all the user > > > cachelines are purged, hence all we have to do is flush the kernel alias > > > to bring the page up to date and make the users see it correctly. > > > > The block layer will have done that even in the swap-out path ? (Just > > asking... I'm not very familiar with the block layer) > > Er ... not really, this is the I/O path for user initiated I/O. The > page out path, by definition, can't have any extant user mappings. For > page out, the relevant page is flushed before its mapping is detached, > and then it can be paged to the backing store (or for anonymous pages to > the swap device) when no mappings remain. Ok, thanks. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 6/8] Walnut DTS
Benjamin Herrenschmidt wrote: > No, interrupt maps are useful in devices with no children in some corner > cases. Remember that a map doesnt need to use the address part of the > source specifier, thus it can be used to do a pure domain->domain > conversion of the irq numbers, what sort of thing. The map has the added > advantage that today, it's the only mechanism that allows you to specify > different interrupt-parents through the same nexus, which is useful for > 4xx. OK... but if you're doing a pure IRQ number conversion, the only useful #address-cells would be zero, which makes it a reasonable default IMHO (unlike the arbitrary 2 for regular traversal). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix Tsi108 ethernet driver performance
Alexandre Bounine wrote: > From: Alexandre Bounine <[EMAIL PROTECTED]> > > This patch improves performance of the Tsi108 Ethernet driver by > changing interrupt handling for frame receive path. It reduces number of > interrupts generated for received frames and therefore lowers CPU > utilization by the device driver. > > Signed-off-by: Alexandre Bounine <[EMAIL PROTECTED]> Look into NAPI... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 6/8] Walnut DTS
On Mon, 2007-07-16 at 17:18 -0500, Scott Wood wrote: > > OK... but if you're doing a pure IRQ number conversion, the only useful > #address-cells would be zero, which makes it a reasonable default IMHO > (unlike the arbitrary 2 for regular traversal). It does make a reasonable default. The thing, as I exlained, is I dislike the whole idea of "default" values in the first place. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] adbhid: enable KEY_FN key reporting
On Mon, 2007-07-16 at 16:53 -0400, Aristeu Rozanski wrote:
> When a Fn key is used in combination with another key in ADB keyboards
> it will generate a Fn event and then a second event that can be a
> different key than pressed (Fn + F1 for instance can generate Fn +
> brightness down if it's configured like that). This patch enables the
> reporting of the Fn key to the input system.
>
> As Fn is a dead key for most purposes, it's useful to report it so
> applications can make use of it. One example is apple_mouse
> (https://jake.ruivo.org/uinputd/trunk/apple_mouse/) that emulates the
> second and third keys using a combination of keyboard keys and the mouse
> button. Other applications may use the KEY_FN as a modifier aswell.
> I've been updating and using this patch for months without problems.
>
> Signed-off-by: Aristeu Rozanski <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> --- linus-2.6.orig/drivers/macintosh/adbhid.c 2007-05-11 10:09:13.0
> -0400
> +++ linus-2.6/drivers/macintosh/adbhid.c 2007-05-11 10:09:19.0
> -0400
> @@ -70,7 +70,7 @@
> #define ADB_KEY_POWER_OLD0x7e
> #define ADB_KEY_POWER0x7f
>
> -u8 adb_to_linux_keycodes[128] = {
> +u16 adb_to_linux_keycodes[128] = {
> /* 0x00 */ KEY_A, /* 30 */
> /* 0x01 */ KEY_S, /* 31 */
> /* 0x02 */ KEY_D, /* 32 */
> @@ -134,7 +134,7 @@
> /* 0x3c */ KEY_RIGHT, /* 106 */
> /* 0x3d */ KEY_DOWN,/* 108 */
> /* 0x3e */ KEY_UP, /* 103 */
> - /* 0x3f */ 0,
> + /* 0x3f */ KEY_FN, /* 0x1d0 */
> /* 0x40 */ 0,
> /* 0x41 */ KEY_KPDOT, /* 83 */
> /* 0x42 */ 0,
> @@ -208,7 +208,7 @@
> int original_handler_id;
> int current_handler_id;
> int mouse_kind;
> - unsigned char *keycode;
> + u16 *keycode;
> char name[64];
> char phys[32];
> int flags;
> @@ -275,7 +275,7 @@
> adbhid_input_keycode(int id, int keycode, int repeat)
> {
> struct adbhid *ahid = adbhid[id];
> - int up_flag;
> + int up_flag, key;
>
> up_flag = (keycode & 0x80);
> keycode &= 0x7f;
> @@ -321,8 +321,7 @@
> }
> } else
> ahid->flags |= FLAG_FN_KEY_PRESSED;
> - /* Swallow the key press */
> - return;
> + break;
> case ADB_KEY_DEL:
> /* Emulate Fn+delete = forward delete */
> if (ahid->flags & FLAG_FN_KEY_PRESSED) {
> @@ -336,9 +335,9 @@
> #endif /* CONFIG_PPC_PMAC */
> }
>
> - if (adbhid[id]->keycode[keycode]) {
> - input_report_key(adbhid[id]->input,
> - adbhid[id]->keycode[keycode], !up_flag);
> + key = adbhid[id]->keycode[keycode];
> + if (key) {
> + input_report_key(adbhid[id]->input, key, !up_flag);
> input_sync(adbhid[id]->input);
> } else
> printk(KERN_INFO "Unhandled ADB key (scancode %#02x) %s.\n",
> keycode,
> @@ -757,8 +756,8 @@
> input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_LED) | BIT(EV_REP);
> input_dev->ledbit[0] = BIT(LED_SCROLLL) | BIT(LED_CAPSL) |
> BIT(LED_NUML);
> input_dev->event = adbhid_kbd_event;
> - input_dev->keycodemax = 127;
> - input_dev->keycodesize = 1;
> + input_dev->keycodemax = KEY_FN;
> + input_dev->keycodesize = sizeof(hid->keycode[0]);
> break;
>
> case ADB_MOUSE:
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] adb: create class devices for each adb device
On Mon, 2007-07-16 at 16:53 -0400, Aristeu Rozanski wrote:
> This patch adds a class device for each adb device that has a handler.
> The class device contents will be accessible by /sys/class/adb/N
> directory. This patch is needed in order to add an class device
> attribute to all keyboards that will determine the sysrq key for each
> keyboard.
I don't think class device is the right approach. Classes are supposed
to be a functional binding, ie, in this case, input devices. ADB is a
bus, and as such, you should create an adb bus type and and adb_device
that is an extension of struct device, not struct class device.
There's also the question of what to do on ADB resets (such as when
doing a sleep/wakeup cycle). Should we wipe out all devices and
re-created them, thus loosing any settings ? Or should we have some way
to attempt at re-matching existing ones ?
Cheers,
Ben.
> Signed-of-by: Aristeu Rozanski <[EMAIL PROTECTED]>
>
> --- linus-2.6.orig/drivers/macintosh/adb.c2007-05-11 10:09:13.0
> -0400
> +++ linus-2.6/drivers/macintosh/adb.c 2007-05-11 10:09:36.0 -0400
> @@ -102,11 +102,21 @@
> static void adbdev_init(void);
> static int try_handler_change(int, int);
>
> +static char *adb_device_id_string[] = {
> + [ADB_DONGLE] = "dongle",
> + [ADB_KEYBOARD] = "keyboard",
> + [ADB_MOUSE] = "mouse",
> + [ADB_TABLET] = "tablet",
> + [ADB_MODEM] = "modem",
> + [ADB_MISC] = "misc",
> +};
> +
> static struct adb_handler {
> void (*handler)(unsigned char *, int, int);
> int original_address;
> int handler_id;
> int busy;
> + char name[16];
> } adb_handler[16];
>
> /*
> @@ -508,6 +518,9 @@
> if ((adb_handler[i].original_address == default_id) &&
> (!handler_id || (handler_id == adb_handler[i].handler_id)
> ||
> try_handler_change(i, handler_id))) {
> + int rc;
> + struct class_device *cdev;
> +
> if (adb_handler[i].handler != 0) {
> printk(KERN_ERR
> "Two handlers for ADB device %d\n",
> @@ -517,7 +530,26 @@
> write_lock_irq(&adb_handler_lock);
> adb_handler[i].handler = handler;
> write_unlock_irq(&adb_handler_lock);
> - ids->id[ids->nids++] = i;
> +
> + snprintf(adb_handler[i].name,
> + sizeof(adb_handler[i].name), "%s%i",
> + adb_device_id_string[default_id], ids->nids);
> +
> + cdev = &ids->id[ids->nids].cdev;
> + cdev->class = adb_dev_class;
> + class_device_initialize(cdev);
> + snprintf(cdev->class_id, sizeof(cdev->class_id), "%s",
> + adb_handler[i].name);
> + rc = class_device_add(cdev);
> + if (rc) {
> + printk(KERN_WARNING "adb: unable to add class "
> +"device\n");
> + for (i = ids->nids - 1; i >= 0; i--)
> + class_device_del(&ids->id[i].cdev);
> + ids->nids = 0;
> + return 0;
> + }
> + ids->id[ids->nids++].id = i;
> }
> }
> up(&adb_handler_sem);
> @@ -525,9 +557,9 @@
> }
>
> int
> -adb_unregister(int index)
> +adb_unregister(int index, struct adb_ids *ids)
> {
> - int ret = -ENODEV;
> + int i, ret = -ENODEV;
>
> down(&adb_handler_sem);
> write_lock_irq(&adb_handler_lock);
> @@ -539,6 +571,8 @@
> }
> ret = 0;
> adb_handler[index].handler = NULL;
> + for (i = 0; i < ids->nids; i++)
> + class_device_del(&ids->id[i].cdev);
> }
> write_unlock_irq(&adb_handler_lock);
> up(&adb_handler_sem);
> --- linus-2.6.orig/include/linux/adb.h2007-05-11 10:09:13.0
> -0400
> +++ linus-2.6/include/linux/adb.h 2007-05-11 10:09:36.0 -0400
> @@ -3,6 +3,7 @@
> */
> #ifndef __ADB_H
> #define __ADB_H
> +#include
>
> /* ADB commands */
> #define ADB_BUSRESET 0
> @@ -57,7 +58,11 @@
>
> struct adb_ids {
> int nids;
> - unsigned char id[16];
> + struct adb_id {
> + unsigned char id;
> + struct class_device cdev;
> + void *priv;
> + } id[16];
> };
>
> /* Structure which encapsulates a low-level ADB driver */
> @@ -91,7 +96,7 @@
> int flags, int nbytes, ...);
> int adb_register(int default_id,int handler_id,struct adb_ids *ids,
>void (*handler)(unsigned char *, int, int));
> -int adb_unregister(int index);
> +int adb_unregister(int index, struct adb_ids *ids);
> void adb_
[PATCH] PHY fixed driver: rework release path and update phy_id notation
device_bind_driver() error code returning has been fixed.
release() function has been written, so that to free resources
in correct way; the release path is now clean.
Before the rework, it used to cause
Device '[EMAIL PROTECTED]:1' does not have a release() function, it is broken
and must be fixed.
BUG: at drivers/base/core.c:104 device_release()
Call Trace:
[] kobject_cleanup+0x53/0x7e
[] kobject_release+0x0/0x9
[] kref_put+0x74/0x81
[] fixed_mdio_register_device+0x230/0x265
[] fixed_init+0x1f/0x35
[] init+0x147/0x2fb
[] schedule_tail+0x36/0x92
[] child_rip+0xa/0x12
[] acpi_ds_init_one_object+0x0/0x83
[] init+0x0/0x2fb
[] child_rip+0x0/0x12
Also changed the notation of the fixed phy definition on
mdio bus to the form of + to make it able to be used by
gianfar and ucc_geth that define phy_id strictly as "%d:%d" and cleaned up
the whitespace issues.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/net/phy/Kconfig | 14 ++
drivers/net/phy/fixed.c | 310 ---
2 files changed, 169 insertions(+), 155 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index dd09011..432c210 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -76,4 +76,18 @@ config FIXED_MII_100_FDX
bool "Emulation for 100M Fdx fixed PHY behavior"
depends on FIXED_PHY
+config FIXED_MII_1000_FDX
+ bool "Emulation for 1000M Fdx fixed PHY behavior"
+ depends on FIXED_PHY
+
+config FIXED_MII_AMNT
+int "Number of emulated PHYs to allocate "
+depends on FIXED_PHY
+default "1"
+---help---
+Sometimes it is required to have several independent emulated
+PHYs on the bus (in case of multi-eth but phy-less HW for instance).
+This control will have specified number allocated for each fixed
+PHY type enabled.
+
endif # PHYLIB
diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
index bb96691..5619182 100644
--- a/drivers/net/phy/fixed.c
+++ b/drivers/net/phy/fixed.c
@@ -30,53 +30,31 @@
#include
#include
#include
+#include
#include
#include
#include
-#define MII_REGS_NUM 7
-
-/*
-The idea is to emulate normal phy behavior by responding with
-pre-defined values to mii BMCR read, so that read_status hook could
-take all the needed info.
-*/
-
-struct fixed_phy_status {
- u8 link;
- u16 speed;
- u8 duplex;
-};
-
-/*-
- * Private information hoder for mii_bus
-
*-*/
-struct fixed_info {
- u16 *regs;
- u8 regs_num;
- struct fixed_phy_status phy_status;
- struct phy_device *phydev; /* pointer to the container */
- /* link & speed cb */
- int(*link_update)(struct net_device*, struct fixed_phy_status*);
-
-};
+/* we need to track the allocated pointers in order to free them on exit */
+static struct fixed_info *fixed_phy_ptrs[CONFIG_FIXED_MII_AMNT*MAX_PHY_AMNT];
/*-
* If something weird is required to be done with link/speed,
* network driver is able to assign a function to implement this.
* May be useful for PHY's that need to be software-driven.
*-*/
-int fixed_mdio_set_link_update(struct phy_device* phydev,
- int(*link_update)(struct net_device*, struct fixed_phy_status*))
+int fixed_mdio_set_link_update(struct phy_device *phydev,
+ int (*link_update) (struct net_device *,
+ struct fixed_phy_status *))
{
struct fixed_info *fixed;
- if(link_update == NULL)
+ if (link_update == NULL)
return -EINVAL;
- if(phydev) {
- if(phydev->bus) {
+ if (phydev) {
+ if (phydev->bus) {
fixed = phydev->bus->priv;
fixed->link_update = link_update;
return 0;
@@ -84,54 +62,64 @@ int fixed_mdio_set_link_update(struct phy_device* phydev,
}
return -EINVAL;
}
+
EXPORT_SYMBOL(fixed_mdio_set_link_update);
+struct fixed_info *fixed_mdio_get_phydev (int phydev_ind)
+{
+ if (phydev_ind >= MAX_PHY_AMNT)
+ return NULL;
+ return fixed_phy_ptrs[phydev_ind];
+}
+
+EXPORT_SYMBOL(fixed_mdio_get_phydev);
+
/*-
* This is used for updating internal mii regs from the status
*-*/
-#if defined(CONFIG_FIXED_MII_100_FDX) || defined(CONFIG_FIXED_MII_10_FDX)
+#if defined(CONFIG_FIXED_MII_100
Re: [PATCH 0/3] 82xx: Add the support for Wind River SBC PowerQUICCII
On Mon, 16 Jul 2007 17:01:28 +0800 Mark Zhan wrote: > These 3 patches add the powerpc support of Wind River SBC > PowerQUICCII. > I am sorry, but this would intercept with big 8xx/82xx series from Scott Wood I am reviewing now. it makes the initial merged code more maintainable and powerpc-friendly, but would have some rework required in upcoming patches for new BSPs. OTOH, it would make all the changes below very short and apparent. Of course, if something would block those series this one can be considered to merge. > 1) Currently, some mpc82xx platform hooks in mpc82xx_ads.c are > actually not specific to ads board. So the 1st patch makes them be > shared by different 82xx boards. > > 2) The 2nd patch make 'cpm_uart_of_init' be able to parse SMC uart in > DTS > > 3) The 3rd patch is the platform codes, defconfig and dts for Wind > River SBC PowerQUICCII 82xx board. > > Any comment is welcome. > > Thanks > Mark Zhan > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: Added RTC support for mpc8313RDB and utilize "clock-frequency"
This enables DS1337 embedded RTC and uses "clock-frequency"
property to configure loops_per_jiffy. Fixed spaces vs tabs issue
in couple of places.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 52 -
1 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 3edfe17..b410e67 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -14,6 +14,8 @@
*/
#include
+#include
+#include
#include
#include
@@ -42,6 +44,17 @@ static void __init mpc8313_rdb_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc8313_rdb_setup_arch()", 0);
+ np = of_find_node_by_type(NULL, "cpu");
+ if (np != 0) {
+ const unsigned int *fp =
+ get_property(np, "clock-frequency", NULL);
+ if (fp != 0)
+ loops_per_jiffy = *fp / HZ;
+ else
+ loops_per_jiffy = 5000 / HZ;
+ of_node_put(np);
+ }
+
#ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
mpc83xx_add_bridge(np);
@@ -67,14 +80,49 @@ void __init mpc8313_rdb_init_IRQ(void)
ipic_set_default_priority();
}
+#if defined (CONFIG_SENSORS_DS1337) && defined (CONFIG_I2C)
+
+extern int ds1337_do_command(int id, int cmd, void *arg);
+extern spinlock_t rtc_lock;
+#define DS1337_GET_DATE0
+#define DS1337_SET_DATE1
+
+static void mpc8313rdb_get_rtc_time(struct rtc_time *tm)
+{
+ int result;
+
+ result = ds1337_do_command(0, DS1337_GET_DATE, tm);
+
+ if (result == 0)
+ result = mktime(tm->tm_year, tm->tm_mon, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec);
+}
+
+static int mpc8313rdb_set_rtc_time(struct rtc_time *tm)
+{
+ int result;
+
+ result = ds1337_do_command(0, DS1337_SET_DATE, tm);
+
+ return result;
+}
+
+static int __init rtc_hookup(void)
+{
+ ppc_md.get_rtc_time = mpc8313rdb_get_rtc_time;
+ ppc_md.set_rtc_time = mpc8313rdb_set_rtc_time;
+ return 0;
+}
+late_initcall(rtc_hookup);
+#endif
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
static int __init mpc8313_rdb_probe(void)
{
-unsigned long root = of_get_flat_dt_root();
+ unsigned long root = of_get_flat_dt_root();
-return of_flat_dt_is_compatible(root, "MPC8313ERDB");
+ return of_flat_dt_is_compatible(root, "MPC8313ERDB");
}
define_machine(mpc8313_rdb) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC: add support of the GiGE switch for mpc8313RDB via fixed PHY
This utilises pretend phy, making access to it via device tree. GiGE switch
is connected to TSEC1 with fixed gigE link, so we need to emulate it
via artificial PHY to make it work.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8313erdb.dts |1 +
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 43 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index a1533cc..1b351dc 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -100,6 +100,7 @@
#size-cells = <0>;
phy1: [EMAIL PROTECTED] {
interrupt-parent = < &ipic >;
+ compatible = "fixed";
interrupts = <13 8>;
reg = <1>;
device_type = "ethernet-phy";
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index b410e67..5ee08fc 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -115,6 +115,49 @@ static int __init rtc_hookup(void)
late_initcall(rtc_hookup);
#endif
+#if defined(CONFIG_FIXED_MII_1000_FDX)
+
+static int fixed_set_link (void)
+{
+ struct fixed_info *phyinfo = fixed_mdio_get_phydev(0); /* only one
fixed phy on this platform */
+ struct phy_device *phydev;
+ struct device_node *np;
+ struct device_node *child;
+ unsigned int i;
+ struct resource res;
+ int ret;
+ u32 *id = NULL;
+
+ if (!phyinfo)
+ return -ENXIO;
+ phydev = phyinfo->phydev;
+ if (!phydev)
+ return -ENXIO;
+ for (np = NULL, i = 0;
+(np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL;
+i++) {
+
+ memset(&res, 0, sizeof(res));
+
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret)
+ return ret;
+ child = of_find_compatible_node(np, "ethernet-phy","fixed");
+ if (!child)
+ return -ENXIO;
+ id = (u32*)of_get_property(child, "reg", NULL);
+ if (!id)
+ return -ENXIO;
+ break;
+ }
+ snprintf(phydev->dev.bus_id, BUS_ID_SIZE, PHY_ID_FMT, res.start, *id);
+ memset(phyinfo->regs,0xff,sizeof(phyinfo->regs[0])*phyinfo->regs_num);
+
+ return 0;
+}
+late_initcall(fixed_set_link);
+#endif
+
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] USB_DR host support for FSL MPC831x
Modifies fsl_ehci code so that to get USB host working on
mpc831x platform. Verified with MPC8313RDB reference board.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8313erdb.dts |1 +
drivers/usb/host/ehci-fsl.c |4 +++-
drivers/usb/host/ehci-hcd.c |2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 1b351dc..c330e79 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -90,6 +90,7 @@
interrupt-parent = < &ipic >;
interrupts = <26 8>;
phy_type = "utmi_wide";
+ control_init = <0280>; // UTMI ext 48 MHz clk
};
[EMAIL PROTECTED] {
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index c7a7c59..3e3187b 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -185,12 +185,14 @@ static void mpc83xx_usb_setup(struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct fsl_usb2_platform_data *pdata;
void __iomem *non_ehci = hcd->regs;
+ u32 temp;
pdata =
(struct fsl_usb2_platform_data *)hcd->self.controller->
platform_data;
/* Enable PHY interface in the control reg. */
- out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x0004);
+ temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
+ out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x0004);
out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x001b);
#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 099aff6..994a127 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -925,7 +925,7 @@ MODULE_LICENSE ("GPL");
#definePCI_DRIVER ehci_pci_driver
#endif
-#ifdef CONFIG_MPC834x
+#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
#include "ehci-fsl.c"
#definePLATFORM_DRIVER ehci_fsl_driver
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] USB_DR device support for FSL MPC831x
This adds support for USB device mode on mpc831x series.
Devicetree node modification is required to make it work -
dr_mode ="peripheral";
which should be commented out if host mode is desired onboot.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |1 +
include/linux/fsl_devices.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index c0ddc80..27a1510 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -514,6 +514,7 @@ static int __init fsl_usb_of_init(void)
}
} else if (prop && !strcmp(prop, "peripheral")) {
usb_data.operating_mode = FSL_USB2_DR_DEVICE;
+ usb_data.max_ep_nr = *(unsigned
int*)of_get_property(np, "max_ep_nr",NULL);
usb_dev_dr_client = platform_device_register_simple(
"fsl-usb2-udc", i, r, 2);
if (IS_ERR(usb_dev_dr_client)) {
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 12e631f..a3feb34 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -103,6 +103,7 @@ struct fsl_usb2_platform_data {
enum fsl_usb2_operating_modes operating_mode;
enum fsl_usb2_phy_modes phy_mode;
unsigned intport_enables;
+ unsigned intmax_ep_nr;
};
/* Flags in fsl_usb2_mph_platform_data */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] 82xx: some 82xx platform hook functions can be shared by different boards
On Monday 16 July 2007, Mark Zhan wrote:
> @@ -96,7 +94,7 @@
> pvid = mfspr(SPRN_PVR);
> svid = mfspr(SPRN_SVR);
>
> - seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
> + seq_printf(m, "Vendor\t\t: %s\n", CPUINFO_VENDOR);
> seq_printf(m, "Machine\t\t: %s\n", CPUINFO_MACHINE);
> seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> seq_printf(m, "SVR\t\t: 0x%x\n", svid);
This is a step in the wrong direction. CPUINFO_{VENDOR,MACHINE}
comes from a platform specific header file, so you can not
use these definitions in platform independent code without
breaking multiplatform kernels.
One possible solution would be a platform specific show_cpuinfo()
function that calls a generic 82xx version and passes in the
two values. Even better would be to just dump whatever string
you find in the /model property in the device tree.
> +
> +#define RMR_CSRE 0x0001
> +
> +void mpc82xx_restart(char *cmd)
> +{
> + __volatile__ unsigned char dummy;
> +
> + local_irq_disable();
> + ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
> +
> + /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
> + mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
> + dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
> + printk("Restart failed\n");
> + while (1) ;
> +}
I know you're just moving that code, but it looks horribly wrong
nonetheless. cpm2_immr is an __iomem variable, so you must not
dereference it but instead should use the in_8() macro to
access it.
Once you get that right, you don't need the volatile variable
any more.
> +void mpc82xx_halt(void)
> +{
> + local_irq_disable();
> + while (1) ;
> +}
Here, as in the function above, there should at least be a cpu_relax()
in the final loop. If the CPU has a nap functionality or something
similar, that would be even better.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
On Monday 16 July 2007, Mark Zhan wrote:
> - cpm_uart_data.uart_clk = ppc_proc_freq;
> + if (strstr(model, "SMC")) {
> + cpm_uart_dev =
> platform_device_register_simple("fsl-cpm-smc:uart",
> + i, &r[0], 3);
> + } else if (strstr(model, "SCC")) {
> + cpm_uart_dev =
> platform_device_register_simple("fsl-cpm-scc:uart",
> + i, &r[0], 3);
> + }
>
You should probably use of_device_is_compatible() to check
if a given device can be used by a particular driver.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] POWERPC 8xx: bump up initial memory limit for 8xx
From: John Traill <[EMAIL PROTECTED]> The 8xx can only support a max of 8M during early boot ( it seems a lot of 8xx boards only have 8M so the bug was never triggered ). The following change makes it able to run with 128M. Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> --- arch/powerpc/mm/init_32.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index e1f5ded..7cee86d 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -133,6 +133,9 @@ void __init MMU_init(void) /* 601 can only access 16MB at the moment */ if (PVR_VER(mfspr(SPRN_PVR)) == 1) __initial_memory_limit = 0x0100; + /* 852 can only access 8MB at the moment */ + if (PVR_VER(mfspr(SPRN_PVR)) == 0x50) + __initial_memory_limit = 0x0080; /* parse args from command line */ MMU_setup(); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2.6.22-rc7 0/4] phy/gianfar: Fixes for gianfar and vitesse RGMII-ID support
A few bugs in the Vitesse PHY driver were found on the 8641D HPCN board. Originally, they were masked by a bug in the PHY Lib which was fixed by patch 5f708dd91d15876e26d7a57f97a255cedffca463 (Fix phy_id for Vitesse 824x PHY). That patch allowed the Vitesse PHY to bind on the 8641D HPCN board, thereby exposing a bug in the interrupt handling and a bug in the configuration of the PHY. This sequence of patches fixes the irq handling bug, then fixes the configuration bug in 3 places: 1) The Vitesse PHY driver 2) The gianfar driver (needs to pass in the mode correctly for internal delay) 3) The OF device tree for arch/powerpc boards You can apply the following patches, or pull them directly: The following changes since commit c5e3ae8823693b260ce1f217adca8add1bc0b3de: Ayaz Abdulla (1): forcedeth bug fix: realtek phy are found in the git repository at: http://opensource.freescale.com/pub/scm/linux-2.6-85xx.git netdev Andy Fleming (4): Fix Vitesse 824x PHY interrupt acking Add phy-connection-type to gianfar nodes Fix Vitesse RGMII-ID support Fix RGMII-ID handling in gianfar Documentation/powerpc/booting-without-of.txt |6 +++ arch/powerpc/boot/dts/mpc8641_hpcn.dts |4 ++ arch/powerpc/sysdev/fsl_soc.c|9 + drivers/net/gianfar.c| 12 ++- drivers/net/phy/vitesse.c| 46 +++--- include/linux/fsl_devices.h |1 + 6 files changed, 72 insertions(+), 6 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] gianfar: Fix RGMII-ID handling in gianfar
The TSEC/eTSEC can detect the interface to the PHY automatically,
but it isn't able to detect whether the RGMII connection needs internal
delay. So we need to detect that change in the device tree, propagate
it to the platform data, and then check it if we're in RGMII. This fixes
a bug on the 8641D HPCN board where the Vitesse PHY doesn't use the delay
for RGMII.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |9 +
drivers/net/gianfar.c | 12 +++-
include/linux/fsl_devices.h |1 +
3 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index cad1757..64efee6 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -197,6 +197,7 @@ static int __init gfar_of_init(void)
struct gianfar_platform_data gfar_data;
const unsigned int *id;
const char *model;
+ const char *ctype;
const void *mac_addr;
const phandle *ph;
int n_res = 2;
@@ -254,6 +255,14 @@ static int __init gfar_of_init(void)
FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
+ ctype = of_get_property(np, "phy-connection-type", NULL);
+
+ /* We only care about rgmii-id. The rest are autodetected */
+ if (ctype && !strcmp(ctype, "rgmii-id"))
+ gfar_data.interface = PHY_INTERFACE_MODE_RGMII_ID;
+ else
+ gfar_data.interface = PHY_INTERFACE_MODE_MII;
+
ph = of_get_property(np, "phy-handle", NULL);
phy = of_find_node_by_phandle(*ph);
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index d7a1a58..f926905 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -420,8 +420,18 @@ static phy_interface_t gfar_get_interface(struct
net_device *dev)
if (ecntrl & ECNTRL_REDUCED_MODE) {
if (ecntrl & ECNTRL_REDUCED_MII_MODE)
return PHY_INTERFACE_MODE_RMII;
- else
+ else {
+ phy_interface_t interface = priv->einfo->interface;
+
+ /*
+* This isn't autodetected right now, so it must
+* be set by the device tree or platform code.
+*/
+ if (interface == PHY_INTERFACE_MODE_RGMII_ID)
+ return PHY_INTERFACE_MODE_RGMII_ID;
+
return PHY_INTERFACE_MODE_RGMII;
+ }
}
if (priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT)
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 73710d6..2de358f 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -53,6 +53,7 @@ struct gianfar_platform_data {
u32 bus_id;
u32 phy_id;
u8 mac_addr[6];
+ phy_interface_t interface;
};
struct gianfar_mdio_data {
--
1.5.0.2.230.gfbe3d-dirty
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] phy: Fix Vitesse 824x PHY interrupt acking
The Vitesse 824x PHY doesn't allow an interrupt to be cleared if
the mask bit for that interrupt isn't set. This means that the PHY
Lib's order of handling interrupts (disable, then clear) breaks on this
PHY. However, clearing then disabling the interrupt opens up the code
for a silly race condition. So rather than change the PHY Lib, we change
the Vitesse driver so it always clears interrupts before disabling them.
Further, the ack function only clears the interrupt if interrupts are
enabled.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
Signed-off-by: York Sun <[EMAIL PROTECTED]>
Acked-by: Haiying Wang <[EMAIL PROTECTED]>
---
drivers/net/phy/vitesse.c | 23 +--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 596222b..f39ab76 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -65,7 +65,15 @@ static int vsc824x_config_init(struct phy_device *phydev)
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
- int err = phy_read(phydev, MII_VSC8244_ISTAT);
+ int err = 0;
+
+ /*
+* Don't bother to ACK the interrupts if interrupts
+* are disabled. The 824x cannot clear the interrupts
+* if they are disabled.
+*/
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ err = phy_read(phydev, MII_VSC8244_ISTAT);
return (err < 0) ? err : 0;
}
@@ -77,8 +85,19 @@ static int vsc824x_config_intr(struct phy_device *phydev)
if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
err = phy_write(phydev, MII_VSC8244_IMASK,
MII_VSC8244_IMASK_MASK);
- else
+ else {
+ /*
+* The Vitesse PHY cannot clear the interrupt
+* once it has disabled them, so we clear them first
+*/
+ err = phy_read(phydev, MII_VSC8244_ISTAT);
+
+ if (err)
+ return err;
+
err = phy_write(phydev, MII_VSC8244_IMASK, 0);
+ }
+
return err;
}
--
1.5.0.2.230.gfbe3d-dirty
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
