linux-kernel - Re: [PATCH 1/2] drm: Introduce crtc->mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20170504130856.GU12629@intel.com>
Date:   Thu, 4 May 2017 16:08:56 +0300
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Jose Abreu <Jose.Abreu@...opsys.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
        Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        Dave Airlie <airlied@...ux.ie>
Subject: Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback

On Thu, May 04, 2017 at 02:49:31PM +0200, Daniel Vetter wrote:
> On Wed, May 3, 2017 at 5:21 PM, Ville Syrjälä
> <ville.syrjala@...ux.intel.com> wrote:
> > We don't actually want the codepaths to match exactly. In i915
> > we allow the user to exceed some of the display/dongle limits
> > because those things often tell us that something shouldn't work
> > when in fact it does. And some users are quick to complain if
> > something stops working for them.
> 
> The goal here is to share the source-side checking
> (crtc/encoder/bridges), and that should match perfectly between probe
> and commit. Sink-side constraints are different, and for those we
> should indeed not check everything. Maybe a good reason to only call
> connector->mode_valid in the probe paths?

I thought you wanted to call it from both. But I guess if we
have a .mode_valid() hook on the encoder as well to handle
the source port limits then it could work out.

Ddi encoders might cause a problem though since we have to know
whether we're going to do DP or HDMI before we check the limits,
so it would need to be done after we've figured out output_types
or else we'll need to duplicate some logic to determine which
case we're dealing with.

-- 
Ville Syrjälä
Intel OTC