* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 15:06 UTC (permalink / raw)
To: Daniel Walker; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <1179500217.20519.53.camel@imap.mvista.com>
Daniel Walker wrote:
>>I haven't looked at all the new clock/timer code, is there any
>>utility in having support for more than one clock source?
> There is if the main clocksource has some issues where it can't be used.
You mean, having more than one clocksource is *useful* in this case?
> On x86 there are lots of different issues with the clocks, so they have
> to get switches once in a while. For instance, if the TSC changes
> frequencies then it can't be used, or if the TSC stops in different
> power states , it can't be used..
Yeah, and there's the rating systems for both clock sources/events.
> Anything like that on PowerPC?
Well, the decrementer frequency may change, at least in theory (if the bus
clock changes).
> Daniel
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Daniel Walker @ 2007-05-18 14:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <135307ED-7125-4859-8594-4B5B900D92D6@kernel.crashing.org>
On Thu, 2007-05-17 at 13:17 -0500, Kumar Gala wrote:
>
> I haven't looked at all the new clock/timer code, is there any
> utility in having support for more than one clock source?
There is if the main clocksource has some issues where it can't be used.
On x86 there are lots of different issues with the clocks, so they have
to get switches once in a while. For instance, if the TSC changes
frequencies then it can't be used, or if the TSC stops in different
power states , it can't be used..
Anything like that on PowerPC?
Daniel
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 14:52 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, tglx, linux-kernel
In-Reply-To: <787b0d920705172024g723412b4n8f82d3cd78e0f702@mail.gmail.com>
Hello.
Albert Cahalan wrote:
>>>>> I haven't looked at all the new clock/timer code, is there any
>>>>> utility in having support for more than one clock source?
>>>> Of course, you may register as many as you like.
>>> Sure, but is there any utility in registering more than the
>>> decrementer on PPC?
>> Not yet. I'm not sure I know any other PPC CPU facility fitting
>> for clockevents. In theory, FIT could be used -- but its period
>> is measured in powers of 2, IIRC.
> I'd really like to have that as an option. It would allow oprofile
> to safely use hardware events on the MPC74xx "G4" processors.
> Alternately it would allow thermal events. It is safe to use at
> most one of the three (decrementer,profiling,thermal) interrupts.
> If two were to hit at the same time, badness happens.
Unfortunately, FIT exists only on Book E CPUs and MPC74xx aren't Book E, IIUC.
> It's possible to wrapper the interrupt in something that divides
> down, calling the normal code only some of the time. I think one
> of the FIT choices is about 4 kHz on my system, which would be OK.
Erm, are you sure you have FIT (or is your system not MPC74xx based)?
> Full oprofile functionality would be wonderful.
WBR, Sergei
^ permalink raw reply
* Re: [i2c] [PATCH 2/5] i2c: Allow preallocation of I2C bus numbers.
From: Jean Delvare @ 2007-05-18 14:47 UTC (permalink / raw)
To: David Brownell, Scott Wood; +Cc: linuxppc-dev, i2c
In-Reply-To: <200705171955.38899.david-b@pacbell.net>
On Thu, 17 May 2007 19:55:38 -0700, David Brownell wrote:
> I confess I don't quite follow the intent of this patch.
>
> - i2c_alloc_bus_number() ... why not just have the platform
> maintainer define the numbers? (Or in the OF case, just
> have the OF glue assign them.) And it's pointless to
> export this, given it supports calling a non-exported routine.
>
> - i2c_add_prenumbered_adapter() ... caller should just set
> adapter->number itself and call i2c_add_numbered_adapter();
> no need for a new routine.
>
> Both calls seem useless to me.
I can only second David's scepticism here. I fail to see the purpose of
this patch. It looks to me like we already have everything in place to
cover all use cases:
* If you need to declare the I2C devices before the I2C adapters are
created, you have i2c_register_board_info() and
i2c_add_numbered_adapter().
* If you declare the I2C adapters first, you have i2c_add_adapter() and
i2c_new_device/i2c_new_probed_device().
Scott, what problem were you trying to solve?
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Thomas Gleixner @ 2007-05-18 14:48 UTC (permalink / raw)
To: Matt Sealey; +Cc: linux-kernel, linuxppc-dev, mingo
In-Reply-To: <464DB800.40702@genesi-usa.com>
On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
> >> I guess the real question is, how high resolution does a high resolution
> >> timer need to be,
> >
> > In the order of microseconds.
>
> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
> easily.
There is some basic work for MPC5200 available:
http://www.pengutronix.de/oselas/bsp/phytec/index_en.html#phyCORE-MPC5200B-tiny
tglx
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Timur Tabi @ 2007-05-18 14:34 UTC (permalink / raw)
To: Wade Farnsworth, linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <20070518005641.GA27350@localhost.localdomain>
David Gibson wrote:
> On Thu, May 17, 2007 at 01:46:26PM -0500, Timur Tabi wrote:
>> Wade Farnsworth wrote:
>>
>>> Yes. On rev 1.0 boards, all of the devices on the south bridge are on
>>> bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
>>>
>>> I'd like to use the same dts for both rev's if possible. But if there
>>> is a reason why they shouldn't, I suppose I could create a separate dts.
>> I think two DTS files is the best approach for now. A few of us had
>> an idea to introduce conditional statements in to the DTS, and
>
> Erm... how would you encode such conditionals in the dtb?
We'll propose a spec once we have everything figured out. Our current idea is to allow
any node or property to have a conditional attached to it. U-Boot will then scan the
device tree, evaluate the conditional, and if it's false, delete the particular node/property.
U-Boot will be also be expanded to include the concept of "hardware options", whether the
user and/or board-specific code can tell U-Boot that hardware option X is set to value Y.
The conditions in the device tree will be of the form "X == Y" (or X != Y, X > Y, etc).
For instance, on some board, if jumper 22 is on, then it means that the USB port is
enabled. If it's possible for software to scan the status of J22, then the board-specific
code will do that, and it will create an environment variable "J22=ON". The USB node in
the device tree will have the conditional "J22 = ON".
> I really
> don't like the idea of having a generalized conditional
> parser/evaluator built into the bootwrapper.
Well, let us present the full proposal with our reasonings when we're ready. I don't want
to engage in speculative debate.
> What I'd been thinking for situations like this is to fold two dtbs
> into the bootwrapper and have it select between them based on on board
> revision (assuming that can be deduced from registers somehow).
Our idea is very similar, but just more standardized and more granular.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Matt Sealey @ 2007-05-18 14:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464DADFC.3080802@ru.mvista.com>
Sergei Shtylyov wrote:
> Hello.
>
>>>> Sure, but is there any utility in registering more than the
>>>> decrementer on PPC?
>
>>> Not yet. I'm not sure I know any other PPC CPU facility fitting
>>> for clockevents. In theory, FIT could be used -- but its period is
>>> measured in powers of 2, IIRC.
>
>> Wouldn't it be possible to use SoC timer functionality, too, and not
>> limit this to what is only present on the CPU die?
>
> If you have some SoC timers, you're welcome to add support for it. :-)
Well, that can't be that hard.. I just make a clock_event_device and
clockevents_register_device?
I'm still learning my way through making platform devices (it would be
a shame to write an oldskool module when I can tie it to the device
tree..) but this does look fairly easy.
>> I guess the real question is, how high resolution does a high resolution
>> timer need to be,
>
> In the order of microseconds.
I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
easily.
>> and how often do you want to be handling interrupts?
>
> That depends on a kind of functionality you need: HRT and/or dynamic
> tick...
To be honest I never understood how dynamic ticks works, I am just
kind of excited about the functionality it brings :)
High resolution timers, that I can do. It's fairly easy to see the
benefits to presenting the system with multiple timers that can fire
with giddy amounts of precision (slice timer is between 16ns and
508ms at least, this is perfectly good considering comments above).
If I add a clock_event_device for each MPC52xx GPT and the slice timers,
what then? Where do they get used, and how? :)
I'm just curious as to how the system picks up and what the current
users are. It would be a little bit of a non-starter to provide 10
new high resolution timers, and for there be very little use for them,
but I assume because Intel HPET is supported, there must be at least
some PLANNED users for at least 2 or 3 independant, high resolution
timer interrupt sources beyond dynticks and nanosleep, but perhaps it
is too early (hrtimers were only integrated 6 months? ago, dynticks
is still brand new in mainline?) and I am being a bit impatient?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware
From: Matt Sealey @ 2007-05-18 13:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <464CA610.1050504@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> We also don't want people using a perfectly good device tree on a newer
>> revision of the board that just fixes things and doesn't make any
>> device-tree-relevant changes,
>
> Well, either one device tree is okay, or we need two. If we do need two, then it would be
> bad to load the wrong one on a particular board and have only 90% functionality. If he
> have the ability to prevent customers from getting confused, then we should do that. I
> wish this was standard behavior for all device trees. I've frequently loaded the wrong
> device tree and wondered why nothing worked.
Another design win for dynamically generated firmware device trees and
a knock on the head for writing text files and hoping they match the
hardware description? :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 13:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, tglx, Dave Liu, mingo, linux-kernel
In-Reply-To: <464DAD06.2060504@ru.mvista.com>
Hello, I wrote:
>>>>>Yes, on some implementations there can be other conditions that
>>>>>make a decrementer exception go away; there is no contradiction
>>>>>here (thankfully). My wording was sloppy.
>>>>Some CPUs have the DEC exceptions basically edge triggered (yeah I know
>>>for example?
>>>>it sucks). That's why, among others, the IRQ soft-disable code has code
>>>>to re-trigger DEC exceptions ASAP (by setting it to 1.. note that we
>>>>could probably use 0 here, we've been a bit conservative).
> Yeah, the classic decrementer is programmed off-by-one.
>>I'm not 100% certain... Paulus thinks all the old 6xx are like that, and
>>maybe POWER4. If I look at the oldest BookIV I can find (the 601), it
> From the "PowerPC Operating Environment Architecture" that I've already
> quoated t follows that POWER4-compatible decremented exception *must* be edge
> triggered.
... and cleared when delivered.
>>says that an exception is generated when the MSB transitions from 0 to
>>1. It's not clear wether the exception sticks while that bit is 1 or is
>>indeed considered as an "edge" event that gets cleared as soon as
>>delivered.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 13:45 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464D9E7E.3090605@genesi-usa.com>
Hello.
Matt Sealey wrote:
>>>>>I haven't looked at all the new clock/timer code, is there any
>>>>>utility in having support for more than one clock source?
>>>> Of course, you may register as many as you like.
>>>Sure, but is there any utility in registering more than the decrementer
>>>on PPC?
>> Not yet. I'm not sure I know any other PPC CPU facility fitting for
>>clockevents. In theory, FIT could be used -- but its period is measured in
>>powers of 2, IIRC.
> Wouldn't it be possible to use SoC timer functionality, too, and not limit
> this to what is only present on the CPU die?
If you have some SoC timers, you're welcome to add support for it. :-)
> I guess the real question is, how high resolution does a high resolution
> timer need to be,
In the order of microseconds.
> and how often do you want to be handling interrupts?
That depends on a kind of functionality you need: HRT and/or dynamic tick...
> The 52XX has 8 general purpose timers and 2 slice timers. Both will
> generate an interrupt once the clock hits a preset value, the timing
> of which is determined by prescalers and the IPB clock..
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Sergei Shtylyov @ 2007-05-18 13:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, tglx, Dave Liu, mingo, linux-kernel
In-Reply-To: <1179472096.32247.394.camel@localhost.localdomain>
Hello.
Benjamin Herrenschmidt wrote:
>>>>Yes, on some implementations there can be other conditions that
>>>>make a decrementer exception go away; there is no contradiction
>>>>here (thankfully). My wording was sloppy.
>>>Some CPUs have the DEC exceptions basically edge triggered (yeah I know
>>for example?
>>>it sucks). That's why, among others, the IRQ soft-disable code has code
>>>to re-trigger DEC exceptions ASAP (by setting it to 1.. note that we
>>>could probably use 0 here, we've been a bit conservative).
Yeah, the classic decrementer is programmed off-by-one.
> I'm not 100% certain... Paulus thinks all the old 6xx are like that, and
> maybe POWER4. If I look at the oldest BookIV I can find (the 601), it
From the "PowerPC Operating Environment Architecture" that I've already
quoated t follows that POWER4-compatible decremented exception *must* be edge
triggered.
> says that an exception is generated when the MSB transitions from 0 to
> 1. It's not clear wether the exception sticks while that bit is 1 or is
Freescale MPC 7450 manual says the same, for example.
> indeed considered as an "edge" event that gets cleared as soon as
> delivered.
> Ben.
WBR, Sergei
^ permalink raw reply
* RE: zImage.elf loads but does not start
From: Mirek23 @ 2007-05-18 13:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC2F39A4@exchangemb3.bnl.gov>
Hi Joe,
I have done this what you have suggested:
I have built statically busybox. During compilation of the busy box I have
go a warning that static build is buggy
but I have built the statically linked binary anyhow.
After that I have created the file:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/ttyUL0 644 0 0 c 208 187
dir /proc 755 0 0
dir /sys 755 0 0
file /init /myrootfs/busybox 755 0 0
Next I have run the program
usr/gen_init_cpio myList > myList.cpio
I have set in the .config CONFIG_INITRAMFS_SOURCE="myInit.cpio"
I have modified the CONFIG_CMDLINE="console=ttyUL0,9600"
I have built successfully the kernel and loaded it to my board.
When I have tried to boot the kernel I got as following:
---------------------------------------------------------------------------------------------------------
loaded at: 00400000 0052C138
board data at: 0052A120 0052A138
relocated to: 00404040 00404058
zimage at: 00404DCD 00529D69
avail ram: 0052D000 04000000
Linux/PPC load: console=ttyUL0,9600
Uncompressing Linux...done.
Now booting the kernel
---------------------------------------------------------------------------
And the kernel did not start.
I have also tried various options:
console=ttyUL0,9600 root=/dev/initrd rw rdinit=/init
or
console=ttyUL0,9600 root=/dev/ram0 rw rdinit=/init
Nothing helped.
I have also done the experiment:
I have set in the .config CONFIG_INITRAMFS_SOURCE=""
I have modified the CONFIG_CMDLINE="console=ttyUL0,9600"
When I have rebuilt the kernel it started to boot up to the point to mount
nfs and it failed.
Any idea why it did not boot with initramfs build in?
The kernel size with simple initramfs is 1.4 MB and without initramfs 1.1
MB.
Best Regards
Mirek
Mead, Joseph wrote:
>
> Hi Mirek,
>
> If you think the networking might be the source of the problem maybe try
> to make a very simple root file system using initramfs to see if you can
> get the init program (or busybox) working.
>
> Just create a file in that looks something like:
>
> dir /dev 755 0 0
> nod /dev/console 644 0 0 c 5 1
> nod /dev/ttyS0 644 0 0 c 4 64
> dir /proc 755 0 0
> dir /sys 755 0 0
> file /init usr/busybox 755 0 0
>
> and then tell the kernel about it General_Setup-> Initramfs source
> file(s)
>
> It will build the file system into the kernel image.
>
> Also, thanks for the files.
>
> Joe
>
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+mead=bnl.gov@ozlabs.org
> [mailto:linuxppc-embedded-bounces+mead=bnl.gov@ozlabs.org] On Behalf Of
> Mirek23
> Sent: Tuesday, May 15, 2007 8:09 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: RE: zImage.elf loads but does not start
>
>
>>It seems to be that the console works fine and the root file system is
> mounted properly via NFS.
>>I do not however understand why eldk4.1 init does not work.
>
> I have done some more investigations. My observation is as following:
>
> The eldk4.1/ppc_4xx root file system has the init which is not
> statically built. When I removed the lib directory on the NFS
> server:/opt/eldk4.1/ppc_4xx/lib the kernel has booted up to the point:
>
> [ 9.302101] VFS: Mounted root (nfs filesystem).
> [ 9.357642] Freeing unused kernel memory: 96k init
> [ 9.481509] Kernel panic - not syncing: No init found. Try passing
> init=
> option to kernel.
>
>
> When the lib directory was present the last printed message was:
> [ 9.357642] Freeing unused kernel memory: 96k init
>
> I have observed the same behaviour with busybox accessed via NFS.
> I have compiled busybox with crosstool-0.43 (gcc-4.0.2 glibc-2.3.2)
> because
> eldk4.1 crosscompilers failed to compile busybox. When using busybox
> mounted via NFS I copied the lib directory from crosstool.
> Unfortunately also this time the system hanged at init.
>
> My own version of init which uses printf just to print the string to the
> screen runs however fine.
>
> Would somebody have some suggestion what might cause the problem to
> properly launch the init command.
>
> Best Regards
>
> Mirek
> --
> View this message in context:
> http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10
> 621564
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10682140
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Please pull powerpc.git master branch
From: Paul Mackerras @ 2007-05-18 12:55 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
to get some powerpc bug and warning fixes, documentation, comment and
defconfig updates, some very minor cleanups, plus a couple more
syscalls wired up.
Thanks,
Paul.
arch/powerpc/Makefile | 3
arch/powerpc/boot/Makefile | 15 +
arch/powerpc/boot/dts/ebony.dts | 37 +--
arch/powerpc/boot/dts/kuroboxHD.dts | 44 +--
arch/powerpc/boot/dts/kuroboxHG.dts | 45 +---
arch/powerpc/boot/dts/lite5200.dts | 69 +++--
arch/powerpc/boot/dts/lite5200b.dts | 77 +++---
arch/powerpc/boot/dts/mpc7448hpc2.dts | 72 +++---
arch/powerpc/boot/dts/mpc8540ads.dts | 16 +
arch/powerpc/boot/dts/mpc8541cds.dts | 16 +
arch/powerpc/boot/dts/mpc8544ds.dts | 16 +
arch/powerpc/boot/dts/mpc8548cds.dts | 16 +
arch/powerpc/boot/dts/mpc8555cds.dts | 16 +
arch/powerpc/boot/dts/mpc8560ads.dts | 18 +
arch/powerpc/boot/dts/mpc8568mds.dts | 16 +
arch/powerpc/boot/flatdevtree.c | 17 +
arch/powerpc/configs/cell_defconfig | 15 -
arch/powerpc/configs/iseries_defconfig | 209 +++++++++-------
arch/powerpc/configs/pasemi_defconfig | 383 +++++++++++++++++-------------
arch/powerpc/kernel/cputable.c | 2
arch/powerpc/kernel/entry_32.S | 18 +
arch/powerpc/kernel/of_platform.c | 10 -
arch/powerpc/kernel/pci_64.c | 23 ++
arch/powerpc/kernel/prom.c | 5
arch/powerpc/kernel/rtas-proc.c | 2
arch/powerpc/lib/rheap.c | 22 +-
arch/powerpc/mm/hash_low_32.S | 18 +
arch/powerpc/mm/hash_utils_64.c | 4
arch/powerpc/mm/pgtable_64.c | 4
arch/powerpc/platforms/44x/Kconfig | 3
arch/powerpc/platforms/44x/ebony.c | 6
arch/powerpc/platforms/iseries/viopath.c | 21 +-
arch/powerpc/platforms/pasemi/Kconfig | 1
arch/powerpc/platforms/pseries/pseries.h | 4
arch/powerpc/sysdev/mpic.c | 12 +
arch/ppc/syslib/pq2_sys.c | 36 ++-
drivers/char/watchdog/booke_wdt.c | 2
drivers/macintosh/windfarm_core.c | 10 +
include/asm-powerpc/cputable.h | 6
include/asm-powerpc/mmu-44x.h | 2
include/asm-powerpc/mpc8260.h | 6
include/asm-powerpc/pgtable-ppc32.h | 15 -
include/asm-powerpc/pmac_feature.h | 6
include/asm-powerpc/systbl.h | 3
include/asm-powerpc/tsi108_irq.h | 6
include/asm-powerpc/tsi108_pci.h | 6
include/asm-powerpc/unistd.h | 11 +
47 files changed, 782 insertions(+), 582 deletions(-)
Becky Bruce (1):
[POWERPC] Change include protections to ASM_POWERPC
Benjamin Herrenschmidt (3):
[POWERPC] Add spinlock to request_phb_iospace()
[POWERPC] Fix IO space on PCI buses created from of_platform
[POWERPC] Make sure device node type/name is not NULL on hot-added nodes
Christian Krafft (1):
[POWERPC] cell_defconfig: Disable cpufreq and pmi
Christoph Hellwig (2):
[POWERPC] viopath: Use completion
[POWERPC] viopath: Use a completion in some more places
Dave Jiang (2):
[POWERPC] Fix comment in booke_wdt
[POWERPC] 85xx: Add device nodes for error reporting devices used by EDAC
David Gibson (4):
[POWERPC] Remove fixup_bigphys_addr() for arch/powerpc to avoid link error
[POWERPC] Fix bug adding properties with flatdevtree.c's ft_set_prop()
[POWERPC] Fix make rules for treeImage.initrd
[POWERPC] Small fixes for the Ebony device tree
James.Yang (1):
[POWERPC] Remove CPU_FTR_NEED_COHERENT for 7448.
Jon Tollefson (1):
[POWERPC] Correct #endif comment
Josh Boyer (1):
[POWERPC] Pass per-file CFLAGs for platform specific op codes
Kumar Gala (3):
[POWERPC] Fix COMMON symbol warnings
[POWERPC] 85xx: Add device nodes for error reporting devices used by EDAC
[POWERPC] Removed hardcoded phandles from dts
Morten Banzon (1):
[PPC] MCC2 missing in MPC826x device_list
Olof Johansson (3):
[POWERPC] pasemi: CONFIG_GENERIC_TBSYNC no longer needed
[POWERPC] Update pasemi_defconfig
[POWERPC] Remove warning in mpic.c
Segher Boessenkool (3):
[POWERPC] Specify GNUTARGET on $(AR) invocations
[POWERPC] Fix sed command lines for zlib source construction
[POWERPC] Fix ppc_rtas_progress_show()
Stephen Rothwell (4):
[POWERPC] Wire up some more syscalls
[POWERPC] Update iseries_defconfig
[POWERPC] Fix warning on UP
[POWERPC] Remove build warnings in windfarm_core
Timur Tabi (1):
[POWERPC] Fix alignment problem in rh_alloc_align() with exact-sized blocks
Tony Breeds (1):
[POWERPC] Fix Kconfig undefined symbol 'IBM_NEW_EMAC_ZMII'
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Mirek23 @ 2007-05-18 12:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0705152027280.16487-100000@slslc02.psi.ch>
> Anyway, you could try adding
> nfsroot=,rsize=1024,wsize=1024
> to your cmdline just in case...
I have tried that but it did not help :(
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10681348
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Matt Sealey @ 2007-05-18 12:39 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <464CA222.8000407@ru.mvista.com>
Sergei Shtylyov wrote:
> Hello.
>
> Kumar Gala wrote:
>
>>> Kumar Gala wrote:
>
>>>> I haven't looked at all the new clock/timer code, is there any
>>>> utility in having support for more than one clock source?
>
>>> Of course, you may register as many as you like.
>
>> Sure, but is there any utility in registering more than the decrementer
>> on PPC?
>
> Not yet. I'm not sure I know any other PPC CPU facility fitting for
> clockevents. In theory, FIT could be used -- but its period is measured in
> powers of 2, IIRC.
Wouldn't it be possible to use SoC timer functionality, too, and not limit
this to what is only present on the CPU die?
I guess the real question is, how high resolution does a high resolution
timer need to be, and how often do you want to be handling interrupts?
The 52XX has 8 general purpose timers and 2 slice timers. Both will
generate an interrupt once the clock hits a preset value, the timing
of which is determined by prescalers and the IPB clock..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] [POWERPC] remove build warnings in windfarm_core
From: Geert Uytterhoeven @ 2007-05-18 11:20 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Paul Mackerras, Segher
In-Reply-To: <20070517112215.6261992d.sfr@canb.auug.org.au>
On Thu, 17 May 2007, Stephen Rothwell wrote:
> diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
> index 192b26e..11ced17 100644
> --- a/drivers/macintosh/windfarm_core.c
> +++ b/drivers/macintosh/windfarm_core.c
> @@ -216,7 +216,10 @@ int wf_register_control(struct wf_control *new_ct)
> new_ct->attr.attr.mode = 0644;
> new_ct->attr.show = wf_show_control;
> new_ct->attr.store = wf_store_control;
> - device_create_file(&wf_platform_device.dev, &new_ct->attr);
> + if (device_create_file(&wf_platform_device.dev, &new_ct->attr))
> + printk(KERN_WARNING "windfarm: device_create_file failed"
> + " for %s\n", new_ct->name);
> + /* the subsystem still does useful work without the file */
Confusing indentation: the comment is not part of the branch
> @@ -326,7 +329,10 @@ int wf_register_sensor(struct wf_sensor *new_sr)
> new_sr->attr.attr.mode = 0444;
> new_sr->attr.show = wf_show_sensor;
> new_sr->attr.store = NULL;
> - device_create_file(&wf_platform_device.dev, &new_sr->attr);
> + if (device_create_file(&wf_platform_device.dev, &new_sr->attr))
> + printk(KERN_WARNING "windfarm: device_create_file failed"
> + " for %s\n", new_sr->name);
> + /* the subsystem still does useful work without the file */
Ditto.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* RE: MPC5200B memory performance
From: Daniel Schnell @ 2007-05-18 10:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070516180259.GA23085@server.idefix.lan>
Hi,
I found the following link to get more insights about the memcpy =
performance of my board:
http://www.greyhound-data.com/gunnar/glibc/index.htm
=20
One can download a testsuite for memory performance and let it run. Not =
only memcpy, but also memcmp and memset is tested.
This gave quite interesting results. Most of the time I get better =
values from optimized functions than from the glibc functions. As a rule =
of thumb: depending on the buffer size used, 15-20 % speedup, sometimes =
> 100% !
I will definetly integrate some of these functions in our software and =
then use=20
-Wl,--wrap,memcpy on the linker line to replace all occurences of =
memcpy, memcmp, etc. also for external libraries.
Best regards,
Daniel Schnell
--=20
Daniel Schnell | daniel.schnell@marel.com
Hugb=FAna=F0arger=F0 | www.marel.com
-----Original Message-----
From: linuxppc-embedded-bounces+daniel.schnell=3Dmarel.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+daniel.schnell=3Dmarel.com@ozlabs.org] =
On Behalf Of Matthias Fechner
Sent: 16. ma=ED 2007 18:03
To: linuxppc-embedded@ozlabs.org
Subject: Re: MPC5200B memory performance
Hello Daniel,
* Daniel Schnell <daniel.schnell@marel.com> [15-05-07 11:22]:
> I get the following values on my board:
my result is:
Test (10000) memcpy of sizes (1024) ....
10000 memcpy. Time per memcpy: 1814 [nsec] (564 MB/sec) finished.
Test (10000) memcpy of sizes (2048) ....
10000 memcpy. Time per memcpy: 3433 [nsec] (596 MB/sec) finished.
Test (10000) memcpy of sizes (4096) ....
10000 memcpy. Time per memcpy: 6687 [nsec] (612 MB/sec) finished.
Test (10000) memcpy of sizes (8192) ....
10000 memcpy. Time per memcpy: 21454 [nsec] (381 MB/sec) finished.
Test (10000) memcpy of sizes (16384) ....
10000 memcpy. Time per memcpy: 205551 [nsec] (79 MB/sec) finished.
Test (1000) memcpy of sizes (32768) ....
1000 memcpy. Time per memcpy: 379875 [nsec] (86 MB/sec) finished.
Test (1000) memcpy of sizes (51200) ....
1000 memcpy. Time per memcpy: 588792 [nsec] (86 MB/sec) finished.
Test (1000) memcpy of sizes (102400) ....
1000 memcpy. Time per memcpy: 1126511 [nsec] (90 MB/sec) finished.
Test (100) memcpy of sizes (1048576) ....
100 memcpy. Time per memcpy: 11307890 [nsec] (92 MB/sec) finished.
Test (10) memcpy of sizes (10485760) ....
10 memcpy. Time per memcpy: 120783600 [nsec] (86 MB/sec) finished.
Test (5) memcpy of sizes (52428800) ....
5 memcpy. Time per memcpy: 673867800 [nsec] (77 MB/sec) finished.
=20
Best regards,
Matthias
--=20
"Programming today is a race between software engineers striving to =
build bigger and better idiot-proof programs, and the universe trying to =
produce bigger and better idiots. So far, the universe is winning." -- =
Rich Cook _______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02hardware
From: Zhang Wei-r63237 @ 2007-05-18 10:20 UTC (permalink / raw)
To: Wade Farnsworth, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1179421139.8132.256.camel@rhino>
For support rev 1.0 boards, you can only remove the
pci@00:pci@00:interrupt-map sector. The pci driver can use
pci@8000:interrupt-map for irq mapping.
Such as below:
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 260b264..04626b1 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -297,6 +297,12 @@
interrupts =3D <49 2>;
interrupt-parent =3D <&mpic>;
};
+ uli1575: uli1575@100 {
+ reg =3D <0 0 0 0 0>;
+ pci_bridge@200 {
+ reg =3D <0 0 0 0 0>;
+ };
+ };
=20
};
Cheers,
Wei
> > On May 17, 2007, at 11:03 AM, Wade Farnsworth wrote:
> >=20
> > > On Thu, 2007-05-17 at 10:50 +0800, Zhang Wei-r63237 wrote:
> > >> Hi,
> > >>
> > >> If you add below sector to pci@8000, please remove the=20
> interrupt-map
> > >> sector from pci@8000.
> > >
> > > Correct me if I'm wrong, but I think if the interrupt-map=20
> for pci@8000
> > > is removed then the pci devices on the revision 1.0 board=20
> will not get
> > > the correct interrupts. I don't currently have a rev 1.0 to test
> > > though. Can someone with a rev 1.0 HPCN board confirm this?
> >=20
> > If I'm understanding things this might best be handled by two =20
> > different dts. Is this because of board changes or chip/silicon =20
> > changes?
> >=20
> > - k
> >=20
>=20
> Yes. On rev 1.0 boards, all of the devices on the south bridge are on
> bus 0, while on rev 1.02, the devices on the southbridge are on bus 2.
>=20
> I'd like to use the same dts for both rev's if possible. But if there
> is a reason why they shouldn't, I suppose I could create a=20
> separate dts.
>=20
> --Wade
>=20
>=20
^ permalink raw reply related
* Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
From: Dragos Carp @ 2007-05-18 7:44 UTC (permalink / raw)
To: Sylvain Munaut
Cc: David Brownell, spi-devel-general, Domen Puncer,
linuxppc-embedded
In-Reply-To: <464B329E.8030600@246tNt.com>
Sylvain Munaut wrote:
> David Brownell wrote:
>
>> On Wednesday 16 May 2007, Sylvain Munaut wrote:
>>
>>
>>> Well, this comment is not about the patch but about the driver it self,
>>> I didn't see it before today.
>>>
>>>
>> It merged earlier in the 2.6.22 cycle. If you don't have criticisms
>> about the patch itself, I'll forward it for merging after I get at
>> least an ack from Dragos.
>>
>>
> Yes, I saw when looking at the spi-devl archive. Would have been nice if the
> author though of cc-ing the ppc-embedded list ;)
>
>
Sorry about not cc-ing ppc-embedded, this was my first kernel patch, I'm
not very familiar with the submitting process.
> The patch looks ok to me (and needed actually since as Domen pointed
> out, 52xx
> has been replaced by 5200 in the device tree).
> And cell-index has been added to know the psc id without dirty tricks.
>
>
The patch looks ok. I'm currently still using 2.6.20 which still has
52xx. I compiled it for 2.6.22-rc2 and of course this problem was not
caught by the compiler. Unfortunately for the board that I'm using
(MPC5200-tiny from Pythec), there is no adaptation yet for 2.6.21.
>>> - MPC52xx_PA(MPC52xx_PSCx_OFFSET(...)) ??? You should get that from the
>>> resource of the platform_device. This macro is just there for early
>>> console stuff.
>>>
>>>
>> That PPC_MERGE stuff does look messy.
>>
>>
> Yes, trying to support both in a driver is really not pretty.
> Once we can finally get rid of it I'll submit a patch to clear that out.
>
>
A clean up for PPC_MERGE will be nice. There are still some magic
numbers used in the driver (SICR_SIM_CODEC8, SICR_GENCLK, etc..) that
should be defined in mpc52xx_psc.h.
Dragos
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Benjamin Herrenschmidt @ 2007-05-18 7:08 UTC (permalink / raw)
To: Dave Liu; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <1179466769.3658.0.camel@localhost.localdomain>
On Fri, 2007-05-18 at 13:39 +0800, Dave Liu wrote:
> > > Yes, on some implementations there can be other conditions that
> > > make a decrementer exception go away; there is no contradiction
> > > here (thankfully). My wording was sloppy.
> >
> > Some CPUs have the DEC exceptions basically edge triggered (yeah I know
>
> for example?
>
> > it sucks). That's why, among others, the IRQ soft-disable code has code
> > to re-trigger DEC exceptions ASAP (by setting it to 1.. note that we
> > could probably use 0 here, we've been a bit conservative).
I'm not 100% certain... Paulus thinks all the old 6xx are like that, and
maybe POWER4. If I look at the oldest BookIV I can find (the 601), it
says that an exception is generated when the MSB transitions from 0 to
1. It's not clear wether the exception sticks while that bit is 1 or is
indeed considered as an "edge" event that gets cleared as soon as
delivered.
Ben.
^ permalink raw reply
* RE: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev1.02 hardware
From: Jin Zhengxiong-R64188 @ 2007-05-18 6:52 UTC (permalink / raw)
To: Wade Farnsworth, Loeliger Jon-LOELIGER; +Cc: linuxppc-dev
In-Reply-To: <1179338794.8132.209.camel@rhino>
> -----Original Message-----
> From: linuxppc-dev-bounces+jinzhengxiong=3Dgmail.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+jinzhengxiong=3Dgmail.com@ozlabs.or
> g] On Behalf Of Wade Farnsworth
> Sent: Thursday, May 17, 2007 2:07 AM
> To: Loeliger Jon-LOELIGER
> Cc: linuxppc-dev
> Subject: Re: [PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0=20
> silicon and Rev1.02 hardware
>=20
> On Wed, 2007-05-16 at 11:44 -0500, Jon Loeliger wrote:
> > On Tue, 2007-05-15 at 11:50, Wade Farnsworth wrote:
> > > +static void __devinit early_mpc86xx_pcie(struct pci_dev *dev) {
> > > + dev->class =3D PCI_CLASS_BRIDGE_PCI << 8 | 0x1; }
> >=20
> > What'd we decide on that 0x1 in there?
> >=20
> > Thanks,
> > jdl
> >=20
> >=20
>=20
> I originally thought that it the 0x1 was necessary, but it=20
> was pointed out to me that it should not be.
>=20
> If I remove the 0x1 I get some I/O resource allocation=20
> failures on the P2P bridge and its child devices. I'm=20
> currently investigating what the cause of this is.
> --Wade
>=20
As you changed the class of the bridge, dev->transparent will be set
again in the later code, if you remove the 0x01 here, the
dev->transparent will be set to 0 later. So if you changed the class
like this, you do not need to set dev->transparent =3D 1 in your patch.
Jason=20
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch
From: Paul Mackerras @ 2007-05-18 6:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5F8D37B3-5A2B-49D8-A7C2-615436EA66D3@kernel.crashing.org>
Kumar Gala writes:
> Sorry for the headache, I thought I had built an ARCH=ppc kernel.
> This is now fixed in my tree so if you haven't pulled it you'll get
> the fix.
>
> Also, added a ppc_ksysm.c fix to remove a duplicate export symbol.
Hmmm. I had pulled your tree, and I ended up rebasing your commits on
top of Linus' current master and adding some more commits on top of
that. I'm about to send a pull request to Linus for that lot. The
arch/ppc changes can go in the next lot.
Paul.
^ permalink raw reply
* AW: BDI2000 configuration file for MPC8313E-RDB
From: Frank Prepelica @ 2007-05-18 6:00 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Leonid
Hi Leonid,
firstly, thanks for reply!
But, are you sure that I cannot access NAND memory via=20
BDI2000? Because I used BDI2000 with the MPC8343M Board=20
and there is "only" 64MB NAND memory. Thus I stored the=20
U-Boot (image was broken) into the flash memory.
Frank
-----Urspr=FCngliche Nachricht-----
Von: Leonid [mailto:Leonid@a-k-a.net]=20
Gesendet: Mittwoch, 16. Mai 2007 22:37
An: Frank Prepelica; linuxppc-embedded@ozlabs.org
Betreff: RE: BDI2000 configuration file for MPC8313E-RDB
AFAIK, BDI2000 doesn't support NAND... of course you can load some code
which has NAND support into RAM (even u-boot if compiled properly) and
thus program NAND flash. But BDI firmware cannot program NAND directly.
Leonid.
________________________________________
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Frank Prepelica
Sent: Wednesday, May 16, 2007 7:25 AM
To: linuxppc-embedded@ozlabs.org
Subject: BDI2000 configuration file for MPC8313E-RDB
Hi all,
maybe this is not the appropriate mailing list, sorry for that!
but, does anyone got a working BDI2000 configuration file + reg.
definitions for MPC8313E-RDB
to get access to NAND memory? I got one but there's only access to NOR
memory.
Many thanks in advance!
Best regards
Frank
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Dave Liu @ 2007-05-18 5:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, tglx, mingo, linux-kernel
In-Reply-To: <1179464690.32247.370.camel@localhost.localdomain>
> > Yes, on some implementations there can be other conditions that
> > make a decrementer exception go away; there is no contradiction
> > here (thankfully). My wording was sloppy.
>
> Some CPUs have the DEC exceptions basically edge triggered (yeah I know
for example?
> it sucks). That's why, among others, the IRQ soft-disable code has code
> to re-trigger DEC exceptions ASAP (by setting it to 1.. note that we
> could probably use 0 here, we've been a bit conservative).
^ permalink raw reply
* Re: RT patches expose netdev race [was Re: [RFC] [patch 2/2] powerpc 2.6.21-rt1: fix kernel hang and/or panic
From: Tsutomu OWA @ 2007-05-18 5:36 UTC (permalink / raw)
To: Linas Vepstas; +Cc: David Miller, linuxppc-dev, netdev, mingo, tglx
In-Reply-To: <20070517235247.GJ4325@austin.ibm.com>
At Thu, 17 May 2007 18:52:47 -0500, Linas Vepstas wrote:
> The stack trace from Owa-san showed a null pointer deref at
> ip_hdr(skb)->protocol for an skb passed in via hard_start_xmit()
>
> I dunno, memory corruption?
It turns out that there was a mistake in my report, sorry.
The error occurs on 2.6.21-rc5 + patch-2.6.21-rc5-rt12 + my patches,
but it does not on 2.6.21 + patch-2.6.21-rt1 + my patches (except spindernet one).
I thought I had checked it before sending the patch, but looks like I didn't.
My appologies...
-- owa
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox