On Fri, 1 Nov 2019 09:36:55 +0100 Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > On 10/31/19 9:52 AM, Boris Brezillon wrote: > > On Tue, 29 Oct 2019 01:24:47 +0000 > > Jonas Karlman <jonas@xxxxxxxxx> wrote: > > > >> TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels, > >> change frmsize max_width/max_height to match TRM at [1]. > >> > >> This patch makes it possible to decode the 4096x2304 sample at [2]. > >> > >> [1] http://www.t-firefly.com/download/firefly-rk3288/docs/TRM/rk3288-chapter-25-video-encoder-decoder-unit-(vcodec).pdf > >> [2] https://4ksamples.com/puppies-bath-in-4k/ > >> > >> Fixes: 760327930e10 ("media: hantro: Enable H264 decoding on rk3288") > >> Signed-off-by: Jonas Karlman <jonas@xxxxxxxxx> > > > > Reviewed-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > > Tested-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > > > > Let's also add > > > > Cc: <stable@xxxxxxxxxxxxxxx> > > > > just in case this patch doesn't make it to 5.4. > > > > > >> --- > >> Changes in v2: > >> - updated commit message with reference to TRM and sample video > >> --- > >> drivers/staging/media/hantro/rk3288_vpu_hw.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/staging/media/hantro/rk3288_vpu_hw.c b/drivers/staging/media/hantro/rk3288_vpu_hw.c > >> index c0bdd6c02520..f8db6fcaad73 100644 > >> --- a/drivers/staging/media/hantro/rk3288_vpu_hw.c > >> +++ b/drivers/staging/media/hantro/rk3288_vpu_hw.c > >> @@ -67,10 +67,10 @@ static const struct hantro_fmt rk3288_vpu_dec_fmts[] = { > >> .max_depth = 2, > >> .frmsize = { > >> .min_width = 48, > >> - .max_width = 3840, > >> + .max_width = 4096, > >> .step_width = MB_DIM, > >> .min_height = 48, > >> - .max_height = 2160, > >> + .max_height = 2304, > >> .step_height = MB_DIM, > > > > Hans, Mauro, we were intending to have this fix merged in 5.4 or at > > the very least be backported to the 5.4 stable branch at some point, > > the problem is, this patch is based on media/master which contains the > > s/MB_DIM_H264/MB_DIM/ change. I can send a new version based on > > media/fixes, but that means Linus will have a conflict when merging the > > media 5.5 PR in his tree. Are you fine dealing with this conflict > > (letting Linus know about the expected resolution or backmerging the -rc > > containing the fix in media/master so that he doesn't even have to deal > > with it), or should we just let this patch go in media/master and > > backport it later? > > Backport it later once it is merged in mainline. > > This patch doesn't fix a bug, it is really an enhancement, so I think this > can safely be delayed. Okay, let's make things simple. Can we have patches 1 to 3 applied to media/master? I'll take care of backporting those patches to 5.4 once 5.5-rc1 is out. Thanks, Boris
