On 08.01.2015 11:31, Peter Maydell wrote: > On 7 January 2015 at 15:52, Claudio Fontana <claudio.font...@huawei.com> > wrote: >> Interrupt map does not seem to work for me; incidentally this ends up being >> the same kind of undocumented blob that Alvise posted in his series. Can >> you add a good comment about what the ranges property contains >> (the 0x01000000, 0x02000000 which I suspect means IO vs MMIO IIRC, but >> there is no need to be cryptic about it). > > The binding docs live in the kernel: > https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/host-generic-pci.txt > (which reference the upstream openfirmware specs): > http://www.firmware.org/1275/practice/imap/imap0_9d.pdf > > so we can provide a brief summary comment here, but if the kernel > binding docs are confusing (which they kind of are) we should really > get them improved... > > On the 'compatible' string: > https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/host-generic-pci.txt > doesn't say anything about using "pci" here in either the > text or the example binding.
Thank you for these pointers. I think that putting a comment with this information (even just a pointer to the effect of "just look at host-generic-pci.txt in the Linux kernel documentation to understand what's going on here" would be helpful, or even go directly referring to the "Open Firmware Recommended Practice: Interrupt Mapping", since QEMU should be guest OS agnostic - to some extent.. -). Also I think Alex' proposal to use defines for IO Space vs Memory Space instead of hardcoding 0x1000000 / 0x2000000 is a good thing. I think the kernel binding docs could be made more helpful, but since I am in the position of trying to figure this stuff out I am not in the best position to make them better.. Thanks, Claudio
