From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <8bd0f97a0906120905r287665c7w883cf133743fc02f@domain.hid> References: <8bd0f97a0906081015k59a49a1dre38622401f011362@domain.hid> <1244492079.7890.70.camel@domain.hid> <8bd0f97a0906120832h14f200f3rfbd66af868af7710@domain.hid> <1244822047.7890.210.camel@domain.hid> <8bd0f97a0906120905r287665c7w883cf133743fc02f@domain.hid> Content-Type: text/plain Date: Fri, 12 Jun 2009 18:32:22 +0200 Message-Id: <1244824342.6786.21.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] irq hooking and irqflags List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mike Frysinger Cc: xenomai@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.