On Thu, Apr 5, 2012 at 12:37 AM, Tarl Neustaedter tarl-b2@tarl.net 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?