From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Deucher Subject: Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver Date: Thu, 6 Jun 2013 09:21:35 -0400 Message-ID: References: <1370314420-26524-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> <1463323.zSQmk3Du5c@avalon> <1706860.sAZ4jDfQzD@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: Sender: linux-sh-owner@vger.kernel.org To: Daniel Vetter Cc: Laurent Pinchart , Laurent Pinchart , dri-devel , linux-sh@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On Thu, Jun 6, 2013 at 9:12 AM, Daniel Vetter wrote: > On Wed, Jun 5, 2013 at 3:10 PM, Alex Deucher wrote: >> To me at least, it doesn't make sense that an encoder can clone >> itself. If an encoder is already in use, trying to clone itself would >> only lead to confusion and possible bugs (make sure some code path >> doesn't try and reprogram the encoder again, etc.). > > For me the possible_clones mask is just the set of encoders which can > together share a crtc (presuming that crtc is indeed in all of the > possible_crtcs mask of each encoder). From that pov it makes imo sense > that a given encoder itself can always be with itself on the same crtc > ;-) > > Otoh setcrtc doesn't care one bit about encoders (the crtc helpers do > internally use them, but it's not interface). And the possible_clones > stuff is by far not enough to describe all hw restrictions. So tbh I > don't care which way we go (or whether we indeed keep on using this > much at all). Same. I can go either way. Alex > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch