linux-kernel - Re: [PATCH v5 0/2] drm: Introduce writeback connectors

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: <20170523171631.1e34c5b1@bbrezillon>
Date:   Tue, 23 May 2017 17:16:31 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Liviu Dudau <Liviu.Dudau@....com>
Cc:     Daniel Vetter <daniel.vetter@...el.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Brian Starkey <brian.starkey@....com>,
        Sean Paul <seanpaul@...omium.org>,
        DRI devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Eric Anholt <eric@...olt.net>
Subject: Re: [PATCH v5 0/2] drm: Introduce writeback connectors

On Tue, 23 May 2017 15:38:42 +0100
Liviu Dudau <Liviu.Dudau@....com> wrote:

> On Tue, May 23, 2017 at 04:33:55PM +0200, Boris Brezillon wrote:
> > Hi Liviu,  
> 
> Hi Boris,
> 
> > 
> > On Mon, 15 May 2017 18:20:55 +0100
> > Liviu Dudau <Liviu.Dudau@....com> wrote:
> >   
> > > Hi,
> > > 
> > > This is v5 of the writeback connector series. Boris Brezillon thought
> > > that having to explicitly instantiate an encoder when using drm_writeback_connector
> > > is a bit too cumbersome, so I'm pushing out this version where we embed
> > > a virtual encoder inside drm_writeback_connector in order to satisfy the
> > > DRM framework. The caller of drm_writeback_connector_init() can control
> > > the embedded encoder by passing the drm_encoder_helper_funcs to be used.
> > > 
> > > Comments are welcome on the suitability of this series.  
> > 
> > Whole series is:
> > 
> > Reviewed-by: Boris Brezillon <boris.brezillon@...e-electrons.com>
> > Tested-by: Boris Brezillon <boris.brezillon@...e-electrons.com>
> > 
> > Note that I tested it with the kms_writeback igt tests (available in
> > your branch [1]).  
> 
> Thanks a lot! Now that you seem to be happy with the series (right?) I'll
> try to push the kms_writeback tests into igt and get this series accepted.

Well, I'm still not convinced that representing the writeback engine as
a connector is the right thing to do (I mean, look at the
encoder/connector hooks we are implementing, those are either empty
stubs or stubs emulating the behavior of a connector to let the user
think he's actually dealing with a real connector). But since I'm the
only one to be concerned by this aspect, I guess I have to accept
it :-).

There's another thing I'm not completely happy with: the fact that we
have to expose a function of the writeback engine driver and call it
from the mode_config->commit_tail() hook, just because the core does
not call encoder/connector hooks when the modes or display pipeline
routes did not changed. I'd really prefer to have a hook that is
unconditionally called to let the writeback engine driver decide when
an update is actually needed. I guess this point can be addressed by
extending the connector_helper vtable.

Anyway, you have my R-b/T-b, so you're not blocked because of me ;-).