* [Adeos-main] [PATCH] ppc mvme5500
@ 2006-12-08 0:28 barbalace
2006-12-08 11:57 ` Wolfgang Grandegger
0 siblings, 1 reply; 8+ messages in thread
From: barbalace @ 2006-12-08 0:28 UTC (permalink / raw)
To: adeos-main
I'm working on linux 2.6.14 + ipipe + xenomai2.2.0 (refer to thread
https://mail.gna.org/public/xenomai-help/2006-05/msg00082.html, maybe the same
case-study).
I'm using ipipe patch:
adeos-ipipe-2.6.14-ppc-1.3-05.patch
this and next patch I tried, doesn't work and some write on the flash, if you
doesn't protect it again write (with on-board jumpers).
I make this simple patch (that I past at the end of the mail).
To use it I recommend to:
1. extract a Vanilla linux kernel
2. patch it with the Motorola patch (BSP)
3. patch it with the ipipe patch (adeos-ipipe-2.6.14-ppc-1.3-05.patch)
4. apply this patch
I test it only with write protect enable on the MVME5500 board; flash and eeprom
were not writeable, ensure this with a cat on /proc/cpuinfo.
regards,
Antonio Barbalace
diff -u -r linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/gt64260_pic.c
linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/gt64260_pic.c
---
linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/gt64260_pic.c 2005-10-28
02:02:08.000000000 +0200
+++
linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/gt64260_pic.c 2006-12-06
13:50:42.000000000 +0100
@@ -32,6 +32,11 @@
* input.
*/
+/*
+ * Modified by: A. Barbalace <barbalac@domain.hid> CNR Consorzio RFX Padova
+ *
+*/
+
#include <linux/stddef.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -52,8 +57,19 @@
/* ========================== forward declaration ========================== */
+static inline void gt64260pic_write(struct mv64x60_handle *bh, u32 offset, u32
val)
+{
+ out_le32(bh->v_base + offset, val);
+}
+
+static inline u32 gt64260pic_read(struct mv64x60_handle *bh, u32 offset)
+{
+ return in_le32(bh->v_base + offset);
+}
+
static void gt64260_unmask_irq(unsigned int);
static void gt64260_mask_irq(unsigned int);
+/* static void gt64260_end_irq(unsigned int); */
/* ========================== local declarations =========================== */
@@ -63,6 +79,7 @@
.disable = gt64260_mask_irq,
.ack = gt64260_mask_irq,
.end = gt64260_unmask_irq,
+ /* .end = gt64260_end_irq */
};
u32 gt64260_irq_base = 0; /* GT64260 handles the next 96 IRQs from here */
@@ -92,10 +109,10 @@
ppc_cached_irq_mask[2] = 0;
/* disable all interrupts and clear current interrupts */
- mv64x60_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2]);
- mv64x60_write(&bh, MV64x60_GPP_INTR_CAUSE, 0);
- mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0]);
- mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1]);
+ gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2]);
+ gt64260pic_write(&bh, MV64x60_GPP_INTR_CAUSE, 0);
+ gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0]);
+ gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1]);
/* use the gt64260 for all (possible) interrupt sources */
for (i = gt64260_irq_base; i < (gt64260_irq_base + 96); i++)
@@ -126,18 +143,18 @@
int irq;
int irq_gpp;
- irq = mv64x60_read(&bh, GT64260_IC_MAIN_CAUSE_LO);
+ irq = gt64260pic_read(&bh, GT64260_IC_MAIN_CAUSE_LO);
irq = __ilog2((irq & 0x3dfffffe) & ppc_cached_irq_mask[0]);
if (irq == -1) {
- irq = mv64x60_read(&bh, GT64260_IC_MAIN_CAUSE_HI);
+ irq = gt64260pic_read(&bh, GT64260_IC_MAIN_CAUSE_HI);
irq = __ilog2((irq & 0x0f000db7) & ppc_cached_irq_mask[1]);
if (irq == -1)
irq = -2; /* bogus interrupt, should never happen */
else {
if (irq >= 24) {
- irq_gpp = mv64x60_read(&bh,
+ irq_gpp = gt64260pic_read(&bh,
MV64x60_GPP_INTR_CAUSE);
irq_gpp = __ilog2(irq_gpp &
ppc_cached_irq_mask[2]);
@@ -146,7 +163,7 @@
irq = -2;
else {
irq = irq_gpp + 64;
- mv64x60_write(&bh,
+ gt64260pic_write(&bh,
MV64x60_GPP_INTR_CAUSE,
~(1 << (irq - 64)));
}
@@ -155,7 +172,7 @@
}
}
- (void)mv64x60_read(&bh, MV64x60_GPP_INTR_CAUSE);
+ (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_CAUSE);
if (irq < 0)
return (irq);
@@ -183,19 +200,23 @@
if (irq > 31)
if (irq > 63) /* unmask GPP irq */
- mv64x60_write(&bh, MV64x60_GPP_INTR_MASK,
- ppc_cached_irq_mask[2] |= (1 << (irq - 64)));
+ gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2] |= (1 <<
(irq - 64)));
else /* mask high interrupt register */
- mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
- ppc_cached_irq_mask[1] |= (1 << (irq - 32)));
+ gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1] |=
(1 << (irq - 32)));
else /* mask low interrupt register */
- mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
- ppc_cached_irq_mask[0] |= (1 << irq));
+ gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0] |=
(1 << irq));
- (void)mv64x60_read(&bh, MV64x60_GPP_INTR_MASK);
+ (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_MASK);
return;
}
+/*static void
+gt64260_end_irq(unsigned int irq)
+{
+ if (!ipipe_root_domain_p || (!irq_desc[irq].status & (IRQ_DISABLED |
IRQ_INPROGRESS)))
+ gt64260_unmask_irq(irq);
+ return;
+}*/
/* gt64260_mask_irq()
*
* This function disables the requested interrupt.
@@ -216,16 +237,16 @@
if (irq > 31)
if (irq > 63) /* mask GPP irq */
- mv64x60_write(&bh, MV64x60_GPP_INTR_MASK,
+ gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK,
ppc_cached_irq_mask[2] &= ~(1 << (irq - 64)));
else /* mask high interrupt register */
- mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
+ gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
ppc_cached_irq_mask[1] &= ~(1 << (irq - 32)));
else /* mask low interrupt register */
- mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
+ gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
ppc_cached_irq_mask[0] &= ~(1 << irq));
- (void)mv64x60_read(&bh, MV64x60_GPP_INTR_MASK);
+ (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_MASK);
return;
}
@@ -234,19 +255,19 @@
{
printk(KERN_ERR "gt64260_cpu_error_int_handler: %s 0x%08x\n",
"Error on CPU interface - Cause regiser",
- mv64x60_read(&bh, MV64x60_CPU_ERR_CAUSE));
+ gt64260pic_read(&bh, MV64x60_CPU_ERR_CAUSE));
printk(KERN_ERR "\tCPU error register dump:\n");
printk(KERN_ERR "\tAddress low 0x%08x\n",
- mv64x60_read(&bh, MV64x60_CPU_ERR_ADDR_LO));
+ gt64260pic_read(&bh, MV64x60_CPU_ERR_ADDR_LO));
printk(KERN_ERR "\tAddress high 0x%08x\n",
- mv64x60_read(&bh, MV64x60_CPU_ERR_ADDR_HI));
+ gt64260pic_read(&bh, MV64x60_CPU_ERR_ADDR_HI));
printk(KERN_ERR "\tData low 0x%08x\n",
- mv64x60_read(&bh, MV64x60_CPU_ERR_DATA_LO));
+ gt64260pic_read(&bh, MV64x60_CPU_ERR_DATA_LO));
printk(KERN_ERR "\tData high 0x%08x\n",
- mv64x60_read(&bh, MV64x60_CPU_ERR_DATA_HI));
+ gt64260pic_read(&bh, MV64x60_CPU_ERR_DATA_HI));
printk(KERN_ERR "\tParity 0x%08x\n",
- mv64x60_read(&bh, MV64x60_CPU_ERR_PARITY));
- mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
+ gt64260pic_read(&bh, MV64x60_CPU_ERR_PARITY));
+ gt64260pic_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
return IRQ_HANDLED;
}
@@ -257,36 +278,36 @@
unsigned int pci_bus = (unsigned int)dev_id;
if (pci_bus == 0) { /* Error on PCI 0 */
- val = mv64x60_read(&bh, MV64x60_PCI0_ERR_CAUSE);
+ val = gt64260pic_read(&bh, MV64x60_PCI0_ERR_CAUSE);
printk(KERN_ERR "%s: Error in PCI %d Interface\n",
"gt64260_pci_error_int_handler", pci_bus);
printk(KERN_ERR "\tPCI %d error register dump:\n", pci_bus);
printk(KERN_ERR "\tCause register 0x%08x\n", val);
printk(KERN_ERR "\tAddress Low 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI0_ERR_ADDR_LO));
+ gt64260pic_read(&bh, MV64x60_PCI0_ERR_ADDR_LO));
printk(KERN_ERR "\tAddress High 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI0_ERR_ADDR_HI));
+ gt64260pic_read(&bh, MV64x60_PCI0_ERR_ADDR_HI));
printk(KERN_ERR "\tAttribute 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI0_ERR_DATA_LO));
+ gt64260pic_read(&bh, MV64x60_PCI0_ERR_DATA_LO));
printk(KERN_ERR "\tCommand 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI0_ERR_CMD));
- mv64x60_write(&bh, MV64x60_PCI0_ERR_CAUSE, ~val);
+ gt64260pic_read(&bh, MV64x60_PCI0_ERR_CMD));
+ gt64260pic_write(&bh, MV64x60_PCI0_ERR_CAUSE, ~val);
}
if (pci_bus == 1) { /* Error on PCI 1 */
- val = mv64x60_read(&bh, MV64x60_PCI1_ERR_CAUSE);
+ val = gt64260pic_read(&bh, MV64x60_PCI1_ERR_CAUSE);
printk(KERN_ERR "%s: Error in PCI %d Interface\n",
"gt64260_pci_error_int_handler", pci_bus);
printk(KERN_ERR "\tPCI %d error register dump:\n", pci_bus);
printk(KERN_ERR "\tCause register 0x%08x\n", val);
printk(KERN_ERR "\tAddress Low 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI1_ERR_ADDR_LO));
+ gt64260pic_read(&bh, MV64x60_PCI1_ERR_ADDR_LO));
printk(KERN_ERR "\tAddress High 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI1_ERR_ADDR_HI));
+ gt64260pic_read(&bh, MV64x60_PCI1_ERR_ADDR_HI));
printk(KERN_ERR "\tAttribute 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI1_ERR_DATA_LO));
+ gt64260pic_read(&bh, MV64x60_PCI1_ERR_DATA_LO));
printk(KERN_ERR "\tCommand 0x%08x\n",
- mv64x60_read(&bh, MV64x60_PCI1_ERR_CMD));
- mv64x60_write(&bh, MV64x60_PCI1_ERR_CAUSE, ~val);
+ gt64260pic_read(&bh, MV64x60_PCI1_ERR_CMD));
+ gt64260pic_write(&bh, MV64x60_PCI1_ERR_CAUSE, ~val);
}
return IRQ_HANDLED;
}
@@ -301,8 +322,8 @@
gt64260_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
- mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0);
- mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
+ gt64260pic_write(&bh, MV64x60_CPU_ERR_MASK, 0);
+ gt64260pic_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
/* Register PCI 0 error interrupt handler */
if ((rc = request_irq(MV64360_IRQ_PCI0, gt64260_pci_error_int_handler,
@@ -310,8 +331,8 @@
printk(KERN_WARNING "Can't register pci 0 error handler: %d",
rc);
- mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
- mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
+ gt64260pic_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
+ gt64260pic_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
/* Register PCI 1 error interrupt handler */
if ((rc = request_irq(MV64360_IRQ_PCI1, gt64260_pci_error_int_handler,
@@ -319,10 +340,11 @@
printk(KERN_WARNING "Can't register pci 1 error handler: %d",
rc);
- mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
- mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
+ gt64260pic_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
+ gt64260pic_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
return 0;
}
arch_initcall(gt64260_register_hdlrs);
+
diff -u -r linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/i8259.c
linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/i8259.c
--- linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/i8259.c 2005-10-28
02:02:08.000000000 +0200
+++
linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/i8259.c 2006-12-06
14:06:19.000000000 +0100
@@ -157,7 +157,8 @@
.flags = IORESOURCE_BUSY,
};
-static struct irqaction i8259_irqaction = {
+//static struct irqaction i8259_irqaction = { // IPIPE: remove static
declaration like other IPIPE patch
+struct irqaction i8259_irqaction = {
.handler = no_action,
.flags = SA_INTERRUPT,
.mask = CPU_MASK_NONE,
Antonio Barbalace
CNR Consorzio RFX - Associazione EURATOM/ENEA sulla Fusione
Corso Stati Uniti, 4
35127 Padova
ITALY
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Adeos-main] [PATCH] ppc mvme5500
2006-12-08 0:28 [Adeos-main] [PATCH] ppc mvme5500 barbalace
@ 2006-12-08 11:57 ` Wolfgang Grandegger
2006-12-08 16:35 ` barbalace
0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Grandegger @ 2006-12-08 11:57 UTC (permalink / raw)
To: barbalace; +Cc: adeos-main
[-- Attachment #1: Type: text/plain, Size: 13351 bytes --]
barbalace@domain.hid wrote:
> I'm working on linux 2.6.14 + ipipe + xenomai2.2.0 (refer to thread
> https://mail.gna.org/public/xenomai-help/2006-05/msg00082.html, maybe the same
> case-study).
>
> I'm using ipipe patch:
> adeos-ipipe-2.6.14-ppc-1.3-05.patch
>
> this and next patch I tried, doesn't work and some write on the flash, if you
> doesn't protect it again write (with on-board jumpers).
>
> I make this simple patch (that I past at the end of the mail).
> To use it I recommend to:
> 1. extract a Vanilla linux kernel
> 2. patch it with the Motorola patch (BSP)
> 3. patch it with the ipipe patch (adeos-ipipe-2.6.14-ppc-1.3-05.patch)
> 4. apply this patch
>
> I test it only with write protect enable on the MVME5500 board; flash and eeprom
> were not writeable, ensure this with a cat on /proc/cpuinfo.
Ah, oh, this is another prime example of PIC code requiring a patch,
also on PowerPC :-(. The problem are the Linux spin_* functions in
include/asm-ppc/mv64x60.h:
/* Define I/O routines for accessing registers on the 64x60 bridge. */
extern inline void
mv64x60_write(struct mv64x60_handle *bh, u32 offset, u32 val) {
ulong flags;
spin_lock_irqsave(&mv64x60_lock, flags);
out_le32(bh->v_base + offset, val);
spin_unlock_irqrestore(&mv64x60_lock, flags);
}
extern inline u32
mv64x60_read(struct mv64x60_handle *bh, u32 offset) {
ulong flags;
u32 reg;
spin_lock_irqsave(&mv64x60_lock, flags);
reg = in_le32(bh->v_base + offset);
spin_unlock_irqrestore(&mv64x60_lock, flags);
return reg;
}
Why not just iron them with the "spin_*_hw" variants, or remove them
completely? That's what your patch does as well. I think the out_le32
and in_le32 functions already access the registers atomically. To be
save, use "spin_*_hw". Does the attached patch work with and without
IPIPE enabled?
Thanks for reporting.
Wolfgang.
>
> regards,
> Antonio Barbalace
>
>
> diff -u -r linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/gt64260_pic.c
> linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/gt64260_pic.c
> ---
> linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/gt64260_pic.c 2005-10-28
> 02:02:08.000000000 +0200
> +++
> linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/gt64260_pic.c 2006-12-06
> 13:50:42.000000000 +0100
> @@ -32,6 +32,11 @@
> * input.
> */
>
> +/*
> + * Modified by: A. Barbalace <barbalac@domain.hid> CNR Consorzio RFX Padova
> + *
> +*/
> +
> #include <linux/stddef.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> @@ -52,8 +57,19 @@
>
> /* ========================== forward declaration ========================== */
>
> +static inline void gt64260pic_write(struct mv64x60_handle *bh, u32 offset, u32
> val)
> +{
> + out_le32(bh->v_base + offset, val);
> +}
> +
> +static inline u32 gt64260pic_read(struct mv64x60_handle *bh, u32 offset)
> +{
> + return in_le32(bh->v_base + offset);
> +}
> +
> static void gt64260_unmask_irq(unsigned int);
> static void gt64260_mask_irq(unsigned int);
> +/* static void gt64260_end_irq(unsigned int); */
>
> /* ========================== local declarations =========================== */
>
> @@ -63,6 +79,7 @@
> .disable = gt64260_mask_irq,
> .ack = gt64260_mask_irq,
> .end = gt64260_unmask_irq,
> + /* .end = gt64260_end_irq */
> };
>
> u32 gt64260_irq_base = 0; /* GT64260 handles the next 96 IRQs from here */
> @@ -92,10 +109,10 @@
> ppc_cached_irq_mask[2] = 0;
>
> /* disable all interrupts and clear current interrupts */
> - mv64x60_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2]);
> - mv64x60_write(&bh, MV64x60_GPP_INTR_CAUSE, 0);
> - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0]);
> - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1]);
> + gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2]);
> + gt64260pic_write(&bh, MV64x60_GPP_INTR_CAUSE, 0);
> + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0]);
> + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1]);
>
> /* use the gt64260 for all (possible) interrupt sources */
> for (i = gt64260_irq_base; i < (gt64260_irq_base + 96); i++)
> @@ -126,18 +143,18 @@
> int irq;
> int irq_gpp;
>
> - irq = mv64x60_read(&bh, GT64260_IC_MAIN_CAUSE_LO);
> + irq = gt64260pic_read(&bh, GT64260_IC_MAIN_CAUSE_LO);
> irq = __ilog2((irq & 0x3dfffffe) & ppc_cached_irq_mask[0]);
>
> if (irq == -1) {
> - irq = mv64x60_read(&bh, GT64260_IC_MAIN_CAUSE_HI);
> + irq = gt64260pic_read(&bh, GT64260_IC_MAIN_CAUSE_HI);
> irq = __ilog2((irq & 0x0f000db7) & ppc_cached_irq_mask[1]);
>
> if (irq == -1)
> irq = -2; /* bogus interrupt, should never happen */
> else {
> if (irq >= 24) {
> - irq_gpp = mv64x60_read(&bh,
> + irq_gpp = gt64260pic_read(&bh,
> MV64x60_GPP_INTR_CAUSE);
> irq_gpp = __ilog2(irq_gpp &
> ppc_cached_irq_mask[2]);
> @@ -146,7 +163,7 @@
> irq = -2;
> else {
> irq = irq_gpp + 64;
> - mv64x60_write(&bh,
> + gt64260pic_write(&bh,
> MV64x60_GPP_INTR_CAUSE,
> ~(1 << (irq - 64)));
> }
> @@ -155,7 +172,7 @@
> }
> }
>
> - (void)mv64x60_read(&bh, MV64x60_GPP_INTR_CAUSE);
> + (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_CAUSE);
>
> if (irq < 0)
> return (irq);
> @@ -183,19 +200,23 @@
>
> if (irq > 31)
> if (irq > 63) /* unmask GPP irq */
> - mv64x60_write(&bh, MV64x60_GPP_INTR_MASK,
> - ppc_cached_irq_mask[2] |= (1 << (irq - 64)));
> + gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2] |= (1 <<
> (irq - 64)));
> else /* mask high interrupt register */
> - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> - ppc_cached_irq_mask[1] |= (1 << (irq - 32)));
> + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1] |=
> (1 << (irq - 32)));
> else /* mask low interrupt register */
> - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> - ppc_cached_irq_mask[0] |= (1 << irq));
> + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0] |=
> (1 << irq));
>
> - (void)mv64x60_read(&bh, MV64x60_GPP_INTR_MASK);
> + (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_MASK);
> return;
> }
> +/*static void
> +gt64260_end_irq(unsigned int irq)
> +{
> + if (!ipipe_root_domain_p || (!irq_desc[irq].status & (IRQ_DISABLED |
> IRQ_INPROGRESS)))
> + gt64260_unmask_irq(irq);
>
> + return;
> +}*/
> /* gt64260_mask_irq()
> *
> * This function disables the requested interrupt.
> @@ -216,16 +237,16 @@
>
> if (irq > 31)
> if (irq > 63) /* mask GPP irq */
> - mv64x60_write(&bh, MV64x60_GPP_INTR_MASK,
> + gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK,
> ppc_cached_irq_mask[2] &= ~(1 << (irq - 64)));
> else /* mask high interrupt register */
> - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> ppc_cached_irq_mask[1] &= ~(1 << (irq - 32)));
> else /* mask low interrupt register */
> - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> ppc_cached_irq_mask[0] &= ~(1 << irq));
>
> - (void)mv64x60_read(&bh, MV64x60_GPP_INTR_MASK);
> + (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_MASK);
> return;
> }
>
> @@ -234,19 +255,19 @@
> {
> printk(KERN_ERR "gt64260_cpu_error_int_handler: %s 0x%08x\n",
> "Error on CPU interface - Cause regiser",
> - mv64x60_read(&bh, MV64x60_CPU_ERR_CAUSE));
> + gt64260pic_read(&bh, MV64x60_CPU_ERR_CAUSE));
> printk(KERN_ERR "\tCPU error register dump:\n");
> printk(KERN_ERR "\tAddress low 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_CPU_ERR_ADDR_LO));
> + gt64260pic_read(&bh, MV64x60_CPU_ERR_ADDR_LO));
> printk(KERN_ERR "\tAddress high 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_CPU_ERR_ADDR_HI));
> + gt64260pic_read(&bh, MV64x60_CPU_ERR_ADDR_HI));
> printk(KERN_ERR "\tData low 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_CPU_ERR_DATA_LO));
> + gt64260pic_read(&bh, MV64x60_CPU_ERR_DATA_LO));
> printk(KERN_ERR "\tData high 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_CPU_ERR_DATA_HI));
> + gt64260pic_read(&bh, MV64x60_CPU_ERR_DATA_HI));
> printk(KERN_ERR "\tParity 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_CPU_ERR_PARITY));
> - mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
> + gt64260pic_read(&bh, MV64x60_CPU_ERR_PARITY));
> + gt64260pic_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
> return IRQ_HANDLED;
> }
>
> @@ -257,36 +278,36 @@
> unsigned int pci_bus = (unsigned int)dev_id;
>
> if (pci_bus == 0) { /* Error on PCI 0 */
> - val = mv64x60_read(&bh, MV64x60_PCI0_ERR_CAUSE);
> + val = gt64260pic_read(&bh, MV64x60_PCI0_ERR_CAUSE);
> printk(KERN_ERR "%s: Error in PCI %d Interface\n",
> "gt64260_pci_error_int_handler", pci_bus);
> printk(KERN_ERR "\tPCI %d error register dump:\n", pci_bus);
> printk(KERN_ERR "\tCause register 0x%08x\n", val);
> printk(KERN_ERR "\tAddress Low 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI0_ERR_ADDR_LO));
> + gt64260pic_read(&bh, MV64x60_PCI0_ERR_ADDR_LO));
> printk(KERN_ERR "\tAddress High 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI0_ERR_ADDR_HI));
> + gt64260pic_read(&bh, MV64x60_PCI0_ERR_ADDR_HI));
> printk(KERN_ERR "\tAttribute 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI0_ERR_DATA_LO));
> + gt64260pic_read(&bh, MV64x60_PCI0_ERR_DATA_LO));
> printk(KERN_ERR "\tCommand 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI0_ERR_CMD));
> - mv64x60_write(&bh, MV64x60_PCI0_ERR_CAUSE, ~val);
> + gt64260pic_read(&bh, MV64x60_PCI0_ERR_CMD));
> + gt64260pic_write(&bh, MV64x60_PCI0_ERR_CAUSE, ~val);
> }
> if (pci_bus == 1) { /* Error on PCI 1 */
> - val = mv64x60_read(&bh, MV64x60_PCI1_ERR_CAUSE);
> + val = gt64260pic_read(&bh, MV64x60_PCI1_ERR_CAUSE);
> printk(KERN_ERR "%s: Error in PCI %d Interface\n",
> "gt64260_pci_error_int_handler", pci_bus);
> printk(KERN_ERR "\tPCI %d error register dump:\n", pci_bus);
> printk(KERN_ERR "\tCause register 0x%08x\n", val);
> printk(KERN_ERR "\tAddress Low 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI1_ERR_ADDR_LO));
> + gt64260pic_read(&bh, MV64x60_PCI1_ERR_ADDR_LO));
> printk(KERN_ERR "\tAddress High 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI1_ERR_ADDR_HI));
> + gt64260pic_read(&bh, MV64x60_PCI1_ERR_ADDR_HI));
> printk(KERN_ERR "\tAttribute 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI1_ERR_DATA_LO));
> + gt64260pic_read(&bh, MV64x60_PCI1_ERR_DATA_LO));
> printk(KERN_ERR "\tCommand 0x%08x\n",
> - mv64x60_read(&bh, MV64x60_PCI1_ERR_CMD));
> - mv64x60_write(&bh, MV64x60_PCI1_ERR_CAUSE, ~val);
> + gt64260pic_read(&bh, MV64x60_PCI1_ERR_CMD));
> + gt64260pic_write(&bh, MV64x60_PCI1_ERR_CAUSE, ~val);
> }
> return IRQ_HANDLED;
> }
> @@ -301,8 +322,8 @@
> gt64260_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
> printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
>
> - mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0);
> - mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
> + gt64260pic_write(&bh, MV64x60_CPU_ERR_MASK, 0);
> + gt64260pic_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
>
> /* Register PCI 0 error interrupt handler */
> if ((rc = request_irq(MV64360_IRQ_PCI0, gt64260_pci_error_int_handler,
> @@ -310,8 +331,8 @@
> printk(KERN_WARNING "Can't register pci 0 error handler: %d",
> rc);
>
> - mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
> - mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
> + gt64260pic_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
> + gt64260pic_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
>
> /* Register PCI 1 error interrupt handler */
> if ((rc = request_irq(MV64360_IRQ_PCI1, gt64260_pci_error_int_handler,
> @@ -319,10 +340,11 @@
> printk(KERN_WARNING "Can't register pci 1 error handler: %d",
> rc);
>
> - mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
> - mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
> + gt64260pic_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
> + gt64260pic_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
>
> return 0;
> }
>
> arch_initcall(gt64260_register_hdlrs);
> +
> diff -u -r linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/i8259.c
> linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/i8259.c
> --- linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/i8259.c 2005-10-28
> 02:02:08.000000000 +0200
> +++
> linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/i8259.c 2006-12-06
> 14:06:19.000000000 +0100
> @@ -157,7 +157,8 @@
> .flags = IORESOURCE_BUSY,
> };
>
> -static struct irqaction i8259_irqaction = {
> +//static struct irqaction i8259_irqaction = { // IPIPE: remove static
> declaration like other IPIPE patch
> +struct irqaction i8259_irqaction = {
> .handler = no_action,
> .flags = SA_INTERRUPT,
> .mask = CPU_MASK_NONE,
>
>
> Antonio Barbalace
> CNR Consorzio RFX - Associazione EURATOM/ENEA sulla Fusione
> Corso Stati Uniti, 4
> 35127 Padova
> ITALY
>
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
>
>
[-- Attachment #2: adeos-ipipe-2.6.x-mv64x60.patch --]
[-- Type: text/x-patch, Size: 1327 bytes --]
+ diff -u linux-2.6.19/include/asm-ppc/mv64x60.h.PIC linux-2.6.19/include/asm-ppc/mv64x60.h
--- linux-2.6.19/include/asm-ppc/mv64x60.h.PIC 2006-11-29 22:57:37.000000000 +0100
+++ linux-2.6.19/include/asm-ppc/mv64x60.h 2006-12-08 11:54:43.000000000 +0100
@@ -255,9 +255,9 @@
mv64x60_write(struct mv64x60_handle *bh, u32 offset, u32 val) {
ulong flags;
- spin_lock_irqsave(&mv64x60_lock, flags);
+ spin_lock_irqsave_hw(&mv64x60_lock, flags);
out_le32(bh->v_base + offset, val);
- spin_unlock_irqrestore(&mv64x60_lock, flags);
+ spin_unlock_irqrestore_hw(&mv64x60_lock, flags);
}
extern inline u32
@@ -265,9 +265,9 @@
ulong flags;
u32 reg;
- spin_lock_irqsave(&mv64x60_lock, flags);
+ spin_lock_irqsave_hw(&mv64x60_lock, flags);
reg = in_le32(bh->v_base + offset);
- spin_unlock_irqrestore(&mv64x60_lock, flags);
+ spin_unlock_irqrestore_hw(&mv64x60_lock, flags);
return reg;
}
@@ -277,11 +277,11 @@
u32 reg;
ulong flags;
- spin_lock_irqsave(&mv64x60_lock, flags);
+ spin_lock_irqsave_hw(&mv64x60_lock, flags);
reg = in_le32(bh->v_base + offs) & (~mask);
reg |= data & mask;
out_le32(bh->v_base + offs, reg);
- spin_unlock_irqrestore(&mv64x60_lock, flags);
+ spin_unlock_irqrestore_hw(&mv64x60_lock, flags);
}
#define mv64x60_set_bits(bh, offs, bits) mv64x60_modify(bh, offs, ~0, bits)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Adeos-main] [PATCH] ppc mvme5500
2006-12-08 11:57 ` Wolfgang Grandegger
@ 2006-12-08 16:35 ` barbalace
2006-12-08 20:38 ` Wolfgang Grandegger
0 siblings, 1 reply; 8+ messages in thread
From: barbalace @ 2006-12-08 16:35 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: adeos-main
;-) Yes, the problem are the Linux spin_* functions, sincerly I don't understand
why there are this spin_* functions (maybe for another architecture, different
from ppc???).
'in_le32' and 'out_le32' are substantially atomic, are declared in
include/asm-ppc/io.h:
extern inline unsigned in_le32(const volatile unsigned __iomem *addr)
{
unsigned ret;
__asm__ __volatile__("lwbrx %0,0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) :
"r" (addr), "m" (*addr));
return ret;
}
extern inline void out_le32(volatile unsigned __iomem *addr, int val)
{
__asm__ __volatile__("stwbrx %1,0,%2; eieio" : "=m" (*addr) :
"r" (val), "r" (addr));
}
The load istruction is lwbrx and the store istruction is stwbrx: one istruction
= atomic (do you agree?). isync and eieio are synchronization istruction, if
executed in a second time doesn't change the behaviour.
I test this patch with and without the IPIPE enabled.
>From my point of view I think is better to remove the spin_* in the ppc arch to
avoid the spinlock overhead. For a portability issue is better to use a pragma
#ifdef structure.
Antonio
Quoting Wolfgang Grandegger <wg@domain.hid>:
> barbalace@domain.hid wrote:
> > I'm working on linux 2.6.14 + ipipe + xenomai2.2.0 (refer to thread
> > https://mail.gna.org/public/xenomai-help/2006-05/msg00082.html, maybe the
> same
> > case-study).
> >
> > I'm using ipipe patch:
> > adeos-ipipe-2.6.14-ppc-1.3-05.patch
> >
> > this and next patch I tried, doesn't work and some write on the flash, if
> you
> > doesn't protect it again write (with on-board jumpers).
> >
> > I make this simple patch (that I past at the end of the mail).
> > To use it I recommend to:
> > 1. extract a Vanilla linux kernel
> > 2. patch it with the Motorola patch (BSP)
> > 3. patch it with the ipipe patch (adeos-ipipe-2.6.14-ppc-1.3-05.patch)
> > 4. apply this patch
> >
> > I test it only with write protect enable on the MVME5500 board; flash and
> eeprom
> > were not writeable, ensure this with a cat on /proc/cpuinfo.
>
> Ah, oh, this is another prime example of PIC code requiring a patch,
> also on PowerPC :-(. The problem are the Linux spin_* functions in
> include/asm-ppc/mv64x60.h:
>
> /* Define I/O routines for accessing registers on the 64x60 bridge. */
> extern inline void
> mv64x60_write(struct mv64x60_handle *bh, u32 offset, u32 val) {
> ulong flags;
>
> spin_lock_irqsave(&mv64x60_lock, flags);
> out_le32(bh->v_base + offset, val);
> spin_unlock_irqrestore(&mv64x60_lock, flags);
> }
>
> extern inline u32
> mv64x60_read(struct mv64x60_handle *bh, u32 offset) {
> ulong flags;
> u32 reg;
>
> spin_lock_irqsave(&mv64x60_lock, flags);
> reg = in_le32(bh->v_base + offset);
> spin_unlock_irqrestore(&mv64x60_lock, flags);
> return reg;
> }
>
> Why not just iron them with the "spin_*_hw" variants, or remove them
> completely? That's what your patch does as well. I think the out_le32
> and in_le32 functions already access the registers atomically. To be
> save, use "spin_*_hw". Does the attached patch work with and without
> IPIPE enabled?
>
> Thanks for reporting.
>
> Wolfgang.
>
> >
> > regards,
> > Antonio Barbalace
> >
> >
> > diff -u -r
> linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/gt64260_pic.c
> > linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/gt64260_pic.c
> > ---
> >
> linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/gt64260_pic.c 2005-10-28
> > 02:02:08.000000000 +0200
> > +++
> >
>
linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/gt64260_pic.c 2006-12-06
> > 13:50:42.000000000 +0100
> > @@ -32,6 +32,11 @@
> > * input.
> > */
> >
> > +/*
> > + * Modified by: A. Barbalace <barbalac@domain.hid> CNR Consorzio RFX
> Padova
> > + *
> > +*/
> > +
> > #include <linux/stddef.h>
> > #include <linux/init.h>
> > #include <linux/interrupt.h>
> > @@ -52,8 +57,19 @@
> >
> > /* ========================== forward declaration
> ========================== */
> >
> > +static inline void gt64260pic_write(struct mv64x60_handle *bh, u32 offset,
> u32
> > val)
> > +{
> > + out_le32(bh->v_base + offset, val);
> > +}
> > +
> > +static inline u32 gt64260pic_read(struct mv64x60_handle *bh, u32 offset)
> > +{
> > + return in_le32(bh->v_base + offset);
> > +}
> > +
> > static void gt64260_unmask_irq(unsigned int);
> > static void gt64260_mask_irq(unsigned int);
> > +/* static void gt64260_end_irq(unsigned int); */
> >
> > /* ========================== local declarations
> =========================== */
> >
> > @@ -63,6 +79,7 @@
> > .disable = gt64260_mask_irq,
> > .ack = gt64260_mask_irq,
> > .end = gt64260_unmask_irq,
> > + /* .end = gt64260_end_irq */
> > };
> >
> > u32 gt64260_irq_base = 0; /* GT64260 handles the next 96 IRQs from here */
> > @@ -92,10 +109,10 @@
> > ppc_cached_irq_mask[2] = 0;
> >
> > /* disable all interrupts and clear current interrupts */
> > - mv64x60_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2]);
> > - mv64x60_write(&bh, MV64x60_GPP_INTR_CAUSE, 0);
> > - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO, ppc_cached_irq_mask[0]);
> > - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI, ppc_cached_irq_mask[1]);
> > + gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2]);
> > + gt64260pic_write(&bh, MV64x60_GPP_INTR_CAUSE, 0);
> > + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> ppc_cached_irq_mask[0]);
> > + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> ppc_cached_irq_mask[1]);
> >
> > /* use the gt64260 for all (possible) interrupt sources */
> > for (i = gt64260_irq_base; i < (gt64260_irq_base + 96); i++)
> > @@ -126,18 +143,18 @@
> > int irq;
> > int irq_gpp;
> >
> > - irq = mv64x60_read(&bh, GT64260_IC_MAIN_CAUSE_LO);
> > + irq = gt64260pic_read(&bh, GT64260_IC_MAIN_CAUSE_LO);
> > irq = __ilog2((irq & 0x3dfffffe) & ppc_cached_irq_mask[0]);
> >
> > if (irq == -1) {
> > - irq = mv64x60_read(&bh, GT64260_IC_MAIN_CAUSE_HI);
> > + irq = gt64260pic_read(&bh, GT64260_IC_MAIN_CAUSE_HI);
> > irq = __ilog2((irq & 0x0f000db7) & ppc_cached_irq_mask[1]);
> >
> > if (irq == -1)
> > irq = -2; /* bogus interrupt, should never happen */
> > else {
> > if (irq >= 24) {
> > - irq_gpp = mv64x60_read(&bh,
> > + irq_gpp = gt64260pic_read(&bh,
> > MV64x60_GPP_INTR_CAUSE);
> > irq_gpp = __ilog2(irq_gpp &
> > ppc_cached_irq_mask[2]);
> > @@ -146,7 +163,7 @@
> > irq = -2;
> > else {
> > irq = irq_gpp + 64;
> > - mv64x60_write(&bh,
> > + gt64260pic_write(&bh,
> > MV64x60_GPP_INTR_CAUSE,
> > ~(1 << (irq - 64)));
> > }
> > @@ -155,7 +172,7 @@
> > }
> > }
> >
> > - (void)mv64x60_read(&bh, MV64x60_GPP_INTR_CAUSE);
> > + (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_CAUSE);
> >
> > if (irq < 0)
> > return (irq);
> > @@ -183,19 +200,23 @@
> >
> > if (irq > 31)
> > if (irq > 63) /* unmask GPP irq */
> > - mv64x60_write(&bh, MV64x60_GPP_INTR_MASK,
> > - ppc_cached_irq_mask[2] |= (1 << (irq - 64)));
> > + gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK, ppc_cached_irq_mask[2] |=
> (1 <<
> > (irq - 64)));
> > else /* mask high interrupt register */
> > - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> > - ppc_cached_irq_mask[1] |= (1 << (irq - 32)));
> > + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> ppc_cached_irq_mask[1] |=
> > (1 << (irq - 32)));
> > else /* mask low interrupt register */
> > - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> > - ppc_cached_irq_mask[0] |= (1 << irq));
> > + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> ppc_cached_irq_mask[0] |=
> > (1 << irq));
> >
> > - (void)mv64x60_read(&bh, MV64x60_GPP_INTR_MASK);
> > + (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_MASK);
> > return;
> > }
> > +/*static void
> > +gt64260_end_irq(unsigned int irq)
> > +{
> > + if (!ipipe_root_domain_p || (!irq_desc[irq].status & (IRQ_DISABLED |
> > IRQ_INPROGRESS)))
> > + gt64260_unmask_irq(irq);
> >
> > + return;
> > +}*/
> > /* gt64260_mask_irq()
> > *
> > * This function disables the requested interrupt.
> > @@ -216,16 +237,16 @@
> >
> > if (irq > 31)
> > if (irq > 63) /* mask GPP irq */
> > - mv64x60_write(&bh, MV64x60_GPP_INTR_MASK,
> > + gt64260pic_write(&bh, MV64x60_GPP_INTR_MASK,
> > ppc_cached_irq_mask[2] &= ~(1 << (irq - 64)));
> > else /* mask high interrupt register */
> > - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> > + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_HI,
> > ppc_cached_irq_mask[1] &= ~(1 << (irq - 32)));
> > else /* mask low interrupt register */
> > - mv64x60_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> > + gt64260pic_write(&bh, GT64260_IC_CPU_INTR_MASK_LO,
> > ppc_cached_irq_mask[0] &= ~(1 << irq));
> >
> > - (void)mv64x60_read(&bh, MV64x60_GPP_INTR_MASK);
> > + (void)gt64260pic_read(&bh, MV64x60_GPP_INTR_MASK);
> > return;
> > }
> >
> > @@ -234,19 +255,19 @@
> > {
> > printk(KERN_ERR "gt64260_cpu_error_int_handler: %s 0x%08x\n",
> > "Error on CPU interface - Cause regiser",
> > - mv64x60_read(&bh, MV64x60_CPU_ERR_CAUSE));
> > + gt64260pic_read(&bh, MV64x60_CPU_ERR_CAUSE));
> > printk(KERN_ERR "\tCPU error register dump:\n");
> > printk(KERN_ERR "\tAddress low 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_CPU_ERR_ADDR_LO));
> > + gt64260pic_read(&bh, MV64x60_CPU_ERR_ADDR_LO));
> > printk(KERN_ERR "\tAddress high 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_CPU_ERR_ADDR_HI));
> > + gt64260pic_read(&bh, MV64x60_CPU_ERR_ADDR_HI));
> > printk(KERN_ERR "\tData low 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_CPU_ERR_DATA_LO));
> > + gt64260pic_read(&bh, MV64x60_CPU_ERR_DATA_LO));
> > printk(KERN_ERR "\tData high 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_CPU_ERR_DATA_HI));
> > + gt64260pic_read(&bh, MV64x60_CPU_ERR_DATA_HI));
> > printk(KERN_ERR "\tParity 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_CPU_ERR_PARITY));
> > - mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
> > + gt64260pic_read(&bh, MV64x60_CPU_ERR_PARITY));
> > + gt64260pic_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
> > return IRQ_HANDLED;
> > }
> >
> > @@ -257,36 +278,36 @@
> > unsigned int pci_bus = (unsigned int)dev_id;
> >
> > if (pci_bus == 0) { /* Error on PCI 0 */
> > - val = mv64x60_read(&bh, MV64x60_PCI0_ERR_CAUSE);
> > + val = gt64260pic_read(&bh, MV64x60_PCI0_ERR_CAUSE);
> > printk(KERN_ERR "%s: Error in PCI %d Interface\n",
> > "gt64260_pci_error_int_handler", pci_bus);
> > printk(KERN_ERR "\tPCI %d error register dump:\n", pci_bus);
> > printk(KERN_ERR "\tCause register 0x%08x\n", val);
> > printk(KERN_ERR "\tAddress Low 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI0_ERR_ADDR_LO));
> > + gt64260pic_read(&bh, MV64x60_PCI0_ERR_ADDR_LO));
> > printk(KERN_ERR "\tAddress High 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI0_ERR_ADDR_HI));
> > + gt64260pic_read(&bh, MV64x60_PCI0_ERR_ADDR_HI));
> > printk(KERN_ERR "\tAttribute 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI0_ERR_DATA_LO));
> > + gt64260pic_read(&bh, MV64x60_PCI0_ERR_DATA_LO));
> > printk(KERN_ERR "\tCommand 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI0_ERR_CMD));
> > - mv64x60_write(&bh, MV64x60_PCI0_ERR_CAUSE, ~val);
> > + gt64260pic_read(&bh, MV64x60_PCI0_ERR_CMD));
> > + gt64260pic_write(&bh, MV64x60_PCI0_ERR_CAUSE, ~val);
> > }
> > if (pci_bus == 1) { /* Error on PCI 1 */
> > - val = mv64x60_read(&bh, MV64x60_PCI1_ERR_CAUSE);
> > + val = gt64260pic_read(&bh, MV64x60_PCI1_ERR_CAUSE);
> > printk(KERN_ERR "%s: Error in PCI %d Interface\n",
> > "gt64260_pci_error_int_handler", pci_bus);
> > printk(KERN_ERR "\tPCI %d error register dump:\n", pci_bus);
> > printk(KERN_ERR "\tCause register 0x%08x\n", val);
> > printk(KERN_ERR "\tAddress Low 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI1_ERR_ADDR_LO));
> > + gt64260pic_read(&bh, MV64x60_PCI1_ERR_ADDR_LO));
> > printk(KERN_ERR "\tAddress High 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI1_ERR_ADDR_HI));
> > + gt64260pic_read(&bh, MV64x60_PCI1_ERR_ADDR_HI));
> > printk(KERN_ERR "\tAttribute 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI1_ERR_DATA_LO));
> > + gt64260pic_read(&bh, MV64x60_PCI1_ERR_DATA_LO));
> > printk(KERN_ERR "\tCommand 0x%08x\n",
> > - mv64x60_read(&bh, MV64x60_PCI1_ERR_CMD));
> > - mv64x60_write(&bh, MV64x60_PCI1_ERR_CAUSE, ~val);
> > + gt64260pic_read(&bh, MV64x60_PCI1_ERR_CMD));
> > + gt64260pic_write(&bh, MV64x60_PCI1_ERR_CAUSE, ~val);
> > }
> > return IRQ_HANDLED;
> > }
> > @@ -301,8 +322,8 @@
> > gt64260_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
> > printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
> >
> > - mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0);
> > - mv64x60_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
> > + gt64260pic_write(&bh, MV64x60_CPU_ERR_MASK, 0);
> > + gt64260pic_write(&bh, MV64x60_CPU_ERR_MASK, 0x000000fe);
> >
> > /* Register PCI 0 error interrupt handler */
> > if ((rc = request_irq(MV64360_IRQ_PCI0, gt64260_pci_error_int_handler,
> > @@ -310,8 +331,8 @@
> > printk(KERN_WARNING "Can't register pci 0 error handler: %d",
> > rc);
> >
> > - mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
> > - mv64x60_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
> > + gt64260pic_write(&bh, MV64x60_PCI0_ERR_MASK, 0);
> > + gt64260pic_write(&bh, MV64x60_PCI0_ERR_MASK, 0x003c0c24);
> >
> > /* Register PCI 1 error interrupt handler */
> > if ((rc = request_irq(MV64360_IRQ_PCI1, gt64260_pci_error_int_handler,
> > @@ -319,10 +340,11 @@
> > printk(KERN_WARNING "Can't register pci 1 error handler: %d",
> > rc);
> >
> > - mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
> > - mv64x60_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
> > + gt64260pic_write(&bh, MV64x60_PCI1_ERR_MASK, 0);
> > + gt64260pic_write(&bh, MV64x60_PCI1_ERR_MASK, 0x003c0c24);
> >
> > return 0;
> > }
> >
> > arch_initcall(gt64260_register_hdlrs);
> > +
> > diff -u -r linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/i8259.c
> > linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/i8259.c
> > ---
> linux-2.6.14-ecc.11012006-rfx01-ipipe/arch/ppc/syslib/i8259.c 2005-10-28
> > 02:02:08.000000000 +0200
> > +++
> >
> linux-2.6.14-ecc.11012006-rfx01-ipipe.rfx01/arch/ppc/syslib/i8259.c 2006-12-06
> > 14:06:19.000000000 +0100
> > @@ -157,7 +157,8 @@
> > .flags = IORESOURCE_BUSY,
> > };
> >
> > -static struct irqaction i8259_irqaction = {
> > +//static struct irqaction i8259_irqaction = { // IPIPE: remove static
> > declaration like other IPIPE patch
> > +struct irqaction i8259_irqaction = {
> > .handler = no_action,
> > .flags = SA_INTERRUPT,
> > .mask = CPU_MASK_NONE,
> >
> >
> > Antonio Barbalace
> > CNR Consorzio RFX - Associazione EURATOM/ENEA sulla Fusione
> > Corso Stati Uniti, 4
> > 35127 Padova
> > ITALY
> >
> > _______________________________________________
> > Adeos-main mailing list
> > Adeos-main@domain.hid
> > https://mail.gna.org/listinfo/adeos-main
> >
> >
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Adeos-main] [PATCH] ppc mvme5500
2006-12-08 16:35 ` barbalace
@ 2006-12-08 20:38 ` Wolfgang Grandegger
[not found] ` <1165665886.457aa65e2c26e@domain.hid>
0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Grandegger @ 2006-12-08 20:38 UTC (permalink / raw)
To: barbalace; +Cc: adeos-main
Hello,
barbalace@domain.hid wrote:
> ;-) Yes, the problem are the Linux spin_* functions, sincerly I don't understand
> why there are this spin_* functions (maybe for another architecture, different
> from ppc???).
> 'in_le32' and 'out_le32' are substantially atomic, are declared in
> include/asm-ppc/io.h:
>
> extern inline unsigned in_le32(const volatile unsigned __iomem *addr)
> {
> unsigned ret;
>
> __asm__ __volatile__("lwbrx %0,0,%1;\n"
> "twi 0,%0,0;\n"
> "isync" : "=r" (ret) :
> "r" (addr), "m" (*addr));
> return ret;
> }
> extern inline void out_le32(volatile unsigned __iomem *addr, int val)
> {
> __asm__ __volatile__("stwbrx %1,0,%2; eieio" : "=m" (*addr) :
> "r" (val), "r" (addr));
> }
>
> The load istruction is lwbrx and the store istruction is stwbrx: one istruction
> = atomic (do you agree?). isync and eieio are synchronization istruction, if
> executed in a second time doesn't change the behaviour.
Yes, but there are these eieio and sync instructions which have to do
with out of order accesses. To be sure I ask on the linuxppc-embedded ML
and the answer is here:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-December/025456.html
> I test this patch with and without the IPIPE enabled.
>>From my point of view I think is better to remove the spin_* in the ppc arch to
> avoid the spinlock overhead. For a portability issue is better to use a pragma
> #ifdef structure.
Therefore my previous patch should be the right fix. I case it works,
I'm going to integrate it into the PPC ADEOS IPIPE patches.
Wolfgang.
> Antonio
>
>
> Quoting Wolfgang Grandegger <wg@domain.hid>:
>
>> barbalace@domain.hid wrote:
>>> I'm working on linux 2.6.14 + ipipe + xenomai2.2.0 (refer to thread
>>> https://mail.gna.org/public/xenomai-help/2006-05/msg00082.html, maybe the
>> same
>>> case-study).
>>>
>>> I'm using ipipe patch:
>>> adeos-ipipe-2.6.14-ppc-1.3-05.patch
>>>
>>> this and next patch I tried, doesn't work and some write on the flash, if
>> you
>>> doesn't protect it again write (with on-board jumpers).
>>>
>>> I make this simple patch (that I past at the end of the mail).
>>> To use it I recommend to:
>>> 1. extract a Vanilla linux kernel
>>> 2. patch it with the Motorola patch (BSP)
>>> 3. patch it with the ipipe patch (adeos-ipipe-2.6.14-ppc-1.3-05.patch)
>>> 4. apply this patch
>>>
>>> I test it only with write protect enable on the MVME5500 board; flash and
>> eeprom
>>> were not writeable, ensure this with a cat on /proc/cpuinfo.
>> Ah, oh, this is another prime example of PIC code requiring a patch,
>> also on PowerPC :-(. The problem are the Linux spin_* functions in
>> include/asm-ppc/mv64x60.h:
>>
>> /* Define I/O routines for accessing registers on the 64x60 bridge. */
>> extern inline void
>> mv64x60_write(struct mv64x60_handle *bh, u32 offset, u32 val) {
>> ulong flags;
>>
>> spin_lock_irqsave(&mv64x60_lock, flags);
>> out_le32(bh->v_base + offset, val);
>> spin_unlock_irqrestore(&mv64x60_lock, flags);
>> }
>>
>> extern inline u32
>> mv64x60_read(struct mv64x60_handle *bh, u32 offset) {
>> ulong flags;
>> u32 reg;
>>
>> spin_lock_irqsave(&mv64x60_lock, flags);
>> reg = in_le32(bh->v_base + offset);
>> spin_unlock_irqrestore(&mv64x60_lock, flags);
>> return reg;
>> }
>>
>> Why not just iron them with the "spin_*_hw" variants, or remove them
>> completely? That's what your patch does as well. I think the out_le32
>> and in_le32 functions already access the registers atomically. To be
>> save, use "spin_*_hw". Does the attached patch work with and without
>> IPIPE enabled?
>>
>> Thanks for reporting.
>>
>> Wolfgang.
>>
>>> regards,
>>> Antonio Barbalace
[...]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Xenomai-help] Re: [Adeos-main] [PATCH] ppc mvme5500
[not found] ` <1165843368.457d5ba8692bd@domain.hid>
@ 2006-12-11 13:43 ` Wolfgang Grandegger
2006-12-11 14:32 ` Jan Kiszka
0 siblings, 1 reply; 8+ messages in thread
From: Wolfgang Grandegger @ 2006-12-11 13:43 UTC (permalink / raw)
To: barbalace; +Cc: xenomai-help, adeos-main
Hi Antonio,
I re-added the ADEOS and Xenomai mailing lists to CC because others
might be able to help better.
barbalace@domain.hid wrote:
>> Thanks for testing. And please read the complete thread at
>> http://ozlabs.org/pipermail/linuxppc-embedded/2006-December/thread.html#25455
>> containing some more infos.
>
> Ok, so when you deciding the right way for the patch let me know it.
I will use the patch with the spin*_hw functions.
>>> I've another question from you: I'm doing a data acquisition loop with my
>>> hardware; I register an interrupt handler and on it (or on a task waiting
>> on a
>>> sem/mutex) read the data over a VME bus. Result over some tests are:
>>> linux interrupt handling (with ipipe and Xenomai loaded) : 75,763uS
>>> xenomai interrupt handling (obiouvsly with ...): 75,489uS
>> In user- or kernel-space? Under what load? And what processor, clock,
>> memory, cache, etc. are you using?
>
> Tests are in kernel-space, there is only network load: pings, ICMP, DHCP, NFS
> server: not very loaded. The processor is a MPC7455@domain.hid, 512MB RAM, L2 and L3
> cache enabled (maybe, I'm not sure at 100%)... is a MVME5500 board!
Ah, this system is really fast. Then the 75 us are not really the
interrupt latency but include some further latencies (reading the data,
etc.), am I right?. And what does the latency test of the test suite report?
> Testing with the native skin I notice (Xenomai2.2.0) that mutex doesn't behave
> like I think:
> 1. create a mutex
> 2. lock the mutex (infinite)
> 3. start a RT task
> 4. lock the mutex in the RT task (infinite)
> 5. register an interrupt
>
> 6a. ...wait...
> 6. reach an interrupt and unlock the mutex
> 6b. ...then...
>
> 7. start 2-times the code after the previous rt_mutex_lock [this is not
> correct!!!]
> 8. goto 6a.
>
> the rt_mutex_lock is clearly in a for loop.
> Probably I'm in truble. Using a semaphore resolve my problems.
> When using mutex I lose the machine control.
I don't have a quick answer but maybe somebody else can help.
>> It's a long time ago that I have done something for RTAI and I'm not
>> up-to-date with recent RTAI implementations. Please ask this question on
>> the RTAI mailing list.
>
> Ok, so I must ask to them.
>
> Thanks a lot,
> Antonio
Wolfgang.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai-help] Re: [Adeos-main] [PATCH] ppc mvme5500
2006-12-11 13:43 ` [Xenomai-help] " Wolfgang Grandegger
@ 2006-12-11 14:32 ` Jan Kiszka
2006-12-11 17:55 ` barbalace
0 siblings, 1 reply; 8+ messages in thread
From: Jan Kiszka @ 2006-12-11 14:32 UTC (permalink / raw)
To: barbalace; +Cc: xenomai-help, adeos-main
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]
Wolfgang Grandegger wrote:
> barbalace@domain.hid wrote:
>> Testing with the native skin I notice (Xenomai2.2.0) that mutex
>> doesn't behave
>> like I think:
>> 1. create a mutex
>> 2. lock the mutex (infinite)
>> 3. start a RT task
>> 4. lock the mutex in the RT task (infinite)
>> 5. register an interrupt
>>
>> 6a. ...wait...
>> 6. reach an interrupt and unlock the mutex
>> 6b. ...then...
>>
>> 7. start 2-times the code after the previous rt_mutex_lock [this is not
>> correct!!!]
>> 8. goto 6a.
>>
>> the rt_mutex_lock is clearly in a for loop.
>> Probably I'm in truble. Using a semaphore resolve my problems.
>> When using mutex I lose the machine control.
>
> I don't have a quick answer but maybe somebody else can help.
Antonio, please use a recent Xenomai version (e.g. 2.2.5) to avoid that
we may hunt old issues. Next post a simple demo code to xenomai-help,
showing the misbehaviour. We could then check if other archs are
involved, if it's reproducible on further PPC boards, or if some mistake
might have slipped into the code.
From your description I wonder if you lock the mutex in line 2 from the
correct context (a Xenomai thread). If you call that lock from main,
don't forget to invoke rt_task_shadow first.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai-help] Re: [Adeos-main] [PATCH] ppc mvme5500
2006-12-11 14:32 ` Jan Kiszka
@ 2006-12-11 17:55 ` barbalace
2006-12-11 18:10 ` Jan Kiszka
0 siblings, 1 reply; 8+ messages in thread
From: barbalace @ 2006-12-11 17:55 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-help, adeos-main
Quoting Jan Kiszka <jan.kiszka@domain.hid>:
> Antonio, please use a recent Xenomai version (e.g. 2.2.5) to avoid that
> we may hunt old issues.
Ok, could be the right solution.
> Next post a simple demo code to xenomai-help,
> showing the misbehaviour. We could then check if other archs are
> involved, if it's reproducible on further PPC boards, or if some mistake
> might have slipped into the code.
> From your description I wonder if you lock the mutex in line 2 from the
> correct context (a Xenomai thread). If you call that lock from main,
> don't forget to invoke rt_task_shadow first.
A simplified version of the code (in the original code there is an hw DAQ and I
understand that the same code run 2-times, here one could use a buffer to write
for example a u(->for unlocking) and a l(->for locking) ):
/* -- START CODE HERE ---------- demo.c --------------------------------------*/
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <native/task.h>
#include <native/intr.h>
#include <native/mutex.h>
#include <native/sem.h>
#define TASK_PRIO 99
#define TASK_MODE (T_FPU | T_CPU(0))
#define TASK_STKSZ 4096
RT_INTR intr_desc;
RT_TASK task_desc;
RT_MUTEX mutex_desc;
int demo_finalize;
#define INTR_IRQ 76
static irqreturn_t demo_irqhandler(void)
{
rt_mutex_unlock(&mutex_desc); // IPC handling
return RT_INTR_HANDLED;
}
void rt_handler(void *data){
printk(KERN_ERR"entered in RT task\n"); // ok I know is
not right use printk
rt_mutex_lock(&mutex_desc, TM_INFINITE);
for(;;){
rt_mutex_lock(&mutex_desc, TM_INFINITE);
if(demo_finalize == 1)
break;
/* doing something */
}
return;
}
static int demo_init(void)
{
int result;
// initialize MUTEX
int err;
err = rt_mutex_create(&mutex_desc, "demo_mutex");
printk(KERN_ERR"mutex created and locked\n");
demo_finalize = 0;
// create the real-time task waiting for data
err = rt_task_create(&task_desc, "demo_acq", TASK_STKSZ, TASK_PRIO,
TASK_MODE);
if (!err) {
rt_task_start(&task_desc, &rt_handler, NULL);
printk(KERN_ERR"RT task started!\n");
} else
printk(KERN_ERR"can't start RT thread!!!\n");
result = rt_intr_create(&intr_desc, "demo_intr", INTR_IRQ,
demo_irqhandler, 0,
0);
return (0);
}
static void demo_exit(void)
{
rt_intr_delete(&intr_desc);
demo_finalize = 1;
rt_mutex_unlock(&mutex_desc);
rt_task_delete(&task_desc);
printk(KERN_ERR"demo: RT task destroyed\n");
return;
}
module_init(demo_init);
module_exit(demo_exit);
/* --- END CODE HERE ---------------------------------------------------------*/
With this code and Xenomai 2.2.0 you lose the machine control... I resolve this
using semaphores.
regards,
Antonio
PS. excuse me, was my error... replay to all, ok! Thanks!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai-help] Re: [Adeos-main] [PATCH] ppc mvme5500
2006-12-11 17:55 ` barbalace
@ 2006-12-11 18:10 ` Jan Kiszka
0 siblings, 0 replies; 8+ messages in thread
From: Jan Kiszka @ 2006-12-11 18:10 UTC (permalink / raw)
To: barbalace; +Cc: xenomai-help, adeos-main
[-- Attachment #1: Type: text/plain, Size: 4144 bytes --]
barbalace@domain.hid wrote:
> Quoting Jan Kiszka <jan.kiszka@domain.hid>:
>> Antonio, please use a recent Xenomai version (e.g. 2.2.5) to avoid that
>> we may hunt old issues.
> Ok, could be the right solution.
Your issue is independent of the version, still 2.2.5 contains a lot of
fixes.
>
>> Next post a simple demo code to xenomai-help,
>> showing the misbehaviour. We could then check if other archs are
>> involved, if it's reproducible on further PPC boards, or if some mistake
>> might have slipped into the code.
>> From your description I wonder if you lock the mutex in line 2 from the
>> correct context (a Xenomai thread). If you call that lock from main,
>> don't forget to invoke rt_task_shadow first.
>
> A simplified version of the code (in the original code there is an hw DAQ and I
> understand that the same code run 2-times, here one could use a buffer to write
> for example a u(->for unlocking) and a l(->for locking) ):
>
> /* -- START CODE HERE ---------- demo.c --------------------------------------*/
> #include <linux/config.h>
> #include <linux/version.h>
> #include <linux/module.h>
> #include <linux/moduleparam.h>
>
> #include <native/task.h>
> #include <native/intr.h>
> #include <native/mutex.h>
> #include <native/sem.h>
>
>
> #define TASK_PRIO 99
> #define TASK_MODE (T_FPU | T_CPU(0))
> #define TASK_STKSZ 4096
>
> RT_INTR intr_desc;
> RT_TASK task_desc;
> RT_MUTEX mutex_desc;
>
> int demo_finalize;
>
> #define INTR_IRQ 76
>
> static irqreturn_t demo_irqhandler(void)
> {
> rt_mutex_unlock(&mutex_desc); // IPC handling
You cannot unlock a mutex from a non-task context like the IRQ handler
is. Actually, the return value of that call should be EPERM, indicating
the misuse.
>
> return RT_INTR_HANDLED;
> }
>
>
>
> void rt_handler(void *data){
>
> printk(KERN_ERR"entered in RT task\n"); // ok I know is
> not right use printk
There is actually no problem (except growing log files), printk is safe
from RT context under Xenomai.
> rt_mutex_lock(&mutex_desc, TM_INFINITE);
>
> for(;;){
> rt_mutex_lock(&mutex_desc, TM_INFINITE);
>
> if(demo_finalize == 1)
> break;
> /* doing something */
> }
>
> return;
> }
>
> static int demo_init(void)
> {
> int result;
> // initialize MUTEX
> int err;
> err = rt_mutex_create(&mutex_desc, "demo_mutex");
> printk(KERN_ERR"mutex created and locked\n");
>
> demo_finalize = 0;
>
> // create the real-time task waiting for data
> err = rt_task_create(&task_desc, "demo_acq", TASK_STKSZ, TASK_PRIO,
> TASK_MODE);
> if (!err) {
> rt_task_start(&task_desc, &rt_handler, NULL);
> printk(KERN_ERR"RT task started!\n");
> } else
> printk(KERN_ERR"can't start RT thread!!!\n");
>
> result = rt_intr_create(&intr_desc, "demo_intr", INTR_IRQ,
> demo_irqhandler, 0,
> 0);
>
> return (0);
> }
>
> static void demo_exit(void)
> {
> rt_intr_delete(&intr_desc);
>
> demo_finalize = 1;
> rt_mutex_unlock(&mutex_desc);
>
>
> rt_task_delete(&task_desc);
> printk(KERN_ERR"demo: RT task destroyed\n");
>
> return;
> }
>
> module_init(demo_init);
> module_exit(demo_exit);
>
> /* --- END CODE HERE ---------------------------------------------------------*/
>
> With this code and Xenomai 2.2.0 you lose the machine control... I resolve this
> using semaphores.
Using a semaphore to wake the blocked RT task up is actually the Right
Thing. Why not a mutex? A locked mutex always has an owner, which is the
task that successfully acquired it. That owner is ought to release the
mutex again - NO ONE ELSE. And having an owner allows do thing like
inheriting the priority of a waiter to the current owner - or to analyse
who forgot to release it...
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-12-11 18:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-08 0:28 [Adeos-main] [PATCH] ppc mvme5500 barbalace
2006-12-08 11:57 ` Wolfgang Grandegger
2006-12-08 16:35 ` barbalace
2006-12-08 20:38 ` Wolfgang Grandegger
[not found] ` <1165665886.457aa65e2c26e@domain.hid>
[not found] ` <457AAEB9.20403@domain.hid>
[not found] ` <1165834501.457d390514d36@domain.hid>
[not found] ` <457D57B4.3000802@domain.hid>
[not found] ` <1165843368.457d5ba8692bd@domain.hid>
2006-12-11 13:43 ` [Xenomai-help] " Wolfgang Grandegger
2006-12-11 14:32 ` Jan Kiszka
2006-12-11 17:55 ` barbalace
2006-12-11 18:10 ` Jan Kiszka
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.