linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/4] Exynos 5433 jpeg h/w codec support
@ 2015-09-18 14:20 Andrzej Pietrasiewicz
  2015-09-18 14:20 ` [PATCH 1/4] s5p-jpeg: generalize clocks handling Andrzej Pietrasiewicz
                   ` (3 more replies)
  0 siblings, 4 replies; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-18 14:20 UTC (permalink / raw)
  To: linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Andrzej Pietrasiewicz, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

Support for Exynos 5433 to the s5p-jpeg driver.

The series also includes jpeg codec node definition for Device Tree,
but it depends on:

git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
branch v4.3-drop/dt64-samsung which has not made it into 4.3,
but the driver is meant for 4.4.

Rebased onto Mauro's master with the branch mentioned above merged.

This patch series also adds Andrzej Pietrasiewicz and
Jacek Anaszewski as maintainers of drivers/media/platform/s5p-jpeg.

Andrzej is the original author of the driver, and has committed
support for three Exynos chip models and some fixes.
Jacek has committed support for another three and a number of fixes,
and is the second author of the driver.
The code size is now quite large compared to the initial release,
so having it maintained is a good idea and we both have the supported
hardware at hand.

Andrzej Pietrasiewicz (2):
  s5p-jpeg: add support for 5433
  MAINTAINERS: add exynos jpeg codec maintainers

Marek Szyprowski (2):
  s5p-jpeg: generalize clocks handling
  ARM64: dts: exynos5433: add jpeg node

 .../bindings/media/exynos-jpeg-codec.txt           |   3 +-
 MAINTAINERS                                        |   8 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi         |  21 +
 drivers/media/platform/s5p-jpeg/jpeg-core.c        | 444 ++++++++++++++++++---
 drivers/media/platform/s5p-jpeg/jpeg-core.h        |  41 +-
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c  |  80 +++-
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h  |  11 +-
 drivers/media/platform/s5p-jpeg/jpeg-regs.h        |  85 ++--
 8 files changed, 588 insertions(+), 105 deletions(-)

-- 
1.9.1


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH 1/4] s5p-jpeg: generalize clocks handling
  2015-09-18 14:20 [PATCH 0/4] Exynos 5433 jpeg h/w codec support Andrzej Pietrasiewicz
@ 2015-09-18 14:20 ` Andrzej Pietrasiewicz
  2015-09-18 14:29   ` Jacek Anaszewski
  2015-09-18 14:20 ` [PATCH 2/4] s5p-jpeg: add support for 5433 Andrzej Pietrasiewicz
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-18 14:20 UTC (permalink / raw)
  To: linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Andrzej Pietrasiewicz, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

From: Marek Szyprowski <m.szyprowski@samsung.com>

Allow jpeg codec variants declare clocks they need.
Before this patch is applied jpeg-core gets jpeg->sclk
"speculatively": if it is not there, we assume no problem.

This patch eliminates this by explicitly declaring
what clocks are needed for each variant.

This is a preparation for adding Exynos 5433 variant support, which
needs 4 clocks of names not compatible with any previous version of
jpeg hw module.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[Rebase and commit message]
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 66 ++++++++++++++---------------
 drivers/media/platform/s5p-jpeg/jpeg-core.h | 10 +++--
 2 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index bfbf157..03d0904 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2455,7 +2455,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
 {
 	struct s5p_jpeg *jpeg;
 	struct resource *res;
-	int ret;
+	int i, ret;
 
 	/* JPEG IP abstraction struct */
 	jpeg = devm_kzalloc(&pdev->dev, sizeof(struct s5p_jpeg), GFP_KERNEL);
@@ -2490,23 +2490,21 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
 	}
 
 	/* clocks */
-	jpeg->clk = clk_get(&pdev->dev, "jpeg");
-	if (IS_ERR(jpeg->clk)) {
-		dev_err(&pdev->dev, "cannot get clock\n");
-		ret = PTR_ERR(jpeg->clk);
-		return ret;
+	for (i = 0; i < jpeg->variant->num_clocks; i++) {
+		jpeg->clocks[i] = devm_clk_get(&pdev->dev,
+					      jpeg->variant->clk_names[i]);
+		if (IS_ERR(jpeg->clocks[i])) {
+			dev_err(&pdev->dev, "failed to get clock: %s\n",
+				jpeg->variant->clk_names[i]);
+			return PTR_ERR(jpeg->clocks[i]);
+		}
 	}
-	dev_dbg(&pdev->dev, "clock source %p\n", jpeg->clk);
-
-	jpeg->sclk = clk_get(&pdev->dev, "sclk");
-	if (IS_ERR(jpeg->sclk))
-		dev_info(&pdev->dev, "sclk clock not available\n");
 
 	/* v4l2 device */
 	ret = v4l2_device_register(&pdev->dev, &jpeg->v4l2_dev);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to register v4l2 device\n");
-		goto clk_get_rollback;
+		return ret;
 	}
 
 	/* mem2mem device */
@@ -2607,17 +2605,13 @@ m2m_init_rollback:
 device_register_rollback:
 	v4l2_device_unregister(&jpeg->v4l2_dev);
 
-clk_get_rollback:
-	clk_put(jpeg->clk);
-	if (!IS_ERR(jpeg->sclk))
-		clk_put(jpeg->sclk);
-
 	return ret;
 }
 
 static int s5p_jpeg_remove(struct platform_device *pdev)
 {
 	struct s5p_jpeg *jpeg = platform_get_drvdata(pdev);
+	int i;
 
 	pm_runtime_disable(jpeg->dev);
 
@@ -2630,15 +2624,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)
 	v4l2_device_unregister(&jpeg->v4l2_dev);
 
 	if (!pm_runtime_status_suspended(&pdev->dev)) {
-		clk_disable_unprepare(jpeg->clk);
-		if (!IS_ERR(jpeg->sclk))
-			clk_disable_unprepare(jpeg->sclk);
+		for (i = jpeg->variant->num_clocks - 1; i >= 0; i--)
+			clk_disable_unprepare(jpeg->clocks[i]);
 	}
 
-	clk_put(jpeg->clk);
-	if (!IS_ERR(jpeg->sclk))
-		clk_put(jpeg->sclk);
-
 	return 0;
 }
 
@@ -2646,10 +2635,10 @@ static int s5p_jpeg_remove(struct platform_device *pdev)
 static int s5p_jpeg_runtime_suspend(struct device *dev)
 {
 	struct s5p_jpeg *jpeg = dev_get_drvdata(dev);
+	int i;
 
-	clk_disable_unprepare(jpeg->clk);
-	if (!IS_ERR(jpeg->sclk))
-		clk_disable_unprepare(jpeg->sclk);
+	for (i = jpeg->variant->num_clocks - 1; i >= 0; i--)
+		clk_disable_unprepare(jpeg->clocks[i]);
 
 	return 0;
 }
@@ -2658,16 +2647,15 @@ static int s5p_jpeg_runtime_resume(struct device *dev)
 {
 	struct s5p_jpeg *jpeg = dev_get_drvdata(dev);
 	unsigned long flags;
-	int ret;
+	int i, ret;
 
-	ret = clk_prepare_enable(jpeg->clk);
-	if (ret < 0)
-		return ret;
-
-	if (!IS_ERR(jpeg->sclk)) {
-		ret = clk_prepare_enable(jpeg->sclk);
-		if (ret < 0)
+	for (i = 0; i < jpeg->variant->num_clocks; i++) {
+		ret = clk_prepare_enable(jpeg->clocks[i]);
+		if (ret) {
+			while (--i > 0)
+				clk_disable_unprepare(jpeg->clocks[i]);
 			return ret;
+		}
 	}
 
 	spin_lock_irqsave(&jpeg->slock, flags);
@@ -2721,6 +2709,8 @@ static struct s5p_jpeg_variant s5p_jpeg_drvdata = {
 	.jpeg_irq	= s5p_jpeg_irq,
 	.m2m_ops	= &s5p_jpeg_m2m_ops,
 	.fmt_ver_flag	= SJPEG_FMT_FLAG_S5P,
+	.clk_names	= {"jpeg"},
+	.num_clocks	= 1,
 };
 
 static struct s5p_jpeg_variant exynos3250_jpeg_drvdata = {
@@ -2729,6 +2719,8 @@ static struct s5p_jpeg_variant exynos3250_jpeg_drvdata = {
 	.m2m_ops	= &exynos3250_jpeg_m2m_ops,
 	.fmt_ver_flag	= SJPEG_FMT_FLAG_EXYNOS3250,
 	.hw3250_compat	= 1,
+	.clk_names	= {"jpeg", "sclk"},
+	.num_clocks	= 2,
 };
 
 static struct s5p_jpeg_variant exynos4_jpeg_drvdata = {
@@ -2737,6 +2729,8 @@ static struct s5p_jpeg_variant exynos4_jpeg_drvdata = {
 	.m2m_ops	= &exynos4_jpeg_m2m_ops,
 	.fmt_ver_flag	= SJPEG_FMT_FLAG_EXYNOS4,
 	.htbl_reinit	= 1,
+	.clk_names	= {"jpeg"},
+	.num_clocks	= 1,
 };
 
 static struct s5p_jpeg_variant exynos5420_jpeg_drvdata = {
@@ -2746,6 +2740,8 @@ static struct s5p_jpeg_variant exynos5420_jpeg_drvdata = {
 	.fmt_ver_flag	= SJPEG_FMT_FLAG_EXYNOS3250,	/* intentionally 3250 */
 	.hw3250_compat	= 1,
 	.htbl_reinit	= 1,
+	.clk_names	= {"jpeg"},
+	.num_clocks	= 1,
 };
 
 static const struct of_device_id samsung_jpeg_match[] = {
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index 7d9a9ed..d0076fe 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -20,6 +20,8 @@
 
 #define S5P_JPEG_M2M_NAME		"s5p-jpeg"
 
+#define JPEG_MAX_CLOCKS			4
+
 /* JPEG compression quality setting */
 #define S5P_JPEG_COMPR_QUAL_BEST	0
 #define S5P_JPEG_COMPR_QUAL_WORST	3
@@ -100,8 +102,7 @@ enum  exynos4_jpeg_img_quality_level {
  * @m2m_dev:		v4l2 mem2mem device data
  * @regs:		JPEG IP registers mapping
  * @irq:		JPEG IP irq
- * @clk:		JPEG IP clock
- * @sclk:		Exynos3250 JPEG IP special clock
+ * @clocks:		JPEG IP clock(s)
  * @dev:		JPEG IP struct device
  * @alloc_ctx:		videobuf2 memory allocator's context
  * @variant:		driver variant to be used
@@ -121,8 +122,7 @@ struct s5p_jpeg {
 	void __iomem		*regs;
 	unsigned int		irq;
 	enum exynos4_jpeg_result irq_ret;
-	struct clk		*clk;
-	struct clk		*sclk;
+	struct clk		*clocks[JPEG_MAX_CLOCKS];
 	struct device		*dev;
 	void			*alloc_ctx;
 	struct s5p_jpeg_variant *variant;
@@ -136,6 +136,8 @@ struct s5p_jpeg_variant {
 	unsigned int		htbl_reinit:1;
 	struct v4l2_m2m_ops	*m2m_ops;
 	irqreturn_t		(*jpeg_irq)(int irq, void *priv);
+	const char		*clk_names[JPEG_MAX_CLOCKS];
+	int			num_clocks;
 };
 
 /**
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH 2/4] s5p-jpeg: add support for 5433
  2015-09-18 14:20 [PATCH 0/4] Exynos 5433 jpeg h/w codec support Andrzej Pietrasiewicz
  2015-09-18 14:20 ` [PATCH 1/4] s5p-jpeg: generalize clocks handling Andrzej Pietrasiewicz
