Re: drm: exynos: mixer: fix using usleep() in atomic context
Hello, On 2015년 01월 22일 07:46, Tobias Jakobi wrote: Hello! Inki Dae wrote: The use of spin lock, reg_slock, has been used for a long time and we hadn't some cleanups to spin lock codes so far. The spin lock is also used in here and there of mixer driver. And at least, it seems that the use of spin lock isn't required in mixer_win_reset. I don't see any atomic contexts in mixer module except interrupt handler. To Seung-Woo, I know that you referred to mixer codes of v4l2 based mixer driver. So was the spin lock used in origin v4l2 driver? or Is there any reason that you used the spin lock? The spinlock usage was originated from Tomasz Stanislawski's s5p-tv. Anyway, we will have some testing to check hdmi and mixer drivers without spin lock. So we will remove or replace it with mutex if needed. Thanks, Inki Dae So it's some weeks later and as far as I can see there has been no changes to the spinlock usage. Wouldn't it be better to apply this patch _now_ (since the use of 'usleep_range' is just plain wrong while under spinlock). When the spinlock setup gets cleaned up later, then we can always change back to 'usleep_range' again. Any thoughts? In s5p-tv, same patch is already applied by Tomasz, so I agree to apply this patch also. Best Regards, - Seung-Woo Kim With best wishes, Tobias ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Seung-Woo Kim Samsung Software RD Center -- -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: hdmi: add null check for hdmiphy_port
The hdmiphy can be apb and hdmiphy_port can be null. So before accessing hdmiphy_port, it should be checked. Signed-off-by: Seung-Woo Kim sw0312@samsung.com --- drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index fd8141f..54d97f7 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2520,7 +2520,8 @@ static int hdmi_remove(struct platform_device *pdev) if (hdata-res.reg_hdmi_en) regulator_disable(hdata-res.reg_hdmi_en); - put_device(hdata-hdmiphy_port-dev); + if (hdata-hdmiphy_port) + put_device(hdata-hdmiphy_port-dev); put_device(hdata-ddc_adpt-dev); pm_runtime_disable(pdev-dev); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: hdmi: remove unnecessary dedicated i2c drivers
The i2c drivers for ddc and hdmiphy are already removed from build
and instead, i2c clients registered via devicetree are used. So this
patch removes the unnecessary i2c drivers.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
drivers/gpu/drm/exynos/exynos_ddc.c | 63 --
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 65 ---
2 files changed, 0 insertions(+), 128 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_ddc.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
deleted file mode 100644
index 6a8c84e..000
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co.Ltd
- * Authors:
- * Seung-Woo Kim sw0312@samsung.com
- * Inki Dae inki@samsung.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
-
-#include drm/drmP.h
-
-#include linux/kernel.h
-#include linux/i2c.h
-#include linux/of.h
-
-#include exynos_drm_drv.h
-#include exynos_hdmi.h
-
-static int s5p_ddc_probe(struct i2c_client *client,
- const struct i2c_device_id *dev_id)
-{
- hdmi_attach_ddc_client(client);
-
- dev_info(client-adapter-dev,
- attached %s into i2c adapter successfully\n,
- client-name);
-
- return 0;
-}
-
-static int s5p_ddc_remove(struct i2c_client *client)
-{
- dev_info(client-adapter-dev,
- detached %s from i2c adapter successfully\n,
- client-name);
-
- return 0;
-}
-
-static struct of_device_id hdmiddc_match_types[] = {
- {
- .compatible = samsung,exynos5-hdmiddc,
- }, {
- .compatible = samsung,exynos4210-hdmiddc,
- }, {
- /* end node */
- }
-};
-
-struct i2c_driver ddc_driver = {
- .driver = {
- .name = exynos-hdmiddc,
- .owner = THIS_MODULE,
- .of_match_table = hdmiddc_match_types,
- },
- .probe = s5p_ddc_probe,
- .remove = s5p_ddc_remove,
- .command= NULL,
-};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
deleted file mode 100644
index 59abb14..000
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co.Ltd
- * Authors:
- * Seung-Woo Kim sw0312@samsung.com
- * Inki Dae inki@samsung.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- */
-
-#include drm/drmP.h
-
-#include linux/kernel.h
-#include linux/i2c.h
-#include linux/of.h
-
-#include exynos_drm_drv.h
-#include exynos_hdmi.h
-
-
-static int hdmiphy_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
-{
- hdmi_attach_hdmiphy_client(client);
-
- dev_info(client-adapter-dev, attached s5p_hdmiphy
- into i2c adapter successfully\n);
-
- return 0;
-}
-
-static int hdmiphy_remove(struct i2c_client *client)
-{
- dev_info(client-adapter-dev, detached s5p_hdmiphy
- from i2c adapter successfully\n);
-
- return 0;
-}
-
-static struct of_device_id hdmiphy_match_types[] = {
- {
- .compatible = samsung,exynos5-hdmiphy,
- }, {
- .compatible = samsung,exynos4210-hdmiphy,
- }, {
- .compatible = samsung,exynos4212-hdmiphy,
- }, {
- /* end node */
- }
-};
-
-struct i2c_driver hdmiphy_driver = {
- .driver = {
- .name = exynos-hdmiphy,
- .owner = THIS_MODULE,
- .of_match_table = hdmiphy_match_types,
- },
- .probe = hdmiphy_probe,
- .remove = hdmiphy_remove,
- .command= NULL,
-};
-EXPORT_SYMBOL(hdmiphy_driver);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] drm/exynos/mixer: use MXR_GRP_SXY_SY
Hello Daniel, On 2014년 05월 07일 23:14, Daniel Kurtz wrote: On Wed, May 7, 2014 at 1:14 PM, Seung-Woo Kim sw0312@samsung.com wrote: Hi Daniel, On 2014년 05월 05일 00:26, Daniel Kurtz wrote: Mixer hardware supports offsetting dma from start of source buffer using the MXR_GRP_SXY register. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 475eb49..40cf39b 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -529,13 +529,11 @@ static void mixer_graph_buffer(struct mixer_context *ctx, int win) dst_x_offset = win_data-crtc_x; dst_y_offset = win_data-crtc_y; + src_x_offset = win_data-fb_x; + src_y_offset = win_data-fb_y; /* converting dma address base and source offset */ - dma_addr = win_data-dma_addr - + (win_data-fb_x * win_data-bpp 3) - + (win_data-fb_y * win_data-fb_width * win_data-bpp 3); - src_x_offset = 0; - src_y_offset = 0; + dma_addr = win_data-dma_addr; Basically, you are right and source offset register can be used. But because of limitation of resolution for mixer up to 1920x1080, I considered modified soruce dma address to set one frame buffer, which is bigger than 1920x1080, on to both fimd and hdmi. Hi Seung-Woo, I do not see why the maximum MIXER resolution matters for choosing between offsetting BASE or using SXY. Let's say you have one big 1920x1908 framebuffer, with a span of 1920, starting at dma_addr (there is no extra padding at the end of the line). Let's say you wanted the mixer to scan out 1920x1080 pixels starting from (0, 800) in the framebuffer, and start drawing them at (0,0) on the screen. What we currently do is: BASE = dma_addr + (800 * 1080 * 4) SPAN = 1920 SXY = SX(0) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) I am proposing we do: BASE = dma_addr SPAN = 1920 SXY = SX(0) | SY(800) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) In both cases, the mixer resolution is 1920x1080. In my test to show each half of big one framebuffer (3840 x 1080) to FIMD from 0 to 1079 and MIXER from 1080 to 3839 with exynos4210 and exynos4412, it was failed to show proper hdmi display. Also it is same for framebuffer (1920 x 2160). AFAIK, it is mainly because mixer dma has limitation of dma memory size. In this case, I set register as like: BASE = dma_addr /* 3840 x 1080 x 4 */ SPAN = 3840 SXY = SX(1920) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) or: BASE = dma_addr /* 1920 x 2160 x 4 */ SPAN = 1920 SXY = SX(0) | SY(1080) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) but these two setting did not show hdmi display as I expected. So I used modified dma address. My motivation for wanting to program an un-modified dma_addr into BASE is so we can then just check BASE_S to determine from which buffer the mixer is actively being scanned out without worrying about the source offset, since the source offset can change for a given framebuffer (for example, when doing panning, or if an overlay is used for a HW cursor). Actually, this patch is exactly same with my first implementation, so I completely understand your motivation. Anyway, I was focus on extended displays with one buffer, so I wrote modified dma base address. Thanks and Regards, - Seung-Woo Kim Best Regards, -Daniel Regards, - Seung-Woo Kim if (win_data-scan_flags DRM_MODE_FLAG_INTERLACE) ctx-interlace = true; -- Seung-Woo Kim Samsung Software RD Center -- -- Seung-Woo Kim Samsung Software RD Center -- -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] drm/exynos/mixer: use MXR_GRP_SXY_SY
Hi Daniel, On 2014년 05월 05일 00:26, Daniel Kurtz wrote: Mixer hardware supports offsetting dma from start of source buffer using the MXR_GRP_SXY register. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 475eb49..40cf39b 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -529,13 +529,11 @@ static void mixer_graph_buffer(struct mixer_context *ctx, int win) dst_x_offset = win_data-crtc_x; dst_y_offset = win_data-crtc_y; + src_x_offset = win_data-fb_x; + src_y_offset = win_data-fb_y; /* converting dma address base and source offset */ - dma_addr = win_data-dma_addr - + (win_data-fb_x * win_data-bpp 3) - + (win_data-fb_y * win_data-fb_width * win_data-bpp 3); - src_x_offset = 0; - src_y_offset = 0; + dma_addr = win_data-dma_addr; Basically, you are right and source offset register can be used. But because of limitation of resolution for mixer up to 1920x1080, I considered modified soruce dma address to set one frame buffer, which is bigger than 1920x1080, on to both fimd and hdmi. Regards, - Seung-Woo Kim if (win_data-scan_flags DRM_MODE_FLAG_INTERLACE) ctx-interlace = true; -- Seung-Woo Kim Samsung Software RD Center -- -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm/exynos: Fix build after removal of DRM_WAKUP
Hello, On 2014년 01월 08일 21:03, Mark Brown wrote: On Wed, Jan 08, 2014 at 10:15:25AM +0900, Inki Dae wrote: 2014/1/8 Daniel Vetter dan...@ffwll.ch: Oops, looks like something slipped past between me making the patches and them getting merged. Thanks for taking care of this. Both patches are These patches already were posted by Seung-Woo link below, and I merged already them to exynos-drm-next. http://www.spinics.net/lists/dri-devel/msg50921.html Are you sure? I still need those patches in -next as of today. Yes, at least for exynos-drm-next tree of Inki. Inki sent pull request including my patch yesterday. Best Regards, - Seung-Woo Kim -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: samsung: exynos4: Correct SRC_MFC register
The SRC_MFC register was incorrect. This patch corrects it. Signed-off-by: Seung-Woo Kim sw0312@samsung.com --- drivers/clk/samsung/clk-exynos4.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c index ad5ff50..1a7c1b9 100644 --- a/drivers/clk/samsung/clk-exynos4.c +++ b/drivers/clk/samsung/clk-exynos4.c @@ -39,7 +39,7 @@ #define SRC_TOP1 0xc214 #define SRC_CAM0xc220 #define SRC_TV 0xc224 -#define SRC_MFC0xcc28 +#define SRC_MFC0xc228 #define SRC_G3D0xc22c #define E4210_SRC_IMAGE0xc230 #define SRC_LCD0 0xc234 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s5p-jpeg: fix uninitialized use in hdr parse
Hi Sylwester,
Thanks for you comment.
On 2013년 10월 12일 18:39, Sylwester Nawrocki wrote:
Hi Seung-Woo,
On 10/10/2013 09:06 AM, Seung-Woo Kim wrote:
For hdr parse error, it can return false without any assignments
which cause build warning.
Signed-off-by: Seung-Woo Kimsw0312@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
1 files 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 15d2396..7db374e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct
s5p_jpeg_q_data *result,
while (notfound) {
c = get_byte(jpeg_buffer);
if (c == -1)
-break;
+return false;
notfound is being assigned before entering the while loop, so I'm not sure
what exactly is not correct here. Can you quote the original build
warning ?
Here is the build warning.
drivers/media/platform/s5p-jpeg/jpeg-core.c: In function
's5p_jpeg_parse_hdr':
drivers/media/platform/s5p-jpeg/jpeg-core.c:432: warning: 'components'
may be used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'height' may
be used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'width' may be
used uninitialized in this function
It's a good idea to always include compiler errors/warnings in the commit
message.
Right, I'll repost with warning message.
BTW, name of the variable is a bit confusing, I think naming it 'found' and
using negation of it would be easier to follow; that's not something we'd
be changing now though.
if (c != 0xff)
continue;
do
c = get_byte(jpeg_buffer);
while (c == 0xff);
if (c == -1)
-break;
+return false;
if (c == 0)
continue;
length = 0;
Thanks,
Sylwester
--
Seung-Woo Kim
Samsung Software RD Center
--
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] s5p-jpeg: fix uninitialized use in hdr parse
For hdr parse error, it can return false without any assignments
which cause following build warning.
drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr':
drivers/media/platform/s5p-jpeg/jpeg-core.c:432: warning: 'components' may be
used uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'height' may be used
uninitialized in this function
drivers/media/platform/s5p-jpeg/jpeg-core.c:433: warning: 'width' may be used
uninitialized in this function
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
change from v1
- add build warning to commit message
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
1 files 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 15d2396..7db374e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
while (notfound) {
c = get_byte(jpeg_buffer);
if (c == -1)
- break;
+ return false;
if (c != 0xff)
continue;
do
c = get_byte(jpeg_buffer);
while (c == 0xff);
if (c == -1)
- break;
+ return false;
if (c == 0)
continue;
length = 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-jpeg: fix uninitialized use in hdr parse
For hdr parse error, it can return false without any assignments
which cause build warning.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.c |4 ++--
1 files 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 15d2396..7db374e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -442,14 +442,14 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
while (notfound) {
c = get_byte(jpeg_buffer);
if (c == -1)
- break;
+ return false;
if (c != 0xff)
continue;
do
c = get_byte(jpeg_buffer);
while (c == 0xff);
if (c == -1)
- break;
+ return false;
if (c == 0)
continue;
length = 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Hi Rahul, On 2013년 07월 30일 12:42, Rahul Sharma wrote: On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com mailto:kis...@ti.com wrote: Hi, On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote: Thanks all, On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com mailto:sw0312@samsung.com wrote: Hello Kishon, On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote: Hi, On Thursday 13 June 2013 04:51 PM, Inki Dae wrote: -Original Message- From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com mailto:s.nawro...@samsung.com] Sent: Thursday, June 13, 2013 5:56 PM To: Rahul Sharma Cc: Rahul Sharma; Inki Dae; linux-samsung-soc@vger.kernel.org mailto:linux-samsung-soc@vger.kernel.org; devicetree- disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim; Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren; grant.lik...@linaro.org mailto:grant.lik...@linaro.org Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control Hi, On 06/13/2013 06:26 AM, Rahul Sharma wrote: Mr. Dae, Thanks for your valuable inputs. I posted it as RFC because, I also have received comments to register hdmiphy as a clock controller. As we always configure it for specific frequency, hdmi-phy looks similar to a PLL. But it really doesn't belong to that class. Secondly prior to exynos5420, it was a i2c device. I am not sure we can register a I2C device as a clock controller. I wanted to discuss and explore this option here. Have you considered using the generic PHY framework for those HDMI PHY devices [1] ? I guess we could add a dedicated group of ops for video PHYs, similarly as is is done with struct v4l2_subdev_ops. For configuring things like the carrier/pixel clock frequency or anything what's common across the video PHYs. Perhaps you could have a look and see if this framework would be useful for HDMI and possibly point out anything what might be missing ? I'm not sure it it really solves the issues specific to the Exynos HDMI but at least with a generic PHY driver the PHY module would be separate from the PHY controller, as often same HDMI DPHY can be used with various types of a HDMI controller. So this would allow to not duplicate the HDMI PHY drivers in the long-term perspective. Yeah, at least, it seems that we could use PHY module to control PMU register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off callbacks. As you may know, HDMIPHY needs i2c interfaces to control HDMIPHY clock. So with PHY module, HDMIPHY driver could enable PMU more generically, but also has to use existing i2c stuff to control HDMIPHY clock. I had a quick review to Generic PHY Framework[v6] but I didn't see that the PHY module could generically support more features such as i2c stuff. I don't think PHY framework needs to provide i2c interfaces to program certain configurations. Instead in one of the callbacks (init/on/off) PHY driver can program whatever it wants using any of the interfaces it needs. IMO PHY framework should work independent of the interfaces. In exnoys hdmi case, i2c interface is not the exact issue. In exynos hdmi, hdmiphy should send i2c configuration about video clock information as the video mode information including resolution, bit per pixel, refresh rate passed from drm subsystem. So init/on/off callbacks of phy framework are not enough for exynos hdmiphy and it should have a callback to set video mode. Do you have plan to add driver specific extend callback pointers to phy framework? Currently, hdmi directly calls phy operations, but Rahul's another patch set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is connected with exynos hdmi own sub driver callback operations. IMHO, if phy framework can support extend callback feature, then this own sub driver callbacks can be replaced with phy framework at long term view. Extended callbacks are always welcome. I can also use phy device private data to pass on private ops like get_pixelclk and set_pixelclk. I would recommend creating a wrapper to the existing PHY framework for HDMI PHY. That way, we can have other HDMI phys added easily. We need to figure out all the ops that might be needed by the HDMI PHY to be added to the wrapper. IMO
[PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmu, dev) do { } while (0)
#endif
#define SYSMMU_CLOCK_DEVNAME(ipname, id) (SYSMMU_DEVNAME_BASE . #id)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Sorry about typo in previous patch.
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
#endif
#define SYSMMU_CLOCK_DEVNAME(ipname, id) (SYSMMU_DEVNAME_BASE . #id)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
