Bug 6829

Summary: [mach64] driver needs to enable PCI bus after S3 suspend
Product: xorg Reporter: Jay Cotton <jay.cotton>
Component: Driver/mach64Assignee: George - <fufutos610>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: alexdeucher, fufutos610
Version: gitKeywords: NEEDINFO, patch
Hardware: x86 (IA32)   
OS: Solaris   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
guard with block I/O, get pVideo from pATI none

Description Jay Cotton 2006-05-04 05:47:26 UTC
When returning from S3 suspend useing the RageXL chip, it is neccessary to
reset the PCI bus to prevent blocking I/O operations to the chip.

This is done in ATIEnterGraphics in the aticonsole.c file.

Here is the code I added to the function ATIEnterGraphics

{
unsigned int PciReg;
pciConfigPtr           pPCI;
pciVideoPtr            pVideo, *xf86PciVideoInfo = xf86GetPciVideoInfo();

        pVideo = xf86PciVideoInfo[pScreenInfo->scrnIndex];
        pPCI = pVideo->thisCard;
/*
* Possibly fix block I/O indicator in PCI configuration space.
*/
        PciReg = pciReadLong(pPCI->tag, PCI_REG_USERCONFIG);
        if (!(PciReg & 0x00000004U))
                pciWriteLong(pPCI->tag, PCI_REG_USERCONFIG, PciReg |
                                0x00000004U);

    /* Map apertures */
Comment 1 Luc Verhaegen 2006-05-04 19:54:24 UTC
Hugely overdue mach64 rework is happening at
http://gitweb.freedesktop.org/?p=users-libv-xf86-video-mach64;a=summary
This will probably move to drivers/ after 7.1 release, and should be solid
before 7.2.

Will take the PCI_REG_USERCONFIG fix into account in the mapping code. But i'm
currently on hold with mach64 waiting for mapping code testing on big endian.
Comment 2 George - 2007-02-17 11:27:49 UTC
(In reply to comment #0)
> When returning from S3 suspend useing the RageXL chip, it is neccessary to
> reset the PCI bus to prevent blocking I/O operations to the chip.
> 
> This is done in ATIEnterGraphics in the aticonsole.c file.
> 
> Here is the code I added to the function ATIEnterGraphics

I guess the code should be guarded with a test for block I/O cards.

There is code in atiprobe.c that does the opposite with that PCI_REG_USERCONFIG bit for sparse I/O cards, so I speculate that the bit indicates support for block I/O, somehow ?

Any chance that this bit can be set in atiprobe.c and survive S3, so that it is more in line with the surrounding ugliness ?
Comment 3 Daniel Stone 2007-02-27 01:31:56 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 4 Jay Cotton 2007-02-28 16:43:38 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > When returning from S3 suspend useing the RageXL chip, it is neccessary to
> > reset the PCI bus to prevent blocking I/O operations to the chip.
> > 
> > This is done in ATIEnterGraphics in the aticonsole.c file.
> > 
> > Here is the code I added to the function ATIEnterGraphics
> 
> I guess the code should be guarded with a test for block I/O cards.
> 
> There is code in atiprobe.c that does the opposite with that PCI_REG_USERCONFIG
> bit for sparse I/O cards, so I speculate that the bit indicates support for
> block I/O, somehow ?
> 
> Any chance that this bit can be set in atiprobe.c and survive S3, so that it is
> more in line with the surrounding ugliness ?
> 
I tried that and it does not work.  Problem is that on resume we don't 
go through the probe code.  

I can't speculate on the other addressing modes.  This bit is needed, but
I don't know all the conditions of the need.  It is not documented in the
RageXL manual.
Comment 5 George - 2007-03-01 09:11:06 UTC
Created attachment 8923 [details] [review]
guard with  block I/O, get pVideo from pATI
Comment 6 Matt Turner 2010-12-03 12:27:28 UTC
Is this still a problem? Providing a patch is the best way to get it fixed.
Comment 7 Luc Verhaegen 2012-01-25 08:56:38 UTC
Since my pci rework of -ati was "redeveloped", unbelievably little code with my name on it made it into this driver. So i am one of the last people who should be seen as the maintainer of this driver.
Comment 8 Adam Jackson 2018-06-12 19:10:03 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.