On Fri, Aug 23, 2013 at 05:14:00PM -0300, Paulo Zanoni wrote: > 2013/8/23 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>: > > On Fri, Aug 23, 2013 at 04:41:57PM -0300, Paulo Zanoni wrote: > >> 2013/8/23 Kristen Carlson Accardi <kristen.c.accardi@xxxxxxxxx>: > >> > On Fri, 23 Aug 2013 13:44:17 -0300 > >> > Paulo Zanoni <przanoni@xxxxxxxxx> wrote: > >> > > >> >> 2013/8/23 Jani Nikula <jani.nikula@xxxxxxxxx>: > >> >> > >> >> /* 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
