On Wed, Jan 13, 2010 at 7:17 PM, Alexander Graf <ag...@suse.de> wrote:
>
> On 13.01.2010, at 19:47, Blue Swirl wrote:
>
>> On Tue, Jan 12, 2010 at 10:11 PM, Alexander Graf <ag...@suse.de> wrote:
>>>
>>> On 12.01.2010, at 21:52, Blue Swirl wrote:
>>>
>>>> On Tue, Jan 12, 2010 at 8:34 PM, Alexander Graf <ag...@suse.de> wrote:
>>>>>
>>>>> On 12.01.2010, at 20:45, Blue Swirl wrote:
>>>>>
>>>>>> On Tue, Jan 12, 2010 at 11:58 AM, Alexander Graf <ag...@suse.de> wrote:
>>>>>>> I'm trying to get the PPC64 system emulation target working finally.
>>>>>>> While doing so, I ran into several issues, all related to PCI this time.
>>>>>>>
>>>>>>> This patchset fixes all the PCI config space access and PCI interrupt
>>>>>>> mapping issues I've found on PPC64. Using this and a patched OpenBIOS
>>>>>>> version, I can successfully access IDE devices and was booting a guest
>>>>>>> into the shell from IDE using serial console.
>>>>>>>
>>>>>>> To leverage this patch, you also need a few patches to OpenBIOS. I'll
>>>>>>> present them to the OpenBIOS list, but in general getting patches into
>>>>>>> Qemu is harder than getting them into OpenBIOS. So I want to wait for
>>>>>>> the review process here first.
>>>>>>>
>>>>>>> Find the OpenBIOS patch at: http://alex.csgraf.de/openbios-ppc-u3.patch
>>>>>>
>>>>>> About the OpenBIOS patch, could you move the PCI_INT_MAP defines to a
>>>>>> PPC-specific header and make pci_host_set_interrupt_map() contents
>>>>>> surrounded by #ifdef CONFIG_PPC (to make it empty function for other
>>>>>> arches)?
>>>>>
>>>>> Well, other archs should be able to use the same code. If OpenBIOS knows
>>>>> how interrupts work for a particular device, it really should tell the OS
>>>>> about it too IMHO.
>>>>
>>>> I'm not so sure. Here's an example of a Sparc64 interrupt-map:
>>>>
>>>> Node 0xf005f9d4
>>>> bus-range: 00000001.00000001
>>>> scsi-initiator-id: 00000007
>>>> compatible: 70636931.3038652c.35303030.00706369
>>>> 66mhz-capable:
>>>> fast-back-to-back:
>>>> devsel-speed: 00000001
>>>> class-code: 00060400
>>>> revision-id: 00000011
>>>> device-id: 00005000
>>>> vendor-id: 0000108e
>>>> interrupt-map:
>>>> 00010800.00000000.00000000.00000001.f005f1e0.00000021.00011000.00000000.00000000.00000001.f005f1e0.0000000f.00011800.00000000.00000000.00000001.f005f1e0.00000020
>>>> interrupt-map-mask: 00fff800.00000000.00000000.00000007
>>>
>>>
>>> This translates to:
>>>
>>> Interrupt PIN A on dev 00010800 -> INT 0x21
>>> Interrupt PIN A on dev 00011000 -> INT 0x0f
>>> Interrupt PIN A on dev 00011800 -> INT 0x20
>>>
>>> What does the corresponding code in OpenBIOS do to figure out which IRQ is
>>> routed where?
>>
>> Currently there isn't anything, so something may be better than
>> nothing. Would your code produce correct interrupt-map then also for
>> Sparc64?
>
> Depends on how your PCI bridge maps interrupts. What does qemu's pci
> interrupt map function for your pci bridge look like?
/* The APB host has an IRQ line for each IRQ line of each slot. */
static int pci_apb_map_irq(PCIDevice *pci_dev, int irq_num)
{
return ((pci_dev->devfn & 0x18) >> 1) + irq_num;
}
This may be bogus though.
>
>>
>>> The UniNorth case is really simple, because it doesn't take any mangling
>>> into account. Usually PCI bridges also assign pins differently depending on
>>> the port the card is plugged into, so an "all devices on PIN A"
>>> configuration still ends up being distributed over all 4 interrupts.
>>>
>>> I'm certainly open to more clever ideas. We could of course forget about
>>> all the interrupt mapping and simply put PIC targeted interrupt properties
>>> into each device's node. But I somehow like the map approach better,
>>> especially because the "normal" (defined in the interrupt map draft) way of
>>> doing PCI interrupts is to have an interrupt property of size=1 which
>>> defines the pin.
>>
>> I should probably read the draft before trying to comment further.
>
> http://playground.sun.com/1275/practice/imap/imap0_9d.pdf
Thanks.
