Kumar Gala wrote:
>>>> I'm still looking into how the PCI address register for the video
>>>> card did not get written, even though the system obviously thinks
>>>> it did (hence "virtual")
>>>>
>>>
>>> It most definitely has something to do with 0xC0000000 being
>>> assigned to the video card. I changed my DTS to move everything
>>> up (started the whole space at 0xC4000000) and the video card
>>> came to life! Of course, I'm not interested in this hack,
>>> so the simplest thing would be to figure out why 2.6.26 allocated
>>> that outgoing window and 2.6.28 doesn't
>>
>> So I think the difference is due to the change in PCI code between
>> 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in
>> .26 you have:
>>
>>>> c0000000-c7ffffff : 0000:00:00.0
>>
>> and in .28 its gone. This accounts for the allocation differences.
>> What I don't get is why the behavior would vary based on address.
>>
>> Can you dump out the PCI inbound/outbound registers. I have a theory
>> as to what's going on and want to confirm it.
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge'
was common among architectures and ended up calling 'setup_pci_atmu'
which created those mappings. In 2.6.28, the 83xx PCI setup code
has been refactored. It uses 'mpc83xx_add_bridge' instead of
'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
I'm sure this is the problem.
> Also, what's your .dts look like for the PCI node.
For the record:
bus-range = <0 0>;
ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
