JPEG codecs on Exynos4 and Exynos3250 SoCs utilize different number
of planes for storing the raw image data, depending on the format
of the image being processed. For the unused planes a random data
was being written to the related registers. Regardless of the fact
that this seemed not to be harmful, fix the issue for clarity reasons.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Reported-by: Andrzej Pietrasiewicz <andrze...@samsung.com>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 12f7452..fb97c4c 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1842,7 +1842,7 @@ static void exynos4_jpeg_set_img_addr(struct s5p_jpeg_ctx
*ctx)
struct s5p_jpeg *jpeg = ctx->jpeg;
struct s5p_jpeg_fmt *fmt;
struct vb2_buffer *vb;
- struct s5p_jpeg_addr jpeg_addr;
+ struct s5p_jpeg_addr jpeg_addr = {};
u32 pix_size, padding_bytes = 0;
pix_size = ctx->cap_q.w * ctx->cap_q.h;
@@ -1943,7 +1943,7 @@ static void exynos3250_jpeg_set_img_addr(struct
s5p_jpeg_ctx *ctx)
struct s5p_jpeg *jpeg = ctx->jpeg;
struct s5p_jpeg_fmt *fmt;
struct vb2_buffer *vb;
- struct s5p_jpeg_addr jpeg_addr;
+ struct s5p_jpeg_addr jpeg_addr = {};
u32 pix_size;
pix_size = ctx->cap_q.w * ctx->cap_q.h;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
