Proper way to enable port access tracing with current xserver

[Alex Villací­s Lasso]

Alex Deucher escribió:
> On Fri, Jan 16, 2009 at 3:21 PM, Alex Villací­s Lasso
> <a_villacis at palosanto.com> wrote:
>   
>> Alex Deucher escribió:
>>     
>>>>  From what I glean from the traces, it seems that using VESA to start up
>>>> the primary Savage chipset works correctly. However, when trying to
>>>> initialize the Oak chipset as secondary (just that one, without
>>>> reference to the primary Savage chipset), it ends up in a loop of
>>>> in(3da) = ff and hangs. Interestingly, I saw no hint that the Savage
>>>> chipset was ever moved out of the legacy  VGA mapping in order to
>>>> initialize the Oak chipset via POST. Which ties back to my previous
>>>> question: what measures (if any) are supposed to be taken by the xserver
>>>> in order to hand over the legacy VGA ports to a secondary chipset that
>>>> needs access to them for POST, when run with a different chipset as
>>>> primary? As in, Savage is mapped to legacy VGA, I want to POST the Oak
>>>> chipset, which needs a mapping to the VGA ports too, so what should the
>>>> xserver do?
>>>>
>>>>         
>>> The bridge chipset needs to route vga to the proper card.  Pre-1.5
>>> xservers used to handle this.  libpciaccess does not yet AFAIK.
>>>
>>> Alex
>>>
>>>
>>>       
>> Then, this is technically a regression.
>>
>> So, lets say I want to add this support back. Is this squarely a
>> libpciaccess change, or do I have to place this on the xserver (since
>> this is specifically a VGA requirement)? Is anyone currently working on
>> this, by any chance (just to avoid duplicating work). Any suggestions on
>> the proper API to expose from libpciaccess? Are there any official docs
>> on bridge chipsets, besides the actual source code of old xservers?
>>     
>
> Ideally it would be done in the kernel to be used with libpciaccess.
> Tiago and Paulo have been working on it:
> http://lists.freedesktop.org/archives/xorg/2007-October/029507.html
> I'm not sure what the current status is.  As for documents, your best
> bet is probably hw reference guides from the vendors who make the PCI
> chipsets (AMD/VIA/Intel/etc.).  Most are available.
>
> Alex
>
>   
I have collected a few patches. However, the referenced repositories are 
now 404. Would it be acceptable to skip a kernel implementation for now 
and instead just modify xserver/libpciaccess to provide a level of 
functionality similar to pre-1.5 ?

-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'