linux-kernel - Re: [PATCH v3 0/6] Introduce new mode validation callbacks

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]

Message-id: <1b3f1b8a-e3b5-f3e9-4697-bd40bd0cfede@samsung.com>
Date:   Fri, 12 May 2017 15:37:03 +0200
From:   Andrzej Hajda <a.hajda@...sung.com>
To:     Jose Abreu <Jose.Abreu@...opsys.com>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
        Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Dave Airlie <airlied@...ux.ie>,
        Archit Taneja <architt@...eaurora.org>
Subject: Re: [PATCH v3 0/6] Introduce new mode validation callbacks

On 12.05.2017 09:32, Daniel Vetter wrote:
> On Thu, May 11, 2017 at 10:05:56AM +0100, Jose Abreu wrote:
>> This series is a follow up from the discussion at [1]. We start by
>> introducing crtc->mode_valid(), encoder->mode_valid() and
>> bridge->mode_valid() callbacks which will be used in followup
>> patches and also by cleaning the documentation a little bit.
>>
>> We proceed by introducing new helpers to call this new callbacks
>> at 2/6.
>>
>> At 3/6 a helper function is introduced that calls all mode_valid()
>> from a set of bridges.
>>
>> Next, at 4/6 we modify the connector probe helper so that only modes
>> which are supported by a given bridge+encoder+crtc combination are
>> probbed.
>>
>> At 5/6 we call all the mode_valid() callbacks for a given pipeline,
>> except the connector->mode_valid one, so that the mode is validated.
>> This is done before calling mode_fixup().
>>
>> Finally, at 6/6 we use the new crtc->mode_valid() callback in arcpgu
>> and remove the atomic_check() callback.
>>
>> [1] https://patchwork.kernel.org/patch/9702233/
>>
>> Jose Abreu (6):
>>   drm: Add crtc/encoder/bridge->mode_valid() callbacks
>>   drm: Add drm_{crtc/encoder/connector}_mode_valid()
>>   drm: Introduce drm_bridge_mode_valid()
>>   drm: Use new mode_valid() helpers in connector probe helper
>>   drm: Use mode_valid() in atomic modeset
>>   drm: arc: Use crtc->mode_valid() callback
>>
>> Cc: Carlos Palminha <palminha@...opsys.com>
>> Cc: Alexey Brodkin <abrodkin@...opsys.com>
>> Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>
>> Cc: Daniel Vetter <daniel.vetter@...ll.ch>
>> Cc: Dave Airlie <airlied@...ux.ie>
>> Cc: Andrzej Hajda <a.hajda@...sung.com>
>> Cc: Archit Taneja <architt@...eaurora.org>
> Commented with an entire patch on patch 1, patches 2-5 are all
>
> Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
>
> But I think some more acks/r-bs would be really good, since this is quite
> a bit change in the helper infrastructure. But otherwise ready for merging
> imo. Can you pls also review my proposal for patch 1?
>
> Thanks, Daniel

As the patchset improves many things, I would like to point here that
there are still issues with mode probing at least in case of panels.
Panels in general does not provide discrete list of supported modes, but
they provide list of supported mode ranges (named display_timings), at
the moment this is only addressed in drm_panel_funcs::get_timings, but
drm core does not use it at all.
Currently most of the panel drivers advertises only fixed list of
arbitrary chosen modes, and if bridge/connector/encoder/crtc does not
support it pipeline does not work, even if slightly different
configuration could work. Of course there are workarounds but maybe it
would be good to replace drm_connector::modes with drm_connector::timings.
This way set of valid timings of the whole pipeline will be intersection
of sets of valid timings of every component of the pipeline - quite
straightforward and simple construct.

As this is just an idea which came to me during patchset review, it is
not backed by any code, but maybe it can be interesting for quick
brainstorm.

Regards
Andrzej


>
>>  drivers/gpu/drm/arc/arcpgu_crtc.c          |  39 ++++++----
>>  drivers/gpu/drm/drm_atomic_helper.c        |  76 +++++++++++++++++++-
>>  drivers/gpu/drm/drm_bridge.c               |  33 +++++++++
>>  drivers/gpu/drm/drm_crtc_helper_internal.h |  13 ++++
>>  drivers/gpu/drm/drm_probe_helper.c         | 103 ++++++++++++++++++++++++++-
>>  include/drm/drm_bridge.h                   |  22 ++++++
>>  include/drm/drm_modeset_helper_vtables.h   | 110 ++++++++++++++++++++++-------
>>  7 files changed, 348 insertions(+), 48 deletions(-)
>>
>> -- 
>> 1.9.1
>>
>>