lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1468830992.2994.6.camel@pengutronix.de>
Date:	Mon, 18 Jul 2016 10:36:32 +0200
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	CK Hu <ck.hu@...iatek.com>
Cc:	YT Shen <yt.shen@...iatek.com>, dri-devel@...ts.freedesktop.org,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	David Airlie <airlied@...ux.ie>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Mao Huang <littlecvr@...omium.org>,
	Bibby Hsieh <bibby.hsieh@...iatek.com>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, srv_heupstream@...iatek.com,
	Sascha Hauer <kernel@...gutronix.de>,
	yingjoe.chen@...iatek.com, emil.l.velikov@...il.com,
	thierry.reding@...il.com
Subject: Re: [PATCH v4 3/8] drm/mediatek: add shadow register support

Hi CK, YT,

Am Montag, den 18.07.2016, 14:32 +0800 schrieb CK Hu:
> Hi, YT:
> 
> One comment inline.
> 
> 
> On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> > We need to acquire mutex before using the resources,
> > and need to release it after finished.
> > So we don't need to write registers in the blanking period.
> > 
> > Signed-off-by: YT Shen <yt.shen@...iatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   75 +++++++++++++++++++------------
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   22 +++++++++
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |    2 +
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |    1 +
> >  4 files changed, 71 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..80d9641 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -315,6 +315,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
> >  	pm_runtime_put(drm->dev);
> >  }
> >  
> > +static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> > +{
> > +	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> > +	struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
> > +	unsigned int i;
> > +
> > +	/*
> > +	 * TODO: instead of updating the registers here, we should prepare
> > +	 * working registers in atomic_commit and let the hardware command
> > +	 * queue update module registers on vblank.
> > +	 */
> > +	if (state->pending_config) {
> > +		mtk_ddp_comp_config(ovl, state->pending_width,
> > +				    state->pending_height,
> > +				    state->pending_vrefresh);
> > +
> > +		state->pending_config = false;
> > +	}
> > +
> > +	if (mtk_crtc->pending_planes) {
> > +		for (i = 0; i < OVL_LAYER_NR; i++) {
> > +			struct drm_plane *plane = &mtk_crtc->planes[i].base;
> > +			struct mtk_plane_state *plane_state;
> > +
> > +			plane_state = to_mtk_plane_state(plane->state);
> > +
> > +			if (plane_state->pending.config) {
> > +				mtk_ddp_comp_layer_config(ovl, i, plane_state);
> > +				plane_state->pending.config = false;
> > +			}
> > +		}
> > +		mtk_crtc->pending_planes = false;
> > +	}
> > +}
> > +
> >  static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
> >  {
> >  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > @@ -391,6 +427,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> >  				      struct drm_crtc_state *old_crtc_state)
> >  {
> >  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +	struct mtk_drm_private *priv = crtc->dev->dev_private;
> >  	unsigned int pending_planes = 0;
> >  	int i;
> >  
> > @@ -409,6 +446,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> >  	}
> >  	if (pending_planes)
> >  		mtk_crtc->pending_planes = true;
> > +
> > +	if (priv->data->shadow_register) {
> > +		mtk_disp_mutex_acquire(mtk_crtc->mutex);
> > +		mtk_crtc_ddp_config(crtc);
> > +		mtk_disp_mutex_release(mtk_crtc->mutex);
> > +	}
> >  }
> >  
> >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > @@ -453,36 +496,10 @@ err_cleanup_crtc:
> >  void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
> >  {
> >  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > -	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> > -	unsigned int i;
> > +	struct mtk_drm_private *priv = crtc->dev->dev_private;
> >  
> > -	/*
> > -	 * TODO: instead of updating the registers here, we should prepare
> > -	 * working registers in atomic_commit and let the hardware command
> > -	 * queue update module registers on vblank.
> > -	 */
> > -	if (state->pending_config) {
> > -		mtk_ddp_comp_config(ovl, state->pending_width,
> > -				    state->pending_height,
> > -				    state->pending_vrefresh);
> > -
> > -		state->pending_config = false;
> > -	}
> > -
> > -	if (mtk_crtc->pending_planes) {
> > -		for (i = 0; i < OVL_LAYER_NR; i++) {
> > -			struct drm_plane *plane = &mtk_crtc->planes[i].base;
> > -			struct mtk_plane_state *plane_state;
> > -
> > -			plane_state = to_mtk_plane_state(plane->state);
> > -
> > -			if (plane_state->pending.config) {
> > -				mtk_ddp_comp_layer_config(ovl, i, plane_state);
> > -				plane_state->pending.config = false;
> > -			}
> > -		}
> > -		mtk_crtc->pending_planes = false;
> > -	}
> > +	if (!priv->data->shadow_register)
> > +		mtk_crtc_ddp_config(crtc);
> >  
> >  	mtk_drm_finish_page_flip(mtk_crtc);
> >  }
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 8030769..fa53806 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -12,6 +12,7 @@
> >   */
> >  
> >  #include <linux/clk.h>
> > +#include <linux/iopoll.h>
> >  #include <linux/module.h>
> >  #include <linux/of_device.h>
> >  #include <linux/platform_device.h>
> > @@ -32,6 +33,7 @@
> >  #define DISP_REG_CONFIG_MMSYS_CG_CON0		0x100
> >  
> >  #define DISP_REG_MUTEX_EN(n)	(0x20 + 0x20 * (n))
> > +#define DISP_REG_MUTEX(n)	(0x24 + 0x20 * (n))
> >  #define DISP_REG_MUTEX_RST(n)	(0x28 + 0x20 * (n))
> >  #define DISP_REG_MUTEX_MOD(n)	(0x2c + 0x20 * (n))
> >  #define DISP_REG_MUTEX_SOF(n)	(0x30 + 0x20 * (n))
> > @@ -300,6 +302,26 @@ void mtk_disp_mutex_disable(struct mtk_disp_mutex *mutex)
> >  	writel(0, ddp->regs + DISP_REG_MUTEX_EN(mutex->id));
> >  }
> >  
> > +void mtk_disp_mutex_acquire(struct mtk_disp_mutex *mutex)
> > +{
> > +	struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
> > +					   mutex[mutex->id]);
> > +	u32 tmp;
> > +
> > +	writel(1, ddp->regs + DISP_REG_MUTEX_EN(mutex->id));
> > +	writel(1, ddp->regs + DISP_REG_MUTEX(mutex->id));
> > +	readl_poll_timeout_atomic(ddp->regs + DISP_REG_MUTEX(mutex->id), tmp,
> > +				  tmp & 0x2, 1, 10000);

Please add a descriptive #define for the 0x2 bit of the DISP_REG_MUTEX
registers.

> Nothing to do with timeout? I think it should print error message here
> or reset HW to recover it.

I assume that if mtk_disp_mutex_acquire is called while the hardware has
the mutex (during the shadow register update), this should wait until
the update is complete, since it can't back out from trying to acquire
the lock. Is that the case?

regards
Philipp

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