From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] drm/i915: revert intel_dp_probe_oui call
 during HPD interrupt handler
Date: Fri, 6 Jun 2014 22:17:54 +0200
Message-ID: <20140606201754.GW7416@phenom.ffwll.local>
References: <1401920981-3137-1-git-send-email-clinton.a.taylor@intel.com>
 <20140605092629.GV7416@phenom.ffwll.local>
 <871tv2e5ot.fsf@intel.com> <539204BD.3060308@intel.com>
 <871tv1yfss.fsf@intel.com>
 <CAPM=9twPzPfeaBtoZKq4Uxr7PtcKgqwub9oO=HJ-0dqyWLGcbA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
 [209.85.212.179])
 by gabe.freedesktop.org (Postfix) with ESMTP id 540876EAD1
 for <Intel-gfx@lists.freedesktop.org>; Fri,  6 Jun 2014 13:17:59 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id bs8so1626856wib.12
 for <Intel-gfx@lists.freedesktop.org>; Fri, 06 Jun 2014 13:17:58 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <CAPM=9twPzPfeaBtoZKq4Uxr7PtcKgqwub9oO=HJ-0dqyWLGcbA@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Dave Airlie <airlied@gmail.com>
Cc: "intel-gfx@lists.freedesktop.org" <Intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Sat, Jun 07, 2014 at 06:14:42AM +1000, Dave Airlie wrote:
> My edp panel bits are all cut-n-paste anyways. maybe we should hold the
> edp on for long periods around that whole probing.

We have a delayed put on the edp panel power. So keeping it just around
the bits where we need it doesn't have perf downsides and imo makes it
clearer why we need it - we've had some good amounts of fun in the past
where functions assumed that the panel is on but not all callers ensured
that. We've pushed the edp panel power handling down the callstacks due
to that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch