* Re: Address mapping PPC 405
From: Jon Masters @ 2005-08-28 15:15 UTC (permalink / raw)
To: P. Sadik; +Cc: linuxppc-embedded
In-Reply-To: <ea43f4f9050825183121655ba2@mail.gmail.com>
On 8/26/05, P. Sadik <psadik@gmail.com> wrote:
> I have a question on how PPC addressing works. I am familiar with
> the MIPS architecture and new to PPC.
Hello!
> On MIPS, there are KUSEG (0x0000_0000 to 0x07FF_FFFF)
> which is always translated using TLB. Then there are two
> un-translated areas KSEG0 (0x8000_0000 which is cached)
> and KSEG1 (0xA000_0000).
Lovely. We don't do it that way on 405 but we could - since the MMU is
heavy soft assisted we could do that - we actually have everything run
through the MMU once we've done initial MMU setup, but we do have the
ability to mark ranges of addresses for IO and have the concept of TLB
pinning to lock ranges of kernel addresses in large translated (BAT
like for bigger PPC users) regions using just a few TLB slots. There
is also a ZPR (zone protection register), but that's mostly used to
fake the usual USER/KERNEL page distinction.
> On PPC I see that, the kernel .text is at 0xC000_0000. Is it a
> translated address? If it is, for running kernel code, the CPU has to
> consult the TLB always?
It's translated except during early setup and on certain exceptions -
but everything else you will do in the kernel sees virtual addresses.
> Another question is regarding addressing local peripherals. I am using
> an ML310 board from Xilinx
That I guessed. Partly since Peter had already replied, but also
because that's a large chunk of ppc405 users currently working on new
designs. Please bear in mind that only a few of us are aware of the
issues below.
> and it has DDR mapped to 0x0000_0000
> to 0x0FFF_FFFF (256 MB). Now, I need to add an IP to the PLB.
> For that, I am thinking of using 0x2000_0000 to 0x2000_0FFF.
> Now, my driver need to access the registers within the above region.
> How will I do that? It is an I/O, hence should I use ioremap, or can
> I access it directly? What role cache will play in this case?
You'll need to do an ioremap to get at that physical address from the
kernel, then use the returned virtual address to access your
peripheral. You should always use the appropriate read function rather
than doing a stw and an eieio and you probably want to make sure your
bootloader also has setup the right ZPR/etc. if you want to write to
that before Linux.
> The third question is, can I use de-referencing of address. Is it O.K
> to use pointers to access the registers, or do I have to use read/write
> variants?
You /can/ use a deference if you're setup that region as an IO remap
but why bother? That said, we've probably all done it and it does work
- that is your call.
> I would appreciate a lot if you could give some insight into this. Any
> pointers or reading materials will be very helpful.
Feel free to email. I've done a bunch of ml<insert number> projects
and I'm coming up on a ML403 when I get around to buying one for home
:-)
Jon.
P.S. I've been quiet on this list for a while, standard moving and
conference season combo.
^ permalink raw reply
* [PATCH] fix -Wundef warning for CONFIG_8xx
From: Olaf Hering @ 2005-08-28 11:49 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
happens with allnoconfig + CONFIG_SWAP, introduced with -rc4
linux-2.6.12/arch/ppc/mm/init.c:565:7: warning: "CONFIG_8xx" is not defined
Signed-off-by: Olaf Hering <olh@suse.de>
arch/ppc/mm/init.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.12/arch/ppc/mm/init.c
===================================================================
--- linux-2.6.12.orig/arch/ppc/mm/init.c
+++ linux-2.6.12/arch/ppc/mm/init.c
@@ -562,7 +562,7 @@ void flush_dcache_icache_page(struct pag
#ifdef CONFIG_BOOKE
__flush_dcache_icache(kmap(page));
kunmap(page);
-#elif CONFIG_8xx
+#elif defined(CONFIG_8xx)
/* On 8xx there is no need to kmap since highmem is not supported */
__flush_dcache_icache(page_address(page));
#else
^ permalink raw reply
* 2.6.13-rc7-git2 crashes on iBook
From: Andreas Schwab @ 2005-08-28 11:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linus Torvalds, linux-kernel
The last change to drivers/pci/setup-res.c (Ignore disabled ROM resources
at setup) is breaking radeonfb on iBook G3 (with Radeon Mobility M6 LY).
It crashes in pci_map_rom when called from radeonfb_map_ROM. This is
probably a dormant bug that was just uncovered by the change.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Debug Register MPC855
From: Marcelo Tosatti @ 2005-08-28 2:18 UTC (permalink / raw)
To: Jan.Schneider; +Cc: linux-ppc-embedded
Hi Jan,
> I have made som changes on kernel 2.4.18 to get access to the Debug
> Registers on a MPC855.
> Please apply and let me know whether the kernel runs stable or not.
> I need this support for the gdb to set Hardware Breakpoints on a MPC855
> target.
Did you wrote gdb support for it? Current gdb 6.3 uses the trap approach
bdm_ppc_ops.to_insert_breakpoint = ocd_insert_breakpoint;
bdm_ppc_ops.to_remove_breakpoint = ocd_remove_breakpoint;
Your patch looks good overall (needs some aesthetic cleanups).
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Paul Mackerras @ 2005-08-28 2:19 UTC (permalink / raw)
To: Dan Malek; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala, Tom Rini
In-Reply-To: <d18c6049f1976912db9a7022a85c158a@embeddededge.com>
Dan Malek writes:
> Yes, the application interfaces are all defined as 100 Hz (10 mSec).
> If the POSIX timer implementation is done properly, it should be
> possible to determine the timer parameters to eliminate this, but
> I doubt any applications do this. They all assume 10 mSec :-)
There are in fact only a few interfaces that work in terms of "clock
ticks", which are 10ms as far as userspace is concerned. I can think
of times() and that's about it. There are also the si_utime and
si_stime fields of the siginfo_t that comes along with a SIGCHLD. All
of those are about reporting CPU time used, not about specifying
timeouts.
All of the interfaces that specify timeouts or control timers use
struct timeval (seconds + microseconds) or struct timespec (seconds +
nanoseconds), or else use milliseconds (e.g. poll()).
Paul.
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-08-28 0:48 UTC (permalink / raw)
To: Grant Likely; +Cc: Andrew Morton, Tom Rini, Kumar Gala, linuxppc-dev
In-Reply-To: <20050827050422.GC7234@siegfried.thelikelysolution.ca>
On Aug 27, 2005, at 1:04 AM, Grant Likely wrote:
> What's the reason for clock jitter? Is it because most timeouts are
> set
> to multiples of 100, or some other reason?
Yes, the application interfaces are all defined as 100 Hz (10 mSec).
If the POSIX timer implementation is done properly, it should be
possible to determine the timer parameters to eliminate this, but
I doubt any applications do this. They all assume 10 mSec :-)
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Grant Likely @ 2005-08-27 5:04 UTC (permalink / raw)
To: Dan Malek; +Cc: Andrew Morton, Tom Rini, Kumar Gala, linuxppc-dev
In-Reply-To: <da1e14409c0face6cee5b4d5fa750c00@embeddededge.com>
On Fri, Aug 26, 2005 at 07:07:01PM -0400, Dan Malek wrote:
>
> On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:
>
> >Yes, it was. With 2.6.13 and on i386 (and other arches that actually
> >make use of the question) it can be any of 100, 250 or 1000.
>
> Well, 250 just seems wrong as I mentioned in a previous message.
> It will function, but an application is going to see lots of clock
> jitter
> unless you work in multiples of 100. My choices would be 100, 200,
> 500, or 1000.
What's the reason for clock jitter? Is it because most timeouts are set
to multiples of 100, or some other reason?
Thanks,
g.
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Tom Rini @ 2005-08-26 23:13 UTC (permalink / raw)
To: Dan Malek; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala
In-Reply-To: <da1e14409c0face6cee5b4d5fa750c00@embeddededge.com>
On Fri, Aug 26, 2005 at 07:07:01PM -0400, Dan Malek wrote:
>
> On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:
>
> >Yes, it was. With 2.6.13 and on i386 (and other arches that actually
> >make use of the question) it can be any of 100, 250 or 1000.
>
> Well, 250 just seems wrong as I mentioned in a previous message.
> It will function, but an application is going to see lots of clock
> jitter
> unless you work in multiples of 100. My choices would be 100, 200,
> 500, or 1000.
That's an arguement for lkml. But as I recall things, there shouldn't
be jitter, probably, with non multiples of 100. There was some
discussion, and a fair bit of flaming about all of this on lkml. I
think with some sort of numbers Linus might buy another choice added to
the list, but refuses anything "in theory" (this stems in part from the
must be 1000 crowd not being happy about 250 as the default).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-08-26 23:07 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala
In-Reply-To: <20050826225509.GF5541@smtp.west.cox.net>
On Aug 26, 2005, at 6:55 PM, Tom Rini wrote:
> Yes, it was. With 2.6.13 and on i386 (and other arches that actually
> make use of the question) it can be any of 100, 250 or 1000.
Well, 250 just seems wrong as I mentioned in a previous message.
It will function, but an application is going to see lots of clock
jitter
unless you work in multiples of 100. My choices would be 100, 200,
500, or 1000.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Tom Rini @ 2005-08-26 22:55 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859440@ismail.innsys.innovsys.com>
On Fri, Aug 26, 2005 at 05:48:53PM -0500, Rune Torgersen wrote:
> On Friday, August 26, 2005 16:32 Tom Rini wrote:
> > So 250 is supposed to be the best choice of power vs latency and such.
> > But hey, there's nothing stopping us from setting all of the embedded
> > configs back down to 100 :)
>
> I thought the default value for HZ in 2.6 was 1000?
Yes, it was. With 2.6.13 and on i386 (and other arches that actually
make use of the question) it can be any of 100, 250 or 1000.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-08-26 22:54 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala, Tom Rini
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859440@ismail.innsys.innovsys.com>
On Aug 26, 2005, at 6:48 PM, Rune Torgersen wrote:
> I thought the default value for HZ in 2.6 was 1000?
> At least this is what it is set at for the 82xx (and bigger embedded)
> boards
Oh geeze, no wonder we can't get any performance
out of 2.6 on these boards. Between that and the TLB
thrashing going on there's nothing left for the applications :-)
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-08-26 22:52 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala
In-Reply-To: <20050826213144.GE5541@smtp.west.cox.net>
On Aug 26, 2005, at 5:31 PM, Tom Rini wrote:
> So 250 is supposed to be the best choice of power vs latency and such.
Hahahaha! Now I've hear it all. I can go home now.
A proper event driven timer would be the best choice ......
Thanks.
-- Dan
^ permalink raw reply
* RE: [PATCH] ppc32: add CONFIG_HZ
From: Rune Torgersen @ 2005-08-26 22:48 UTC (permalink / raw)
To: Tom Rini, Dan Malek; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala
On Friday, August 26, 2005 16:32 Tom Rini wrote:
> So 250 is supposed to be the best choice of power vs latency and such.
> But hey, there's nothing stopping us from setting all of the embedded
> configs back down to 100 :)
I thought the default value for HZ in 2.6 was 1000?
At least this is what it is set at for the 82xx (and bigger embedded)
boards=20
^ permalink raw reply
* Re: Address mapping PPC 405
From: Peter Ryser @ 2005-08-26 22:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20050826031057.GA6553@siegfried.thelikelysolution.ca>
>Since there is no seperate IO memory space you can access the registers
>with simple pointers.
>
>Whether or not it is a good idea (based on coding conventions) I'll
>leave for someone else to answer. :)
>
You want to use the read{b,w,l} and write{b,w,l} macros for two reasons:
1. Accesses to registers need to be synch'ed with 'eieio' or some other
synchronizing instructions.
2. Portability of your driver if you ever should ever move it to a
different architecture and/or change the endianness in your system
- Peter
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Tom Rini @ 2005-08-26 21:31 UTC (permalink / raw)
To: Dan Malek; +Cc: Andrew Morton, linuxppc-dev, Kumar Gala
In-Reply-To: <f0351d402e64b569bbcfc16fa921d860@embeddededge.com>
On Fri, Aug 26, 2005 at 04:13:04PM -0400, Dan Malek wrote:
>
> On Aug 26, 2005, at 3:15 PM, Kumar Gala wrote:
>
> >While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
> >used. Connect it up and set all platforms to 250Hz. This pretty much
> >mimics the ppc64 patch from Anton Blanchard.
>
> Why do we keep cranking up this clock frequency? Do we really need
> it running that fast? Is it time for someone with RTOS experience to
> implement a real scheduled clock queue in Linux instead of just
> wasting interrupts decrementing a counter waiting for the next
> event to expire? :-) If the user "ticks" are still 100 Hz, don't we
> need
> something that is an integer multiple of that for at least an attempt
> at getting it close to what a user would request?
So 250 is supposed to be the best choice of power vs latency and such.
But hey, there's nothing stopping us from setting all of the embedded
configs back down to 100 :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Jon Loeliger @ 2005-08-26 20:55 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev@ozlabs.org
In-Reply-To: <20050806005941.5d1fe432.sfr@canb.auug.org.au>
On Fri, 2005-08-05 at 09:59, Stephen Rothwell wrote:
> > Another interesting point about it is which define to use. For s390, we
> > decided to '#ifdef __s390x__' rather than '#ifdef CONFIG_ARCH_S390X' or
> > 'ifdef CONFIG_64BIT', because CONFIG_* does not work when including the
> > headers from user space.
>
> Well noone should even include kernel headers from user space :-) and my
> understanding is that glibc "sanitizes" its version of the kernel headers
> anyway.
>
> > Using CONFIG_64BIT instead of __powerpc64__ only within #ifdef __KERNEL__
> > would be correct but less consistant.
>
> The advantage of using CONFIG_64BIT as much as possible is that it shows
> us places that can be consolidated across the various architectures
> (which is a bit of a passion of mine :-)). And more consolidation should
> make life easier for the glibc folks in the long run.
Hi guys,
Well, the time has come when I need an answer to this
question in order to make more progress on merging
some include files.
Anyone care to take a semi-authoritative stand on what
symbol to use to distinguish 32/64-bit-ness in the
include files?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-08-26 20:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0508261415080.29975@nylon.am.freescale.net>
On Aug 26, 2005, at 3:15 PM, Kumar Gala wrote:
> While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
> used. Connect it up and set all platforms to 250Hz. This pretty much
> mimics the ppc64 patch from Anton Blanchard.
Why do we keep cranking up this clock frequency? Do we really need
it running that fast? Is it time for someone with RTOS experience to
implement a real scheduled clock queue in Linux instead of just
wasting interrupts decrementing a counter waiting for the next
event to expire? :-) If the user "ticks" are still 100 Hz, don't we
need
something that is an integer multiple of that for at least an attempt
at getting it close to what a user would request?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc64: Add CONFIG_HZ
From: Kumar Gala @ 2005-08-26 19:23 UTC (permalink / raw)
To: Olof Johansson; +Cc: ppc64-dev, linuxppc-dev list
In-Reply-To: <20050826191450.GB6265@austin.ibm.com>
On Aug 26, 2005, at 2:14 PM, Olof Johansson wrote:
> On Fri, Aug 26, 2005 at 02:07:37PM -0500, Kumar Gala wrote:
>
>> What were you building for? I'm wondering if the same issue exists
>> that you are asked, but its not wired to actually do anything.
>>
>
> Doh, you're right. No, it's not wired up. I was building for pmac.
Ok, sent a patch to linuxppc-dev for ppc32 which mimic's Anton's
patch. Once we get an include/asm-powerpc going we can merge these
into on file that lives there.
- kumar
^ permalink raw reply
* [PATCH] ppc32: add CONFIG_HZ
From: Kumar Gala @ 2005-08-26 19:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
While ppc32 has the CONFIG_HZ Kconfig option, it wasnt actually being
used. Connect it up and set all platforms to 250Hz. This pretty much
mimics the ppc64 patch from Anton Blanchard.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit a7d81273171d49ac130f303eb63903298b4aeefb
tree a36b7872c98068519b9d85aa16e5f3f0b1668183
parent d90fa018552f3c3515ec46beadc0f0ff64c54547
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 26 Aug 2005 14:14:40 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 26 Aug 2005 14:14:40 -0500
include/asm-ppc/param.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/param.h b/include/asm-ppc/param.h
--- a/include/asm-ppc/param.h
+++ b/include/asm-ppc/param.h
@@ -1,8 +1,10 @@
#ifndef _ASM_PPC_PARAM_H
#define _ASM_PPC_PARAM_H
+#include <linux/config.h>
+
#ifdef __KERNEL__
-#define HZ 1000 /* internal timer frequency */
+#define HZ CONFIG_HZ /* internal timer frequency */
#define USER_HZ 100 /* for user interfaces in "ticks" */
#define CLOCKS_PER_SEC (USER_HZ) /* frequency at which times() counts */
#endif /* __KERNEL__ */
^ permalink raw reply
* Re: [PATCH] ppc64: Add CONFIG_HZ
From: Olof Johansson @ 2005-08-26 19:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, ppc64-dev, linuxppc-dev list
In-Reply-To: <28F4C8E9-FF41-4954-977D-546732D561B8@freescale.com>
On Fri, Aug 26, 2005 at 02:07:37PM -0500, Kumar Gala wrote:
> What were you building for? I'm wondering if the same issue exists
> that you are asked, but its not wired to actually do anything.
Doh, you're right. No, it's not wired up. I was building for pmac.
-Olof
^ permalink raw reply
* Re: [PATCH] ppc64: Add CONFIG_HZ
From: Kumar Gala @ 2005-08-26 19:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: Andrew Morton, ppc64-dev, linuxppc-dev list
In-Reply-To: <20050826190403.GA6265@austin.ibm.com>
What were you building for? I'm wondering if the same issue exists
that you are asked, but its not wired to actually do anything.
- kumar
On Aug 26, 2005, at 2:04 PM, Olof Johansson wrote:
> On Fri, Aug 26, 2005 at 02:00:43PM -0500, Kumar Gala wrote:
>
>> Any reason we shouldn't do the same thing on ppc32?
>>
>
> When I built a 2.6.13-rc7 I got the question about what HZ I wanted,
> so I guess we're already doing it. Maybe the default needs changing
> though, can't remember what it was.
>
>
> -Olof
>
^ permalink raw reply
* Re: [PATCH] ppc64: Add CONFIG_HZ
From: Olof Johansson @ 2005-08-26 19:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, ppc64-dev, linuxppc-dev list
In-Reply-To: <0192F2FD-0132-4B51-9524-590084E3FB0B@freescale.com>
On Fri, Aug 26, 2005 at 02:00:43PM -0500, Kumar Gala wrote:
> Any reason we shouldn't do the same thing on ppc32?
When I built a 2.6.13-rc7 I got the question about what HZ I wanted,
so I guess we're already doing it. Maybe the default needs changing
though, can't remember what it was.
-Olof
^ permalink raw reply
* Re: [PATCH] ppc64: Add CONFIG_HZ
From: Kumar Gala @ 2005-08-26 19:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, ppc64-dev, linuxppc-dev list
In-Reply-To: <20050823225303.GF31949@krispykreme>
Any reason we shouldn't do the same thing on ppc32?
- kumar
On Aug 23, 2005, at 5:53 PM, Anton Blanchard wrote:
>
> Hi,
>
> While ppc64 has the CONFIG_HZ Kconfig option, it wasnt actually being
> used. Connect it up and set all platforms to 250Hz.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
>
> Index: build/include/asm-ppc64/param.h
> ===================================================================
> --- build.orig/include/asm-ppc64/param.h 2005-08-15
> 23:42:07.000000000 +1000
> +++ build/include/asm-ppc64/param.h 2005-08-24 08:02:29.000000000
> +1000
> @@ -1,6 +1,8 @@
> #ifndef _ASM_PPC64_PARAM_H
> #define _ASM_PPC64_PARAM_H
>
> +#include <linux/config.h>
> +
> /*
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> @@ -9,7 +11,7 @@
> */
>
> #ifdef __KERNEL__
> -# define HZ 1000 /* Internal kernel timer
> frequency */
> +# define HZ CONFIG_HZ /* Internal kernel timer
> frequency */
> # define USER_HZ 100 /* .. some user interfaces are
> in "ticks" */
> # define CLOCKS_PER_SEC (USER_HZ) /* like times() */
> #endif
> Index: build/arch/ppc64/configs/g5_defconfig
> ===================================================================
> --- build.orig/arch/ppc64/configs/g5_defconfig 2005-08-15
> 23:42:04.000000000 +1000
> +++ build/arch/ppc64/configs/g5_defconfig 2005-08-24
> 07:55:50.000000000 +1000
> @@ -103,10 +103,10 @@
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_BKL is not set
> -CONFIG_HZ_100=y
> -# CONFIG_HZ_250 is not set
> +# CONFIG_HZ_100 is not set
> +CONFIG_HZ_250=y
> # CONFIG_HZ_1000 is not set
> -CONFIG_HZ=100
> +CONFIG_HZ=250
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_SECCOMP=y
> CONFIG_ISA_DMA_API=y
> Index: build/arch/ppc64/configs/iSeries_defconfig
> ===================================================================
> --- build.orig/arch/ppc64/configs/iSeries_defconfig 2005-08-15
> 23:42:04.000000000 +1000
> +++ build/arch/ppc64/configs/iSeries_defconfig 2005-08-24
> 07:56:46.000000000 +1000
> @@ -94,10 +94,10 @@
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_BKL is not set
> -CONFIG_HZ_100=y
> -# CONFIG_HZ_250 is not set
> +# CONFIG_HZ_100 is not set
> +CONFIG_HZ_250=y
> # CONFIG_HZ_1000 is not set
> -CONFIG_HZ=100
> +CONFIG_HZ=250
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_MSCHUNKS=y
> CONFIG_LPARCFG=y
> Index: build/arch/ppc64/configs/maple_defconfig
> ===================================================================
> --- build.orig/arch/ppc64/configs/maple_defconfig 2005-08-15
> 23:42:04.000000000 +1000
> +++ build/arch/ppc64/configs/maple_defconfig 2005-08-24
> 08:46:58.000000000 +1000
> @@ -103,10 +103,10 @@
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_BKL is not set
> -CONFIG_HZ_100=y
> -# CONFIG_HZ_250 is not set
> +# CONFIG_HZ_100 is not set
> +CONFIG_HZ_250=y
> # CONFIG_HZ_1000 is not set
> -CONFIG_HZ=100
> +CONFIG_HZ=250
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_SECCOMP=y
> CONFIG_ISA_DMA_API=y
> Index: build/arch/ppc64/configs/pSeries_defconfig
> ===================================================================
> --- build.orig/arch/ppc64/configs/pSeries_defconfig 2005-08-15
> 23:42:04.000000000 +1000
> +++ build/arch/ppc64/configs/pSeries_defconfig 2005-08-24
> 07:58:38.000000000 +1000
> @@ -112,10 +112,10 @@
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_BKL is not set
> -CONFIG_HZ_100=y
> -# CONFIG_HZ_250 is not set
> +# CONFIG_HZ_100 is not set
> +CONFIG_HZ_250=y
> # CONFIG_HZ_1000 is not set
> -CONFIG_HZ=100
> +CONFIG_HZ=250
> CONFIG_EEH=y
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_PPC_RTAS=y
> Index: build/arch/ppc64/defconfig
> ===================================================================
> --- build.orig/arch/ppc64/defconfig 2005-08-15 23:42:04.000000000
> +1000
> +++ build/arch/ppc64/defconfig 2005-08-24 07:55:27.000000000 +1000
> @@ -114,10 +114,10 @@
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> # CONFIG_PREEMPT_BKL is not set
> -CONFIG_HZ_100=y
> -# CONFIG_HZ_250 is not set
> +# CONFIG_HZ_100 is not set
> +CONFIG_HZ_250=y
> # CONFIG_HZ_1000 is not set
> -CONFIG_HZ=100
> +CONFIG_HZ=250
> CONFIG_EEH=y
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_PPC_RTAS=y
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
>
^ permalink raw reply
* [PATCH] ppc32: ppc_sys system on chip identification additions (updated)
From: Kumar Gala @ 2005-08-26 18:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Add the ability to identify an SOC by a name and id. There are cases in
which the integer identifier is not sufficient to specify a specific SOC.
In these cases we can use a string to further qualify the match.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 57c213c1a2e50b06fe69b63bc596cf7cbef9105e
tree 194c870fad7f29e7a97d787b0a895c7ed59b2f10
parent 4005c652e0887d29554a73ff661a2365ebb7691a
author Kumar K. Gala <kumar.gala@freescale.com> Fri, 26 Aug 2005 13:46:53 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Fri, 26 Aug 2005 13:46:53 -0500
arch/ppc/syslib/ppc_sys.c | 52 ++++++++++++++++++++++++++++++++++++++++++++-
include/asm-ppc/ppc_sys.h | 1 +
2 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -6,6 +6,7 @@
* Maintainer: Kumar Gala <kumar.gala@freescale.com>
*
* Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005 MontaVista, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -35,8 +36,57 @@ void __init identify_ppc_sys_by_id(u32 i
void __init identify_ppc_sys_by_name(char *name)
{
- /* TODO */
+ unsigned int i = 0;
+ while (ppc_sys_specs[i].ppc_sys_name[0])
+ {
+ if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+ break;
+ i++;
+ }
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
return;
+}
+
+static int __init count_sys_specs(void)
+{
+ int i = 0;
+ while (ppc_sys_specs[i].ppc_sys_name[0])
+ i++;
+ return i;
+}
+
+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+ int ret = -1;
+ unsigned int i = 0;
+ unsigned int j = 0;
+ unsigned int dups = 0;
+
+ unsigned char matched[count_sys_specs()];
+
+ while (ppc_sys_specs[i].ppc_sys_name[0]) {
+ if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+ matched[j++] = i;
+ i++;
+ }
+ if (j != 0) {
+ for (i = 0; i < j; i++) {
+ if ((ppc_sys_specs[matched[i]].mask & id) ==
+ ppc_sys_specs[matched[i]].value) {
+ ret = matched[i];
+ dups++;
+ }
+ }
+ ret = (dups == 1) ? ret : (-1 * dups);
+ }
+ return ret;
+}
+
+void __init identify_ppc_sys_by_name_and_id(char *name, u32 id)
+{
+ int i = find_chip_by_name_and_id(name, id);
+ BUG_ON(i < 0);
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
}
/* Update all memory resources by paddr, call before platform_device_register */
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -52,6 +52,7 @@ extern struct ppc_sys_spec *cur_ppc_sys_
/* determine which specific SOC we are */
extern void identify_ppc_sys_by_id(u32 id) __init;
extern void identify_ppc_sys_by_name(char *name) __init;
+extern void identify_ppc_sys_by_name_and_id(char *name, u32 id) __init;
/* describes all devices that may exist in a given family of processors */
extern struct platform_device ppc_sys_platform_devices[];
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys system on chip identification additions
From: Kumar Gala @ 2005-08-26 18:48 UTC (permalink / raw)
To: Gala Kumar K.-galak; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0508241017480.23831@nylon.am.freescale.net>
Oops, this patch doesn't build since its missing a '{'. Will send up
an updated patch that fixes the problem.
- kumar
On Aug 24, 2005, at 10:18 AM, Gala Kumar K.-galak wrote:
> Add the ability to identify an SOC by a name and id. There are
> cases in
> which the integer identifier is not sufficient to specify a specific
> SOC.
> In these cases we can use a string to further qualify the match.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> commit 58d478e75ac5d6cb3a1f738a22555c3841445264
> tree 999d1722d74eb8dc76f40c8f4c52966cea681cb4
> parent eb5d5922d749a74f58416ca1a852651e7323449b
> author Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005
> 10:14:42 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005
> 10:14:42 -0500
>
> arch/ppc/syslib/ppc_sys.c | 51
> ++++++++++++++++++++++++++++++++++++++++++++-
> include/asm-ppc/ppc_sys.h | 1 +
> 2 files changed, 51 insertions(+), 1 deletions(-)
>
> diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
> --- a/arch/ppc/syslib/ppc_sys.c
> +++ b/arch/ppc/syslib/ppc_sys.c
> @@ -6,6 +6,7 @@
> * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> *
> * Copyright 2005 Freescale Semiconductor Inc.
> + * Copyright 2005 MontaVista, Inc. by Vitaly Bordug
> <vbordug@ru.mvista.com>
> *
> * This program is free software; you can redistribute it and/or
> modify it
> * under the terms of the GNU General Public License as
> published by
> the
> @@ -35,8 +36,56 @@ void __init identify_ppc_sys_by_id(u32 i
>
> void __init identify_ppc_sys_by_name(char *name)
> {
> - /* TODO */
> + unsigned int i = 0;
> + while (ppc_sys_specs[i].ppc_sys_name[0])
> + if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
> + break;
> + i++;
> + }
> + cur_ppc_sys_spec = &ppc_sys_specs[i];
> return;
> +}
> +
> +static int __init count_sys_specs(void)
> +{
> + int i = 0;
> + while (ppc_sys_specs[i].ppc_sys_name[0])
> + i++;
> + return i;
> +}
> +
> +static int __init find_chip_by_name_and_id(char *name, u32 id)
> +{
> + int ret = -1;
> + unsigned int i = 0;
> + unsigned int j = 0;
> + unsigned int dups = 0;
> +
> + unsigned char matched[count_sys_specs()];
> +
> + while (ppc_sys_specs[i].ppc_sys_name[0]) {
> + if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
> + matched[j++] = i;
> + i++;
> + }
> + if (j != 0) {
> + for (i = 0; i < j; i++) {
> + if ((ppc_sys_specs[matched[i]].mask & id) ==
> + ppc_sys_specs[matched[i]].value) {
> + ret = matched[i];
> + dups++;
> + }
> + }
> + ret = (dups == 1) ? ret : (-1 * dups);
> + }
> + return ret;
> +}
> +
> +void __init identify_ppc_sys_by_name_and_id(char *name, u32 id)
> +{
> + int i = find_chip_by_name_and_id(name, id);
> + BUG_ON(i < 0);
> + cur_ppc_sys_spec = &ppc_sys_specs[i];
> }
>
> /* Update all memory resources by paddr, call before
> platform_device_register */
> diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
> --- a/include/asm-ppc/ppc_sys.h
> +++ b/include/asm-ppc/ppc_sys.h
> @@ -50,6 +50,7 @@ extern struct ppc_sys_spec *cur_ppc_sys_
> /* determine which specific SOC we are */
> extern void identify_ppc_sys_by_id(u32 id) __init;
> extern void identify_ppc_sys_by_name(char *name) __init;
> +extern void identify_ppc_sys_by_name_and_id(char *name, u32 id)
> __init;
>
> /* describes all devices that may exist in a given family of
> processors
> */
> extern struct platform_device ppc_sys_platform_devices[];
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ 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