From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 6/6] DRAFT: drm/i915: do adapter power state notification on PC8+ enable/disable Date: Mon, 26 Aug 2013 10:43:50 +0300 Message-ID: <20130826074350.GD11428@intel.com> References: <4dc131ec233507a510afdbbe6369a7983dafe4a4.1377246881.git.jani.nikula@intel.com> <20130823105722.5f2e932a@bluebird.jf.intel.com> <20130823200652.GC11428@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 63C12E6FB6 for ; Mon, 26 Aug 2013 00:44:00 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Paulo Zanoni Cc: Jani Nikula , Intel Graphics Development , Kristen Carlson Accardi List-Id: intel-gfx@lists.freedesktop.org On Fri, Aug 23, 2013 at 05:14:00PM -0300, Paulo Zanoni wrote: > 2013/8/23 Ville Syrj=E4l=E4 : > > On Fri, Aug 23, 2013 at 04:41:57PM -0300, Paulo Zanoni wrote: > >> 2013/8/23 Kristen Carlson Accardi : > >> > On Fri, 23 Aug 2013 13:44:17 -0300 > >> > Paulo Zanoni wrote: > >> > > >> >> 2013/8/23 Jani Nikula : > >> >> > >> >> /* 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=E4l=E4 Intel OTC