Re: [PATCH 7/9] media: cedrus: Move IRQ maintainance to cedrus_dec_ops

[Paul Kocialkowski]

On Mon, 2018-06-25 at 17:38 +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Wed, 2018-06-13 at 16:07 +0200, Maxime Ripard wrote:
> > The IRQ handler up until now was hardcoding the use of the MPEG engine to
> > read the interrupt status, clear it and disable the interrupts.
> > 
> > Obviously, that won't work really well with the introduction of new codecs
> > that use a separate engine with a separate register set.
> > 
> > In order to make this more future proof, introduce new decodec operations
> > to deal with the interrupt management. The only one missing is the one to
> > enable the interrupts in the first place, but that's taken care of by the
> > trigger hook for now.
> 
> Here's another comment about an issue I just figured out.
> 
> > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxx>
> > ---
> >  .../sunxi/cedrus/sunxi_cedrus_common.h        |  9 +++++
> >  .../platform/sunxi/cedrus/sunxi_cedrus_hw.c   | 21 ++++++------
> >  .../sunxi/cedrus/sunxi_cedrus_mpeg2.c         | 33 +++++++++++++++++++
> >  3 files changed, 53 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
> > index c2e2c92d103b..a2a507eb9fc9 100644
> > --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
> > +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_common.h
> > @@ -108,7 +108,16 @@ struct sunxi_cedrus_buffer *vb2_to_cedrus_buffer(const struct vb2_buffer *p)
> >  	return vb2_v4l2_to_cedrus_buffer(to_vb2_v4l2_buffer(p));
> >  }
> >  
> > +enum sunxi_cedrus_irq_status {
> > +	SUNXI_CEDRUS_IRQ_NONE,
> > +	SUNXI_CEDRUS_IRQ_ERROR,
> > +	SUNXI_CEDRUS_IRQ_OK,
> > +};
> > +
> >  struct sunxi_cedrus_dec_ops {
> > +	void (*irq_clear)(struct sunxi_cedrus_ctx *ctx);
> > +	void (*irq_disable)(struct sunxi_cedrus_ctx *ctx);
> > +	enum sunxi_cedrus_irq_status (*irq_status)(struct sunxi_cedrus_ctx *ctx);
> >  	void (*setup)(struct sunxi_cedrus_ctx *ctx,
> >  		      struct sunxi_cedrus_run *run);
> >  	void (*trigger)(struct sunxi_cedrus_ctx *ctx);
> > diff --git a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_hw.c b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_hw.c
> > index bb46a01214e0..6b97cbd2834e 100644
> > --- a/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_hw.c
> > +++ b/drivers/media/platform/sunxi/cedrus/sunxi_cedrus_hw.c
> > @@ -77,27 +77,28 @@ static irqreturn_t sunxi_cedrus_ve_irq(int irq, void *dev_id)
> >  	struct sunxi_cedrus_ctx *ctx;
> >  	struct sunxi_cedrus_buffer *src_buffer, *dst_buffer;
> >  	struct vb2_v4l2_buffer *src_vb, *dst_vb;
> > +	enum sunxi_cedrus_irq_status status;
> >  	unsigned long flags;
> > -	unsigned int value, status;
> >  
> >  	spin_lock_irqsave(&dev->irq_lock, flags);
> >  
> > -	/* Disable MPEG interrupts and stop the MPEG engine */
> > -	value = sunxi_cedrus_read(dev, VE_MPEG_CTRL);
> > -	sunxi_cedrus_write(dev, value & (~0xf), VE_MPEG_CTRL);
> > -
> > -	status = sunxi_cedrus_read(dev, VE_MPEG_STATUS);
> > -	sunxi_cedrus_write(dev, 0x0000c00f, VE_MPEG_STATUS);
> > -	sunxi_cedrus_engine_disable(dev);
> 
> This call was dropped from the code reorganization. What it intentional?
> 
> IMO, it should be brought back to the irq_disable ops for MPEG2 (and the
> same probably applies to H264).

Actually, this doesn't seem like the right place to put it.

Looking at the sunxi_engine_enable function, explicitly passing the
codec as an argument and calling that function from each codec's code
feels strange.

We should probably break down these functions
(sunxi_engine_enable/sunxi_engine_disable) into codec ops. The
start/stop couple seems like a good fit, but it brings up the following
question: do we want to disable the engine between each frame or not?

I really don't know how significant the power saving benefits are and
what downsides there might be.

What do you think?

>  Things still seem to work without it,
> though, but there might be a difference in terms of standby VPU power
> consumption.
> 
> Cheers,
> 
> Paul
> 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

Attachment: signature.asc
Description: This is a digitally signed message part