From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Fri, 07 Jun 2013 07:23:58 +0000 Subject: Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver Message-Id: <7879358.D2jilZSibG@avalon> List-Id: References: <1370314420-26524-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alex Deucher Cc: Daniel Vetter , Laurent Pinchart , dri-devel , linux-sh@vger.kernel.org On Thursday 06 June 2013 09:21:35 Alex Deucher wrote: > 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. So what's the agreement ? :-) -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver Date: Fri, 07 Jun 2013 09:23:58 +0200 Message-ID: <7879358.D2jilZSibG@avalon> References: <1370314420-26524-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: Sender: linux-sh-owner@vger.kernel.org To: Alex Deucher Cc: Daniel Vetter , Laurent Pinchart , dri-devel , linux-sh@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On Thursday 06 June 2013 09:21:35 Alex Deucher wrote: > 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. So what's the agreement ? :-) -- Regards, Laurent Pinchart