Re: [Xenomai-core] irq hooking and irqflags

2009-06-12 Thread 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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] irq hooking and irqflags

2009-06-12 Thread 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.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] irq hooking and irqflags

2009-06-12 Thread 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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] irq hooking and irqflags

2009-06-12 Thread 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.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] irq hooking and irqflags

2009-06-12 Thread 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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] irq hooking and irqflags

2009-06-08 Thread 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.



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core