@ 2015-09-18 14:20 ` Andrzej Pietrasiewicz
  2015-09-18 14:30   ` Jacek Anaszewski
  2015-09-18 14:20 ` [PATCH 3/4] MAINTAINERS: add exynos jpeg codec maintainers Andrzej Pietrasiewicz
  2015-09-18 14:21 ` [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node Andrzej Pietrasiewicz
  3 siblings, 1 reply; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-18 14:20 UTC (permalink / raw)
  To: linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Andrzej Pietrasiewicz, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

JPEG IP found in Exynos5433 is similar to what is in Exynos4, but
there are some subtle differences which this patch takes into account.

The most important difference is in what is processed by the JPEG IP and
what has to be provided to it. In case of 5433 the IP does not parse
Huffman and quantisation tables, so this has to be performed with the CPU
and the majority of the code in this patch does that.

A small but important difference is in what address is passed to the JPEG
IP. In case of 5433 it is the SOS (start of scan) position, which is
natural, because the headers must be parsed elsewhere.

There is also a difference in how the hardware is put to work in
device_run.

Data structures are extended as appropriate to accommodate the above
changes.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
---
 .../bindings/media/exynos-jpeg-codec.txt           |   3 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.c        | 378 +++++++++++++++++++--
 drivers/media/platform/s5p-jpeg/jpeg-core.h        |  31 ++
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c  |  80 ++++-
 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h  |  11 +-
 drivers/media/platform/s5p-jpeg/jpeg-regs.h        |  85 +++--
 6 files changed, 522 insertions(+), 66 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index 4ef4563..38941db 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -4,7 +4,8 @@ Required properties:
 
 - compatible	: should be one of:
 		  "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg",
-		  "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg";
+		  "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg",
+		  "samsung,exynos5433-jpeg";
 - reg		: address and length of the JPEG codec IP register set;
 - interrupts	: specifies the JPEG codec IP interrupt;
 - clock-names   : should contain:
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 03d0904..bc5505a 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -626,6 +626,7 @@ static int s5p_jpeg_to_user_subsampling(struct s5p_jpeg_ctx *ctx)
 			return V4L2_JPEG_CHROMA_SUBSAMPLING_411;
 		return exynos3250_decoded_subsampling[ctx->subsampling];
 	case SJPEG_EXYNOS4:
+	case SJPEG_EXYNOS5433:
 		if (ctx->subsampling > 2)
 			return V4L2_JPEG_CHROMA_SUBSAMPLING_420;
 		return exynos4x12_decoded_subsampling[ctx->subsampling];
@@ -750,6 +751,211 @@ static void exynos4_jpeg_set_huff_tbl(void __iomem *base)
 							ARRAY_SIZE(hactblg0));
 }
 
+static inline int __exynos4_huff_tbl(int class, int id, bool lenval)
+{
+	/*
+	 * class: 0 - DC, 1 - AC
+	 * id: 0 - Y, 1 - Cb/Cr
+	 */
+	if (class) {
+		if (id)
+			return lenval ? EXYNOS4_HUFF_TBL_HACCL :
+				EXYNOS4_HUFF_TBL_HACCV;
+		return lenval ? EXYNOS4_HUFF_TBL_HACLL : EXYNOS4_HUFF_TBL_HACLV;
+
+	}
+	/* class == 0 */
+	if (id)
+		return lenval ? EXYNOS4_HUFF_TBL_HDCCL : EXYNOS4_HUFF_TBL_HDCCV;
+
+	return lenval ? EXYNOS4_HUFF_TBL_HDCLL : EXYNOS4_HUFF_TBL_HDCLV;
+}
+
+static inline int exynos4_huff_tbl_len(int class, int id)
+{
+	return __exynos4_huff_tbl(class, id, true);
+}
+
+static inline int exynos4_huff_tbl_val(int class, int id)
+{
+	return __exynos4_huff_tbl(class, id, false);
+}
+
+static int get_byte(struct s5p_jpeg_buffer *buf);
+static int get_word_be(struct s5p_jpeg_buffer *buf, unsigned int *word);
+static void skip(struct s5p_jpeg_buffer *buf, long len);
+
+static void exynos4_jpeg_parse_decode_h_tbl(struct s5p_jpeg_ctx *ctx)
+{
+	struct s5p_jpeg *jpeg = ctx->jpeg;
+	struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+	struct s5p_jpeg_buffer jpeg_buffer;
+	unsigned int word;
+	int c, x, components;
+
+	jpeg_buffer.size = 2; /* Ls */
+	jpeg_buffer.data =
+		(unsigned long)vb2_plane_vaddr(vb, 0) + ctx->out_q.sos + 2;
+	jpeg_buffer.curr = 0;
+
+	word = 0;
+
+	if (get_word_be(&jpeg_buffer, &word))
+		return;
+	jpeg_buffer.size = (long)word - 2;
+	jpeg_buffer.data += 2;
+	jpeg_buffer.curr = 0;
+
+	components = get_byte(&jpeg_buffer);
+	if (components == -1)
+		return;
+	while (components--) {
+		c = get_byte(&jpeg_buffer);
+		if (c == -1)
+			return;
+		x = get_byte(&jpeg_buffer);
+		if (x == -1)
+			return;
+		exynos4_jpeg_select_dec_h_tbl(jpeg->regs, c,
+					(((x >> 4) & 0x1) << 1) | (x & 0x1));
+	}
+
+}
+
+static void exynos4_jpeg_parse_huff_tbl(struct s5p_jpeg_ctx *ctx)
+{
+	struct s5p_jpeg *jpeg = ctx->jpeg;
+	struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+	struct s5p_jpeg_buffer jpeg_buffer;
+	unsigned int word;
+	int c, i, n, j;
+
+	for (j = 0; j < ctx->out_q.dht.n; ++j) {
+		jpeg_buffer.size = ctx->out_q.dht.len[j];
+		jpeg_buffer.data = (unsigned long)vb2_plane_vaddr(vb, 0) +
+				   ctx->out_q.dht.marker[j];
+		jpeg_buffer.curr = 0;
+
+		word = 0;
+		while (jpeg_buffer.curr < jpeg_buffer.size) {
+			char id, class;
+
+			c = get_byte(&jpeg_buffer);
+			if (c == -1)
+				return;
+			id = c & 0xf;
+			class = (c >> 4) & 0xf;
+			n = 0;
+			for (i = 0; i < 16; ++i) {
+				c = get_byte(&jpeg_buffer);
+				if (c == -1)
+					return;
+				word |= c << ((i % 4) * 8);
+				if ((i + 1) % 4 == 0) {
+					writel(word, jpeg->regs +
+					exynos4_huff_tbl_len(class, id) +
+					(i / 4) * 4);
+					word = 0;
+				}
+				n += c;
+			}
+			word = 0;
+			for (i = 0; i < n; ++i) {
+				c = get_byte(&jpeg_buffer);
+				if (c == -1)
+					return;
+				word |= c << ((i % 4) * 8);
+				if ((i + 1) % 4 == 0) {
+					writel(word, jpeg->regs +
+					exynos4_huff_tbl_val(class, id) +
+					(i / 4) * 4);
+					word = 0;
+				}
+			}
+			if (i % 4) {
+				writel(word, jpeg->regs +
+				exynos4_huff_tbl_val(class, id) + (i / 4) * 4);
+			}
+			word = 0;
+		}
+	}
+}
+
+static void exynos4_jpeg_parse_decode_q_tbl(struct s5p_jpeg_ctx *ctx)
+{
+	struct s5p_jpeg *jpeg = ctx->jpeg;
+	struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+	struct s5p_jpeg_buffer jpeg_buffer;
+	unsigned int word;
+	int c, x, components;
+
+	jpeg_buffer.size = ctx->out_q.sof_len;
+	jpeg_buffer.data =
+		(unsigned long)vb2_plane_vaddr(vb, 0) + ctx->out_q.sof;
+	jpeg_buffer.curr = 0;
+
+	word = 0;
+
+	skip(&jpeg_buffer, 5); /* P, Y, X */
+	components = get_byte(&jpeg_buffer);
+	if (components == -1)
+		return;
+
+	exynos4_jpeg_set_dec_components(jpeg->regs, components);
+
+	while (components--) {
+		c = get_byte(&jpeg_buffer);
+		if (c == -1)
+			return;
+		skip(&jpeg_buffer, 1);
+		x = get_byte(&jpeg_buffer);
+		if (x == -1)
+			return;
+		exynos4_jpeg_select_dec_q_tbl(jpeg->regs, c, x);
+	}
+}
+
+static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx *ctx)
+{
+	struct s5p_jpeg *jpeg = ctx->jpeg;
+	struct vb2_buffer *vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
+	struct s5p_jpeg_buffer jpeg_buffer;
+	unsigned int word;
+	int c, i, j;
+
+	for (j = 0; j < ctx->out_q.dqt.n; ++j) {
+		jpeg_buffer.size = ctx->out_q.dqt.len[j];
+		jpeg_buffer.data = (unsigned long)vb2_plane_vaddr(vb, 0) +
+				   ctx->out_q.dqt.marker[j];
+		jpeg_buffer.curr = 0;
+
+		word = 0;
+		while (jpeg_buffer.size - jpeg_buffer.curr >= 65) {
+			char id;
+
+			c = get_byte(&jpeg_buffer);
+			if (c == -1)
+				return;
+			id = c & 0xf;
+			/* nonzero means extended mode - not supported */
+			if ((c >> 4) & 0xf)
+				return;
+			for (i = 0; i < 64; ++i) {
+				c = get_byte(&jpeg_buffer);
+				if (c == -1)
+					return;
+				word |= c << ((i % 4) * 8);
+				if ((i + 1) % 4 == 0) {
+					writel(word, jpeg->regs +
+					EXYNOS4_QTBL_CONTENT(id) + (i / 4) * 4);
+					word = 0;
+				}
+			}
+			word = 0;
+		}
+	}
+}
+
 /*
  * ============================================================================
  * Device file operations
@@ -894,8 +1100,11 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 			       unsigned long buffer, unsigned long size,
 			       struct s5p_jpeg_ctx *ctx)
 {
-	int c, components = 0, notfound;
-	unsigned int height, width, word, subsampling = 0;
+	int c, components = 0, notfound, n_dht = 0, n_dqt = 0;
+	unsigned int height, width, word, subsampling = 0, sos = 0, sof = 0,
+		     sof_len = 0;
+	unsigned int dht[S5P_JPEG_MAX_MARKER], dht_len[S5P_JPEG_MAX_MARKER],
+		     dqt[S5P_JPEG_MAX_MARKER], dqt_len[S5P_JPEG_MAX_MARKER];
 	long length;
 	struct s5p_jpeg_buffer jpeg_buffer;
 
@@ -904,7 +1113,7 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 	jpeg_buffer.curr = 0;
 
 	notfound = 1;
-	while (notfound) {
+	while (notfound || !sos) {
 		c = get_byte(&jpeg_buffer);
 		if (c == -1)
 			return false;
@@ -923,6 +1132,11 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 		case SOF0:
 			if (get_word_be(&jpeg_buffer, &word))
 				break;
+			length = (long)word - 2;
+			if (!length)
+				return false;
+			sof = jpeg_buffer.curr; /* after 0xffc0 */
+			sof_len = length;
 			if (get_byte(&jpeg_buffer) == -1)
 				break;
 			if (get_word_be(&jpeg_buffer, &height))
