From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Subject: Re: [PATCH 2/4] drm/i915: Make *_crtc_mode_set work on
 new_config
Date: Thu, 09 Oct 2014 15:18:03 +0300
Message-ID: <54367CFB.4000908@intel.com>
References: <1412782343-28836-1-git-send-email-conselvan2@gmail.com>	<1412782343-28836-3-git-send-email-conselvan2@gmail.com>
 <CAKMK7uFSY=3NoFttsQwgjL4ZYwq9q4sPxhXTrFzbEBd+jFZ2pw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by gabe.freedesktop.org (Postfix) with ESMTP id B5E3F6E20A
 for <intel-gfx@lists.freedesktop.org>; Thu,  9 Oct 2014 05:18:01 -0700 (PDT)
In-Reply-To: <CAKMK7uFSY=3NoFttsQwgjL4ZYwq9q4sPxhXTrFzbEBd+jFZ2pw@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: Daniel Vetter <daniel@ffwll.ch>, Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On 10/09/2014 12:11 PM, Daniel Vetter wrote:
> On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira wrote:
>> From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
>>
>> This shouldn't change the behavior of those functions, since they are
>> called after the new_config is made effective and that points to the
>> current config. In a follow up patch, the mode set sequence will be
>> changed so this is called before disabling crtcs, and in that case
>> those functions should work on the staged config.
>>
>> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
>> ---

[snip]

>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 3a06c3d..9d8fe8d 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -420,13 +420,32 @@ static bool intel_pipe_has_type(struct drm_crtc *crtc, int type)
>>    return false;
>>   }
>>
>> +/**
>> + * Returns whether any output on the specified pipe will have the specified
>> + * type after a staged modeset is complete, i.e., the same as
>> + * intel_pipe_has_type() but looking at encoder->new_crtc instead of
>> + * encoder->crtc.
>> + */
>> +static bool intel_pipe_will_have_type(struct drm_crtc *crtc, int type)
>
> s/drm_crtc/intel_crtc/. In general we use the most specific type
> for internal functions to avoid tons of upcasting. So you might want to
> throw a patch on top to convert the existing has_type for consistency.

What about the functions in drm_i915_display_funcs (find_dpll, 
crtc_mode_set)? Are these not considered internal functions or is this 
leftover from before this rule was in place?

If I write that consistency patch it might be easier to just convert 
everything.

Ander
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.