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. Regards, Hans > >> }, >> }, >