@@ -932,7 +1146,6 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 			components = get_byte(&jpeg_buffer);
 			if (components == -1)
 				break;
-			notfound = 0;
 
 			if (components == 1) {
 				subsampling = 0x33;
@@ -941,8 +1154,40 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 				subsampling = get_byte(&jpeg_buffer);
 				skip(&jpeg_buffer, 1);
 			}
-
+			if (components > 3)
+				return false;
 			skip(&jpeg_buffer, components * 2);
+			notfound = 0;
+			break;
+
+		case DQT:
+			if (get_word_be(&jpeg_buffer, &word))
+				break;
+			length = (long)word - 2;
+			if (!length)
+				return false;
+			if (n_dqt >= S5P_JPEG_MAX_MARKER)
+				return false;
+			dqt[n_dqt] = jpeg_buffer.curr; /* after 0xffdb */
+			dqt_len[n_dqt++] = length;
+			skip(&jpeg_buffer, length);
+			break;
+
+		case DHT:
+			if (get_word_be(&jpeg_buffer, &word))
+				break;
+			length = (long)word - 2;
+			if (!length)
+				return false;
+			if (n_dht >= S5P_JPEG_MAX_MARKER)
+				return false;
+			dht[n_dht] = jpeg_buffer.curr; /* after 0xffc4 */
+			dht_len[n_dht++] = length;
+			skip(&jpeg_buffer, length);
+			break;
+
+		case SOS:
+			sos = jpeg_buffer.curr - 2; /* 0xffda */
 			break;
 
 		/* skip payload-less markers */
@@ -963,7 +1208,20 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 	}
 	result->w = width;
 	result->h = height;
-	result->size = components;
+	result->sos = sos;
+	result->dht.n = n_dht;
+	while (n_dht--) {
+		result->dht.marker[n_dht] = dht[n_dht];
+		result->dht.len[n_dht] = dht_len[n_dht];
+	}
+	result->dqt.n = n_dqt;
+	while (n_dqt--) {
+		result->dqt.marker[n_dqt] = dqt[n_dqt];
+		result->dqt.len[n_dqt] = dqt_len[n_dqt];
+	}
+	result->sof = sof;
+	result->sof_len = sof_len;
+	result->size = result->components = components;
 
 	switch (subsampling) {
 	case 0x11:
@@ -982,7 +1240,7 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data *result,
 		return false;
 	}
 
-	return !notfound;
+	return !notfound && sos;
 }
 
 static int s5p_jpeg_querycap(struct file *file, void *priv,
@@ -1226,8 +1484,7 @@ static int s5p_jpeg_try_fmt_vid_cap(struct file *file, void *priv,
 		return -EINVAL;
 	}
 
-	if ((ctx->jpeg->variant->version != SJPEG_EXYNOS4) ||
-	    (ctx->mode != S5P_JPEG_DECODE))
+	if (!ctx->jpeg->variant->hw_ex4_compat || ctx->mode != S5P_JPEG_DECODE)
 		goto exit;
 
 	/*
@@ -1350,7 +1607,7 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct, struct v4l2_format *f)
 		 * the JPEG_IMAGE_SIZE register. In order to avoid sysmmu
 		 * page fault calculate proper buffer size in such a case.
 		 */
-		if (ct->jpeg->variant->version == SJPEG_EXYNOS4 &&
+		if (ct->jpeg->variant->hw_ex4_compat &&
 		    f_type == FMT_TYPE_OUTPUT && ct->mode == S5P_JPEG_ENCODE)
 			q_data->size = exynos4_jpeg_get_output_buffer_size(ct,
 							f,
@@ -1889,9 +2146,36 @@ static void exynos4_jpeg_set_jpeg_addr(struct s5p_jpeg_ctx *ctx)
 		vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 
 	jpeg_addr = vb2_dma_contig_plane_dma_addr(vb, 0);
+	if (jpeg->variant->version == SJPEG_EXYNOS5433 &&
+	    ctx->mode == S5P_JPEG_DECODE)
+		jpeg_addr += ctx->out_q.sos;
 	exynos4_jpeg_set_stream_buf_address(jpeg->regs, jpeg_addr);
 }
 
+static inline void exynos4_jpeg_set_img_fmt(void __iomem *base,
+					    unsigned int img_fmt)
+{
+	__exynos4_jpeg_set_img_fmt(base, img_fmt, SJPEG_EXYNOS4);
+}
+
+static inline void exynos5433_jpeg_set_img_fmt(void __iomem *base,
+					       unsigned int img_fmt)
+{
+	__exynos4_jpeg_set_img_fmt(base, img_fmt, SJPEG_EXYNOS5433);
+}
+
+static inline void exynos4_jpeg_set_enc_out_fmt(void __iomem *base,
+						unsigned int out_fmt)
+{
+	__exynos4_jpeg_set_enc_out_fmt(base, out_fmt, SJPEG_EXYNOS4);
+}
+
+static inline void exynos5433_jpeg_set_enc_out_fmt(void __iomem *base,
+						   unsigned int out_fmt)
+{
+	__exynos4_jpeg_set_enc_out_fmt(base, out_fmt, SJPEG_EXYNOS5433);
+}
+
 static void exynos4_jpeg_device_run(void *priv)
 {
 	struct s5p_jpeg_ctx *ctx = priv;
@@ -1899,11 +2183,11 @@ static void exynos4_jpeg_device_run(void *priv)
 	unsigned int bitstream_size;
 	unsigned long flags;
 
-	spin_lock_irqsave(&ctx->jpeg->slock, flags);
+	spin_lock_irqsave(&jpeg->slock, flags);
 
 	if (ctx->mode == S5P_JPEG_ENCODE) {
 		exynos4_jpeg_sw_reset(jpeg->regs);
-		exynos4_jpeg_set_interrupt(jpeg->regs);
+		exynos4_jpeg_set_interrupt(jpeg->regs, jpeg->variant->version);
 		exynos4_jpeg_set_huf_table_enable(jpeg->regs, 1);
 
 		exynos4_jpeg_set_huff_tbl(jpeg->regs);
@@ -1920,27 +2204,56 @@ static void exynos4_jpeg_device_run(void *priv)
 		exynos4_jpeg_set_stream_size(jpeg->regs, ctx->cap_q.w,
 							ctx->cap_q.h);
 
-		exynos4_jpeg_set_enc_out_fmt(jpeg->regs, ctx->subsampling);
-		exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->out_q.fmt->fourcc);
+		if (ctx->jpeg->variant->version == SJPEG_EXYNOS4) {
+			exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
+						     ctx->subsampling);
+			exynos4_jpeg_set_img_fmt(jpeg->regs,
+						 ctx->out_q.fmt->fourcc);
+		} else {
+			exynos5433_jpeg_set_enc_out_fmt(jpeg->regs,
+							ctx->subsampling);
+			exynos5433_jpeg_set_img_fmt(jpeg->regs,
+						    ctx->out_q.fmt->fourcc);
+		}
 		exynos4_jpeg_set_img_addr(ctx);
 		exynos4_jpeg_set_jpeg_addr(ctx);
 		exynos4_jpeg_set_encode_hoff_cnt(jpeg->regs,
 							ctx->out_q.fmt->fourcc);
 	} else {
 		exynos4_jpeg_sw_reset(jpeg->regs);
-		exynos4_jpeg_set_interrupt(jpeg->regs);
+		exynos4_jpeg_set_interrupt(jpeg->regs,
+					   jpeg->variant->version);
 		exynos4_jpeg_set_img_addr(ctx);
 		exynos4_jpeg_set_jpeg_addr(ctx);
-		exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->cap_q.fmt->fourcc);
 
-		bitstream_size = DIV_ROUND_UP(ctx->out_q.size, 32);
+		if (jpeg->variant->version == SJPEG_EXYNOS5433) {
+			exynos4_jpeg_parse_huff_tbl(ctx);
+			exynos4_jpeg_parse_decode_h_tbl(ctx);
+
+			exynos4_jpeg_parse_q_tbl(ctx);
+			exynos4_jpeg_parse_decode_q_tbl(ctx);
+
+			exynos4_jpeg_set_huf_table_enable(jpeg->regs, 1);
+
+			exynos4_jpeg_set_stream_size(jpeg->regs, ctx->cap_q.w,
+					ctx->cap_q.h);
+			exynos5433_jpeg_set_enc_out_fmt(jpeg->regs,
+							ctx->subsampling);
+			exynos5433_jpeg_set_img_fmt(jpeg->regs,
+						    ctx->cap_q.fmt->fourcc);
+			bitstream_size = DIV_ROUND_UP(ctx->out_q.size, 16);
+		} else {
+			exynos4_jpeg_set_img_fmt(jpeg->regs,
+						 ctx->cap_q.fmt->fourcc);
+			bitstream_size = DIV_ROUND_UP(ctx->out_q.size, 32);
+		}
 
 		exynos4_jpeg_set_dec_bitstream_size(jpeg->regs, bitstream_size);
 	}
 
 	exynos4_jpeg_set_enc_dec_mode(jpeg->regs, ctx->mode);
 
-	spin_unlock_irqrestore(&ctx->jpeg->slock, flags);
+	spin_unlock_irqrestore(&jpeg->slock, flags);
 }
 
 static void exynos3250_jpeg_set_img_addr(struct s5p_jpeg_ctx *ctx)
@@ -2187,6 +2500,17 @@ static void s5p_jpeg_buf_queue(struct vb2_buffer *vb)
 		q_data = &ctx->out_q;
 		q_data->w = tmp.w;
 		q_data->h = tmp.h;
