* Re: [PATCH] fix ARCH=ppc timer_interrupt after global pt_regs
From: Kumar Gala @ 2006-10-16 20:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: Peter Korsgaard, paulus, linuxppc-dev
In-Reply-To: <0371C551-B535-4B95-81F3-8CC95C4FFC82@kernel.crashing.org>
On Oct 16, 2006, at 3:22 PM, Kumar Gala wrote:
>
> On Oct 16, 2006, at 3:18 PM, Peter Korsgaard wrote:
>
>>>>>>> "JB" == Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
>>
>> Hi,
>>
>> JB> Kumar Galak already fixed this on Oct 11 in the powerpc git tree.
>>
>> Ahh, I didn't notice.
>>
>> JB> Paul, could you send this fix to Linus soon please?
>>
>> Yes, please - I spend most of the morning tracking this down.
>
> Yeah, akpm picked up the patch for -mm.
Paul's got this in is powerpc.git tree now so it should go to Linus
on his next pull request.
- k
^ permalink raw reply
* Re: [PATCH] fix ARCH=ppc timer_interrupt after global pt_regs
From: Kumar Gala @ 2006-10-16 20:22 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, paulus
In-Reply-To: <87slhot3pe.fsf@sleipner.barco.com>
On Oct 16, 2006, at 3:18 PM, Peter Korsgaard wrote:
>>>>>> "JB" == Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
>
> Hi,
>
> JB> Kumar Galak already fixed this on Oct 11 in the powerpc git tree.
>
> Ahh, I didn't notice.
>
> JB> Paul, could you send this fix to Linus soon please?
>
> Yes, please - I spend most of the morning tracking this down.
Yeah, akpm picked up the patch for -mm.
- k
^ permalink raw reply
* Re: [PATCH] fix ARCH=ppc timer_interrupt after global pt_regs
From: Peter Korsgaard @ 2006-10-16 20:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1161029148.3172.19.camel@zod.rchland.ibm.com>
>>>>> "JB" == Josh Boyer <jwboyer@linux.vnet.ibm.com> writes:
Hi,
JB> Kumar Galak already fixed this on Oct 11 in the powerpc git tree.
Ahh, I didn't notice.
JB> Paul, could you send this fix to Linus soon please?
Yes, please - I spend most of the morning tracking this down.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] fix ARCH=ppc timer_interrupt after global pt_regs
From: Josh Boyer @ 2006-10-16 20:05 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, paulus
In-Reply-To: <871wp8ukh0.fsf@sleipner.barco.com>
On Mon, 2006-10-16 at 21:30 +0200, Peter Korsgaard wrote:
> Hi,
>
> 2.6.19-rc2 doesn't boot on arch/ppc (atleast of 4xx), because the
> 'global-pt_regs' megapatch forgot to fix up the arch/ppc
> timer_interrupt handler. This patch fixes it.
Kumar Galak already fixed this on Oct 11 in the powerpc git tree.
Paul, could you send this fix to Linus soon please?
josh
^ permalink raw reply
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: Peter Korsgaard @ 2006-10-16 19:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4532A1D1.4040006@dlasys.net>
>>>>> "David" == David H Lynch <dhlii@dlasys.net> writes:
Hi,
>> I'm still not convinced that DCR access and variable register
>> offsets are needed - But it can always be added (through a
>> seperate struct in platform_data) - Patches are welcome.
David> It does not matter whether you or I are convinced. It
David> matters whether there are people that need it. Xilinx has a
David> reference design that uses DCR. While I have never tripped
David> over an actual implimentation that uses DCR there are others
David> on this list that have.
Those people are welcome to add it then. Benh recently posted some
patches with a dcr abstraction that could probably make it pretty
clean to add. I don't have a DCR based design to do the implementation
and test, so it's pretty low on my priority list.
David> Right now I can not get your driver to work. I spent alot
David> of time trying to fix it and got nowhere. I can not get it to
David> receive at all, and I can not get it to send after switching
David> from the console driver without dropping characters. I am very
David> busy with other things right now and it is going to be a long
David> time before I have time to look at your driver again.
Sorry to hear. We are using it in several designs without problems and
it also worked for Oluf. I'm afraid I won't be able to help you
anymore unless you provide more details.
David> But what matters is not whether the changes are intrusive,
David> but whether they produce a better result.
Sorry, I don't agree. Maintainability is very important.
David> I am glad somebody is using your driver and finding it
David> works. But we are all better served by fixing the failure
David> cases.
Yes, please do or provide enough details for me to reproduce it.
David> It is not particularly odd at all. The UartLite despite
David> its simplicity is worse than a normal driver - different FPGA
David> implimentations can vary. Normal drivers for fixed inflexible
David> hardware often do not work accross differing implimentations,
David> why would you expect something like UartLite to be invariant ?
It's no worse than Xilinx 8250 core. There's only 1 implementation of
the uarlite IP core - Xilinx's.
David> I would also ask what data rates you and others with
David> Working UartLites are using ? The cases I am dealing with run
David> at 57600 and 115200 respectively - it is not that odd for
David> driver problems to manifest themselves only or more frequently
David> at high baud rates.
We're using 115200 for most designs, but one design is using it at
1mbit.
David> Without being difficult - don't hold your breath. It is
David> something I would like to do, but I do not have infinite time.
Ok.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: Peter Korsgaard @ 2006-10-16 19:49 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <4532A1D1.4040006@dlasys.net>
>>>>> "David" == David H Lynch <dhlii@dlasys.net> writes:
Hi,
>> I'm still not convinced that DCR access and variable register
>> offsets are needed - But it can always be added (through a
>> seperate struct in platform_data) - Patches are welcome.
David> It does not matter whether you or I are convinced. It
David> matters whether there are people that need it. Xilinx has a
David> reference design that uses DCR. While I have never tripped
David> over an actual implimentation that uses DCR there are others
David> on this list that have.
Those people are welcome to add it then. Benh recently posted some
patches with a dcr abstraction that could probably make it pretty
clean to add.
David> Right now I can not get your driver to work. I spent alot
David> of time trying to fix it and got nowhere. I can not get it to
David> receive at all, and I can not get it to send after switching
David> from the console driver without dropping characters. I am very
David> busy with other things right now and it is going to be a long
David> time before I have time to look at your driver again.
Sorry to hear. We are using it in several designs without problems and
it also worked for Oluf. I'm afraid I won't be able to help you
anymore unless you provide more details.
David> But what matters is not whether the changes are intrusive,
David> but whether they produce a better result.
Sorry, I don't agree. Maintainability is very important.
David> I am glad somebody is using your driver and finding it
David> works. But we are all better served by fixing the failure
David> cases.
Yes, please do or provide enough details for me to reproduce it.
David> It is not particularly odd at all. The UartLite despite
David> its simplicity is worse than a normal driver - different FPGA
David> implimentations can vary. Normal drivers for fixed inflexible
David> hardware often do not work accross differing implimentations,
David> why would you expect something like UartLite to be invariant ?
It's no worse than Xilinx 8250 core. There's only 1 implementation of
the uarlite IP core - Xilinx's.
David> I would also ask what data rates you and others with
David> Working UartLites are using ? The cases I am dealing with run
David> at 57600 and 115200 respectively - it is not that odd for
David> driver problems to manifest themselves only or more frequently
David> at high baud rates.
We're using 115200 for most designs, but one design is using it at
1mbit.
David> Without being difficult - don't hold your breath. It is
David> something I would like to do, but I do not have infinite time.
Ok.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] fix ARCH=ppc timer_interrupt after global pt_regs
From: Peter Korsgaard @ 2006-10-16 19:30 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi,
2.6.19-rc2 doesn't boot on arch/ppc (atleast of 4xx), because the
'global-pt_regs' megapatch forgot to fix up the arch/ppc
timer_interrupt handler. This patch fixes it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
diff -urpN linux-2.6.19-rc2.orig/arch/ppc/kernel/time.c linux-2.6.19-rc2/arch/ppc/kernel/time.c
--- linux-2.6.19-rc2.orig/arch/ppc/kernel/time.c 2006-10-16 21:05:52.000000000 +0200
+++ linux-2.6.19-rc2/arch/ppc/kernel/time.c 2006-10-16 21:12:42.000000000 +0200
@@ -56,6 +56,7 @@
#include <linux/time.h>
#include <linux/init.h>
#include <linux/profile.h>
+#include <linux/irq.h>
#include <asm/io.h>
#include <asm/nvram.h>
@@ -129,6 +130,7 @@ void wakeup_decrementer(void)
*/
void timer_interrupt(struct pt_regs * regs)
{
+ struct pt_regs *old_regs;
int next_dec;
unsigned long cpu = smp_processor_id();
unsigned jiffy_stamp = last_jiffy_stamp(cpu);
@@ -137,6 +139,7 @@ void timer_interrupt(struct pt_regs * re
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
+ old_regs = set_irq_regs(regs);
irq_enter();
while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) <= 0) {
@@ -188,6 +191,7 @@ void timer_interrupt(struct pt_regs * re
ppc_md.heartbeat();
irq_exit();
+ set_irq_regs(old_regs);
}
/*
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-16 19:25 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1161026409.31903.15.camel@farscape>
On Mon, 16 Oct 2006, Will Schmidt wrote:
> Node 1 MemTotal: 327680 kB
> Node 1 MemFree: 435704 kB
Too big.
> Node 1 MemUsed: 18446744073709443592 kB
Memused is going negative?
> Node 1 Active: 41412 kB
> Node 1 Inactive: 19976 kB
> Node 1 HighTotal: 0 kB
> Node 1 HighFree: 0 kB
> Node 1 LowTotal: 327680 kB
> Node 1 LowFree: 435704 kB
> Node 1 Dirty: 0 kB
> Node 1 Writeback: 0 kB
> Node 1 Mapped: 0 kB
> Node 1 Slab: 0 kB
zero slab??? That cannot be. The slab allocator always allocs on each
node. Or is this <2.6.18 with the strange counters that we had before?
> Node 0 MemTotal: 229376 kB
> Node 0 MemFree: 0 kB
> Node 0 MemUsed: 229376 kB
Node 0 is filled up during bootup?
^ permalink raw reply
* Re: Not know how to build image and user application from ELDK 4.0
From: Wolfgang Denk @ 2006-10-16 19:20 UTC (permalink / raw)
To: tran vanle; +Cc: linuxppc-embedded
In-Reply-To: <20061016142137.34580.qmail@web33007.mail.mud.yahoo.com>
In message <20061016142137.34580.qmail@web33007.mail.mud.yahoo.com> you wrote:
>
> I have just installed ELDK 4.0 for TQM 8xxL and read it README but I don't know how to build my custom image or adding user application.Such as I want to build ssh and openssh but I don't know where to start and how to do it step by step.
> Every one who HAD did it please guide me step by step to do it
I strongly recommend to read the extensive documentation that is
available at http://www.denx.de/wiki/view/DULG/Manual?stickboard=tqm8xxl
Also, I would like to point out that you should use ELDK 3.1.1 for
MPC8xx based systems like the TQM8xxL (that's the reason why the
TQM8xxL ships with ELDK 3.1.1 included on CDROM).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A Perl script is correct if it's halfway readable and gets the job
done before your boss fires you.
- L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-16 19:20 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610131515200.28279@schroedinger.engr.sgi.com>
Here is the content of /sys/devices/system/node/* and /proc/meminfo.
This is from the same partition, booted with a 2.6.16-ish distro
kernel.
notice that the node1/meminfo MemUsed value seems just a little bit
elevated. MemFree being larger than MemTotal seems a bit wrong too.
14:07:43 0 willschm@airbag2:~> find /sys/devices/system/node -type f
-print -exec cat {} \;
/sys/devices/system/node/node1/distance
20 10
/sys/devices/system/node/node1/numastat
numa_hit 6279
numa_miss 141588
numa_foreign 0
interleave_hit 5218
local_node 0
other_node 147867
/sys/devices/system/node/node1/meminfo
Node 1 MemTotal: 327680 kB
Node 1 MemFree: 435704 kB
Node 1 MemUsed: 18446744073709443592 kB
Node 1 Active: 41412 kB
Node 1 Inactive: 19976 kB
Node 1 HighTotal: 0 kB
Node 1 HighFree: 0 kB
Node 1 LowTotal: 327680 kB
Node 1 LowFree: 435704 kB
Node 1 Dirty: 0 kB
Node 1 Writeback: 0 kB
Node 1 Mapped: 0 kB
Node 1 Slab: 0 kB
Node 1 HugePages_Total: 0
Node 1 HugePages_Free: 0
/sys/devices/system/node/node1/cpumap
00000000,00000000,00000000,00000000
/sys/devices/system/node/node0/distance
10 20
/sys/devices/system/node/node0/numastat
numa_hit 0
numa_miss 0
numa_foreign 141749
interleave_hit 0
local_node 0
other_node 0
/sys/devices/system/node/node0/meminfo
Node 0 MemTotal: 229376 kB
Node 0 MemFree: 0 kB
Node 0 MemUsed: 229376 kB
Node 0 Active: 0 kB
Node 0 Inactive: 0 kB
Node 0 HighTotal: 0 kB
Node 0 HighFree: 0 kB
Node 0 LowTotal: 229376 kB
Node 0 LowFree: 0 kB
Node 0 Dirty: 8 kB
Node 0 Writeback: 0 kB
Node 0 Mapped: 33940 kB
Node 0 Slab: 25500 kB
Node 0 HugePages_Total: 0
Node 0 HugePages_Free: 0
/sys/devices/system/node/node0/cpumap
00000000,00000000,00000000,000000ff
---
14:07:45 0 willschm@airbag2:~> cat /proc/meminfo
MemTotal: 531628 kB
MemFree: 436000 kB
Buffers: 2880 kB
Cached: 35156 kB
SwapCached: 0 kB
Active: 41364 kB
Inactive: 19976 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 531628 kB
LowFree: 436000 kB
SwapTotal: 803240 kB
SwapFree: 803240 kB
Dirty: 0 kB
Writeback: 0 kB
Mapped: 33776 kB
Slab: 25332 kB
CommitLimit: 1069052 kB
Committed_AS: 81980 kB
PageTables: 1088 kB
VmallocTotal: 8589934592 kB
VmallocUsed: 2560 kB
VmallocChunk: 8589931608 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 16384 kB
^ permalink raw reply
* Re: Recently removed io accessors
From: Peter Korsgaard @ 2006-10-16 18:54 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, sfr
In-Reply-To: <20061016165140.GB6537@austin.ibm.com>
>>>>> "LV" == Linas Vepstas <linas@austin.ibm.com> writes:
Hi,
>> It doesn't have to be readw (16bit accesses). Enabling the BE mode
>> and using _outsl/_insl (32bit access with byteswap) works fine.
LV> I think Paul was trrying to say that it might be easier just to
LV> 16-bit words. Are you trying to use 32-bit access due to
LV> performance concerns?
Yes, this is the hot path of the driver as I don't have DMA hardware
(copy to/from packet buffer).
Another reason is that the same driver is used for the entire 911x
series, some which have an 16bit interface and others with full 32bit.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: RFC: qe lib code location?
From: Andy Fleming @ 2006-10-16 18:46 UTC (permalink / raw)
To: Dan Malek; +Cc: Li Yang, linuxppc-dev list, Kim Phillips
In-Reply-To: <713AF674-0689-4F20-9896-70696969ED24@embeddededge.com>
On Oct 3, 2006, at 12:30, Dan Malek wrote:
>
> On Oct 3, 2006, at 12:34 PM, Kumar Gala wrote:
>
>> I was wondering what peoples thought were on having the qe lib code
>> live in drivers/qe instead of sysdev/qe_lib (with the exception of
>> the interrupt controller code)
>
> My personal reason for choosing one place or the other
> is based upon usefulness to architectures other than PowerPC,
> or general kernel APIs that may change. If something is
> useful to architectures other than PowerPC, clearly it
> should go there. If the software has dependencies on
> general kernel APIs (networking is a good example), I like
> to put is there in hopes that someone changing the APIs
> will at least make an attempt to keep this code up to
> date as well.
>
> I think it neither of these apply (and I don't think the VM
> interfaces are a good argument because they generally
> affect the architecture ports anyway), then I think it
> should stay in a more architecture specific place.
My feeling here is that, all things being equal, drivers/ is better.
My reasoning is that, should Freescale decide to release a non-
powerpc chip with a QUICC Engine, having the code in drivers/ makes
this easier. It would also allow for some screwier implementations
(put an 8360 on a PCI card, and just use the QE directly from the
host processor). Of course, all of this is pure speculation, so if
there's a good reason *not* to put it in drivers/, we should probably
just maintain the status quo.
>
>
>> Yes, one can argue the cpm code should live in drivers/cpm by this
>> logic, but lets considered them grandfathered for now.
>
> I would say that based on my opinion above the cpm
> stuff should stay in sysdev, too. These are not only
> powerpc specific, but even Freescale embedded powerpc
> specific. I don't think that code belongs in drivers.
>
> Thanks.
>
> -- Dan
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Failed to boot kernel 2.6.19-rc2 due to IBM veth problem.
From: Yao Fei Zhu @ 2006-10-16 17:44 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20061016014334.GA30921@localhost.localdomain>
David Gibson 写道:
> On Mon, Oct 16, 2006 at 12:26:37AM +0800, Yao Fei Zhu wrote:
>
>>Hi, all,
>>
>>Boot kernel 2.6.19-rc2 on IBM System P5 partitions will fall into xmon.
>>Here is the boot log,
>
>
> This is probably the same bug I recently posted about. The patch
> below should fix it.
>
> ibmveth: Fix index increment calculation
>
> The recent commit 751ae21c6cd1493e3d0a4935b08fb298b9d89773 introduced
> a bug in the producer/consumer index calculation in the ibmveth driver
> - incautious use of the post-increment ++ operator resulted in an
> increment being immediately reverted. This patch corrects the logic.
>
> Without this patch, the driver oopses almost immediately after
> activation on at least some machines.
>
> Signed-off-by: David Gibson <dwg@au1.ibm.com>
>
> Index: working-2.6/drivers/net/ibmveth.c
> ===================================================================
> --- working-2.6.orig/drivers/net/ibmveth.c 2006-10-13 14:19:54.000000000 +1000
> +++ working-2.6/drivers/net/ibmveth.c 2006-10-13 14:19:59.000000000 +1000
> @@ -212,8 +212,8 @@ static void ibmveth_replenish_buffer_poo
> break;
> }
>
> - free_index = pool->consumer_index++ % pool->size;
> - pool->consumer_index = free_index;
> + free_index = pool->consumer_index;
> + pool->consumer_index = (pool->consumer_index + 1) % pool->size;
> index = pool->free_map[free_index];
>
> ibmveth_assert(index != IBM_VETH_INVALID_MAP);
> @@ -329,8 +329,10 @@ static void ibmveth_remove_buffer_from_p
> adapter->rx_buff_pool[pool].buff_size,
> DMA_FROM_DEVICE);
>
> - free_index = adapter->rx_buff_pool[pool].producer_index++ % adapter->rx_buff_pool[pool].size;
> - adapter->rx_buff_pool[pool].producer_index = free_index;
> + free_index = adapter->rx_buff_pool[pool].producer_index;
> + adapter->rx_buff_pool[pool].producer_index
> + = (adapter->rx_buff_pool[pool].producer_index + 1)
> + % adapter->rx_buff_pool[pool].size;
> adapter->rx_buff_pool[pool].free_map[free_index] = index;
>
> mb();
>
>
David, I have verified this fix, it works fine for me, Thanks. What's the status of it? Submitted?
^ permalink raw reply
* Re: Recently removed io accessors
From: Linas Vepstas @ 2006-10-16 16:51 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, Paul Mackerras, sfr
In-Reply-To: <8764ent8j4.fsf@sleipner.barco.com>
On Sat, Oct 14, 2006 at 01:57:03PM +0200, Peter Korsgaard wrote:
> PM> code up a loop of readw (or equivalent) in the driver with a big
> PM> comment explaining why you need to do it that way.
>
> It doesn't have to be readw (16bit accesses). Enabling the BE mode and
> using _outsl/_insl (32bit access with byteswap) works fine.
I think Paul was trrying to say that it might be easier just to
16-bit words. Are you trying to use 32-bit access due to performance
concerns?
--linas
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-16 16:00 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610131515200.28279@schroedinger.engr.sgi.com>
On Fri, 2006-13-10 at 15:22 -0700, Christoph Lameter wrote:
> Here is another fall back fix checking if the slab has already been setup
> for this node. MPOL_INTERLEAVE could redirect the allocation.
>
with this patch applied, a different error in the same area..
freeing bootmem node 0
freeing bootmem node 1
Memory: 530256k/557056k available (5508k kernel code, 30468k reserved,
2224k data, 543k bss, 244k init)
Kernel panic - not syncing: kmem_cache_create(): failed to create slab
`size-32'
> Index: linux-2.6.19-rc1-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.19-rc1-mm1.orig/mm/slab.c 2006-10-10 21:47:12.949563383 -0500
> +++ linux-2.6.19-rc1-mm1/mm/slab.c 2006-10-13 17:21:31.937863714 -0500
> @@ -3158,12 +3158,15 @@ void *fallback_alloc(struct kmem_cache *
> struct zone **z;
> void *obj = NULL;
>
> - for (z = zonelist->zones; *z && !obj; z++)
> + for (z = zonelist->zones; *z && !obj; z++) {
> + int nid = zone_to_nid(*z);
> +
> if (zone_idx(*z) <= ZONE_NORMAL &&
> - cpuset_zone_allowed(*z, flags))
> + cpuset_zone_allowed(*z, flags) &&
> + cache->nodelists[nid])
> obj = __cache_alloc_node(cache,
> - flags | __GFP_THISNODE,
> - zone_to_nid(*z));
> + flags | __GFP_THISNODE, nid);
> + }
> return obj;
> }
>
>
^ permalink raw reply
* Not know how to build image and user application from ELDK 4.0
From: tran vanle @ 2006-10-16 14:21 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
Hi every one
I have just installed ELDK 4.0 for TQM 8xxL and read it README but I don't know how to build my custom image or adding user application.Such as I want to build ssh and openssh but I don't know where to start and how to do it step by step.
Every one who HAD did it please guide me step by step to do it
Thanks for all
---------------------------------
On Yahoo!7
PS Trixi: Check back weekly for Trixi's latest update
[-- Attachment #2: Type: text/html, Size: 547 bytes --]
^ permalink raw reply
* RE: preempt crash in 2.6.18
From: Rune Torgersen @ 2006-10-16 13:50 UTC (permalink / raw)
To: Vitaly Bordug, Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20061015132058.01c68605@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
-----Original Message-----
From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
On Sat, 14 Oct 2006 09:14:38 +1000
Benjamin Herrenschmidt wrote:
> On Sat, 2006-10-14 at 01:21 +0400, Vitaly Bordug wrote:
> > On Fri, 13 Oct 2006 09:16:52 -0500
> > Rune Torgersen wrote:
> >
> > >
> > > This is from a Freescale 8265 running 2.6.18
> > > Anyone have any idea what this is and how to fix it?
> > >
> > Yes. Actually, I recall alike thing and used to fix with proper
> > spin-locking if the cascade PCI irq, which apparently does do_irq
> > that seems to confuse preempt counters.
> >
> > Just a pure guess.
>
> How so ? Cascades shouldn't do do_IRQ with the new irq code anyway
> unless this is still arch/ppc, they should do either __do_IRQ or
> better, generic_handle_irq().
>
To clarify - I was about __do_IRQ and arch/ppc.
Anyway, cascade for PCI is the first place I'd give a look.
In our case it turned out to be in the TIPC network code. post_timeout was called and didn't unlock a lock.
The patch had been in the TIPC tree for abpout 2 days when we saw the problem.
--
Sincerely,
-Vitaly
[-- Attachment #2: Type: text/html, Size: 1792 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] powerpc: Add flatdevtree source
From: Paul Mackerras @ 2006-10-16 10:46 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20061012013427.GC9143@mag.az.mvista.com>
Mark A. Greer writes:
> Add the latest version of the flatdevtree code and corresponding glue.
Please resend with the fixes you posted subsequently applied. Same
for your patch 4/4.
Paul.
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: More bootwrapper reorg
From: Paul Mackerras @ 2006-10-16 10:45 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20061012013346.GB9143@mag.az.mvista.com>
Mark A. Greer writes:
> More reorganization of the bootwrapper:
> - Add dtb section to zImage
Unfortunately it doesn't build for powermac because zImage.coff.lds is
missing the _dtb_start/end symbols. Could you add the necessary bits
to zImage.coff.lds and resend?
Paul.
^ permalink raw reply
* pci-usb card problem
From: tony @ 2006-10-16 9:51 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 3513 bytes --]
hi,all
I got a pci to usb card problem this days.
env: linux-2.6.17,ppc405ep,bubinga board
problem:
during boot time,an error show up like this
Scanning device for bad blocks
Creating 1 MTD partitions on "NAND 8MiB 1,8V 8-bit":
0x00000000-0x00800000 : "NAND simulator partition"
ehci_hcd 0000:00:02.2: EHCI Host Controller
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.2: irq 29, io mem 0xbfffff00
ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.17-rc3 ehci_hcd
usb usb1: SerialNumber: 0000:00:02.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
USB Universal Host Controller Interface driver v3.0
uhci_hcd 0000:00:02.0: UHCI Host Controller
uhci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:02.0: detected 2 ports
uhci_hcd 0000:00:02.0: irq 29, io base 0x0000ffe0
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.17-rc3 uhci_hcd
usb usb2: SerialNumber: 0000:00:02.0
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:02.1: UHCI Host Controller
uhci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:02.1: detected 2 ports
uhci_hcd 0000:00:02.1: irq 29, io base 0x0000ffc0
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.17-rc3 uhci_hcd
usb usb3: SerialNumber: 0000:00:02.1
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 1-3: new high speed USB device using ehci_hcd and address 2
usb 1-3: configuration #1 chosen from 1 choice
ub(1.2): GetMaxLUN returned 0, using 1 LUNs
Oops: kernel access of bad area, sig: 11 [#1]
NIP: 00000000 LR: C0170314 CTR: 00000000
REGS: c030bd40 TRAP: 0400 Not tainted (2.6.17-rc3)
MSR: 00021030 <ME,IR,DR> CR: 42004024 XER: 20000000
TASK = c02c78f8[0] 'swapper' THREAD: c030a000
GPR00: 00000000 C030BDF0 C02C78F8 C75CE800 C75D0A00 00000000 00000008 00000008
GPR08: 00000001 00000000 C75D0A00 C75CE854 22004082 00000000 07FF7F00 00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 07FF2B4C 00000000 C75CE9D4 C016F5C0
GPR24: 00029030 00000000 C75CE960 C75CE9F4 C75CE978 C0330000 00000000 C75CE800
Call Trace:
[C030BDF0] [C0330000] (unreliable)
[C030BE10] [C01704C8]
[C030BE40] [C001F734]
[C030BE60] [C001F908]
[C030BE90] [C0007CC0]
[C030BEA0] [C001F638]
[C030BEB0] [C0007C1C]
[C030BED0] [C00032F8]
[C030BF90] [C000A6B0]
[C030BFB0] [C0002358]
[C030BFC0] [C030C694]
[C030BFF0] [C0002254]
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 1 seconds..
rarely,it can boot successfully,shows:
Initializing USB Mass Storage driver...
usb 1-3: new high speed USB device using ehci_hcd and address 2
usb 1-3: Product: USBFlash
usb 1-3: Manufacturer: Generic
usb 1-3: configuration #1 chosen from 1 choice
ub(1.2): Unable to submit GetMaxLUN (-22)
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
TCP bic registered
I have tried to configure kernel many times...but the problem still exists....
any advise is appreciated.
tony
[-- Attachment #2: Type: text/html, Size: 4348 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: New DCR access methods
From: Benjamin Herrenschmidt @ 2006-10-16 8:21 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev list, cbe-oss-dev@ozlabs.org
In-Reply-To: <20061016081748.GA11677@lst.de>
> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > +#include <asm/dcr-native.h>
> > +#else
> > +#include <asm/dcr-mmio.h>
> > +#endif
>
> Having this as a compile-time switch seems broken. I thought the plan was
> to support all different 64bit kernels with a single kernel binary?
"native" DCRs only exist in 32 bits 4xx / BookE processors as of today.
Basically, those processors have mtdcr and mfdcr instructions to access
those special "registers". They are in fact connected to a bus to
control various IOs. On AXON (and possibly other future chips), since
the host processor doesn't have those instructions, they are memory
mapped.
There is currently no way you can have both in the same kernel. If that
ever happens, then the "mmio" version could easily be tweaked to deal
with both. However, the "native only" implementation is useful for
embedded 4xx etc... as it resolves directly to mfdcr/mtdcr instructions,
dcr_map is an empty macro, etc... thus there is 0 overhead of switching
4xx code to the new dcr accessors.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: New DCR access methods
From: Christoph Hellwig @ 2006-10-16 8:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, cbe-oss-dev@ozlabs.org
In-Reply-To: <1160984698.22522.60.camel@localhost.localdomain>
On Mon, Oct 16, 2006 at 05:44:58PM +1000, Benjamin Herrenschmidt wrote:
> This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that
> can be used by drivers to transparently address either native DCRs or
> memory mapped DCRs. The implementation for memory mapped DCRs is done
> after the binding being currently worked on for SLOF and the Axon
> chipset. This patch enables it for the cell native platform
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-cell/include/asm-powerpc/dcr.h
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-cell/include/asm-powerpc/dcr.h 2006-10-16 16:42:32.000000000 +1000
> @@ -0,0 +1,42 @@
> +/*
> + * (c) Copyright 2006 Benjamin Herrenschmidt, IBM Corp.
> + * <benh@kernel.crashing.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> + * the GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef _ASM_POWERPC_DCR_H
> +#define _ASM_POWERPC_DCR_H
> +#ifdef __KERNEL__
> +
> +#ifdef CONFIG_PPC_DCR_NATIVE
> +#include <asm/dcr-native.h>
> +#else
> +#include <asm/dcr-mmio.h>
> +#endif
Having this as a compile-time switch seems broken. I thought the plan was
to support all different 64bit kernels with a single kernel binary?
^ permalink raw reply
* [PATCH] powerpc: Support for MPIC on native cell
From: Benjamin Herrenschmidt @ 2006-10-16 7:45 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: cbe-oss-dev@ozlabs.org
Add support for southbridges using the MPIC interrupt controller to
the native cell platforms.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-cell/arch/powerpc/Kconfig
===================================================================
--- linux-cell.orig/arch/powerpc/Kconfig 2006-10-16 14:48:22.000000000 +1000
+++ linux-cell/arch/powerpc/Kconfig 2006-10-16 14:48:27.000000000 +1000
@@ -461,6 +461,7 @@ config PPC_CELL_NATIVE
bool
select PPC_CELL
select PPC_DCR_MMIO
+ select MPIC
default n
config PPC_IBM_CELL_BLADE
Index: linux-cell/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-cell.orig/arch/powerpc/platforms/cell/setup.c 2006-10-16 14:46:50.000000000 +1000
+++ linux-cell/arch/powerpc/platforms/cell/setup.c 2006-10-16 14:48:27.000000000 +1000
@@ -50,6 +50,7 @@
#include <asm/spu.h>
#include <asm/spu_priv1.h>
#include <asm/udbg.h>
+#include <asm/mpic.h>
#include "interrupt.h"
#include "iommu.h"
@@ -88,10 +89,53 @@ static void __init cell_pcibios_fixup(vo
pci_read_irq_line(dev);
}
+static void cell_mpic_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct mpic *mpic = desc->handler_data;
+ unsigned int virq;
+
+ virq = mpic_get_one_irq(mpic);
+ if (virq != NO_IRQ)
+ generic_handle_irq(virq);
+ desc->chip->eoi(irq);
+}
+
+static void __init mpic_init_IRQ(void)
+{
+ struct device_node *dn;
+ struct mpic *mpic;
+ unsigned int virq;
+
+ for (dn = NULL;
+ (dn = of_find_node_by_name(dn, "interrupt-controller"));) {
+ if (!device_is_compatible(dn, "CBEA,platform-open-pic"))
+ continue;
+
+ /* The MPIC driver will get everything it needs from the
+ * device-tree, just pass 0 to all arguments
+ */
+ mpic = mpic_alloc(dn, 0, 0, 0, 0, " MPIC ");
+ if (mpic == NULL)
+ continue;
+ mpic_init(mpic);
+
+ virq = irq_of_parse_and_map(dn, 0);
+ if (virq == NO_IRQ)
+ continue;
+
+ printk(KERN_INFO "%s : hooking up to IRQ %d\n",
+ dn->full_name, virq);
+ set_irq_data(virq, mpic);
+ set_irq_chained_handler(virq, cell_mpic_cascade);
+ }
+}
+
+
static void __init cell_init_irq(void)
{
iic_init_IRQ();
spider_init_IRQ();
+ mpic_init_IRQ();
}
static void __init cell_setup_arch(void)
^ permalink raw reply
* [PATCH] powerpc: MPIC init get address from device-tree
From: Benjamin Herrenschmidt @ 2006-10-16 7:45 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: cbe-oss-dev@ozlabs.org
This patch applies on top of the MPIC DCR support. It makes the MPIC
driver capable of a lot more auto-configuration based on the device-tree,
for example, it can retreive it's own physical address if not passed as
an argument, find out if it's DCR or MMIO mapped, and set the BIG_ENDIAN
flag automatically in the presence of a "big-endian" property in the
device-tree node.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-cell/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-cell.orig/arch/powerpc/sysdev/mpic.c 2006-10-16 17:29:50.000000000 +1000
+++ linux-cell/arch/powerpc/sysdev/mpic.c 2006-10-16 17:29:57.000000000 +1000
@@ -943,6 +943,11 @@ struct mpic * __init mpic_alloc(struct d
mpic->irq_count = irq_count;
mpic->num_sources = 0; /* so far */
+ /* Check for "big-endian" in device-tree */
+ if (node && get_property(node, "big-endian", NULL) != NULL)
+ mpic->flags |= MPIC_BIG_ENDIAN;
+
+
#ifdef CONFIG_MPIC_WEIRD
mpic->hw_set = mpic_infos[MPIC_GET_REGSET(flags)];
#endif
@@ -951,11 +956,17 @@ struct mpic * __init mpic_alloc(struct d
mpic->reg_type = (flags & MPIC_BIG_ENDIAN) ?
mpic_access_mmio_be : mpic_access_mmio_le;
+ /* If no physical address is passed in, a device-node is mandatory */
+ BUG_ON(phys_addr == 0 && node == NULL);
+
+ /* If no physical address passed in, check if it's dcr based */
+ if (phys_addr == 0 && get_property(node, "dcr-reg", NULL) != NULL)
+ mpic->flags |= MPIC_USES_DCR;
+
#ifdef CONFIG_PPC_DCR
if (mpic->flags & MPIC_USES_DCR) {
const u32 *dbasep;
- BUG_ON(mpic->of_node == NULL);
- dbasep = get_property(mpic->of_node, "dcr-reg", NULL);
+ dbasep = get_property(node, "dcr-reg", NULL);
BUG_ON(dbasep == NULL);
mpic->dcr_base = *dbasep;
mpic->reg_type = mpic_access_dcr;
@@ -964,6 +975,17 @@ struct mpic * __init mpic_alloc(struct d
BUG_ON (mpic->flags & MPIC_USES_DCR);
#endif /* CONFIG_PPC_DCR */
+ /* If the MPIC is not DCR based, and no physical address was passed
+ * in, try to obtain one
+ */
+ if (phys_addr == 0 && !(mpic->flags & MPIC_USES_DCR)) {
+ const u32 *reg;
+ reg = get_property(node, "reg", NULL);
+ BUG_ON(reg == NULL);
+ phys_addr = of_translate_address(node, reg);
+ BUG_ON(phys_addr == OF_BAD_ADDR);
+ }
+
/* Map the global registers */
mpic_map(mpic, phys_addr, &mpic->gregs, MPIC_INFO(GREG_BASE), 0x1000);
mpic_map(mpic, phys_addr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
^ permalink raw reply
* [PATCH] powerpc: Support for DCR based MPIC
From: Benjamin Herrenschmidt @ 2006-10-16 7:45 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: cbe-oss-dev@ozlabs.org
This patch implements support for DCR based MPIC implementations. Such
implementations have the MPIC_USES_DCR flag set and don't use the phys_addr
argument of mpic_alloc (they require a valid dcr mapping in the device node)
This version of the patch can use a little bif of cleanup still (I can
probably consolidate rb->dbase/doff, at least once I'm sure on how the
hardware is actually supposed to work vs. possible simulator issues) and
it should be possible to build a DCR-only version of the driver. I need
to cleanup a bit the CONFIG_* handling for that and probably introduce
CONFIG_MPIC_MMIO and CONFIG_MPIC_DCR.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-cell/arch/powerpc/sysdev/mpic.c
===================================================================
--- linux-cell.orig/arch/powerpc/sysdev/mpic.c 2006-10-16 17:20:39.000000000 +1000
+++ linux-cell/arch/powerpc/sysdev/mpic.c 2006-10-16 17:29:50.000000000 +1000
@@ -147,33 +147,51 @@ static u32 mpic_infos[][MPIC_IDX_END] =
*/
-static inline u32 _mpic_read(unsigned int be, volatile u32 __iomem *base,
- unsigned int reg)
-{
- if (be)
- return in_be32(base + (reg >> 2));
- else
- return in_le32(base + (reg >> 2));
+static inline u32 _mpic_read(enum mpic_reg_type type,
+ struct mpic_reg_bank *rb,
+ unsigned int reg)
+{
+ switch(type) {
+#ifdef CONFIG_PPC_DCR
+ case mpic_access_dcr:
+ return dcr_read(rb->dhost,
+ rb->dbase + reg + rb->doff);
+#endif
+ case mpic_access_mmio_be:
+ return in_be32(rb->base + (reg >> 2));
+ case mpic_access_mmio_le:
+ default:
+ return in_le32(rb->base + (reg >> 2));
+ }
}
-static inline void _mpic_write(unsigned int be, volatile u32 __iomem *base,
- unsigned int reg, u32 value)
+static inline void _mpic_write(enum mpic_reg_type type,
+ struct mpic_reg_bank *rb,
+ unsigned int reg, u32 value)
{
- if (be)
- out_be32(base + (reg >> 2), value);
- else
- out_le32(base + (reg >> 2), value);
+ switch(type) {
+#ifdef CONFIG_PPC_DCR
+ case mpic_access_dcr:
+ return dcr_write(rb->dhost,
+ rb->dbase + reg + rb->doff, value);
+#endif
+ case mpic_access_mmio_be:
+ return out_be32(rb->base + (reg >> 2), value);
+ case mpic_access_mmio_le:
+ default:
+ return out_le32(rb->base + (reg >> 2), value);
+ }
}
static inline u32 _mpic_ipi_read(struct mpic *mpic, unsigned int ipi)
{
- unsigned int be = (mpic->flags & MPIC_BIG_ENDIAN) != 0;
+ enum mpic_reg_type type = mpic->reg_type;
unsigned int offset = MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
(ipi * MPIC_INFO(GREG_IPI_STRIDE));
- if (mpic->flags & MPIC_BROKEN_IPI)
- be = !be;
- return _mpic_read(be, mpic->gregs, offset);
+ if ((mpic->flags & MPIC_BROKEN_IPI) && type == mpic_access_mmio_le)
+ type = mpic_access_mmio_be;
+ return _mpic_read(type, &mpic->gregs, offset);
}
static inline void _mpic_ipi_write(struct mpic *mpic, unsigned int ipi, u32 value)
@@ -181,7 +199,7 @@ static inline void _mpic_ipi_write(struc
unsigned int offset = MPIC_INFO(GREG_IPI_VECTOR_PRI_0) +
(ipi * MPIC_INFO(GREG_IPI_STRIDE));
- _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->gregs, offset, value);
+ _mpic_write(mpic->reg_type, &mpic->gregs, offset, value);
}
static inline u32 _mpic_cpu_read(struct mpic *mpic, unsigned int reg)
@@ -190,8 +208,7 @@ static inline u32 _mpic_cpu_read(struct
if (mpic->flags & MPIC_PRIMARY)
cpu = hard_smp_processor_id();
- return _mpic_read(mpic->flags & MPIC_BIG_ENDIAN,
- mpic->cpuregs[cpu], reg);
+ return _mpic_read(mpic->reg_type, &mpic->cpuregs[cpu], reg);
}
static inline void _mpic_cpu_write(struct mpic *mpic, unsigned int reg, u32 value)
@@ -201,7 +218,7 @@ static inline void _mpic_cpu_write(struc
if (mpic->flags & MPIC_PRIMARY)
cpu = hard_smp_processor_id();
- _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->cpuregs[cpu], reg, value);
+ _mpic_write(mpic->reg_type, &mpic->cpuregs[cpu], reg, value);
}
static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, unsigned int reg)
@@ -209,7 +226,7 @@ static inline u32 _mpic_irq_read(struct
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- return _mpic_read(mpic->flags & MPIC_BIG_ENDIAN, mpic->isus[isu],
+ return _mpic_read(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
@@ -219,12 +236,12 @@ static inline void _mpic_irq_write(struc
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- _mpic_write(mpic->flags & MPIC_BIG_ENDIAN, mpic->isus[isu],
+ _mpic_write(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
}
-#define mpic_read(b,r) _mpic_read(mpic->flags & MPIC_BIG_ENDIAN,(b),(r))
-#define mpic_write(b,r,v) _mpic_write(mpic->flags & MPIC_BIG_ENDIAN,(b),(r),(v))
+#define mpic_read(b,r) _mpic_read(mpic->reg_type,&(b),(r))
+#define mpic_write(b,r,v) _mpic_write(mpic->reg_type,&(b),(r),(v))
#define mpic_ipi_read(i) _mpic_ipi_read(mpic,(i))
#define mpic_ipi_write(i,v) _mpic_ipi_write(mpic,(i),(v))
#define mpic_cpu_read(i) _mpic_cpu_read(mpic,(i))
@@ -238,6 +255,38 @@ static inline void _mpic_irq_write(struc
*/
+static void _mpic_map_mmio(struct mpic *mpic, unsigned long phys_addr,
+ struct mpic_reg_bank *rb, unsigned int offset,
+ unsigned int size)
+{
+ rb->base = ioremap(phys_addr + offset, size);
+ BUG_ON(rb->base == NULL);
+}
+
+#ifdef CONFIG_PPC_DCR
+static void _mpic_map_dcr(struct mpic *mpic, struct mpic_reg_bank *rb,
+ unsigned int offset, unsigned int size)
+{
+ rb->dbase = mpic->dcr_base;
+ rb->doff = offset;
+ rb->dhost = dcr_map(mpic->of_node, rb->dbase + rb->doff, size);
+ BUG_ON(!DCR_MAP_OK(rb->dhost));
+}
+
+static inline void mpic_map(struct mpic *mpic, unsigned long phys_addr,
+ struct mpic_reg_bank *rb, unsigned int offset,
+ unsigned int size)
+{
+ if (mpic->flags & MPIC_USES_DCR)
+ _mpic_map_dcr(mpic, rb, offset, size);
+ else
+ _mpic_map_mmio(mpic, phys_addr, rb, offset, size);
+}
+#else /* CONFIG_PPC_DCR */
+#define mpic_map(m,p,b,o,s) _mpic_map_mmio(m,p,b,o,s)
+#endif /* !CONFIG_PPC_DCR */
+
+
/* Check if we have one of those nice broken MPICs with a flipped endian on
* reads from IPI registers
@@ -883,6 +932,7 @@ struct mpic * __init mpic_alloc(struct d
if (flags & MPIC_PRIMARY)
mpic->hc_ht_irq.set_affinity = mpic_set_affinity;
#endif /* CONFIG_MPIC_BROKEN_U3 */
+
#ifdef CONFIG_SMP
mpic->hc_ipi = mpic_ipi_chip;
mpic->hc_ipi.typename = name;
@@ -897,11 +947,26 @@ struct mpic * __init mpic_alloc(struct d
mpic->hw_set = mpic_infos[MPIC_GET_REGSET(flags)];
#endif
+ /* default register type */
+ mpic->reg_type = (flags & MPIC_BIG_ENDIAN) ?
+ mpic_access_mmio_be : mpic_access_mmio_le;
+
+#ifdef CONFIG_PPC_DCR
+ if (mpic->flags & MPIC_USES_DCR) {
+ const u32 *dbasep;
+ BUG_ON(mpic->of_node == NULL);
+ dbasep = get_property(mpic->of_node, "dcr-reg", NULL);
+ BUG_ON(dbasep == NULL);
+ mpic->dcr_base = *dbasep;
+ mpic->reg_type = mpic_access_dcr;
+ }
+#else
+ BUG_ON (mpic->flags & MPIC_USES_DCR);
+#endif /* CONFIG_PPC_DCR */
+
/* Map the global registers */
- mpic->gregs = ioremap(phys_addr + MPIC_INFO(GREG_BASE), 0x1000);
- mpic->tmregs = mpic->gregs +
- ((MPIC_INFO(TIMER_BASE) - MPIC_INFO(GREG_BASE)) >> 2);
- BUG_ON(mpic->gregs == NULL);
+ mpic_map(mpic, phys_addr, &mpic->gregs, MPIC_INFO(GREG_BASE), 0x1000);
+ mpic_map(mpic, phys_addr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
/* Reset */
if (flags & MPIC_WANTS_RESET) {
@@ -926,17 +991,16 @@ struct mpic * __init mpic_alloc(struct d
/* Map the per-CPU registers */
for (i = 0; i < mpic->num_cpus; i++) {
- mpic->cpuregs[i] = ioremap(phys_addr + MPIC_INFO(CPU_BASE) +
- i * MPIC_INFO(CPU_STRIDE), 0x1000);
- BUG_ON(mpic->cpuregs[i] == NULL);
+ mpic_map(mpic, phys_addr, &mpic->cpuregs[i],
+ MPIC_INFO(CPU_BASE) + i * MPIC_INFO(CPU_STRIDE),
+ 0x1000);
}
/* Initialize main ISU if none provided */
if (mpic->isu_size == 0) {
mpic->isu_size = mpic->num_sources;
- mpic->isus[0] = ioremap(phys_addr + MPIC_INFO(IRQ_BASE),
- MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
- BUG_ON(mpic->isus[0] == NULL);
+ mpic_map(mpic, phys_addr, &mpic->isus[0],
+ MPIC_INFO(IRQ_BASE), MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
}
mpic->isu_shift = 1 + __ilog2(mpic->isu_size - 1);
mpic->isu_mask = (1 << mpic->isu_shift) - 1;
@@ -979,8 +1043,8 @@ void __init mpic_assign_isu(struct mpic
BUG_ON(isu_num >= MPIC_MAX_ISU);
- mpic->isus[isu_num] = ioremap(phys_addr,
- MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
+ mpic_map(mpic, phys_addr, &mpic->isus[isu_num], 0,
+ MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
if ((isu_first + mpic->isu_size) > mpic->num_sources)
mpic->num_sources = isu_first + mpic->isu_size;
}
Index: linux-cell/include/asm-powerpc/mpic.h
===================================================================
--- linux-cell.orig/include/asm-powerpc/mpic.h 2006-10-16 17:20:39.000000000 +1000
+++ linux-cell/include/asm-powerpc/mpic.h 2006-10-16 17:26:46.000000000 +1000
@@ -3,6 +3,7 @@
#ifdef __KERNEL__
#include <linux/irq.h>
+#include <asm/dcr.h>
/*
* Global registers
@@ -225,6 +226,23 @@ struct mpic_irq_fixup
#endif /* CONFIG_MPIC_BROKEN_U3 */
+enum mpic_reg_type {
+ mpic_access_mmio_le,
+ mpic_access_mmio_be,
+#ifdef CONFIG_PPC_DCR
+ mpic_access_dcr
+#endif
+};
+
+struct mpic_reg_bank {
+ u32 __iomem *base;
+#ifdef CONFIG_PPC_DCR
+ dcr_host_t dhost;
+ unsigned int dbase;
+ unsigned int doff;
+#endif /* CONFIG_PPC_DCR */
+};
+
/* The instance data of a given MPIC */
struct mpic
{
@@ -264,11 +282,18 @@ struct mpic
spinlock_t fixup_lock;
#endif
+ /* Register access method */
+ enum mpic_reg_type reg_type;
+
/* The various ioremap'ed bases */
- volatile u32 __iomem *gregs;
- volatile u32 __iomem *tmregs;
- volatile u32 __iomem *cpuregs[MPIC_MAX_CPUS];
- volatile u32 __iomem *isus[MPIC_MAX_ISU];
+ struct mpic_reg_bank gregs;
+ struct mpic_reg_bank tmregs;
+ struct mpic_reg_bank cpuregs[MPIC_MAX_CPUS];
+ struct mpic_reg_bank isus[MPIC_MAX_ISU];
+
+#ifdef CONFIG_PPC_DCR
+ unsigned int dcr_base;
+#endif
#ifdef CONFIG_MPIC_WEIRD
/* Pointer to HW info array */
@@ -305,6 +330,8 @@ struct mpic
#define MPIC_SPV_EOI 0x00000020
/* No passthrough disable */
#define MPIC_NO_PTHROU_DIS 0x00000040
+/* DCR based MPIC */
+#define MPIC_USES_DCR 0x00000080
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf0000000
^ 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