Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp2232550pxt; Sun, 8 Aug 2021 16:30:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwyy29mGdxR/Wvl9PrUtysB7Fk6Rkh/LFpeORdgP+IXXgq74TnTyiEKqt+UEKULV2witpFs X-Received: by 2002:a17:906:4e08:: with SMTP id z8mr426135eju.360.1628465406712; Sun, 08 Aug 2021 16:30:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628465406; cv=none; d=google.com; s=arc-20160816; b=0T50tgPbtg1+0yczhajAqpq/qKFiBTtKJCbYEhNzmdBSB0EUMZ1oxktibCECA0+A+w MqIa6VzRBP/FL05eLvEX9tF+0KUmQNTYtnp3Idd2lgXBQ7L60RIp5rnVOhrCOelhUusN +y4rQ/b+DoQp4OyMH0SDF3yHdp9gioJlM6WCRBI5fDJ8dnOtIjV3tfyRSDQEGivgj/c9 PiciozAOmfS/zhFDIPmkVuWXe+CKLRSVHLdFZezi11lxyXsL+LeBBSXVh0EnQ171TCWi quFvNhWcqwHkOw4gwhmDwvC6OhNHOvkhjoeMf2ju9gb5yvkBY+i770iQmwlGV4XNwIet aZkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:cc:to:subject:from:date; bh=HaGR+yLSHPOy1FZK79XpJdVT8X21WRjXQn9sd75tdCs=; b=dnrUXdZIq79y+zqVuLwYPOSxZkW38cO/KTAyacEIP9BIHy/BTBeoHcP5bH8V4zNyRf U3Irl9tUL+efjvYC0SUiGuO9E9hGGJhT6XoCFMxhdmvw3vF7w5PvSefR+KtjIHthwbh0 HsmQbeUmuaza8Ft7HBf0Ri343vZvoUh7vjE4t4vPT1nvdWbEYfIjDaMIXUPyv7y0j5t+ 9J+OJ18dfUfy6RqSzbx4MoJQoS0EH1/vDB8ezyqnMZDKHqNQKhWiY/e8iC5o2r01hHEq AEGxEYGEa+8ZGLvVuhtWJa/cBRhVvA82wATsu9Nnm/b7B0DDFX/uvSE2zZiwQ4SOeTi5 AkFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t1si1416995eds.244.2021.08.08.16.29.40; Sun, 08 Aug 2021 16:30:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232659AbhHHWXH convert rfc822-to-8bit (ORCPT + 99 others); Sun, 8 Aug 2021 18:23:07 -0400 Received: from aposti.net ([89.234.176.197]:54676 "EHLO aposti.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230506AbhHHWXG (ORCPT ); Sun, 8 Aug 2021 18:23:06 -0400 Date: Mon, 09 Aug 2021 00:22:38 +0200 From: Paul Cercueil Subject: Re: [PATCH 2/8] drm/ingenic: Simplify code by using hwdescs array To: Thomas Zimmermann Cc: David Airlie , Daniel Vetter , "H . Nikolaus Schaller" , Paul Boddie , list@opendingux.net, Sam Ravnborg , linux-mips@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: References: <20210808134526.119198-1-paul@crapouillou.net> <20210808134526.119198-3-paul@crapouillou.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, Le dim., ao?t 8 2021 at 20:42:53 +0200, Thomas Zimmermann a ?crit : > Hi > > Am 08.08.21 um 15:45 schrieb Paul Cercueil: >> Instead of having one 'hwdesc' variable for the plane #0 and one for >> the >> plane #1, use a 'hwdesc[2]' array, where the DMA hardware descriptors >> are indexed by the plane's number. >> >> Signed-off-by: Paul Cercueil >> --- >> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 38 >> ++++++++++++----------- >> 1 file changed, 20 insertions(+), 18 deletions(-) >> >> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c >> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c >> index e42eb43d8020..bc71ba44ccf4 100644 >> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c >> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c >> @@ -49,8 +49,7 @@ struct ingenic_dma_hwdesc { >> } __aligned(16); >>  struct ingenic_dma_hwdescs { >> - struct ingenic_dma_hwdesc hwdesc_f0; >> - struct ingenic_dma_hwdesc hwdesc_f1; >> + struct ingenic_dma_hwdesc hwdesc[2]; >> struct ingenic_dma_hwdesc hwdesc_pal; >> u16 palette[256] __aligned(16); >> }; >> @@ -141,6 +140,13 @@ static inline struct ingenic_drm >> *drm_nb_get_priv(struct notifier_block *nb) >> return container_of(nb, struct ingenic_drm, clock_nb); >> } >> +static inline dma_addr_t dma_hwdesc_addr(const struct >> ingenic_drm *priv, bool use_f1) > > Using the plane index instead of a boolean would be more aligned to > the way this function is being used. Alright, I can do that. >> +{ >> + u32 offset = offsetof(struct ingenic_dma_hwdescs, hwdesc[use_f1]); > > use_f1 is a function parameter. Is offsetof guaranteed to be > evaluated at runtime? The offsetof() macro could be defined like this: #define offsetof(type, elm) ((size_t) &((type *) 0)->elm) So I don't see a reason why this couldn't be evaluated at runtime, yes. It's just that the value of "offset" is not known at compilation time (unless the compiler does some constant propagation). In practice though, this code works fine. >> + >> + return priv->dma_hwdescs_phys + offset; >> +} >> + >> static int ingenic_drm_update_pixclk(struct notifier_block *nb, >> unsigned long action, >> void *data) >> @@ -562,6 +568,7 @@ static void >> ingenic_drm_plane_atomic_update(struct drm_plane *plane, >> struct ingenic_dma_hwdesc *hwdesc; >> unsigned int width, height, cpp, offset; >> dma_addr_t addr; >> + bool use_f1; >> u32 fourcc; >>  if (newstate && newstate->fb) { >> @@ -569,16 +576,14 @@ static void >> ingenic_drm_plane_atomic_update(struct drm_plane *plane, >> drm_fb_cma_sync_non_coherent(&priv->drm, oldstate, newstate); >>  crtc_state = newstate->crtc->state; >> + use_f1 = priv->soc_info->has_osd && plane != &priv->f0; >>  addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0); >> width = newstate->src_w >> 16; >> height = newstate->src_h >> 16; >> cpp = newstate->fb->format->cpp[0]; >> - if (!priv->soc_info->has_osd || plane == &priv->f0) >> - hwdesc = &priv->dma_hwdescs->hwdesc_f0; >> - else >> - hwdesc = &priv->dma_hwdescs->hwdesc_f1; >> + hwdesc = &priv->dma_hwdescs->hwdesc[use_f1]; > > Maybe add a helper that looks up the hwdesc field for a given plane? Sure. >>  hwdesc->addr = addr; >> hwdesc->cmd = JZ_LCD_CMD_EOF_IRQ | (width * height * cpp / 4); >> @@ -591,9 +596,9 @@ static void >> ingenic_drm_plane_atomic_update(struct drm_plane *plane, >> if (fourcc == DRM_FORMAT_C8) >> offset = offsetof(struct ingenic_dma_hwdescs, hwdesc_pal); >> else >> - offset = offsetof(struct ingenic_dma_hwdescs, hwdesc_f0); >> + offset = offsetof(struct ingenic_dma_hwdescs, hwdesc[0]); >> - priv->dma_hwdescs->hwdesc_f0.next = priv->dma_hwdescs_phys + >> offset; >> + priv->dma_hwdescs->hwdesc[0].next = priv->dma_hwdescs_phys + >> offset; > > Maybe priv->dma_hwdescs_phys + offset could be computed in a more > flexible helper than dma_hwdesc_addr(). > >>  crtc_state->color_mgmt_changed = fourcc == DRM_FORMAT_C8; >> } >> @@ -964,20 +969,17 @@ static int ingenic_drm_bind(struct device >> *dev, bool has_components) >>   /* Configure DMA hwdesc for foreground0 plane */ >> - dma_hwdesc_phys_f0 = priv->dma_hwdescs_phys >> - + offsetof(struct ingenic_dma_hwdescs, hwdesc_f0); >> - priv->dma_hwdescs->hwdesc_f0.next = dma_hwdesc_phys_f0; >> - priv->dma_hwdescs->hwdesc_f0.id = 0xf0; >> + dma_hwdesc_phys_f0 = dma_hwdesc_addr(priv, 0); >> + priv->dma_hwdescs->hwdesc[0].next = dma_hwdesc_phys_f0; >> + priv->dma_hwdescs->hwdesc[0].id = 0xf0; >>  /* Configure DMA hwdesc for foreground1 plane */ >> - dma_hwdesc_phys_f1 = priv->dma_hwdescs_phys >> - + offsetof(struct ingenic_dma_hwdescs, hwdesc_f1); >> - priv->dma_hwdescs->hwdesc_f1.next = dma_hwdesc_phys_f1; >> - priv->dma_hwdescs->hwdesc_f1.id = 0xf1; >> + dma_hwdesc_phys_f1 = dma_hwdesc_addr(priv, 1); >> + priv->dma_hwdescs->hwdesc[1].next = dma_hwdesc_phys_f1; >> + priv->dma_hwdescs->hwdesc[1].id = 0xf1; >>  /* Configure DMA hwdesc for palette */ >> - priv->dma_hwdescs->hwdesc_pal.next = priv->dma_hwdescs_phys >> - + offsetof(struct ingenic_dma_hwdescs, hwdesc_f0); >> + priv->dma_hwdescs->hwdesc_pal.next = dma_hwdesc_phys_f0; >> priv->dma_hwdescs->hwdesc_pal.id = 0xc0; >> priv->dma_hwdescs->hwdesc_pal.addr = priv->dma_hwdescs_phys >> + offsetof(struct ingenic_dma_hwdescs, palette); >> > > Could the setup in these three blocks be moved into a common helper? Yes. Thanks for the review. Cheers, -Paul