+		q_data->sos = tmp.sos;
+		memcpy(q_data->dht.marker, tmp.dht.marker,
+		       sizeof(tmp.dht.marker));
+		memcpy(q_data->dht.len, tmp.dht.len, sizeof(tmp.dht.len));
+		q_data->dht.n = tmp.dht.n;
+		memcpy(q_data->dqt.marker, tmp.dqt.marker,
+		       sizeof(tmp.dqt.marker));
+		memcpy(q_data->dqt.len, tmp.dqt.len, sizeof(tmp.dqt.len));
+		q_data->dqt.n = tmp.dqt.n;
+		q_data->sof = tmp.sof;
+		q_data->sof_len = tmp.sof_len;
 
 		q_data = &ctx->cap_q;
 		q_data->w = tmp.w;
@@ -2373,7 +2697,8 @@ static irqreturn_t exynos4_jpeg_irq(int irq, void *priv)
 	}
 
 	v4l2_m2m_job_finish(jpeg->m2m_dev, curr_ctx->fh.m2m_ctx);
-	curr_ctx->subsampling = exynos4_jpeg_get_frame_fmt(jpeg->regs);
+	if (jpeg->variant->version == SJPEG_EXYNOS4)
+		curr_ctx->subsampling = exynos4_jpeg_get_frame_fmt(jpeg->regs);
 
 	spin_unlock(&jpeg->slock);
 	return IRQ_HANDLED;
@@ -2731,6 +3056,7 @@ static struct s5p_jpeg_variant exynos4_jpeg_drvdata = {
 	.htbl_reinit	= 1,
 	.clk_names	= {"jpeg"},
 	.num_clocks	= 1,
+	.hw_ex4_compat	= 1,
 };
 
 static struct s5p_jpeg_variant exynos5420_jpeg_drvdata = {
@@ -2744,6 +3070,17 @@ static struct s5p_jpeg_variant exynos5420_jpeg_drvdata = {
 	.num_clocks	= 1,
 };
 
+static struct s5p_jpeg_variant exynos5433_jpeg_drvdata = {
+	.version	= SJPEG_EXYNOS5433,
+	.jpeg_irq	= exynos4_jpeg_irq,
+	.m2m_ops	= &exynos4_jpeg_m2m_ops,
+	.fmt_ver_flag	= SJPEG_FMT_FLAG_EXYNOS4,
+	.htbl_reinit	= 1,
+	.clk_names	= {"pclk", "aclk", "aclk_xiu", "sclk"},
+	.num_clocks	= 4,
+	.hw_ex4_compat	= 1,
+};
+
 static const struct of_device_id samsung_jpeg_match[] = {
 	{
 		.compatible = "samsung,s5pv210-jpeg",
@@ -2760,6 +3097,9 @@ static const struct of_device_id samsung_jpeg_match[] = {
 	}, {
 		.compatible = "samsung,exynos5420-jpeg",
 		.data = &exynos5420_jpeg_drvdata,
+	}, {
+		.compatible = "samsung,exynos5433-jpeg",
+		.data = &exynos5433_jpeg_drvdata,
 	},
 	{},
 };
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index d0076fe..9b1db09 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -42,9 +42,12 @@
 /* a selection of JPEG markers */
 #define TEM				0x01
 #define SOF0				0xc0
+#define DHT				0xc4
 #define RST				0xd0
 #define SOI				0xd8
 #define EOI				0xd9
+#define	SOS				0xda
+#define DQT				0xdb
 #define DHP				0xde
 
 /* Flags that indicate a format can be used for capture/output */
@@ -68,12 +71,15 @@
 #define SJPEG_SUBSAMPLING_422	0x21
 #define SJPEG_SUBSAMPLING_420	0x22
 
+#define S5P_JPEG_MAX_MARKER	4
+
 /* Version numbers */
 enum sjpeg_version {
 	SJPEG_S5P,
 	SJPEG_EXYNOS3250,
 	SJPEG_EXYNOS4,
 	SJPEG_EXYNOS5420,
+	SJPEG_EXYNOS5433,
 };
 
 enum exynos4_jpeg_result {
@@ -134,6 +140,7 @@ struct s5p_jpeg_variant {
 	unsigned int		fmt_ver_flag;
 	unsigned int		hw3250_compat:1;
 	unsigned int		htbl_reinit:1;
+	unsigned int		hw_ex4_compat:1;
 	struct v4l2_m2m_ops	*m2m_ops;
 	irqreturn_t		(*jpeg_irq)(int irq, void *priv);
 	const char		*clk_names[JPEG_MAX_CLOCKS];
@@ -163,16 +170,40 @@ struct s5p_jpeg_fmt {
 };
 
 /**
+ * s5p_jpeg_marker - collection of markers from jpeg header
+ * @marker:	markers' positions relative to the buffer beginning
+ * @len:	markers' payload lengths (without length field)
+ * @n:		number of markers in collection
+ */
+struct s5p_jpeg_marker {
+	u32	marker[S5P_JPEG_MAX_MARKER];
+	u32	len[S5P_JPEG_MAX_MARKER];
+	u32	n;
+};
+
+/**
  * s5p_jpeg_q_data - parameters of one queue
  * @fmt:	driver-specific format of this queue
  * @w:		image width
  * @h:		image height
+ * @sos:	SOS marker's position relative to the buffer beginning
+ * @dht:	DHT markers' positions relative to the buffer beginning
+ * @dqt:	DQT markers' positions relative to the buffer beginning
+ * @sof:	SOF0 marker's postition relative to the buffer beginning
+ * @sof_len:	SOF0 marker's payload length (without length field itself)
+ * @components:	number of image components
  * @size:	image buffer size in bytes
  */
 struct s5p_jpeg_q_data {
 	struct s5p_jpeg_fmt	*fmt;
 	u32			w;
 	u32			h;
+	u32			sos;
+	struct s5p_jpeg_marker	dht;
+	struct s5p_jpeg_marker	dqt;
+	u32			sof;
+	u32			sof_len;
+	u32			components;
 	u32			size;
 };
 
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index ab6d6f43..0912d0a 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -45,9 +45,20 @@ void exynos4_jpeg_set_enc_dec_mode(void __iomem *base, unsigned int mode)
 	}
 }
 
-void exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt)
+void __exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt,
+				unsigned int version)
 {
 	unsigned int reg;
+	unsigned int exynos4_swap_chroma_cbcr;
+	unsigned int exynos4_swap_chroma_crcb;
+
+	if (version == SJPEG_EXYNOS4) {
+		exynos4_swap_chroma_cbcr = EXYNOS4_SWAP_CHROMA_CBCR;
+		exynos4_swap_chroma_crcb = EXYNOS4_SWAP_CHROMA_CRCB;
+	} else {
+		exynos4_swap_chroma_cbcr = EXYNOS5433_SWAP_CHROMA_CBCR;
+		exynos4_swap_chroma_crcb = EXYNOS5433_SWAP_CHROMA_CRCB;
+	}
 
 	reg = readl(base + EXYNOS4_IMG_FMT_REG) &
 			EXYNOS4_ENC_IN_FMT_MASK; /* clear except enc format */
@@ -67,48 +78,48 @@ void exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt)
 	case V4L2_PIX_FMT_NV24:
 		reg = reg | EXYNOS4_ENC_YUV_444_IMG |
 				EXYNOS4_YUV_444_IP_YUV_444_2P_IMG |
-				EXYNOS4_SWAP_CHROMA_CBCR;
+				exynos4_swap_chroma_cbcr;
 		break;
 	case V4L2_PIX_FMT_NV42:
 		reg = reg | EXYNOS4_ENC_YUV_444_IMG |
 				EXYNOS4_YUV_444_IP_YUV_444_2P_IMG |
-				EXYNOS4_SWAP_CHROMA_CRCB;
+				exynos4_swap_chroma_crcb;
 		break;
 	case V4L2_PIX_FMT_YUYV:
 		reg = reg | EXYNOS4_DEC_YUV_422_IMG |
 				EXYNOS4_YUV_422_IP_YUV_422_1P_IMG |
-				EXYNOS4_SWAP_CHROMA_CBCR;
+				exynos4_swap_chroma_cbcr;
 		break;
 
 	case V4L2_PIX_FMT_YVYU:
 		reg = reg | EXYNOS4_DEC_YUV_422_IMG |
 				EXYNOS4_YUV_422_IP_YUV_422_1P_IMG |
-				EXYNOS4_SWAP_CHROMA_CRCB;
+				exynos4_swap_chroma_crcb;
 		break;
 	case V4L2_PIX_FMT_NV16:
 		reg = reg | EXYNOS4_DEC_YUV_422_IMG |
 				EXYNOS4_YUV_422_IP_YUV_422_2P_IMG |
-				EXYNOS4_SWAP_CHROMA_CBCR;
+				exynos4_swap_chroma_cbcr;
 		break;
 	case V4L2_PIX_FMT_NV61:
 		reg = reg | EXYNOS4_DEC_YUV_422_IMG |
 				EXYNOS4_YUV_422_IP_YUV_422_2P_IMG |
-				EXYNOS4_SWAP_CHROMA_CRCB;
+				exynos4_swap_chroma_crcb;
 		break;
 	case V4L2_PIX_FMT_NV12:
 		reg = reg | EXYNOS4_DEC_YUV_420_IMG |
 				EXYNOS4_YUV_420_IP_YUV_420_2P_IMG |
-				EXYNOS4_SWAP_CHROMA_CBCR;
+				exynos4_swap_chroma_cbcr;
 		break;
 	case V4L2_PIX_FMT_NV21:
 		reg = reg | EXYNOS4_DEC_YUV_420_IMG |
 				EXYNOS4_YUV_420_IP_YUV_420_2P_IMG |
-				EXYNOS4_SWAP_CHROMA_CRCB;
+				exynos4_swap_chroma_crcb;
 		break;
 	case V4L2_PIX_FMT_YUV420:
 		reg = reg | EXYNOS4_DEC_YUV_420_IMG |
 				EXYNOS4_YUV_420_IP_YUV_420_3P_IMG |
-				EXYNOS4_SWAP_CHROMA_CBCR;
+				exynos4_swap_chroma_cbcr;
 		break;
 	default:
 		break;
@@ -118,12 +129,14 @@ void exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt)
 	writel(reg, base + EXYNOS4_IMG_FMT_REG);
 }
 
-void exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt)
+void __exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt,
+				    unsigned int version)
 {
 	unsigned int reg;
 
 	reg = readl(base + EXYNOS4_IMG_FMT_REG) &
-			~EXYNOS4_ENC_FMT_MASK; /* clear enc format */
+			~(version == SJPEG_EXYNOS4 ? EXYNOS4_ENC_FMT_MASK :
+			  EXYNOS5433_ENC_FMT_MASK); /* clear enc format */
 
 	switch (out_fmt) {
 	case V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY:
@@ -149,9 +162,18 @@ void exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt)
 	writel(reg, base + EXYNOS4_IMG_FMT_REG);
 }
 
