Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
On Mon, 26 Nov 2007 15:41:19 -0600 Scott Wood wrote: > Vitaly Bordug wrote: > > perhaps I was not clear enough. That was a rough idea how to handle > > the whole thing, not just cpm_cr_cmd. This cpm command is a corner > > case, but there can be other actions that may confuse CPM being > > triggered simultaneously or overlapping. > > What kind of actions did you have in mind? Microcode patching? > microcode is another case to handle gracefully. There are also "soft" cases like cpmux mess-up, incompatible SoC devices (which we are handling by logical exclude now but which do have natural reasons of "not leaving together" like shared dedicated GPIO or smth else) etc. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/9] ps3: Use symbolic names for video modes
On Tue, 27 Nov 2007, Stephen Rothwell wrote:
> On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]>
> wrote:
> > @@ -594,20 +594,21 @@ static const struct {
> > unsigned mask : 19;
> > unsigned id : 4;
> > } ps3av_preferred_modes[] = {
> > - { .mask = PS3AV_RESBIT_WUXGA<< SHIFT_VESA, .id = 13 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60,.id = 5 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50,.id = 10 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60,.id = 4 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50,.id = 9 },
> > - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> > - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> > - { .mask = PS3AV_RESBIT_1280x720P<< SHIFT_60,.id = 3 },
> > - { .mask = PS3AV_RESBIT_1280x720P<< SHIFT_50,.id = 8 },
> > - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60,.id = 2 },
> > - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50,.id = 7 },
> > + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> > + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA},
> > + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA},
> > + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> > + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P},
> > + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P},
>
> Why did you remove the C99 style initialisers?
Because else things no longer fit on one line.
I prefered a clean structural overview over the protection against the
(almost nonexisting) risk of initializing the wrong member.
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: time accounting problem (powerpc only?)
Johannes Berg writes: > Contrary to what I claimed later in the thread, my 64-bit powerpc box > (quad-core G5) doesn't suffer from this problem. > > Does anybody have any idea? I don't even know how to debug it further. I see it on my G4 powerbook. However, a compute-bound task runs just as fast (i.e. completes in the same elapsed time) as on older kernels, so it does look like it is just an accounting problem. If the CPU was really spending more than half its time servicing hardware interrupts, the task should take more than twice as long to complete. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] the scheduled I2C RTC driver removal
On Fri, 2 Nov 2007 23:12:43 +0100, Jean Delvare wrote: > Hi Adrian, > > On Thu, 1 Nov 2007 00:03:58 +0100, Adrian Bunk wrote: > > This patch contains the scheduled removal of legacy I2C RTC drivers with > > replacement drivers. > > (...) > > Documentation/feature-removal-schedule.txt |7 > > arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 - > > arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 - > > arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 - > > arch/ppc/platforms/83xx/mpc834x_sys.c | 20 - > > arch/ppc/platforms/85xx/tqm85xx.c | 21 - > > arch/ppc/platforms/katana.c| 21 - > > drivers/i2c/chips/Kconfig | 38 - > > drivers/i2c/chips/Makefile |3 > > drivers/i2c/chips/ds1337.c | 410 > > drivers/i2c/chips/ds1374.c | 267 - > > drivers/i2c/chips/m41t00.c | 413 - > > include/linux/m41t00.h | 50 -- > > 13 files changed, 1322 deletions(-) > > Obviously we're not yet ready to remove the drivers, as some platforms > still use them! The remaining platforms need to be updated to use the > new RTC drivers first. The mapping is as follows: > > chip | old driver | new driver | > ---++--+ > DS1337 | ds1337 | rtc-ds1307 | > DS1339 | ds1337 | rtc-ds1307 | > DS1374 | ds1374 | rtc-ds1374 | > M41T00 | m41t00 | rtc-ds1307 | > M41T81 | m41t00 | rtc-m41t80 | > M41ST85| m41t00 | rtc-m41t80 | > > So, PPC people, please update your platform code to make use of the new > drivers now, and let me know when you're done. As soon as all platforms > are converted, I'll apply Adrian's patch. As of 2.6.24-rc3-git2, I see that the references to the obsolete drivers have been removed from arch/powerpc/*. Great, I'll update Adrian's patch. This leaves only 3 platforms under arch/ppc (83xx, 85xx and katana) that still need updating. Kumar, Paul, what's the status? Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 I2C and 2.6 kernel
Hi, I'm using a TQM5200S (MPC5200B CPU) module on the STK52xx starter kit. For some reasons I have to use the 2.6 kernel (the latest 2.6.23.1 from the DENX git archive) with ARCH=powerpc and most of my external hardware is running fine with this. On the starter kit there is an external I2C RTC (M41T00) and I like to use it now. In the 2.4 kernel there were some options regarding MPC5200 I2C, but I could not find them in the 2.6 kernel. There were options for MPCxxx I2C Algorithm or MPC5xxx TQM5200 I2C Adapter, for example. Regardless what I'm doing in the 2.6 kernel configuration I can't get this RTC running (I activated RTC support and the driver for the M41T00 in the configuration). hwclock --debug tells me: hwclock: Open of /dev/rtc failed, errno=19: No such device. No usable clock interface found. So the questions is: Is the I2C support for the MPC5200 in the 2.6.23 kernel in an usable state? Or do I need some special patches from TQ for this board to get it running? Thanks in advance and bye, -- Dipl. Ing. Oliver Rutsch EMail: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote: > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that > > not connected to the real MDIO bus. > > > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > > > --- > > > > Documentation/powerpc/booting-without-of.txt |3 + > > arch/powerpc/sysdev/fsl_soc.c| 56 > > ++ > > 2 files changed, 42 insertions(+), 17 deletions(-) > > > > > > diff --git a/Documentation/powerpc/booting-without-of.txt > > b/Documentation/powerpc/booting-without-of.txt > > index e9a3cb1..cf25070 100644 > > --- a/Documentation/powerpc/booting-without-of.txt > > +++ b/Documentation/powerpc/booting-without-of.txt > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the > > flattened-device-tree model. > >services interrupts for this device. > > - phy-handle : The phandle for the PHY connected to this ethernet > >controller. > > +- fixed-link : where a is emulated phy id - choose any, > > + but unique to the all specified fixed-links, b is duplex - 0 half, > > + 1 full, c is link speed - d#10/d#100/d#1000. > > Good work! > May I suggest adding a "d" to where d is flow control - 0 no, 1 yes Well, I see no reference of the "flow" neither in the include/linux/mii.h nor in the drivers/net/phy/*. :-/ Thus today there is no such register bit we can emulate?.. > flow control or not just popped up here today so I got a use for it. ..and I looked into few drivers (gianfar, ucc), and they seem to use hard-coded flow control values, thus they don't speak to the PHYs about that. Can you give any reference to the driver that needs that parameter? Does it use PHY subsystem to obtain flow-control on/off information? Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc3: High CPU load -- hardware interrupts
Hi Elimar, Elimar Riesebieter schrieb am Mon 26. Nov, 23:38 (+0100): > I can confirm this situation. But it seems, that no one takes care > of it Have a look at the thread “time accounting problem (powerpc only?)” started by Johannes Berg on 23 Nov 2007. Bye, Jörg. -- Du kannst einem Schwein einen goldenen Ring durch die Nase ziehen, deswegen bleibt es trozdem ein Schwein! pgpc03ARrnw3H.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: time accounting problem (powerpc only?)
> On my powerbook, with NO_HZ and HIGH_RES_TIMERS, I observed recently > that powernowd would not ever switch between CPU speeds. Also happens without NO_HZ (with HIGH_RES_TIMERS). johannes 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: time accounting problem (powerpc only?)
On Tue, 2007-11-27 at 20:57 +1100, Paul Mackerras wrote: > Johannes Berg writes: > > > Contrary to what I claimed later in the thread, my 64-bit powerpc box > > (quad-core G5) doesn't suffer from this problem. > > > > Does anybody have any idea? I don't even know how to debug it further. > > I see it on my G4 powerbook. However, a compute-bound task runs just > as fast (i.e. completes in the same elapsed time) as on older kernels, > so it does look like it is just an accounting problem. If the CPU was > really spending more than half its time servicing hardware interrupts, > the task should take more than twice as long to complete. Exactly. So where do I look for the accounting bug? johannes 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/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote: > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote: > > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: > > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that > > > not connected to the real MDIO bus. > > > > > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > > > > > --- > > > > > > Documentation/powerpc/booting-without-of.txt |3 + > > > arch/powerpc/sysdev/fsl_soc.c| 56 > > > ++ > > > 2 files changed, 42 insertions(+), 17 deletions(-) > > > > > > > > > diff --git a/Documentation/powerpc/booting-without-of.txt > > > b/Documentation/powerpc/booting-without-of.txt > > > index e9a3cb1..cf25070 100644 > > > --- a/Documentation/powerpc/booting-without-of.txt > > > +++ b/Documentation/powerpc/booting-without-of.txt > > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the > > > flattened-device-tree model. > > >services interrupts for this device. > > > - phy-handle : The phandle for the PHY connected to this ethernet > > >controller. > > > +- fixed-link : where a is emulated phy id - choose any, > > > + but unique to the all specified fixed-links, b is duplex - 0 half, > > > + 1 full, c is link speed - d#10/d#100/d#1000. > > > > Good work! > > May I suggest adding a "d" to where d is flow control - 0 no, 1 yes > > Well, I see no reference of the "flow" neither in the include/linux/mii.h > nor in the drivers/net/phy/*. :-/ Thus today there is no such register > bit we can emulate?.. Well, as good as I can recall, flow control(pause) is something that the PHY negotiates, just like FDX/HDX and should be dealt with in the adjust_link callback but not many do currently. If you seach for pause in phy_device.c you will find it. > > > flow control or not just popped up here today so I got a use for it. > > ..and I looked into few drivers (gianfar, ucc), and they seem to use > hard-coded flow control values, thus they don't speak to the PHYs > about that. Yes, but they should. > > Can you give any reference to the driver that needs that parameter? > Does it use PHY subsystem to obtain flow-control on/off information? > > Thanks, > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: time accounting problem (powerpc only?)
On Tue, 2007-11-27 at 16:00 +1100, Tony Breeds wrote: > On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote: > > Contrary to what I claimed later in the thread, my 64-bit powerpc box > > (quad-core G5) doesn't suffer from this problem. > > > > Does anybody have any idea? I don't even know how to debug it further. > > I'll see if I can grab an appropriate machine tomorrow and have a look at > it. I think it's just an accounting bug, which is probably my fault :) Thanks. Let me know if you need any info. johannes 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/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
On Tue, Nov 27, 2007 at 02:17:11PM +0100, Joakim Tjernlund wrote: > > On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote: > > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote: > > > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: > > > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that > > > > not connected to the real MDIO bus. > > > > > > > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > > > > > > > --- > > > > > > > > Documentation/powerpc/booting-without-of.txt |3 + > > > > arch/powerpc/sysdev/fsl_soc.c| 56 > > > > ++ > > > > 2 files changed, 42 insertions(+), 17 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/powerpc/booting-without-of.txt > > > > b/Documentation/powerpc/booting-without-of.txt > > > > index e9a3cb1..cf25070 100644 > > > > --- a/Documentation/powerpc/booting-without-of.txt > > > > +++ b/Documentation/powerpc/booting-without-of.txt > > > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the > > > > flattened-device-tree model. > > > >services interrupts for this device. > > > > - phy-handle : The phandle for the PHY connected to this ethernet > > > >controller. > > > > +- fixed-link : where a is emulated phy id - choose any, > > > > + but unique to the all specified fixed-links, b is duplex - 0 > > > > half, > > > > + 1 full, c is link speed - d#10/d#100/d#1000. > > > > > > Good work! > > > May I suggest adding a "d" to where d is flow control - 0 no, 1 > > > yes > > > > Well, I see no reference of the "flow" neither in the include/linux/mii.h > > nor in the drivers/net/phy/*. :-/ Thus today there is no such register > > bit we can emulate?.. > > Well, as good as I can recall, flow control(pause) is something that the > PHY negotiates, just like FDX/HDX and should be dealt with in the > adjust_link callback but not many do currently. > > If you seach for pause in phy_device.c you will find it. Ah, pause. Sure, we can emulate that. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
On Tue, 2007-11-27 at 16:59 +0300, Anton Vorontsov wrote: > On Tue, Nov 27, 2007 at 02:17:11PM +0100, Joakim Tjernlund wrote: > > > > On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote: > > > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote: > > > > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote: > > > > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that > > > > > not connected to the real MDIO bus. > > > > > > > > > > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]> > > > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > > > > > > > > > --- > > > > > > > > > > Documentation/powerpc/booting-without-of.txt |3 + > > > > > arch/powerpc/sysdev/fsl_soc.c| 56 > > > > > ++ > > > > > 2 files changed, 42 insertions(+), 17 deletions(-) > > > > > > > > > > > > > > > diff --git a/Documentation/powerpc/booting-without-of.txt > > > > > b/Documentation/powerpc/booting-without-of.txt > > > > > index e9a3cb1..cf25070 100644 > > > > > --- a/Documentation/powerpc/booting-without-of.txt > > > > > +++ b/Documentation/powerpc/booting-without-of.txt > > > > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the > > > > > flattened-device-tree model. > > > > >services interrupts for this device. > > > > > - phy-handle : The phandle for the PHY connected to this ethernet > > > > >controller. > > > > > +- fixed-link : where a is emulated phy id - choose any, > > > > > + but unique to the all specified fixed-links, b is duplex - 0 > > > > > half, > > > > > + 1 full, c is link speed - d#10/d#100/d#1000. > > > > > > > > Good work! > > > > May I suggest adding a "d" to where d is flow control - 0 no, 1 > > > > yes > > > > > > Well, I see no reference of the "flow" neither in the include/linux/mii.h > > > nor in the drivers/net/phy/*. :-/ Thus today there is no such register > > > bit we can emulate?.. > > > > Well, as good as I can recall, flow control(pause) is something that the > > PHY negotiates, just like FDX/HDX and should be dealt with in the > > adjust_link callback but not many do currently. > > > > If you seach for pause in phy_device.c you will find it. > > Ah, pause. Sure, we can emulate that. Good, looking into phy_device there seems to be 2 pauses: ADVERTISED_Pause and ADVERTISE_PAUSE_ASYM which maps to phydev->pause and phydev->asym_pause so "d" should reflect that or a "e" should be added for the asym pause. Jocke Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections
Hi Paul, I'm just wondering what are your latest thoughts about this patch (http://patchwork.ozlabs.org/linuxppc/patch?id=14707). Cheers, Emil. > -Original Message- > From: Medve Emilian > Sent: Tuesday, November 13, 2007 10:24 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; > [EMAIL PROTECTED] > Cc: Medve Emilian > Subject: [PATCH v2] [POWERPC] Optimize counting distinct > entries in the relocation sections > > When a module has relocation sections with tens of thousands > worth of entries, > counting the distinct/unique entries only (i.e. no > duplicates) at load time can > take tens of seconds and up to minutes. The sore point is the > count_relocs() > function which is called as part of the architecture specific > module loading > processing path: > > -> load_module()generic > -> module_frob_arch_sections() arch specific > -> get_plt_size() 32-bit > -> get_stubs_size() 64-bit >-> count_relocs() > > (Not sure why the relocation tables could contain lots of > duplicates and why > they are not trimmed at compile time by the linker. In some > test cases, out of > 35K relocation entries only 1.5K were distinct/unique) > > The previous counting algorithm was having O(n^2) complexity. > Basically two > solutions were proposed on the e-mail list: a hash based > approach and a sort > based approach > > The hash based approach is the fastest (O(n)) but the has it > needs additional > memory and for certain corner cases it could take lots of > memory due to the > degeneration of the hash. One such proposal was submitted here: > > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html > > In this proposal, the symbol + addendum are hashed to > generate a key and a > pointer to the relocation entry will be stored in it. The > hash is implemented as > a linked list of memory pages with PAGE_SIZE / > sizeof(Elfxx_Rela *) entries. In > case of collisions in all the existing pages, a new page is > added to the list to > accommodate the new distinct relocation entry > > For 32-bit PowerPCs with 4K pages, a page can accommodate 1K > worth of pointers > to relocation entries. In the 35K entries scenario, as > much/little of six (6) > pages could be allocated using 24K of extra memory during the > module load > > The sort based approach is slower (O(n * log n + n)) but if > the sorting is done > "in place" it doesn't need additional memory. A proposal was > submitted here: > > http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045854.html > (http://patchwork.ozlabs.org/linuxppc/patch?filter=default&id=14573) > > In this proposal an array of pointers to the relocation > entries is built and > then is sorted using the kernel sort() utility function. This > is basically a heap > sort algorithm with a stable O(n * log n) complexity. With > this counting the > distinct/unique entries is just linear (O(n)) complexity. The > problem is the > extra memory needed in this proposal, which in the 35K > relocation entries test > case it can be as much as 140K (for 32-bit PowerPCs; double > for 64-bit). This is > much more then the memory needed by the hash based approach described > above/earlier but it doesn't hide potential degenerative corner cases > > The current patch is a happy compromise between the two > proposals above: > O(n + n * log n) performance with no additional memory > requirements due to > sorting in place the relocation table itself > > Signed-off-by: Emil Medve <[EMAIL PROTECTED]> > --- > > This patch only tries to address counting the distinct > R_PPC_REL24 entries for > the purpose of sizing the PLT. This operation was/can be > detected by the proper > kernel logic as a soft lockup for large relocation tables > > A related optimization (that could cause rewriting the this > patch) is to > optimize the PLT search from do_plt_call() but that doesn't > seem to be a > problem right now > > The errors below are false positives due to the fact that > Elfxx_Rela are > falsely assumed to be variables/operands instead of types: > > linux-2.6> scripts/checkpatch.pl > 0001-POWERPC-Optimize-counting-distinct-entries-in-the.patch > ERROR: need consistent spacing around '*' (ctx:WxV) > #116: FILE: arch/powerpc/kernel/module_32.c:78: > + const Elf32_Rela *x, *y; > ^ > > ERROR: need consistent spacing around '*' (ctx:WxV) > #228: FILE: arch/powerpc/kernel/module_64.c:122: > + const Elf64_Rela *x, *y; > ^ > > total: 2 errors, 0 warnings, 218 lines checked > Your patch has style problems, please review. If any of these errors > are false positives report them to the maintainer, see > CHECKPATCH in MAINTAINERS. > > arch/powerpc/kernel/module_32.c | 77 > ++
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Wed, 21 Nov 2007, Geert Uytterhoeven wrote:
> On Tue, 20 Nov 2007, Kumar Gala wrote:
> > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
> > >> isel (Integer Select) is a new user space instruction in the
> > >> PowerISA 2.04 spec. Not all processors implement it so lets emulate
> > >> to ensure code built with isel will run everywhere.
> > >
> > > Given that the instruction is meant to be a performance enhancement,
> > > we should probably warn the first few times it's emulated, so the user
> > > knows they should change their toolchain setup if possible.
> >
> > The same is true of mcrxr, popcntb, and possibly string ld/st.
> >
> > Feel free to submit a patch that warns about their usage.
>
> Something like this?
New version below.
Do we want it in sysfs? Or should we use debugfs instead?
Subject: powerpc: Keep track of emulated instructions
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
powerpc: Keep track of emulated instructions
Counters for the various classes of emulated instructions are available under
/sys/devices/system/cpu/cpu*/emulated/.
Optionally, rate-limited warnings can be printed to the console when
instructions are emulated.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig.debug | 10 ++
arch/powerpc/kernel/align.c| 17 --
arch/powerpc/kernel/sysfs.c| 64 -
arch/powerpc/kernel/traps.c| 17 +-
include/asm-powerpc/emulator.h | 60 ++
5 files changed, 161 insertions(+), 7 deletions(-)
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -284,4 +284,14 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config DEBUG_WARN_EMULATED
+ bool "Warn if emulated instructions are used"
+ depends on DEBUG_KERNEL && SYSFS
+ help
+ This option will cause messages to be printed if an instruction is
+ emulated.
+ Counters for emulated instruction usages are always available under
+ /sys/devices/system/cpu/cpu*/emulated/, irrespective of the state
+ of this option.
+
endmenu
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
struct aligninfo {
unsigned char len;
@@ -696,8 +697,10 @@ int fix_alignment(struct pt_regs *regs)
areg = dsisr & 0x1f;/* register to update */
#ifdef CONFIG_SPE
- if ((instr >> 26) == 0x4)
+ if ((instr >> 26) == 0x4) {
+ WARN_EMULATE(spe);
return emulate_spe(regs, reg, instr);
+ }
#endif
instr = (dsisr >> 10) & 0x7f;
@@ -731,17 +734,21 @@ int fix_alignment(struct pt_regs *regs)
/* A size of 0 indicates an instruction we don't support, with
* the exception of DCBZ which is handled as a special case here
*/
- if (instr == DCBZ)
+ if (instr == DCBZ) {
+ WARN_EMULATE(dcbz);
return emulate_dcbz(regs, addr);
+ }
if (unlikely(nb == 0))
return 0;
/* Load/Store Multiple instructions are handled in their own
* function
*/
- if (flags & M)
+ if (flags & M) {
+ WARN_EMULATE(multiple);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
+ }
/* Verify the address of the operand */
if (unlikely(user_mode(regs) &&
@@ -758,8 +765,10 @@ int fix_alignment(struct pt_regs *regs)
}
/* Special case for 16-byte FP loads and stores */
- if (nb == 16)
+ if (nb == 16) {
+ WARN_EMULATE(fp_pair);
return emulate_fp_pair(regs, addr, reg, flags);
+ }
/* If we are loading, get the data from user space, else
* get it from register values
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
static DEFINE_PER_CPU(struct cpu, cpu_devices);
@@ -291,12 +292,68 @@ static struct sysdev_attribute pa6t_attr
};
+#define SYSFS_EMULATED_SETUP(type) \
+DEFINE_PER_CPU(atomic_long_t, emulated_ ## type); \
+static ssize_t show_emulated_ ## type (struct sys_device *dev, \
+ char *buf) \
+{ \
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev);\
+ \
+ return sprintf(buf, "%lu\n",\
+ atomic_long_read(&per_cpu(emulated_ ## type, \
+
[PATCH 0/3] OF-platform PATA driver
Hi all, Here is the second spin of the OF-platform PATA driver and related patches. Changes since RFC: - nuked drivers/ata/pata_platform.h; - powerpc bits: proper localbus node added. Thanks for the previous review! This time I'm collecting acks, don't be shy to give 'em generously. ;-) Good luck, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/ata/pata_platform.c | 139 -
include/linux/pata_platform.h |8 +++
2 files changed, 90 insertions(+), 57 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..6436c38 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
-struct pata_platform_info *info)
+unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info && info->ioport_shift)
- shift = info->ioport_shift;
-
ioaddr->data_addr = ioaddr->cmd_addr + (ATA_REG_DATA<< shift);
ioaddr->error_addr = ioaddr->cmd_addr + (ATA_REG_ERR << shift);
ioaddr->feature_addr= ioaddr->cmd_addr + (ATA_REG_FEATURE << shift);
@@ -114,8 +109,12 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +134,17 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
-* Simple resource validation ..
-*/
- if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- /*
-* Get the I/O base first
-*/
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
-* Then the CTL base
-*/
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,14 +155,15 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- irq = 0;/* no irq */
+ if (irq_res && irq_res->start > 0) {
+ irq = irq_res->start;
+ irq_flags = irq_res->flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host->ports[0];
@@ -209,25 +184,24 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap->ioaddr.cmd_addr = devm_ioremap(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioremap(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioremap(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioremap(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
} else {
- ap->ioaddr.cmd_addr = devm_ioport_map(&pdev-
Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
On Tue, Nov 27, 2007 at 03:56:53PM +0100, Geert Uytterhoeven wrote: > On Wed, 21 Nov 2007, Geert Uytterhoeven wrote: > > On Tue, 20 Nov 2007, Kumar Gala wrote: > > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote: > > > > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote: > > > >> isel (Integer Select) is a new user space instruction in the > > > >> PowerISA 2.04 spec. Not all processors implement it so lets emulate > > > >> to ensure code built with isel will run everywhere. > > > > > > > > Given that the instruction is meant to be a performance enhancement, > > > > we should probably warn the first few times it's emulated, so the user > > > > knows they should change their toolchain setup if possible. > > > > > > The same is true of mcrxr, popcntb, and possibly string ld/st. > > > > > > Feel free to submit a patch that warns about their usage. > > > > Something like this? > > New version below. > > Do we want it in sysfs? Or should we use debugfs instead? I like this, and I'd say it's useful to have in sysfs. Few production systems enable debugfs, and this is something that could be useful to have access to there. > Subject: powerpc: Keep track of emulated instructions > > From: Geert Uytterhoeven <[EMAIL PROTECTED]> > > powerpc: Keep track of emulated instructions > > Counters for the various classes of emulated instructions are available under > /sys/devices/system/cpu/cpu*/emulated/. > Optionally, rate-limited warnings can be printed to the console when > instructions are emulated. > > Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> > --- > arch/powerpc/Kconfig.debug | 10 ++ > arch/powerpc/kernel/align.c| 17 -- > arch/powerpc/kernel/sysfs.c| 64 > - > arch/powerpc/kernel/traps.c| 17 +- > include/asm-powerpc/emulator.h | 60 ++ This name stood out as being a bit too generic, emulator could mean system support for running under some sort of emulator as well. How about emulated_ops.h? > +config DEBUG_WARN_EMULATED > + bool "Warn if emulated instructions are used" > + depends on DEBUG_KERNEL && SYSFS > + help > + This option will cause messages to be printed if an instruction is > + emulated. > + Counters for emulated instruction usages are always available under > + /sys/devices/system/cpu/cpu*/emulated/, irrespective of the state > + of this option. How about making it a sysctl instead, so it can be flipped at runtime (but default off)? -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/pata_of_platform.c | 86
3 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..5a492fa 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -614,6 +614,16 @@ config PATA_PLATFORM
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI)+= pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 000..e6c769c
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,86 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int ioport_shift = 0;
+ uint32_t *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = (uint32_t *)of_get_property(dn, "ioport-shift", NULL);
+ if (prop)
+ ioport_shift = *prop;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+ioport_shift);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = "pata-platform", },
+};
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = "pata_of_platform",
+ .match_table= pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove = __devexit_p(pata_of_platform_remove),
+};
+
+static int __init pata_of_platform_init(void)
+{
+ return of_register_platform_driver(&pata_of_platform_driver);
+}
+module_init(pata_of_platform_init);
+
+static void __exit pata_of_platform_exit(void)
+{
+ of_unregister_platform_driver(&pata_of_platform_driver);
+}
+module_exit(pata_of_platform_exit);
+
+MODULE_DESCRIPTION("OF-platform PATA driver");
+MODULE_AUTHOR("Anton Vorontsov <[EMAIL PROTECTED]>");
+MODULE_LICENSE("GPL");
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
This patch adds localbus and pata nodes to use CF IDE interface
on MPC8349E-mITX boards.
Patch also adds code to probe localbus.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts| 17 -
arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5072f6d..7a97068 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -249,6 +249,21 @@
device_type = "pci";
};
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349emitx-localbus",
+"fsl,mpc8349e-localbus",
+"fsl,pq2pro-localbus";
+ reg = ;
+ ranges = <3 0 f000 210>;
-
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8349emitx-pata", "pata-platform";
+ reg = <3 0 10 3 20c 4>;
+ ioport-shift = <1>;
+ interrupts = <17 8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
};
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..ea5f176 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -37,6 +38,22 @@
#include "mpc83xx.h"
+static struct of_device_id mpc834x_itx_ids[] = {
+ { .name = "localbus", },
+ {},
+};
+
+static int __init mpc834x_itx_declare_of_platform_devices(void)
+{
+ if (!machine_is(mpc834x_itx))
+ return 0;
+
+ of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
+
+ return 0;
+}
+device_initcall(mpc834x_itx_declare_of_platform_devices);
+
/*
*
* Setup the architecture
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Hello.
Anton Vorontsov wrote:
> This patch adds localbus and pata nodes to use CF IDE interface
> on MPC8349E-mITX boards.
> Patch also adds code to probe localbus.
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts| 17 -
> arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
> 2 files changed, 33 insertions(+), 1 deletions(-)
> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
> b/arch/powerpc/boot/dts/mpc8349emitx.dts
> index 5072f6d..7a97068 100644
> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> @@ -249,6 +249,21 @@
> device_type = "pci";
> };
>
> + [EMAIL PROTECTED] {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8349emitx-localbus",
Board compatible bus?
> + "fsl,mpc8349e-localbus",
> + "fsl,pq2pro-localbus";
> + reg = ;
> + ranges = <3 0 f000 210>;
>
> -
> + [EMAIL PROTECTED],0 {
> + compatible = "fsl,mpc8349emitx-pata", "pata-platform";
> + reg = <3 0 10 3 20c 4>;
> + ioport-shift = <1>;
Bleh... that shift again. And this is surely not a good name for a
property (where's I/O ports in your case?) -- why not call it "reg-shift"
(well, I'd call it "reg-size" or "reg-stride" myself :-)?
MBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
How to notify userspace of custom bus master/slave access mode changes ?
Hi everybody, I'm a bit unsure about how to notify userspace of changes to access mode to a custom bus. This is more an architecture issue than an implementation issue. My system has an ISA-like cold-pluggable extension bus. The bus controller sits on the CPU board which is plugged along with slave devices into a passive backplane. To add CPU redundancy support to the system, I implemented master and slave modes for the CPU board. The slave monitors the master and can disconnect it from the bus when a failure is detected. The bus drivers haven't been developed with hotplug in mind, but I eventually managed to fix them. The kernel is now able to scan the bus when a CPU board switches from slave to master mode, adding peripherals as they are detected, and to remove all peripherals when the CPU board switches from master to slave. I now have to notify userspace applications of master <-> slave mode changes. I thought about using kobject netlink notifications, but the kernel only generates events for individual peripherals (when they are added or removed). The bus driver registers a peripheral for the bus controller at boot time. I thought about registering the peripheral only when the system switches from slave to master, and deregistering it when it switches back to slave mode, but that's not very clean as the bus controller is always attached to the CPU, regardless of its bus access mode. Beside, I need to access the bus controller to detect master <-> slave transitions, so this would be a bit hackish. Is there a kobject netlink event I could use that I haven't thought about ? Am I missing a pseudo-peripheral in my implementation ? Is there a preferred way to notify userspace of such events ? Thanks for any help you can provide (and thanks for having read this mail throughout :-)). Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpP35yPlaXJH.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
On Tue, Nov 27, 2007 at 06:49:13PM +0300, Sergei Shtylyov wrote:
> Hello.
Hi Sergei,
> Anton Vorontsov wrote:
>
> >This patch adds localbus and pata nodes to use CF IDE interface
> >on MPC8349E-mITX boards.
>
> >Patch also adds code to probe localbus.
>
> >Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> >---
> > arch/powerpc/boot/dts/mpc8349emitx.dts| 17 -
> > arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
> > 2 files changed, 33 insertions(+), 1 deletions(-)
>
> >diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
> >b/arch/powerpc/boot/dts/mpc8349emitx.dts
> >index 5072f6d..7a97068 100644
> >--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> >+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> >@@ -249,6 +249,21 @@
> > device_type = "pci";
> > };
> >
> >+[EMAIL PROTECTED] {
> >+#address-cells = <2>;
> >+#size-cells = <1>;
> >+compatible = "fsl,mpc8349emitx-localbus",
>
>Board compatible bus?
This is what Documentation/powerpc/booting-without-of.txt suggests
for localbuses. I'm following.
> >+ "fsl,mpc8349e-localbus",
> >+ "fsl,pq2pro-localbus";
> >+reg = ;
> >+ranges = <3 0 f000 210>;
> >
> >-
> >+[EMAIL PROTECTED],0 {
> >+compatible = "fsl,mpc8349emitx-pata",
> >"pata-platform";
> >+reg = <3 0 10 3 20c 4>;
> >+ioport-shift = <1>;
>
>Bleh... that shift again. And this is surely not a good name for a
> property (where's I/O ports in your case?) -- why not call it "reg-shift"
> (well, I'd call it "reg-size" or "reg-stride" myself :-)?
1. "shift" because pata_platform using that name. I don't see any
reason to contrive indirections. ioport-shift is what the whole
Linux kernel using nowadays, and ioport-shift dts property
anyway Linux-specific.
I'm just following todays' conventions.
If you feel really bad about that, I think better to fix that in
the source of the badness -- pata_platform. It's easy, I can do
that. Would you ack patch that converts whole pata_platform and
users? Would Paul ack it?
Still, is there any hardware that needs not power of 2 stride?
2. "ioport" because shift^Wstride ;-) applies only to the io range
(yes, it's obvious, but worth open-wording, no?).
And btw, I can get rid of ioport-shift at all. And do fixups in
the pata_of_platform driver via .compatible matching. But I don't
want: it feels bad to list every needs-to-fixup board in the common
driver. It also feels not so great creating something like
pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Anton Vorontsov wrote:
>>>This patch adds localbus and pata nodes to use CF IDE interface
>>>on MPC8349E-mITX boards.
>>>Patch also adds code to probe localbus.
>>>Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>>>---
>>>arch/powerpc/boot/dts/mpc8349emitx.dts| 17 -
>>>arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
>>>2 files changed, 33 insertions(+), 1 deletions(-)
>>>diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>b/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>index 5072f6d..7a97068 100644
>>>--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
>>>@@ -249,6 +249,21 @@
>>> device_type = "pci";
>>> };
>>>
>>>+[EMAIL PROTECTED] {
>>>+#address-cells = <2>;
>>>+#size-cells = <1>;
>>>+compatible = "fsl,mpc8349emitx-localbus",
>>
>> Board compatible bus?
> This is what Documentation/powerpc/booting-without-of.txt suggests
> for localbuses. I'm following.
Hm...
>>>+ "fsl,mpc8349e-localbus",
>>>+ "fsl,pq2pro-localbus";
>>>+reg = ;
>>>+ranges = <3 0 f000 210>;
>>>
>>>-
>>>+[EMAIL PROTECTED],0 {
>>>+compatible = "fsl,mpc8349emitx-pata",
>>>"pata-platform";
>>>+reg = <3 0 10 3 20c 4>;
>>>+ioport-shift = <1>;
>> Bleh... that shift again. And this is surely not a good name for a
>>property (where's I/O ports in your case?) -- why not call it "reg-shift"
>>(well, I'd call it "reg-size" or "reg-stride" myself :-)?
> 1. "shift" because pata_platform using that name. I don't see any
>reason to contrive indirections. ioport-shift is what the whole
>Linux kernel using nowadays, and ioport-shift dts property
>anyway Linux-specific.
It's just a bad name. There's not even I/O ports in this case (and
moreover, the *real* I/O mapped device would always have a shift of 0, I bet
-- larger strides are for memory mapped devices).
>I'm just following todays' conventions.
>If you feel really bad about that, I think better to fix that in
>the source of the badness -- pata_platform. It's easy, I can do
I only feel really bad about the "ioport" part, I can live with "shift"
part. :-)
>that. Would you ack patch that converts whole pata_platform and
>users? Would Paul ack it?
I don't understand -- why the property name should duplicate pata_platform
field name? :-O
>Still, is there any hardware that needs not power of 2 stride?
Not really -- "size" just seems better, aesthetically. :-)
> 2. "ioport" because shift^Wstride ;-) applies only to the io range
>(yes, it's obvious, but worth open-wording, no?).
Contrarywise, to memory range.
> And btw, I can get rid of ioport-shift at all. And do fixups in
> the pata_of_platform driver via .compatible matching. But I don't
> want: it feels bad to list every needs-to-fixup board in the common
> driver. It also feels not so great creating something like
> pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
I didn't propose neither of that. :-)
All I want is that "ioport-*" be renamed.
> Thanks,
MBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
On Tue, Nov 27, 2007 at 07:46:13PM +0300, Sergei Shtylyov wrote:
[...]
> >>>+ ioport-shift = <1>;
>
> >> Bleh... that shift again. And this is surely not a good name for a
> >>property (where's I/O ports in your case?) -- why not call it "reg-shift"
> >>(well, I'd call it "reg-size" or "reg-stride" myself :-)?
>
> >1. "shift" because pata_platform using that name. I don't see any
> > reason to contrive indirections. ioport-shift is what the whole
> > Linux kernel using nowadays, and ioport-shift dts property
> > anyway Linux-specific.
>
>It's just a bad name. There's not even I/O ports in this case (and
> moreover, the *real* I/O mapped device would always have a shift of 0, I
> bet -- larger strides are for memory mapped devices).
>
> > I'm just following todays' conventions.
>
> > If you feel really bad about that, I think better to fix that in
> > the source of the badness -- pata_platform. It's easy, I can do
>
>I only feel really bad about the "ioport" part, I can live with "shift"
> part. :-)
>
> > that. Would you ack patch that converts whole pata_platform and
> > users? Would Paul ack it?
>
>I don't understand -- why the property name should duplicate
>pata_platform field name? :-O
Because:
> >1. [...] I don't see any reason to contrive indirections.
That is, different names for single thing is worse than single
bogus name.
> Not really -- "size" just seems better, aesthetically. :-)
reg-size will look confusing. Is it ata registers' size? No,
can't be. So, what is it? It's stride/shift because of bus, on
which ata resides.
> >And btw, I can get rid of ioport-shift at all. And do fixups in
> >the pata_of_platform driver via .compatible matching. But I don't
> >want: it feels bad to list every needs-to-fixup board in the common
> >driver. It also feels not so great creating something like
> >pata-platform-stride-{1,2,4,...} compatible stuff. Heh.
>
>I didn't propose neither of that. :-)
Yup, that was "by the way"...
>All I want is that "ioport-*" be renamed.
I give up.
The final name is..? I can think out wrong one, so you'd better
convoy me on that way. ;-) reg-shift sounds okay? Or reg-stride
better? No size, please.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Anton Vorontsov wrote: >> All I want is that "ioport-*" be renamed. > I give up. Don't. :-) > The final name is..? I can think out wrong one, so you'd better > convoy me on that way. ;-) reg-shift sounds okay? Yes. > Thanks, WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
[ Had cut too much in the previous reply ] On Tue, Nov 27, 2007 at 07:46:13PM +0300, Sergei Shtylyov wrote: [...] > >2. "ioport" because shift^Wstride ;-) applies only to the io range > > (yes, it's obvious, but worth open-wording, no?). > >Contrarywise, to memory range. By io range I meant "I/O base", in contrast to "CTL base". There is no need to apply shifting for CTL. That's why ioport-* appeared in the first place. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Anton Vorontsov wrote: >>>2. "ioport" because shift^Wstride ;-) applies only to the io range >>> (yes, it's obvious, but worth open-wording, no?). >> Contrarywise, to memory range. > By io range I meant "I/O base", in contrast to "CTL base". > There is no need to apply shifting for CTL. That's why ioport-* > appeared in the first place. So, a matter of wrong terminology then. The thing that you meant by "I/O" is actually called "command block". MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
On Tue, Nov 27, 2007 at 08:34:11PM +0300, Sergei Shtylyov wrote: > Anton Vorontsov wrote: > > >>>2. "ioport" because shift^Wstride ;-) applies only to the io range > >>> (yes, it's obvious, but worth open-wording, no?). > > >> Contrarywise, to memory range. > > >By io range I meant "I/O base", in contrast to "CTL base". > > >There is no need to apply shifting for CTL. That's why ioport-* > >appeared in the first place. > >So, a matter of wrong terminology then. The thing that you meant by >"I/O" is actually called "command block". Yes. And IO is the second name. It's used widespread in the drivers/ide/. Now you understand why I'm so reluctant to hanging up different labels on the single thing? ;-) -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
Anton Vorontsov wrote: >2. "ioport" because shift^Wstride ;-) applies only to the io range >(yes, it's obvious, but worth open-wording, no?). Contrarywise, to memory range. >>>By io range I meant "I/O base", in contrast to "CTL base". >>>There is no need to apply shifting for CTL. That's why ioport-* >>>appeared in the first place. >> So, a matter of wrong terminology then. The thing that you meant by >> "I/O" is actually called "command block". > Yes. And IO is the second name. I'd say the first place in drivers/ide belongs to the historic name "taskfile". The "command block" which is as ATA standard calls it, is hardly used. > It's used widespread in the drivers/ide/. Don't remember seeing it. > Now you understand why I'm so reluctant to hanging up different > labels on the single thing? ;-) :-) MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
On Tue, Nov 27, 2007 at 09:07:14PM +0300, Sergei Shtylyov wrote: > Anton Vorontsov wrote: > > >2. "ioport" because shift^Wstride ;-) applies only to the io range > >(yes, it's obvious, but worth open-wording, no?). > > Contrarywise, to memory range. > > >>>By io range I meant "I/O base", in contrast to "CTL base". > > >>>There is no need to apply shifting for CTL. That's why ioport-* > >>>appeared in the first place. > > >> So, a matter of wrong terminology then. The thing that you meant by > >> "I/O" is actually called "command block". > > > Yes. And IO is the second name. > > I'd say the first place in drivers/ide belongs to the historic name > "taskfile". The "command block" which is as ATA standard calls it, is hardly > used. > > > It's used widespread in the drivers/ide/. > > Don't remember seeing it. Oops, thinko -- not drivers/ide/, but include/linux/ide.h. Grep for io_addr. > > Now you understand why I'm so reluctant to hanging up different > > labels on the single thing? ;-) > > :-) -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
On Nov 27, 2007, at 9:49 AM, Sergei Shtylyov wrote:
> Hello.
>
> Anton Vorontsov wrote:
>
>> This patch adds localbus and pata nodes to use CF IDE interface
>> on MPC8349E-mITX boards.
>
>> Patch also adds code to probe localbus.
>
>> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>> ---
>> arch/powerpc/boot/dts/mpc8349emitx.dts| 17 -
>> arch/powerpc/platforms/83xx/mpc834x_itx.c | 17 +
>> 2 files changed, 33 insertions(+), 1 deletions(-)
>
>> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/
>> boot/dts/mpc8349emitx.dts
>> index 5072f6d..7a97068 100644
>> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
>> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
>> @@ -249,6 +249,21 @@
>> device_type = "pci";
>> };
>>
>> +[EMAIL PROTECTED] {
>> +#address-cells = <2>;
>> +#size-cells = <1>;
>> +compatible = "fsl,mpc8349emitx-localbus",
>
>Board compatible bus?
>
>> + "fsl,mpc8349e-localbus",
>> + "fsl,pq2pro-localbus";
>> +reg = ;
>> +ranges = <3 0 f000 210>;
>>
>> -
>> +[EMAIL PROTECTED],0 {
>> +compatible = "fsl,mpc8349emitx-pata", "pata-platform";
>> +reg = <3 0 10 3 20c 4>;
>> +ioport-shift = <1>;
>
>Bleh... that shift again. And this is surely not a good name for a
> property (where's I/O ports in your case?) -- why not call it "reg-
> shift"
> (well, I'd call it "reg-size" or "reg-stride" myself :-)?
I'm coming into this late, but if ioport-shift applies to reg (which I
think it does) it should really be called "reg-shift". The ePAPR is
using that property name:
Specifies in bytes how far the discrete device registers are separated
from each other. The
individual register location is calculated by using following formula:
“registers address” <<
reg-shift. If unspecified the default value is 0.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> This driver nicely wraps around pata_platform library functions,
> and provides OF platform bus bindings to the PATA devices.
> +static struct of_device_id pata_of_platform_match[] = {
> + { .compatible = "pata-platform", },
> +};
"pata-platform" really means nothing outside of linux. A more
generic label would be useful.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Tuesday 27 November 2007, Olof Johansson wrote:
> On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> > This driver nicely wraps around pata_platform library functions,
> > and provides OF platform bus bindings to the PATA devices.
>
> > +static struct of_device_id pata_of_platform_match[] = {
> > + { .compatible = "pata-platform", },
> > +};
>
> "pata-platform" really means nothing outside of linux. A more
> generic label would be useful.
Maybe the name of the standards it supports? Could be
"ata-4", "ata-5" and the like, or the exact transfer mode, like
"pata-udma-5", "pata-pio-3", "sata-150", etc.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
On Tuesday 27 November 2007, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC upstream kernel ignored DABR bug
On Monday 26 November 2007, Jan Kratochvil wrote: > Hi, > > this testcase: > http://people.redhat.com/jkratoch/dabr-lost.c > > reproduces a PPC DABR kernel bug. The variable `variable' should not get > modified as the thread modifying it should be caught by its DABR: > > $ ./dabr-lost > TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318 > TID 30915: DABR 0x10012a77 NIP 0x80f6ebb318 > TID 30916: DABR 0x10012a77 NIP 0x80f6ebb318 > TID 30914: hitting the variable > TID 30915: hitting the variable > TID 30916: hitting the variable > variable found = 30916, caught TID = 30914 > TID 30916: DABR 0x10012a77 > Variable got modified by a thread which has DABR still set! > This sounds like a bug recently reported by Uli Weigand. BenH said he'd take a look, but it probably fell under the table. The problem found by Uli is that on certain processors (Cell/B.E. in his case), the DABRX register needs to be set in order for the DABR to take effect. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sys_indirect kernel implementation for PowerPC
On Wednesday 21 November 2007, Stephen Rothwell wrote: > > +++ b/include/asm-powerpc/systbl.h > > @@ -313,3 +313,4 @@ COMPAT_SYS_SPU(timerfd) > > SYSCALL_SPU(eventfd) > > COMPAT_SYS_SPU(sync_file_range2) > > COMPAT_SYS(fallocate) > > +COMPAT_SYS(indirect) > > Do the SPUs want this? Excellent question. Sorry for being late in my reply here. The calls that are marked non-spu capable are those that are harmful when run on the SPU, e.g. because they modify the signal mask -- the SPU cannot receive signals itself. sys_indirect is potentially very useful on the SPU, but we can't allow it if it gives you access to all other syscalls. If we want to use it on the SPU at some point, we may have to provide an alternative implementation that walks the spu_syscall_table instead. OTOH, if sys_indirect is mostly useful for the eventual addition of syslets, we can leave it out, because syslets don't make sense if you have no multithreading capability. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] kernel_execve is identical in 32 and 64 bit
so concolidate it into misc.S. Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- arch/powerpc/kernel/misc.S|8 arch/powerpc/kernel/misc_32.S |7 --- arch/powerpc/kernel/misc_64.S |7 --- 3 files changed, 8 insertions(+), 14 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S index 330c9dc..74ce0c7 100644 --- a/arch/powerpc/kernel/misc.S +++ b/arch/powerpc/kernel/misc.S @@ -14,6 +14,7 @@ * 2 of the License, or (at your option) any later version. */ #include +#include .text @@ -43,3 +44,10 @@ _GLOBAL(add_reloc_offset) add r3,r3,r5 mtlrr0 blr + +_GLOBAL(kernel_execve) + li r0,__NR_execve + sc + bnslr + neg r3,r3 + blr diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 8b642ab..ea11378 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -793,13 +793,6 @@ _GLOBAL(kernel_thread) addir1,r1,16 blr -_GLOBAL(kernel_execve) - li r0,__NR_execve - sc - bnslr - neg r3,r3 - blr - /* * This routine is just here to keep GCC happy - sigh... */ diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index bbb3ba5..a3c491e 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -518,13 +518,6 @@ _GLOBAL(giveup_altivec) #endif /* CONFIG_ALTIVEC */ -_GLOBAL(kernel_execve) - li r0,__NR_execve - sc - bnslr - neg r3,r3 - blr - /* kexec_wait(phys_cpu) * * wait for the flag to change, indicating this kernel is going away but -- 1.5.3.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix os-term usage on kernel panic
(resending with the proper "from" addr this time).
I'm seeing some funky behavior on power5/power6 partitions with this
patch.A "/sbin/reboot" is now behaving much more like a
"/sbin/halt".
Anybody else seeing this, or is it time for me to call an exorcist for
my boxes?
-Will
On Mon, 2007-11-19 at 19:28 -0600, Linas Vepstas wrote:
> The rtas_os_term() routine was being called at the wrong time.
> The actual rtas call "os-term" will not ever return, and so
> calling it from the panic notifier is too early. Instead,
> call it from the machine_reset() call.
>
> The patch splits the rtas_os_term() routine into two: one
> part to capture the kernel panic message, invoked during
> the panic notifier, and another part that is invoked during
> machine_reset().
>
> Prior to this patch, the os-term call was never being made,
> because panic_timeout was always non-zero. Calling os-term
> helps keep the hypervisor happy! We have to keep the hypervisor
> happy to avoid service, dump and error reporting problems.
>
> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
>
>
> One could make a strong argument to move all of this code
> from kernel/rtas.c to platforms/pseries/setup.c I did not
> do this, just so as to make the changes minimal.
>
> arch/powerpc/kernel/rtas.c | 12 ++--
> arch/powerpc/platforms/pseries/setup.c |3 ++-
> include/asm-powerpc/rtas.h |3 ++-
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c
> ===
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/kernel/rtas.c 2007-11-19
> 18:58:53.0 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/kernel/rtas.c 2007-11-19
> 19:01:10.0 -0600
> @@ -631,18 +631,18 @@ void rtas_halt(void)
> /* Must be in the RMO region, so we place it here */
> static char rtas_os_term_buf[2048];
>
> -void rtas_os_term(char *str)
> +void rtas_panic_msg(char *str)
> {
> - int status;
> + snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> +}
>
> - if (panic_timeout)
> - return;
> +void rtas_os_term(void)
> +{
> + int status;
>
> if (RTAS_UNKNOWN_SERVICE == rtas_token("ibm,os-term"))
> return;
>
> - snprintf(rtas_os_term_buf, 2048, "OS panic: %s", str);
> -
> do {
> status = rtas_call(rtas_token("ibm,os-term"), 1, 1, NULL,
> __pa(rtas_os_term_buf));
> Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
> ===
> --- linux-2.6.24-rc2-git4.orig/arch/powerpc/platforms/pseries/setup.c
> 2007-11-19 18:58:53.0 -0600
> +++ linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/setup.c
> 2007-11-19 19:01:10.0 -0600
> @@ -507,7 +507,8 @@ define_machine(pseries) {
> .restart= rtas_restart,
> .power_off = pSeries_power_off,
> .halt = rtas_halt,
> - .panic = rtas_os_term,
> + .panic = rtas_panic_msg,
> + .machine_shutdown = rtas_os_term,
> .get_boot_time = rtas_get_boot_time,
> .get_rtc_time = rtas_get_rtc_time,
> .set_rtc_time = rtas_set_rtc_time,
> Index: linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h
> ===
> --- linux-2.6.24-rc2-git4.orig/include/asm-powerpc/rtas.h 2007-11-19
> 18:58:53.0 -0600
> +++ linux-2.6.24-rc2-git4/include/asm-powerpc/rtas.h 2007-11-19
> 19:01:10.0 -0600
> @@ -164,7 +164,8 @@ extern int rtas_call(int token, int, int
> extern void rtas_restart(char *cmd);
> extern void rtas_power_off(void);
> extern void rtas_halt(void);
> -extern void rtas_os_term(char *str);
> +extern void rtas_panic_msg(char *str);
> +extern void rtas_os_term(void);
> extern int rtas_get_sensor(int sensor, int index, int *state);
> extern int rtas_get_power_level(int powerdomain, int *level);
> extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
> ___
> 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 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, 27 Nov 2007 18:39:08 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +static int __devinit pata_of_platform_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + uint32_t *prop;
Make this "const uint32_t *prop" or (more kernel like) "const u32 *prop" ...
> + prop = (uint32_t *)of_get_property(dn, "ioport-shift", NULL);
then you don't need this cast. Anytime you use a cast to get rid of
"const", is probably a mistake.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpp8zGdiDVGf.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
of_compat_cmp on various platforms
Is this right or should it be the same everywhere? asm-powerpc/prom.h:#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2)) asm-sparc/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l)) asm-sparc64/prom.h:#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l)) -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: add hugepagesz boot-time parameter
This patch adds the hugepagesz boot-time parameter for ppc64 that lets
you pick the size for your huge pages. The choices available are 64K
and 16M. It defaults to 16M (previously the only choice) if nothing or
an invalid choice is specified. Tested 64K huge pages with the
libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
invocations.
This patch requires the patch posted by Mel Gorman that adds
HUGETLB_PAGE_SIZE_VARIABLE; "[PATCH] Fix boot problem with iSeries
lacking hugepage support" on 2007-11-15.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |1
arch/powerpc/mm/hash_utils_64.c | 11 +
arch/powerpc/mm/hugetlbpage.c | 41
include/asm-powerpc/mmu-hash64.h|1
mm/hugetlb.c|1
5 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 33121d6..2fc1fb8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in
the file
See Documentation/isdn/README.HiSax.
hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
+ hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
i8042.direct[HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f09730b..afc044c 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -368,18 +368,11 @@ static void __init htab_init_page_sizes(void)
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
- mmu_huge_psize = MMU_PAGE_16M;
+ set_huge_psize(MMU_PAGE_16M);
/* With 4k/4level pagetables, we can't (for now) cope with a
* huge page size < PMD_SIZE */
else if (mmu_psize_defs[MMU_PAGE_1M].shift)
- mmu_huge_psize = MMU_PAGE_1M;
-
- /* Calculate HPAGE_SHIFT and sanity check it */
- if (mmu_psize_defs[mmu_huge_psize].shift > MIN_HUGEPTE_SHIFT &&
- mmu_psize_defs[mmu_huge_psize].shift < SID_SHIFT)
- HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift;
- else
- HPAGE_SHIFT = 0; /* No huge pages dude ! */
+ set_huge_psize(MMU_PAGE_1M);
#endif /* CONFIG_HUGETLB_PAGE */
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 71efb38..f4632ad 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -24,6 +24,9 @@
#include
#include
+#define HPAGE_SHIFT_64K16
+#define HPAGE_SHIFT_16M24
+
#define NUM_LOW_AREAS (0x1UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
@@ -526,6 +529,44 @@ repeat:
return err;
}
+void set_huge_psize(int psize)
+{
+ /* Check that it is a page size supported by the hardware and
+* that it fits within pagetable limits. */
+ if (mmu_psize_defs[psize].shift && mmu_psize_defs[psize].shift <
SID_SHIFT &&
+ (mmu_psize_defs[psize].shift > MIN_HUGEPTE_SHIFT ||
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+ HPAGE_SHIFT = mmu_psize_defs[psize].shift;
+ mmu_huge_psize = psize;
+ } else
+ HPAGE_SHIFT = 0;
+}
+
+static int __init hugepage_setup_sz(char *str)
+{
+ unsigned long long size;
+
+ size = memparse(str, &str);
+
+ int shift = __ffs(size);
+ int mmu_psize = -1;
+ switch (shift) {
+ case HPAGE_SHIFT_64K:
+ mmu_psize = MMU_PAGE_64K;
+ break;
+ case HPAGE_SHIFT_16M:
+ mmu_psize = MMU_PAGE_16M;
+ break;
+ }
+ if (mmu_psize >= 0 && mmu_psize_defs[mmu_psize].shift)
+ set_huge_psize(mmu_psize);
+ else
+ printk(KERN_WARNING "Invalid huge page size specified(%i)\n",
size);
+
+ return 1;
+}
+__setup("hugepagesz=", hugepage_setup_sz);
+
static void zero_ctor(struct kmem_cache *cache, void *addr)
{
memset(addr, 0, kmem_cache_size(cache));
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 82328de..f35c945 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -277,6 +277,7 @@ extern int hash_huge_page(struct mm_struct *mm, unsigned
long access,
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
+extern void set_huge_psize(int psize);
extern void htab_initialize(void);
extern void htab_initialize
[PATCH 2/2] powerpc: make 64K huge pages more reliable
This patch adds reliability to the 64K huge page option by making use of
the PMD for 64K huge pages when base pages are 4k. So instead of a 12
bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
would continue as 9 bits and 7 bits respectively. This will allow the
pgtable to fit in one base page. This patch would have to be applied
after part 1.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
hugetlbpage.c | 53 ++---
1 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index f4632ad..c6df45b 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -30,15 +30,11 @@
#define NUM_LOW_AREAS (0x1UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
-#ifdef CONFIG_PPC_64K_PAGES
-#define HUGEPTE_INDEX_SIZE (PMD_SHIFT-HPAGE_SHIFT)
-#else
-#define HUGEPTE_INDEX_SIZE (PUD_SHIFT-HPAGE_SHIFT)
-#endif
-#define PTRS_PER_HUGEPTE (1 << HUGEPTE_INDEX_SIZE)
-#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << HUGEPTE_INDEX_SIZE)
+unsigned int hugepte_shift;
+#define PTRS_PER_HUGEPTE (1 << hugepte_shift)
+#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << hugepte_shift)
-#define HUGEPD_SHIFT (HPAGE_SHIFT + HUGEPTE_INDEX_SIZE)
+#define HUGEPD_SHIFT (HPAGE_SHIFT + hugepte_shift)
#define HUGEPD_SIZE(1UL << HUGEPD_SHIFT)
#define HUGEPD_MASK(~(HUGEPD_SIZE-1))
@@ -105,7 +101,14 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long
addr)
if (!pmd_none(*pm))
return hugepte_offset((hugepd_t *)pm, addr);
#else
- return hugepte_offset((hugepd_t *)pu, addr);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ pmd_t *pm;
+ pm = pmd_offset(pu, addr);
+ if (!pmd_none(*pm))
+ return hugepte_offset((hugepd_t *)pm,
addr);
+ } else {
+ return hugepte_offset((hugepd_t *)pu, addr);
+ }
#endif
}
}
@@ -133,7 +136,14 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long
addr)
if (pm)
hpdp = (hugepd_t *)pm;
#else
- hpdp = (hugepd_t *)pu;
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ pmd_t *pm;
+ pm = pmd_alloc(mm, pu, addr);
+ if (pm)
+ hpdp = (hugepd_t *)pm;
+ } else {
+ hpdp = (hugepd_t *)pu;
+ }
#endif
}
@@ -161,7 +171,6 @@ static void free_hugepte_range(struct mmu_gather *tlb,
hugepd_t *hpdp)
PGF_CACHENUM_MASK));
}
-#ifdef CONFIG_PPC_64K_PAGES
static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
unsigned long addr, unsigned long end,
unsigned long floor, unsigned long ceiling)
@@ -194,7 +203,6 @@ static void hugetlb_free_pmd_range(struct mmu_gather *tlb,
pud_t *pud,
pud_clear(pud);
pmd_free_tlb(tlb, pmd);
}
-#endif
static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
unsigned long addr, unsigned long end,
@@ -213,9 +221,15 @@ static void hugetlb_free_pud_range(struct mmu_gather *tlb,
pgd_t *pgd,
continue;
hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
#else
- if (pud_none(*pud))
- continue;
- free_hugepte_range(tlb, (hugepd_t *)pud);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ if (pud_none_or_clear_bad(pud))
+ continue;
+ hugetlb_free_pmd_range(tlb, pud, addr, next, floor,
ceiling);
+ } else {
+ if (pud_none(*pud))
+ continue;
+ free_hugepte_range(tlb, (hugepd_t *)pud);
+ }
#endif
} while (pud++, addr = next, addr != end);
@@ -538,6 +552,15 @@ void set_huge_psize(int psize)
mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
HPAGE_SHIFT = mmu_psize_defs[psize].shift;
mmu_huge_psize = psize;
+#ifdef CONFIG_PPC_64K_PAGES
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+#else
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else
+ hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
+#endif
+
} else
HPAGE_SHIFT = 0;
}
__
