Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 May 2004 11:19:27 -0700 (PDT)
From:      Nate Lawson <nate@root.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-acpi@FreeBSD.org
Subject:   Re: Bug?  PCI link device _SRS
Message-ID:  <20040528111825.I99600@root.org>
In-Reply-To: <200405281334.03956.jhb@FreeBSD.org>
References:  <29AC424F54821A4FB5D7CBE081922E40928BB1@hdsmsx403.hd.intel.com> <200405281236.52812.jhb@FreeBSD.org> <20040528095533.E99072@root.org> <200405281334.03956.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 May 2004, John Baldwin wrote:
> On Friday 28 May 2004 01:00 pm, Nate Lawson wrote:
> > John, great to see you're working on a lot of these already.  Appreciate
> > it.
> >
> > On Fri, 28 May 2004, John Baldwin wrote:
> > > On Thursday 27 May 2004 04:55 pm, Brown, Len wrote:
> > > >    If a platform gives you a _CRS IRQ that
> > > >    is outside the _PRS list, then do no
> > > >    stick with the _CRS -- select
> > > >    a new (valid) one from the _PRS list.
> > >
> > > Ah, I have a patch to do this already that I can commit.
> > >
> > > >    If a platform gives you a _CRS IRQ that
> > > >    is different from the _SRS you just
> > > >    invoked.  Assume that the _SRS worked
> > > >    and that the _CRS is bogus.
> > >
> > > Huh, we don't do that type of checking, but we do use _CRS for later
> > > devices routed to the same link to see what IRQ they should use.
> >
> > I think the first one will take care of how we handle this one.  We'll do
> > _SRS and ignore the _CRS that comes back.  Later, we go to program a
> > device that has the same link and its _CRS will be outside the _PRS list,
> > so we'll fall back to selecting a valid one from _PRS.
>
> But what if we chose a different IRQ?  Then the routing for the earlier device
> would be wrong.  acpi_pcib_route_interrupt() needs to work with the pci_link
> code more closely, and we should cache the current IRQ in the softc and use
> that to determine if it is routed rather than _CRS I think.  This is how the
> new $PIR code works.

I was assuming that the _PRS selection algorithm was idempotent and
deterministic.  If this is not the case, you will need to cache the value
you set.

-Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040528111825.I99600>