I have an i875 chipset with these two devices:
8086:2578 - 00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory
Controller Hub (rev 02)
8086:2579 - 00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP
Controller (rev 02)
In the legacy io space thread we are talking about making a device
driver for host bridges. The Intel AGP drivers (in my case
agpgart-intel-mch) are attaching to the PCI IDs of the host bus device
instead of the AGP bridge. This blocks us from making a host bridge
driver.
PCI_DEVICE_ID_INTEL_82875_HB 0x2578
Shouldn't they be attaching to device 0x2579? It looks like all of the
drivers have this problem and are attaching to the host bus PCI IDs
instead of the AGP bridge ID.
[root@jonsmirl pci]# cat devices
0000 80862578 0 ec000008 00000000
00000000 00000000 00000000 00000000
00000000 04000000 00000000 00000000 00000000
00000000 00000000 00000000 agpgart-intel-mch
0008 80862579 0 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
Am I correct in thinking that in all cases there has to be two PCI
IDs, one for the host bridge and one for the APG bridge?
--
Jon Smirl
[email protected]
On Sat, Feb 05, 2005 at 08:45:19PM -0500, Jon Smirl wrote:
> I have an i875 chipset with these two devices:
>
> 8086:2578 - 00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory
> Controller Hub (rev 02)
> 8086:2579 - 00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP
> Controller (rev 02)
>
> In the legacy io space thread we are talking about making a device
> driver for host bridges. The Intel AGP drivers (in my case
> agpgart-intel-mch) are attaching to the PCI IDs of the host bus device
> instead of the AGP bridge. This blocks us from making a host bridge
> driver.
> PCI_DEVICE_ID_INTEL_82875_HB 0x2578
>
> Shouldn't they be attaching to device 0x2579? It looks like all of the
> drivers have this problem and are attaching to the host bus PCI IDs
> instead of the AGP bridge ID.
Take a peek at 'lspci -vv' output. You'll notice that the AGP
capabilities are attached to the host bridge.
Dave
On Sat, 5 Feb 2005 23:05:26 -0500, Dave Jones <[email protected]> wrote:
> Take a peek at 'lspci -vv' output. You'll notice that the AGP
> capabilities are attached to the host bridge.
I see that now, why is it on the host bridge instead of the AGP
bridge? So that means if we add drivers for the host bridges we have
to add the code to the AGP drivers. It also implies that we have to
load them.
--
Jon Smirl
[email protected]
On Sun, Feb 06, 2005 at 12:58:46AM -0500, Jon Smirl wrote:
> On Sat, 5 Feb 2005 23:05:26 -0500, Dave Jones <[email protected]> wrote:
> > Take a peek at 'lspci -vv' output. You'll notice that the AGP
> > capabilities are attached to the host bridge.
>
> I see that now, why is it on the host bridge instead of the AGP
> bridge?
Not sure. Maybe its partly due to the host bridge having all the
smarts to deal with the memory controller.
> So that means if we add drivers for the host bridges we have
> to add the code to the AGP drivers. It also implies that we have to
> load them.
Why exactly are you trying to write host bridge drivers anyway ?
Confused.
If there's a sensible reason for such drivers, we could at some
stage have the bridge drivers check for AGP capabilities, and
if found, start up the initialisation of the relevant AGP chipset
driver. (and then rip out the whole PCI detection stuff in agpgart).
This is quite a lot of work though, so unless there's a really
compelling reason, I don't think its worth doing.
Another way forward (somewhat hacky in one sense, but a lot cleaner in another)
would be to change the PCI code so that it'll load and init
multiple drivers that claim to support the same PCI ID.
This may cause issues for some other drivers however where
we have an old and a new driver with ID overlap.
So,.. what are you up to?
Dave
On Sun, 6 Feb 2005 01:08:40 -0500, Dave Jones <[email protected]> wrote:
> Why exactly are you trying to write host bridge drivers anyway ?
> Confused.
We're trying to add sysfs attributes for identifying and controlling
legacy address spaces. Desktop x86 has just a single legacy IO/mem
address space but more advanced systems like the IA64 support multiple
ones. See Documentation/filesystems/sysfs-pci.txt. All architectures
need to provide a consistent API to make it easier to write the user
space app (like video reset). If IA64 is the example then x86 needs to
add legacy_io/mem attributes to the host bus bridge which just passes
the accesses on without change.
Another part of this is VGA control. When there are multiple VGA
devices the bridges have to be set to route VGA appropriately. This is
a different feature than multiple legacy address spaces on the IA64.
> Another way forward (somewhat hacky in one sense, but a lot cleaner in another)
> would be to change the PCI code so that it'll load and init
> multiple drivers that claim to support the same PCI ID.
> This may cause issues for some other drivers however where
> we have an old and a new driver with ID overlap.
This problem already exits in DRM/fbdev. DRM loads like a normal
driver and binds to the PCI IDs. But if it loads and finds fbdev
already bound to the PCI IDs it goes into stealth mode and runs
without binding to the ID.
I would prefer that we stick with the one driver per ID rule and
instead sort out DRM/fbdev to coordinate more. The legacy_io/mem
support can probably be added some place in common AGP code since the
attributes need to be created on all x86 boxes.
> What are you up to?
Putting together a foundation for X on GL. That involves reworking
video support in Linux so that X can remove all the horrible code that
plays with bridge chips and PCI config space from a user space app.
Right now the foundation is not there to allow X to remove the code.
Several things are needed:
1) Secondary card reset at boot
2) Mode setting on secondary heads - fbdev does not have this
3) A way to set modes without being root
4) Memory management coordination between fbdev/DRM when multiple scan
buffers are active
5) Mouse cursor support in fbdev
6) Fix video reset when resuming from suspend
Something that isn't required but would be nice it to fix things so
that an OOPs will be visible even if X is running.
Once DRM/fbdev is fixed mesa-solo will run on it with full features
(it already runs on fbdev/DRM with limited features). This will bring
up a standalone OpenGL stack.
X on GL is already written and is part of the xserver project. This
will run on the standalone OpenGL stack. Combine this with Cairo/Glitz
and we have a graphics system that can compete with Windows Longhorn.
--
Jon Smirl
[email protected]
On Feb 06, 2005, at 01:49, Jon Smirl wrote:
> X on GL is already written and is part of the xserver project. This
> will run on the standalone OpenGL stack. Combine this with Cairo/Glitz
> and we have a graphics system that can compete with Windows Longhorn.
Why compete with vaporware (mostly)? If you really want to see a
complete
modern graphics system, check out OS X. See the below screenshots for
one example.
http://tjhsst.edu/~kmoffett/2k4-1.png
http://tjhsst.edu/~kmoffett/2k4-2.png
The rendered window from 2k4 has been distorted by the windowing system
post-processing using a mesh transform. It runs just as quickly this
way as it does full screen normally, at least as far as I can tell
while playing. :-D A truely well-performing graphics system should be
able to handle multiple applications processing to generate a single
output stream without effort. I also ran some informal and simple
end-user-style tests a while back where I rapidly switched between and
moved around the following windows (each distorted in the same way):
1) A UT2k4 window playing a demo
2) A couple translucent terminal windows continuously scrolling
text
3) A DVD player window playing The Matrix
4) A couple Quicktime player windows with movies running
The best part was: ~60 FPS on everything, despite the distortions,
translucency, rapid movement, DVD playing, etc. I hope that when the
new linux graphics and Soft-RT stuff is done it will be able to achieve
similar performance. If my coding skills were a little more up to
snuff, I would try to help out, but as it is, I fear I'd just muddy
the waters :-\.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
On Sun, 6 Feb 2005, Dave Jones wrote:
> Another way forward (somewhat hacky in one sense, but a lot cleaner in another)
> would be to change the PCI code so that it'll load and init
> multiple drivers that claim to support the same PCI ID.
That might actually be useful to support some weird hardware. E.g. I
have a single-function PCI device which reports as a graphics adapter
(either VGA or other, depending on the configuration), but besides the
actual graphics adapter the chip includes a frame grabber, an USB host
controller, an Ethernet interface, an IEEE 1284 parallel port, an UART, an
I2C controller and a PS/2 keybard/mouse controller. ;-) All of these
mapped with a single PCI BAR; the chip can also be configured for legacy
mapping of some devices, like the PS/2 stuff.
Maciej
Dave Jones wrote:
> Another way forward (somewhat hacky in one sense, but a lot cleaner in another)
> would be to change the PCI code so that it'll load and init
> multiple drivers that claim to support the same PCI ID.
> This may cause issues for some other drivers however where
> we have an old and a new driver with ID overlap.
This sounds like it would allow the use of the parallel ATA interfaces
on SATA controllers, which would make a lot of people happy.
--
========================================================================
Ian Pilcher [email protected]
========================================================================
