Message ID | 20240415100726.19911-1-brnkv.i1@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Wave515 decoder IP support | expand |
Hey Ivan, On 15.04.2024 13:07, Ivan Bornyakov wrote: >Initial support for Wave515 multi-decoder IP among other refinements. >This was tested on FPGA prototype, so wave5_dt_ids[] was not expanded. > >fluster score for JCT-VC-HEVC_V1 testsuite with >GStreamer-H.265-V4L2-Gst1.0 decoder is 132/147 > >The issue with Main10 tests is that fluster expects decoded file to be >in yuv420p10le format while this driver decodes HEVC Main10 into 8-bit >yuv420p. Though result is looks alright to the naked eye, proper >decoding into yuv420p10le is to be added. > >The rest failed fluster tests are common with Wave521. > >ChangeLog: > v1: >https://lore.kernel.org/linux-media/20240318144225.30835-1-brnkv.i1@gmail.com/ > v2: >https://lore.kernel.org/linux-media/20240325064102.9278-1-brnkv.i1@gmail.com/ > * drop patch "dt-bindings: media: cnm,wave521c: drop resets restriction" > The only user of Wave5 in mainline is TI K3 boards, thus there is > no real need to alter dt-bindings > * in patch "media: chips-media: wave5: support decoding HEVC Main10 profile" > add check for flag "support_hevc10bit_dec" > * in patch "media: chips-media: wave5: support reset lines" move > reset_control_deassert() out of else branch, add > reset_control_assert() to probe error path. > * rework patch "media: chips-media: wave5: drop "sram-size" DT prop" > - don't move alloc/free form device open/close > - intead of exact configuration of reserved SRAM memory in DT and > allocating all of it, allocate all available SRAM memory up to > WAVE5_MAX_SRAM_SIZE from whatever pool provided. > * adjust patch "media: chips-media: wave5: support Wave515 decoder" > according to changes in patches > "media: chips-media: wave5: support decoding HEVC Main10 profile" and > "media: chips-media: wave5: drop "sram-size" DT prop" > v3: >https://lore.kernel.org/linux-media/20240405164112.24571-1-brnkv.i1@gmail.com/ > * reword patch "media: chips-media: wave5: separate irq setup routine" > a bit. > * in patch "media: chips-media: wave5: drop "sram-size" DT prop" > - move MAX_SRAM_SIZE define into match_data->sram_size > - add placeholders for validation that allocated SRAM memory is > enough to encode/decode bitstream of given resolution before > setting W5_USE_SEC_AXI and W5_CMD_ENC_PIC_USE_SEC_AXI registers > - reword accordingly > * in patch "media: chips-media: wave5: support Wave515 decoder" > - add comments around SRAM memory allocation/freeing about > Wave515 specifics > - add comments about BSOPTION_RD_PTR_VALID_FLAG bit in > W5_BS_OPTION register > - add W[AVE]521_ prefix to defines, for wich there are W[AVE]515_ > alternatieves > - add semi-magic Wave515 specific formulas to estimate SRAM usage > v4: > * rebase onto next-20240415, no functional changes Sorry for not finding the time for review, I'll work on it asap. But please don't send a full new series just for a rebase, as that just causes noise, I can very well rebase the series myself before a PR and if any hard conflicts appear they can be communicated. Greetings, Sebastian > >Ivan Bornyakov (5): > media: chips-media: wave5: support decoding HEVC Main10 profile > media: chips-media: wave5: support reset lines > media: chips-media: wave5: separate irq setup routine > media: chips-media: wave5: drop "sram-size" DT prop > media: chips-media: wave5: support Wave515 decoder > > .../platform/chips-media/wave5/wave5-helper.c | 8 +- > .../platform/chips-media/wave5/wave5-hw.c | 395 +++++++++++++----- > .../chips-media/wave5/wave5-regdefine.h | 5 + > .../platform/chips-media/wave5/wave5-vdi.c | 27 +- > .../chips-media/wave5/wave5-vpu-dec.c | 51 ++- > .../chips-media/wave5/wave5-vpu-enc.c | 2 +- > .../platform/chips-media/wave5/wave5-vpu.c | 35 +- > .../platform/chips-media/wave5/wave5-vpuapi.h | 3 + > .../chips-media/wave5/wave5-vpuconfig.h | 16 +- > .../media/platform/chips-media/wave5/wave5.h | 6 + > 10 files changed, 407 insertions(+), 141 deletions(-) > >-- >2.44.0 >
Hi On Mon, Apr 15, 2024 at 02:49:38PM +0200, Sebastian Fricke wrote: > Hey Ivan, > > On 15.04.2024 13:07, Ivan Bornyakov wrote: > > Initial support for Wave515 multi-decoder IP among other refinements. > > This was tested on FPGA prototype, so wave5_dt_ids[] was not expanded. > > > > fluster score for JCT-VC-HEVC_V1 testsuite with > > GStreamer-H.265-V4L2-Gst1.0 decoder is 132/147 > > > > The issue with Main10 tests is that fluster expects decoded file to be > > in yuv420p10le format while this driver decodes HEVC Main10 into 8-bit > > yuv420p. Though result is looks alright to the naked eye, proper > > decoding into yuv420p10le is to be added. > > > > The rest failed fluster tests are common with Wave521. > > > > ChangeLog: > > v1: > > https://lore.kernel.org/linux-media/20240318144225.30835-1-brnkv.i1@gmail.com/ > > v2: > > https://lore.kernel.org/linux-media/20240325064102.9278-1-brnkv.i1@gmail.com/ > > * drop patch "dt-bindings: media: cnm,wave521c: drop resets restriction" > > The only user of Wave5 in mainline is TI K3 boards, thus there is > > no real need to alter dt-bindings > > * in patch "media: chips-media: wave5: support decoding HEVC Main10 profile" > > add check for flag "support_hevc10bit_dec" > > * in patch "media: chips-media: wave5: support reset lines" move > > reset_control_deassert() out of else branch, add > > reset_control_assert() to probe error path. > > * rework patch "media: chips-media: wave5: drop "sram-size" DT prop" > > - don't move alloc/free form device open/close > > - intead of exact configuration of reserved SRAM memory in DT and > > allocating all of it, allocate all available SRAM memory up to > > WAVE5_MAX_SRAM_SIZE from whatever pool provided. > > * adjust patch "media: chips-media: wave5: support Wave515 decoder" > > according to changes in patches > > "media: chips-media: wave5: support decoding HEVC Main10 profile" and > > "media: chips-media: wave5: drop "sram-size" DT prop" > > v3: > > https://lore.kernel.org/linux-media/20240405164112.24571-1-brnkv.i1@gmail.com/ > > * reword patch "media: chips-media: wave5: separate irq setup routine" > > a bit. > > * in patch "media: chips-media: wave5: drop "sram-size" DT prop" > > - move MAX_SRAM_SIZE define into match_data->sram_size > > - add placeholders for validation that allocated SRAM memory is > > enough to encode/decode bitstream of given resolution before > > setting W5_USE_SEC_AXI and W5_CMD_ENC_PIC_USE_SEC_AXI registers > > - reword accordingly > > * in patch "media: chips-media: wave5: support Wave515 decoder" > > - add comments around SRAM memory allocation/freeing about > > Wave515 specifics > > - add comments about BSOPTION_RD_PTR_VALID_FLAG bit in > > W5_BS_OPTION register > > - add W[AVE]521_ prefix to defines, for wich there are W[AVE]515_ > > alternatieves > > - add semi-magic Wave515 specific formulas to estimate SRAM usage > > v4: > > * rebase onto next-20240415, no functional changes > > Sorry for not finding the time for review, I'll work on it asap. Thanks in advance > But please don't send a full new series just for a rebase, as that just > causes noise, I can very well rebase the series myself before a PR > and if any hard conflicts appear they can be communicated. Ok, noted. BTW, there was minor conflicts with commit "media: chips-media: wave5: Add hrtimer based polling support" wich was accepted since v3. Next time I'll ask explicitly if I should post rebased version or not. Apologies for the noise. > > Greetings, > Sebastian > > > > > Ivan Bornyakov (5): > > media: chips-media: wave5: support decoding HEVC Main10 profile > > media: chips-media: wave5: support reset lines > > media: chips-media: wave5: separate irq setup routine > > media: chips-media: wave5: drop "sram-size" DT prop > > media: chips-media: wave5: support Wave515 decoder > > > > .../platform/chips-media/wave5/wave5-helper.c | 8 +- > > .../platform/chips-media/wave5/wave5-hw.c | 395 +++++++++++++----- > > .../chips-media/wave5/wave5-regdefine.h | 5 + > > .../platform/chips-media/wave5/wave5-vdi.c | 27 +- > > .../chips-media/wave5/wave5-vpu-dec.c | 51 ++- > > .../chips-media/wave5/wave5-vpu-enc.c | 2 +- > > .../platform/chips-media/wave5/wave5-vpu.c | 35 +- > > .../platform/chips-media/wave5/wave5-vpuapi.h | 3 + > > .../chips-media/wave5/wave5-vpuconfig.h | 16 +- > > .../media/platform/chips-media/wave5/wave5.h | 6 + > > 10 files changed, 407 insertions(+), 141 deletions(-) > > > > -- > > 2.44.0 > >
On Mon, Apr 15, 2024 at 01:07:18PM GMT, Ivan Bornyakov wrote: > Initial support for Wave515 multi-decoder IP among other refinements. > This was tested on FPGA prototype, so wave5_dt_ids[] was not expanded. > > fluster score for JCT-VC-HEVC_V1 testsuite with > GStreamer-H.265-V4L2-Gst1.0 decoder is 132/147 > > The issue with Main10 tests is that fluster expects decoded file to be > in yuv420p10le format while this driver decodes HEVC Main10 into 8-bit > yuv420p. Though result is looks alright to the naked eye, proper > decoding into yuv420p10le is to be added. > > The rest failed fluster tests are common with Wave521. > > ChangeLog: > v1: > https://lore.kernel.org/linux-media/20240318144225.30835-1-brnkv.i1@gmail.com/ > v2: > https://lore.kernel.org/linux-media/20240325064102.9278-1-brnkv.i1@gmail.com/ > * drop patch "dt-bindings: media: cnm,wave521c: drop resets restriction" > The only user of Wave5 in mainline is TI K3 boards, thus there is > no real need to alter dt-bindings > * in patch "media: chips-media: wave5: support decoding HEVC Main10 profile" > add check for flag "support_hevc10bit_dec" > * in patch "media: chips-media: wave5: support reset lines" move > reset_control_deassert() out of else branch, add > reset_control_assert() to probe error path. > * rework patch "media: chips-media: wave5: drop "sram-size" DT prop" > - don't move alloc/free form device open/close > - intead of exact configuration of reserved SRAM memory in DT and > allocating all of it, allocate all available SRAM memory up to > WAVE5_MAX_SRAM_SIZE from whatever pool provided. > * adjust patch "media: chips-media: wave5: support Wave515 decoder" > according to changes in patches > "media: chips-media: wave5: support decoding HEVC Main10 profile" and > "media: chips-media: wave5: drop "sram-size" DT prop" > v3: > https://lore.kernel.org/linux-media/20240405164112.24571-1-brnkv.i1@gmail.com/ > * reword patch "media: chips-media: wave5: separate irq setup routine" > a bit. > * in patch "media: chips-media: wave5: drop "sram-size" DT prop" > - move MAX_SRAM_SIZE define into match_data->sram_size > - add placeholders for validation that allocated SRAM memory is > enough to encode/decode bitstream of given resolution before > setting W5_USE_SEC_AXI and W5_CMD_ENC_PIC_USE_SEC_AXI registers > - reword accordingly > * in patch "media: chips-media: wave5: support Wave515 decoder" > - add comments around SRAM memory allocation/freeing about > Wave515 specifics > - add comments about BSOPTION_RD_PTR_VALID_FLAG bit in > W5_BS_OPTION register > - add W[AVE]521_ prefix to defines, for wich there are W[AVE]515_ > alternatieves > - add semi-magic Wave515 specific formulas to estimate SRAM usage > v4: > * rebase onto next-20240415, no functional changes > > Ivan Bornyakov (5): > media: chips-media: wave5: support decoding HEVC Main10 profile > media: chips-media: wave5: support reset lines > media: chips-media: wave5: separate irq setup routine > media: chips-media: wave5: drop "sram-size" DT prop > media: chips-media: wave5: support Wave515 decoder > > .../platform/chips-media/wave5/wave5-helper.c | 8 +- > .../platform/chips-media/wave5/wave5-hw.c | 395 +++++++++++++----- > .../chips-media/wave5/wave5-regdefine.h | 5 + > .../platform/chips-media/wave5/wave5-vdi.c | 27 +- > .../chips-media/wave5/wave5-vpu-dec.c | 51 ++- > .../chips-media/wave5/wave5-vpu-enc.c | 2 +- > .../platform/chips-media/wave5/wave5-vpu.c | 35 +- > .../platform/chips-media/wave5/wave5-vpuapi.h | 3 + > .../chips-media/wave5/wave5-vpuconfig.h | 16 +- > .../media/platform/chips-media/wave5/wave5.h | 6 + > 10 files changed, 407 insertions(+), 141 deletions(-) > > -- > 2.44.0 > Friendly ping.
Hey Ivan, On 02.05.2024 09:40, Ivan Bornyakov wrote: >On Mon, Apr 15, 2024 at 01:07:18PM GMT, Ivan Bornyakov wrote: >> Initial support for Wave515 multi-decoder IP among other refinements. >> This was tested on FPGA prototype, so wave5_dt_ids[] was not expanded. >> >> fluster score for JCT-VC-HEVC_V1 testsuite with >> GStreamer-H.265-V4L2-Gst1.0 decoder is 132/147 >> >> The issue with Main10 tests is that fluster expects decoded file to be >> in yuv420p10le format while this driver decodes HEVC Main10 into 8-bit >> yuv420p. Though result is looks alright to the naked eye, proper >> decoding into yuv420p10le is to be added. >> >> The rest failed fluster tests are common with Wave521. >> >> ChangeLog: >> v1: >> https://lore.kernel.org/linux-media/20240318144225.30835-1-brnkv.i1@gmail.com/ >> v2: >> https://lore.kernel.org/linux-media/20240325064102.9278-1-brnkv.i1@gmail.com/ >> * drop patch "dt-bindings: media: cnm,wave521c: drop resets restriction" >> The only user of Wave5 in mainline is TI K3 boards, thus there is >> no real need to alter dt-bindings >> * in patch "media: chips-media: wave5: support decoding HEVC Main10 profile" >> add check for flag "support_hevc10bit_dec" >> * in patch "media: chips-media: wave5: support reset lines" move >> reset_control_deassert() out of else branch, add >> reset_control_assert() to probe error path. >> * rework patch "media: chips-media: wave5: drop "sram-size" DT prop" >> - don't move alloc/free form device open/close >> - intead of exact configuration of reserved SRAM memory in DT and >> allocating all of it, allocate all available SRAM memory up to >> WAVE5_MAX_SRAM_SIZE from whatever pool provided. >> * adjust patch "media: chips-media: wave5: support Wave515 decoder" >> according to changes in patches >> "media: chips-media: wave5: support decoding HEVC Main10 profile" and >> "media: chips-media: wave5: drop "sram-size" DT prop" >> v3: >> https://lore.kernel.org/linux-media/20240405164112.24571-1-brnkv.i1@gmail.com/ >> * reword patch "media: chips-media: wave5: separate irq setup routine" >> a bit. >> * in patch "media: chips-media: wave5: drop "sram-size" DT prop" >> - move MAX_SRAM_SIZE define into match_data->sram_size >> - add placeholders for validation that allocated SRAM memory is >> enough to encode/decode bitstream of given resolution before >> setting W5_USE_SEC_AXI and W5_CMD_ENC_PIC_USE_SEC_AXI registers >> - reword accordingly >> * in patch "media: chips-media: wave5: support Wave515 decoder" >> - add comments around SRAM memory allocation/freeing about >> Wave515 specifics >> - add comments about BSOPTION_RD_PTR_VALID_FLAG bit in >> W5_BS_OPTION register >> - add W[AVE]521_ prefix to defines, for wich there are W[AVE]515_ >> alternatieves >> - add semi-magic Wave515 specific formulas to estimate SRAM usage >> v4: >> * rebase onto next-20240415, no functional changes >> >> Ivan Bornyakov (5): >> media: chips-media: wave5: support decoding HEVC Main10 profile >> media: chips-media: wave5: support reset lines >> media: chips-media: wave5: separate irq setup routine >> media: chips-media: wave5: drop "sram-size" DT prop >> media: chips-media: wave5: support Wave515 decoder >> >> .../platform/chips-media/wave5/wave5-helper.c | 8 +- >> .../platform/chips-media/wave5/wave5-hw.c | 395 +++++++++++++----- >> .../chips-media/wave5/wave5-regdefine.h | 5 + >> .../platform/chips-media/wave5/wave5-vdi.c | 27 +- >> .../chips-media/wave5/wave5-vpu-dec.c | 51 ++- >> .../chips-media/wave5/wave5-vpu-enc.c | 2 +- >> .../platform/chips-media/wave5/wave5-vpu.c | 35 +- >> .../platform/chips-media/wave5/wave5-vpuapi.h | 3 + >> .../chips-media/wave5/wave5-vpuconfig.h | 16 +- >> .../media/platform/chips-media/wave5/wave5.h | 6 + >> 10 files changed, 407 insertions(+), 141 deletions(-) >> >> -- >> 2.44.0 >> > >Friendly ping. Sorry again for the delay, I was nearly finished with the patch set last week but the time wasn't sufficient. And I sadly have to delay it again a bit as I am on vacation until 13.05. I expect finishing it probably until 17.05. Regards, Sebastian
Greetings, On Fri, May 03, 2024 at 05:07:21PM GMT, Sebastian Fricke wrote: > Hey Ivan, > > On 02.05.2024 09:40, Ivan Bornyakov wrote: > > > > Friendly ping. > > Sorry again for the delay, I was nearly finished with the patch set last > week but the time wasn't sufficient. And I sadly have to delay it again > a bit as I am on vacation until 13.05. I expect finishing it probably > until 17.05. > > Regards, > Sebastian Do you still intend to review the patch series? Also should I resend? Is there anything I can do to budge the process?
Hey Ivan, On 24.05.2024 12:09, Ivan Bornyakov wrote: >Greetings, > >On Fri, May 03, 2024 at 05:07:21PM GMT, Sebastian Fricke wrote: >> Hey Ivan, >> >> On 02.05.2024 09:40, Ivan Bornyakov wrote: >> > >> > Friendly ping. >> >> Sorry again for the delay, I was nearly finished with the patch set last >> week but the time wasn't sufficient. And I sadly have to delay it again >> a bit as I am on vacation until 13.05. I expect finishing it probably >> until 17.05. >> >> Regards, >> Sebastian > >Do you still intend to review the patch series? Yes, sadly maintainer work isn't the highest priority work at my job however. > >Also should I resend? Is there anything I can do to budge the process? Nope no action required from your side, just my busy schedule that keeps me from doing the work. If you want to you can help me get through my shelf quicker however by for example reviewing: https://patchwork.linuxtv.org/project/linux-media/list/?series=12848 Regards, Sebastian
On Fri, May 24, 2024 at 12:19:50PM GMT, Sebastian Fricke wrote: > Hey Ivan, > > On 24.05.2024 12:09, Ivan Bornyakov wrote: > > Greetings, > > > > On Fri, May 03, 2024 at 05:07:21PM GMT, Sebastian Fricke wrote: > > > Hey Ivan, > > > > > > On 02.05.2024 09:40, Ivan Bornyakov wrote: > > > > > > > > Friendly ping. > > > > > > Sorry again for the delay, I was nearly finished with the patch set last > > > week but the time wasn't sufficient. And I sadly have to delay it again > > > a bit as I am on vacation until 13.05. I expect finishing it probably > > > until 17.05. > > > > > > Regards, > > > Sebastian > > > > Do you still intend to review the patch series? > > Yes, sadly maintainer work isn't the highest priority work at my job > however. > > > > > Also should I resend? Is there anything I can do to budge the process? > > Nope no action required from your side, just my busy schedule that keeps > me from doing the work. If you want to you can help me get through my > shelf quicker however by for example reviewing: > https://patchwork.linuxtv.org/project/linux-media/list/?series=12848 > > Regards, > Sebastian Understood. I'll have a look.