All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: adeos-main <adeos-main@gna.org>
Subject: Re: [Adeos-main] [git pull] Updates for ipipe-2.6.36-noarch
Date: Tue, 18 Jan 2011 18:27:28 +0100	[thread overview]
Message-ID: <1295371648.1857.88.camel@domain.hid> (raw)
In-Reply-To: <4D35CC68.5010204@domain.hid>

On Tue, 2011-01-18 at 18:22 +0100, Jan Kiszka wrote:
> On 2011-01-18 18:13, Philippe Gerum wrote:
> > On Thu, 2010-11-25 at 17:33 +0100, Jan Kiszka wrote:
> >> The following changes since commit 4c83ab8e3ac5b194695e38bbc253f78e6072ad24:
> >>
> >>   ipipe: tell __ipipe_run_irqtail about the latest IRQ number (2010-11-05 13:52:55 +0100)
> >>
> >> are available in the git repository at:
> >>   git://git.kiszka.org/ipipe-2.6 queues/2.6.35-noarch
> >>
> >> [edited log]
> >> Jan Kiszka (4):
> >>       ipipe: Provide wrapper for IRQ mask/unmask at chip level
> > 
> > Could you give me some hints about the intended usage of these?
> 
> The idea was (and still is but effort stalled ATM) to emulate MSI
> masking on top of that.

Ok, let's keep this on the shelf until we come with a complete solution.
I suspect we will have to resync the Xenomai and I-pipe interfaces to
this end.

> 
> > 
> >>       ipipe: Drop spurious irq_enter/exit from __ipipe_sync_stage
> > 
> > Actually, what is wrong is not with irq_enter/exit, but rather with the
> > fact that we should only attempt a preemption resched when a virq
> > handler returns, and that is a generic operation. There is no point in
> > having uselessly hairy code in the arch-dep section, and that code is
> > pure nop with CONFIG_PREEMPT off.
> > 
> > I just merged something along these lines.
> 
> OK, will have a look.
> 
> > 
> >>       ipipe: Provide __ipipe_spin_trylock_irq for !CONFIG_IPIPE
> >>       Merge commit 'v2.6.35.9' into queues/2.6.35-noarch
> >>
> >> Will follow up with the ipipe specific patches for review.
> > 
> > I'll be merging the IRQ virtualization removal for x86_32 next, but I
> > want to issue an intermediate patch with the pending fixes first, given
> > the potential for regression there is when messing with entry.S.
> > However, I'll merge the EFLAGS fixes early on, since they are obviously
> > required and right, and merge them along with 2.8-03 asap.
> > 
> 
> Fine with me.
> 
> Thanks,
> Jan
> 

-- 
Philippe.




  reply	other threads:[~2011-01-18 17:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 16:33 [Adeos-main] [git pull] Updates for ipipe-2.6.36-noarch Jan Kiszka
2010-11-25 16:38 ` [Adeos-main] [PATCH 1/3] ipipe: Provide wrapper for IRQ mask/unmask at chip level Jan Kiszka
2010-11-25 16:38 ` [Adeos-main] [PATCH 2/3] ipipe: Drop spurious irq_enter/exit from __ipipe_sync_stage Jan Kiszka
2010-11-25 16:38 ` [Adeos-main] [PATCH 3/3] ipipe: Provide __ipipe_spin_trylock_irq for !CONFIG_IPIPE Jan Kiszka
2011-01-18 17:13 ` [Adeos-main] [git pull] Updates for ipipe-2.6.36-noarch Philippe Gerum
2011-01-18 17:22   ` Jan Kiszka
2011-01-18 17:27     ` Philippe Gerum [this message]
2011-01-18 17:30       ` Jan Kiszka
2011-01-18 17:37         ` Gilles Chanteperdrix
2011-01-18 17:44           ` Jan Kiszka
2011-01-25 19:45   ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295371648.1857.88.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=adeos-main@gna.org \
    --cc=jan.kiszka@domain.hid \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.