Re: [v3,2/9] clk: samsung: exynos5433: Add clocks for CMU_ATLAS domain
Hi Chanwoo, On Tuesday 03 February 2015 05:43 AM, Chanwoo Choi wrote: This patch adds the mux/divider/gate clocks for CMU_ATLAS domain which generates the clocks for Cortex-A57 Quad-core processsor, L2 cache controller and CoreSight. Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Inki Dae inki@samsung.com Verified clock tree, clock register and bitfields against UM. Patch look OK to me. Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com Thanks, Pankaj Dubey -- 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 4/4] drm/exynos: remove checks for zpos == -1 on primary planes
Hi,
On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The primary plane default zpos is now 0, so remove checks for zpos ==
-1. We don't need to set win to 0 anymore it is already zero.
Could you also remove DEFAULT_ZPOS define? And zpos and win should be
unsigned from now.
Thanks.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 --
drivers/gpu/drm/exynos/exynos_mixer.c| 6 ++
3 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 00df40d..7637780 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -612,9 +612,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
int win)
if (ctx-suspended)
return;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
@@ -735,9 +732,6 @@ static void fimd_win_disable(struct exynos_drm_crtc
*crtc, int win)
struct fimd_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3c0dcb4..e730ef6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -125,9 +125,6 @@ static void vidi_win_commit(struct exynos_drm_crtc *crtc,
int win)
if (ctx-suspended)
return;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
@@ -146,9 +143,6 @@ static void vidi_win_disable(struct exynos_drm_crtc
*crtc, int win)
struct vidi_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 141d461..b283713 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -892,10 +892,9 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
*crtc)
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
-static void mixer_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void mixer_win_commit(struct exynos_drm_crtc *crtc, int win)
{
struct mixer_context *mixer_ctx = crtc-ctx;
- int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
DRM_DEBUG_KMS(win: %d\n, win);
@@ -914,11 +913,10 @@ static void mixer_win_commit(struct exynos_drm_crtc
*crtc, int zpos)
mixer_ctx-planes[win].enabled = true;
}
-static void mixer_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void mixer_win_disable(struct exynos_drm_crtc *crtc, int win)
{
struct mixer_context *mixer_ctx = crtc-ctx;
struct mixer_resources *res = mixer_ctx-mixer_res;
- int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
unsigned long flags;
DRM_DEBUG_KMS(win: %d\n, win);
--
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: preset zpos value for overlay planes
Hi,
On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.
Plane zpos should be read-only. If not, it can't do 1:1 mapping plane
and hw overlay. Let's make zpos to DRM_MODE_PROP_IMMUTABLE property.
Thanks.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 ---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
5 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 489ce90..b49b038 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1006,7 +1006,7 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, ctx-planes[zpos], 1 ctx-pipe,
- type);
+ type, zpos);
}
ret = fimd_ctx_initialize(ctx, drm_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 011a9b1..4c33e04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -211,7 +211,7 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.set_property = exynos_plane_set_property,
};
-static void exynos_plane_attach_zpos_property(struct drm_plane *plane)
+static void exynos_plane_attach_zpos_property(struct drm_plane *plane, int
zpos)
{
struct drm_device *dev = plane-dev;
struct exynos_drm_private *dev_priv = dev-dev_private;
@@ -227,12 +227,13 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane)
dev_priv-plane_zpos_property = prop;
}
- drm_object_attach_property(plane-base, prop, 0);
+ drm_object_attach_property(plane-base, prop, zpos);
}
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane,
- unsigned long possible_crtcs, enum drm_plane_type type)
+ unsigned long possible_crtcs, enum drm_plane_type type,
+ int zpos)
{
int err;
@@ -244,10 +245,10 @@ int exynos_plane_init(struct drm_device *dev,
return err;
}
- if (type == DRM_PLANE_TYPE_PRIMARY)
- exynos_plane-zpos = DEFAULT_ZPOS;
- else
- exynos_plane_attach_zpos_property(exynos_plane-base);
+ exynos_plane-zpos = zpos;
+
+ if (type == DRM_PLANE_TYPE_OVERLAY)
+ exynos_plane_attach_zpos_property(exynos_plane-base, zpos);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index d8a3494..d8a66b5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -22,4 +22,5 @@ int exynos_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
uint32_t src_w, uint32_t src_h);
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane,
- unsigned long possible_crtcs, enum drm_plane_type type);
+ unsigned long possible_crtcs, enum drm_plane_type type,
+ int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index f33974e..e545a58 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -478,7 +478,7 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, ctx-planes[zpos], 1 ctx-pipe,
- type);
+ type, zpos);
}
vidi_ctx_initialize(ctx, drm_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6e7c0cc..141d461 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1177,7 +1177,7 @@ static int mixer_bind(struct device *dev, struct device
*manager, void *data)
Re: [PATCH v5 0/2] mmc: dw_mmc: exynos: Add HS400 support
Hi, Vivek. On 02/06/2015 02:52 PM, Vivek Gautam wrote: Hi Jaehoon, On Fri, Feb 6, 2015 at 6:48 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Alim. On my board, this patch isn't working fine. So when i complete to test on my board(exynos5), i will reply with comments. Sorry for late testing. I tested this series on linux-next, on Exynos5800-peach-pi board, and HS400 seems to be working fine. I can see the card getting detected as HS400, and then i ran iozone as well. The iozone numbers are also as required. On peach-pit board too, the HS200 mode seems to be working good. What are the observations you saw on your board ? Thanks for testing on your board. I have exynos5422 and exynos5433.(One is eMMC5.0, other is eMMC5.1) I want to see that it's working fine on my board. I should miss something..so i will check more detail after complete my other job, or on this weekend. (It failed for hs400 tuning sequence..I needs to check that it has the board dependency) Best Regards, Jaehoon Chung Best Regards, Jaehoon Chung On 01/29/2015 11:41 AM, Alim Akhtar wrote: This adds HS400 mode support for exynos dw_mmc host controller. Currently tested on Exynos5800-peach-pi and Exyons7 platform for HS400 mode. Tested HS200 mode with this series applied, HS200 still works. Appreciate testing on other exynos5/7 platform which supports emmc5.0 Changes in V5: * Enable HS400 on Exynos5800-peach-pi boards * Addressed other review comments from Jaehoon Chung Changes in V4: * drop the idea of changing existing binding for ciu_div as per [1] * addressed comments from Jaehoon Chung [2] [1] http://www.spinics.net/lists/linux-samsung-soc/msg40923.html [2] http://www.spinics.net/lists/devicetree/msg64373.html Changes in V3: rebased on ulf's next (commit: 607b448 mmc: core: Make tuning block patterns static) Seungwon Jeon (2): mmc: dw_mmc: exynos: Support eMMC's HS400 mode ARM: dts: Add HS400 support for exynos5420 and exynos5800 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 + arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts |4 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |7 +- drivers/mmc/host/dw_mmc-exynos.c | 185 drivers/mmc/host/dw_mmc-exynos.h | 19 +- drivers/mmc/host/dw_mmc.c | 16 +- drivers/mmc/host/dw_mmc.h |2 + 9 files changed, 213 insertions(+), 38 deletions(-) -- 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 -- 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 v5 0/2] mmc: dw_mmc: exynos: Add HS400 support
Hi, On Fri, Feb 6, 2015 at 11:33 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Vivek. On 02/06/2015 02:52 PM, Vivek Gautam wrote: Hi Jaehoon, On Fri, Feb 6, 2015 at 6:48 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Alim. On my board, this patch isn't working fine. So when i complete to test on my board(exynos5), i will reply with comments. Sorry for late testing. I tested this series on linux-next, on Exynos5800-peach-pi board, and HS400 seems to be working fine. I can see the card getting detected as HS400, and then i ran iozone as well. The iozone numbers are also as required. On peach-pit board too, the HS200 mode seems to be working good. What are the observations you saw on your board ? Thanks for testing on your board. I have exynos5422 and exynos5433.(One is eMMC5.0, other is eMMC5.1) I want to see that it's working fine on my board. I should miss something..so i will check more detail after complete my other job, or on this weekend. (It failed for hs400 tuning sequence..I needs to check that it has the board dependency) Ok Thanks for testing it on your side. Best Regards, Jaehoon Chung Best Regards, Jaehoon Chung On 01/29/2015 11:41 AM, Alim Akhtar wrote: This adds HS400 mode support for exynos dw_mmc host controller. Currently tested on Exynos5800-peach-pi and Exyons7 platform for HS400 mode. Tested HS200 mode with this series applied, HS200 still works. Appreciate testing on other exynos5/7 platform which supports emmc5.0 Changes in V5: * Enable HS400 on Exynos5800-peach-pi boards * Addressed other review comments from Jaehoon Chung Changes in V4: * drop the idea of changing existing binding for ciu_div as per [1] * addressed comments from Jaehoon Chung [2] [1] http://www.spinics.net/lists/linux-samsung-soc/msg40923.html [2] http://www.spinics.net/lists/devicetree/msg64373.html Changes in V3: rebased on ulf's next (commit: 607b448 mmc: core: Make tuning block patterns static) Seungwon Jeon (2): mmc: dw_mmc: exynos: Support eMMC's HS400 mode ARM: dts: Add HS400 support for exynos5420 and exynos5800 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 + arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts |4 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |7 +- drivers/mmc/host/dw_mmc-exynos.c | 185 drivers/mmc/host/dw_mmc-exynos.h | 19 +- drivers/mmc/host/dw_mmc.c | 16 +- drivers/mmc/host/dw_mmc.h |2 + 9 files changed, 213 insertions(+), 38 deletions(-) -- 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 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 PATCH 0/3] Fix power domains handling on exynos542x
Hi, On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote: Hello Andrzej, Thanks a lot for finally finding what was causing the HDMI issue. On 02/05/2015 01:35 PM, Andrzej Hajda wrote: Hi, Exynos chipsets since 542x have asynchronous bridges connecting different IPs. These bridges should be operational during power domain switching, ie associated clocks cannot be gated. This patchset adds binding to provide such clocks per power domain and adds code which enables them during domain on/off operation. This patchset fixes power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos platforms' [1]. It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2]. It was successfully tested on OdroidXU3. [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743 Your patches looks good to me so please feel free to add: Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I also tested on an Exynos5420 Peach Pit Chromebook and both the Power domain power-domain disable failed message and the system crash are gone. Really gone out Power domain power-domain disable failed message? Still i get the message from second try, # modetest -M exynos -s 23@21:1920x1080 setting mode 1920x1080@XR24 on connectors 23, crtc 21 # modetest -M exynos -s 23@21:1920x1080 setting mode 1920x1080@XR24 on connectors 23, crtc 21 [ 39.608881] Power domain power-domain disable failed # modetest -M exynos -s 23@21:1920x1080 setting mode 1920x1080@XR24 on connectors 23, crtc 21 [ 42.827637] Power domain power-domain disable failed ... Thanks. Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier [2]: https://lkml.org/lkml/2015/1/20/235 -- 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 -- 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 v5 0/2] mmc: dw_mmc: exynos: Add HS400 support
Hi Jaehoon, On Fri, Feb 6, 2015 at 6:48 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Alim. On my board, this patch isn't working fine. So when i complete to test on my board(exynos5), i will reply with comments. Sorry for late testing. I tested this series on linux-next, on Exynos5800-peach-pi board, and HS400 seems to be working fine. I can see the card getting detected as HS400, and then i ran iozone as well. The iozone numbers are also as required. On peach-pit board too, the HS200 mode seems to be working good. What are the observations you saw on your board ? Best Regards, Jaehoon Chung On 01/29/2015 11:41 AM, Alim Akhtar wrote: This adds HS400 mode support for exynos dw_mmc host controller. Currently tested on Exynos5800-peach-pi and Exyons7 platform for HS400 mode. Tested HS200 mode with this series applied, HS200 still works. Appreciate testing on other exynos5/7 platform which supports emmc5.0 Changes in V5: * Enable HS400 on Exynos5800-peach-pi boards * Addressed other review comments from Jaehoon Chung Changes in V4: * drop the idea of changing existing binding for ciu_div as per [1] * addressed comments from Jaehoon Chung [2] [1] http://www.spinics.net/lists/linux-samsung-soc/msg40923.html [2] http://www.spinics.net/lists/devicetree/msg64373.html Changes in V3: rebased on ulf's next (commit: 607b448 mmc: core: Make tuning block patterns static) Seungwon Jeon (2): mmc: dw_mmc: exynos: Support eMMC's HS400 mode ARM: dts: Add HS400 support for exynos5420 and exynos5800 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 + arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts |4 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |7 +- drivers/mmc/host/dw_mmc-exynos.c | 185 drivers/mmc/host/dw_mmc-exynos.h | 19 +- drivers/mmc/host/dw_mmc.c | 16 +- drivers/mmc/host/dw_mmc.h |2 + 9 files changed, 213 insertions(+), 38 deletions(-) -- 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 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 04/14] drm/exynos: remove struct *_win_data abstraction on planes
Hi, On 02/05/2015 10:06 PM, Daniel Vetter wrote: On Thu, Feb 05, 2015 at 12:48:07PM +, Daniel Stone wrote: Hi, On 5 February 2015 at 12:26, Rob Clark robdcl...@gmail.com wrote: On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter dan...@ffwll.ch wrote: Yeah I noticed the zpos fun when hacking around too. Exynos should probably switch defaults so that overlays are visible by default. And we need to standardize the zpos property so that other drivers can use it too. jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really mdp4 probably needs the same) to sort attached planes and derive the actual hw zpos (with each layer having a unique zpos).. I suspect most hw will end up needing the same (ie. dislike having two overlays at same zpos), so might not be a horrible idea to make the atomic helpers do this sorting for us.. Oh yeah such a helper would be nice. Especially since on intel hw flipping planes around means fishing the right value out of some enum table ;-) So some sort of helper to compute the absolute ordering in a stable way would be nice. Same with Exynos, except it's a bit funnier still. In terms of its hardware, each CRTC has a number of planes which have a fixed zpos. The reason exynos_drm exposes zpos is because it sets up a fixed number of planes for the entire device and declares they can run across every single CRTC, and then works out from the combination of CRTC assignment and zpos property, which hardware plane to assign it to. This includes the primary, so if you accidentally get zpos==0 in there, then you smash the primary plane. Or set a duplicate zpos and then the last one in wins. It also means if you're using multiple CRTCs (e.g. FIMD for internal panel plus mixer for external HDMI), then you can only use 5 planes in total, rather than 5 planes per head. (And let's not forget that each backend has disjoint format support, so again the driver just lies to you and claims to support them all, with a silent fallback via a default case statement when the format isn't actually supported. Whoops.) I think a more ideal setup would be a much more direct 1:1 mapping with the hardware, where each actual plane on each actual CRTC gets exposed directly to userspace, perhaps with a fixed/read-only zpos property to tell the userspace which plane it's actually configuring. I suspect this would be a pretty good map to other hardware as well. Hm that sounds indeed a bit funny. I agree that exynos should split planes into per-crtc and separate the code and capability tables out so that there's less lying. And zpos should probably be converted to a read-only property to tell userspace about the facts, instead of doing something funny behind the scenes. I agree, it seems be time to convert each planes have unique zpos. Thanks. -- 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 1/4] drm/exynos: remove struct *_win_data abstraction on planes
Hi Gustavo,
On 02/06/2015 02:59 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
OK, let's go ahead this with next zpos problem fix.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
drivers/gpu/drm/exynos/exynos_mixer.c | 212
+++---
9 files changed, 183 insertions(+), 389 deletions(-)
[snip]
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 736269a..6e7c0cc 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -37,34 +37,13 @@
#include exynos_drm_drv.h
#include exynos_drm_crtc.h
+#include exynos_drm_plane.h
#include exynos_drm_iommu.h
#include exynos_mixer.h
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN0
-struct hdmi_win_data {
- dma_addr_t dma_addr;
- dma_addr_t chroma_dma_addr;
- uint32_tpixel_format;
- unsigned intbpp;
- unsigned intcrtc_x;
- unsigned intcrtc_y;
- unsigned intcrtc_width;
- unsigned intcrtc_height;
- unsigned intfb_x;
- unsigned intfb_y;
- unsigned intfb_width;
- unsigned intfb_height;
- unsigned intsrc_width;
- unsigned intsrc_height;
- unsigned intmode_width;
- unsigned intmode_height;
- unsigned intscan_flags;
- boolenabled;
- boolresume;
-};
-
struct mixer_resources {
int irq;
void __iomem*mixer_regs;
@@ -88,6 +67,7 @@ struct mixer_context {
struct device *dev;
struct drm_device *drm_dev;
struct exynos_drm_crtc *crtc;
+ struct exynos_drm_plane planes[MIXER_WIN_NR];
int pipe;
boolinterlace;
boolpowered;
@@ -97,7 +77,6 @@ struct mixer_context {
struct mutexmixer_mutex;
struct mixer_resources mixer_res;
- struct hdmi_win_datawin_data[MIXER_WIN_NR];
enum mixer_version_id mxr_ver;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -401,7 +380,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
int win)
{
struct mixer_resources *res = ctx-mixer_res;
unsigned long flags;
- struct hdmi_win_data *win_data;
+ struct exynos_drm_plane *plane;
unsigned int x_ratio, y_ratio;
unsigned int buf_num = 1;
dma_addr_t luma_addr[2], chroma_addr[2];
@@ -409,9 +388,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
int win)
bool crcb_mode = false;
u32 val;
- win_data = ctx-win_data[win];
+ plane = ctx-planes[win];
- switch (win_data-pixel_format) {
+ switch (plane-pixel_format) {
case DRM_FORMAT_NV12MT:
tiled_mode = true;
case DRM_FORMAT_NV12:
@@ -421,35 +400,35 @@ static void vp_video_buffer(struct mixer_context *ctx,
int win)
/* TODO: single buffer format NV12, NV21 */
default:
/* ignore pixel format at disable time */
- if (!win_data-dma_addr)
+ if (!plane-dma_addr[0])
break;
DRM_ERROR(pixel format for vp is wrong [%d].\n,
- win_data-pixel_format);
+ plane-pixel_format);
return;
}
/* scaling feature: (src 16) / dst */
- x_ratio = (win_data-src_width 16) / win_data-crtc_width;
- y_ratio = (win_data-src_height 16) / win_data-crtc_height;
+ x_ratio = (plane-src_width 16) / plane-crtc_width;
+ y_ratio = (plane-src_height 16) / plane-crtc_height;
if (buf_num == 2) {
- luma_addr[0] = win_data-dma_addr;
- chroma_addr[0] = win_data-chroma_dma_addr;
+ luma_addr[0] = plane-dma_addr[0];
+ chroma_addr[0] = plane-dma_addr[1];
} else {
-
Re: [PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes
On Thu, Feb 05, 2015 at 12:48:07PM +, Daniel Stone wrote: Hi, On 5 February 2015 at 12:26, Rob Clark robdcl...@gmail.com wrote: On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter dan...@ffwll.ch wrote: Yeah I noticed the zpos fun when hacking around too. Exynos should probably switch defaults so that overlays are visible by default. And we need to standardize the zpos property so that other drivers can use it too. jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really mdp4 probably needs the same) to sort attached planes and derive the actual hw zpos (with each layer having a unique zpos).. I suspect most hw will end up needing the same (ie. dislike having two overlays at same zpos), so might not be a horrible idea to make the atomic helpers do this sorting for us.. Oh yeah such a helper would be nice. Especially since on intel hw flipping planes around means fishing the right value out of some enum table ;-) So some sort of helper to compute the absolute ordering in a stable way would be nice. Same with Exynos, except it's a bit funnier still. In terms of its hardware, each CRTC has a number of planes which have a fixed zpos. The reason exynos_drm exposes zpos is because it sets up a fixed number of planes for the entire device and declares they can run across every single CRTC, and then works out from the combination of CRTC assignment and zpos property, which hardware plane to assign it to. This includes the primary, so if you accidentally get zpos==0 in there, then you smash the primary plane. Or set a duplicate zpos and then the last one in wins. It also means if you're using multiple CRTCs (e.g. FIMD for internal panel plus mixer for external HDMI), then you can only use 5 planes in total, rather than 5 planes per head. (And let's not forget that each backend has disjoint format support, so again the driver just lies to you and claims to support them all, with a silent fallback via a default case statement when the format isn't actually supported. Whoops.) I think a more ideal setup would be a much more direct 1:1 mapping with the hardware, where each actual plane on each actual CRTC gets exposed directly to userspace, perhaps with a fixed/read-only zpos property to tell the userspace which plane it's actually configuring. I suspect this would be a pretty good map to other hardware as well. Hm that sounds indeed a bit funny. I agree that exynos should split planes into per-crtc and separate the code and capability tables out so that there's less lying. And zpos should probably be converted to a read-only property to tell userspace about the facts, instead of doing something funny behind the scenes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
[RFC PATCH 2/3] arm/exynos/pm_domains: add support for async-bridge clocks
Since Exynos5420 there are async-bridges (ASB) between different IPs. These
bridges must be operational during power domain on/off, ie. clocks used
by these bridges should be enabled.
This patch enabled these clocks during domain on/off.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 0e2bc36..ecff522 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -37,6 +37,7 @@ struct exynos_pm_domain {
struct clk *oscclk;
struct clk *clk[MAX_CLK_PER_DOMAIN];
struct clk *pclk[MAX_CLK_PER_DOMAIN];
+ struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
};
static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -45,14 +46,19 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
void __iomem *base;
u32 timeout, pwr;
char *op;
+ int i;
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd-base;
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ clk_prepare_enable(pd-asb_clk[i]);
+ }
+
/* Set oscclk before powering off a domain*/
if (!power_on) {
- int i;
-
for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
@@ -81,8 +87,6 @@ static int exynos_pd_power(struct generic_pm_domain *domain,
bool power_on)
/* Restore clocks after powering on a domain*/
if (power_on) {
- int i;
-
for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
@@ -92,6 +96,12 @@ static int exynos_pd_power(struct generic_pm_domain *domain,
bool power_on)
}
}
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ clk_disable_unprepare(pd-asb_clk[i]);
+ }
+
return 0;
}
@@ -137,6 +147,15 @@ static __init int exynos4_pm_init_power_domain(void)
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
+ for (i = 0; i MAX_CLK_PER_DOMAIN; i++) {
+ char clk_name[8];
+
+ snprintf(clk_name, sizeof(clk_name), asb%d, i);
+ pd-asb_clk[i] = clk_get(dev, clk_name);
+ if (IS_ERR(pd-asb_clk[i]))
+ break;
+ }
+
pd-oscclk = clk_get(dev, oscclk);
if (IS_ERR(pd-oscclk))
goto no_clk;
--
1.9.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
[RFC PATCH 1/3] arm/exynos: add asynchronous bridge clock bindings
The patch adds bindings for clocks required by async-bridges present in the particular power domain. Signed-off-by: Andrzej Hajda a.ha...@samsung.com --- Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 1e09703..5da38c5 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -22,6 +22,9 @@ Optional Properties: - pclkN, clkN: Pairs of parent of input clock and input clock to the devices in this power domain. Maximum of 4 pairs (N = 0 to 3) are supported currently. + - asbN: Clocks required by asynchronous bridges (ASB) present in + the power domain. These clock should be enabled during power + domain on/off operations. - power-domains: phandle pointing to the parent power domain, for more details see Documentation/devicetree/bindings/power/power_domain.txt -- 1.9.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
[RFC PATCH 3/3] ARM: dts: exynos5420: add async-bridge clock to disp1 power domain
disp1 power domain requires operational async-bridge associated with HDMI,
ie its clock should be enabled during power on/off.
This patch fixes broken Odroid XU3 HDMI support.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index b8f1c9f..13191fe 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -285,9 +285,11 @@
clock CLK_MOUT_SW_ACLK300,
clock CLK_MOUT_USER_ACLK300_DISP1,
clock CLK_MOUT_SW_ACLK400,
-clock CLK_MOUT_USER_ACLK400_DISP1;
+clock CLK_MOUT_USER_ACLK400_DISP1,
+clock CLK_HDMI;
clock-names = oscclk, pclk0, clk0,
- pclk1, clk1, pclk2, clk2;
+ pclk1, clk1, pclk2, clk2,
+ asb0;
};
pinctrl_0: pinctrl@1340 {
--
1.9.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 04/14] drm/exynos: remove struct *_win_data abstraction on planes
Hi, On 5 February 2015 at 12:26, Rob Clark robdcl...@gmail.com wrote: On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter dan...@ffwll.ch wrote: Yeah I noticed the zpos fun when hacking around too. Exynos should probably switch defaults so that overlays are visible by default. And we need to standardize the zpos property so that other drivers can use it too. jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really mdp4 probably needs the same) to sort attached planes and derive the actual hw zpos (with each layer having a unique zpos).. I suspect most hw will end up needing the same (ie. dislike having two overlays at same zpos), so might not be a horrible idea to make the atomic helpers do this sorting for us.. Same with Exynos, except it's a bit funnier still. In terms of its hardware, each CRTC has a number of planes which have a fixed zpos. The reason exynos_drm exposes zpos is because it sets up a fixed number of planes for the entire device and declares they can run across every single CRTC, and then works out from the combination of CRTC assignment and zpos property, which hardware plane to assign it to. This includes the primary, so if you accidentally get zpos==0 in there, then you smash the primary plane. Or set a duplicate zpos and then the last one in wins. It also means if you're using multiple CRTCs (e.g. FIMD for internal panel plus mixer for external HDMI), then you can only use 5 planes in total, rather than 5 planes per head. (And let's not forget that each backend has disjoint format support, so again the driver just lies to you and claims to support them all, with a silent fallback via a default case statement when the format isn't actually supported. Whoops.) I think a more ideal setup would be a much more direct 1:1 mapping with the hardware, where each actual plane on each actual CRTC gets exposed directly to userspace, perhaps with a fixed/read-only zpos property to tell the userspace which plane it's actually configuring. I suspect this would be a pretty good map to other hardware as well. Cheers, Daniel -- 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: [v3,1/9] clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
Hi Pankaj and Sylwester,
On Thu, Feb 5, 2015 at 6:56 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 05/02/15 08:44, Pankaj Dubey wrote:
+static struct samsung_gate_clock apollo_gate_clks[] __initdata = {
+
+ /* ENABLE_PCLK_APOLLO */
+ GATE(CLK_PCLK_ASAPBMST_CSSYS_APOLLO, pclk_asapbmst_cssys_apollo,
+ div_pclk_dbg_apollo, ENABLE_PCLK_APOLLO,
+ 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_PMU_APOLLO, pclk_pmu_apollo, div_pclk_apollo,
+ ENABLE_PCLK_APOLLO, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_SYSREG_APOLLO, pclk_pmu_sysreg_apollo,
Isn't pclk_pmu_sysreg_apollo be named as pclk_sysreg_apollo to match
with UM?
You're right. It is my mistake.
Sounds reasonable, Chanwoo, if you agree I'll squash following change
to this patch before sending upstream:
I agree.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 7a024cd..387e3e3 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3656,7 +3656,7 @@ static struct samsung_gate_clock apollo_gate_clks[]
__initdata = {
2, CLK_IGNORE_UNUSED, 0),
GATE(CLK_PCLK_PMU_APOLLO, pclk_pmu_apollo, div_pclk_apollo,
ENABLE_PCLK_APOLLO, 1, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_PCLK_SYSREG_APOLLO, pclk_pmu_sysreg_apollo,
+ GATE(CLK_PCLK_SYSREG_APOLLO, pclk_sysreg_apollo,
div_pclk_apollo, ENABLE_PCLK_APOLLO,
0, CLK_IGNORE_UNUSED, 0),
Best Regards,
Chanwoo Choi
--
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] cpufreq: exynos: Use simple approach to asses if cpu cooling can be used
Commit: e725d26c4857e5e41975b5e74e64ce6ab09a7121 provided possibility to
use device tree to asses if cpu can be used as cooling device. Since the
code was somewhat awkward, simpler approach has been proposed.
Test HW: Exynos 4412 - Odroid U3.
Suggested-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
Changes for v2:
- Remove superfluous *np pointer
---
drivers/cpufreq/exynos-cpufreq.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 5e98c6b..82d2fbb 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -159,7 +159,7 @@ static struct cpufreq_driver exynos_driver = {
static int exynos_cpufreq_probe(struct platform_device *pdev)
{
- struct device_node *cpus, *np;
+ struct device_node *cpu0;
int ret = -EINVAL;
exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
@@ -206,28 +206,19 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
if (ret)
goto err_cpufreq_reg;
- cpus = of_find_node_by_path(/cpus);
- if (!cpus) {
- pr_err(failed to find cpus node\n);
+ cpu0 = of_get_cpu_node(0, NULL);
+ if (!cpu0) {
+ pr_err(failed to find cpu0 node\n);
return 0;
}
- np = of_get_next_child(cpus, NULL);
- if (!np) {
- pr_err(failed to find cpus child node\n);
- of_node_put(cpus);
- return 0;
- }
-
- if (of_find_property(np, #cooling-cells, NULL)) {
- cdev = of_cpufreq_cooling_register(np,
+ if (of_find_property(cpu0, #cooling-cells, NULL)) {
+ cdev = of_cpufreq_cooling_register(cpu0,
cpu_present_mask);
if (IS_ERR(cdev))
pr_err(running cpufreq without cooling device: %ld\n,
PTR_ERR(cdev));
}
- of_node_put(np);
- of_node_put(cpus);
return 0;
--
2.0.0.rc2
--
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 v3 3/3] ARM: EXYNOS: Remove left over 'extra_save'
Hi Krzysztof On 5 February 2015 at 12:53, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Since 32b0aa9aaeb4 (ARM: EXYNOS: Remove i2c sys configuration related code) the Exynos 5250 no longer saves additional registers under 'exynos_pm_data.extra_save' field. No one else uses this code so get rid of it making also 'exynos_pm_data' const everywhere. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com Thanks, Pankaj Dubey -- 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 V4] drm/exynos: Add DECON driver
This patch is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
The current version of the driver supports video mode displays.
Signed-off-by: Akshu Agrawal aks...@gmail.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
Changes since V1:
-- Address comments from Pankaj and do few cleanups.
Changes since V2:
-- Address more comments from Pankaj and cleanup.
Changes since V3:
-- Rebase on exynos-drm-next. Pull in changes from
FIMD driver.
-- Address comments from Inki Dae. Remove unnecessary
functions and delays. Make use of i80-if-timings
node to differentiate between command/video mode.
.../devicetree/bindings/video/exynos7-decon.txt| 68 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 991
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 349 +++
7 files changed, 1424 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..f5f9c8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,68 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be samsung,exynos7-decon;
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: fifo, vsync,
+ lcd_sys, in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a default entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain pclk_decon0, aclk_decon0,
+ decon0_eclk, decon0_vclk.
+- i80-if-timings: timing configuration for lcd i80 interface support.
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for DECON, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = samsung,exynos7-decon;
+ interrupt-parent = combiner;
+ reg = 0x1393 0x1000;
+ interrupt-names = lcd_sys, vsync, fifo;
+ interrupts = 0 188 0, 0 189 0, 0 190 0;
+ clocks = clock_disp PCLK_DECON_INT,
+clock_disp ACLK_DECON_INT,
+clock_disp SCLK_DECON_INT_ECLK,
+clock_disp SCLK_DECON_INT_EXTCLKPLL;
+ clock-names = pclk_decon0, aclk_decon0, decon0_eclk,
+ decon0_vclk;
+ status = disabled;
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = lcd_clk pwm1_out;
+ pinctrl-names = default;
+ status = okay;
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 627aaa0..378cfd5 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -24,9 +24,16 @@ config DRM_EXYNOS_FIMD
Re: [PATCH 02/14] drm/exynos: Remove exynos_plane_dpms() call with no effect
On Thu, Feb 05, 2015 at 10:05:43AM +0900, Joonyoung Shim wrote: Hi Daniel, On 02/04/2015 11:16 PM, Daniel Vetter wrote: On Wed, Feb 04, 2015 at 04:42:57PM +0900, Joonyoung Shim wrote: Hi, On 02/04/2015 04:14 AM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback from the underlying layer. However neither one of these layers implement win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms() is pointless. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b2a4b84..ad675fb 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -65,8 +65,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc) if (exynos_crtc-ops-commit) exynos_crtc-ops-commit(exynos_crtc); - - exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON); As i said, this needs to keep pair enabled flag of struct exynos_drm_plane. The reason exynos needs that exynos_plane-enable is because it has its own per-plane dpms state. There's two problems with that: - It's highyl non-standard, the drm kms way is to just disable the plane and not have some additional knob on top. - The atomic helpers will not be able to handle this. They assume that there's only one dpms knob for the entire display pipeline, and per-plane enable/disable is handled by setting plane-state-crtc, which must be set iff plane-state-fb is set right now. I recommend we rip this all out if we can adjust existing userspace to stop using the mode property on planes and crtcs. And with that non-standard exynos plane mode thing gone we can indeed rip out exynos_plane_dpms and exynos_plane-enabled and just directly call manager-ops-win_enable/disble. And then rip out the win_enable since it's unused. But this cleanup on current codes doesn't care now current operation normally. First let's cleanup non-standard exynos plane dpms state as you said. Yeah my reply wasn't too clear, so let me clarify: I agree with you, Padovan's patch as-is can't be merged. First we need to get rid of the non-standard plane dpms stuff, then we can remove the -win_enable hook and then can we remove this call here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] GPU-DRM-Exynos: Delete unnecessary checks before two function calls
Hi,
On 02/05/2015 06:00 AM, SF Markus Elfring wrote:
From: Markus Elfring elfr...@users.sourceforge.net
Date: Wed, 4 Feb 2015 21:54:45 +0100
The functions phy_power_on() and vunmap() perform also input
parameter validation. Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 6 ++
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 34d46aa..306cf1d 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1057,14 +1057,12 @@ static int exynos_dp_create_connector(struct
exynos_drm_display *display,
static void exynos_dp_phy_init(struct exynos_dp_device *dp)
{
- if (dp-phy)
- phy_power_on(dp-phy);
+ phy_power_on(dp-phy);
}
static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
{
- if (dp-phy)
- phy_power_off(dp-phy);
+ phy_power_off(dp-phy);
}
static void exynos_dp_poweron(struct exynos_drm_display *display)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index e12ea90..0dd448a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -313,7 +313,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device
*dev,
struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
struct drm_framebuffer *fb;
- if (is_drm_iommu_supported(dev) exynos_gem_obj-buffer-kvaddr)
+ if (is_drm_iommu_supported(dev))
vunmap(exynos_gem_obj-buffer-kvaddr);
/* release drm framebuffer and real buffer */
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Thanks.
--
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: [v3,3/9] clk: samsung: exynos5433: Add clocks for CMU_MSCL domain
Hi Chanwoo, On Tuesday 03 February 2015 05:43 AM, Chanwoo Choi wrote: This patch adds the mux/divider/gate clocks for CMU_MSCL domain which generates the clocks for M2M (Memory to Memory) scaler, JPEG IPs. Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Acked-by: Inki Dae inki@samsung.com --- .../devicetree/bindings/clock/exynos5433-clock.txt | 20 +++ drivers/clk/samsung/clk-exynos5433.c | 185 + include/dt-bindings/clock/exynos5433.h | 41 - 3 files changed, 245 insertions(+), 1 deletion(-) Verified clock tree, clock register and bitfield settings against UM. Changes looks OK to me. Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com Thanks, Pankaj Dubey -- 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 PATCH 0/3] Fix power domains handling on exynos542x
Hello Andrzej, Thanks a lot for finally finding what was causing the HDMI issue. On 02/05/2015 01:35 PM, Andrzej Hajda wrote: Hi, Exynos chipsets since 542x have asynchronous bridges connecting different IPs. These bridges should be operational during power domain switching, ie associated clocks cannot be gated. This patchset adds binding to provide such clocks per power domain and adds code which enables them during domain on/off operation. This patchset fixes power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos platforms' [1]. It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2]. It was successfully tested on OdroidXU3. [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743 Your patches looks good to me so please feel free to add: Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I also tested on an Exynos5420 Peach Pit Chromebook and both the Power domain power-domain disable failed message and the system crash are gone. Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier [2]: https://lkml.org/lkml/2015/1/20/235 -- 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 v5 0/2] mmc: dw_mmc: exynos: Add HS400 support
Hi, Alim. On my board, this patch isn't working fine. So when i complete to test on my board(exynos5), i will reply with comments. Sorry for late testing. Best Regards, Jaehoon Chung On 01/29/2015 11:41 AM, Alim Akhtar wrote: This adds HS400 mode support for exynos dw_mmc host controller. Currently tested on Exynos5800-peach-pi and Exyons7 platform for HS400 mode. Tested HS200 mode with this series applied, HS200 still works. Appreciate testing on other exynos5/7 platform which supports emmc5.0 Changes in V5: * Enable HS400 on Exynos5800-peach-pi boards * Addressed other review comments from Jaehoon Chung Changes in V4: * drop the idea of changing existing binding for ciu_div as per [1] * addressed comments from Jaehoon Chung [2] [1] http://www.spinics.net/lists/linux-samsung-soc/msg40923.html [2] http://www.spinics.net/lists/devicetree/msg64373.html Changes in V3: rebased on ulf's next (commit: 607b448 mmc: core: Make tuning block patterns static) Seungwon Jeon (2): mmc: dw_mmc: exynos: Support eMMC's HS400 mode ARM: dts: Add HS400 support for exynos5420 and exynos5800 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 + arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts |4 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |7 +- drivers/mmc/host/dw_mmc-exynos.c | 185 drivers/mmc/host/dw_mmc-exynos.h | 19 +- drivers/mmc/host/dw_mmc.c | 16 +- drivers/mmc/host/dw_mmc.h |2 + 9 files changed, 213 insertions(+), 38 deletions(-) -- 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 04/14] drm/exynos: remove struct *_win_data abstraction on planes
On Thu, Feb 05, 2015 at 11:37:13AM +0900, Joonyoung Shim wrote:
Hi Daniel,
On 02/04/2015 11:28 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
I commented already on prior patch.
I think you don't quite understand how this primary/overlay plane stuff
works in drm core. The entire point of the drm core primary plane is to
work _exactly_ like an overlay plane and allow userspace to mangle the
primary plane configuration through the overlay plane. The only reason we
have primary planes is so that old userspace keeps working.
Right, i misunderstood a bit because exynos hw drivers have dependency
of zpos(hw overlay position).
Current exynos drm driver has each primary plane of hw drivers and five
overlay planes. The primary plane is fixed on default hw overlay and all
overlay plane can map to all hw overlays using specific zpos property of
exynos drm plane.
Gustavo approach will include specific hw overlay data in overlay plane
and hw driver keeps overlay planes to array by zpos order. But current
zpos of overlay plane is 0 always if user doesn't modify it, so hw
driver will use only hw overlay data of primary plane always even if
user want to use overlay plane.
If user is modified zpos of overlay plane, hw driver can get wrong hw
overlay data from different overlay plane because hw driver keeps
overlay planes by zpos order.
Yeah I noticed the zpos fun when hacking around too. Exynos should
probably switch defaults so that overlays are visible by default. And we
need to standardize the zpos property so that other drivers can use it
too.
But that doesn't change anything with the primary plane just being a
special plane from the sw side (backwards compat), for exynos hw they all
look the same.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 v3 1/3] ARM: EXYNOS: Add missing static to file-scope declarations
Hi Krzysztof, On Thursday 05 February 2015 12:53 PM, Krzysztof Kozlowski wrote: The 'pm_data', 'exynos_release_ret_regs', 'exynos3250_release_ret_regs' and 'exynos5420_release_ret_regs' are not exported nor used outside of suspend.c file. Make them static. This fixes following sparse warnings: arch/arm/mach-exynos/suspend.c:83:23: warning: symbol 'pm_data' was not declared. Should it be static? arch/arm/mach-exynos/suspend.c:106:14: warning: symbol 'exynos_release_ret_regs' was not declared. Should it be static? arch/arm/mach-exynos/suspend.c:117:14: warning: symbol 'exynos5420_release_ret_regs' was not declared. Should it be static? Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com Thanks, Pankaj Dubey -- 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: [v3,1/9] clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
On 05/02/15 08:44, Pankaj Dubey wrote:
+static struct samsung_gate_clock apollo_gate_clks[] __initdata = {
+
+ /* ENABLE_PCLK_APOLLO */
+ GATE(CLK_PCLK_ASAPBMST_CSSYS_APOLLO, pclk_asapbmst_cssys_apollo,
+ div_pclk_dbg_apollo, ENABLE_PCLK_APOLLO,
+ 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_PMU_APOLLO, pclk_pmu_apollo, div_pclk_apollo,
+ ENABLE_PCLK_APOLLO, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_SYSREG_APOLLO, pclk_pmu_sysreg_apollo,
Isn't pclk_pmu_sysreg_apollo be named as pclk_sysreg_apollo to match
with UM?
Sounds reasonable, Chanwoo, if you agree I'll squash following change
to this patch before sending upstream:
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 7a024cd..387e3e3 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3656,7 +3656,7 @@ static struct samsung_gate_clock apollo_gate_clks[]
__initdata = {
2, CLK_IGNORE_UNUSED, 0),
GATE(CLK_PCLK_PMU_APOLLO, pclk_pmu_apollo, div_pclk_apollo,
ENABLE_PCLK_APOLLO, 1, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_PCLK_SYSREG_APOLLO, pclk_pmu_sysreg_apollo,
+ GATE(CLK_PCLK_SYSREG_APOLLO, pclk_sysreg_apollo,
div_pclk_apollo, ENABLE_PCLK_APOLLO,
0, CLK_IGNORE_UNUSED, 0),
--
Thanks,
Sylwester
--
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: exynos3250: Add driver for CMU_ISP clock domain
From: Tomasz Figa t.f...@samsung.com
Add clock controller for CMU ISP clock domain on Exynos3250,
providing clocks for FIMC-IS subsystem.
[b.michalska: initial setup of ISP block source clocks
(setting root oscillator clock as the input);
use samsung_cmu_register_one to register the provider;
updated DT binding documentation]
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Beata Michalska b.michal...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/clock/exynos3250-clock.txt |8 +
drivers/clk/samsung/clk-exynos3250.c | 189
include/dt-bindings/clock/exynos3250.h | 61 +++
3 files changed, 258 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
index f57d9dd..f1738b8 100644
--- a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -9,6 +9,8 @@ Required Properties:
- samsung,exynos3250-cmu - controller compatible with Exynos3250 SoC.
- samsung,exynos3250-cmu-dmc - controller compatible with
Exynos3250 SoC for Dynamic Memory Controller domain.
+ - samsung,exynos3250-cmu-isp - ISP block clock controller compatible
+ with Exynos3250 SOC
- reg: physical base address of the controller and length of memory mapped
region.
@@ -36,6 +38,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = 1;
};
+ cmu_isp: clock-controller@10048000 {
+ compatible = samsung,exynos3250-cmu-isp;
+ reg = 0x10048000 0x1000;
+ #clock-cells = 1;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index 6e6cca3..36dceb6 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -814,9 +814,16 @@ static void __init exynos3_core_down_clock(void)
__raw_writel(0x0, reg_base + PWR_CTRL2);
}
+static inline struct clk *__samsung_clk_get(struct samsung_clk_provider *ctx,
+ unsigned int idx)
+{
+ return ctx-clk_data.clks[idx];
+}
+
static void __init exynos3250_cmu_init(struct device_node *np)
{
struct samsung_clk_provider *ctx;
+ struct clk* clk_mux, *clk_parent;
reg_base = of_iomap(np, 0);
if (!reg_base)
@@ -841,6 +848,27 @@ static void __init exynos3250_cmu_init(struct device_node
*np)
samsung_clk_register_div(ctx, div_clks, ARRAY_SIZE(div_clks));
samsung_clk_register_gate(ctx, gate_clks, ARRAY_SIZE(gate_clks));
+ /**
+* Both mux clocks: mout_aclk_400_mcuisp_sub and mout_aclk_266_sub
+* drive the source clocks for ISP block (MCUISP and ISP respectively).
+* Switch both muxes to root oscillator clock to secure
+* proper power down of ISP power domain case it's state
+* transitions remain unhandled (by a relevant device driver).
+* This will also reduce the risk of accessing the ISP CMU registers
+* while the ISP power domain remains turned off.
+* Note: This still requires some real solutions (involving
+* the ISP CMU)
+*/
+ clk_parent = __samsung_clk_get(ctx, CLK_FIN_PLL);
+ if (!IS_ERR(clk_parent)) {
+ clk_mux = __samsung_clk_get(ctx, CLK_MOUT_ACLK_400_MCUISP_SUB);
+ if (!IS_ERR(clk_mux))
+ clk_set_parent(clk_mux, clk_parent);
+ clk_mux = __samsung_clk_get(ctx, CLK_MOUT_ACLK_266_SUB);
+ if (!IS_ERR(clk_mux))
+ clk_set_parent(clk_mux, clk_parent);
+ }
+
exynos3_core_down_clock();
exynos3250_clk_sleep_init();
@@ -1017,3 +1045,164 @@ static void __init exynos3250_cmu_dmc_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos3250_cmu_dmc, samsung,exynos3250-cmu-dmc,
exynos3250_cmu_dmc_init);
+
+/*
+ * CMU ISP
+ */
+
+#define DIV_ISP0 0x300
+#define DIV_ISP1 0x304
+#define GATE_IP_ISP0 0x800
+#define GATE_IP_ISP1 0x804
+#define GATE_SCLK_ISP 0x900
+
+static struct samsung_div_clock isp_div_clks[] __initdata = {
+ /*
+* NOTE: Following table is sorted by register address in ascending
+* order and then bitfield shift in descending order, as it is done
+* in the User's Manual. When adding new entries, please make sure
+* that the order is preserved, to avoid merge conflicts and make
+*
[RFC PATCH 0/3] Fix power domains handling on exynos542x
Hi, Exynos chipsets since 542x have asynchronous bridges connecting different IPs. These bridges should be operational during power domain switching, ie associated clocks cannot be gated. This patchset adds binding to provide such clocks per power domain and adds code which enables them during domain on/off operation. This patchset fixes power domain issues with disp1 domain and HDMI (some of them) on Odroid XU3: - disp1 power domain can be turned off, - no more imprecise external abort faults. The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos platforms' [1]. It was successfully tested on OdroidXU3. [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743 Regards Andrzej Andrzej Hajda (3): arm/exynos: add asynchronous bridge clock bindings arm/exynos/pm_domains: add support for async-bridge clocks ARM: dts: exynos5420: add async-bridge clock to disp1 power domain .../bindings/arm/exynos/power_domain.txt | 3 +++ arch/arm/boot/dts/exynos5420.dtsi | 6 +++-- arch/arm/mach-exynos/pm_domains.c | 27 ++ 3 files changed, 30 insertions(+), 6 deletions(-) -- 1.9.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 v2 2/2] arm/dma-mapping: Respect NO_KERNEL_MAPPING when we don't have an IOMMU
On Wed, Feb 4, 2015 at 11:21 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On 2015-02-04 10:23, Carlo Caione wrote: From: Jasper St. Pierre jstpie...@mecheye.net Even without an iommu, NO_KERNEL_MAPPING is still convenient to save on kernel address space in places where we don't need a kernel mapping. Implement support for it in the two places where we're creating an expensive mapping. __alloc_from_pool uses an internal pool from which we already have virtual addresses, so it's not relevant, and __alloc_simple_buffer uses alloc_pages, which will always return a lowmem page, which is already mapped into kernel space, so we can't prevent a mapping for it in that case. Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net Signed-off-by: Carlo Caione ca...@caione.org Reviewed-by: Rob Clark robdcl...@gmail.com Reviewed-by: Daniel Drake d...@endlessm.com Acked-by: Marek Szyprowski m.szyprow...@samsung.com Thanks. Who is supposed to take this patch? Russel? Cheers, -- Carlo Caione -- 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 04/14] drm/exynos: remove struct *_win_data abstraction on planes
On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Feb 05, 2015 at 11:37:13AM +0900, Joonyoung Shim wrote:
Hi Daniel,
On 02/04/2015 11:28 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:44:12PM +0900, Joonyoung Shim wrote:
Hi,
On 02/04/2015 04:14 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
I commented already on prior patch.
I think you don't quite understand how this primary/overlay plane stuff
works in drm core. The entire point of the drm core primary plane is to
work _exactly_ like an overlay plane and allow userspace to mangle the
primary plane configuration through the overlay plane. The only reason we
have primary planes is so that old userspace keeps working.
Right, i misunderstood a bit because exynos hw drivers have dependency
of zpos(hw overlay position).
Current exynos drm driver has each primary plane of hw drivers and five
overlay planes. The primary plane is fixed on default hw overlay and all
overlay plane can map to all hw overlays using specific zpos property of
exynos drm plane.
Gustavo approach will include specific hw overlay data in overlay plane
and hw driver keeps overlay planes to array by zpos order. But current
zpos of overlay plane is 0 always if user doesn't modify it, so hw
driver will use only hw overlay data of primary plane always even if
user want to use overlay plane.
If user is modified zpos of overlay plane, hw driver can get wrong hw
overlay data from different overlay plane because hw driver keeps
overlay planes by zpos order.
Yeah I noticed the zpos fun when hacking around too. Exynos should
probably switch defaults so that overlays are visible by default. And we
need to standardize the zpos property so that other drivers can use it
too.
jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really
mdp4 probably needs the same) to sort attached planes and derive the
actual hw zpos (with each layer having a unique zpos)..
I suspect most hw will end up needing the same (ie. dislike having two
overlays at same zpos), so might not be a horrible idea to make the
atomic helpers do this sorting for us..
BR,
-R
But that doesn't change anything with the primary plane just being a
special plane from the sw side (backwards compat), for exynos hw they all
look the same.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
Hi,
On Thursday, February 05, 2015 08:12:20 AM Krzysztof Kozlowski wrote:
On śro, 2015-02-04 at 19:07 +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday, February 04, 2015 11:27:26 AM Krzysztof Kozlowski wrote:
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to
`cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to
`exynos_cpu_power_down'
Make the cpuidle driver depending on SMP because this will be the
fastest way to fix build break without adding a bunch of ifdefs in few
places.
There shouldn't be a lot of new ifdefs (please see below) and I would
very much prefer for cpuidle to stay supported also on UP kernels.
Sure, I'm fine with your patch.
Thanks!
I tested it today with SMP UP kernels on Origen4210 board and it works
fine in both cases (-next is fine on Origen4210, the problem I hit yestereday
was caused by a configuration issue on my side).
Kukjin, please apply it. Thank you.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
Best regards,
Krzysztof
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/mach-exynos/pm.c | 2 ++
drivers/cpuidle/Kconfig.arm | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index e6209dadc00d..17db00ff7f3a 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -181,6 +181,7 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
static int exynos_cpu0_enter_aftr(void)
@@ -302,3 +303,4 @@ struct cpuidle_exynos_data
cpuidle_coupled_exynos_data = {
.pre_enter_aftr = exynos_pre_enter_aftr,
.post_enter_aftr= exynos_post_enter_aftr,
};
+#endif /* CONFIG_ARM_EXYNOS_CPUIDLE */
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 8e07c9419153..5eb86a4f74d9 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -55,7 +55,8 @@ config ARM_AT91_CPUIDLE
config ARM_EXYNOS_CPUIDLE
bool Cpu Idle Driver for the Exynos processors
depends on ARCH_EXYNOS
- select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
+ depends on SMP
+ select ARCH_NEEDS_CPU_IDLE_COUPLED
help
Select this to enable cpuidle for Exynos processors
How's about the patch below instead? It builds fine for UP and SMP.
I will do more testing tomorrow (unfortunately it seems that something
else broke Origen4210 in -next).
From: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Subject: [PATCH] ARM: EXYNOS: cpuidle: Fix build breakage on !SMP
The Exynos cpuidle driver has coupled cpuidle built-in so it cannot be
built without SMP:
arch/arm/mach-exynos/pm.c: In function ‘exynos_cpu0_enter_aftr’:
arch/arm/mach-exynos/pm.c:246:4: error: implicit declaration of function
‘arch_send_wakeup_ipi_mask’ [-Werror=implicit-function-declaration]
arch/arm/mach-exynos/built-in.o: In function `exynos_pre_enter_aftr':
../arch/arm/mach-exynos/pm.c:300: undefined reference to `cpu_boot_reg_base'
arch/arm/mach-exynos/built-in.o: In function `exynos_cpu1_powerdown':
../arch/arm/mach-exynos/pm.c:282: undefined reference to
`exynos_cpu_power_down'
Fix it by adding missing checks for SMP.
Reported-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/mach-exynos/exynos.c|2 +-
arch/arm/mach-exynos/pm.c|2 ++
drivers/cpuidle/cpuidle-exynos.c |3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
Index: b/arch/arm/mach-exynos/exynos.c
===
--- a/arch/arm/mach-exynos/exynos.c 2015-02-04 18:30:23.555819717 +0100
+++ b/arch/arm/mach-exynos/exynos.c 2015-02-04 18:43:23.539807815 +0100
@@ -211,7 +211,7 @@ static void __init exynos_dt_machine_ini
if (!IS_ENABLED(CONFIG_SMP))
exynos_sysram_init();
-#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
+#if defined(CONFIG_SMP) defined(CONFIG_ARM_EXYNOS_CPUIDLE)
if (of_machine_is_compatible(samsung,exynos4210))
exynos_cpuidle.dev.platform_data = cpuidle_coupled_exynos_data;
#endif
Index: b/arch/arm/mach-exynos/pm.c
Re: [PATCH 08/14] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
On Thu, Feb 05, 2015 at 11:48:18AM +0900, Joonyoung Shim wrote: Hi Daniel, On 02/04/2015 11:30 PM, Daniel Vetter wrote: On Wed, Feb 04, 2015 at 04:49:25PM +0900, Joonyoung Shim wrote: Hi, On 02/04/2015 04:14 AM, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they unprotect the windows before the commit and protects it after based on a plane mask tha store which plane will be updated. I don't think they need now. This does exactly what I wanted to do in my atomic poc but couldn't because of the massive layer hell that was still around in atomic. Haven't looked into the patch in details, so no full r-b but good enough for an I agree about its operation but i think it is unnecessary now. Because it's exactly same operation with current codes. Well that's to be expected since if you don't want to have some duplicated code while transitioning to atomic you must do it all in one giant patch. With a bit of duplication you can move things over slowly, in differnt phases and piece by piece like Padovan's patch series here. The duplication should go away in the end again. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 1/4] drm/exynos: remove struct *_win_data abstraction on planes
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 182 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 20 +--
drivers/gpu/drm/exynos/exynos_drm_plane.h | 6 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 123 +
drivers/gpu/drm/exynos/exynos_mixer.c | 212 +++---
9 files changed, 183 insertions(+), 389 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 48ccab7..47dd2b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -239,13 +239,13 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
};
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
void *ctx)
{
struct exynos_drm_crtc *exynos_crtc;
- struct drm_plane *plane;
struct exynos_drm_private *private = drm_dev-dev_private;
struct drm_crtc *crtc;
int ret;
@@ -262,12 +262,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
exynos_crtc-type = type;
exynos_crtc-ops = ops;
exynos_crtc-ctx = ctx;
- plane = exynos_plane_init(drm_dev, 1 pipe,
- DRM_PLANE_TYPE_PRIMARY);
- if (IS_ERR(plane)) {
- ret = PTR_ERR(plane);
- goto err_plane;
- }
crtc = exynos_crtc-base;
@@ -284,7 +278,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
err_crtc:
plane-funcs-destroy(plane);
-err_plane:
kfree(exynos_crtc);
return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 6258b80..e1fd2ef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -18,6 +18,7 @@
#include exynos_drm_drv.h
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
+ struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
struct exynos_drm_crtc_ops *ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 1bcbe07..c598197 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -55,7 +55,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
{
struct exynos_drm_private *private;
int ret;
- int nr;
private = kzalloc(sizeof(struct exynos_drm_private), GFP_KERNEL);
if (!private)
@@ -81,19 +80,6 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
exynos_drm_mode_config_init(dev);
- for (nr = 0; nr MAX_PLANE; nr++) {
- struct drm_plane *plane;
- unsigned long possible_crtcs = (1 MAX_CRTC) - 1;
-
- plane = exynos_plane_init(dev, possible_crtcs,
- DRM_PLANE_TYPE_OVERLAY);
- if (!IS_ERR(plane))
- continue;
-
- ret = PTR_ERR(plane);
- goto err_mode_config_cleanup;
- }
-
/* setup possible_clones. */
exynos_drm_encoder_setup(dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 1aceafc..67936eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -78,6 +78,7 @@ enum exynos_drm_output_type {
* @transparency: transparency on or off.
* @activated: activated or not.
* @enabled: enabled or not.
+ * @resume: to resume or not.
*
* this structure is common to exynos SoC and its contents would be copied
* to hardware specific overlay info.
@@ -112,6 +113,7 @@ struct exynos_drm_plane {
bool transparency:1;
bool activated:1;
bool enabled:1;
[PATCH 2/4] drm/exynos: preset zpos value for overlay planes
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 ---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
5 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 489ce90..b49b038 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1006,7 +1006,7 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, ctx-planes[zpos], 1 ctx-pipe,
- type);
+ type, zpos);
}
ret = fimd_ctx_initialize(ctx, drm_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 011a9b1..4c33e04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -211,7 +211,7 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.set_property = exynos_plane_set_property,
};
-static void exynos_plane_attach_zpos_property(struct drm_plane *plane)
+static void exynos_plane_attach_zpos_property(struct drm_plane *plane, int
zpos)
{
struct drm_device *dev = plane-dev;
struct exynos_drm_private *dev_priv = dev-dev_private;
@@ -227,12 +227,13 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane)
dev_priv-plane_zpos_property = prop;
}
- drm_object_attach_property(plane-base, prop, 0);
+ drm_object_attach_property(plane-base, prop, zpos);
}
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane,
- unsigned long possible_crtcs, enum drm_plane_type type)
+ unsigned long possible_crtcs, enum drm_plane_type type,
+ int zpos)
{
int err;
@@ -244,10 +245,10 @@ int exynos_plane_init(struct drm_device *dev,
return err;
}
- if (type == DRM_PLANE_TYPE_PRIMARY)
- exynos_plane-zpos = DEFAULT_ZPOS;
- else
- exynos_plane_attach_zpos_property(exynos_plane-base);
+ exynos_plane-zpos = zpos;
+
+ if (type == DRM_PLANE_TYPE_OVERLAY)
+ exynos_plane_attach_zpos_property(exynos_plane-base, zpos);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index d8a3494..d8a66b5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -22,4 +22,5 @@ int exynos_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
uint32_t src_w, uint32_t src_h);
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane,
- unsigned long possible_crtcs, enum drm_plane_type type);
+ unsigned long possible_crtcs, enum drm_plane_type type,
+ int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index f33974e..e545a58 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -478,7 +478,7 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
type = (zpos == ctx-default_win) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, ctx-planes[zpos], 1 ctx-pipe,
- type);
+ type, zpos);
}
vidi_ctx_initialize(ctx, drm_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6e7c0cc..141d461 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1177,7 +1177,7 @@ static int mixer_bind(struct device *dev, struct device
*manager, void *data)
type = (zpos == MIXER_DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
exynos_plane_init(drm_dev, ctx-planes[zpos], 1 ctx-pipe,
-
[PATCH 3/4] drm/exynos: avoid extra variable to keep window number
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Define the function args as 'win' to avoid the assignment later in the
functions.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 ++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b49b038..00df40d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -601,11 +601,10 @@ static void fimd_shadow_protect_win(struct fimd_context
*ctx,
writel(val, ctx-regs + reg);
}
-static void fimd_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void fimd_win_commit(struct exynos_drm_crtc *crtc, int win)
{
struct fimd_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
dma_addr_t dma_addr;
unsigned long val, alpha, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
@@ -731,11 +730,10 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
atomic_set(ctx-win_updated, 1);
}
-static void fimd_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void fimd_win_disable(struct exynos_drm_crtc *crtc, int win)
{
struct fimd_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
if (win == DEFAULT_ZPOS)
win = ctx-default_win;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index e545a58..3c0dcb4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -117,11 +117,10 @@ static void vidi_disable_vblank(struct exynos_drm_crtc
*crtc)
ctx-vblank_on = false;
}
-static void vidi_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void vidi_win_commit(struct exynos_drm_crtc *crtc, int win)
{
struct vidi_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
if (ctx-suspended)
return;
@@ -142,11 +141,10 @@ static void vidi_win_commit(struct exynos_drm_crtc *crtc,
int zpos)
schedule_work(ctx-work);
}
-static void vidi_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void vidi_win_disable(struct exynos_drm_crtc *crtc, int win)
{
struct vidi_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- int win = zpos;
if (win == DEFAULT_ZPOS)
win = ctx-default_win;
--
1.9.3
--
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 4/4] drm/exynos: remove checks for zpos == -1 on primary planes
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The primary plane default zpos is now 0, so remove checks for zpos ==
-1. We don't need to set win to 0 anymore it is already zero.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 --
drivers/gpu/drm/exynos/exynos_mixer.c| 6 ++
3 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 00df40d..7637780 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -612,9 +612,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
int win)
if (ctx-suspended)
return;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
@@ -735,9 +732,6 @@ static void fimd_win_disable(struct exynos_drm_crtc *crtc,
int win)
struct fimd_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3c0dcb4..e730ef6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -125,9 +125,6 @@ static void vidi_win_commit(struct exynos_drm_crtc *crtc,
int win)
if (ctx-suspended)
return;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
@@ -146,9 +143,6 @@ static void vidi_win_disable(struct exynos_drm_crtc *crtc,
int win)
struct vidi_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
- if (win == DEFAULT_ZPOS)
- win = ctx-default_win;
-
if (win 0 || win = WINDOWS_NR)
return;
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 141d461..b283713 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -892,10 +892,9 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
*crtc)
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
-static void mixer_win_commit(struct exynos_drm_crtc *crtc, int zpos)
+static void mixer_win_commit(struct exynos_drm_crtc *crtc, int win)
{
struct mixer_context *mixer_ctx = crtc-ctx;
- int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
DRM_DEBUG_KMS(win: %d\n, win);
@@ -914,11 +913,10 @@ static void mixer_win_commit(struct exynos_drm_crtc
*crtc, int zpos)
mixer_ctx-planes[win].enabled = true;
}
-static void mixer_win_disable(struct exynos_drm_crtc *crtc, int zpos)
+static void mixer_win_disable(struct exynos_drm_crtc *crtc, int win)
{
struct mixer_context *mixer_ctx = crtc-ctx;
struct mixer_resources *res = mixer_ctx-mixer_res;
- int win = zpos == DEFAULT_ZPOS ? MIXER_DEFAULT_WIN : zpos;
unsigned long flags;
DRM_DEBUG_KMS(win: %d\n, win);
--
1.9.3
--
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: [RESEND PATCH V3 15/15] ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs
On Tue, Feb 03, 2015 at 03:06:22PM +0100, Sylwester Nawrocki wrote: I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, samsung,s3c6410-i2s compatible should be used for them. I've applied this even though I really shouldn't in order to get it in. Since it's a bug fix for stable it should've been near the head of any series it's part of not the very last patch in the series, and since it's not really related to the rest of the series except in that it relates to the same driver it should probably have been sent by itself rather than mixed in with everything else. signature.asc Description: Digital signature
[GIT PULL] clk/samsung: clk support for Exynos 5433 SoC
Hi Mike,
This pull request includes driver for clock controller of the Exynos
5433 SoC. As the hardware is quite complex, with many peripherals and
corresponding clock management units the driver is rather huge. I guess
it will require a bit more cleanups than last time to balance lines
introduced in this patch set... Please review and pull if it looks OK.
The following changes since commit e64fb42da4c6c713cfc7cad607e97e0773fa41ff:
clk: samsung: exynos4: Add divider clock id for memory bus frequency
(2015-01-28 15:51:17 +0100)
are available in the git repository at:
git://linuxtv.org/snawrocki/samsung.git tags/v3.20-exynos5433-clk
for you to fetch changes up to b2f0e5f28e0686c0d5db238357a2e32555e97633:
clk: samsung: exynos5433: Move CLK_SCLK_HDMI_SPDIF_DISP clock to CMU_TOP
domain (2015-02-05 19:31:09 +0100)
Clock controller driver for Exynos 5433 SoC.
Chanwoo Choi (22):
clk: samsung: exynos5433: Add binding document for Exynos5433 clock
domains
clk: samsung: exynos5433: Add clocks using common clock framework
clk: samsung: exynos5433: Add MUX clocks of CMU_TOP domain
clk: samsung: exynos5433: Add clocks for CMU_PERIC domain
clk: samsung: exynos5433: Add clocks for CMU_PERIS domain
clk: samsung: exynos5433: Add clocks for CMU_G2D domain
clk: samsung: exynos5433: Add clocks for CMU_MIF domain
clk: samsung: exynos5433: Add clocks for CMU_DISP domain
clk: samsung: exynos5433: Add clocks for CMU_AUD domain
clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain
clk: samsung: exynos5433: Add clocks for CMU_G3D domain
clk: samsung: exynos5433: Add clocks for CMU_GSCL domain
clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
clk: samsung: exynos5433: Add clocks for CMU_ATLAS domain
clk: samsung: exynos5433: Add clocks for CMU_MSCL domain
clk: samsung: exynos5433: Add clocks for CMU_MFC domain
clk: samsung: exynos5433: Add clocks for CMU_HEVC domain
clk: samsung: exynos5433: Add clocks for CMU_ISP domain
clk: samsung: exynos5433: Add clocks for CMU_CAM0 domain
clk: samsung: exynos5433: Add clocks for CMU_CAM1 domain
clk: samsung: exynos5433: Move CLK_SCLK_HDMI_SPDIF_DISP clock to CMU_TOP
domain
Inha Song (1):
clk: samsung: Add CLKOUT driver support for Exynos5433 SoC
.../devicetree/bindings/clock/exynos5433-clock.txt | 462 ++
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos-clkout.c|2 +
drivers/clk/samsung/clk-exynos5433.c | 5423
include/dt-bindings/clock/exynos5433.h | 1403 +
5 files changed, 7291 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5433-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5433.c
create mode 100644 include/dt-bindings/clock/exynos5433.h
--
Regards
Sylwester
--
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
