[Intel-gfx] [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable

[Ville Syrjälä]

On Fri, Aug 23, 2013 at 05:14:00PM -0300, Paulo Zanoni wrote:
> 2013/8/23 Ville Syrjälä <ville.syrjala at linux.intel.com>:
> > On Fri, Aug 23, 2013 at 04:41:57PM -0300, Paulo Zanoni wrote:
> >> 2013/8/23 Kristen Carlson Accardi <kristen.c.accardi at intel.com>:
> >> > On Fri, 23 Aug 2013 13:44:17 -0300
> >> > Paulo Zanoni <przanoni at gmail.com> wrote:
> >> >
> >> >> 2013/8/23 Jani Nikula <jani.nikula at intel.com>:
> >> >>
> >> >> /* Please insert explanation on why we need this and what changes if
> >> >> we do this. */
> >> >>
> >> >> I applied your patches and booted them. I got into PC8, did the PC8
> >> >> test suite and nothing changed. I really don't know what to expect
> >> >> from this series and/or how to check what's improving. Also, see
> >> >> below:
> >> >>
> >> >
> >> > So this is one of these things that will have no visible impact on
> >> > i915, but will impact other parts of the system.  So I think the only
> >> > way to test it is by throwing it on the SIP board and checking the
> >> > power level of the components this impacts (Audio, thermal, KBC/EC,
> >> > LPT).  And without the code which does the actual PCI D3 request from
> >> > i915, nothing will happen.
> >>
> >> I was told we could try to verify this by reading PCI config register
> >> 0xd4, but for me it's always 0x0, which means we're probably not
> >> really getting into D3.
> >
> > You have to write 0x3 into the PCI PM register to make it enter D3.
> > Exactly like you do when you suspend the whole machine.
> >
> > Not sure 0xd4 is the correct offset in this case, but you can look
> > it up from lspci output (remember +4), or in kernel code just use
> > pci_dev.pm_cap+4. Hmm, it's 0xd4 in my SNB at least. Maybe it's always
> > the same for the GPU.
> 
> Check the description of 0xd4 on BSpec.
> 
> I actually wrote the "get into D3" value to it (using setpci), and
> then when I got out of PC8 I saw tons and tons of error messages on
> dmesg due to the fact that we were failing to write registers. Which
> means it probably works, but we may have more work to do.

My quick and dirty idea for runtime PM would be something like this:
- for ioctls just slap rpm_get_sync/put() around drm_ioctl,
  not optimal but it's very easy for getting started
- all sysfs/debugfs stuff would need to be handled individually
- to deal w/ gtt mmaps just call put_fence or something during suspend,
  grab one ref in fault and probably release it from a delayed work,
  or mabe record a timestamp at last fault time and check it in the idle
  callback
- grab one ref per request (or per active ring maybe?)
- grab one ref per active pipe
- maybe some odd delayed work would need another reference

With that, I think everything of importance would hold a reference,
so the runtime pm idle callback shouldn't really need to do much.

-- 
Ville Syrjälä
Intel OTC