-void exynos4_jpeg_set_interrupt(void __iomem *base)
+void exynos4_jpeg_set_interrupt(void __iomem *base, unsigned int version)
 {
-	writel(EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+	unsigned int reg;
+
+	if (version == SJPEG_EXYNOS4) {
+		reg = readl(base + EXYNOS4_INT_EN_REG) & ~EXYNOS4_INT_EN_MASK;
+		writel(reg | EXYNOS4_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+	} else {
+		reg = readl(base + EXYNOS4_INT_EN_REG) &
+							~EXYNOS5433_INT_EN_MASK;
+		writel(reg | EXYNOS5433_INT_EN_ALL, base + EXYNOS4_INT_EN_REG);
+	}
 }
 
 unsigned int exynos4_jpeg_get_int_status(void __iomem *base)
@@ -234,6 +256,36 @@ void exynos4_jpeg_set_encode_tbl_select(void __iomem *base,
 	writel(reg, base + EXYNOS4_TBL_SEL_REG);
 }
 
+void exynos4_jpeg_set_dec_components(void __iomem *base, int n)
+{
+	unsigned int	reg;
+
+	reg = readl(base + EXYNOS4_TBL_SEL_REG);
+
+	reg |= EXYNOS4_NF(n);
+	writel(reg, base + EXYNOS4_TBL_SEL_REG);
+}
+
+void exynos4_jpeg_select_dec_q_tbl(void __iomem *base, char c, char x)
+{
+	unsigned int	reg;
+
+	reg = readl(base + EXYNOS4_TBL_SEL_REG);
+
+	reg |= EXYNOS4_Q_TBL_COMP(c, x);
+	writel(reg, base + EXYNOS4_TBL_SEL_REG);
+}
+
+void exynos4_jpeg_select_dec_h_tbl(void __iomem *base, char c, char x)
+{
+	unsigned int	reg;
+
+	reg = readl(base + EXYNOS4_TBL_SEL_REG);
+
+	reg |= EXYNOS4_HUFF_TBL_COMP(c, x);
+	writel(reg, base + EXYNOS4_TBL_SEL_REG);
+}
+
 void exynos4_jpeg_set_encode_hoff_cnt(void __iomem *base, unsigned int fmt)
 {
 	if (fmt == V4L2_PIX_FMT_GREY)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h
index c228d28..cf6ec05 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h
@@ -15,10 +15,12 @@
 
 void exynos4_jpeg_sw_reset(void __iomem *base);
 void exynos4_jpeg_set_enc_dec_mode(void __iomem *base, unsigned int mode);
-void exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt);
-void exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt);
+void __exynos4_jpeg_set_img_fmt(void __iomem *base, unsigned int img_fmt,
+				unsigned int version);
+void __exynos4_jpeg_set_enc_out_fmt(void __iomem *base, unsigned int out_fmt,
+				    unsigned int version);
 void exynos4_jpeg_set_enc_tbl(void __iomem *base);
-void exynos4_jpeg_set_interrupt(void __iomem *base);
+void exynos4_jpeg_set_interrupt(void __iomem *base, unsigned int version);
 unsigned int exynos4_jpeg_get_int_status(void __iomem *base);
 void exynos4_jpeg_set_huf_table_enable(void __iomem *base, int value);
 void exynos4_jpeg_set_sys_int_enable(void __iomem *base, int value);
@@ -30,6 +32,9 @@ void exynos4_jpeg_set_frame_buf_address(void __iomem *base,
 				struct s5p_jpeg_addr *jpeg_addr);
 void exynos4_jpeg_set_encode_tbl_select(void __iomem *base,
 		enum exynos4_jpeg_img_quality_level level);
+void exynos4_jpeg_set_dec_components(void __iomem *base, int n);
+void exynos4_jpeg_select_dec_q_tbl(void __iomem *base, char c, char x);
+void exynos4_jpeg_select_dec_h_tbl(void __iomem *base, char c, char x);
 void exynos4_jpeg_set_encode_hoff_cnt(void __iomem *base, unsigned int fmt);
 void exynos4_jpeg_set_dec_bitstream_size(void __iomem *base, unsigned int size);
 unsigned int exynos4_jpeg_get_stream_size(void __iomem *base);
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-regs.h b/drivers/media/platform/s5p-jpeg/jpeg-regs.h
index 050fc44..1870400 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-regs.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-regs.h
@@ -231,12 +231,14 @@
 
 /* JPEG INT Register bit */
 #define EXYNOS4_INT_EN_MASK		(0x1f << 0)
+#define EXYNOS5433_INT_EN_MASK		(0x1ff << 0)
 #define EXYNOS4_PROT_ERR_INT_EN		(1 << 0)
 #define EXYNOS4_IMG_COMPLETION_INT_EN	(1 << 1)
 #define EXYNOS4_DEC_INVALID_FORMAT_EN	(1 << 2)
 #define EXYNOS4_MULTI_SCAN_ERROR_EN	(1 << 3)
 #define EXYNOS4_FRAME_ERR_EN		(1 << 4)
 #define EXYNOS4_INT_EN_ALL		(0x1f << 0)
+#define EXYNOS5433_INT_EN_ALL		(0x1b6 << 0)
 
 #define EXYNOS4_MOD_REG_PROC_ENC	(0 << 3)
 #define EXYNOS4_MOD_REG_PROC_DEC	(1 << 3)
@@ -296,6 +298,8 @@
 
 #define EXYNOS4_ENC_FMT_SHIFT			24
 #define EXYNOS4_ENC_FMT_MASK			(3 << EXYNOS4_ENC_FMT_SHIFT)
+#define EXYNOS5433_ENC_FMT_MASK			(7 << EXYNOS4_ENC_FMT_SHIFT)
+
 #define EXYNOS4_ENC_FMT_GRAY			(0 << EXYNOS4_ENC_FMT_SHIFT)
 #define EXYNOS4_ENC_FMT_YUV_444			(1 << EXYNOS4_ENC_FMT_SHIFT)
 #define EXYNOS4_ENC_FMT_YUV_422			(2 << EXYNOS4_ENC_FMT_SHIFT)
@@ -305,6 +309,8 @@
 
 #define EXYNOS4_SWAP_CHROMA_CRCB		(1 << 26)
 #define EXYNOS4_SWAP_CHROMA_CBCR		(0 << 26)
+#define EXYNOS5433_SWAP_CHROMA_CRCB		(1 << 27)
+#define EXYNOS5433_SWAP_CHROMA_CBCR		(0 << 27)
 
 /* JPEG HUFF count Register bit */
 #define EXYNOS4_HUFF_COUNT_MASK			0xffff
@@ -316,35 +322,56 @@
 #define EXYNOS4_DECODED_IMG_FMT_MASK		0x3
 
 /* JPEG TBL SEL Register bit */
-#define EXYNOS4_Q_TBL_COMP1_0		(0 << 0)
-#define EXYNOS4_Q_TBL_COMP1_1		(1 << 0)
-#define EXYNOS4_Q_TBL_COMP1_2		(2 << 0)
-#define EXYNOS4_Q_TBL_COMP1_3		(3 << 0)
-
-#define EXYNOS4_Q_TBL_COMP2_0		(0 << 2)
-#define EXYNOS4_Q_TBL_COMP2_1		(1 << 2)
-#define EXYNOS4_Q_TBL_COMP2_2		(2 << 2)
-#define EXYNOS4_Q_TBL_COMP2_3		(3 << 2)
-
-#define EXYNOS4_Q_TBL_COMP3_0		(0 << 4)
-#define EXYNOS4_Q_TBL_COMP3_1		(1 << 4)
-#define EXYNOS4_Q_TBL_COMP3_2		(2 << 4)
-#define EXYNOS4_Q_TBL_COMP3_3		(3 << 4)
-
-#define EXYNOS4_HUFF_TBL_COMP1_AC_0_DC_0	(0 << 6)
-#define EXYNOS4_HUFF_TBL_COMP1_AC_0_DC_1	(1 << 6)
-#define EXYNOS4_HUFF_TBL_COMP1_AC_1_DC_0	(2 << 6)
-#define EXYNOS4_HUFF_TBL_COMP1_AC_1_DC_1	(3 << 6)
-
-#define EXYNOS4_HUFF_TBL_COMP2_AC_0_DC_0	(0 << 8)
-#define EXYNOS4_HUFF_TBL_COMP2_AC_0_DC_1	(1 << 8)
-#define EXYNOS4_HUFF_TBL_COMP2_AC_1_DC_0	(2 << 8)
-#define EXYNOS4_HUFF_TBL_COMP2_AC_1_DC_1	(3 << 8)
-
-#define EXYNOS4_HUFF_TBL_COMP3_AC_0_DC_0	(0 << 10)
-#define EXYNOS4_HUFF_TBL_COMP3_AC_0_DC_1	(1 << 10)
-#define EXYNOS4_HUFF_TBL_COMP3_AC_1_DC_0	(2 << 10)
-#define EXYNOS4_HUFF_TBL_COMP3_AC_1_DC_1	(3 << 10)
+#define EXYNOS4_Q_TBL_COMP(c, n)	((n) << (((c) - 1) << 1))
+
+#define EXYNOS4_Q_TBL_COMP1_0		EXYNOS4_Q_TBL_COMP(1, 0)
+#define EXYNOS4_Q_TBL_COMP1_1		EXYNOS4_Q_TBL_COMP(1, 1)
+#define EXYNOS4_Q_TBL_COMP1_2		EXYNOS4_Q_TBL_COMP(1, 2)
+#define EXYNOS4_Q_TBL_COMP1_3		EXYNOS4_Q_TBL_COMP(1, 3)
+
+#define EXYNOS4_Q_TBL_COMP2_0		EXYNOS4_Q_TBL_COMP(2, 0)
+#define EXYNOS4_Q_TBL_COMP2_1		EXYNOS4_Q_TBL_COMP(2, 1)
+#define EXYNOS4_Q_TBL_COMP2_2		EXYNOS4_Q_TBL_COMP(2, 2)
+#define EXYNOS4_Q_TBL_COMP2_3		EXYNOS4_Q_TBL_COMP(2, 3)
+
+#define EXYNOS4_Q_TBL_COMP3_0		EXYNOS4_Q_TBL_COMP(3, 0)
+#define EXYNOS4_Q_TBL_COMP3_1		EXYNOS4_Q_TBL_COMP(3, 1)
+#define EXYNOS4_Q_TBL_COMP3_2		EXYNOS4_Q_TBL_COMP(3, 2)
+#define EXYNOS4_Q_TBL_COMP3_3		EXYNOS4_Q_TBL_COMP(3, 3)
+
+#define EXYNOS4_HUFF_TBL_COMP(c, n)	((n) << ((((c) - 1) << 1) + 6))
+
+#define EXYNOS4_HUFF_TBL_COMP1_AC_0_DC_0	\
+	EXYNOS4_HUFF_TBL_COMP(1, 0)
+#define EXYNOS4_HUFF_TBL_COMP1_AC_0_DC_1	\
+	EXYNOS4_HUFF_TBL_COMP(1, 1)
+#define EXYNOS4_HUFF_TBL_COMP1_AC_1_DC_0	\
+	EXYNOS4_HUFF_TBL_COMP(1, 2)
+#define EXYNOS4_HUFF_TBL_COMP1_AC_1_DC_1	\
+	EXYNOS4_HUFF_TBL_COMP(1, 3)
+
+#define EXYNOS4_HUFF_TBL_COMP2_AC_0_DC_0	\
+	EXYNOS4_HUFF_TBL_COMP(2, 0)
+#define EXYNOS4_HUFF_TBL_COMP2_AC_0_DC_1	\
+	EXYNOS4_HUFF_TBL_COMP(2, 1)
+#define EXYNOS4_HUFF_TBL_COMP2_AC_1_DC_0	\
+	EXYNOS4_HUFF_TBL_COMP(2, 2)
+#define EXYNOS4_HUFF_TBL_COMP2_AC_1_DC_1	\
+	EXYNOS4_HUFF_TBL_COMP(2, 3)
+
+#define EXYNOS4_HUFF_TBL_COMP3_AC_0_DC_0	\
+	EXYNOS4_HUFF_TBL_COMP(3, 0)
+#define EXYNOS4_HUFF_TBL_COMP3_AC_0_DC_1	\
+	EXYNOS4_HUFF_TBL_COMP(3, 1)
+#define EXYNOS4_HUFF_TBL_COMP3_AC_1_DC_0	\
+	EXYNOS4_HUFF_TBL_COMP(3, 2)
+#define EXYNOS4_HUFF_TBL_COMP3_AC_1_DC_1	\
+	EXYNOS4_HUFF_TBL_COMP(3, 3)
+
+#define EXYNOS4_NF_SHIFT			16
+#define EXYNOS4_NF_MASK				0xff
+#define EXYNOS4_NF(x)				\
+	(((x) << EXYNOS4_NF_SHIFT) & EXYNOS4_NF_MASK)
 
 /* JPEG quantizer table register */
 #define EXYNOS4_QTBL_CONTENT(n)	(0x100 + (n) * 0x40)
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH 3/4] MAINTAINERS: add exynos jpeg codec maintainers
  2015-09-18 14:20 [PATCH 0/4] Exynos 5433 jpeg h/w codec support Andrzej Pietrasiewicz
  2015-09-18 14:20 ` [PATCH 1/4] s5p-jpeg: generalize clocks handling Andrzej Pietrasiewicz
  2015-09-18 14:20 ` [PATCH 2/4] s5p-jpeg: add support for 5433 Andrzej Pietrasiewicz
