public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC][PATCH 0/2] SN platform needs platform_irq_to_vector?
Date: Fri, 03 Aug 2007 06:20:15 +0000	[thread overview]
Message-ID: <1186122016.3985.88.camel@kane-linux> (raw)
In-Reply-To: <1186028871.3875.12.camel@kane-linux>

2007-08-02 (木) の 14:32 -0500 に John Keller さんは書きました:
> > 
> > Hi,
> > 
> > This is FYI.
> > 
> > If VECTOR_DOMAIN_PERCPU is NOT enabled:
> > 
> > The "irq = vector" is always true in the following cases:
> >     - reserve_irq_vector(), which is used only by SN
> >     - create_irq() used on the system that has NO I/O SAPIC
> 
> Could you say a bit more about this case. I see create_irq()
> calling find_unassigned_vector() and find_unassigned_irq().
> How is "irq = vector" guaranteed to be always true in this case?
> 

Both find_unassigned_vector() and find_unassigned_irq() searchs the
number from IA64_FIRST_DEVICE_VECTOR. And all irq and vector numbers
from IA64_FIRST_DEVICE_VECTOR to IA64_LAST_DEVICE_VECTOR are not used.

The create_irq() acquires both irq number and vector number using
find_unassigned_irq() and find_unassigned_vector() respectively and
bind them, with vector_lock held.

The clear_irq_vector(), which is called through destroy_irq() and so
on, frees both irq and vector with vector_lock held.

Since oth irq and vector are acquired/freed at a time, "irq = vector"
is guaranteed.

But there is a exception destroy_and_reserve_irq(), which is called
by IOSAPIC code. It frees both irq and vector, and reserve irq after
that. That is, it only frees vector. This is required for fixed
mapping between gsi and irq.

Thanks,
Kenji Kaneshige


> John
> 
> 
> 
> >     - assign_irq_vector() with AUTO_ASSIGN specified
> >     - Vectors outside FIRST_DEVICE_VECTOR to LAST_DEVICE_VECTOR
> > 
> > The "irq = vector" is not always true in the folliwng cases:
> >     - create_irq() used on the system that has I/O SAPICs.
> >     - assign_irq_vector() with the value other than AUTO_ASSIGN
> >       specified on the system has I/O SAPICs.
> > 
> > And it is not ensured that those are true even in the future.
> > 
> > Yasuaki, could you check if it is correct?
> > 
> > Thanks,
> > Kenji Kaneshige
> > 
> > 
> > 
> > 2007-08-02 (木) の 08:26 -0500 に John Keller さんは書きました:
> > > Yes, we'll take a look at it.
> > > 
> > > John
> > > 
> > > 
> > > > 
> > > > Hi Kenji-san
> > > > 
> > > > I believe we need this property, but I am not 100% sure, so I am
> > > > going to forward your patch to our team who maintain the IRQ code
> > > > for Altix.
> > > > 
> > > > Mike, Aaron or John, would one of you have time to take a look at
> > > > this?
> > > > 
> > > > Thanks,
> > > > Jes
> > > > 
> > > > 
> > > > Kenji Kaneshige wrote:
> > > > > Hi Jes-san, Russ-san, Christoph-san and SN platform developers,
> > > > > 
> > > > > I glanced over the SN code, and I found SN platform doesn't have SN
> > > > > specific irq_to_vector() function, though it has SN specific
> > > > > local_vector_to_irq() function. I guess it was OK because maybe SN
> > > > > platform depends on irq = vector and old generic irq_to_vector() was
> > > > > just returning the same value as irq.
> > > > > 
> > > > > The irq_to_vector() function, however, has been changed by vector
> > > > > domain support, and currently it can return the different value from
> > > > > irq, even when VECTOR_DOMAIN_PERCPU is not enabled. This can happen
> > > > > when an interrupt thorough I/O SAPIC is unregistered and another
> > > > > interupt is registered. So if my guess (SN platform depends on irq =
> > > > > vector) is true, something problem might happen on SN platform when
> > > > > PCI hotplugging or driver reloading.
> > > > > 
> > > > > If it is true that SN platform depends on irq = vector, we need to
> > > > > implement SN specific irq_to_vector() that returns the same value as
> > > > > irq, I think. I made sample patches to implement platform specific
> > > > > irq_to_vector() as follows. Note that [PATCH 2/2] is not tested yet
> > > > > because I don't have any SN platform unfortunately.
> > > > > 
> > > > >     [PATCH 1/2] Add base support for platform_irq_to_vector()
> > > > >     [PATCH 2/2] Implement platform_irq_to_vector() for SN
> > > > > 
> > > > > Could you give me comments?
> > > > > 
> > > > > Thanks,
> > > > > Kenji Kaneshige
> > > > > 
> > > > 
> > > > 
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  parent reply	other threads:[~2007-08-03  6:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-02  4:27 [RFC][PATCH 0/2] SN platform needs platform_irq_to_vector? Kenji Kaneshige
2007-08-02  7:27 ` Jes Sorensen
2007-08-02 13:26 ` John Keller
2007-08-02 14:04 ` Kenji Kaneshige
2007-08-02 14:50 ` Russ Anderson
2007-08-02 17:38 ` Keith Rich
2007-08-02 19:32 ` John Keller
2007-08-03  5:22 ` Kenji Kaneshige
2007-08-03  6:04 ` Yasuaki Ishimatsu
2007-08-03  6:20 ` Kenji Kaneshige [this message]
2007-08-03 14:58 ` Russ Anderson
2007-08-03 18:03 ` John Keller
2007-08-03 18:19 ` Luck, Tony
2007-08-06 13:59 ` John Keller

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=1186122016.3985.88.camel@kane-linux \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-ia64@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox