* Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2011-01-06 4:47 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, linuxppc-dev
In-Reply-To: <1292049075-1809-1-git-send-email-hs@denx.de>
On Sat, Dec 11, 2010 at 07:31:15AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: linux-fbdev@vger.kernel.org
> cc: devicetree-discuss@ozlabs.org
> cc: Ben Dooks <ben@simtec.co.uk>
> cc: Vincent Sanders <vince@simtec.co.uk>
> cc: Samuel Ortiz <sameo@linux.intel.com>
> cc: linux-kernel@vger.kernel.org
>
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
So has this stalled out? If Samuel wants to ack the MFD bits I don't mind
taking it through the fbdev tree. I can dust off an SM501 board to make
sure it still works for the non-OF case, although most of the changes
look fairly mechanical, so I don't forsee too much difficulty.
A few minor notes however. For starters, it would be nice to see this
patch split out a bit more logically. All of the items in your changelog
are more or less independent logical changes, and should really be
independent patches. As such, I'd like to see the EDID support as one
patch, the OF binding support layered on top of that, the documentation
split out as a trivial patch, and the I/O routine thing dealt with
separately. This should also make it easier for Samuel to simply ack the
OF bindings part that touch the MFD driver without having to be bothered
with any of the other stuff should regressions pop up at a later point in
time via a bisection.
As far as the DTS bindings documentation goes, I'm not sure what the best
way to split that out is. Perhaps simply lumping it in with the OF
bindings makes the most logical sense, and it's obviously a dependency
for the architecture-specific portion as well.
> @@ -1698,6 +1727,9 @@ static int sm501fb_init_fb(struct fb_info *fb,
> fb->fbops = &par->ops;
> fb->flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST |
> FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
> +#if defined(CONFIG_PPC_MPC52xx)
> + FBINFO_FOREIGN_ENDIAN |
> +#endif
> FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
>
> /* fixed data */
This is now getting in to deep hack territory. It's also not entirely
obvious how you expect things like the imageblit op to work given that
you're not selecting any of FB_{BIG,LITTLE,BOTH,FOREIGN}_ENDIAN, which
leads me to suspect you are manually doing this in your .config in a
relatively fragile way.
In the OF case I suppose you probably want something like:
#ifdef __BIG_ENDIAN
if (of_get_property(dp, "little-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#else
if (of_get_property(dp, "big-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#endif
and then simply hide the details in the DTS file in order to get rid of
CPU-specific hacks.
> +#if defined(CONFIG_PPC_MPC52xx)
> +#define smc501_readl(addr) __do_readl_be((addr))
> +#define smc501_writel(val, addr) __do_writel_be((val), (addr))
> +#else
> +#define smc501_readl(addr) readl(addr)
> +#define smc501_writel(val, addr) writel(val, addr)
> +#endif
Based on the Kconfig option for endianness you could probably just wrap these
to ioread/write32{,be} and hide the semantics in your iomap implementation?
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-06 2:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <20110103142200.738c0b17@udp111988uds.am.freescale.net>
On 01/03/2011 02:22 PM, Scott Wood wrote:
> On Wed, 22 Dec 2010 23:58:09 -0600
> Perhaps a something like this, with "doorbell" being a new standard
> hw-independent service with its own binding:
>
> msg1: mpic-msg@1400 {
> compatible = "fsl,mpic-v3.0-msg";
> reg =<0x1400 0x200>;
> interrupts<176 2 178 2>;
>
> // We have message registers 0 and 2 for sending,
> // and 1 and 3 for receiving.
> // If absent, we own all message registers in this block.
> fsl,mpic-msg-send-mask =<0x5>;
> fsl,mpic-msg-receive-mask =<0xa>;
>
> doorbell-controller;
>
> // split into #doorbell-send-cells and #doorbell-receive-cells?
> #doorbell-cells =<1>;
> };
>
> some-amp-protocol-thingy {
> send-doorbells =<&msg1 0>; // generate messages on MSGR0
> receive-doorbells =<&msg1 0>; // receive messages on MSGR1
> };
>
> some-other-amp-protocol-thingy {
> send-doorbells =<&msg1 1>; // generate messages on MSGR2
> receive-doorbells =<&msg1 1>; // receive messages on MSGR3
> };
>
> Doorbell capabilities such as passing a 32-bit message can be negotiated
> between the drivers for the doorbell controller and the doorbell client.
After thinking about it a little more, I like the idea of having a
'receive-mask' to further partition the message register blocks. This
would also allow us to remove IRQs from the 'interrupts' property that
are not being used on a given node. As for the 'send-mask', why would
we want to block sending messages? It seems to me that it would be
reasonable to allow a node to send a message to any other node.
As an example, consider a four core system. Then we might have
something like (only relevant DTS bits shown):
Core 0:
mpic-msgr-block@1400 {
// Receives messages on registers 1 and 3.
interrupts = <0xb1 2 0xb3 2>;
receive-mask = <0xa>;
};
Core 1:
mpic-msgr-block@1400 {
// Receives messages on register 2.
interrupts = <0xb2 2>;
receive-mask = <0x4>;
};
Core 2:
mpic-msgr-block@1400 {
// Receives messages on register 0.
interrupts = <0xb0 2>;
receive-mask = <0x1>;
};
Core 3:
mpic-msgr-block@1400 {
// Receives no messages.
interrupts = <>;
};
Then the API usage, for say core 0, might look something like:
/* Core 0 */
mpic_msgr *reg0 = mpic_get(0);
mpic_msgr *reg1 = mpic_get(1);
assert(mpic_msgr_get(100) == NULL);
u32 value;
/* Send a message on register 0. */
assert(mpic_msgr_write(reg0, 12) == 0);
/* Send a message on register 1. */
assert(mpic_msgr_write(reg1, 12) == 0);
/* Attempt to read a message on register 0, but can't
since it is not owned. */
assert(mpic_msgr_read(reg0, &value) == -ENODEV);
/* Successfully read a message on register 1. */
assert(mpic_msgr_read(reg1, &value) == 0);
The API usage for other cores would look similar. As mentioned in
another thread, this will provide us with the low-level building blocks
and we can layer other protocols, such as the doorbell protocol, on top
later (if needed).
Hollis, how do you feel about this?
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: Per process DSCR
From: Alexey Kardashevskiy @ 2011-01-06 2:02 UTC (permalink / raw)
To: Linuxppc-dev
test
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Scott Wood @ 2011-01-05 23:42 UTC (permalink / raw)
To: michael, Rex Feany; +Cc: Rafael Beims, linuxppc-dev
In-Reply-To: <4D24B725.2020300@evidence.eu.com>
On Wed, 5 Jan 2011 19:23:33 +0100
michael <michael@evidence.eu.com> wrote:
> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
> index dd5ea95..cb67076 100644
> --- a/arch/powerpc/include/asm/pte-8xx.h
> +++ b/arch/powerpc/include/asm/pte-8xx.h
> @@ -32,7 +32,7 @@
> #define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
> #define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
> #define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
> -#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
> +#define _PAGE_SPECIAL 0x0000 /* SW entry, forced to 0 by the TLB miss */
What do you think is going wrong with the special bit on 8xx?
Or might the change to set_pte_filter() alone be what fixed the problem?
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index 5304093..1da03a8 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
> pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
> if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
> cpu_has_feature(CPU_FTR_NOEXECUTE))) {
> - struct page *pg = maybe_pte_to_page(pte);
> - if (!pg)
> + unsigned long pfn = pte_pfn(pte);
> + struct page *pg;
> +
> + if (unlikely(!pfn_valid(pfn)))
> return pte;
> - if (!test_bit(PG_arch_1, &pg->flags)) {
> +
> + pg = pfn_to_page(pfn);
> #ifdef CONFIG_8xx
> - /* On 8xx, cache control instructions (particularly
> - * "dcbst" from flush_dcache_icache) fault as write
> - * operation if there is an unpopulated TLB entry
> - * for the address in question. To workaround that,
> - * we invalidate the TLB here, thus avoiding dcbst
> - * misbehaviour.
> - */
> - /* 8xx doesn't care about PID, size or ind args */
> - _tlbil_va(addr, 0, 0, 0);
> + /* On 8xx, cache control instructions (particularly
> + * "dcbst" from flush_dcache_icache) fault as write
> + * operation if there is an unpopulated TLB entry
> + * for the address in question. To workaround that,
> + * we invalidate the TLB here, thus avoiding dcbst
> + * misbehaviour.
> + */
> + /* 8xx doesn't care about PID, size or ind args */
> + _tlbil_va(addr, 0, 0, 0);
> #endif /* CONFIG_8xx */
> +
> + if (!pg)
> + return pte;
> +
> + if (!PageReserved(pg) && !test_bit(PG_arch_1, &pg->flags)) {
> flush_dcache_icache_page(pg);
> set_bit(PG_arch_1, &pg->flags);
> }
Rex, do you recall under what specific circumstances the _tlbil_va is
needed? Is it possible that it will be caused by a dcbst in other
contexts that are not dependent on the state of PG_arch_1?
-Scott
^ permalink raw reply
* Re: [PATCH] of/device: Don't register disabled devices
From: David Gibson @ 2011-01-05 23:35 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: devicetree-discuss, linux-kernel, Saxena, Deepak, Scott Wood,
linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA8E5@na3-mail.mgc.mentorg.com>
On Wed, Jan 05, 2011 at 02:53:27PM -0800, Blanchard, Hollis wrote:
> On 01/03/2011 03:01 PM, Grant Likely wrote:
> > Device nodes with the property status="disabled" are not usable and so
> > don't register them when parsing the device tree for devices.
> >
> This is great and all, but a fair amount of driver code explicitly
> searches the tree, rather than registering a probe function. That's why
> our earlier patches in this area were more comprehensive.
>
> What are your thoughts on handling those cases?
One by one. Trying to handle the explicit searches automagically is
just asking for trouble.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-05 23:07 UTC (permalink / raw)
To: Blanchard, Hollis; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA8E4@na3-mail.mgc.mentorg.com>
On Wed, 5 Jan 2011 14:49:40 -0800
"Blanchard, Hollis" <Hollis_Blanchard@mentor.com> wrote:
> On 01/05/2011 02:09 PM, Scott Wood wrote:
> > On Wed, 5 Jan 2011 15:58:55 -0600
> > Meador Inge<meador_inge@mentor.com> wrote:
> >
> >> We need some sort of mapping between a message register and a message
> >> register number so that the message registers can be referenced through
> >> some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that would
> >> be by putting an order on the registers. Maybe there is a better way,
> >> though ...
> > A message register is uniquely identified by a reference to the device
> > tree node, plus a 0-3 index into that node's message registers.
> Really what we're talking about is software configuration, not hardware
> description.
Part of that software configuration involves identifying the hardware
being referenced.
> We've gone back and forth on representing this information
> in the device tree, and most recently decided against it. Outside the
> kernel, a device node reference isn't really practical.
Global enumeration isn't much fun either. For something like this
where it's very unlikely that additional MPIC message units will be
added to the system dynamically, it's managable, but it's not a good
habit to get into. Look at the pain that's been caused by such
assumptions in the i2c subsystem, in kernel interrupt management, etc.
A reference to a node is just a pointer to a software message driver
object, which can be obtained from looking up an alias. It's a little
less simple than just using a number, but it's not impractical. It also
provides a natural place to put a layer of indirection in the code that
isolates the upper-layer protocol from the details of what sort of
message transport it is using.
Now, if you don't care about this, and want to just use numbers in your
application, go ahead. But I don't think that such an assumption
should go into the device tree binding. Have the software number the
message register banks in increasing physical address order, or based
on numbered aliases similar to how U-Boot enumerates ethernet nodes, or
something similar.
-Scott
^ permalink raw reply
* [30/49] hvc_console: Fix race between hvc_close and hvc_remove
From: Greg KH @ 2011-01-05 23:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rusty Russell, linuxppc-dev, Amit Shah, akpm, torvalds,
stable-review, alan
In-Reply-To: <20110105230438.GA26241@kroah.com>
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Amit Shah <amit.shah@redhat.com>
commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp->tty
unlock
lock
hp->tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty->ops will be NULL
NULL->...
This patch adds some tty krefs and also converts to using tty_vhangup().
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/char/hvc_console.c | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -312,6 +312,7 @@ static int hvc_open(struct tty_struct *t
spin_lock_irqsave(&hp->lock, flags);
/* Check and then increment for fast path open. */
if (hp->count++ > 0) {
+ tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
hvc_kick();
return 0;
@@ -319,7 +320,7 @@ static int hvc_open(struct tty_struct *t
tty->driver_data = hp;
- hp->tty = tty;
+ hp->tty = tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
@@ -336,6 +337,7 @@ static int hvc_open(struct tty_struct *t
spin_lock_irqsave(&hp->lock, flags);
hp->tty = NULL;
spin_unlock_irqrestore(&hp->lock, flags);
+ tty_kref_put(tty);
tty->driver_data = NULL;
kref_put(&hp->kref, destroy_hvc_struct);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -363,13 +365,18 @@ static void hvc_close(struct tty_struct
return;
hp = tty->driver_data;
+
spin_lock_irqsave(&hp->lock, flags);
+ tty_kref_get(tty);
if (--hp->count == 0) {
/* We are done with the tty pointer now. */
hp->tty = NULL;
spin_unlock_irqrestore(&hp->lock, flags);
+ /* Put the ref obtained in hvc_open() */
+ tty_kref_put(tty);
+
if (hp->ops->notifier_del)
hp->ops->notifier_del(hp, hp->data);
@@ -389,6 +396,7 @@ static void hvc_close(struct tty_struct
spin_unlock_irqrestore(&hp->lock, flags);
}
+ tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
@@ -424,10 +432,11 @@ static void hvc_hangup(struct tty_struct
spin_unlock_irqrestore(&hp->lock, flags);
if (hp->ops->notifier_hangup)
- hp->ops->notifier_hangup(hp, hp->data);
+ hp->ops->notifier_hangup(hp, hp->data);
while(temp_open_count) {
--temp_open_count;
+ tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
}
@@ -592,7 +601,7 @@ int hvc_poll(struct hvc_struct *hp)
}
/* No tty attached, just skip */
- tty = hp->tty;
+ tty = tty_kref_get(hp->tty);
if (tty == NULL)
goto bail;
@@ -672,6 +681,8 @@ int hvc_poll(struct hvc_struct *hp)
tty_flip_buffer_push(tty);
}
+ if (tty)
+ tty_kref_put(tty);
return poll_mask;
}
@@ -806,7 +817,7 @@ int hvc_remove(struct hvc_struct *hp)
struct tty_struct *tty;
spin_lock_irqsave(&hp->lock, flags);
- tty = hp->tty;
+ tty = tty_kref_get(hp->tty);
if (hp->index < MAX_NR_HVC_CONSOLES)
vtermnos[hp->index] = -1;
@@ -818,18 +829,18 @@ int hvc_remove(struct hvc_struct *hp)
/*
* We 'put' the instance that was grabbed when the kref instance
* was initialized using kref_init(). Let the last holder of this
- * kref cause it to be removed, which will probably be the tty_hangup
+ * kref cause it to be removed, which will probably be the tty_vhangup
* below.
*/
kref_put(&hp->kref, destroy_hvc_struct);
/*
- * This function call will auto chain call hvc_hangup. The tty should
- * always be valid at this time unless a simultaneous tty close already
- * cleaned up the hvc_struct.
+ * This function call will auto chain call hvc_hangup.
*/
- if (tty)
- tty_hangup(tty);
+ if (tty) {
+ tty_vhangup(tty);
+ tty_kref_put(tty);
+ }
return 0;
}
^ permalink raw reply
* Re: [PATCH] of/device: Don't register disabled devices
From: Blanchard, Hollis @ 2011-01-05 22:53 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Saxena, Deepak, Scott Wood,
linuxppc-dev, David Gibson
In-Reply-To: <20110103230122.25772.72990.stgit@localhost6.localdomain6>
T24gMDEvMDMvMjAxMSAwMzowMSBQTSwgR3JhbnQgTGlrZWx5IHdyb3RlOg0KPiBEZXZpY2Ugbm9k
ZXMgd2l0aCB0aGUgcHJvcGVydHkgc3RhdHVzPSJkaXNhYmxlZCIgYXJlIG5vdCB1c2FibGUgYW5k
IHNvDQo+IGRvbid0IHJlZ2lzdGVyIHRoZW0gd2hlbiBwYXJzaW5nIHRoZSBkZXZpY2UgdHJlZSBm
b3IgZGV2aWNlcy4NCj4NClRoaXMgaXMgZ3JlYXQgYW5kIGFsbCwgYnV0IGEgZmFpciBhbW91bnQg
b2YgZHJpdmVyIGNvZGUgZXhwbGljaXRseSANCnNlYXJjaGVzIHRoZSB0cmVlLCByYXRoZXIgdGhh
biByZWdpc3RlcmluZyBhIHByb2JlIGZ1bmN0aW9uLiBUaGF0J3Mgd2h5IA0Kb3VyIGVhcmxpZXIg
cGF0Y2hlcyBpbiB0aGlzIGFyZWEgd2VyZSBtb3JlIGNvbXByZWhlbnNpdmUuDQoNCldoYXQgYXJl
IHlvdXIgdGhvdWdodHMgb24gaGFuZGxpbmcgdGhvc2UgY2FzZXM/DQoNCkhvbGxpcyBCbGFuY2hh
cmQNCk1lbnRvciBHcmFwaGljcywgRW1iZWRkZWQgU3lzdGVtcyBEaXZpc2lvbg0KDQo+IC0tLQ0K
PiAgIGRyaXZlcnMvb2YvcGxhdGZvcm0uYyB8ICAgMjIgKysrKysrKysrKysrKystLS0tLS0tLQ0K
PiAgIDEgZmlsZXMgY2hhbmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMoLSkNCj4N
Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvb2YvcGxhdGZvcm0uYyBiL2RyaXZlcnMvb2YvcGxhdGZv
cm0uYw0KPiBpbmRleCA1YjRhMDdmLi5jMDFjZDFhIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL29m
L3BsYXRmb3JtLmMNCj4gKysrIGIvZHJpdmVycy9vZi9wbGF0Zm9ybS5jDQo+IEBAIC02MzMsNiAr
NjMzLDkgQEAgRVhQT1JUX1NZTUJPTChvZl9kZXZpY2VfYWxsb2MpOw0KPiAgICAqIEBucDogcG9p
bnRlciB0byBub2RlIHRvIGNyZWF0ZSBkZXZpY2UgZm9yDQo+ICAgICogQGJ1c19pZDogbmFtZSB0
byBhc3NpZ24gZGV2aWNlDQo+ICAgICogQHBhcmVudDogTGludXggZGV2aWNlIG1vZGVsIHBhcmVu
dCBkZXZpY2UuDQo+ICsgKg0KPiArICogUmV0dXJucyBwb2ludGVyIHRvIGNyZWF0ZWQgcGxhdGZv
cm0gZGV2aWNlLCBvciBOVUxMIGlmIGEgZGV2aWNlIHdhcyBub3QNCj4gKyAqIHJlZ2lzdGVyZWQu
ICBVbmF2YWlsYWJsZSBkZXZpY2VzIHdpbGwgbm90IGdldCByZWdpc3RlcmVkLg0KPiAgICAqLw0K
PiAgIHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKm9mX3BsYXRmb3JtX2RldmljZV9jcmVhdGUoc3Ry
dWN0IGRldmljZV9ub2RlICpucCwNCj4gICAJCQkJCSAgICBjb25zdCBjaGFyICpidXNfaWQsDQo+
IEBAIC02NDAsNiArNjQzLDkgQEAgc3RydWN0IHBsYXRmb3JtX2RldmljZSAqb2ZfcGxhdGZvcm1f
ZGV2aWNlX2NyZWF0ZShzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wLA0KPiAgIHsNCj4gICAJc3RydWN0
IHBsYXRmb3JtX2RldmljZSAqZGV2Ow0KPg0KPiArCWlmICghb2ZfZGV2aWNlX2lzX2F2YWlsYWJs
ZShucCkpDQo+ICsJCXJldHVybiBOVUxMOw0KPiArDQo+ICAgCWRldiA9IG9mX2RldmljZV9hbGxv
YyhucCwgYnVzX2lkLCBwYXJlbnQpOw0KPiAgIAlpZiAoIWRldikNCj4gICAJCXJldHVybiBOVUxM
Ow0KPiBAQCAtNjgzLDggKzY4OSw5IEBAIHN0YXRpYyBpbnQgb2ZfcGxhdGZvcm1fYnVzX2NyZWF0
ZShjb25zdCBzdHJ1Y3QgZGV2aWNlX25vZGUgKmJ1cywNCj4gICAJCXByX2RlYnVnKCIgICBjcmVh
dGUgY2hpbGQ6ICVzXG4iLCBjaGlsZC0+ZnVsbF9uYW1lKTsNCj4gICAJCWRldiA9IG9mX3BsYXRm
b3JtX2RldmljZV9jcmVhdGUoY2hpbGQsIE5VTEwsIHBhcmVudCk7DQo+ICAgCQlpZiAoZGV2ID09
IE5VTEwpDQo+IC0JCQlyYyA9IC1FTk9NRU07DQo+IC0JCWVsc2UgaWYgKCFvZl9tYXRjaF9ub2Rl
KG1hdGNoZXMsIGNoaWxkKSkNCj4gKwkJCWNvbnRpbnVlOw0KPiArDQo+ICsJCWlmICghb2ZfbWF0
Y2hfbm9kZShtYXRjaGVzLCBjaGlsZCkpDQo+ICAgCQkJY29udGludWU7DQo+ICAgCQlpZiAocmMg
PT0gMCkgew0KPiAgIAkJCXByX2RlYnVnKCIgICBhbmQgc3ViIGJ1c3Nlc1xuIik7DQo+IEBAIC03
MzMsMTAgKzc0MCw5IEBAIGludCBvZl9wbGF0Zm9ybV9idXNfcHJvYmUoc3RydWN0IGRldmljZV9u
b2RlICpyb290LA0KPiAgIAlpZiAob2ZfbWF0Y2hfbm9kZShtYXRjaGVzLCByb290KSkgew0KPiAg
IAkJcHJfZGVidWcoIiByb290IG1hdGNoLCBjcmVhdGUgYWxsIHN1YiBkZXZpY2VzXG4iKTsNCj4g
ICAJCWRldiA9IG9mX3BsYXRmb3JtX2RldmljZV9jcmVhdGUocm9vdCwgTlVMTCwgcGFyZW50KTsN
Cj4gLQkJaWYgKGRldiA9PSBOVUxMKSB7DQo+IC0JCQlyYyA9IC1FTk9NRU07DQo+ICsJCWlmIChk
ZXYgPT0gTlVMTCkNCj4gICAJCQlnb3RvIGJhaWw7DQo+IC0JCX0NCj4gKw0KPiAgIAkJcHJfZGVi
dWcoIiBjcmVhdGUgYWxsIHN1YiBidXNzZXNcbiIpOw0KPiAgIAkJcmMgPSBvZl9wbGF0Zm9ybV9i
dXNfY3JlYXRlKHJvb3QsIG1hdGNoZXMsJmRldi0+ZGV2KTsNCj4gICAJCWdvdG8gYmFpbDsNCj4g
QEAgLTc0OCw5ICs3NTQsOSBAQCBpbnQgb2ZfcGxhdGZvcm1fYnVzX3Byb2JlKHN0cnVjdCBkZXZp
Y2Vfbm9kZSAqcm9vdCwNCj4gICAJCXByX2RlYnVnKCIgIG1hdGNoOiAlc1xuIiwgY2hpbGQtPmZ1
bGxfbmFtZSk7DQo+ICAgCQlkZXYgPSBvZl9wbGF0Zm9ybV9kZXZpY2VfY3JlYXRlKGNoaWxkLCBO
VUxMLCBwYXJlbnQpOw0KPiAgIAkJaWYgKGRldiA9PSBOVUxMKQ0KPiAtCQkJcmMgPSAtRU5PTUVN
Ow0KPiAtCQllbHNlDQo+IC0JCQlyYyA9IG9mX3BsYXRmb3JtX2J1c19jcmVhdGUoY2hpbGQsIG1h
dGNoZXMsJmRldi0+ZGV2KTsNCj4gKwkJCWNvbnRpbnVlOw0KPiArDQo+ICsJCXJjID0gb2ZfcGxh
dGZvcm1fYnVzX2NyZWF0ZShjaGlsZCwgbWF0Y2hlcywmZGV2LT5kZXYpOw0KPiAgIAkJaWYgKHJj
KSB7DQo+ICAgCQkJb2Zfbm9kZV9wdXQoY2hpbGQpOw0KPiAgIAkJCWJyZWFrOw0KPg0K
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-05 22:49 UTC (permalink / raw)
To: Scott Wood; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110105160918.2b530fea@udp111988uds.am.freescale.net>
On 01/05/2011 02:09 PM, Scott Wood wrote:
> On Wed, 5 Jan 2011 15:58:55 -0600
> Meador Inge<meador_inge@mentor.com> wrote:
>
>> We need some sort of mapping between a message register and a message
>> register number so that the message registers can be referenced =
through
>> some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that =
would
>> be by putting an order on the registers. Maybe there is a better =
way,
>> though ...
> A message register is uniquely identified by a reference to the device
> tree node, plus a 0-3 index into that node's message registers.
Really what we're talking about is software configuration, not hardware=20
description. We've gone back and forth on representing this information=20
in the device tree, and most recently decided against it. Outside the=20
kernel, a device node reference isn't really practical.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* [PATCH v2 3/3] powerpc: Add IO event interrupt support
From: Tseng-Hui (Frank) Lin @ 2011-01-05 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tsenglin
This patch adds support for handling IO Event interrupts which come
through at the /event-sources/ibm,io-events device tree node.
There is one ibm,io-events interrupt, but this interrupt might be used
for multiple I/O devices, each with their own separate driver. So, we
create a platform interrupt handler that will do the RTAS check-exception
call and then call the driver's interrupt handlers.
So, a driver for a device that uses IO Event interrupts will register
it's interrupt service routine (or interrupt handler) with the platform
code using pseries_ioei_register_isr(). This register function takes
a function pointer to the driver's handler.
A driver can unregister to stop receiving the IO Event interrupts using
pseries_ioei_unregister_isr(), passing it the same function pointer to the
driver's handler the driver was registered with.
The platform code registers ioei_interrupt() as the interrupt handler
for the ibm,io-events interrupt. Upon receiving an IO Event interrupt, it
pulls in the IO event from RTAS and pass the contents of the IO event
to those drivers' handlers that have registered until the IO event is
handled. Since there could be multiple drivers' handlers, drivers' handlers
are responsible to identify who the incoming IO event belongs to by checking
the event type, sub-type, and scope. A driver handler should return
IRQ_HANDLED If the IO event is handled or IRQ_NONE otherwise.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
Signed-off-by: Tseng-Hui (Frank) Lin <tsenglin@us.ibm.com>
---
arch/powerpc/include/asm/io_event_irq.h | 54 ++++
arch/powerpc/platforms/pseries/Kconfig | 20 ++
arch/powerpc/platforms/pseries/Makefile | 1 +
arch/powerpc/platforms/pseries/io_event_irq.c | 260 ++++++++++++++++++++
4 files changed, 335 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/io_event_irq.h b/arch/powerpc/include/asm/io_event_irq.h
new file mode 100644
index 0000000..447f23d
--- /dev/null
+++ b/arch/powerpc/include/asm/io_event_irq.h
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2010 Mark Nelson and Tseng-Hui (Frank) Lin, IBM Corporation
+ *
+ * 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.
+ */
+
+#ifndef _ASM_POWERPC_IO_EVENT_IRQ_H
+#define _ASM_POWERPC_IO_EVENT_IRQ_H
+
+#define PSERIES_IOEI_RPC_MAX_LEN 216
+
+#define PSERIES_IOEI_TYPE_ERR_DETECTED 0x01
+#define PSERIES_IOEI_TYPE_ERR_RECOVERED 0x02
+#define PSERIES_IOEI_TYPE_EVENT 0x03
+#define PSERIES_IOEI_TYPE_RPC_PASS_THRU 0x04
+
+#define PSERIES_IOEI_SUBTYPE_NOT_APP 0x00
+#define PSERIES_IOEI_SUBTYPE_REBALANCE_REQ 0x01
+#define PSERIES_IOEI_SUBTYPE_NODE_ONLINE 0x03
+#define PSERIES_IOEI_SUBTYPE_NODE_OFFLINE 0x04
+#define PSERIES_IOEI_SUBTYPE_DUMP_SIZE_CHANGE 0x05
+#define PSERIES_IOEI_SUBTYPE_TORRENT_IRV_UPDATE 0x06
+#define PSERIES_IOEI_SUBTYPE_TORRENT_HFI_CFGED 0x07
+
+#define PSERIES_IOEI_SCOPE_NOT_APP 0x00
+#define PSERIES_IOEI_SCOPE_RIO_HUB 0x36
+#define PSERIES_IOEI_SCOPE_RIO_BRIDGE 0x37
+#define PSERIES_IOEI_SCOPE_PHB 0x38
+#define PSERIES_IOEI_SCOPE_EADS_GLOBAL 0x39
+#define PSERIES_IOEI_SCOPE_EADS_SLOT 0x3A
+#define PSERIES_IOEI_SCOPE_TORRENT_HUB 0x3B
+#define PSERIES_IOEI_SCOPE_SERVICE_PROC 0x51
+
+/* Platform Event Log Format, Version 6, data portition of IO event section */
+struct pseries_io_event_sect_data {
+ uint8_t event_type; /* 0x00 IO-Event Type */
+ uint8_t rpc_data_len; /* 0x01 RPC data length */
+ uint8_t scope; /* 0x02 Error/Event Scope */
+ uint8_t event_subtype; /* 0x03 I/O-Event Sub-Type */
+ uint32_t drc_index; /* 0x04 DRC Index */
+ uint8_t rpc_data[PSERIES_IOEI_RPC_MAX_LEN];
+ /* 0x08 RPC Data (0-216 bytes, */
+ /* padded to 4 bytes alignment) */
+};
+
+typedef irqreturn_t (*pseries_ioei_handler_t) (struct pseries_io_event_sect_data *);
+
+extern int pseries_ioei_register_handler(pseries_ioei_handler_t handler);
+extern int pseries_ioei_unregister_handler(pseries_ioei_handler_t handler);
+
+#endif /* _ASM_POWERPC_IO_EVENT_IRQ_H */
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index c667f0f..0f36aad 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -42,6 +42,25 @@ bool
depends on PPC_PSERIES && RTAS_ERROR_LOGGING
default n
+config IO_EVENT_IRQ
+ bool "IO Event Interrupt support"
+ depends on PPC_PSERIES
+ select PSERIES_EVENT_LOG
+ default y
+ help
+ Select this option, if you want to enable support for IO Event
+ interrupts. IO event interrupt is a mechanism provided by RTAS
+ to return information about hardware error and non-error events
+ which may need OS attention. RTAS returns events for multiple
+ event types and scopes. Device drivers can register their handlers
+ to receive events.
+
+ This option will only enable the IO event platform code. You
+ will still need to enable or compile the actual drivers
+ that use this infrastruture to handle IO event interrupts.
+
+ Say Y if you are unsure.
+
config LPARCFG
bool "LPAR Configuration Data"
depends on PPC_PSERIES || PPC_ISERIES
@@ -81,3 +105,4 @@ config DTL
which are accessible through a debugfs file.
Say N if you are unsure.
+
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 046ace9..73909ca 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
obj-$(CONFIG_DTL) += dtl.o
obj-$(CONFIG_PSERIES_EVENT_LOG) += pseries_event_log.o
+obj-$(CONFIG_IO_EVENT_IRQ) += io_event_irq.o
ifeq ($(CONFIG_PPC_PSERIES),y)
obj-$(CONFIG_SUSPEND) += suspend.o
diff --git a/arch/powerpc/platforms/pseries/io_event_irq.c b/arch/powerpc/platforms/pseries/io_event_irq.c
new file mode 100644
index 0000000..a39f451
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/io_event_irq.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright 2010 Mark Nelson and Tseng-Hui (Frank) Lin, IBM Corporation
+ *
+ * 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.
+ */
+
+#include <linux/errno.h>
+#include <linux/spinlock.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/list.h>
+
+#include <asm/machdep.h>
+#include <asm/rtas.h>
+#include <asm/irq.h>
+#include <asm/io_event_irq.h>
+
+#include "pseries.h"
+#include "pseries_event_log.h"
+
+/*
+ * IO event interrupt is a mechanism provided by RTAS to return
+ * information about hardware error and non-error events. Device
+ * drivers can register their handlers to receive events.
+ * Device drivers are expected to use pseries_ioei_register_handler()
+ * and pseries_ioei_unregister_handler() to register and unregister
+ * their interrupt handlers. Since multiple IO event types and scopes
+ * share an IO event interrupt, the interrupt handlers are called one
+ * by one until the IO event is claimed by one of the handlers.
+ * IO event interrupt handlers are expected to return IRQ_HANDLED
+ * if the IO event is handled by the handler and IRQ_NONE if the
+ * IO event does not belong to the handler.
+ */
+
+struct ioei_consumer {
+ pseries_ioei_handler_t handler;
+ struct list_head list;
+};
+
+static int ioei_supported = 0;
+
+static int ioei_check_exception_token;
+
+static LIST_HEAD(ioei_handler_list);
+static DEFINE_SPINLOCK(ioei_handler_list_lock);
+
+int pseries_ioei_register_handler(pseries_ioei_handler_t handler)
+{
+ struct ioei_consumer *iter;
+ struct ioei_consumer *cons;
+ int found;
+
+ if (!ioei_supported)
+ return -ENODEV;
+
+ cons = kmalloc(sizeof(struct ioei_consumer), GFP_KERNEL);
+
+ if (!cons)
+ return -ENOMEM;
+
+ spin_lock_irq(&ioei_handler_list_lock);
+ /* check to see if we've already registered this function.
+ * If we have, don't register it again
+ */
+ found = 0;
+ list_for_each_entry(iter, &ioei_handler_list, list)
+ if (iter->handler == handler) {
+ kfree(cons);
+ found = 1;
+ break;
+ }
+
+ if (!found) {
+ cons->handler = handler;
+ INIT_LIST_HEAD(&cons->list);
+ list_add(&cons->list, &ioei_handler_list);
+ }
+
+ spin_unlock_irq(&ioei_handler_list_lock);
+
+ return (found) ? -EEXIST : 0;
+}
+EXPORT_SYMBOL_GPL(pseries_ioei_register_handler);
+
+int pseries_ioei_unregister_handler(pseries_ioei_handler_t handler)
+{
+ struct ioei_consumer *iter, *temp;
+ int ret = -ENOENT;
+
+ spin_lock_irq(&ioei_handler_list_lock);
+
+ list_for_each_entry_safe(iter, temp, &ioei_handler_list, list)
+ if (iter->handler == handler) {
+ list_del(&iter->list);
+ kfree(iter);
+ ret = 0;
+ break;
+ }
+
+ spin_unlock_irq(&ioei_handler_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pseries_ioei_unregister_handler);
+
+static void ioei_call_handlers(struct pseries_io_event_sect_data *ioei_event)
+{
+ struct ioei_consumer *iter;
+ irqreturn_t ret = IRQ_NONE;
+
+ spin_lock(&ioei_handler_list_lock);
+ list_for_each_entry(iter, &ioei_handler_list, list) {
+ ret = iter->handler(ioei_event);
+ if (ret == IRQ_HANDLED)
+ break;
+ }
+ if (ret != IRQ_HANDLED) {
+ pr_err("io_event_irq: No one claims interrupt for IO event "
+ "type=%d, scope=%d. Interrupt lost!\n",
+ ioei_event->event_type, ioei_event->scope);
+ }
+ spin_unlock(&ioei_handler_list_lock);
+}
+
+/*
+ * Get the contents of IO Event section from event log.
+ * Return:
+ * 1: succeeded. ioei_buf contains a valid IO Event.
+ * 0: failed. ioei_buf does not contain a valid IO Event.
+ */
+static int ioei_get_event(struct rtas_error_log *rtas_elog,
+ struct pseries_io_event_sect_data *ioei_buf)
+{
+ struct pseries_io_event_sect_data *event_p;
+
+ /* We should only ever get called for io-event interrupts, but if
+ * we do get called for another type then something went wrong so
+ * make some noise about it.
+ * RTAS_TYPE_IO only exists in error log version 6 or later.
+ * No need to check error log version.
+ */
+ if (unlikely(rtas_elog->type != RTAS_TYPE_IO)) {
+ pr_warning("io_event_irq: We got called with an event type "
+ "of %d rather than %d!\n",
+ rtas_elog->type, RTAS_TYPE_IO);
+ WARN_ON(1);
+ return 0;
+ }
+
+ event_p = pseries_elog_find_section(
+ (struct rtas_error_log_v6ext *) &rtas_elog->buffer,
+ rtas_elog->extended_log_length,
+ PSERIES_ELOG_SECT_ID_IO_EVENT);
+ if (unlikely(!event_p)) {
+ pr_warning("io_event_irq: RTAS error log does not contain an "
+ "IO Event section. Could be a bug in firmware!\n");
+ WARN_ON(1);
+ return 0;
+ }
+
+ /* Check buffer last so that we can log info about the lost event. */
+ if (!ioei_buf) {
+ pr_warning("io_event_irq: No memory to copy IO event. "
+ "Event type=%d, scope=%d. Interrupt lost!\n",
+ event_p->event_type, event_p->scope);
+ return 0;
+ }
+
+ memcpy(ioei_buf, event_p, pseries_elog_sect_data_len(event_p));
+ return 1;
+}
+
+/*
+ * PAPR:
+ * - check-exception returns the first found error or event and clear that
+ * error or event so it is reported once.
+ * - Each interrupt returns one event. If a plateform chooses to report
+ * multiple events through a single interrupt, it must ensure that the
+ * interrupt remains asserted until check-exception has been used to
+ * process all out-standing events for that interrupt.
+ *
+ * Implementation notes:
+ * - Events must be processed in the order they are returned. Hence,
+ * sequential in nature.
+ * - The owner of an event is determined by the combination of scope,
+ * event type, and sub-type. There is no easy way to pre-sort clients
+ * by scope or event type alone. For example, Torrent ISR route change
+ * event is reported with scope 0x00 (Not Applicatable) rather than
+ * 0x3B (Torrent-hub). It is easier to let the clients to identify
+ * who owns the the event. This is bad for performance but we should
+ * only have a very small number of clients.
+ */
+
+static irqreturn_t ioei_interrupt(int irq, void *dev_id)
+{
+ struct pseries_io_event_sect_data *ioei_buf;
+ int status, event_valid;
+
+ ioei_buf = kmalloc(sizeof(struct pseries_io_event_sect_data),
+ GFP_ATOMIC);
+ /* Need to call rtas_call() to release IRQ even if kmalloc() failed. */
+ do {
+ spin_lock(&rtas_data_buf_lock);
+ status = rtas_call(ioei_check_exception_token, 6, 1, NULL,
+ RTAS_VECTOR_EXTERNAL_INTERRUPT,
+ virq_to_hw(irq),
+ RTAS_IO_EVENTS, 1 /* Time Critical */,
+ __pa(&rtas_data_buf),
+ RTAS_DATA_BUF_SIZE);
+ if ((status == 0) &&
+ ioei_get_event((struct rtas_error_log *) &rtas_data_buf,
+ ioei_buf))
+ event_valid = 1;
+ else
+ event_valid = 0;
+ spin_unlock(&rtas_data_buf_lock);
+ if (event_valid)
+ ioei_call_handlers(ioei_buf);
+ } while (status == 0);
+
+ if (ioei_buf)
+ kfree(ioei_buf);
+ return IRQ_HANDLED;
+}
+
+static int __init pseries_ioei_init_irq(void)
+{
+ struct device_node *np;
+
+ ioei_supported = 0;
+ ioei_check_exception_token = rtas_token("check-exception");
+ if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE) {
+ pr_warning("io_event_irq: No check-exception on system! "
+ "IO Event interrupt disabled.\n");
+ return -ENODEV;
+ }
+
+ np = of_find_node_by_path("/event-sources/ibm,io-events");
+ if (np) {
+ request_event_sources_irqs(np, ioei_interrupt, "IO_EVENT");
+ of_node_put(np);
+ } else {
+ pr_warning("io_event_irq: No ibm,io-events on system! "
+ "IO Event interrupt disabled.\n");
+ return -ENODEV;
+ }
+
+ ioei_supported = 1;
+
+ return 0;
+}
+
+machine_device_initcall(pseries, pseries_ioei_init_irq);
+
diff --git a/arch/powerpc/platforms/pseries/pseries_event_log.c b/arch/powerpc/platforms/pseries/pseries_event_log.c
new file mode 100644
index 0000000..c00837d
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/pseries_event_log.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright 2010 Tseng-Hui (Frank) Lin, IBM Corporation
+ *
+ * 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.
+ */
+
+/*
+ * IBM pSerie platform event log specific functions.
+ * All data in this file is in big endian.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+
+#include <asm/rtas.h>
+
+#include "pseries_event_log.h"
+
+/*
+ * Find the size of data portation in a platform event log section.
+ */
+size_t pseries_elog_sect_data_len(void *sect_data_p)
+{
+ struct pseries_elog_section *p;
+
+ p = container_of(sect_data_p, struct pseries_elog_section, sect_data);
+ return(p->length - offsetof(struct pseries_elog_section, sect_data));
+}
+
+/*
+ * Find data portion of a specific section in extended error/event log.
+ * Return:
+ * location of section data
+ * NULL if not found
+ */
+void *pseries_elog_find_section(
+ struct rtas_error_log_v6ext *v6ext, size_t v6ext_len,
+ uint16_t sect_id)
+{
+ struct pseries_elog_section *sect_p;
+ uint8_t *p, *log_end;
+
+ if ((v6ext_len < sizeof(struct rtas_error_log_v6ext)) ||
+ (v6ext->log_format != RTAS_V6EXT_LOG_FORMAT_EVENT_LOG) ||
+ (v6ext->company_id != RTAS_V6EXT_COMPANY_ID_IBM))
+ return NULL;
+
+ log_end = (uint8_t *) v6ext + v6ext_len;
+ p = (uint8_t *) v6ext->vendor_log;
+ while (p < log_end) {
+ sect_p = (struct pseries_elog_section *) p;
+ if (sect_p->id == sect_id)
+ return sect_p->sect_data;
+ p += sect_p->length;
+ }
+
+ return NULL;
+}
+
^ permalink raw reply related
* [PATCH v2 2/3] powerpc: add IBM specific v6 extended error log support
From: Tseng-Hui (Frank) Lin @ 2011-01-05 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tsenglin
This patch adds IBM specific v6 extended log definition and utilities.
Signed-off-by: Tseng-Hui (Frank) Lin <tsenglin@us.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 6 +
arch/powerpc/platforms/pseries/Makefile | 1 +
arch/powerpc/platforms/pseries/pseries_event_log.c | 62 +++++
arch/powerpc/platforms/pseries/pseries_event_log.h | 50 ++++
4 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index c667f0f..6f29642 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -37,6 +37,11 @@ config SCANLOG
tristate "Scanlog dump interface"
depends on RTAS_PROC && PPC_PSERIES
+config PSERIES_EVENT_LOG
+ bool
+ depends on PPC_PSERIES && RTAS_ERROR_LOGGING
+ default n
+
config LPARCFG
bool "LPAR Configuration Data"
depends on PPC_PSERIES || PPC_ISERIES
@@ -81,3 +86,4 @@ config DTL
which are accessible through a debugfs file.
Say N if you are unsure.
+
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 046ace9..1cc20ba 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
obj-$(CONFIG_DTL) += dtl.o
+obj-$(CONFIG_PSERIES_EVENT_LOG) += pseries_event_log.o
ifeq ($(CONFIG_PPC_PSERIES),y)
obj-$(CONFIG_SUSPEND) += suspend.o
diff --git a/arch/powerpc/platforms/pseries/pseries_event_log.c b/arch/powerpc/platforms/pseries/pseries_event_log.c
new file mode 100644
index 0000000..c00837d
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/pseries_event_log.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright 2010 Tseng-Hui (Frank) Lin, IBM Corporation
+ *
+ * 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.
+ */
+
+/*
+ * IBM pSerie platform event log specific functions.
+ * All data in this file is in big endian.
+ */
+
+#include <linux/kernel.h>
+#include <linux/types.h>
+
+#include <asm/rtas.h>
+
+#include "pseries_event_log.h"
+
+/*
+ * Find the size of data portation in a platform event log section.
+ */
+size_t pseries_elog_sect_data_len(void *sect_data_p)
+{
+ struct pseries_elog_section *p;
+
+ p = container_of(sect_data_p, struct pseries_elog_section, sect_data);
+ return(p->length - offsetof(struct pseries_elog_section, sect_data));
+}
+
+/*
+ * Find data portion of a specific section in extended error/event log.
+ * Return:
+ * location of section data
+ * NULL if not found
+ */
+void *pseries_elog_find_section(
+ struct rtas_error_log_v6ext *v6ext, size_t v6ext_len,
+ uint16_t sect_id)
+{
+ struct pseries_elog_section *sect_p;
+ uint8_t *p, *log_end;
+
+ if ((v6ext_len < sizeof(struct rtas_error_log_v6ext)) ||
+ (v6ext->log_format != RTAS_V6EXT_LOG_FORMAT_EVENT_LOG) ||
+ (v6ext->company_id != RTAS_V6EXT_COMPANY_ID_IBM))
+ return NULL;
+
+ log_end = (uint8_t *) v6ext + v6ext_len;
+ p = (uint8_t *) v6ext->vendor_log;
+ while (p < log_end) {
+ sect_p = (struct pseries_elog_section *) p;
+ if (sect_p->id == sect_id)
+ return sect_p->sect_data;
+ p += sect_p->length;
+ }
+
+ return NULL;
+}
+
diff --git a/arch/powerpc/platforms/pseries/pseries_event_log.h b/arch/powerpc/platforms/pseries/pseries_event_log.h
new file mode 100644
index 0000000..e7fc452
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/pseries_event_log.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2010 Tseng-Hui (Frank) Lin, IBM Corporation
+ *
+ * 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.
+ */
+
+#ifndef _PSERIES_PSERIES_EVENT_LOG_H
+#define _PSERIES_PSERIES_EVENT_LOG_H
+
+#include <linux/types.h>
+
+#include <asm/rtas.h>
+
+/* Two bytes ASCII section IDs */
+#define PSERIES_ELOG_SECT_ID_PRIV_HDR (('P' << 8) | 'H')
+#define PSERIES_ELOG_SECT_ID_USER_HDR (('U' << 8) | 'H')
+#define PSERIES_ELOG_SECT_ID_PRIMARY_SRC (('P' << 8) | 'S')
+#define PSERIES_ELOG_SECT_ID_EXTENDED_UH (('E' << 8) | 'H')
+#define PSERIES_ELOG_SECT_ID_FAILING_MTMS (('M' << 8) | 'T')
+#define PSERIES_ELOG_SECT_ID_SECONDARY_SRC (('S' << 8) | 'S')
+#define PSERIES_ELOG_SECT_ID_DUMP_LOCATOR (('D' << 8) | 'H')
+#define PSERIES_ELOG_SECT_ID_FW_ERROR (('S' << 8) | 'W')
+#define PSERIES_ELOG_SECT_ID_IMPACT_PART_ID (('L' << 8) | 'P')
+#define PSERIES_ELOG_SECT_ID_LOGIC_RESOURCE_ID (('L' << 8) | 'R')
+#define PSERIES_ELOG_SECT_ID_HMC_ID (('H' << 8) | 'M')
+#define PSERIES_ELOG_SECT_ID_EPOW (('E' << 8) | 'P')
+#define PSERIES_ELOG_SECT_ID_IO_EVENT (('I' << 8) | 'E')
+#define PSERIES_ELOG_SECT_ID_MANUFACT_INFO (('M' << 8) | 'I')
+#define PSERIES_ELOG_SECT_ID_CALL_HOME (('C' << 8) | 'H')
+#define PSERIES_ELOG_SECT_ID_USER_DEF (('U' << 8) | 'D')
+
+/* Vendor specific Platform Error/Event Log Format, Version 6, section header */
+
+struct pseries_elog_section {
+ uint16_t id; /* 0x00 2-byte ASCII section ID */
+ uint16_t length; /* 0x02 Section length in bytes */
+ uint8_t version; /* 0x04 Section version */
+ uint8_t subtype; /* 0x05 Section subtype */
+ uint16_t creator_component; /* 0x06 Creator component ID */
+ uint8_t sect_data[1]; /* 0x08 Start of section data */
+};
+
+size_t pseries_elog_sect_data_len(void *sect_data);
+void *pseries_elog_find_section(struct rtas_error_log_v6ext *v6ext,
+ size_t v6ext_len, uint16_t sect_id);
+
+#endif /* _PSERIES_PSERIES_EVENT_LOG_H */
^ permalink raw reply related
* [PATCH v2 1/3] powerpc: Add v6 extended error log definitions
From: Tseng-Hui (Frank) Lin @ 2011-01-05 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tsenglin
This patch adds definitions of non-IBM specific v6 extended log definitions to rtas.h.
Signed-off-by: Tseng-Hui (Frank) Lin <tsenglin@us.ibm.com>
---
arch/powerpc/include/asm/rtas.h | 45 ++++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 3d35f8a..181e32a 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -158,7 +158,50 @@ struct rtas_error_log {
unsigned long target:4; /* Target of failed operation */
unsigned long type:8; /* General event or error*/
unsigned long extended_log_length:32; /* length in bytes */
- unsigned char buffer[1];
+ unsigned char buffer[1]; /* Start of extended log */
+ /* Variable length. */
+};
+
+#define RTAS_V6EXT_LOG_FORMAT_EVENT_LOG 14
+
+#define RTAS_V6EXT_COMPANY_ID_IBM (('I' << 24) | ('B' << 16) | ('M' << 8))
+
+/* RTAS extended error/event log, Version 6. The extended log starts
+ * from "buffer" field of struct rtas_error_log defined above.
+ */
+struct rtas_error_log_v6ext {
+ /* Byte 0 */
+ uint32_t log_valid:1; /* 1:Log valid */
+ uint32_t unrecoverable_error:1; /* 1:Unrecoverable error */
+ uint32_t recoverable_error:1; /* 1:recoverable (correctable */
+ /* or successfully retried) */
+ uint32_t degraded_operation:1; /* 1:Unrecoverable err, bypassed*/
+ /* - degraded operation (e.g. */
+ /* CPU or mem taken off-line) */
+ uint32_t predictive_error:1;
+ uint32_t new_log:1; /* 1:"New" log (Always 1 for */
+ /* data returned from RTAS */
+ uint32_t big_endian:1; /* 1: Big endian */
+ uint32_t :1; /* reserved */
+ /* Byte 1 */
+ uint32_t :8; /* reserved */
+ /* Byte 2 */
+ uint32_t powerpc_format:1; /* Set to 1 (indicating log is */
+ /* in PowerPC format */
+ uint32_t :3; /* reserved */
+ uint32_t log_format:4; /* Log format indicator. Define */
+ /* format used for byte 12-2047 */
+ /* Byte 3 */
+ uint32_t :8; /* reserved */
+ /* Byte 4-11 */
+ uint8_t reserved[8]; /* reserved */
+ /* Byte 12-15 */
+ uint32_t company_id; /* Company ID of the company */
+ /* that defines the format for */
+ /* the vendor specific log type */
+ /* Byte 16-end of log */
+ uint8_t vendor_log[1]; /* Start of vendor specific log */
+ /* Variable length. */
};
/*
^ permalink raw reply related
* [PATCH v2 0/3] powerpc: Add IO event interrupt support
From: Tseng-Hui (Frank) Lin @ 2011-01-05 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tsenglin
This series of patches adds support for handling IO Event interrupts which
come through at the /event-sources/ibm,io-events device tree node.
Change log from v1:
- Restructure the patch into 3 patches.
= Move non-IBM specific v6 extended log definition to rtas.h.
= Move IBM specific v6 extended log definition to pseries_event_log.h
and code to pseries_event_log.c.
- Add CONFIG_PSERIES_EVENT_LOG to pseries Kconfig
- Add CONFIG_IO_EVENT_IRQ to pseries Kconfig
io_events.h:
- Change C++ comments to C format.
- Add definitions for all known type, sub-types, and scopes.
- Change data type of rpc_data from u32 to u8 as the size of rpc_data is
specified in rpc_field_len in bytes.
- Set maximum length for rpc_data.
- Change ioei_register_isr() and ioei_unregister_isr() declearation to match
the change in io_events.c file
io_events.c:
- Use pseries_/PSERIES_ prefix for global symbols.
- Change to use list_head for ioei_consumer list.
- Remove scope from handler registeration.
- Change device_initcall() to machine_device_initcall()
- ioei_register_handler():
= Return -ENODEV if IOEI not supported on the machine.
= Change use spin_lock() to use spin_lock_irq().
- ioei_unregister_handler():
= Change use spin_lock() to use spin_lock_irq().
- ioei_call_consumers():
= Change spin_lock_irqsave() to spin_lock() because we are called from
an interrupt handler.
= Return IRQ_HANDLED/IRQ_NONE if interrupt is handled/not handled.
= Print an error message if no one claims the interrupt.
- io_event_interrupt():
= Change to use rtas_data_buf and RTAS_DATA_BUF_SIZE for rtas_call().
= Loop calling rtas_call() to pull in multiple events in one interrupt.
= Split IO event section searching code into ioei_get_event().
- init_ioei_IRQ()
= Check rtas_token() return code.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
Signed-off-by: Tseng-Hui (Frank) Lin <tsenglin@us.ibm.com>
---
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-05 22:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <20101223223325.GK20384@angua.secretlab.ca>
On 12/23/2010 04:33 PM, Grant Likely wrote:
> This argument has been rehashed many times, but it basically comes
> down to compatible values should ideally be anchored to a real
> implemented device, not to a family of devices, or to an unversioned
> specification.
>
> In practise, the implementation doesn't actually look any different
> except that the 'reference' version specifies a specific
> implementation instead of a generic name. To use a concrete example,
> if there are two parts using this MPIC, like the freescale p2040 and
> p4080, and say for argument that the p2040 was implemented first, then
> the compatible values would look like:
>
> for the p2040: compatible = "fsl,p2040-msgr";
> for the p4080: compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";
>
> and the driver could simply bind on "fsl,p2040-msgr" to work with both
> chips. So, instead of an arbitrary "fsl,mpic-msgr" string,
> "fsl,p2040-msgr" is used as the baseline value and there is no
> ambiguity about which part it describes.
>
> If the p4080 is actually subtly different from the p2040, then
> it would not claim compatibility with the former and the driver can
> match against either string; adapting its behaviour as necessary.
Thanks for the explanation. I see now that there is a warning note in
'http://www.devicetree.org/Device_Tree_Usage' about this case. Perhaps
a "best practices" guide for writing bindings might be useful as well.
I would be happy to contribute to that, but I am still learning the best
practices :)
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-05 22:09 UTC (permalink / raw)
To: Meador Inge; +Cc: Blanchard, Hollis, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D24E99F.90908@mentor.com>
On Wed, 5 Jan 2011 15:58:55 -0600
Meador Inge <meador_inge@mentor.com> wrote:
> We need some sort of mapping between a message register and a message
> register number so that the message registers can be referenced through
> some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that would
> be by putting an order on the registers. Maybe there is a better way,
> though ...
A message register is uniquely identified by a reference to the device
tree node, plus a 0-3 index into that node's message registers.
-Scott
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-05 21:58 UTC (permalink / raw)
To: Scott Wood; +Cc: Blanchard, Hollis, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110103135120.32aeb60d@udp111988uds.am.freescale.net>
On 01/03/2011 01:51 PM, Scott Wood wrote:
> On Thu, 23 Dec 2010 15:33:25 -0700
> Grant Likely<grant.likely@secretlab.ca> wrote:
>
>> On Thu, Dec 23, 2010 at 03:49:54PM -0600, Meador Inge wrote:
>>> How do you
>>> see this working in terms of processing the data? It seems like we
>>> are going to have to be aware of N values instead of 1, which seems
>>> worse.
>>
>> This argument has been rehashed many times, but it basically comes
>> down to compatible values should ideally be anchored to a real
>> implemented device, not to a family of devices, or to an unversioned
>> specification.
>
> Freescale MPICs do have version numbers (version registers, even). We
> should put that version (possibly along with a compatible version) in
> the compatible, though, for blocks such as this which don't include the
> main MPIC registers and thus the version registers.
I like that better than claiming compatibility with other chips. I will
incorporate that idea. Thanks.
>> In practise, the implementation doesn't actually look any different
>> except that the 'reference' version specifies a specific
>> implementation instead of a generic name. To use a concrete example,
>> if there are two parts using this MPIC, like the freescale p2040 and
>> p4080, and say for argument that the p2040 was implemented first, then
>> the compatible values would look like:
>>
>> for the p2040: compatible = "fsl,p2040-msgr";
>> for the p4080: compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";
>
> While I don't think it affected the message unit, p4080 rev 1 has a
> different version of the MPIC from p4080 rev 2 (4.0 versus 4.1, IIRC).
>
> I don't think "mpic-" should be dropped, whether a specific chip is
> added or not. "msgr" just seems too generic, and "mpic-" tells the
> reader where in the chip manual they can find information about it.
Agreed.
>>>> ? This needs some more explanation. cell-index often gets abused as
>>>> a way to enumerate devices. Typically, the address of the device
>>>> itself is sufficient to identify the device.
>>>
>>> The message registers typically come in blocks of four memory mapped
>>> registers and may not be in contiguous memory (example [3]). The
>>> intent of 'cell-index' is to put an ordering on the blocks (so, yes,
>>> enumeration). We could order them by address as well I suppose.
>>> One less property to worry about :)
>
> But why do we care about ordering them? What's important is just that
> you use the same one on both the sending partition and the receiving
> partition.
We need some sort of mapping between a message register and a message
register number so that the message registers can be referenced through
some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that would
be by putting an order on the registers. Maybe there is a better way,
though ...
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-05 21:19 UTC (permalink / raw)
To: Scott Wood; +Cc: Blanchard, Hollis, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110104181346.2a9ab036@udp111988uds.am.freescale.net>
On 01/04/2011 06:13 PM, Scott Wood wrote:
> On Tue, 4 Jan 2011 17:52:38 -0600
> Meador Inge<meador_inge@mentor.com> wrote:
>
>> Thanks for the feedback Scott.
>>
>> On 01/03/2011 02:22 PM, Scott Wood wrote:
>>> On Wed, 22 Dec 2010 23:58:09 -0600
>>> These nodes cannot go under the mpic node, because interrupt
>>> controllers need #address-cells =<0>.
>>
>> Good point. Do they actually need it or is that just the way it
>> currently is? [1] mandates it, I didn't see anything in [2] and I can't
>> access [3].
>
> It's because of the way interrupt maps work -- a full interrupt
> specifier includes the node's reg address as well as the values in the
> interrupts property. This is useful for things like PCI controllers,
> but normal interrupt controllers won't have any use for it.
>
> In theory, I suppose you could have a non-zero #address-cells in an
> interrupt controller, but then you'd have to pad the parent interrupt
> specifiers in any interrupt map entries that point at the MPIC node with
> that many don't-care cells.
>
> Better to just avoid the issue.
Agreed, it would be nasty to have padding for this.
>> However, AFAIK '#address-cells' is taken directly from the parent node
>> and is not inherited from ancestors higher in the tree. So another
>> option would be to do something like:
>>
>> mpic: pic@40000 {
>> ...
>> message-registers@0 {
>> #address-cells =<1>;
>> #size-cells =<1>;
>>
>> msgr@1400 {
>> compatible = "fsl,mpic-v3.0-msgr";
>> reg =<0x1400 0x200>;
>> interrupts =<0xb0 0x2 0xb1 0x2 0xb2 0x2 0xb3 0x2>;
>> };
>>
>> msgr@2400 {
>> compatible = "fsl,mpic-v3.0-msgr";
>> reg =<0x2400 0x200>;
>> interrupts =<0xb4 0x2 0xb5 0x2 0xb6 0x2 0xb7 0x2>;
>> };
>> };
>> };
>
> Won't work, the reg addresses need to be translatable through ranges all
> the way up to the root.
Ah, I see. This is because we would have to add 'ranges' on
'message-registers' and 'pic', but 'pic' needs to have '#address-cells'
> 0 to interpret 'ranges'. Fun :) I will hoist the message registers
nodes out of the MPIC node.
>> I like the nesting as it models the physical relationship closer and
>> creates a clean namespace.
>
> Sure, if it weren't for the #address-cells issue I'd agree.
>
>>> It would be nice if the binding provided some way of partitioning
>>> up individual message interrupts within a block.
>>>
>>> Interrupt generation could be exported as a "service", similar to
>>> (inbound) interrupts and gpios.
>>>
>>> Perhaps a something like this, with "doorbell" being a new standard
>>> hw-independent service with its own binding:
>>
>> I need to think about this proposal more, but our original intent was to
>> just have a simple description of the message registers in the device
>> tree and the policy for how those message registers are used is in
>> software (not necessarily an exact API use case, but you get the point):
>
> That may be fine for your use case (just as some people may be happy
> to hardcode device knowledge into their kernel), but in the general case
> inter-partition protocols are effectively a non-probeable part of the
> "hardware" the partition runs on. It's good to have a standard way of
> labelling what goes where. The details of the protocol would still be
> in software, referenced by the compatible string on the protocol node.
>
>> /* Core 0 */
>> mpic_msgr_reserve(0);
>> mpic_msgr_reserve(1);
>>
>> /* Send message to Core 1 */
>> mpic_msgr_write(3, 13);
>>
>> /* Read a value */
>> u32 value;
>> mpic_msgr_read(0,&value);
>>
>> /* Free the register */
>> mpic_msgr_release(0);
>> ...
>>
>> /* Core 1 */
>> mpic_msgr_reserve(3);
>> mpic_msgr_reserve(4);
>>
>> /* Send message to Core 0 */
>> mpic_msgr_write(0, 1);
>
> You're hardcoding into software that core 0 gets msg0 and msg1, and
> core 1 gets msg3 and msg4, etc. Not much different than hardcoding that
> core 0 gets enet0 and core 1 gets enet1 and enet2.
>
>> Note that a "reservation" is still isolated to a particular core, e.g.
>> 'mpic_msgr_reserve(0)' on core 0 will not cause 'mpic_msgr_reserve(0)'
>> to fail on another core. Where as two invocations of
>> 'mpic_msgr_reserve(0)' on the same core without an interleaved
>> 'mpic_msgr_release(0)' would, of course, fail.
>
> So basically, you're assigning the resource to both partitions, and
> relying on dynamic cooperation. That's fine, in that case both
> partitions would see the resource in their device tree, hopefully along
> with something to indicate what the situation is. But dedicated
> ownership is common enough, and similar enough to the question of
> whether the hardware exists at all, that it's nice to be able to express
> it in the device tree. It also makes it easier to deal with situations
> where you later want to plug in different hardware (or possibly a
> virtualized interface) underneath the protocol.
I agree that it would be nice to have some elements of the protocol
represented in the device tree. I would just like to do this in small
steps. We are going to need the data in the device tree for the message
registers no matter what. We are also going to need a simple API for
interfacing with the registers. The bottom layer so to speak. These
building blocks can be utilized later by a higher-level protocol if need
be. For now I would just like to propose the MPIC bindings, the initial
message register bindings, and the message registers API. Sound good?
> I'm not sure how much practical benefit there is to dynamically
> allocating message registers across partitions, though -- you'd have
> to have some way of communicating to the other end the result of the
> allocation, so it knows which one to send a message on. And if you
> only have 2 cores, and unhypervised AMP, you'll be able to dedicate 4
> message registers to each partition...
Hollis and I discussed that a bit already. The problem with our use
case (and presumably others) is that we are using the message registers
to aid in communicating over shared memory. If we go into dynamic
allocation of message registers across partitions, then we need to
coordinate between the partitions across shared memory. So you need
shared memory communication to setup shared memory communication. Also,
if we just get the basic pieces in place with the message register API
('reserve', 'release', 'read', 'write', etc...) we can perhaps figure
out a way to build a dynamically allocator on top of those services
later, if need be.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-05 18:23 UTC (permalink / raw)
To: Rafael Beims; +Cc: linuxppc-dev
In-Reply-To: <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1758 bytes --]
Hi
On 01/05/2011 07:09 PM, Rafael Beims wrote:
> Hello all,
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
> Monitoring the network packets, I can see that the nfs protocol is exchanged
> just fine, but at some time it simply stops, starting again with a request
> from the board several seconds later.
> I'm thinking that the processor is running (something, I don't know what)
> for all this time before I can see requests coming from the board again. I
> pinged the board from the PC and during all this I can see the packets being
> answered.
>
Can you try this patch?
> My question to all is, did anyone see something like this already? Besides
> that, what is the status of the linux kernel support for the 8xx platform?
> Is it being actively tested / used today? I ask this because it seems that
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
>
> Is there something that I can do to try to narrow the cause of the problem?
>
> Anyway, any help would be truly appreciated. Please excuse me if this is not
> the right place to ask this too.
>
> Thanks and best regards,
> Rafael Beims
> rbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #1.2: Type: text/html, Size: 2624 bytes --]
[-- Attachment #2: slowdown.patch --]
[-- Type: text/x-diff, Size: 2703 bytes --]
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index dd5ea95..cb67076 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -32,7 +32,7 @@
#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
-#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
+#define _PAGE_SPECIAL 0x0000 /* SW entry, forced to 0 by the TLB miss */
/* These five software bits must be masked out when the entry is loaded
* into the TLB.
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index f2b3701..3b88376 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -176,5 +176,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#define HAVE_PAGE_AGP
/* Advertise support for _PAGE_SPECIAL */
+#if _PAGE_SPECIAL != 0
#define __HAVE_ARCH_PTE_SPECIAL
+#endif
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 5304093..1da03a8 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
cpu_has_feature(CPU_FTR_NOEXECUTE))) {
- struct page *pg = maybe_pte_to_page(pte);
- if (!pg)
+ unsigned long pfn = pte_pfn(pte);
+ struct page *pg;
+
+ if (unlikely(!pfn_valid(pfn)))
return pte;
- if (!test_bit(PG_arch_1, &pg->flags)) {
+
+ pg = pfn_to_page(pfn);
#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
- * "dcbst" from flush_dcache_icache) fault as write
- * operation if there is an unpopulated TLB entry
- * for the address in question. To workaround that,
- * we invalidate the TLB here, thus avoiding dcbst
- * misbehaviour.
- */
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
+ /* On 8xx, cache control instructions (particularly
+ * "dcbst" from flush_dcache_icache) fault as write
+ * operation if there is an unpopulated TLB entry
+ * for the address in question. To workaround that,
+ * we invalidate the TLB here, thus avoiding dcbst
+ * misbehaviour.
+ */
+ /* 8xx doesn't care about PID, size or ind args */
+ _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */
+
+ if (!pg)
+ return pte;
+
+ if (!PageReserved(pg) && !test_bit(PG_arch_1, &pg->flags)) {
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
^ permalink raw reply related
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-05 19:22 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Rafael Beims, linuxppc-dev
In-Reply-To: <20110105183506.07BB815243A@gemini.denx.de>
Hi
On 01/05/2011 07:35 PM, Wolfgang Denk wrote:
> Dear Rafael Beims,
>
> In message<AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com> you wrote:
>> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
>> some work, I could get the kernel up and running, mounting a rootfs via
>> NFS.
> 2.6.32 is pretty old. Is there any specific reason for not using a
> recent kernel version?
>
I think that all the kernel version has the same problem
>> The problem that I'm facing now is that when I try to run any process (may
>> be an ls, cat, or whatever), the response of the process is *very* slow
>> (something like 10 to 20 seconds for a ls).
> This sounds as if only the output to the (serial ?) console port was
> slow - typically this happens when there is a problem with interrupt
> assignment, and you receive charatcers only after each of these times
> out.
>
It is not a serial/console/interrupt problem
>> My question to all is, did anyone see something like this already? Besides
> We have seen this many times in the past, when interrupts were not
> working correctly. I recommend to check youyr device tree settings
> for these.
>
> [It would have helped if you had included a log of your kernel's boot
> messages.]
>
>> that, what is the status of the linux kernel support for the 8xx platform?
> It is working and actively maintained, but 8xx is a platform that is
> more or less hopelessly obsoleted - nobody uses it in new designs any
> more, so there is little work going on with it in recent kernel
> versions (at least compared with other architectures).
>
agree, this architecture is basically dead
>> Is it being actively tested / used today? I ask this because it seems that
> Yes, it is.
>
>> all the information on the internet very aged (forum discussions from 2005
>> and below mostly).
>> Is there something that I can do to try to narrow the cause of the problem?
> Check your interrupts.
>
> Best regards,
>
> Wolfgang Denk
>
Michael Trimarchi
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-05 19:13 UTC (permalink / raw)
To: Rafael Beims; +Cc: LinuxPPC-Dev
In-Reply-To: <AANLkTi=uvunJ-ZFVGHZZExgBaNL9Sh0uZ3OiiCrcPnx=@mail.gmail.com>
Hi
On 01/05/2011 07:43 PM, Rafael Beims wrote:
> Wow! That was fast!
> I applied the patch and it worked very well. Now I can use the commands
> normally.
> I will be doing more tests in the next days, but it seems that my problem is
> solved.
>
> Is this patch already mainstream in newer kernel versions?
>
Not yet, because I was moved to another project
Michael Trimarchi
> Thanks again,
> Rafael Beims
> rbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
> On Wed, Jan 5, 2011 at 4:23 PM, michael<michael@evidence.eu.com> wrote:
>
>> Hi
>>
>> On 01/05/2011 07:09 PM, Rafael Beims wrote:
>>
>> Hello all,
>> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
>> some work, I could get the kernel up and running, mounting a rootfs via
>> NFS.
>> The problem that I'm facing now is that when I try to run any process (may
>> be an ls, cat, or whatever), the response of the process is *very* slow
>> (something like 10 to 20 seconds for a ls).
>> Monitoring the network packets, I can see that the nfs protocol is exchanged
>> just fine, but at some time it simply stops, starting again with a request
>> from the board several seconds later.
>> I'm thinking that the processor is running (something, I don't know what)
>> for all this time before I can see requests coming from the board again. I
>> pinged the board from the PC and during all this I can see the packets being
>> answered.
>>
>>
>> Can you try this patch?
>>
>> My question to all is, did anyone see something like this already? Besides
>> that, what is the status of the linux kernel support for the 8xx platform?
>> Is it being actively tested / used today? I ask this because it seems that
>> all the information on the internet very aged (forum discussions from 2005
>> and below mostly).
>>
>> Is there something that I can do to try to narrow the cause of the problem?
>>
>> Anyway, any help would be truly appreciated. Please excuse me if this is not
>> the right place to ask this too.
>>
>> Thanks and best regards,
>> Rafael Beimsrbeims@gmail.com
>> (41) 8873-7565
>> "What I hear, I forget. What I see, I remember. And what I do, I
>> understand."
>> - Chinese Proverb
>>
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-05 18:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20110105183506.07BB815243A@gemini.denx.de>
Hello Mr. Denk
As I already posted, the patch that was posted before seems to have
solved the problem. Anyway, some answers follow:
On Wed, Jan 5, 2011 at 4:35 PM, Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Rafael Beims,
>
> In message <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>=
you wrote:
> >
> > I'm working with an MPC880 board that is supposed to run linux-2.6.32. =
After
> > some work, I could get the kernel up and running, mounting a rootfs via
> > NFS.
>
> 2.6.32 is pretty old. =A0Is there any specific reason for not using a
> recent kernel version?
>
The company that I work for uses some kernel versions in favor of
others... Maybe with time we can change that, but for now I need to
use this version.
> > The problem that I'm facing now is that when I try to run any process (=
may
> > be an ls, cat, or whatever), the response of the process is *very* slow
> > (something like 10 to 20 seconds for a ls).
>
> This sounds as if only the output to the (serial ?) console port was
> slow - typically this happens when there is a problem with interrupt
> assignment, and you receive charatcers only after each of these times
> out.
>
> > My question to all is, did anyone see something like this already? Besi=
des
>
> We have seen this many times in the past, when interrupts were not
> working correctly. =A0I recommend to check youyr device tree settings
> for these.
>
> [It would have helped if you had included a log of your kernel's boot
> messages.]
>
> > that, what is the status of the linux kernel support for the 8xx platfo=
rm?
>
> It is working and actively maintained, but 8xx is a platform that is
> more or less hopelessly obsoleted - nobody uses it in new designs any
> more, so there is little work going on with it in recent kernel
> versions (at least compared with other architectures).
>
> > Is it being actively tested / used today? I ask this because it seems t=
hat
>
> Yes, it is.
This is very nice, because this way we can be more confident that
everything will work as it should.
>
> > all the information on the internet very aged (forum discussions from 2=
005
> > and below mostly).
>
> > Is there something that I can do to try to narrow the cause of the prob=
lem?
>
> Check your interrupts.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Never underestimate the power of human stupidity =A0when =A0it =A0comes =
=A0to
> using technology they don't understand.
Thank you very much for the answers!
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I understand=
."
- Chinese Proverb
^ permalink raw reply
* Fwd: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-05 18:45 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTi=uvunJ-ZFVGHZZExgBaNL9Sh0uZ3OiiCrcPnx=@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]
I forgot to copy the list, sorry...
---------- Forwarded message ----------
From: Rafael Beims <rbeims@gmail.com>
Date: Wed, Jan 5, 2011 at 4:43 PM
Subject: Re: mpc880 linux-2.6.32 slow running processes
To: michael <michael@evidence.eu.com>
Wow! That was fast!
I applied the patch and it worked very well. Now I can use the commands
normally.
I will be doing more tests in the next days, but it seems that my problem is
solved.
Is this patch already mainstream in newer kernel versions?
Thanks again,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb
On Wed, Jan 5, 2011 at 4:23 PM, michael <michael@evidence.eu.com> wrote:
> Hi
>
> On 01/05/2011 07:09 PM, Rafael Beims wrote:
>
> Hello all,
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
> Monitoring the network packets, I can see that the nfs protocol is exchanged
> just fine, but at some time it simply stops, starting again with a request
> from the board several seconds later.
> I'm thinking that the processor is running (something, I don't know what)
> for all this time before I can see requests coming from the board again. I
> pinged the board from the PC and during all this I can see the packets being
> answered.
>
>
> Can you try this patch?
>
> My question to all is, did anyone see something like this already? Besides
> that, what is the status of the linux kernel support for the 8xx platform?
> Is it being actively tested / used today? I ask this because it seems that
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
>
> Is there something that I can do to try to narrow the cause of the problem?
>
> Anyway, any help would be truly appreciated. Please excuse me if this is not
> the right place to ask this too.
>
> Thanks and best regards,
> Rafael Beimsrbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
>
> _______________________________________________
> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 3732 bytes --]
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Wolfgang Denk @ 2011-01-05 18:35 UTC (permalink / raw)
To: Rafael Beims; +Cc: linuxppc-dev
In-Reply-To: <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>
Dear Rafael Beims,
In message <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com> you wrote:
>
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
2.6.32 is pretty old. Is there any specific reason for not using a
recent kernel version?
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
This sounds as if only the output to the (serial ?) console port was
slow - typically this happens when there is a problem with interrupt
assignment, and you receive charatcers only after each of these times
out.
> My question to all is, did anyone see something like this already? Besides
We have seen this many times in the past, when interrupts were not
working correctly. I recommend to check youyr device tree settings
for these.
[It would have helped if you had included a log of your kernel's boot
messages.]
> that, what is the status of the linux kernel support for the 8xx platform?
It is working and actively maintained, but 8xx is a platform that is
more or less hopelessly obsoleted - nobody uses it in new designs any
more, so there is little work going on with it in recent kernel
versions (at least compared with other architectures).
> Is it being actively tested / used today? I ask this because it seems that
Yes, it is.
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
> Is there something that I can do to try to narrow the cause of the problem?
Check your interrupts.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Never underestimate the power of human stupidity when it comes to
using technology they don't understand.
^ permalink raw reply
* mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-05 18:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
Hello all,
I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.
The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).
Monitoring the network packets, I can see that the nfs protocol is exchanged
just fine, but at some time it simply stops, starting again with a request
from the board several seconds later.
I'm thinking that the processor is running (something, I don't know what)
for all this time before I can see requests coming from the board again. I
pinged the board from the PC and during all this I can see the packets being
answered.
My question to all is, did anyone see something like this already? Besides
that, what is the status of the linux kernel support for the 8xx platform?
Is it being actively tested / used today? I ask this because it seems that
all the information on the internet very aged (forum discussions from 2005
and below mostly).
Is there something that I can do to try to narrow the cause of the problem?
Anyway, any help would be truly appreciated. Please excuse me if this is not
the right place to ask this too.
Thanks and best regards,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb
[-- Attachment #2: Type: text/html, Size: 1703 bytes --]
^ permalink raw reply
* Re: powerpc: Per process DSCR
From: Alexey Kardashevskiy @ 2011-01-05 7:21 UTC (permalink / raw)
To: linuxppc-dev
joining the thread...
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ 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