🚀 go-pugleaf

On Mon, Apr 22, 2013 at 09:07:57PM +0900, KIYOHARA Takashi wrote:
> Hi! Chuck,
> 
> 
> From: Chuck Silvers <chuq@chuq.com>
> Date: Sun, 21 Apr 2013 07:32:29 -0700
> 
> > On Mon, Apr 15, 2013 at 12:26:06AM +0300, Jukka Ruohonen wrote:
> > > On Sat, Apr 13, 2013 at 06:26:19PM -0700, Chuck Silvers wrote:
> > > > anyway, there are more problems with the new pchb,
> > > > it's unhappy with the other two PCI root bridges in this system:
> > > > 
> > > > pchb7 at acpi0 (PCI1, PNP0A03-8): ACPI Host-PCI Bridge
> > > > pchb7: Can't get _PRT
> > > > pchb8 at acpi0 (PCI2, PNP0A03-9): ACPI Host-PCI Bridge
> > > > pchb8: Can't get _PRT
> > > > 
> > > > these really don't have a _PRT method, but the rest of the code doesn't mind.
> > > > they still attach fine with the mainbus attachment:
> > > > 
> > > > I guess that's because even though these root bridges themselves don't have
> > > > _PRT methods, the PCI bridges directly under them do have them.
> > > > so we'll need to accomodate that somehow.
> > > 
> > > Why not just probe _PRT in the match()? According to the spec, _PRT should
> > > be mandatory for all PCI root bridges.
> > 
> > I'm confused... if we were to make pchb_acpi_match() fail to match when the
> > root bridge device doesn't have a _PRT object, then how would you propose to
> > support systems like mine where some of the PCI root bridge devices don't have
> > _PRT objects?
> 
> hmm...
> Can you try processing of _CRS of pci_intr_map() written to the patch
> of ia64?
> 
>   http://mail-index.NetBSD.org/tech-kern/2013/04/15/msg015173.html
> 
> Linux was performing this processing by MI layer(under drivers/acpi/). 
> This processing is also implemented by pchb_acpi.c. 

I guess you're thinking about making an MI acpi_pci_intr_map() that
can be called from pci_intr_map() on both x86 and ia64?   that sounds reasonable.
I can try doing that but I'm not sure when I'll have time for it.

-Chuck