://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
]
- 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
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
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
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
undocumented changes to genirq.
--
Guillaume Knispel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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
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
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
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
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
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
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
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
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
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
-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
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
18 matches
Mail list logo