Re: [Xenomai-core] irq hooking and irqflags

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2009-06-12 at 12:05 -0400, Mike Frysinger wrote:
> On Fri, Jun 12, 2009 at 11:54, Philippe Gerum wrote:
> > On Fri, 2009-06-12 at 11:32 -0400, Mike Frysinger wrote:
> >> On Mon, Jun 8, 2009 at 16:14, Philippe Gerum wrote:
> >> > On Mon, 2009-06-08 at 13:15 -0400, Mike Frysinger wrote:
> >> >> i just finished converting Blackfin to the new irqflags.h system which
> >> >> included punting pretty much all of the irq.h guts (including IPIPE).
> >> >> since irqflags.h is directly designed for hooking the lower irq stuff,
> >> >> do we still need this stuff patched into the Blackfin code ?  seems
> >> >> like patching linux/irqflags.h would get you support for pretty much
> >> >> all arches for free ...
> >> >
> >> > I wish it was so, but we do need to override the native routines that
> >> > manipulate the hw interrupt state when the I-pipe is enabled, and using
> >> > the irqflags framework will still require the implementation to provide
> >> > the raw_local_irq* helpers linux/irqflags.h requires, in some arch-dep
> >> > companion file for the Blackfin. This is the one we want to patch for
> >> > the I-pipe, to get them virtualized.
> >>
> >> well ive just tossed the code for 2.6.31 since it's pretty hopeless
> >> for me to get this right.  consider yourself notified ! ;)
> >
> > Ok, I now consider myself in trouble then.
> >
> > Btw, could you give me some hints regarding the Blackfin project policy
> > for updating svn://sources.blackfin.uclinux.org/linux-kernel and/or
> > git://sources.blackfin.uclinux.org/git/readonly-mirrors/linux-kernel.git?
> > Is the latter still a pre-mainline staging tree pulling from the former?
> 
> let's just forget about that stuff from now on (or at least as long as
> i'm handling the tree)

Hey, nice, you just allowed me to save 580Mb of disk space!

> 
> > More specifically, which one shall I pull your changes from?
> 
> boom:
> http://git.kernel.org/?p=linux/kernel/git/vapier/blackfin.git;a=shortlog;h=trunk
> 

Hey, nice, you just allowed me to eat 738Mb of disk space!

> currently i rebase this branch as i treat it as a set of patches on
> top of the upstream branch.  but if you only have one patch to
> maintain against these sources, that shouldnt be too much of a problem
> ... you can pop/push it ...
> 
> if that really is a hassle for you though, i can look at making a
> branch that is full of ugly merge commits and keep my patch series in
> a different branch ...
> 

That should be ok; I have a single patch and this is fine as long as I
am able to rebase it on the next tree; I don't need much linear history
here. I will send the arch-dep part of it for inclusion as usual, the
rest landing on the bfin_patch/ area IIRC.

> > (the blackfin.uclinux.org seems currently unreachable).
> 
> ugh, rogers in canada really blows sometimes.  this isnt the first
> time they screwed up routing and sent things into an infinite loop.

Oops, they did it again. 

> -mike
-- 
Philippe.