[PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Ville Syrjälä]

On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart wrote:
> >
> > [snip]
> > 
> > >> Should we add that to crtc helpers, instead of the current "just try to
> > >> smash the old config on top of the ill-defined hw state after a failed
> > >> modeset"?
> > > 
> > > It would probably make sense to add a rollback operation to undo the
> > > prepare operation, or maybe just a rollback/commit flag to the commit
> > > operation. We would still need to smash the old config back though, as
> > > the rollback operation shouldn't be expected to handle encoders and
> > > connectors.
> > > 
> > > While we're at it, shouldn't we make drivers report supported formats for
> > > the main frame buffer, like we do for planes ? That would allow catching
> > > format errors before calling the prepare operation.
> > 
> > Yeah, I've noticed that one, too. I guess we could tackle that as part
> > of an eventual "make the implicit primary plane a bit more explict"
> > project. For now I'm not too offended by the duplication of checks.
> 
> It would be nice to treat the primary plane as all the other planes. Several 
> embedded display engines don't make the primary plane special and just paint 
> the background with a plain color when the enabled planes don't cover the 
> entire display.

Same deal for some intel hardware (at least partially). Anyways, my
current plan is that we fix it for the atomic pageflip/modeset stuff.
Ie. I don't even want expose the CRTC scanout stuff in the new atomic
API.

-- 
Ville Syrjälä
Intel OTC