[Intel-gfx] [PATCH 3/5] drm/i915: Implement GPU reset
Ben Gamari
bgamari.foss at gmail.com
Wed Jul 15 05:07:53 CEST 2009
On Tue, Jul 14, 2009 at 03:52:13PM -0700, Jesse Barnes wrote:
> On Wed, 8 Jul 2009 18:30:13 -0400
> Ben Gamari <bgamari.foss at gmail.com> wrote:
> > + if (flags & GDRST_FULL)
> > + i915_save_display(dev);
> > +
I just realized that save_display() will never get called here.
GDRST_FULL == 0x0.
> > + /*
> > + * Set the reset bit, wait for reset, then clear it.
> > Hardware
> > + * will clear the status bit (bit 1) when it's actually ready
> > + * for action again.
> > + */
> > + pci_read_config_byte(dev->pdev, GDRST, &gdrst);
> > + pci_write_config_byte(dev->pdev, GDRST, gdrst | flags);
> > + udelay(50);
> > + pci_write_config_byte(dev->pdev, GDRST, gdrst & 0xfe);
> > +
> > + /* ...we don't want to loop forever though, 500ms should be
> > plenty */
> > + do {
> > + udelay(100);
> > + pci_read_config_byte(dev->pdev, GDRST, &gdrst);
> > + } while ((gdrst & 2) && time_after(timeout, jiffies));
>
> Given the docs I have, it's unclear whether the 'flags' part of this is
> correct (the published docs imply yes, the partial doc I have
> describing the low 2 bits implies no).
>
> The normal reset sequence for 945/Q33/G33 (independent of
> render/media/display domains) is:
> 1) set bit 0 to 1
> 2) confirm hardware is in reset by checking bit 1 status
> 3) clear bit 0
> 4) read back bit 1 to make sure it cleared
>
> On 965 and some G4x:
> 1) set bit 0 to 1
> 2) spin on bit 0 for "awhile", waiting for it to clear
>
> On more recent chips (some G4x and above):
> 1) use another reg in MMIO space, indicating which domain to reset
>
> So the conclusion here is that one shouldn't trust documentation or
> even code based on that documentation.
>
> Many registers will be clobbered by the reset of the chip, so it's
> probably best to save/restore most everything across the reset, at
> least until we have the new style stuff for G4x+ implemented and
> confirm that we don't need to restore display regs for example.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list