@ 2015-09-18 14:20 ` Andrzej Pietrasiewicz
  2015-09-18 14:30   ` Jacek Anaszewski
  2015-09-18 14:21 ` [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node Andrzej Pietrasiewicz
  3 siblings, 1 reply; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-18 14:20 UTC (permalink / raw)
  To: linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Andrzej Pietrasiewicz, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

Add Andrzej Pietrasiewicz and Jacek Anaszewski
as maintainers of drivers/media/platform/s5p-jpeg.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..ee9240b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1452,6 +1452,14 @@ L:	linux-media@vger.kernel.org
 S:	Maintained
 F:	drivers/media/platform/s5p-tv/
 
+ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
+M:	Andrzej Pietrasiewicz <andrzej.p@samsung.com>
+M:	Jacek Anaszewski <j.anaszewski@samsung.com>
+L:	linux-arm-kernel@lists.infradead.org
+L:	linux-media@vger.kernel.org
+S:	Maintained
+F:	drivers/media/platform/s5p-jpeg/
+
 ARM/SHMOBILE ARM ARCHITECTURE
 M:	Simon Horman <horms@verge.net.au>
 M:	Magnus Damm <magnus.damm@gmail.com>
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-18 14:20 [PATCH 0/4] Exynos 5433 jpeg h/w codec support Andrzej Pietrasiewicz
                   ` (2 preceding siblings ...)
  2015-09-18 14:20 ` [PATCH 3/4] MAINTAINERS: add exynos jpeg codec maintainers Andrzej Pietrasiewicz
@ 2015-09-18 14:21 ` Andrzej Pietrasiewicz
  2015-09-21  9:50   ` Hans Verkuil
  3 siblings, 1 reply; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-18 14:21 UTC (permalink / raw)
  To: linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Andrzej Pietrasiewicz, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

From: Marek Szyprowski <m.szyprowski@samsung.com>

Add Exynos 5433 jpeg h/w codec node.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 59e21b6..5cb489f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -916,6 +916,27 @@
 			io-channel-ranges;
 			status = "disabled";
 		};
+		jpeg: jpeg@15020000 {
+			compatible = "samsung,exynos5433-jpeg";
+			reg = <0x15020000 0x10000>;
+			interrupts = <0 411 0>;
+			clock-names = "pclk",
+				      "aclk",
+				      "aclk_xiu",
+				      "sclk";
+			clocks = <&cmu_mscl CLK_PCLK_JPEG>,
+				 <&cmu_mscl CLK_ACLK_JPEG>,
+				 <&cmu_mscl CLK_ACLK_XIU_MSCLX>,
+				 <&cmu_mscl CLK_SCLK_JPEG>;
+			assigned-clocks = <&cmu_mscl CLK_MOUT_ACLK_MSCL_400_USER>,
+					  <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
+					  <&cmu_mscl CLK_MOUT_SCLK_JPEG>,
+					  <&cmu_top CLK_MOUT_SCLK_JPEG_A>;
+			assigned-clock-parents = <&cmu_top CLK_ACLK_MSCL_400>,
+						 <&cmu_top CLK_SCLK_JPEG_MSCL>,
+						 <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
+						 <&cmu_top CLK_MOUT_BUS_PLL_USER>;
+		};
 	};
 
 	timer {
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH 1/4] s5p-jpeg: generalize clocks handling
  2015-09-18 14:20 ` [PATCH 1/4] s5p-jpeg: generalize clocks handling Andrzej Pietrasiewicz
@ 2015-09-18 14:29   ` Jacek Anaszewski
  0 siblings, 0 replies; 18+ messages in thread
From: Jacek Anaszewski @ 2015-09-18 14:29 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: linux-samsung-soc, linux-media, linux-arm-kernel, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

Hi Andrzej, Marek,

On 09/18/2015 04:20 PM, Andrzej Pietrasiewicz wrote:
> From: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Allow jpeg codec variants declare clocks they need.
> Before this patch is applied jpeg-core gets jpeg->sclk
> "speculatively": if it is not there, we assume no problem.
>
> This patch eliminates this by explicitly declaring
> what clocks are needed for each variant.
>
> This is a preparation for adding Exynos 5433 variant support, which
> needs 4 clocks of names not compatible with any previous version of
> jpeg hw module.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> [Rebase and commit message]
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> ---
>   drivers/media/platform/s5p-jpeg/jpeg-core.c | 66 ++++++++++++++---------------
>   drivers/media/platform/s5p-jpeg/jpeg-core.h | 10 +++--
>   2 files changed, 37 insertions(+), 39 deletions(-)

Reviewed-by: Jacek Anaszewski <j.anaszewski@samsung.com>

-- 
Best Regards,
Jacek Anaszewski

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 2/4] s5p-jpeg: add support for 5433
  2015-09-18 14:20 ` [PATCH 2/4] s5p-jpeg: add support for 5433 Andrzej Pietrasiewicz
@ 2015-09-18 14:30   ` Jacek Anaszewski
  0 siblings, 0 replies; 18+ messages in thread
From: Jacek Anaszewski @ 2015-09-18 14:30 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: linux-samsung-soc, linux-media, linux-arm-kernel, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

Hi Andrzej,

On 09/18/2015 04:20 PM, Andrzej Pietrasiewicz wrote:
> JPEG IP found in Exynos5433 is similar to what is in Exynos4, but
> there are some subtle differences which this patch takes into account.
>
> The most important difference is in what is processed by the JPEG IP and
> what has to be provided to it. In case of 5433 the IP does not parse
> Huffman and quantisation tables, so this has to be performed with the CPU
> and the majority of the code in this patch does that.
>
> A small but important difference is in what address is passed to the JPEG
> IP. In case of 5433 it is the SOS (start of scan) position, which is
> natural, because the headers must be parsed elsewhere.
>
> There is also a difference in how the hardware is put to work in
> device_run.
>
> Data structures are extended as appropriate to accommodate the above
> changes.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> ---
>   .../bindings/media/exynos-jpeg-codec.txt           |   3 +-
>   drivers/media/platform/s5p-jpeg/jpeg-core.c        | 378 +++++++++++++++++++--
>   drivers/media/platform/s5p-jpeg/jpeg-core.h        |  31 ++
>   drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c  |  80 ++++-
>   drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h  |  11 +-
>   drivers/media/platform/s5p-jpeg/jpeg-regs.h        |  85 +++--
>   6 files changed, 522 insertions(+), 66 deletions(-)

Reviewed-by: Jacek Anaszewski <j.anaszewski@samsung.com>

-- 
Best Regards,
Jacek Anaszewski

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 3/4] MAINTAINERS: add exynos jpeg codec maintainers
  2015-09-18 14:20 ` [PATCH 3/4] MAINTAINERS: add exynos jpeg codec maintainers Andrzej Pietrasiewicz
