From patchwork Tue Apr 19 09:06:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Keeping X-Patchwork-Id: 8878191 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 6A7C59F1D3 for ; Tue, 19 Apr 2016 09:07:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 79CFB2011B for ; Tue, 19 Apr 2016 09:07:17 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8007C2017D for ; Tue, 19 Apr 2016 09:07:15 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1asRcn-0005xX-Rh; Tue, 19 Apr 2016 09:07:13 +0000 Received: from dougal.metanate.com ([90.155.101.14] helo=metanate.com) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1asRcd-0005XW-G1; Tue, 19 Apr 2016 09:07:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=metanate.com; s=stronger; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=mtr83LvylBuuen4TYK5zFuP7LZbkxaH7xDxfO98pw5g=; b=n00FVU0Uj1fU9wwX2byrAvZ0CMLluF+dv0a3D1bzC0L40Kp2xvLib+6qwaveffowFzhcvIQSLyYslFA1+ddH3RdBKlL2slbLtgN04YrG6Oyk0K1s23P1damBvwaCbiu9It5+WcVuQ1gVr8Zd6+CGZ6tCLMo2R0731HcAqUQRhkruM+ZE3RgrngB9+T224iDVq44woMhwj4n4OTIzMQ7WVB6lyBYbqfp30n9kGFM6hEm3Td0lt1pIqc0O2WD21UbA9nGAy76iQPf2r94Dic+0+eyyb9VeWktrxayvorWEcP2hSYuUfFjMMq4Delh12CCUAjgD5MUzdq+SQdJ9CP8CZw==; Received: from brian ([192.168.88.1] helo=localhost.localdomain) by shrek.metanate.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.83_RC2) (envelope-from ) id 1asRc6-0002Zp-Uc; Tue, 19 Apr 2016 10:06:31 +0100 Date: Tue, 19 Apr 2016 10:06:30 +0100 From: John Keeping To: Mark yao Subject: Re: [PATCH] drm/rockchip: get rid of rockchip_drm_crtc_mode_config Message-ID: <20160419100630.06518b63.john@metanate.com> In-Reply-To: <57159B37.9050806@rock-chips.com> References: <1460948611-32259-1-git-send-email-mark.yao@rock-chips.com> <20160418102538.0ed730ca.john@metanate.com> <57159B37.9050806@rock-chips.com> Organization: Metanate Ltd X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-unknown-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160419_020703_762690_CE8E5FD9 X-CRM114-Status: GOOD ( 21.13 ) X-Spam-Score: -3.0 (---) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heiko Stuebner , David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 19 Apr 2016 10:43:03 +0800, Mark yao wrote: > On 2016?04?18? 17:25, John Keeping wrote: > > On Mon, 18 Apr 2016 11:03:31 +0800, Mark Yao wrote: > > > >> >We need to take care of the vop status when use > >> >rockchip_drm_crtc_mode_config, if vop is disabled, > >> >the function would failed, that is terrible. > >> > > >> >Save connector type and output mode on drm_display_mode->private_flags > >> >at encoder mode_fixup, then we can configure the type and mode safely > >> >on crtc mode_set. > > Since Rockchip is atomic, shouldn't this be using atomic_check hooks and > > a subclassed crtc_state structure? > > > > I try to use atomic_check with crtc_state, but it seems not easy, > there are two value need transmit from connector to vop: connector type > and out_mode > > the connector type I think we can loop the atomic state to find the > connector type. > but the out_mode is a custom value, I can't find a generic way to > transmit it with atomic state. > > BTW, I think on atomic side, the drm_display_mode is under control by > atomic state, > and the mode->private_flags is not use by drm framework, I found i915 > and gma500 also use > mode->private_flags to transmit custom value. > > So I think it's no problem using mode->private_flags. The documentation for drm_display_mode::private says: It shouldn't be used by atomic drivers since they can store any additional data by subclassing state structures. This applies to private_flags as well. I think this means that we should do something like the patch below (which isn't even compile tested and doesn't cover implementing drm_encoder_helper_funcs::atomic_check on all of the encoders): -- >8 -- diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index 00d17d71aa4c..9d65fa9188f4 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h @@ -31,6 +31,14 @@ struct drm_device; struct drm_connector; +struct rockchip_crtc_state { + struct drm_crtc_state base; + int output_type; + int output_mode; +}; + +#define to_rockchip_crtc_state(s) container_of(x, struct rockchip_crtc_state, base) + /* * Rockchip drm private crtc funcs. * @enable_vblank: enable crtc vblank irq. diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index a619f120f801..5cdf3123e1eb 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -1044,13 +1044,34 @@ static void vop_crtc_destroy(struct drm_crtc *crtc) drm_crtc_cleanup(crtc); } +static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc) +{ + struct rockchip_crtc_state *rockchip_state; + + rockchip_state = kzalloc(sizeof(*rockchip_state), GFP_KERNEL); + if (!rockchip_state) + return NULL; + + __drm_atomic_helper_crtc_duplicate_state(crtc, &rockchip_state->base); + return &rockchip_state->base; +} + +static void vop_crtc_destroy_state(struct drm_crtc *crtc, + struct drm_crtc_state *state) +{ + struct rockchip_crtc_state *s = to_rockchip_crtc_state(state); + + __drm_atomic_helper_crtc_destroy_state(crtc, &s->base); + kfree(s); +} + static const struct drm_crtc_funcs vop_crtc_funcs = { .set_config = drm_atomic_helper_set_config, .page_flip = drm_atomic_helper_page_flip, .destroy = vop_crtc_destroy, .reset = drm_atomic_helper_crtc_reset, - .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, - .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, + .atomic_duplicate_state = vop_crtc_duplicate_state, + .atomic_destroy_state = vop_crtc_destroy_state, }; static bool vop_win_pending_is_complete(struct vop_win *vop_win)