* 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: 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 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
* [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
* [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 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 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
* 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
* 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
* [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: [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
* 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: 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: 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: [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: [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
* RapidIO: question about rionet probe call
From: Thomas Taranowski @ 2011-01-06 8:26 UTC (permalink / raw)
To: linuxppc-dev
I'm doing some work to support multiple mport architectures, and have
run into an issue where the rionet_probe() function isn't being
called, so my rionet net device never get's created. I've also
verified that the rio_device_probe() isn't being called either.
The low level rio bus driver initializes and probes correctly, and
creates the required entries in sysfs. Then, later, I see the
rionet_init get called and return success, indicating it registered
with the rapidio bus correctly, so everything looks good.
I see the following output (extra debug prints added) , indicating the
rionet driver is being added, but it never gets probed afterward.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~ rio_register_driver ~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
bus: 'rapidio': add driver rionet
initializing klist
init and added kobj, err=0
driver_create_file err=0
driver added attrs, err=0
returning 0
RIO: rionet_init rio_register_driver: rc=0
Any ideas on why rionet isn't being probed? Is rionet currently working?
I'm running a 2.6.36-rc8 baseline.
Thanks,
Thomas Taranowski
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-06 12:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Rafael Beims, Rex Feany
In-Reply-To: <20110105174256.29fd378a@udp111988uds.am.freescale.net>
Hi
On 01/06/2011 12:42 AM, Scott Wood wrote:
> 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?
>
Only the set_pte_filter doesn't fix the problem. The slow-down depends on
the __HAVE_ARCH_PTE_SPECIAL related code, but 2 months ago I didn't find the reason
and now I don't have the architecture. I will do some tests when I will came back in Italy.
>> 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
>
Michael
^ permalink raw reply
* DMA implementation on MPC8572
From: deebul nair @ 2011-01-06 14:24 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Hi all
I am using the MPC8572 processor.
I wanted to use the DMA functionality in the powerpc board for talking to a
FPGA device connected on the loacl bus.
I have compiled the fsldma.c code and inserted it.
On insertion the driver probes all the dma channels
Can anyone tell me how to test the driver and also how to use the driver?
--
Cheeers
Deebul !!!!!!
[-- Attachment #2: Type: text/html, Size: 481 bytes --]
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Joakim Tjernlund @ 2011-01-06 16:52 UTC (permalink / raw)
To: michael; +Cc: scottwood, linuxppc-dev, RFeany, rbeims
In-Reply-To: <4D25BB08.7000001@evidence.eu.com>
>>> + /* On 8xx, cache control instructions (particularly
>>> + * "dcbst" from flush=5Fdcache=5Ficache) 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 */
>>> + =5Ftlbil=5Fva(addr, 0, 0, 0);
>>> #endif /* CONFIG=5F8xx */
>>> +
>>> + if (!pg)
>>> + return pte;
>>> +
>>> + if (!PageReserved(pg)&& !test=5Fbit(PG=5Farch=5F1,&pg->flags)) {
>>> flush=5Fdcache=5Ficache=5Fpage(pg);
>>> set=5Fbit(PG=5Farch=5F1,&pg->flags);
>>> }
>> Rex, do you recall under what specific circumstances the =5Ftlbil=5Fva 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=5Farch=5F1?
The 8xx tlbil=5Fva should not be needed in recent 2.6 after I fixed the 8xx=
TLB code
to workaround the dcbst bug there instead. See=20
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98c3=
7d03a4a7c5a3f8b1e3b8e5
Not sure what release it went into though.
Jocke=
=
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Fix SPRG get/set for Book3S and BookE
From: Marcelo Tosatti @ 2011-01-06 16:39 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, kvm, kvm-ppc, agraf
In-Reply-To: <1293652285-13313-1-git-send-email-ptyser@xes-inc.com>
On Wed, Dec 29, 2010 at 01:51:25PM -0600, Peter Tyser wrote:
> Previously SPRGs 4-7 were improperly read and written in
> kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> I noticed this while grepping for somthing unrelated and assume its
> a typo. Feel free to add to the patch description; I don't use KVM
> so don't know what the high-level consequences of this change are.
>
> arch/powerpc/kvm/book3s.c | 14 ++++++++------
> arch/powerpc/kvm/booke.c | 14 ++++++++------
> 2 files changed, 16 insertions(+), 12 deletions(-)
Applied, thanks.
^ permalink raw reply
* RE: RapidIO: question about rionet probe call
From: Bounine, Alexandre @ 2011-01-06 19:43 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTi=ns4-bz1JBdzjX0tvqNuEDRiM6UpmzMu_Fr8cw@mail.gmail.com>
Did you change anything in RIO initialization sequence?
For multiple mport support I had to adjust rio_init_mports/rio_init
sequence.
Alex.
> -----Original Message-----
> From: =
linuxppc-dev-bounces+alexandre.bounine=3Didt.com@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+alexandre.bounine=3Didt.com@lists.ozlabs.org] On Behalf Of
Thomas Taranowski
> Sent: Thursday, January 06, 2011 3:27 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: RapidIO: question about rionet probe call
>=20
> I'm doing some work to support multiple mport architectures, and have
> run into an issue where the rionet_probe() function isn't being
> called, so my rionet net device never get's created. I've also
> verified that the rio_device_probe() isn't being called either.
>=20
> The low level rio bus driver initializes and probes correctly, and
> creates the required entries in sysfs. Then, later, I see the
> rionet_init get called and return success, indicating it registered
> with the rapidio bus correctly, so everything looks good.
>=20
>=20
> I see the following output (extra debug prints added) , indicating the
> rionet driver is being added, but it never gets probed afterward.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~ rio_register_driver ~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> bus: 'rapidio': add driver rionet
> initializing klist
> init and added kobj, err=3D0
> driver_create_file err=3D0
> driver added attrs, err=3D0
> returning 0
> RIO: rionet_init rio_register_driver: rc=3D0
>=20
>=20
> Any ideas on why rionet isn't being probed? Is rionet currently
working?
> I'm running a 2.6.36-rc8 baseline.
>=20
> Thanks,
> Thomas Taranowski
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-06 20:10 UTC (permalink / raw)
To: Meador Inge; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <4D252FDC.4090404@mentor.com>
On Wed, 5 Jan 2011 20:58:36 -0600
Meador Inge <meador_inge@mentor.com> wrote:
> 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>;
Alternatively, we could describe available ranges similarly to the
existing MSI binding.
> 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.
The send-mask, like the receive-mask, is optional. If for your
application it makes sense to give all partitions send access to all
doorbells, then you can do that.
You might want to provide a send-mask if you are not specifying to the
partition how to use the message registers, just splitting them up for
their own internal use (especially if you have a larger multicore system
where each partition has multiple CPUs).
Or, you may want to add a layer of robustness against one partition
interfering with a message register that is only supposed to be used by
another partition, even if there are instructions elsewhere about which
message register to use for what purpose.
Plus, it provides symmetry between send and receive -- otherwise, you'd
have a numberspace that is limited to your own resources on receive,
but a global numberspace on send.
> 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 = <>;
> };
For core 3 I'd just leave out the node entirely. Note that the absence
of a receive-mask indicates that all the registers are available (i.e.
normal unpartitioned case), not none.
-Scott
^ permalink raw reply
* Re: DMA implementation on MPC8572
From: Ira W. Snyder @ 2011-01-06 20:52 UTC (permalink / raw)
To: deebul nair; +Cc: linuxppc-dev
In-Reply-To: <AANLkTik1br89HU+sUOfHYB74uWqOBJSCNpbvf21xsh_r@mail.gmail.com>
On Thu, Jan 06, 2011 at 07:54:16PM +0530, deebul nair wrote:
> Hi all
>
> I am using the MPC8572 processor.
> I wanted to use the DMA functionality in the powerpc board for talking to a
> FPGA device connected on the loacl bus.
>
> I have compiled the fsldma.c code and inserted it.
> On insertion the driver probes all the dma channels
> Can anyone tell me how to test the driver and also how to use the driver?
>
For memcpy tests, the dmatest module provides a good example. See
drivers/dma/dmatest.c for the source.
For more advanced usage, search the archives for:
[PATCH RFCv3 0/2] CARMA Board Support
Those drivers use some of the advanced features of the DMAEngine API to
transfer data from an FPGA into RAM.
Ira
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-06 21:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110105170725.1a82c5a6@udp111988uds.am.freescale.net>
On 01/05/2011 03:07 PM, Scott Wood wrote:
> 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.
Using physical addresses doesn't solve the enumeration problem either,=20
but I think it's beside the point: userspace must refer to the device.=20
There is a rich history of userspace *not* walking /proc/device-tree in=20
order to refer to a physical device. Are you suggesting this case is=20
special?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ 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