@ 2015-09-18 14:30   ` Jacek Anaszewski
  0 siblings, 0 replies; 18+ messages in thread
From: Jacek Anaszewski @ 2015-09-18 14:30 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: linux-samsung-soc, linux-media, linux-arm-kernel, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz,
	Mauro Carvalho Chehab, Krzysztof Kozlowski

On 09/18/2015 04:20 PM, Andrzej Pietrasiewicz wrote:
> Add Andrzej Pietrasiewicz and Jacek Anaszewski
> as maintainers of drivers/media/platform/s5p-jpeg.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> ---
>   MAINTAINERS | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8133cef..ee9240b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1452,6 +1452,14 @@ L:	linux-media@vger.kernel.org
>   S:	Maintained
>   F:	drivers/media/platform/s5p-tv/
>
> +ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
> +M:	Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> +M:	Jacek Anaszewski <j.anaszewski@samsung.com>
> +L:	linux-arm-kernel@lists.infradead.org
> +L:	linux-media@vger.kernel.org
> +S:	Maintained
> +F:	drivers/media/platform/s5p-jpeg/
> +
>   ARM/SHMOBILE ARM ARCHITECTURE
>   M:	Simon Horman <horms@verge.net.au>
>   M:	Magnus Damm <magnus.damm@gmail.com>
>

Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>

-- 
Best Regards,
Jacek Anaszewski

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-18 14:21 ` [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node Andrzej Pietrasiewicz
@ 2015-09-21  9:50   ` Hans Verkuil
  2015-09-21  9:59     ` Andrzej Pietrasiewicz
  0 siblings, 1 reply; 18+ messages in thread
From: Hans Verkuil @ 2015-09-21  9:50 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz, linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Jacek Anaszewski, Kukjin Kim, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz, Mauro Carvalho Chehab,
	Krzysztof Kozlowski

On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> From: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> Add Exynos 5433 jpeg h/w codec node.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> ---
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi

This dtsi file doesn't exist in the media-git tree. What is the story here?

Should this go through a different subsystem?

I think the media subsystem can take patches 1-3 and whoever does DT patches can
take this patch, right?

Regards,

	Hans

> index 59e21b6..5cb489f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -916,6 +916,27 @@
>  			io-channel-ranges;
>  			status = "disabled";
>  		};
> +		jpeg: jpeg@15020000 {
> +			compatible = "samsung,exynos5433-jpeg";
> +			reg = <0x15020000 0x10000>;
> +			interrupts = <0 411 0>;
> +			clock-names = "pclk",
> +				      "aclk",
> +				      "aclk_xiu",
> +				      "sclk";
> +			clocks = <&cmu_mscl CLK_PCLK_JPEG>,
> +				 <&cmu_mscl CLK_ACLK_JPEG>,
> +				 <&cmu_mscl CLK_ACLK_XIU_MSCLX>,
> +				 <&cmu_mscl CLK_SCLK_JPEG>;
> +			assigned-clocks = <&cmu_mscl CLK_MOUT_ACLK_MSCL_400_USER>,
> +					  <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
> +					  <&cmu_mscl CLK_MOUT_SCLK_JPEG>,
> +					  <&cmu_top CLK_MOUT_SCLK_JPEG_A>;
> +			assigned-clock-parents = <&cmu_top CLK_ACLK_MSCL_400>,
> +						 <&cmu_top CLK_SCLK_JPEG_MSCL>,
> +						 <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
> +						 <&cmu_top CLK_MOUT_BUS_PLL_USER>;
> +		};
>  	};
>  
>  	timer {
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-21  9:50   ` Hans Verkuil
@ 2015-09-21  9:59     ` Andrzej Pietrasiewicz
  2015-09-21 11:41       ` Mauro Carvalho Chehab
  2015-09-28  8:52       ` Krzysztof Kozlowski
  0 siblings, 2 replies; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-21  9:59 UTC (permalink / raw)
  To: Hans Verkuil, linux-samsung-soc, linux-media, linux-arm-kernel
  Cc: Jacek Anaszewski, Kukjin Kim, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz, Mauro Carvalho Chehab,
	Krzysztof Kozlowski

Hi Hans,

W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>> From: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> Add Exynos 5433 jpeg h/w codec node.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>> ---
>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
>>   1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>
> This dtsi file doesn't exist in the media-git tree. What is the story here?
>
> Should this go through a different subsystem?
>
> I think the media subsystem can take patches 1-3 and whoever does DT patches can
> take this patch, right?
>

The cover letter explains that the series is rebased onto Mauro's
master with Kukjin's branch merged. The latter does contain
the exynos5433.dtsi. That said, yes, taking patches 1-3 in
media subsystem and leaving DT patch to someone else is the
way to go.

Andrzej

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-21  9:59     ` Andrzej Pietrasiewicz
@ 2015-09-21 11:41       ` Mauro Carvalho Chehab
  2015-09-21 12:28         ` Sylwester Nawrocki
  2015-09-21 12:55         ` Andrzej Pietrasiewicz
  2015-09-28  8:52       ` Krzysztof Kozlowski
  1 sibling, 2 replies; 18+ messages in thread
From: Mauro Carvalho Chehab @ 2015-09-21 11:41 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: Hans Verkuil, linux-samsung-soc, linux-media, linux-arm-kernel,
	Jacek Anaszewski, Kukjin Kim, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski

Em Mon, 21 Sep 2015 11:59:27 +0200
Andrzej Pietrasiewicz <andrzej.p@samsung.com> escreveu:

> Hi Hans,
> 
> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> > On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> >> From: Marek Szyprowski <m.szyprowski@samsung.com>
> >>
> >> Add Exynos 5433 jpeg h/w codec node.
> >>
> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> >> ---
> >>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
> >>   1 file changed, 21 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >
> > This dtsi file doesn't exist in the media-git tree. What is the story here?
> >
> > Should this go through a different subsystem?
> >
> > I think the media subsystem can take patches 1-3 and whoever does DT patches can
> > take this patch, right?
> >
> 
> The cover letter explains that the series is rebased onto Mauro's
> master with Kukjin's branch merged. The latter does contain
> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> media subsystem and leaving DT patch to someone else is the
> way to go.

I'm ok with such strategy, provided that the new driver builds fine with
COMPILE_TEST without the need of the dtsi patch.

Please also notice that, if the driver uses MC, it has to wait for
the MC next gen support to be merged, and may need to be rebased, due
to a few changes at the MC internal APIs: one function got renamed
(the function that create links between two pads) and we're now using
lists for links (that will only affect the driver if it has its own
graph traversal routines).

Btw, I just got a Samsung TM1 device, with seems to be using an arm64
SoC. Is this driver providing support for its camera?

Regards,
Mauro.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-21 11:41       ` Mauro Carvalho Chehab
@ 2015-09-21 12:28         ` Sylwester Nawrocki
  2015-09-21 12:55         ` Andrzej Pietrasiewicz
  1 sibling, 0 replies; 18+ messages in thread
From: Sylwester Nawrocki @ 2015-09-21 12:28 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Andrzej Pietrasiewicz, Hans Verkuil, linux-samsung-soc,
	linux-media, linux-arm-kernel, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski

Hi Mauro,

On 21/09/15 13:41, Mauro Carvalho Chehab wrote:
> Btw, I just got a Samsung TM1 device, with seems to be using an arm64
> SoC. Is this driver providing support for its camera?

The TM1 device (Z3) is based on a Qualcomm 64-bit SoC. The $subject
patch adds support for a standalone JPEG codec IP block of Samsung
Exynos5433 SoC, which can be found for instance in Galaxy Note4.
Perhaps someone else can provide more details regarding the TM1's camera
status.

-- 
Regards,
Sylwester

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-21 11:41       ` Mauro Carvalho Chehab
  2015-09-21 12:28         ` Sylwester Nawrocki
@ 2015-09-21 12:55         ` Andrzej Pietrasiewicz
  1 sibling, 0 replies; 18+ messages in thread
From: Andrzej Pietrasiewicz @ 2015-09-21 12:55 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Hans Verkuil, linux-samsung-soc, linux-media, linux-arm-kernel,
	Jacek Anaszewski, Kukjin Kim, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski

Hi Mauro,

W dniu 21.09.2015 o 13:41, Mauro Carvalho Chehab pisze:

<snip>

>>>
>>> I think the media subsystem can take patches 1-3 and whoever does DT patches can
>>> take this patch, right?
>>>
>>
>> The cover letter explains that the series is rebased onto Mauro's
>> master with Kukjin's branch merged. The latter does contain
>> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
>> media subsystem and leaving DT patch to someone else is the
>> way to go.
>
> I'm ok with such strategy, provided that the new driver builds fine with
> COMPILE_TEST without the need of the dtsi patch.
>

I've checked. It does compile with COMPILE_TEST.


> Please also notice that, if the driver uses MC, it has to wait for
> the MC next gen support to be merged,

No, it does not. It is a rather simple mem2mem device.

Sylwester has answered about camera support which is a different
topic.

Andrzej

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-21  9:59     ` Andrzej Pietrasiewicz
  2015-09-21 11:41       ` Mauro Carvalho Chehab
@ 2015-09-28  8:52       ` Krzysztof Kozlowski
  2015-09-28 11:54         ` Bartlomiej Zolnierkiewicz
  1 sibling, 1 reply; 18+ messages in thread
From: Krzysztof Kozlowski @ 2015-09-28  8:52 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz, Hans Verkuil, linux-samsung-soc,
	linux-media, linux-arm-kernel
  Cc: Jacek Anaszewski, Kukjin Kim, Marek Szyprowski,
	Bartlomiej Zolnierkiewicz, Mauro Carvalho Chehab

W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
> Hi Hans,
> 
> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
>> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>>> From: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> Add Exynos 5433 jpeg h/w codec node.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>>> ---
>>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
>>>   1 file changed, 21 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>
>> This dtsi file doesn't exist in the media-git tree. What is the story
>> here?
>>
>> Should this go through a different subsystem?
>>
>> I think the media subsystem can take patches 1-3 and whoever does DT
>> patches can
>> take this patch, right?
>>
> 
> The cover letter explains that the series is rebased onto Mauro's
> master with Kukjin's branch merged. The latter does contain
> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> media subsystem and leaving DT patch to someone else is the
> way to go.

Although Kukjin picked Exynos 5433 ARM64 patches but they were not
accepted upstream by arm-soc. He rolled it for few releases but:
1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
2. Kukjin did not rebase the branch for 4.4... which maybe means that he
wants to drop it?
3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
on sources on opensource.samsung.com. The DTS there is for 32-bit but it
can be probably easily adjusted for ARM64.

All of this means that Device Tree support for this driver can't be
merged now and effort for mainlining 5433 may be unfortunately wasted...

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-28  8:52       ` Krzysztof Kozlowski
@ 2015-09-28 11:54         ` Bartlomiej Zolnierkiewicz
  2015-09-28 12:02           ` Krzysztof Kozlowski
  0 siblings, 1 reply; 18+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2015-09-28 11:54 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Andrzej Pietrasiewicz, Hans Verkuil, linux-samsung-soc,
	linux-media, linux-arm-kernel, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Mauro Carvalho Chehab


Hi,

On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
> W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
> > Hi Hans,
> > 
> > W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
> >> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
> >>> From: Marek Szyprowski <m.szyprowski@samsung.com>
> >>>
> >>> Add Exynos 5433 jpeg h/w codec node.
> >>>
> >>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> >>> ---
> >>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
> >>>   1 file changed, 21 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> >>
> >> This dtsi file doesn't exist in the media-git tree. What is the story
> >> here?
> >>
> >> Should this go through a different subsystem?
> >>
> >> I think the media subsystem can take patches 1-3 and whoever does DT
> >> patches can
> >> take this patch, right?
> >>
> > 
> > The cover letter explains that the series is rebased onto Mauro's
> > master with Kukjin's branch merged. The latter does contain
> > the exynos5433.dtsi. That said, yes, taking patches 1-3 in
> > media subsystem and leaving DT patch to someone else is the
> > way to go.
> 
> Although Kukjin picked Exynos 5433 ARM64 patches but they were not
> accepted upstream by arm-soc. He rolled it for few releases but:
> 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
> 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
> wants to drop it?
> 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
> on sources on opensource.samsung.com. The DTS there is for 32-bit but it
> can be probably easily adjusted for ARM64.
> 
> All of this means that Device Tree support for this driver can't be
> merged now and effort for mainlining 5433 may be unfortunately wasted...

Exynos5433 support is being incrementally merged (clocks, drm, phy,
pinctrl, thermal and tty support is already in upstream or -next).

I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
could you please explain?) but I think that this shouldn't not stop
us from continuing Exynos5433 upstreaming effort.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-28 11:54         ` Bartlomiej Zolnierkiewicz
@ 2015-09-28 12:02           ` Krzysztof Kozlowski
  2015-09-30  6:35             ` Kukjin Kim
  0 siblings, 1 reply; 18+ messages in thread
From: Krzysztof Kozlowski @ 2015-09-28 12:02 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Andrzej Pietrasiewicz, Hans Verkuil, linux-samsung-soc,
	linux-media, linux-arm-kernel, Jacek Anaszewski, Kukjin Kim,
	Marek Szyprowski, Mauro Carvalho Chehab

W dniu 28.09.2015 o 20:54, Bartlomiej Zolnierkiewicz pisze:
> 
> Hi,
> 
> On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
>> W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
>>> Hi Hans,
>>>
>>> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
>>>> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>>>>> From: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> Add Exynos 5433 jpeg h/w codec node.
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>>>>> ---
>>>>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
>>>>>   1 file changed, 21 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>>
>>>> This dtsi file doesn't exist in the media-git tree. What is the story
>>>> here?
>>>>
>>>> Should this go through a different subsystem?
>>>>
>>>> I think the media subsystem can take patches 1-3 and whoever does DT
>>>> patches can
>>>> take this patch, right?
>>>>
>>>
>>> The cover letter explains that the series is rebased onto Mauro's
>>> master with Kukjin's branch merged. The latter does contain
>>> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
>>> media subsystem and leaving DT patch to someone else is the
>>> way to go.
>>
>> Although Kukjin picked Exynos 5433 ARM64 patches but they were not
>> accepted upstream by arm-soc. He rolled it for few releases but:
>> 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
>> 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
>> wants to drop it?
>> 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
>> on sources on opensource.samsung.com. The DTS there is for 32-bit but it
>> can be probably easily adjusted for ARM64.
>>
>> All of this means that Device Tree support for this driver can't be
>> merged now and effort for mainlining 5433 may be unfortunately wasted...
> 
> Exynos5433 support is being incrementally merged (clocks, drm, phy,
> pinctrl, thermal and tty support is already in upstream or -next).
> 
> I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
> could you please explain?) but I think that this shouldn't not stop
> us from continuing Exynos5433 upstreaming effort.

I already explained. There is no DTS, so the pull request was rejected
(pull request for v4.0 I believe).

It was not about adding drivers for 5433's clocks/phy/pinctrl etc. It
was about DTS.

Best regards,
Krzysztof


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-28 12:02           ` Krzysztof Kozlowski
@ 2015-09-30  6:35             ` Kukjin Kim
  2015-09-30  6:46               ` Chanwoo Choi
  0 siblings, 1 reply; 18+ messages in thread
