public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v5 05/10] drm/i915: Stop frobbing with DDI encoder->type
Date: Fri, 27 Oct 2017 16:05:33 +0200	[thread overview]
Message-ID: <6c21f026-51c5-56d3-44ff-d173d55dbb2e@linux.intel.com> (raw)
In-Reply-To: <20171027140347.GJ10981@intel.com>

Op 27-10-17 om 16:03 schreef Ville Syrjälä:
> On Fri, Oct 27, 2017 at 03:53:34PM +0200, Maarten Lankhorst wrote:
>> Op 27-10-17 om 14:44 schreef Ville Syrjälä:
>>> On Fri, Oct 27, 2017 at 02:05:38PM +0200, Maarten Lankhorst wrote:
>>>> Op 19-10-17 om 15:37 schreef Ville Syrjala:
>>>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>
>>>>> Currently the DDI encoder->type will change at runtime depending on
>>>>> what kind of hotplugs we've processed. That's quite bad since we can't
>>>>> really trust that that current value of encoder->type actually matches
>>>>> the type of signal we're trying to drive through it.
>>>>>
>>>>> Let's eliminate that problem by declaring that non-eDP DDI port will
>>>>> always have the encoder type as INTEL_OUTPUT_DDI. This means the code
>>>>> can no longer try to distinguish DP vs. HDMI based on encoder->type.
>>>>> We'll leave eDP as INTEL_OUTPUT_EDP, since it'll never change and
>>>>> there's a bunch of code that relies on that value to identify eDP
>>>>> encoders.
>>>>>
>>>>> We'll introduce a new encoder .compute_output_type() hook. This allows
>>>>> us to compute the full output_types before any encoder .compute_config()
>>>>> hooks get called, thus those hooks can rely on output_types being
>>>>> correct, which is useful for cloning on oldr platforms. For now we'll
>>>>> just look at the connector type and pick the correct mode based on that.
>>>>> In the future the new hook could be used to implement dynamic switching
>>>>> between LS and PCON modes for LSPCON.
>>>>>
>>>>> TODO: maybe make .get_config() populate output_types rather than doing
>>>>> the default encoder->type thing in caller and then undoing it for
>>>>> DDI in .get_config().
>>>>>
>>>>> v2: Fix BXT/GLK PPS explosion with DSI/MST encoders
>>>>> v3: Avoid the PPS warn on pure HDMI/DVI DDI encoders by checking dp.output_reg
>>>>> v4: Rebase
>>>>> v5: Populate output_types in .get_config() rather than in the caller
>>>> Could we get rid of compute_output_type in this patch? Perhaps do it as preliminary
>>>> patch towards removing the use?
>>> We don't want to remove it.
>> Ok, but could that still be a separate preparation patch? That would make it easier to review. :)
> Not sure which part you mean here. Moving the 'output_types |= whatever'
> into .get_config()? Hmm. Yeah that should be easy to split out. I guess
> it won't even make the DDI case any more broken that it already is since
> even currently encoder->type might change between the modeset compute
> phase and .get_config(). And it's going to be followed closely by the
> actual fix anyway.
>
Yes, that part. It should work even without the UNKNOWN->DDI change afaics.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-10-27 14:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 13:37 [PATCH 00/10] drm/i915: Last part of DDI encoder->type cleanup Ville Syrjala
2017-10-19 13:37 ` [PATCH 01/10] drm/i915: Don't use encoder->type in intel_ddi_set_pipe_settings() Ville Syrjala
2017-10-19 13:37 ` [PATCH 02/10] drm/i915: Pass crtc state to intel_prepare_dp_ddi_buffers() Ville Syrjala
2017-10-19 13:37 ` [PATCH 03/10] drm/i915: Start using output_types for DPLL selection Ville Syrjala
2017-10-19 13:37 ` [PATCH 04/10] drm/i915: Stop using encoder->type in intel_ddi_enable_transcoder_func() Ville Syrjala
2017-10-19 13:37 ` [PATCH v5 05/10] drm/i915: Stop frobbing with DDI encoder->type Ville Syrjala
2017-10-27 12:05   ` Maarten Lankhorst
2017-10-27 12:44     ` Ville Syrjälä
2017-10-27 13:53       ` Maarten Lankhorst
2017-10-27 14:03         ` Ville Syrjälä
2017-10-27 14:05           ` Maarten Lankhorst [this message]
2017-10-27 19:32     ` Ville Syrjälä
2017-10-19 13:37 ` [PATCH 06/10] drm/i915: Nuke intel_ddi_get_encoder_port() Ville Syrjala
2017-10-19 13:37 ` [PATCH 07/10] drm/i915: Eliminate pll->state usage from bxt_calc_pll_link() Ville Syrjala
2017-10-19 13:37 ` [PATCH 08/10] drm/i915: Pass a crtc state to ddi post_disable from MST code Ville Syrjala
2017-10-27 11:39   ` Maarten Lankhorst
2017-10-27 11:49     ` Ville Syrjälä
2017-10-27 14:31       ` Maarten Lankhorst
2017-10-19 13:37 ` [PATCH 09/10] drm/i915: Use intel_ddi_get_config() for MST Ville Syrjala
2017-10-27 11:43   ` Maarten Lankhorst
2017-10-27 11:55     ` Ville Syrjälä
2017-10-19 13:37 ` [PATCH 10/10] drm/i915: Use intel_crtc_has_dp_encoder() for LPE audio Ville Syrjala
2017-10-27 11:43   ` Maarten Lankhorst
2017-10-27 11:53     ` Ville Syrjälä
2017-10-19 14:00 ` ✓ Fi.CI.BAT: success for drm/i915: Last part of DDI encoder->type cleanup Patchwork
2017-10-19 14:59 ` ✓ Fi.CI.IGT: " Patchwork
2017-10-27 16:39 ` ✗ Fi.CI.BAT: failure " Patchwork

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=6c21f026-51c5-56d3-44ff-d173d55dbb2e@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox