linux-kernel - Re: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to drm_crtc_helper

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 15 Feb 2017 17:54:12 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Chen Feng <puck.chen@...ilicon.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Xinliang Liu <z.liuxinliang@...ilicon.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Rongrong Zou <zourongrong@...il.com>,
        Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to
 drm_crtc_helper_funcs

Hi Daniel,

On Tue, Feb 14, 2017 at 10:42:53PM +0100, Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 01:03:27PM -0800, John Stultz wrote:
> > On Tue, Feb 14, 2017 at 12:22 PM, Daniel Vetter <daniel@...ll.ch> wrote:
> > > On Tue, Feb 14, 2017 at 11:45:54AM -0800, John Stultz wrote:
> > >>
> > >> Not following here. What do you mean by "put it into drivers"?  Where?
> > >
> > > In your driver callback for ->mode_valid, call into a shared function to
> > > validate CRTC limits. Which you also call from the crtc's ->mode_fixup
> > > function.
> > 
> > So bascially have the adv7511 driver's mode_valid() have a special
> > callback to the kirin (and freedreno, and whatever other) drm driver
> > to check the modes? Or I guess the drm driver that uses that bridge
> > should register something w/ the adv7511 code?
> > 
> > Part of my confusion here is that the main issue is that its not just
> > one driver I'm dealing with, and they're all really just tied together
> > via device tree, so I'm not sure how to special case it in just one of
> > the drivers.
> 
> This sounds you want to fix this for bridges, but your patch only adds a
> crtc callback?

I've had kind of the same issue on sun4i actually. The issue is that a
bridge (through EDID) might report that some modes are supported, and
the bridge has a chance to say whether or not it can support such
resolutions and filter out the ones it cannot.

However, components higher in the pipeline cannot do so. In my case,
we had an RGB to HDMI that was definitely able to support up to
1080p60. However, our RGB encoder can only generate a pixel clock for
up to ~720p60, and this is not really the bridge's fault, so it
shouldn't be in the bridge driver. The same bridge attached to a
different RGB encoder (even a different SoC from the same family in
our case) will run just fine at 1080p.

We currently end up letting the user choose a resolution we knew very
well had not a chance to work. I came up with a similar solution than
John's, but for the encoders (since our clocks are per-encoder), but
unfortunately had no time to push it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)