linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonas Karlman <jonas@kwiboo.se>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Tomasz Figa <tfiga@chromium.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 06/10] media: hantro: Use capture buffer width and height for H264 decoding
Date: Thu, 31 Oct 2019 10:00:48 +0000	[thread overview]
Message-ID: <HE1PR06MB4011EADF6F3255CA0B7D9B19AC630@HE1PR06MB4011.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <20191031102102.63afd4e5@collabora.com>

On 2019-10-31 10:21, Boris Brezillon wrote:
> On Tue, 29 Oct 2019 01:24:50 +0000
> Jonas Karlman <jonas@kwiboo.se> wrote:
>
>> Calculations for motion vector buffer offset is based on width and height
>> from the configured capture format, lets use the same values for macroblock
>> width and height hw regs.
>>
>> Fixes: dea0a82f3d22 ("media: hantro: Add support for H264 decoding on G1")
>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>> ---
>> Changes in v2:
>>   - new patch split from "media: hantro: Fix H264 motion vector buffer offset"
>> ---
>>  drivers/staging/media/hantro/hantro_g1_h264_dec.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
>> index 71bf162eaf73..eeed11366135 100644
>> --- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
>> +++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
>> @@ -51,8 +51,8 @@ static void set_params(struct hantro_ctx *ctx)
>>  	vdpu_write_relaxed(vpu, reg, G1_REG_DEC_CTRL0);
>>  
>>  	/* Decoder control register 1. */
>> -	reg = G1_REG_DEC_CTRL1_PIC_MB_WIDTH(sps->pic_width_in_mbs_minus1 + 1) |
>> -	      G1_REG_DEC_CTRL1_PIC_MB_HEIGHT_P(sps->pic_height_in_map_units_minus1 + 1) |
>> +	reg = G1_REG_DEC_CTRL1_PIC_MB_WIDTH(MB_WIDTH(ctx->dst_fmt.width)) |
>> +	      G1_REG_DEC_CTRL1_PIC_MB_HEIGHT_P(MB_HEIGHT(ctx->dst_fmt.height)) |
> I'm just curious, do they differ in practice? Also not sure what's been
> decided for the "G1 post-proc", but if the dst/capture format res set
> by the user is the scaled res (PP can scale IIRC), then you probably
> shouldn't use those values here.

You are correct, I wanted to use the same source for both size and offsets, looking at this again
both here and where is it used for offsets this probably need to change.

Do you think we can use src_fmt.width/height for size and offsets? It looks like that is what cedrus is using.

Regards,
Jonas

>
>>  	      G1_REG_DEC_CTRL1_REF_FRAMES(sps->max_num_ref_frames);
>>  	vdpu_write_relaxed(vpu, reg, G1_REG_DEC_CTRL1);
>>  
>>

  reply	other threads:[~2019-10-31 10:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29  1:23 [PATCH RFC v2 00/10] media: hantro: H264 fixes and improvements Jonas Karlman
2019-10-29  1:24 ` [PATCH v2 01/10] media: hantro: Fix H264 max frmsize supported on RK3288 Jonas Karlman
2019-10-31  8:52   ` Boris Brezillon
2019-11-01  8:36     ` Hans Verkuil
2019-11-05  7:56       ` Boris Brezillon
     [not found] ` <20191029012430.24566-1-jonas@kwiboo.se>
2019-10-29  1:24   ` [PATCH v2 02/10] media: hantro: Fix motion vectors usage condition Jonas Karlman
2019-10-31  8:58     ` Boris Brezillon
2019-11-02 23:09     ` Ezequiel Garcia
2019-11-02 23:10       ` Ezequiel Garcia
2019-10-29  1:24   ` [PATCH v2 03/10] media: hantro: Fix picture order count table enable Jonas Karlman
2019-10-31  8:59     ` Boris Brezillon
2019-10-29  1:24   ` [PATCH v2 04/10] media: hantro: Fix H264 motion vector buffer offset Jonas Karlman
2019-10-31  9:47     ` Boris Brezillon
2019-10-29  1:24   ` [PATCH v2 05/10] media: hantro: Reduce H264 extra space for motion vectors Jonas Karlman
2019-10-31  9:50     ` Boris Brezillon
2019-10-29  1:24   ` [PATCH v2 06/10] media: hantro: Use capture buffer width and height for H264 decoding Jonas Karlman
2019-10-31  9:21     ` Boris Brezillon
2019-10-31 10:00       ` Jonas Karlman [this message]
2019-10-29  1:24   ` [PATCH v2 07/10] media: hantro: Remove now unused H264 pic_size Jonas Karlman
2019-10-31  9:53     ` Boris Brezillon
2019-10-29  1:26 ` [PATCH v2 08/10] media: hantro: Set H264 FIELDPIC_FLAG_E flag correctly Jonas Karlman
2019-10-31 10:00   ` Boris Brezillon
     [not found] ` <20191029012550.24628-1-jonas@kwiboo.se>
2019-10-29  1:26   ` [RFC v2 09/10] media: uapi: h264: Add DPB entry field reference flags Jonas Karlman
2019-10-31 10:20     ` Boris Brezillon
2019-11-15  6:26       ` Jonas Karlman
2019-11-15  7:45         ` Boris Brezillon
2019-11-15  8:15           ` Jonas Karlman
2019-10-29  1:26   ` [RFC v2 10/10] media: hantro: Fix H264 decoding of field encoded content Jonas Karlman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HE1PR06MB4011EADF6F3255CA0B7D9B19AC630@HE1PR06MB4011.eurprd06.prod.outlook.com \
    --to=jonas@kwiboo.se \
    --cc=boris.brezillon@collabora.com \
    --cc=ezequiel@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).