All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, naresh.kumar.kachhi@intel.com
Subject: Re: [RFC 1/6] drm/i915: cover ioctls with runtime_get/put
Date: Wed, 22 Jan 2014 15:23:28 +0200	[thread overview]
Message-ID: <1390397008.12277.15.camel@intelbox> (raw)
In-Reply-To: <20140122125122.GG9772@phenom.ffwll.local>


[-- Attachment #1.1: Type: text/plain, Size: 1844 bytes --]

On Wed, 2014-01-22 at 13:51 +0100, Daniel Vetter wrote:
> On Wed, Jan 22, 2014 at 05:34:17PM +0530, naresh.kumar.kachhi@intel.com wrote:
> > From: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
> > 
> > With runtime PM enabled, we need to make sure that all HW access
> > are valid (i.e.  Gfx is in D0). Invalid accesses might end up in
> > HW hangs. Ex. A hang is seen if display register is accessed on
> > BYT while display power island is power gated.
> > 
> > This patch is covering all the IOCTLs with get/put.
> > TODO: limit runtime_get/put to IOCTLs that accesses HW
> > 
> > Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
> 
> Nack on the concept. We need to have get/put calls for the individual
> functional blocks of the hw, which then in turn (if it's not the top-level
> power domain) need to grab references to the next up power domain.
> Splattering unconditional get/puts over all driver entry points is bad
> style and imo also too fragile.
> 
> Also, with Paulos final runtime pm/pc8 unification patches and Imre's
> display power well patches for byt we should have full coverage already.
> Have you looked at the work of these too?

I'm still in debt with the BYT specific power domain patches, I want to
post them (this week) after I sorted out spurious pipe stat IRQs we'd
receive atm with the power well off. Until then there is only the WIP
version at: https://github.com/ideak/linux/commits/powerwells

But in practice, as you point out the plan was to only call
modeset_update_power_wells() during modeset time and that will end up
doing the proper RPM get/put as necessary. Similarly on some other code
paths like connector detect and HW state read-out code, we'd ask only
for the needed power domains which would end up doing the RPM get/put.

--Imre


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-01-22 13:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22 12:04 [RFC 0/6] enabling runtime on BYT naresh.kumar.kachhi
2014-01-22 12:04 ` [RFC 1/6] drm/i915: cover ioctls with runtime_get/put naresh.kumar.kachhi
2014-01-22 12:51   ` Daniel Vetter
2014-01-22 13:23     ` Imre Deak [this message]
2014-01-24 15:05       ` Naresh Kumar Kachhi
2014-01-24 15:56         ` Paulo Zanoni
2014-02-24  5:17           ` Naresh Kumar Kachhi
2014-01-24 17:23         ` Imre Deak
2014-02-21 20:07           ` Jesse Barnes
2014-02-24  5:30             ` Naresh Kumar Kachhi
2014-01-22 13:35   ` Paulo Zanoni
2014-01-22 12:04 ` [RFC 2/6] drm/i915: cover ring access with rpm get/put naresh.kumar.kachhi
2014-01-22 13:39   ` Paulo Zanoni
2014-01-22 12:04 ` [RFC 3/6] drm/i915: introduce runtime get/put based on display activity naresh.kumar.kachhi
2014-01-22 13:40   ` Paulo Zanoni
2014-02-24  5:21     ` Naresh Kumar Kachhi
2014-01-22 12:04 ` [RFC 4/6] drm/i915/vlv: call runtime get/put based on disp activity naresh.kumar.kachhi
2014-01-22 12:04 ` [RFC 5/6] drm/i915: device specific runtime suspend/resume naresh.kumar.kachhi
2014-01-22 12:58   ` Daniel Vetter
2014-01-24 15:23     ` Naresh Kumar Kachhi
2014-01-22 12:04 ` [RFC 6/6] FOR_UPSTREAM [VPG]: drm/i915: call init_runtime_pm before gem_init naresh.kumar.kachhi
2014-01-22 13:44   ` Paulo Zanoni
2014-01-24 15:11     ` Naresh Kumar Kachhi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1390397008.12277.15.camel@intelbox \
    --to=imre.deak@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=naresh.kumar.kachhi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.