mbox series

[0/4] Hantro VPU JPEG encoder fixes

Message ID 20200127143009.15677-1-andrzej.p@collabora.com (mailing list archive)
Headers show
Series Hantro VPU JPEG encoder fixes | expand

Message

Andrzej Pietrasiewicz Jan. 27, 2020, 2:30 p.m. UTC
This series addresses quality issues in encoded JPEG images.

The first patch actually restores the intention of the original submission
of this driver: due to a typo the helper variables were unused and then
have been removed in some cleanup done by Mauro.

The second patch aligns the driver's luma quantization table with
the one in the ITU-T.81 standard.

The third patch changes the order in which quantization tables are
written to the resulting file and to the hardware. The file expects
a zig-zag order, while the hardware wants some special order, neither
linear nor zig-zag. In other words, hardware-wise it rearranges which
parts of quantization tables go into which 4-byte registers - in a hardware
specific order rather than linear or zig-zag. It also affects rk3288 and
hasn't been tested with it.

The fourth patch then rearranges the sequence of register writes.
The whole luma quantization table must be written first, and then the
chroma quantization is written. In other words, while patch 3/4
changes what goes into which register, this patch changes when each
register is written to. It also affects rk3288 and hasn't been
tested with it.

Andrzej Pietrasiewicz (4):
  media: hantro: Read be32 words starting at every fourth byte
  media: hantro: Use standard luma quantization table
  media: hantro: Write the quantization tables in proper order
  media: hantro: Write quantization table registers in increasing
    addresses order

 .../staging/media/hantro/hantro_h1_jpeg_enc.c | 19 ++++-
 drivers/staging/media/hantro/hantro_jpeg.c    | 76 ++++++++++++++-----
 drivers/staging/media/hantro/hantro_jpeg.h    |  2 +-
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     | 24 ++++--
 4 files changed, 89 insertions(+), 32 deletions(-)

Comments

Ezequiel Garcia Jan. 27, 2020, 6:11 p.m. UTC | #1
Hi Andrzej,

Thanks a lot for the fixes!

On Mon, 2020-01-27 at 15:30 +0100, Andrzej Pietrasiewicz wrote:
> This series addresses quality issues in encoded JPEG images.
> 
> The first patch actually restores the intention of the original submission
> of this driver: due to a typo the helper variables were unused and then
> have been removed in some cleanup done by Mauro.
> 
> The second patch aligns the driver's luma quantization table with
> the one in the ITU-T.81 standard.
> 
> The third patch changes the order in which quantization tables are
> written to the resulting file and to the hardware. The file expects
> a zig-zag order, while the hardware wants some special order, neither
> linear nor zig-zag. In other words, hardware-wise it rearranges which
> parts of quantization tables go into which 4-byte registers - in a hardware
> specific order rather than linear or zig-zag. It also affects rk3288 and
> hasn't been tested with it.
> 
> The fourth patch then rearranges the sequence of register writes.
> The whole luma quantization table must be written first, and then the
> chroma quantization is written. In other words, while patch 3/4
> changes what goes into which register, this patch changes when each
> register is written to. It also affects rk3288 and hasn't been
> tested with it.
> 

I've just tested RK3288, and this series is indeed fixing
these issues. So for all patches:

Tested-by: Ezequiel Garcia <ezequiel@collabora.com>

Thanks,
Ezequiel

> Andrzej Pietrasiewicz (4):
>   media: hantro: Read be32 words starting at every fourth byte
>   media: hantro: Use standard luma quantization table
>   media: hantro: Write the quantization tables in proper order
>   media: hantro: Write quantization table registers in increasing
>     addresses order
> 
>  .../staging/media/hantro/hantro_h1_jpeg_enc.c | 19 ++++-
>  drivers/staging/media/hantro/hantro_jpeg.c    | 76 ++++++++++++++-----
>  drivers/staging/media/hantro/hantro_jpeg.h    |  2 +-
>  .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     | 24 ++++--
>  4 files changed, 89 insertions(+), 32 deletions(-)
> 
> -- 
> 2.17.1
> 
>
Andrzej Pietrasiewicz Feb. 7, 2020, 11:50 a.m. UTC | #2
Hi All,

<snip>

> I've just tested RK3288, and this series is indeed fixing
> these issues. So for all patches:
> 
> Tested-by: Ezequiel Garcia <ezequiel@collabora.com>

A kind reminder.

The series fixes serious encoding quality problems in both rk3399 and rk3288,
so it seems it should be included. A review is needed, though, at least for
patches 2-4.

Thank you,

Andrzej