Re: hostb(4) and vgapci(4) patch

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_at_ 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_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org