From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751078AbdEaKsY (ORCPT ); Wed, 31 May 2017 06:48:24 -0400 Received: from foss.arm.com ([217.140.101.70]:42226 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751022AbdEaKsX (ORCPT ); Wed, 31 May 2017 06:48:23 -0400 Date: Wed, 31 May 2017 11:48:20 +0100 From: Liviu Dudau To: Neil Armstrong , g@e110455-lin.cambridge.arm.com, Jose Abreu , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Carlos Palminha Subject: Re: [PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback Message-ID: <20170531104820.GE7992@e110455-lin.cambridge.arm.com> References: <656f3894-58cd-d70c-78ae-b537a7480386@baylibre.com> <20170530093729.GB7992@e110455-lin.cambridge.arm.com> <20170531082004.pmqhieuvynnpjwcy@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170531082004.pmqhieuvynnpjwcy@phenom.ffwll.local> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 31, 2017 at 10:20:04AM +0200, Daniel Vetter wrote: > On Tue, May 30, 2017 at 10:37:29AM +0100, Liviu Dudau wrote: > > On Tue, May 30, 2017 at 09:29:44AM +0200, Neil Armstrong wrote: > > > On 05/25/2017 04:19 PM, Jose Abreu wrote: > > > > Now that we have a callback to check if crtc supports a given mode > > > > we can use it in malidp so that we restrict the number of probbed > > > > modes to the ones we can actually display. > > > > > > > > Also, remove the mode_fixup() callback as this is no longer needed > > > > because mode_valid() will be called before. > > > > > > > > NOTE: Not even compiled tested > > > > I did compile it, even done some testing, but by no means have I managed > > to cover all the cases. Looks OK to me. > > > > > > > > > > Signed-off-by: Jose Abreu > > > > Cc: Carlos Palminha > > > > Cc: Daniel Vetter > > > > Cc: Liviu Dudau > > > > Acked-by: Liviu Dudau > > What does this mean? Do you expect me to merge this through drm-misc? Or > do you plan to merge it through your arm tree (all the required patches > are in drm-misc-next and will be in Dave's tree soonish)? > > /me confused. /me too. :) I've only got Cc-ed on one patch, so I'm guessing the whole series is going to be picked up through drm-misc. For patches that are part of a larger series (to me) it makes sense to push them through a single channel. But I'm not the author of the series so I don't know what Jose prefers. If Jose wants this patch to go through mali-dp tree then I'm happy to pull it, otherwise I can sort out the conflict(s) before sending a pull request to Dave. On the larger topic, I'm guessing this is not the first time a series touches multiple drivers that are not together in a single tree. How was this sorted in the past? Is there a better way? Best regards, Liviu > > Thanks, Daniel > > > > > > > Cc: Brian Starkey > > > > Cc: David Airlie > > > > --- > > > > drivers/gpu/drm/arm/malidp_crtc.c | 11 +++++------ > > > > 1 file changed, 5 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/arm/malidp_crtc.c b/drivers/gpu/drm/arm/malidp_crtc.c > > > > index 9446a67..4bb38a2 100644 > > > > --- a/drivers/gpu/drm/arm/malidp_crtc.c > > > > +++ b/drivers/gpu/drm/arm/malidp_crtc.c > > > > @@ -22,9 +22,8 @@ > > > > #include "malidp_drv.h" > > > > #include "malidp_hw.h" > > > > > > > > -static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc, > > > > - const struct drm_display_mode *mode, > > > > - struct drm_display_mode *adjusted_mode) > > > > +static enum drm_mode_status malidp_crtc_mode_valid(struct drm_crtc *crtc, > > > > + const struct drm_display_mode *mode) > > > > { > > > > struct malidp_drm *malidp = crtc_to_malidp_device(crtc); > > > > struct malidp_hw_device *hwdev = malidp->dev; > > > > @@ -40,11 +39,11 @@ static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc, > > > > if (rate != req_rate) { > > > > DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n", > > > > req_rate); > > > > - return false; > > > > + return MODE_NOCLOCK; > > > > } > > > > } > > > > > > > > - return true; > > > > + return MODE_OK; > > > > } > > > > > > > > static void malidp_crtc_enable(struct drm_crtc *crtc) > > > > @@ -408,7 +407,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc, > > > > } > > > > > > > > static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = { > > > > - .mode_fixup = malidp_crtc_mode_fixup, > > > > + .mode_valid = malidp_crtc_mode_valid, > > > > .enable = malidp_crtc_enable, > > > > .disable = malidp_crtc_disable, > > > > .atomic_check = malidp_crtc_atomic_check, > > > > > > > > > > Reviewed-by: Neil Armstrong > > > > -- > > ==================== > > | I would like to | > > | fix the world, | > > | but they're not | > > | giving me the | > > \ source code! / > > --------------- > > ¯\_(ツ)_/¯ > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