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
ler ISR.
Now the big question: does 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 taskl
having explicitly written all of the above and thought
about the various possible modes of the master and of the slave 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
On Sun, 18 Apr 2010 05:34:39 +0200
Guillaume Knispel 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
> CONFIG_HARDIRQS_SW
On Sun, 18 Apr 2010 21:14:12 +0200 (CEST)
Thomas Gleixner 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 sign
ows if it's safe to activate 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
Linuxp
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
CC: linux-ker...@vger.kernel.org
CC: Linuxppc-dev@lists.ozlabs.org
CC: Bartlomiej Zolnierkiewicz
CC: Benjamin Herrenschmidt
CC: Haavard Skin
On Tue, 27 Apr 2010 15:42:11 +0200 (CEST)
Thomas Gleixner 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
e for [1/2]
- 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 |
ml/2010/4/19/129 for the first discussion about
this problem.
Signed-off-by: Guillaume Knispel
CC: linux-ker...@vger.kernel.org
CC: Linuxppc-dev@lists.ozlabs.org
CC: Bartlomiej Zolnierkiewicz
CC: Benjamin Herrenschmidt
CC: Haavard Skinnemoen
CC: Ingo Molnar
CC: Lars-Peter Clausen
CC: Linus To
Following "genirq: always build resend_irqs" and previous changes, this
commit updates the genirq DocBook.
Signed-off-by: Guillaume Knispel
CC: linux-ker...@vger.kernel.org
CC: Linuxppc-dev@lists.ozlabs.org
CC: Bartlomiej Zolnierkiewicz
CC: Benjamin Herrenschmidt
CC: Haavard Skin
n of prior postings to this mail list?
Maybe try something like :
http://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
e same issue that the 8272 about
PC2 / PC3 missing which shifts 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
__
ures.
Signed-off-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/powe
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 -
On Tue, 09 Dec 2008 09:16:50 -0600
Timur Tabi 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.
> >
On Mon, 15 Dec 2008 08:21:05 +1100
Paul Mackerras wrote:
> Guillaume Knispel writes:
>
> > On Tue, 09 Dec 2008 09:16:50 -0600
> > Timur Tabi wrote:
> >
> > > Guillaume Knispel wrote:
> > >
> > > > blk = NULL; at the end of the loop i
18 matches
Mail list logo