Re: [RFC] powerpc/irq: Add generic API for setting up cascaded IRQs
On Fri, 2009-09-11 at 23:46 -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
prototype implementation. This probably doesn't work at all right now.
Ben, I'm posting this now to get your thoughts before I go too far down
this path.
Looks ok. I was initially thinking about putting get_irq() in irq_host,
but as we discussed on IRC, a host is not necessarily a PIC, and it's
nice for the parent to have a way to setup/init the cascade in case
it needs to do some HW tweaking there as well.
However, why cascade_setup() and not setup_cascade() which sounds
somewhat more natural ? :-)
Cheers,
Ben.
Cheers,
g.
---
arch/powerpc/include/asm/irq.h|3 ++
arch/powerpc/kernel/irq.c | 20 +++
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 39
+
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0a51376..014e1e8 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -90,6 +90,9 @@ struct irq_host_ops {
/* Update of such a mapping */
void (*remap)(struct irq_host *h, unsigned int virq, irq_hw_number_t
hw);
+ /* Setup hook for cascade irqs */
+ int (*cascade_setup)(int virq, int (*get_irq)(void *data), void *data);
+
/* Translate device-tree interrupt specifier from raw format coming
* from the firmware to a irq_hw_number_t (interrupt line number) and
* type (sense) that can be passed to set_irq_type(). In the absence
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index f7f376e..5a9cb46 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -750,6 +750,26 @@ unsigned int irq_of_parse_and_map(struct device_node
*dev, int index)
}
EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
+unsigned int irq_of_cascade_setup(int virq, int (*get_irq)(void *data),
+ void *data)
+{
+ struct irq_host *host = irq_map[virq].host;
+
+ if (!host) {
+ pr_err(error: no irq host found virq %i !\n, virq);
+ return -ENODEV;
+ }
+
+ /* If host has no cascade setup function, then this method for
+ * setting up a cascade is not available */
+ if (!host-ops-cascade_setup) {
+ pr_err(error: no cascade_setup support on virq %i\n, virq);
+ return -EINVAL;
+ }
+
+ return host-ops-cascade_setup(virq, get_irq, data);
+}
+
void irq_dispose_mapping(unsigned int virq)
{
struct irq_host *host;
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index 480f806..a91c69b 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -437,9 +437,48 @@ static int mpc52xx_irqhost_map(struct irq_host *h,
unsigned int virq,
return 0;
}
+struct mpc52xx_cascade_data {
+ int (*get_irq)(void *data);
+ void *data;
+};
+
+void mpc52xx_handle_level_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct mpc52xx_cascade_data *cascade_data = get_irq_desc_data(desc);
+ int cascade_virq;
+
+ cascade_virq = cascade_data-get_irq(cascade_data-data);
+ if (cascade_virq)
+ generic_handle_irq(cascade_virq);
+}
+
+void mpc52xx_handle_edge_cascade(unsigned int virq, struct irq_desc *desc)
+{
+ mpc52xx_handle_level_cascade(virq, desc);
+ /** TODO: clear edge IRQ here **/
+}
+
+int mpc52xx_cascade_setup(int virq, int (*get_irq)(void *data), void *data)
+{
+ struct mpc52xx_cascade_data *cascade_data;
+
+ cascade_data = kzalloc(sizeof(struct mpc52xx_cascade_data), GFP_KERNEL);
+ if (!cascade_data)
+ return -ENOMEM;
+
+ /* TODO: make this handle edge cascades too */
+ cascade_data-get_irq = get_irq;
+ cascade_data-data = data;
+ set_irq_data(virq, cascade_data);
+ set_irq_chained_handler(virq, mpc52xx_handle_level_cascade);
+
+ return 0;
+}
+
static struct irq_host_ops mpc52xx_irqhost_ops = {
.xlate = mpc52xx_irqhost_xlate,
.map = mpc52xx_irqhost_map,
+ .cascade_setup = mpc52xx_cascade_setup,
};
/**
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] Add support for GCC-4.5's __builtin_unreachable() to compiler.h
On Fri, Sep 11, 2009 at 17:58, David Daneydda...@caviumnetworks.com wrote:
Michael Buesch wrote:
On Friday 11 September 2009 01:56:42 David Daney wrote:
+/* Unreachable code */
+#ifndef unreachable
+# define unreachable() do { for (;;) ; } while (0)
+#endif
# define unreachable() do { } while (1)
? :)
Clearly I was not thinking clearly when I wrote that part. RTH noted the
same thing. I will fix it.
However, people are so used to seeing the `do { } while (0)' idiom,
that they might miss
there's a `1' here, not a `0'.
So perhaps it's better to use plain `for (;;)' for infinite loops?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC5200/BestComm functions question
Hi all, I have a MPC5200B based system with a 16-bit peripheral attached to the Local Bus, and I am looking into possibilities to use BestComm for the data transfer. I found Grant Likely's cool 'mpc5200-localplus-test.c' driver which demonstrates this using the 'gen_bd' driver, and which is apparently a great starting point. However, I also have to (a) 32-bit endianess-swap the data and (b) calculate a 32-bit crc on it. Of course, this is possible with the buffers using the cpu, but I saw some remarks that the Bestcomm engine also includes functions which can perform swapping and crc calculation. I believe it would unload the cpu if the BestComm engine could perform these tasks, but I cannot find a good documentation/example for that. Does anyone know any pointers for that? Or maybe even a tool to create the bestcomm tasks from a 'readable' source? Thanks in advance, Albrecht. pgpdE9qYr3kFR.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5200/BestComm functions question
On Sat, Sep 12, 2009 at 6:36 AM, Albrecht Dreß albrecht.dr...@arcor.de wrote: Hi all, I have a MPC5200B based system with a 16-bit peripheral attached to the Local Bus, and I am looking into possibilities to use BestComm for the data transfer. I found Grant Likely's cool 'mpc5200-localplus-test.c' driver which demonstrates this using the 'gen_bd' driver, and which is apparently a great starting point. I've actually got a better driver which exports an API for doing local plus bus FIFO transfers. It's been posted to the mailing list a couple of times. I'll cc: you the next time I post it (real soon now). However, I also have to (a) 32-bit endianess-swap the data and (b) calculate a 32-bit crc on it. Of course, this is possible with the buffers using the cpu, but I saw some remarks that the Bestcomm engine also includes functions which can perform swapping and crc calculation. I believe it would unload the cpu if the BestComm engine could perform these tasks, but I cannot find a good documentation/example for that. Does anyone know any pointers for that? Or maybe even a tool to create the bestcomm tasks from a 'readable' source? Bestcomm can do that, but Freescale has not publically released the bestcomm documentation, and they do not support writing custom bestcomm tasks. From what I understand there are a number of hidden bugs in the bestcomm engine which you could run into if you deviate from the provided tasks. You're very much on your own if you go down that route. :-( g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc/irq: Add generic API for setting up cascaded IRQs
On Sat, Sep 12, 2009 at 12:28 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-09-11 at 23:46 -0600, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca prototype implementation. This probably doesn't work at all right now. Ben, I'm posting this now to get your thoughts before I go too far down this path. Looks ok. I was initially thinking about putting get_irq() in irq_host, but as we discussed on IRC, a host is not necessarily a PIC, and it's nice for the parent to have a way to setup/init the cascade in case it needs to do some HW tweaking there as well. Cool. Thanks for the review. I'll continue on with this approach and hopefully get something working this weekend. However, why cascade_setup() and not setup_cascade() which sounds somewhat more natural ? :-) I'm a reverse polish kind of guy. I preferring 'subject'_'action' over 'action'_'subject' just because it groups like subjects together. But it doesn't matter much, especially in this case where 'subject' is in a group of exactly 1. :-) I'll do whichever you prefer. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pmc: Don't access lppaca on Book3E
It doesn't exist ! Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/include/asm/pmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/pmc.h b/arch/powerpc/include/asm/pmc.h index ccc68b5..5a9ede4 100644 --- a/arch/powerpc/include/asm/pmc.h +++ b/arch/powerpc/include/asm/pmc.h @@ -29,7 +29,7 @@ int reserve_pmc_hardware(perf_irq_t new_perf_irq); void release_pmc_hardware(void); void ppc_enable_pmcs(void); -#ifdef CONFIG_PPC64 +#ifdef CONFIG_PPC_BOOK3S_64 #include asm/lppaca.h static inline void ppc_set_pmu_inuse(int inuse) -- 1.6.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FTRACE] Enabling function_graph causes OOPS
On Wed, 2009-09-09 at 11:57 +0530, Sachin Sant wrote: Steven Rostedt wrote: I'm going through old email, and I found this. Do you still see this error. I don't recall seeing it myself. I can still recreate this with 31-rc9. When i enable tracing with function_graph i notice the following oops. This happens only once. Later if i try to enable/disable tracing i don't get this oops message. This behavior is observed only with function_graph. Other tracers work fine. Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: ipv6 fuse loop dm_mod sr_mod ehea ibmveth sg cdrom sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod NIP: c0008f30 LR: c0008f04 CTR: 800f6d68 REGS: c0003e98f560 TRAP: 0300 Not tainted (2.6.31-rc9) MSR: 80009032 EE,ME,IR,DR CR: 24000422 XER: 0020 DAR: 0008, DSISR: 4000 TASK = c0003e953b20[2483] 'irqbalance' THREAD: c0003e98c000 CPU: 1 GPR00: c0008f04 c0003e98f7e0 d117ed38 GPR04: 6600 10bf GPR08: 80010021bb40 00ff 80010021bb60 GPR12: 0002 c1032800 effdff68 GPR16: 0fffa39fd6a0 0fffa39e6c38 c0003ebe9c38 f000 GPR20: c0002a6cf980 c0003e98fdf8 c0003e98fba8 0fffa174 GPR24: f000 80010300 ffe0 0009 GPR28: c0003db4 0002 d117da78 c0003e98f850 NIP [c0008f30] .mod_return_to_handler+0x2c/0x64 LR [c0008f04] .mod_return_to_handler+0x0/0x64 Call Trace: [c0003e98f7e0] [c0002a6cf980] 0xc0002a6cf980 (unreliable) [c0003e98f850] [c0008f04] .mod_return_to_handler+0x0/0x64 [c0003e98f900] [c0008f04] .mod_return_to_handler+0x0/0x64 [c0003e98f9a0] [c0008f04] .mod_return_to_handler+0x0/0x64 [c0003e98fa30] [c0008ed0] .return_to_handler+0x0/0x34 (.bad_page_fault+0xc8/0xe8) [c0003e98fb30] [c0008ed0] .return_to_handler+0x0/0x34 (handle_page_fault+0x3c/0x5c) [c0003e98fc20] [c0008ed0] .return_to_handler+0x0/0x34 (.ehea_h_query_ehea_port+0x74/0x9c [ehea]) [c0003e98fcd0] [c0008ed0] .return_to_handler+0x0/0x34 (.ehea_get_stats+0xa0/0x1d0 [ehea]) [c0003e98fd80] [c0008ed0] .return_to_handler+0x0/0x34 (.dev_get_stats+0x50/0xec) [c0003e98fe30] [c0008ed0] .return_to_handler+0x0/0x34 (.dev_seq_show+0x5c/0x140) Instruction dump: 4e800020 f881ffe0 f861ffe8 f841fff0 fbe1fff8 7c3f0b78 f821ff91 3c80 6084 788407c6 6484 6084 e8440008 48126375 6000 7c6803a6 ---[ end trace bb43efc994aed790 ]--- I'm looking at your back dump and this really bothers me. I did a objdump -dr arch/powerpc/kernel/entry_64.o and this is what I have: 0968 .mod_return_to_handler: 968: f8 81 ff e0 std r4,-32(r1) 96c: f8 61 ff e8 std r3,-24(r1) 970: f8 41 ff f0 std r2,-16(r1) 974: fb e1 ff f8 std r31,-8(r1) 978: 7c 3f 0b 78 mr r31,r1 97c: f8 21 ff 91 stdur1,-112(r1) 980: 3c 80 00 00 lis r4,0 982: R_PPC64_ADDR16_HIGHEST ftrace_return_to_handler 984: 60 84 00 00 ori r4,r4,0 986: R_PPC64_ADDR16_HIGHER ftrace_return_to_handler 988: 78 84 07 c6 rldicr r4,r4,32,31 98c: 64 84 00 00 orisr4,r4,0 98e: R_PPC64_ADDR16_HI ftrace_return_to_handler 990: 60 84 00 00 ori r4,r4,0 992: R_PPC64_ADDR16_LO ftrace_return_to_handler 994: e8 44 00 08 ld r2,8(r4) 998: 48 00 00 01 bl 998 .mod_return_to_handler+0x30 998: R_PPC64_REL24 .ftrace_return_to_handler 99c: 60 00 00 00 nop 9a0: 7c 68 03 a6 mtlrr3 The bug happened at mod_return_to_handler+0x2c which is 994 above. Your reg dump shows r4 is 0, and worse yet, looking at the code: 4e800020 f881ffe0 f861ffe8 f841fff0 fbe1fff8 7c3f0b78 f821ff91 3c80 6084 788407c6 6484 6084 e8440008 48126375 6000 7c6803a6 The 6484 6084 shows that the linker never resolved the address to ftrace_return_to_handle?? Something is totally messed up here. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FTRACE] Enabling function_graph causes OOPS
On Sun, 2009-09-13 at 00:07 -0400, Steven Rostedt wrote: 982: R_PPC64_ADDR16_HIGHEST ftrace_return_to_handler 984: 60 84 00 00 ori r4,r4,0 986: R_PPC64_ADDR16_HIGHER ftrace_return_to_handler 988: 78 84 07 c6 rldicr r4,r4,32,31 98c: 64 84 00 00 orisr4,r4,0 98e: R_PPC64_ADDR16_HI ftrace_return_to_handler 990: 60 84 00 00 ori r4,r4,0 992: R_PPC64_ADDR16_LO ftrace_return_to_handler 994: e8 44 00 08 ld r2,8(r4) 998: 48 00 00 01 bl 998 .mod_return_to_handler+0x30 998: R_PPC64_REL24 .ftrace_return_to_handler 99c: 60 00 00 00 nop 9a0: 7c 68 03 a6 mtlrr3 .../... Something is totally messed up here. Could it be that we don't handle R_PPC64_ADDR16_* relocs in arch/powerpc/kernel/modules/module_64.c ? Sachin, do you see a bunch of Unknown ADD relocation in your dmesg ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
