Date: Thu, 15 Dec 2005 12:45:01 -0500 From: John Baldwin <jhb@freebsd.org> To: Anish Mistry <mistry.7@osu.edu> Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) patch Message-ID: <200512151245.01913.jhb@freebsd.org> In-Reply-To: <200512150033.13676.mistry.7@osu.edu> References: <200512141720.01572.jhb@freebsd.org> <200512150033.13676.mistry.7@osu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 15 December 2005 12:32 am, Anish Mistry wrote: > On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > > I have a patch that is an attempt to untangle a few things in > > relation to Host-PCI bridges and VGA PCI devices. Basically, the > > change is to create a more "real" hostb driver as well as a new > > vgapci driver and to change agp, drm, and acpi_video to attach to > > these drivers. This means among other things: > > > > - In theory you can now kldload agp after boot since it still has a > > place to attach to. > > - i830/915 drm is no longer a child of agp, instead both become > > children of vgapci0. > > - You can now use acpi_video with drm as both attach as children of > > vgapci0. - This provides a way for us to possibly solve the DPMS > > problem for suspend/resume (including a cleaner way to do the hack > > dpms patch I posted to acpi@ a long while ago that several people > > still use). > > > > Some other details include: > > > > - agp devices no longer map the _entire_ aperture into contiguous > > KVA meaning that it might be possible now to use a 256 MB aperture > > without panicing - I've added a new pci_if.m method for locating a > > specific capability for a PCI device. > > > > I have tested this on my laptop and verified that dri still works, > > but it needs some wider testing, especially the i830/i915 case is > > slightly more complicated. Also, this is not going to work with > > the nvidia-driver currently, but that's something that can be fixed > > in the future. If the agp non-mapping does fix the 256 MB aperture > > issues then I will probably MFC that part to RELENG_6. > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > Thank you! It seems to work as advertised. I'm running mach64 DRM > with the DPMS patch acpi_video and they both work. :) > One small problem though. When I unload the acpi_video module and > reload it I get the following: > littleguy# kldload acpi_video > acpi_video0: <ACPI video extension> on vgapci0 > acpi_video1: <ACPI video extension> on vgapci0 > littleguy# kldunload acpi_video > acpi_video0: detached > acpi_video1: detached > littleguy# kldunload acpi_video > kldunload: can't find file acpi_video: No such file or directory > littleguy# kldload acpi_video > acpi_video0: <ACPI video extension> on vgapci0 > acpi_video1: <ACPI video extension> on vgapci0 > acpi_video2: <ACPI video extension> on vgapci0 > littleguy# > It also created multiple sysctls with subsequent loads: > hw.acpi.video.crt0.active: 1 > hw.acpi.video.lcd0.active: 1 > hw.acpi.video.tv0.active: 0 > hw.acpi.video.crt1.active: 1 > hw.acpi.video.lcd1.active: 1 > hw.acpi.video.tv1.active: 0 > hw.acpi.video.crt2.active: 1 > hw.acpi.video.lcd2.active: 1 > hw.acpi.video.tv2.active: 0 Ok, I can work around that for now. There really should be a driver_unidentify routine that gets called during bus_generic_detach() to clean these up. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512151245.01913.jhb>