Re: MPC5121e, MBX driver, pvr.ko ...
On Friday 06 February 2009 10:03:55 Klaus Pedersen wrote: > Hi David > > I'm also run on a custom board, and using the MBX. > > You need to get the device tree file right. You will see the MBX reserved > the irq 66 in the boot printout. > Instead of using insmod use modprobe. The are 2 versions of rc.pvr. Thanks. I'll try that. Two versions of rc.pvr? Why's that, and where is the other one? > I a early thread about memcpy for G2/G3 cores, you mentioned that you will > have a look at the init. of the dram controller and the prio-manager, did > that give you anything?? Yes it did, and it's a long story, I havn't had persmission to talk about, sorry. I believe I can now say that there should be a new errata from Freescale explaining it all. As of now it's not on their web-site, but it should have been there since last week at least *grrr*. Btw, it has nothing to do with the prio-manager or the DRAM controller whatsoever. Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OpenPIC / CPM2 PIC and cascading interrupt priorities
On Mon, 16 Feb 2009 08:04:20 +1100
Benjamin Herrenschmidt wrote:
> > static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
> > {
> > int cascade_irq;
> >
> > while ((cascade_irq = cpm2_get_irq()) >= 0)
> > generic_handle_irq(cascade_irq);
> >
> > desc->chip->eoi(irq);
> > }
>
> You can try doing an early EOI see that helps. Ie, stick it inside the loop,
> after cpm_2_get_irq() and before generic_handle_irq() and see if that helps,
> but make sure you do that EOI only once, ie, only on the first iteration.
>
> Depending on how the CPM2 works, you may also be able to just get rid
> of the loop... ie, if CPM2 output is level sensitive.
>
> Ben.
Well the CPM2 -> OpenPIC signal is level sensitive and cpm2_get_irq()
just read SIVEC (register containing the CPM2 interrupt code) with no
side effect so doing an EOI just after cpm2_get_irq() will
unconditionally schedule a new (spurious) interrupt (which is latched
in the OpenPIC) which will reach the core as soon as it
local_irq_enable(), which is just before the ISR is called.
So I think to respect priorities of cascaded interrupts without
generating spurious interrupts, EOI of the master must be called from
within the flow handler of the slave after the slave has been acked,
that's why I wrote "that would need some changes in the architecture
independent code".
And now, after having explicitly written all of the above and thought
about the various possible modes of the master and of the slave and
their combinations (in the general case for Linux, not just for OpenPIC
and CPM2), I'm starting to think that it would be quite complicated and
error prone, so i guess i'll happily use a tasklet :)
Thanks!
Guillaume Knispel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: OpenPIC / CPM2 PIC and cascading interrupt priorities
> static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
> {
> int cascade_irq;
>
> while ((cascade_irq = cpm2_get_irq()) >= 0)
> generic_handle_irq(cascade_irq);
>
> desc->chip->eoi(irq);
> }
You can try doing an early EOI see that helps. Ie, stick it inside the loop,
after cpm_2_get_irq() and before generic_handle_irq() and see if that helps,
but make sure you do that EOI only once, ie, only on the first iteration.
Depending on how the CPM2 works, you may also be able to just get rid
of the loop... ie, if CPM2 output is level sensitive.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx tree updates
On Sun, Feb 15, 2009 at 05:31:40AM -0800, Felix Radensky wrote: >What about 4xx SPI driver ? Is it planned for inclusion in 2.6.30 ? I really hope so. I've Acked it twice now I think. However, that needs to go in through the SPI tree, which isn't mine. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
The state of Serial Rapid IO on MPC8548
Hi I've noticed that in 2.6.29-rc5 Serial Rapid IO is only available for 86xx processors. There's also no Freescale BSP for 8548. What is the best source of SRIO driver for this CPU ? Can I simply enable SRIO support in mainline kernel for 85xx and hope it will work ? Thanks. Felix. -- View this message in context: http://www.nabble.com/The-state-of-Serial-Rapid-IO-on-MPC8548-tp22022709p22022709.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx tree updates
Josh Boyer-4 wrote: > > Hi All, > > I've been rather busy lately and have unfortunately gotten behind on > updating the 4xx tree. I spent some time this weekend looking over > the patches queued up, and fortunately there were not too many. I'm > doing some build testing of these 4 today: > > commit 6c7120902305b3a21460cd2f0f917a39307df566 > Author: Madhulika Madishetty > > AMCC PPC 460SX redwood SoC platform initial framework > > commit 41b6a085e48d0d9e1200946755f49f31dd930137 > Author: Benjamin Herrenschmidt > > powerpc/4xx: Enable PCI domains on 4xx > > commit 018f76ec516c09a5381e517d0739d377a60ec0d5 > Author: Benjamin Herrenschmidt > > powerpc/4xx: Add missing USB and i2c devices to Canyonlands > > commit e12401222f749c37277a313d631dc024bbfd3b00 > Author: Yuri Tikhonov > > powerpc/44x: Support for 256KB PAGE_SIZE > > Barring any unforseen issues with these, I'll push them to my > next branch tomorrow and ask Ben to pull them shortly thereafter. > > If I've missed any patches that should be headed for 2.6.30, please > let me know! > > josh > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > Hi, Josh What about 4xx SPI driver ? Is it planned for inclusion in 2.6.30 ? Thanks. Felix. -- View this message in context: http://www.nabble.com/4xx-tree-updates-tp22016711p22022614.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
* Benjamin Herrenschmidt wrote: > On Sat, 2009-02-14 at 23:03 +0100, Ingo Molnar wrote: > > > > So the question is: even with FRAME_POINTERS disabled on PPC, is > > __builtin_return_address(1)/(2) reliable, and is save_stack_trace() fast? > > (i.e. > > can it walk down the stack frame efficiently, or does it have to scan the > > full > > kernel stack) I.e. does PPC have all the material advantages of frame > > pointers? > > Yes, we do. We effectively have frame pointers in fact, they may only be > omitted in leaf functions but then gcc __builtin_return_address() knows > how to handle that afaik. So basically we want to define FRAME_POINTERS on PPC, but do not want the -fno-omit-frame-pointers flag. Originally (many moons ago) FRAME_POINTER _was_ just the toplevel Makefile detail, but these days we've got a handful of secondary uses as well, expressing the reliability of backtraces in essence. We could split the whole option (affecting lots of files), or we could zap that compiler flag in the PPC case - it is only PPC that worries about this anyway. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
