Re: [OpenBIOS] sun4u interrupt-map

[Tarl Neustaedter]

On 2012-Apr-4 18:15 , Artyom Tarasenko wrote:
> > > Evidently on the Ultra-5, we aren't using three cells to identify the child,
> > >  only two. So we probably skip child.mid in both of the above specifications.
>
> And what are child.hi and child.lo? Is it the physical address, stored
> in the reg property?

Yes. It's bus-binding specific. I don't remember what the parent bus of 
the PCI node was on an Ultra-5, but presumably <3c,0> indicates the PCI 
root complex. It should be from the reg property of that same PCI node.
> But then the filter (address&   0x3e) == 0x3c can potentially hit
> really a lot of devices?

In this case, the mask of 0x3e (0011.1110) presumably indicates there 
are only five meaningful bits in the child address that should be used 
for comparison. Interestingly, by having a zero in the intrspec field, 
presumably it only allows one interrupt (zero) to be mapped in this case.

sun4u interrupt-map

[Artyom Tarasenko]

On Thu, Apr 5, 2012 at 12:37 AM, Tarl Neustaedter  wrote:
> On 2012-Apr-4 18:15 , Artyom Tarasenko wrote:
> > > > Evidently on the Ultra-5, we aren't using three cells to identify the
> > > > child,
> > > >  only two. So we probably skip child.mid in both of the above
> > > > specifications.
> >
> > And what are child.hi and child.lo? Is it the physical address, stored
> > in the reg property?
>
> Yes. It's bus-binding specific. I don't remember what the parent bus of the
> PCI node was on an Ultra-5, but presumably <3c,0> indicates the PCI root
> complex. It should be from the reg property of that same PCI node.
> > But then the filter (address&   0x3e) == 0x3c can potentially hit
> >
> > really a lot of devices?
>
> In this case, the mask of 0x3e (0011.1110) presumably indicates there are
> only five meaningful bits in the child address that should be used for
> comparison. Interestingly, by having a zero in the intrspec field,
> presumably it only allows one interrupt (zero) to be mapped in this case.

I gave the following shot:

0 > show-devs
ffe1a2b0 /
( ... )
ffe29140 /pci@1fe,0 (pci)
ffe299a8 /pci@1fe,0/pci@1 (pci)
ffe2a060 /pci@1fe,0/pci@1,1 (pci)
ffe2aeb8 /pci@1fe,0/ebus@3
ffe2bb00 /pci@1fe,0/ebus@3/su@0,1 (serial)
( ... )

ok
cd /pci@1fe,0/ebus
000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+
ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property

0000001f encode-int 00ffffff encode-int encode+ 00000003 encode-int encode+
" interrupt-map-mask" property

cd /pci@1fe,0/ebus@3/su
1 encode-int " interrupts" property
device-end

And Linux's of_device_64 interprets it the following way:

/pci@1f,0: direct translate 7f0 --> 1
/pci@1f,0: direct translate 7ee --> 1
/pci@1f,0: direct translate 7ef --> 1
/pci@1f,0: direct translate 7e5 --> 1

^^^^^ This is strange but is the same regardless my interrupt-map try above.

/pci@1f,0/ebus@3/su@1fe,20003f8: Apply [/pci@1f,0/ebus@3:1] imap --> [NULL:1]

^^^^^ Have I done something wrong, or more interrupt mappings  is needed?