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

[Boris Brezillon <boris.brezillon@free-electrons.com>]

On Tue, 23 May 2017 15:38:42 +0100
Liviu Dudau <Liviu.Dudau@arm.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@arm.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@free-electrons.com>
> > Tested-by: Boris Brezillon <boris.brezillon@free-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 ;-).