* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Benjamin Herrenschmidt @ 2006-10-31 4:27 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, sl, sha, linuxppc-embedded
In-Reply-To: <200610292310.k9TNAHXZ013852@post.webmailer.de>
On Mon, 2006-10-30 at 00:10 +0100, Nicolas DET wrote:
> +/*
> + * void call to be used for .ack in the irq_chip_ops
> + * indeed, some of our irq does noy need ack
> + * but the kernel call .ack if it's valid or not
> +*/
> +
> +static void mpc52xx_voidfunc(unsigned int virq)
> +{
> +#ifdef DEBUG
> + int irq;
> + int l2irq;
> +
> + irq = irq_map[virq].hwirq;
> + l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
> +
> + pr_debug("%s: irq=%x, l2=%d\n", __func__, irq, l2irq);
> +#endif
> +}
As I said on IRC, we might be able to get away without that one, but
that's not urgent.
> + irq = irq_map[virq].hwirq;
> + l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
> +
> + pr_debug("%s: irq=%x, l2=%d\n", __func__, irq, l2irq);
> +
> + if (l2irq != 0)
> + BUG();
Use BUG_ON(l2irq != 0); instead, generates better code (though I don't
think you really need to keep those checks once you've verified things
work fine).
> + val = in_be32(&intr->ctrl);
> + val &= ~(1 << 11);
> + out_be32(&intr->ctrl, val);
> +}
>From the above, I deduce there is only one possible crit interrupt
right ? Also, it looks a lot, from the rest of the code that it's
basically just "main irq" 0, so why do you do two different L2's for
it ?
In fact, I'm a bit dubious of the way you differenciated "mainirq" and
"main" by giving them the same L2 number while they have different chips
and register sets... that seems to defeat the whole purpose of having
the L2 in the first place don't you think ?
I would have rather an L2 for CRIT + "IRQMAIN" thing (that is interrupts
using intr->ctrl bits 11 and below, I'll let you find a nice "name" for
it, maybe EXTIRQ ? (external irq), then a level for "MAIN" using
intr->main_mask etc...
> + case MPC52xx_IRQ_L1_CRIT:
> + pr_debug("%s: Critical. l2=%x\n", __func__, l2irq);
> +
> + if (l2irq != 0)
> + BUG();
> +
> + type = mpc52xx_irqx_gettype(l2irq);
> + good_irqchip = &mpc52xx_crit_irqchip;
> + break;
> +
> + case MPC52xx_IRQ_L1_MAIN:
> + pr_debug("%s: Main IRQ[1-3] l2=%x\n", __func__, l2irq);
> +
> + if ((l2irq >= 0) && (l2irq <= 3)) {
> + type = mpc52xx_irqx_gettype(l2irq);
> + good_irqchip = &mpc52xx_mainirq_irqchip;
> + } else {
> + good_irqchip = &mpc52xx_main_irqchip;
> + }
> + break;
See my comment above... Also, the only ones that can be edge are the
ones using intr->ctrl, thus if you do things right, you don't need your
fake ack, just only provide an ack for these. For the others, provide an
ack&mask that just masks :) (Though it's debateable wether we should
make the generic ack&mask test for ack beeing NULL indeed, I'll talk to
thomas about it).
> + case MPC52xx_IRQ_L1_PERP:
> + pr_debug("%s: Peripherals. l2=%x\n", __func__, l2irq);
> + good_irqchip = &mpc52xx_periph_irqchip;
> + break;
> +
> + case MPC52xx_IRQ_L1_SDMA:
> + pr_debug("%s: SDMA. l2=%x\n", __func__, l2irq);
> + good_irqchip = &mpc52xx_sdma_irqchip;
> + break;
> +
> + set_irq_chip_and_handler(virq, good_irqchip, good_handle);
> + set_irq_type(virq, type);
set_irq_type() does nothing if you haven't hooked a set_type callback to
your irq_chip and none of yours does so just drop it for now and look at
how this is done in mpic or ipic. If you actually want to implement
proper set_type (which you might need to do if you want that code to
work without having the firmware pre-initialize interrupts with the
right type at boot), you probably want to set the handler in
set_irq_type().
^ permalink raw reply
* Re: [PATCH] powerpc: map 4K iommu pages even on 64K largepage systems
From: Stephen Rothwell @ 2006-10-31 3:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev list, Paul Mackerras
In-Reply-To: <1162185359.25682.165.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
On Mon, 30 Oct 2006 16:15:59 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> iSeries friendly version of it. Needs to go to RHEL5 too.
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
From: Li Yang-r58472 @ 2006-10-31 2:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <BAAA9C5D-78F6-4B72-8FCB-633464EA85FB@kernel.crashing.org>
> >> I'm confused, if there are other users of immrbar_virt_to_phy() how
> >> can you get ride of it completely?
> >
> > Other users will change to use iopa() instead. There was some bug
to
> > use iopa() with io_block_mapping area, but it is ok to use it now.
>=20
> Hmm, what are the other users doing? I think we should avoid using
> iopa.
Get physical address from virtual address. I have considered to use
virt_to_phys(), but it is not consistent between ppc and powerpc arch.
- Leo
^ permalink raw reply
* Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
From: Kumar Gala @ 2006-10-31 2:46 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D2632BC@zch01exm20.fsl.freescale.net>
On Oct 30, 2006, at 8:28 PM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Tuesday, October 31, 2006 6:16 AM
>> To: Li Yang-r58472
>> Cc: Paul Mackerras; linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
>>
>>
>> On Oct 30, 2006, at 12:22 AM, Li Yang-r58472 wrote:
>>
>>>> -----Original Message-----
>>>> From: Paul Mackerras [mailto:paulus@samba.org]
>>>> Sent: Monday, October 30, 2006 11:22 AM
>>>> To: Li Yang-r58472
>>>> Cc: linuxppc-dev@ozlabs.org
>>>> Subject: Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
>>>>
>>>> Li Yang writes:
>>>>
>>>>> Remove private physical address mapping routine in qe_lib. Users
>>>>> of qe_lib should use generic functions like iopa().
>>>>> The change also addresses a bug found by Timur Tabi that cmd_input
>>>>> got mapped in qe_issue_cmd(). It should be written to CECDR
>>>>> unmodified.
>>>>
>>>> Do you mean that the argument to qe_issue_cmd is a physical
> address?
>>>> It seems to me that the bug fix you mention is the main thing the
>>>> patch does, and the removal of immrvar_virt_to_phys is a cleanup on
>>>> the side that is made possible by the bugfix.
>>>
>>> The argument cmd_input should be offset to the MURAM base. The
>>> cleanup
>>> is inspired by the bugfix but not result of the bugfix. There are
>>> still
>>> other users of the immrbar_virt_to_phy() which can be replaced. The
>>> bugfix can be covered by the work of removing all users of the
>>> routine.
>>> Or the removal will be depending on the bugfix to complete its
>>> work. Do
>>> you suggest us to separate the patches?
>>
>> I'm confused, if there are other users of immrbar_virt_to_phy() how
>> can you get ride of it completely?
>
> Other users will change to use iopa() instead. There was some bug to
> use iopa() with io_block_mapping area, but it is ok to use it now.
Hmm, what are the other users doing? I think we should avoid using
iopa.
- kumar
^ permalink raw reply
* RE: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
From: Li Yang-r58472 @ 2006-10-31 2:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <3C52C167-8CD5-4731-9F66-D8651E712DDD@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, October 31, 2006 6:16 AM
> To: Li Yang-r58472
> Cc: Paul Mackerras; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
>=20
>=20
> On Oct 30, 2006, at 12:22 AM, Li Yang-r58472 wrote:
>=20
> >> -----Original Message-----
> >> From: Paul Mackerras [mailto:paulus@samba.org]
> >> Sent: Monday, October 30, 2006 11:22 AM
> >> To: Li Yang-r58472
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
> >>
> >> Li Yang writes:
> >>
> >>> Remove private physical address mapping routine in qe_lib. Users
> >>> of qe_lib should use generic functions like iopa().
> >>> The change also addresses a bug found by Timur Tabi that cmd_input
> >>> got mapped in qe_issue_cmd(). It should be written to CECDR
> >>> unmodified.
> >>
> >> Do you mean that the argument to qe_issue_cmd is a physical
address?
> >> It seems to me that the bug fix you mention is the main thing the
> >> patch does, and the removal of immrvar_virt_to_phys is a cleanup on
> >> the side that is made possible by the bugfix.
> >
> > The argument cmd_input should be offset to the MURAM base. The
> > cleanup
> > is inspired by the bugfix but not result of the bugfix. There are
> > still
> > other users of the immrbar_virt_to_phy() which can be replaced. The
> > bugfix can be covered by the work of removing all users of the
> > routine.
> > Or the removal will be depending on the bugfix to complete its
> > work. Do
> > you suggest us to separate the patches?
>=20
> I'm confused, if there are other users of immrbar_virt_to_phy() how
> can you get ride of it completely?
Other users will change to use iopa() instead. There was some bug to
use iopa() with io_block_mapping area, but it is ok to use it now.
- Leo
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Kumar Gala @ 2006-10-31 1:11 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-dev, linuxppc-embedded, sl, sha
In-Reply-To: <45468775.8040108@246tNt.com>
>> * lets drop all the other struct defn in mpc52xx.h. This is a hold
>> over from arch/ppc and we really should only put defn that we
>> actually need closer to the code that uses them (ie, drivers, etc.)
>>
> Most of the struct that were in mpc52xx.h are the ones used in more
> than
> one driver.
> (or don't really belong to a driver)
> That's why they've been left there and not in the driver header, so I
> would leave those
> there.
>
> (e.g. the IDE struct is not there, neither is the FEC. But sdma is
> used
> at several place
> for example, so is rtc, xlb and cdm, ...)
I can see that some of these might be used, like SDMA, XLB, and CDM.
However, others like RTC should really be done via a single driver.
Additionally, I'd have to see code use GPIO, SDRAM, GPT, etc before I
think we should have them defined here. I'd rather we add these
items as they are used rather than having them here wholesale.
- kumar
^ permalink raw reply
* Re: Building ELDK 3.0/3.1 from SRPMS
From: Wolfgang Denk @ 2006-10-30 23:53 UTC (permalink / raw)
To: John W; +Cc: linuxppc-embedded
In-Reply-To: <20061030033846.1930.qmail@web50313.mail.yahoo.com>
Dear John,
in message <20061030033846.1930.qmail@web50313.mail.yahoo.com> you wrote:
> Thanks Wolfgang! Loading RH7.3 and updating
> everything with YUM seemed to do the trick to building
> ELDK 3.0!
Out of curiosity: may I ask why you invest efforts in this old
version?
> On a another note, I am also trying to build ELDK
> 2.1.0 from SRPMS on the same RH7.3 machine, and I am
> comming across two problems:
> 1. The SRPM for mount-2.11g-5a.src.rpm from the
> Yellowdog 2.3 release seems to have "bad magic" in
> that when trying to install the SRPM, there is some
> sort of validation problem. In remeding this, I am
> using mount-2.11g-5a.src.rpm from the Yellowdog 2.2
> release. It probably isn't safe to to so, but I was
> wondering how you over came this issue.
Exactly the same way you did :-)
> 2. I'm pretty sure that not all of my applications
> are building in the ELDK2.1.0 release, for example
...
> /bin/sh: gperf: command not found
> make[1]: *** [keywords.c] Error 127
> make[1]: Leaving directory
> `/opt/eldkv2.1.0/build/ppc-2006-10-27/work/usr/src/de
> nx/BUILD/modutils-2.4.13/genksyms'
> make: *** [all] Error 2
> error: Bad exit status from
> /opt/eldkv2.1.0/build/ppc-2006-10-27/work/var/tmp/rp
> m-tmp.26616 (%build)
>
> Does mean that I need to go get gperf?
Sorry, I don't have these old logs online any more. Please drop me a
note if you really want to see these, so I can restore the files from
tape.
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
How many Unix hacks does it take to change a light bulb? Let's see,
can you use a shell script for that or does it need a C program?
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Sylvain Munaut @ 2006-10-30 23:18 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20061030174724.7155.qmail@farnsworth.org>
Dale Farnsworth wrote:
> In article <200610292310.k9TNAHXZ013852@post.webmailer.de> Nicolas wrote:
>
>> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>>
>> It includes the main code in arch/powerpc/sysdev/ ad well as an header
>> file in include/asm-powerpc.
>>
>> Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
>>
>
> NAK.
>
> Two requests:
> 1. Please include patches inline so that they may be easily reviewed.
> 2. Please do not remove copyright lines from files you modify.
>
Indeed.
Dale Farnsworth wrote:
> Wow, the source code size sure ballooned in this revision.
>
> I'd like to see us go the other direction, with something like the
> following (untested code).
>
Well that's kind of a contradiction with what benh asked (separate IC
chips).
> static inline void io_be_setbit(u32 __iomem *addr, int bitno)
> {
> out_be32(addr, in_be32(addr) | 1 << bitno);
> }
>
> static inline void io_be_clrbit(u32 __iomem *addr, int bitno)
> {
> out_be32(addr, in_be32(addr) & ~(1 << bitno));
> }
>
Those could still be used to cleanup a little the code.
Sylvain
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Sylvain Munaut @ 2006-10-30 23:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc-embedded, sl, sha
In-Reply-To: <7BDB728E-0CC2-4940-9856-B496022F3482@kernel.crashing.org>
Kumar Gala wrote:
> On Oct 29, 2006, at 5:10 PM, Nicolas DET wrote:
>
>
>> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>>
>> It includes the main code in arch/powerpc/sysdev/ ad well as an
>> header file in
>> include/asm-powerpc.
>>
>> Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
>>
>
> Can you see if you can figure out how to inline patches with your
> mailer, its really difficult to comment on issues w/an attachment.
>
.There are also scripts to post patches ... So you're sure it's not mangled
or anything.
> +/* MBAR position */
> +#define MPC52xx_MBAR 0xf0000000 /* Phys address */
> +#define MPC52xx_MBAR_VIRT 0xf0000000 /* Virt address */
> +#define MPC52xx_MBAR_SIZE 0x00010000
> +
> +#define MPC52xx_PA(x) ((phys_addr_t)(MPC52xx_MBAR + (x)))
> +#define MPC52xx_VA(x) ((void __iomem *)(MPC52xx_MBAR_VIRT + (x)))
>
> This should be handled dynamically (pulled from the device tree), I
> doubt MBAR will be at the same location for all boards.
>
Agreed.
A little explanation on why they were used before :
the _VA was used for very early access (mostly boot debug) before
anything is setup.
the _PA was used for addresses used at several places. Like, a lot of
driver / code
needs to access XLB and there was not much way to distribute that
address around.
Now with the device tree that should be doable.
Having a nice function/helper
void *find_and_map_my_good_old_register_set(char *)
that would find and ioremap it for you would be nice ;) like
struct mpc52xx_xlb __iomem *xlb_regs =
find_and_map_my_good_old_register_set("xlb");
> * lets drop all the other struct defn in mpc52xx.h. This is a hold
> over from arch/ppc and we really should only put defn that we
> actually need closer to the code that uses them (ie, drivers, etc.)
>
Most of the struct that were in mpc52xx.h are the ones used in more than
one driver.
(or don't really belong to a driver)
That's why they've been left there and not in the driver header, so I
would leave those
there.
(e.g. the IDE struct is not there, neither is the FEC. But sdma is used
at several place
for example, so is rtc, xlb and cdm, ...)
Personnal note to Nicolas : It may seem a long process to just post a
patch but
since it imports a new platform to the arch/powerpc, it kinda requires
to make all
the due cleanups ;)
Sylvain
^ permalink raw reply
* Re: CPM2 SCC/SMC break handling broken
From: Ricardo Scop @ 2006-10-30 21:52 UTC (permalink / raw)
To: Vitaly Bordug, Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <20061030184002.35611755@vitb.ru.mvista.com>
Hi Laurent,
On Monday 30 October 2006 13:40, Vitaly Bordug wrote:
> On Mon, 30 Oct 2006 16:23:51 +0100
>
> Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
> > Hi Ricardo,
> >
> > > > > > I need to generate a break on a CPM2 SMC serial port (same is=
sue
> > > > > > with SCC serial ports).
> > > > > >
> > > > > > The tcsendbreak() man page states that the function should
> > > > > > generate a break between 250ms and 500ms, but testing showed =
that
> > > > > > the break is one character long (10 bits in 8N1 mode).
> > > > >
> > > > > [snip]
> > > > >
> > > > > > CPM_CR_STOP_TX is documented to generate a break of BRKCR
> > > > > > characters. The BRKCR register is initialized to 1, so only 1
> > > > > > break character is sent, which won't last between 250ms and
> > > > > > 500ms.
> > > > >
> > > > > [snip]
> > > > >
> > > > > > Could anyone think of a proper solution which would not distu=
rb
> > > > > > the other drivers too much ?
> > > > >
> > > > > Well, one could always set the BRKCR parameter to the maximum
> > > > > number of break characters permitted by it's size, since the br=
eak
> > > > > condition will anyway end as soon as the RESTART TX command is
> > > > > issued as a consequence of the tty->driver->break_ctl(tty, 0) c=
all.
> > > > > But I did not test this.
> > > >
> > > > That's a very good idea, but the documentation is a bit misleadin=
g
> > > > here. I tested the CPM2 behaviour, and found out that the break w=
ill
> > > > last BRKCR characters, even if a RESTART TX command is sent soone=
r.
> > > >
> > > > The user manual states
> > > >
> > > > "The SMC sends a programmable number of break characters accordin=
g to
> > > > BRKCR and reverts to idle or sends data if a RESTART TRANSMIT is
> > > > issued before completion."
> > > >
> > > > I suppose they meant that, if a RESTART TX command is issued befo=
re
> > > > completion of the break sequence, the SMC will send data at the e=
nd
> > > > of the break sequence. This is at least the behaviour I noticed a=
fter
> > > > trying your idea.
> > >
> > > Too bad.... :( One more good idea to the junk bin.
> > >
> > > Hmm, just a wild shot you can try, while you're at that: what about
> > > setting BRKCR to zero and issuing another STOP TRANSMIT, just befor=
e
> > > the RESTART TRANSMIT?
> >
> > Wow, congratulations. I wouldn't have thought about that.
Thanks.
BTW, thank you for trying that out. My fingers are much lazier than my br=
ain.
Cheers,
--=20
Ricardo Scop.
^ permalink raw reply
* Re: AW: Xubuntu and Xenomai on the Lite5200 (IceCube)...
From: Wolfgang Denk @ 2006-10-30 22:41 UTC (permalink / raw)
To: David Jander; +Cc: achim.machura, linuxppc-embedded
In-Reply-To: <200610301710.03626.david.jander@protonic.nl>
In message <200610301710.03626.david.jander@protonic.nl> you wrote:
>
> > after enabling pci in the kernelconfig,
> > usb is working.
>
> Duh. And how is one supposed to know that?
You aren't. I consider this a bug, too. Actually, this is supposed to
be fixed in the current tree.
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
"The greatest warriors are the ones who fight for peace."
- Holly Near
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Benjamin Herrenschmidt @ 2006-10-30 22:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc-embedded, sl, sha
In-Reply-To: <7BDB728E-0CC2-4940-9856-B496022F3482@kernel.crashing.org>
On Mon, 2006-10-30 at 16:25 -0600, Kumar Gala wrote:
> On Oct 29, 2006, at 5:10 PM, Nicolas DET wrote:
>
> > This patch add MPC52xx Interrupt controller for ARCH=powerpc.
> >
> > It includes the main code in arch/powerpc/sysdev/ ad well as an
> > header file in
> > include/asm-powerpc.
> >
> > Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
>
> Can you see if you can figure out how to inline patches with your
> mailer, its really difficult to comment on issues w/an attachment.
>
> +/* MBAR position */
> +#define MPC52xx_MBAR 0xf0000000 /* Phys address */
> +#define MPC52xx_MBAR_VIRT 0xf0000000 /* Virt address */
> +#define MPC52xx_MBAR_SIZE 0x00010000
> +
> +#define MPC52xx_PA(x) ((phys_addr_t)(MPC52xx_MBAR + (x)))
> +#define MPC52xx_VA(x) ((void __iomem *)(MPC52xx_MBAR_VIRT + (x)))
>
> This should be handled dynamically (pulled from the device tree), I
> doubt MBAR will be at the same location for all boards.
The physical address should indeed come from the DT. The virtual address
should be assigned dynamically by ioremap anyway. What are thse _PA/_VA
used for ?
> * can you split out the interrupt controller header info into a
> mpc52xx_pic.h [mpc52xx_intr, MPC52xx_IRQ_...]
Good idea.
Ben
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Kumar Gala @ 2006-10-30 22:25 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, sl, sha, linuxppc-embedded
In-Reply-To: <200610292310.k9TNAHXZ013852@post.webmailer.de>
On Oct 29, 2006, at 5:10 PM, Nicolas DET wrote:
> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>
> It includes the main code in arch/powerpc/sysdev/ ad well as an
> header file in
> include/asm-powerpc.
>
> Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
Can you see if you can figure out how to inline patches with your
mailer, its really difficult to comment on issues w/an attachment.
+/* MBAR position */
+#define MPC52xx_MBAR 0xf0000000 /* Phys address */
+#define MPC52xx_MBAR_VIRT 0xf0000000 /* Virt address */
+#define MPC52xx_MBAR_SIZE 0x00010000
+
+#define MPC52xx_PA(x) ((phys_addr_t)(MPC52xx_MBAR + (x)))
+#define MPC52xx_VA(x) ((void __iomem *)(MPC52xx_MBAR_VIRT + (x)))
This should be handled dynamically (pulled from the device tree), I
doubt MBAR will be at the same location for all boards.
* can you split out the interrupt controller header info into a
mpc52xx_pic.h [mpc52xx_intr, MPC52xx_IRQ_...]
* lets drop all the other struct defn in mpc52xx.h. This is a hold
over from arch/ppc and we really should only put defn that we
actually need closer to the code that uses them (ie, drivers, etc.)
- kumar
^ permalink raw reply
* Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
From: Kumar Gala @ 2006-10-30 22:15 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D2631CD@zch01exm20.fsl.freescale.net>
On Oct 30, 2006, at 12:22 AM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: Paul Mackerras [mailto:paulus@samba.org]
>> Sent: Monday, October 30, 2006 11:22 AM
>> To: Li Yang-r58472
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] qe_lib: Remove immrbar_virt_to_phys() function
>>
>> Li Yang writes:
>>
>>> Remove private physical address mapping routine in qe_lib. Users
>>> of qe_lib should use generic functions like iopa().
>>> The change also addresses a bug found by Timur Tabi that cmd_input
>>> got mapped in qe_issue_cmd(). It should be written to CECDR
>>> unmodified.
>>
>> Do you mean that the argument to qe_issue_cmd is a physical address?
>> It seems to me that the bug fix you mention is the main thing the
>> patch does, and the removal of immrvar_virt_to_phys is a cleanup on
>> the side that is made possible by the bugfix.
>
> The argument cmd_input should be offset to the MURAM base. The
> cleanup
> is inspired by the bugfix but not result of the bugfix. There are
> still
> other users of the immrbar_virt_to_phy() which can be replaced. The
> bugfix can be covered by the work of removing all users of the
> routine.
> Or the removal will be depending on the bugfix to complete its
> work. Do
> you suggest us to separate the patches?
I'm confused, if there are other users of immrbar_virt_to_phy() how
can you get ride of it completely?
I would suggest just sending the bugfix so it can go in for 2.6.19
and we can do the cleanup after that.
- kumar
^ permalink raw reply
* Re: [PATCH] powerpc: map 4K iommu pages even on 64K largepage systems
From: Olof Johansson @ 2006-10-30 21:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1162185359.25682.165.camel@localhost.localdomain>
Thanks for doing this, Linas and Ben.
On Mon, 30 Oct 2006 16:15:59 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* Re: glibc-2.5 test suite hangs/crashes the machine
From: Benjamin Herrenschmidt @ 2006-10-30 20:36 UTC (permalink / raw)
To: Fabio Massimo Di Nitto
Cc: linuxppc-dev, Jeff Bailey, Paul Mackerras, Ben Collins
In-Reply-To: <4545E38B.5010702@ubuntu.com>
On Mon, 2006-10-30 at 12:35 +0100, Fabio Massimo Di Nitto wrote:
> Benjamin Herrenschmidt wrote:
> > Does that patch fixes it ?
> >
>
> tested with kernel .17 and headers from .19 and the build hangs. Still tons of
> Zl processes around.
>
> On the note building with kernel .19 and .19 headers it all goes smooth.
Ok, so there's a different issue from what I've found. You haven't by
chance noted what those processes are (which test case typically) ?
Also, there's a sysrq to get a backtrace of all pending processes,
though I don't remember which one off the top of my mind, might be
useful to have a look though.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] Create compat_sys_migrate_pages.
From: Christoph Lameter @ 2006-10-30 19:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, LKML, ak, linux-mm, pj, paulus
In-Reply-To: <20061030181701.23ea7cba.sfr@canb.auug.org.au>
On Mon, 30 Oct 2006, Stephen Rothwell wrote:
> This is needed on bigendian 64bit architectures.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Christoph Lameter <clameter@sgi.com>
^ permalink raw reply
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: David Bolcsfoldi @ 2006-10-30 19:45 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <877iylreca.fsf@sleipner.barco.com>
On 10/27/06, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
>
> Peter> I'll test and take a closer look at your patch when I have
> Peter> access to hw again on Monday.
>
> Sorry, it got a bit later than promised, but I've now had a closer
> look at your patch ..
>
> --- uartlite/arch/ppc/boot/simple/misc.c 2006-10-15 14:09:47.000000000 -0700
> +++ uartlite-mod/arch/ppc/boot/simple/misc.c 2006-10-15 13:58:51.000000000 -0700
> @@ -48,7 +48,8 @@
> #if (defined(CONFIG_SERIAL_8250_CONSOLE) \
> || defined(CONFIG_VGA_CONSOLE) \
> || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \
> - || defined(CONFIG_SERIAL_MPSC_CONSOLE)) \
> + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \
> + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)) \
> && !defined(CONFIG_GEMINI)
> #define INTERACTIVE_CONSOLE 1
> #endif
>
> The Xilinx boards use misc-embedded.c not misc.c - Why is this needed?
>
You are right, it's not.
> +unsigned long serial_init(int chan, void *ignored)
> +{
> + switch (chan) {
> + #ifdef XPAR_XUL_UART_0_BASEADDR
> + case 0:
> + return XPAR_XUL_UART_0_BASEADDR;
> + #endif
> + #ifdef XPAR_XUL_UART_1_BASEADDR
> + case 1:
> + return XPAR_XUL_UART_1_BASEADDR;
> + #endif
> + #ifdef XPAR_XUL_UART_2_BASEADDR
> + case 2:
> + return XPAR_XUL_UART_2_BASEADDR;
> + #endif
> + #ifdef XPAR_XUL_UART_3_BASEADDR
> + case 3:
> + return XPAR_XUL_UART_3_BASEADDR;
> + #endif
>
> This doesn't help much as you don't use the com_port argument in the
> other functions.
>
True, it's utterly useless. I was planning on having an array with
base addresses which would be used to support the com_port argument.
But it didn't make it in this patch although I have version that does
this now.
> Where did you get the XPAR_XUL_UART_ defines from? Our xparameters.h
> seem to contain XPAR_UARTLITE_ defines instead.
>
I think that name is picked up from the name of the device in your
design, the defines get names XPAR_NNN_ and mine are called XUL_UART.
> @@ -131,12 +115,16 @@
> struct uart_port *port = (struct uart_port *)dev_id;
> int busy;
>
> + spin_lock(&port->lock); /* Lock the port in case of printk */
> +
>
> In an interrupt handler? Why? The console_write does a spin_lock_irqsave.
>
Sorry, my mistake. It's not needed.
> static int __init ulite_console_setup(struct console *co, char *options)
> {
> + int i, ret;
> struct uart_port *port;
> -
> + struct platform_device *pdev;
> +
> if (co->index < 0 || co->index >= ULITE_NR_UARTS)
> return -EINVAL;
>
> port = &ports[co->index];
>
> /* not initialized yet? */
> - if (!port->membase)
> - return -ENODEV;
> + if (!port->membase) {
> + /* We might be early console */
>
> Is this really necessary? The platform probe get's called quite early, E.G.:
>
> Breakpoint 2, ulite_probe (pdev=0xc01c84d0) at drivers/serial/uartlite.c:392
> 392 {
> (gdb) print __log_buf
> $1 = "<5>Linux version 2.6.19-rc3 (peko@sleipner) (gcc version 3.4.5) #19 Fri Oct 27 16:39:00 CEST 2006\n<6>Barco ThinLite (V2P) <peter.korsgaard@barco.com>\n<7>Entering add_active_range(0, 0, 15360) 0 entrie"...
>
> You can always use the ppc_md.progress() stuff for really early
> debugging if needed. I would prefer to keep this workaround out of
> uartlite.c if it isn't needed.
>
I am pretty certain probe won't get called until ppc_sys_init has been
called which is fairly far into the booting process and even if it did
the platform_bus hasn't been initialized before the ppc_sys_init is
called, at least not with any of the devices exported by
ppc_sys_devices.
Thanks for the review!
David
> --
> Bye, Peter Korsgaard
>
^ permalink raw reply
* Re: enabling MDIO on ppc/8xx_io/fec.c causes ioctl problems
From: Vitaly Bordug @ 2006-10-30 19:19 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200610302007.30041.antonio.dibacco@aruba.it>
On Mon, 30 Oct 2006 20:07:29 +0100
Antonio Di Bacco <antonio.dibacco@aruba.it> wrote:
> I enabled the use of MDIO in the fec.c driver but now the driver doesn't
> handle some ioctls that ifconfig sends to it. I saw that there is this code
> snippet in the driver:
>
> #ifdef CONFIG_USE_MDIO
> dev->do_ioctl = fec_enet_ioctl;
>
> for (i=0; i<NMII-1; i++)
> mii_cmds[i].mii_next = &mii_cmds[i+1];
> mii_free = mii_cmds;
> #endif /* CONFIG_USE_MDIO */
>
> But fec_enet_ioctl treats only mii related ioctls.
>
> What am I missing?
>
The 8xx_io/ stuff is obsoleted long ago. You should use drivers/fs_enet/* for your FEC eth instead.
arch/ppc/mpc885_setup.c can hand some guidance on ho to do that.
--
Sincerely,
Vitaly
^ permalink raw reply
* enabling MDIO on ppc/8xx_io/fec.c causes ioctl problems
From: Antonio Di Bacco @ 2006-10-30 19:07 UTC (permalink / raw)
To: linuxppc-embedded
I enabled the use of MDIO in the fec.c driver but now the driver doesn't
handle some ioctls that ifconfig sends to it. I saw that there is this code
snippet in the driver:
#ifdef CONFIG_USE_MDIO
dev->do_ioctl = fec_enet_ioctl;
for (i=0; i<NMII-1; i++)
mii_cmds[i].mii_next = &mii_cmds[i+1];
mii_free = mii_cmds;
#endif /* CONFIG_USE_MDIO */
But fec_enet_ioctl treats only mii related ioctls.
What am I missing?
Thank you,
Antonio.
^ permalink raw reply
* Re: [RFC] Fix for interrupt distribution
From: Nathan Lynch @ 2006-10-30 18:17 UTC (permalink / raw)
To: Mohan Kumar M; +Cc: linuxppc-dev, fastboot, anton
In-Reply-To: <20061030180446.GA24307@in.ibm.com>
Mohan Kumar M wrote:
> Hello,
>
> When kdump kernel is booted with the parameter "maxcpus=1" on a threaded
> CPU, we faced some interrupt routing problems.
>
> In the xics initialization code, "reg" property in each cpu node
> (device-tree/cpus/PowerPC,POWER5@x) is used to match the current boot
> cpu id and based on that "default_server" and "default_distrib_server"
> are calculated. This condition will always meet when OF chooses CPU0 as
> boot cpu or crash happenes on any cpu whose id is any physical cpu id.
>
> The "reg" property in cpu node gives the id of the cpu and this cpu node
> is created only for physical cpus (not for logical/threaded cpus). The
> code compares the "reg" value to the current boot cpu id and if it
> matches then only it reads "ibm,ppc-interrupt-gserver#s" and assigns the
> last value of it (which is usually 0xff) to default_distrib_server. So
> when a crash occurs on CPU 3, it will not be able to match the condition
> and thus default_distrib_server is left as zero only. This makes all
> interrupts routed to cpu 0 but cpu 0 is not up because of "maxcpus=1"
> parameter.
>
> To overcome this, I have just added one more condition to check the
> above condition. I have attached the patch also. Patch is generated over
> 2.6.19-rc3.
>
> One more idea will be instead of using "reg" property in each cpu node,
> can we use "ibm,ppc-interrupt-gserver#s" to determine the distribution
> server? "ibm,ppc-interrupt-gserver#s" format is (please correct
> if I am wrong)
> phys_cpu_id distrib_server logical_cpu_id distrib_server
Firmware has no notion of Linux's logical cpu numbering.
> In a Dual core SMT enabled system, "ibm,ppc-interrupt-gserver#s" will
> be:
>
> 00000002 000000ff 00000003 000000ff
> ^ phys cpu id
> ^ distribution server
> ^ logical cpu id
> ^ distribution server
>
> Tested on POWER5 box.
>
> Since POWER4 does not have SMT, crash can happen on any CPU and kdump
> kernel can boot with "maxcpus=1" without any problem.
>
>
>
> Allow any cpu to become boot cpu.
>
> Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
> ---
>
> Index: test/linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
> ===================================================================
> --- test.orig/linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
> +++ test/linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
> @@ -687,7 +687,8 @@ void __init xics_init_IRQ(void)
> np;
> np = of_find_node_by_type(np, "cpu")) {
> ireg = get_property(np, "reg", &ilen);
> - if (ireg && ireg[0] == get_hard_smp_processor_id(boot_cpuid)) {
> + if (ireg && ((ireg[0] == get_hard_smp_processor_id(boot_cpuid))
> + || (ireg[0] == get_hard_smp_processor_id(boot_cpuid) - 1))) {
> ireg = get_property(np,
> "ibm,ppc-interrupt-gserver#s", &ilen);
> i = ilen / sizeof(int);
NAK
We can't assume any arithmetic relationship between the
"hard"/platform thread ids; it's completely unspecified. I bet this
patch happens to work on your system but will fail on others.
^ permalink raw reply
* [RFC] Fix for interrupt distribution
From: Mohan Kumar M @ 2006-10-30 18:04 UTC (permalink / raw)
To: linuxppc-dev, fastboot; +Cc: anton
Hello,
When kdump kernel is booted with the parameter "maxcpus=1" on a threaded
CPU, we faced some interrupt routing problems.
In the xics initialization code, "reg" property in each cpu node
(device-tree/cpus/PowerPC,POWER5@x) is used to match the current boot
cpu id and based on that "default_server" and "default_distrib_server"
are calculated. This condition will always meet when OF chooses CPU0 as
boot cpu or crash happenes on any cpu whose id is any physical cpu id.
The "reg" property in cpu node gives the id of the cpu and this cpu node
is created only for physical cpus (not for logical/threaded cpus). The
code compares the "reg" value to the current boot cpu id and if it
matches then only it reads "ibm,ppc-interrupt-gserver#s" and assigns the
last value of it (which is usually 0xff) to default_distrib_server. So
when a crash occurs on CPU 3, it will not be able to match the condition
and thus default_distrib_server is left as zero only. This makes all
interrupts routed to cpu 0 but cpu 0 is not up because of "maxcpus=1"
parameter.
To overcome this, I have just added one more condition to check the
above condition. I have attached the patch also. Patch is generated over
2.6.19-rc3.
One more idea will be instead of using "reg" property in each cpu node,
can we use "ibm,ppc-interrupt-gserver#s" to determine the distribution
server? "ibm,ppc-interrupt-gserver#s" format is (please correct
if I am wrong)
phys_cpu_id distrib_server logical_cpu_id distrib_server
In a Dual core SMT enabled system, "ibm,ppc-interrupt-gserver#s" will
be:
00000002 000000ff 00000003 000000ff
^ phys cpu id
^ distribution server
^ logical cpu id
^ distribution server
Tested on POWER5 box.
Since POWER4 does not have SMT, crash can happen on any CPU and kdump
kernel can boot with "maxcpus=1" without any problem.
Allow any cpu to become boot cpu.
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
---
Index: test/linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- test.orig/linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
+++ test/linux-2.6.19-rc3/arch/powerpc/platforms/pseries/xics.c
@@ -687,7 +687,8 @@ void __init xics_init_IRQ(void)
np;
np = of_find_node_by_type(np, "cpu")) {
ireg = get_property(np, "reg", &ilen);
- if (ireg && ireg[0] == get_hard_smp_processor_id(boot_cpuid)) {
+ if (ireg && ((ireg[0] == get_hard_smp_processor_id(boot_cpuid))
+ || (ireg[0] == get_hard_smp_processor_id(boot_cpuid) - 1))) {
ireg = get_property(np,
"ibm,ppc-interrupt-gserver#s", &ilen);
i = ilen / sizeof(int);
^ permalink raw reply
* Re: Xubuntu and Xenomai on the Lite5200 (IceCube)...
From: Grant Likely @ 2006-10-30 17:58 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded list
In-Reply-To: <200610301209.38103.david.jander@protonic.nl>
On 10/30/06, David Jander <david.jander@protonic.nl> wrote:
>
> Hi all,
>
> I got the task to help make Linux run on the IceCube, with support for MSCAN,
> FEC and USB. After a rather exciting jurney I managed to get kernel 2.6.18
> working with bestcomm DMA and FEC support backported from DENX's git
> 2.6.19-rcsomething, and Xenomai installed upon that.
> Btw, before Wolfgang Denk starts complaining why I didn't use his 2.4 kernel,
> it's because I wasn't smart enough to get USB working. If it does work,
> please tell me how, I just get errors when plugging in a USB device "kernel:
> usb.c: USB device not accepting new address=2 (error=-110)".
> This seems to work fine in 2.6, though.
> It was not easy, so I wrote everything down (I hope I didn't forget anything
> important):
>
> http://yopesblog.blogspot.com/2006/10/how-to-run-ubuntu-and-xenomai-on.html
Congratulations, that's good work! Especially the bit about
documenting what you did! I've been meaning to play w/ xenomai for a
while now.
Care to help with the port to arch/powerpc now? :P
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Dale Farnsworth @ 2006-10-30 17:47 UTC (permalink / raw)
To: nd, linuxppc-embedded
In-Reply-To: <200610292310.k9TNAHXZ013852@post.webmailer.de>
In article <200610292310.k9TNAHXZ013852@post.webmailer.de> Nicolas wrote:
> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>
> It includes the main code in arch/powerpc/sysdev/ ad well as an header file in
> include/asm-powerpc.
>
> Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
Wow, the source code size sure ballooned in this revision.
I'd like to see us go the other direction, with something like the
following (untested code).
-Dale Farnsworth
(BTW, I sent a patch containing these changes to Nicolas last week.)
-----------------------
static inline void io_be_setbit(u32 __iomem *addr, int bitno)
{
out_be32(addr, in_be32(addr) | 1 << bitno);
}
static inline void io_be_clrbit(u32 __iomem *addr, int bitno)
{
out_be32(addr, in_be32(addr) & ~(1 << bitno));
}
static void mpc52xx_ic_mask(unsigned int virq)
{
u32 val;
int irq;
int l1irq;
int l2irq;
irq = irq_map[virq].hwirq;
l1irq = (irq & MPC52xx_IRQ_L1_MASK) >> MPC52xx_IRQ_L1_OFFSET;
l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
pr_debug("%s: irq=%x. l1=%d, l2=%d\n", __func__, irq, l1irq, l2irq);
switch (l1irq) {
case MPC52xx_IRQ_L1_CRIT:
case MPC52xx_IRQ_L1_MAIN:
if (l2irq <= 3)
io_be_clrbit(&intr->ctrl, 11 - l2irq);
else
io_be_setbit(&intr->main_mask, 16 - l2irq);
break;
case MPC52xx_IRQ_L1_PERP:
io_be_setbit(&intr->per_mask, 31 - l2irq);
break;
case MPC52xx_IRQ_L1_SDMA:
io_be_setbit(&sdma->IntMask, l2irq);
break;
}
}
static void mpc52xx_ic_unmask(unsigned int virq)
{
u32 val;
int irq;
int l1irq;
int l2irq;
irq = irq_map[virq].hwirq;
l1irq = (irq & MPC52xx_IRQ_L1_MASK) >> MPC52xx_IRQ_L1_OFFSET;
l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
pr_debug("%s: irq=%x. l1=%d, l2=%d\n", __func__, irq, l1irq, l2irq);
switch (l1irq) {
case MPC52xx_IRQ_L1_CRIT:
case MPC52xx_IRQ_L1_MAIN:
if (l2irq <= 3)
io_be_setbit(&intr->ctrl, 11 - l2irq);
else
io_be_clrbit(&intr->main, 16 - l2irq);
break;
case MPC52xx_IRQ_L1_PERP:
io_be_setbit(&intr->per_mask, 31 - l2irq);
break;
case MPC52xx_IRQ_L1_SDMA:
io_be_clrbit(&sdma->IntMask, l2irq);
break;
}
}
static void mpc52xx_ic_ack(unsigned int virq)
{
u32 val;
int irq;
int l1irq;
int l2irq;
irq = irq_map[virq].hwirq;
l1irq = (irq & MPC52xx_IRQ_L1_MASK) >> MPC52xx_IRQ_L1_OFFSET;
l2irq = (irq & MPC52xx_IRQ_L2_MASK) >> MPC52xx_IRQ_L2_OFFSET;
pr_debug("%s: irq=%x. l1=%d, l2=%d\n", __func__, irq, l1irq, l2irq);
switch (l1irq) {
case MPC52xx_IRQ_L1_CRIT:
case MPC52xx_IRQ_L1_MAIN:
if (l2irq <= 3)
io_be_setbit(&intr->ctrl, 27 - l2irq);
break;
case MPC52xx_IRQ_L1_PERP:
io_be_clrbit(&intr->per_mask, 31 - l2irq);
break;
case MPC52xx_IRQ_L1_SDMA:
out_be32(&sdma->IntPend, 1 << l2irq);
break;
}
}
^ permalink raw reply
* Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
From: Dale Farnsworth @ 2006-10-30 17:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200610292310.k9TNAHXZ013852@post.webmailer.de>
In article <200610292310.k9TNAHXZ013852@post.webmailer.de> Nicolas wrote:
> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>
> It includes the main code in arch/powerpc/sysdev/ ad well as an header
> file in include/asm-powerpc.
>
> Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
NAK.
Two requests:
1. Please include patches inline so that they may be easily reviewed.
2. Please do not remove copyright lines from files you modify.
-Dale
^ 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