Re: question about cpm_uart_cpm2.c Section mismatch in reference from the function cpm_uart_allocbuf

2010-05-05 Thread Guillaume Knispel
://www.google.com/#q=site%3Alists.ozlabs.org+cpm_uart_allocbuf (I have not checked the results) Cheers! Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCHv2 0/2] genirq: reliably replay pending edge-triggered irq (plus doc)

2010-05-03 Thread Guillaume Knispel
] - Correct spelling errors in [2/2] [v1]- initial patch Guillaume Knispel (2): genirq: reliably replay pending edge-triggered irq genirq: update doc Documentation/DocBook/genericirq.tmpl | 73 ++-- kernel/irq/resend.c |6 --- 2

[PATCHv2 1/2] genirq: reliably replay pending edge-triggered irq

2010-05-03 Thread Guillaume Knispel
about this problem. Signed-off-by: Guillaume Knispel gknis...@proformatique.com CC: linux-ker...@vger.kernel.org CC: Linuxppc-dev@lists.ozlabs.org CC: Bartlomiej Zolnierkiewicz bzoln...@gmail.com CC: Benjamin Herrenschmidt b...@kernel.crashing.org CC: Haavard Skinnemoen hskinnem...@atmel.com CC: Ingo

[PATCHv2 2/2] genirq: update doc

2010-05-03 Thread Guillaume Knispel
Following genirq: always build resend_irqs and previous changes, this commit updates the genirq DocBook. Signed-off-by: Guillaume Knispel gknis...@proformatique.com CC: linux-ker...@vger.kernel.org CC: Linuxppc-dev@lists.ozlabs.org CC: Bartlomiej Zolnierkiewicz bzoln...@gmail.com CC: Benjamin

Re: [PATCH 1/2] genirq: reliably replay pending edge-triggered irq

2010-04-28 Thread Guillaume Knispel
On Tue, 27 Apr 2010 15:42:11 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Thu, 22 Apr 2010, Guillaume Knispel wrote: [snip] acked and masked at controller level and IRQ_PENDING is set. --- arch/arm/Kconfig |4 arch/arm/configs

[PATCH 0/2] genirq: reliably replay pending edge-triggered irq (plus doc)

2010-04-22 Thread Guillaume Knispel
undocumented changes to genirq. -- Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] genirq: update doc

2010-04-22 Thread Guillaume Knispel
Following genirq: always build resend_irqs and previous changes, this commit updates the genirq DocBook. Signed-off-by: Guillaume Knispel gknis...@proformatique.com CC: linux-ker...@vger.kernel.org CC: Linuxppc-dev@lists.ozlabs.org CC: Bartlomiej Zolnierkiewicz bzoln...@gmail.com CC: Benjamin

Re: Pending interrupts not always replayed

2010-04-19 Thread Guillaume Knispel
On Sun, 18 Apr 2010 21:14:12 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Sun, 18 Apr 2010, Guillaume Knispel wrote: Now everything seems to work fine: my device was not previously not interrupting anymore after typically 1 or 2 minutes (because the interrupt signal stays

Pending interrupts not always replayed

2010-04-19 Thread Guillaume Knispel
CONFIG_HARDIRQS_SW_RESEND for a powerpc or are there some known dangerous interactions? (I'll give it a try on my side in the meantime anyway) Cheers! -- Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: Pending interrupts not always replayed

2010-04-18 Thread Guillaume Knispel
On Sun, 18 Apr 2010 05:34:39 +0200 Guillaume Knispel gknis...@proformatique.com wrote: From reading the code (kernel/irq stuffs), it seems that at least some handle_edge_irq based interrupts are not replayed when enabling if desc-chip-retrigger == NULL and on a platform where

Re: Is volatile always verboten for FSL QE structures?

2009-10-02 Thread Guillaume Knispel
Michael Barkowski wrote: Kumar Gala wrote: On Oct 2, 2009, at 9:46 AM, Timur Tabi wrote: Michael Barkowski wrote: Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be

Re: Configure CPM2 PORTC pin (PC9) for external interrupt?

2009-08-14 Thread Guillaume Knispel
other vectors, but I don't know if 56 for PC9 take that into account. PS: in the future make sure to include your Linux version number, so we know if an issue apply or not. -- Guillaume KNISPEL ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: OpenPIC / CPM2 PIC and cascading interrupt priorities

2009-02-15 Thread Guillaume Knispel
and their combinations (in the general case for Linux, not just for OpenPIC and CPM2), I'm starting to think that it would be quite complicated and error prone, so i guess i'll happily use a tasklet :) Thanks! Guillaume Knispel ___ Linuxppc-dev mailing

OpenPIC / CPM2 PIC and cascading interrupt priorities

2009-02-14 Thread Guillaume Knispel
anybody think it could be interesting to reorganize the Linux irq layers such as the priorities of cascaded interrupts are respected (that would need some changes in the architecture independent code), or is this a stupid idea and I should just use a tasklet? Cheers, Guillaume KNISPEL

Re: [PATCH] Fix corruption error in rh_alloc_fixed()

2008-12-14 Thread Guillaume Knispel
On Tue, 09 Dec 2008 09:16:50 -0600 Timur Tabi ti...@freescale.com wrote: Guillaume Knispel wrote: blk = NULL; at the end of the loop is what is done in the more used rh_alloc_align(), so for consistency either we change both or we use the same construction here. I also think

Re: [PATCH] Fix corruption error in rh_alloc_fixed()

2008-12-14 Thread Guillaume Knispel
On Mon, 15 Dec 2008 08:21:05 +1100 Paul Mackerras pau...@samba.org wrote: Guillaume Knispel writes: On Tue, 09 Dec 2008 09:16:50 -0600 Timur Tabi ti...@freescale.com wrote: Guillaume Knispel wrote: blk = NULL; at the end of the loop is what is done in the more used

[PATCH] Fix corruption error in rh_alloc_fixed()

2008-12-09 Thread Guillaume Knispel
-by: Guillaume Knispel [EMAIL PROTECTED] --- Fix an error in rh_alloc_fixed() that made allocations succeed when they should fail, and corrupted management structures. diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c index 29b2941..45907c1 100644 --- a/arch/powerpc/lib/rheap.c +++ b/arch

Re: [PATCH] Fix corruption error in rh_alloc_fixed()

2008-12-09 Thread Guillaume Knispel
On Tue, 09 Dec 2008 09:03:19 -0600 Timur Tabi [EMAIL PROTECTED] wrote: Guillaume Knispel wrote: There is an error in rh_alloc_fixed() of the Remote Heap code: If there is at least one free block blk won't be NULL at the end of the search loop, so -ENOMEM won't be returned and the else