From: Kukjin Kim @ 2015-09-30  6:35 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Bartlomiej Zolnierkiewicz, Andrzej Pietrasiewicz, Hans Verkuil,
	linux-samsung-soc, linux-media, linux-arm-kernel,
	Jacek Anaszewski, Kukjin Kim, Marek Szyprowski,
	Mauro Carvalho Chehab, 'Chanwoo Choi'

On 09/28/15 21:02, Krzysztof Kozlowski wrote:
> W dniu 28.09.2015 o 20:54, Bartlomiej Zolnierkiewicz pisze:
>>
>> Hi,
>>
>> On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
>>> W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
>>>> Hi Hans,
>>>>
>>>> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
>>>>> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>>>>>> From: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>
>>>>>> Add Exynos 5433 jpeg h/w codec node.
>>>>>>
>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>>>>>> ---
>>>>>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
>>>>>>   1 file changed, 21 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>>>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>>>
>>>>> This dtsi file doesn't exist in the media-git tree. What is the story
>>>>> here?
>>>>>
>>>>> Should this go through a different subsystem?
>>>>>
>>>>> I think the media subsystem can take patches 1-3 and whoever does DT
>>>>> patches can
>>>>> take this patch, right?
>>>>
>>>> The cover letter explains that the series is rebased onto Mauro's
>>>> master with Kukjin's branch merged. The latter does contain
>>>> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
>>>> media subsystem and leaving DT patch to someone else is the
>>>> way to go.
>>>
>>> Although Kukjin picked Exynos 5433 ARM64 patches but they were not
>>> accepted upstream by arm-soc. He rolled it for few releases but:
>>> 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
>>> 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
>>> wants to drop it?
>>> 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
>>> on sources on opensource.samsung.com. The DTS there is for 32-bit but it
>>> can be probably easily adjusted for ARM64.
>>>
>>> All of this means that Device Tree support for this driver can't be
>>> merged now and effort for mainlining 5433 may be unfortunately wasted...
>>
>> Exynos5433 support is being incrementally merged (clocks, drm, phy,
>> pinctrl, thermal and tty support is already in upstream or -next).
>>
>> I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
>> could you please explain?) but I think that this shouldn't not stop
>> us from continuing Exynos5433 upstreaming effort.
> 
> I already explained. There is no DTS, so the pull request was rejected
> (pull request for v4.0 I believe).
> 
+ Chanwoo Choi

Yes right, as Krzysztof commented, the pull-request has been rejected by
arm-soc even I explained it has been tested on smdk5433, because it will
not be compiled without relevant board DT file. And I've rebased when
new -rc1 released until 4.3...because Chanwoo said at that time that
regarding DT file will be submitted but not yet...

To be honest, I'm not sure I can keep the exynos5433 changes for v4.4 in
my tree at this moment...

> It was not about adding drivers for 5433's clocks/phy/pinctrl etc. It
> was about DTS.

Could be...hmm...

Thanks,
Kukjin

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node
  2015-09-30  6:35             ` Kukjin Kim
@ 2015-09-30  6:46               ` Chanwoo Choi
  0 siblings, 0 replies; 18+ messages in thread
From: Chanwoo Choi @ 2015-09-30  6:46 UTC (permalink / raw)
  To: Kukjin Kim, Krzysztof Kozlowski
  Cc: Bartlomiej Zolnierkiewicz, Andrzej Pietrasiewicz, Hans Verkuil,
	linux-samsung-soc, linux-media, linux-arm-kernel,
	Jacek Anaszewski, Marek Szyprowski, Mauro Carvalho Chehab

Dear Kukjin,

On 2015년 09월 30일 15:35, Kukjin Kim wrote:
> On 09/28/15 21:02, Krzysztof Kozlowski wrote:
>> W dniu 28.09.2015 o 20:54, Bartlomiej Zolnierkiewicz pisze:
>>>
>>> Hi,
>>>
>>> On Monday, September 28, 2015 05:52:13 PM Krzysztof Kozlowski wrote:
>>>> W dniu 21.09.2015 o 18:59, Andrzej Pietrasiewicz pisze:
>>>>> Hi Hans,
>>>>>
>>>>> W dniu 21.09.2015 o 11:50, Hans Verkuil pisze:
>>>>>> On 18-09-15 16:21, Andrzej Pietrasiewicz wrote:
>>>>>>> From: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>>
>>>>>>> Add Exynos 5433 jpeg h/w codec node.
>>>>>>>
>>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
>>>>>>> ---
>>>>>>>   arch/arm64/boot/dts/exynos/exynos5433.dtsi | 21 +++++++++++++++++++++
>>>>>>>   1 file changed, 21 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>>>>> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>>>>
>>>>>> This dtsi file doesn't exist in the media-git tree. What is the story
>>>>>> here?
>>>>>>
>>>>>> Should this go through a different subsystem?
>>>>>>
>>>>>> I think the media subsystem can take patches 1-3 and whoever does DT
>>>>>> patches can
>>>>>> take this patch, right?
>>>>>
>>>>> The cover letter explains that the series is rebased onto Mauro's
>>>>> master with Kukjin's branch merged. The latter does contain
>>>>> the exynos5433.dtsi. That said, yes, taking patches 1-3 in
>>>>> media subsystem and leaving DT patch to someone else is the
>>>>> way to go.
>>>>
>>>> Although Kukjin picked Exynos 5433 ARM64 patches but they were not
>>>> accepted upstream by arm-soc. He rolled it for few releases but:
>>>> 1. Reason for not accepting by arm-soc was not resolved - there is no DTS.
>>>> 2. Kukjin did not rebase the branch for 4.4... which maybe means that he
>>>> wants to drop it?
>>>> 3. Anyone (but me...) can send Galaxy Note4 (Exynos5433) DTS file based
>>>> on sources on opensource.samsung.com. The DTS there is for 32-bit but it
>>>> can be probably easily adjusted for ARM64.
>>>>
>>>> All of this means that Device Tree support for this driver can't be
>>>> merged now and effort for mainlining 5433 may be unfortunately wasted...
>>>
>>> Exynos5433 support is being incrementally merged (clocks, drm, phy,
>>> pinctrl, thermal and tty support is already in upstream or -next).
>>>
>>> I don't know why DTS changes got stuck in Kukjin's tree (Kukjin,
>>> could you please explain?) but I think that this shouldn't not stop
>>> us from continuing Exynos5433 upstreaming effort.
>>
>> I already explained. There is no DTS, so the pull request was rejected
>> (pull request for v4.0 I believe).
>>
> + Chanwoo Choi
> 
> Yes right, as Krzysztof commented, the pull-request has been rejected by
> arm-soc even I explained it has been tested on smdk5433, because it will
> not be compiled without relevant board DT file. And I've rebased when
> new -rc1 released until 4.3...because Chanwoo said at that time that
> regarding DT file will be submitted but not yet...
> 
> To be honest, I'm not sure I can keep the exynos5433 changes for v4.4 in
> my tree at this moment...

Thanks for your handling the exynos5433 patches on your tree.
But, I might not send the board DTS file for Exynos5433 SoC right now.
If I send the board DTS patches in the future, I'll send both board dts patches
and Exynos5433 SoC patches again.

Best Regards,
Chanwoo Choi


^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2015-09-30  6:46 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-18 14:20 [PATCH 0/4] Exynos 5433 jpeg h/w codec support Andrzej Pietrasiewicz
2015-09-18 14:20 ` [PATCH 1/4] s5p-jpeg: generalize clocks handling Andrzej Pietrasiewicz
2015-09-18 14:29   ` Jacek Anaszewski
2015-09-18 14:20 ` [PATCH 2/4] s5p-jpeg: add support for 5433 Andrzej Pietrasiewicz
2015-09-18 14:30   ` Jacek Anaszewski
2015-09-18 14:20 ` [PATCH 3/4] MAINTAINERS: add exynos jpeg codec maintainers Andrzej Pietrasiewicz
2015-09-18 14:30   ` Jacek Anaszewski
2015-09-18 14:21 ` [PATCH 4/4] ARM64: dts: exynos5433: add jpeg node Andrzej Pietrasiewicz
2015-09-21  9:50   ` Hans Verkuil
2015-09-21  9:59     ` Andrzej Pietrasiewicz
2015-09-21 11:41       ` Mauro Carvalho Chehab
2015-09-21 12:28         ` Sylwester Nawrocki
2015-09-21 12:55         ` Andrzej Pietrasiewicz
2015-09-28  8:52       ` Krzysztof Kozlowski
2015-09-28 11:54         ` Bartlomiej Zolnierkiewicz
2015-09-28 12:02           ` Krzysztof Kozlowski
2015-09-30  6:35             ` Kukjin Kim
2015-09-30  6:46               ` Chanwoo Choi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).