* Re: [PATCH][POWERPC] document ipic level/sense info
From: Segher Boessenkool @ 2007-07-10 12:59 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707091820.l69IKjBU013685@ld0164-tx32.am.freescale.net>
> +Sense and level information follows the Linux convention
> +(specified in include/linux/interrupt.h) and should be encoded
> +as follows:
> +
> + 1 = low to high edge sensitive type enabled
> + 2 = high to low edge sensitive type enabled
> + 4 = active high level sensitive type enabled
> + 8 = active low level sensitive type enabled
Please note that using the same bit encoding as some Linux
version does buys you (almost) nothing; a good parser for
this OF node should do range/value checking on this property
anyway, translating the values in the process costs nothing.
Segher
^ permalink raw reply
* Re: [PATCH] ide: Use inline function for eieio
From: Sergei Shtylyov @ 2007-07-10 13:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ide, bzolnier, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0707100018020.5814@blarg.am.freescale.net>
Hello.
Kumar Gala wrote:
> Move to using inline function variant of eieio instead of inline assmebly.
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-10 13:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <4692A5B8.9010702@freescale.com>
>> I may be missing the obvious, but doesn't that defeat the purpose of
>> non-executable mappings?
>
> The hardware in question doesn't support non-executable mappings;
Not on a per-page basis, anyway.
> otherwise, it'd never have worked in the first place. Note that
> this is
> only allowed on 32-bit, non-book-E.
>
> There isn't much value in enforcing non-exec mappings only if it
> happens
> to be the first fault on a given page.
Yeah. Giving the warning is a good thing though.
Segher
^ permalink raw reply
* Re: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
From: Jean Delvare @ 2007-07-10 12:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded, Domen Puncer, i2c
In-Reply-To: <fa686aa40707092322v58bbdad0veb0ee2ec00f125b0@mail.gmail.com>
Hi Grant, hi Domen,
On Tue, 10 Jul 2007 00:22:05 -0600, Grant Likely wrote:
> On 7/10/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > Work around a problem reported on:
> > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> > Without this patch I2C on mpc5200 becomes unusable after a while.
> > Tested on mpc5200 boards by Matthias and me.
> >
> >
> > Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> Looks good to me,
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
OK, I will take this patch, but I'd like you to add a comment before
mpc_i2c_fixup() explaining what exactly the problem is and how it is
worked around. Otherwise it's a bit obscure what is going on.
I guess you want this patch in 2.6.23-rc1?
> > ---
> > drivers/i2c/busses/i2c-mpc.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > ===================================================================
> > --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> > +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > @@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq,
> > return IRQ_HANDLED;
> > }
> >
> > +static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> > +{
> > + writeccr(i2c, 0);
> > + udelay(30);
> > + writeccr(i2c, CCR_MEN);
> > + udelay(30);
> > + writeccr(i2c, CCR_MSTA | CCR_MTX);
> > + udelay(30);
> > + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > + udelay(30);
> > + writeccr(i2c, CCR_MEN);
> > + udelay(30);
> > +}
> > +
> > static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> > {
> > unsigned long orig_jiffies = jiffies;
> > @@ -153,6 +167,7 @@ static void mpc_i2c_start(struct mpc_i2c
> > static void mpc_i2c_stop(struct mpc_i2c *i2c)
> > {
> > writeccr(i2c, CCR_MEN);
> > + writeccr(i2c, 0);
> > }
> >
> > static int mpc_write(struct mpc_i2c *i2c, int target,
> > @@ -245,6 +260,8 @@ static int mpc_xfer(struct i2c_adapter *
> > }
> > if (time_after(jiffies, orig_jiffies + HZ)) {
> > pr_debug("I2C: timeout\n");
> > + if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
> > + mpc_i2c_fixup(i2c);
> > return -EIO;
> > }
> > schedule();
> >
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-10 13:11 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070709195743.GA26089@ld0162-tx32.am.freescale.net>
> In older versions of glibc (through 2.3), the dynamic linker
> executes a
> small amount of code from the data segment, which is not marked as
> executable. A recent change (commit
> 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; there should be a deprecation period before
> older glibc versions stop working.
>
> The problem has been observed on glibc 2.2. While glibc 2.3 has
> the same
> code, I did not see the problem; it may be that it accesses the
> page in
> question as data before executing from it, and thus it is already
> mapped.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
> Unfortunately, this didn't make it into 2.6.22, but it should
> probably go
> into the stable branch...
Both .21.x and .22.x I suppose; if we care about glibc 2.2.x
at all still, that is.
So to make double sure, this doesn't warn on glibc 2.3.x?
Segher
^ permalink raw reply
* Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
From: Matt Sealey @ 2007-07-10 13:14 UTC (permalink / raw)
To: ThomasB; +Cc: linuxppc-embedded
In-Reply-To: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
Isn't the ethernet the same on the 64260, 64360, 64460?
There's definitely a driver for 6436x and above..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
ThomasB wrote:
> Hi all,
> I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board.
> My Linux runs completely except for Ethernet. I don't find any Ethernet
> driver for my bridge. Do you know if there is an Ethernet driver for the
> Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260
> ethernet driver in the kernel 2.4.34 for MIPS processor, will it be
> possible to port it in a 2.6 kernel?
> Thanks for you help.
>
>
> --
> ThomasB
> http://psyphi.zeblog.com/ <http://psyphi.zeblog.com/>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 00/13] IB/ehca: eHCA2 enablement & some fixes
From: Joachim Fenkes @ 2007-07-10 13:20 UTC (permalink / raw)
To: Roland Dreier
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <adak5t9w7kx.fsf@cisco.com>
Roland Dreier <rdreier@cisco.com> wrote on 10.07.2007 00:11:42:
> thanks, I applied these for 2.6.23 and fixed a bunch of minor things
> that scripts/checkpatch.pl complained about (since I was in a mood to
> do mindless things).
Thanks! Both for the quick merge and for the fixes!
> In the future please run that yourself and clean
> up the obvious things. I generally don't worry about the 80 column
> stuff, but it will catch most whitespace problems and tell you that
> foo(x,y) should be foo(x, y) etc. So you don't have to completely
> silence the script but at least take a look at the output.
Didn't know about that script before, so thanks for the pointer!
I'll be sure to pass the next set of patches through it.
Joachim
^ permalink raw reply
* Re: [PATCH v2][POWERPC] document ipic level/sense info
From: Segher Boessenkool @ 2007-07-10 13:21 UTC (permalink / raw)
To: Grant Likely; +Cc: Stuart Yoder, paulus, linuxppc-dev
In-Reply-To: <fa686aa40707091548h5182d6d0r900afc1f35d4f80f@mail.gmail.com>
>> +Sense and level information follows the Linux convention
>> +(specified in include/linux/interrupt.h) and should be encoded
>> +as follows:
>> +
>> + 2 = high to low edge sensitive type enabled
>> + 8 = active low level sensitive type enabled
> ... but it is probably worthwhile commentting that sense types 1 & 4
> are not supported; just to fill in the obvious gaps. :-)
Same for sense types 0, 3, 5, 6, ...
Just name the sense types 0 and 1, similar to what all other
OF interrupt controller bindings do.
Segher
^ permalink raw reply
* Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
From: Dale Farnsworth @ 2007-07-10 13:22 UTC (permalink / raw)
To: psyphi, Linuxppc-embedded
In-Reply-To: <13b81f0c0707092336r5c7f4996u6f9c73d95c63bdc6@mail.gmail.com>
> I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board.
> My Linux runs completely except for Ethernet. I don't find any Ethernet
> driver for my bridge. Do you know if there is an Ethernet driver for the
> Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260 ethernet
> driver in the kernel 2.4.34 for MIPS processor, will it be possible to port
> it in a 2.6 kernel?
I believe that Steve Hill <sjhill@realitydiluted.com> has patched
the mv643xx_eth driver to work with the 64260 and plans to submit
the patches.
-Dale
^ permalink raw reply
* Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
From: ThomasB @ 2007-07-10 13:41 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-embedded
In-Reply-To: <20070710132207.12018.qmail@farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
>Isn't the ethernet the same on the 64260, 64360, 64460?
>
> There's definitely a driver for 6436x and above..
I just try it, it doesn't work, I receive without end the message:
mv643xx PHY read timeout, port 0
> I believe that Steve Hill <sjhill@realitydiluted.com> has patched
> the mv643xx_eth driver to work with the 64260 and plans to submit
> the patches.
That's means the patch isn't yet ready?
I will try to contact him.
It's nevertheless odd, I read about a file named gt64260_eth.c during my
search on the internet.But I wasn't able to find it :(.
Thanks for you help
--
ThomasB
http://psyphi.zeblog.com/
[-- Attachment #2: Type: text/html, Size: 820 bytes --]
^ permalink raw reply
* Re: [PATCH 06/13] IB/ehca: Set SEND_GRH flag for all non-LL UD QPs on eHCA2
From: Christoph Raisch @ 2007-07-10 16:35 UTC (permalink / raw)
To: Roland Dreier
Cc: Joachim Fenkes, LKML, LinuxPPC-Dev, OF-General, Stefan Roscher
In-Reply-To: <adazm25w998.fsf@cisco.com>
> What decides if a QP is LL or not?
>
> - R.
Currently we use a high bit in the QP type, which is not how we want to
keep it permanently.
What would you suggest, add two additional LL QP types, or change something
more fundamental
in libibverbs and kernel ib core?
We think we can get along quite well with the existing parameters in the
current create QP.
The current user-kernel interface is ok for these new QPs for post_send +
post_recv,
but unfortunately the libibverbs userspace calls don't match exactly how
the LL queues are to be used.
We would need something like the LL QP interface in libehca in libibverbs
to keep that interface generic.
We didn't see a usage yet for LL QP in kernel, so maybe we should continue
that
discussion on general@openfabrics only.
We could provide example code in libehca/samples if needed.
Gruss / Regards
Christoph + Nam
^ permalink raw reply
* Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
From: Dale Farnsworth @ 2007-07-10 13:50 UTC (permalink / raw)
To: ThomasB; +Cc: Linuxppc-embedded
In-Reply-To: <13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>
On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote:
> It's nevertheless odd, I read about a file named gt64260_eth.c during my
> search on the internet.But I wasn't able to find it :(.
It was in the (now obsolete) linuxppc_2_4_devel kernel. I can send
you a copy, but a merged mv64x60 driver will be much better.
-Dale
^ permalink raw reply
* Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
From: Mark A. Greer @ 2007-07-10 13:51 UTC (permalink / raw)
To: ThomasB; +Cc: Linuxppc-embedded
In-Reply-To: <13b81f0c0707100641i56e08bd3n7c7911782a81628a@mail.gmail.com>
On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote:
> >Isn't the ethernet the same on the 64260, 64360, 64460?
> >
> >There's definitely a driver for 6436x and above..
>
> I just try it, it doesn't work, I receive without end the message:
> mv643xx PHY read timeout, port 0
>
> >I believe that Steve Hill <sjhill@realitydiluted.com> has patched
> >the mv643xx_eth driver to work with the 64260 and plans to submit
> >the patches.
> That's means the patch isn't yet ready?
It probably means you don't something set up for whatever PHY you're
using.
> I will try to contact him.
A good idea.
> It's nevertheless odd, I read about a file named gt64260_eth.c during my
> search on the internet.But I wasn't able to find it :(.
There was one for 2.4 that was in the ppc devel tree but it never went
mainline. Hopefully, Steve can help you from here.
Mark
^ permalink raw reply
* Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts
From: Segher Boessenkool @ 2007-07-10 13:55 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11840606621515-git-send-email-wei.zhang@freescale.com>
> + dma@21000{
> + compatible = "fsl,mpc8xxx-dma";
Please use a real name, not this "xxx" stuff.
> + reg = <21000 100>;
> + ranges = <0 21000 1000>;
These overlap, that can't be right; it is just begging for
trouble.
> + ch0@100{
> + reg = <100 80>;
> + extended;
I think you want a little more detailed property name
than "extended" here?
Segher
^ permalink raw reply
* Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts
From: Segher Boessenkool @ 2007-07-10 13:57 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11840606621515-git-send-email-wei.zhang@freescale.com>
> + dma@21000{
"dma-controller" btw. And a space before the "{" (here and
elsewhere) :-)
Segher
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-10 14:01 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11840606624025-git-send-email-wei.zhang@freescale.com>
> + k) DMA
> +
> + This sector define DMA for dma-engine driver of Freescale
It's called a "device node" or "node", not a "sector".
> + - compatible : Should be "fsl,mpc8xxx-dma"
Should _include_, not should _be_. And none of this xxx
business, of course.
> + - extended : Set the DMA channel to work at extended chain mode.
> + If not set, the DMA channel will work at basic
> + chain mode.
Call it "extended-chain-mode", perhaps?
> + - reserved : Reserve the DMA channel to device.
What does this do? Reserve it for what device, and where?
The OS driver?
Segher
^ permalink raw reply
* MPC82xx ADS SCC ports initialisation
From: Laurent Pinchart @ 2007-07-10 14:19 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: vbordug
Hi everybody,
while checking the availability of MPC8260 support in ARCH=powerpc, I ran
across a possible issue in SCC ports initialisation for the MPC82xx ADS
boards.
init_scc1_uart_ioports and init_scc4_uart_ioports in
arch/powerpc/platforms/mpc82xx/mpx82xx_ads.c use the following code to
configure the SCC clocks:
clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
setbits32(&immap->im_cpmux.cmx_scr,
((data->clk_tx - 1) << (4 - data->clk_tx)));
setbits32(&immap->im_cpmux.cmx_scr,
((data->clk_rx - 1) << (4 - data->clk_rx)));
The shift right-hand operand doesn't seem to be correct. Could anyone confirm
this ? If my assumption is right, could anyone tell me if the MPC82xx
processors are actually supported by the powerpc architecture, or if the
MPC82xx ADS code is just a non-functional work in progress.
I also noticed that U-Boot doesn't have flatten device tree support for the
MPC82xx family. There seem to be still a lot of work to do to support the
MPC82xx in the powerpc tree, and the effort is much bigger than just porting
a board from ppc to powerpc.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
From: Segher Boessenkool @ 2007-07-10 14:24 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Thomas Gleixner, mingo, linux-kernel, linuxppc-dev
In-Reply-To: <20070710105212.GA14682@iram.es>
> This scales with the number of processors since there is one
> decrementer per core (is it per thread on SMT chips?
> I don't know).
One per core.
Segher
^ permalink raw reply
* Re: [PATCH] Fix the PCI-Ex link training bug on MPC8641HPCN board.
From: Kumar Gala @ 2007-07-10 14:36 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11840492523488-git-send-email-wei.zhang@freescale.com>
On Jul 10, 2007, at 1:34 AM, Zhang Wei wrote:
> If the PCI-Ex hose link training is failed, the kernel will halt at
> the
> PCI scan process on MPC8641HPCN board.
>
> This patch will remove and free the hose from PCI host list if the
> PCI hose link training is failed.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Thanks. Going to roll this into the work Roy's been doing to make
PCI code work across 85xx/86xx.
- k
> ---
> arch/powerpc/platforms/86xx/pci.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/
> platforms/86xx/pci.c
> index 73cd5b0..0b7835c 100644
> --- a/arch/powerpc/platforms/86xx/pci.c
> +++ b/arch/powerpc/platforms/86xx/pci.c
> @@ -210,8 +210,10 @@ int __init mpc86xx_add_bridge(struct
> device_node *dev)
>
> /* Probe the hose link training status */
> early_read_config_word(hose, 0, 0, PCIE_LTSSM, &val);
> - if (val < PCIE_LTSSM_L0)
> + if (val < PCIE_LTSSM_L0) {
> + pcibios_free_controller(hose);
> return -ENXIO;
> + }
>
> /* Setup the PCIE host controller. */
> mpc86xx_setup_pcie(hose, rsrc.start, rsrc.end - rsrc.start + 1);
> --
> 1.5.1
^ permalink raw reply
* RE: [PATCH v2][POWERPC] document ipic level/sense info
From: Yoder Stuart-B08248 @ 2007-07-10 14:36 UTC (permalink / raw)
To: Segher Boessenkool, Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <A9B90D06-77BD-49B5-8D2D-300641A973BC@kernel.crashing.org>
=20
> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]=20
> Sent: Tuesday, July 10, 2007 8:21 AM
> To: Grant Likely
> Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org; paulus@samba.org
> Subject: Re: [PATCH v2][POWERPC] document ipic level/sense info
>=20
> >> +Sense and level information follows the Linux convention
> >> +(specified in include/linux/interrupt.h) and should be encoded
> >> +as follows:
> >> +
> >> + 2 =3D high to low edge sensitive type enabled
> >> + 8 =3D active low level sensitive type enabled
>=20
> > ... but it is probably worthwhile commentting that sense types 1 & 4
> > are not supported; just to fill in the obvious gaps. :-)
>=20
> Same for sense types 0, 3, 5, 6, ...
>=20
> Just name the sense types 0 and 1, similar to what all other
> OF interrupt controller bindings do.
Actually, all I am trying to do with this patch is document the
current state of things. The 2/8 sense type usage has been that
way for a long time, and I'll defer to the 83xx maintainers
if they see any value in changing it.
Right now there are many DTS files with level/sense set to values
like 8 and no indication anywhere where those values came from.
Stuart
^ permalink raw reply
* Re: [PATCH v2][POWERPC] document ipic level/sense info
From: Kumar Gala @ 2007-07-10 14:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Stuart Yoder, paulus, linuxppc-dev
In-Reply-To: <A9B90D06-77BD-49B5-8D2D-300641A973BC@kernel.crashing.org>
On Jul 10, 2007, at 8:21 AM, Segher Boessenkool wrote:
>>> +Sense and level information follows the Linux convention
>>> +(specified in include/linux/interrupt.h) and should be encoded
>>> +as follows:
>>> +
>>> + 2 = high to low edge sensitive type enabled
>>> + 8 = active low level sensitive type enabled
>
>> ... but it is probably worthwhile commentting that sense types 1 & 4
>> are not supported; just to fill in the obvious gaps. :-)
>
> Same for sense types 0, 3, 5, 6, ...
>
> Just name the sense types 0 and 1, similar to what all other
> OF interrupt controller bindings do.
I'm not really keen on changing the values at this point. I think we
are stuck with them.
- k
^ permalink raw reply
* [PATCH 1/1] powerpc: Add H_ILLAN_ATTRIBUTES
From: Brian King @ 2007-07-10 14:41 UTC (permalink / raw)
To: paulus; +Cc: brking, linuxppc-dev
Adds the H_ILLAN_ATTRIBUTES hcall
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/include/asm-powerpc/hvcall.h | 1 +
1 file changed, 1 insertion(+)
diff -puN include/asm-powerpc/hvcall.h~powerpc_illan_attrs include/asm-powerpc/hvcall.h
--- linux-2.6/include/asm-powerpc/hvcall.h~powerpc_illan_attrs 2007-07-10 09:37:57.000000000 -0500
+++ linux-2.6-bjking1/include/asm-powerpc/hvcall.h 2007-07-10 09:37:57.000000000 -0500
@@ -206,6 +206,7 @@
#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
+#define H_ILLAN_ATTRIBUTES 0x244
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
_
^ permalink raw reply
* [PATCH v3][POWERPC] document ipic level/sense info
From: Stuart Yoder @ 2007-07-10 14:51 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
document level/sense encoding info for IPIC
interrupt controllers
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index c169299..e7a465c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -50,13 +50,14 @@ Table of Contents
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- g) Flash chip nodes
+ j) Flash chip nodes
VII - Specifying interrupt information for devices
1) interrupts property
2) interrupt-parent property
3) OpenPIC Interrupt Controllers
4) ISA Interrupt Controllers
+ 5) IPIC Interrupt Controllers
Appendix A - Sample SOC node for MPC8540
@@ -1878,6 +1879,22 @@ encodings listed below:
2 = high to low edge sensitive type enabled
3 = low to high edge sensitive type enabled
+5) Freescale IPIC Interrupt Controllers
+---------------------------------------
+
+IPIC interrupt controllers are specific to Freescale 83xx
+SOCs. Two cells are required to encode interrupt information.
+The first cell defines the interrupt number. The second cell
+defines the sense and level information.
+
+Sense and level information follows the Linux convention
+(specified in include/linux/interrupt.h) and should be encoded
+as follows:
+
+ 2 = high to low edge sense type enabled
+ 8 = active low level sense type enabled
+
+Note: other level/sense types (0,1,4, etc) are not supported.
Appendix A - Sample SOC node for MPC8540
========================================
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH] xilinxfb: Parameterize xilinxfb platform device registration
From: Grant Likely @ 2007-07-10 14:56 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46934496.40805@ru.mvista.com>
On 7/10/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > This patch allows multiple xilinxfb devices to be registered and used
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > cc: Andrei Konovalov <akonovalov@ru.mvista.com>
> > ---
>
> Looks OK for me.
Paulus, can you please pick this one up?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v3][POWERPC] document ipic level/sense info
From: Grant Likely @ 2007-07-10 15:03 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707101451.l6AEp9A3019214@ld0164-tx32.am.freescale.net>
On 7/10/07, Stuart Yoder <b08248@freescale.com> wrote:
> document level/sense encoding info for IPIC
> interrupt controllers
>
> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
> ---
> + 2 = high to low edge sense type enabled
> + 8 = active low level sense type enabled
> +
> +Note: other level/sense types (0,1,4, etc) are not supported.
Perfect! :-)
Acked-by: Grant Likely <grant.likely@secretlab.ca>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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