[Xenomai-core] irq hooking and irqflags

[Xenomai-core] irq hooking and irqflags

[Mike Frysinger]

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 ...
-mike

Re: [Xenomai-core] irq hooking and irqflags

[Philippe Gerum]

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.

> -mike
-- 
Philippe.

Re: [Xenomai-core] irq hooking and irqflags

[Mike Frysinger]

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 ! ;)
-mike

Re: [Xenomai-core] irq hooking and irqflags

[Philippe Gerum]

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?

More specifically, which one shall I pull your changes from?
(the blackfin.uclinux.org seems currently unreachable).

TIA,

> -mike
-- 
Philippe.

Re: [Xenomai-core] irq hooking and irqflags

[Mike Frysinger]

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)

> 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

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 ...

> (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.
-mike

Re: [Xenomai-core] irq hooking and irqflags

[Philippe Gerum]

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.

Re: [Xenomai-core] irq hooking and irqflags

[Mike Frysinger]

On Fri, Jun 12, 2009 at 12:32, Philippe Gerum wrote:
> On Fri, 2009-06-12 at 12:05 -0400, Mike Frysinger wrote:
>> On Fri, Jun 12, 2009 at 11:54, Philippe Gerum wrote:
>> > 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!

hmm maybe i should run gc/pack on the tree and prune unreferenced objects.

>> 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.

git rebase has an --onto option which should let you do it.  git am -3
also does a pretty good job.  but if it does get to be a hassle, lemme
know.
-mike