Re: [PATCH v2 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
On 2015년 06월 12일 18:05, Marek Szyprowski wrote:
Hello,
On 2015-06-11 17:04, Inki Dae wrote:
On 2015년 06월 03일 17:26, Marek Szyprowski wrote:
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 96618534358e..3ec9d4299a86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -242,12 +242,21 @@ static void
fimd_enable_shadow_channel_path(struct fimd_context *ctx,
writel(val, ctx-regs + SHADOWCON);
}
+static int fimd_enable_vblank(struct exynos_drm_crtc *crtc);
+static void fimd_disable_vblank(struct exynos_drm_crtc *crtc);
You can remove abvoe declarations. See the below comment.
+
static void fimd_clear_channel(struct fimd_context *ctx)
{
unsigned int win, ch_enabled = 0;
DRM_DEBUG_KMS(%s\n, __FILE__);
+/* Hardware is in unknown state, so ensure it gets enabled
properly */
+pm_runtime_get_sync(ctx-dev);
+
+clk_prepare_enable(ctx-bus_clk);
+clk_prepare_enable(ctx-lcd_clk);
+
/* Check if any channel is enabled. */
for (win = 0; win WINDOWS_NR; win++) {
u32 val = readl(ctx-regs + WINCON(win));
@@ -265,12 +274,17 @@ static void fimd_clear_channel(struct
fimd_context *ctx)
/* Wait for vsync, as disable channel takes effect at next
vsync */
if (ch_enabled) {
-unsigned int state = ctx-suspended;
-
-ctx-suspended = 0;
+ctx-suspended = false;
+fimd_enable_vblank(ctx-crtc);
I think you can call enable_vblank callback instead of
fimd_enable_vblank function because ctx object has exynos_crtc object.
i.e.,
struct exynos_drm_crtc_ops *ops = ctx-crtc-ops;
...
if (ops-enable_vblank)
ops-enable_vblank(ctx-crtc);
...
Well, I don't like such indirect calls to known functions, but if you
prefer
this approach I will send an updated patch in a minute. There is also
alternative
way of getting rid of forward declarations. Code of fimd_enable_vblank and
fimd_disable_vblank can be moved closer to fimd_wait_vblank function.
I will also send such alternative patch. Feel free to select the one
that better
fits your preferences.
Latter one it's better.
Thanks,
Inki Dae
fimd_wait_for_vblank(ctx-crtc);
-ctx-suspended = state;
+fimd_disable_vblank(ctx-crtc);
Ditto.
Thanks,
Inki Dae
+ctx-suspended = true;
}
+
+clk_disable_unprepare(ctx-lcd_clk);
+clk_disable_unprepare(ctx-bus_clk);
+
+pm_runtime_put(ctx-dev);
}
static int fimd_iommu_attach_devices(struct fimd_context *ctx,
Best regards
--
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 v3 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changelog:
v3:
- replaced forward declaration and calls to fimd_{enable,disable}_vblank
functions by calls throught ctrt ops
v2:
- rebased onto latest exynos-drm-next branch with atomic mode setting
patches applied.
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 96618534358e..c67bb6b97399 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -248,6 +248,12 @@ static void fimd_clear_channel(struct fimd_context *ctx)
DRM_DEBUG_KMS(%s\n, __FILE__);
+ /* Hardware is in unknown state, so ensure it gets enabled properly */
+ pm_runtime_get_sync(ctx-dev);
+
+ clk_prepare_enable(ctx-bus_clk);
+ clk_prepare_enable(ctx-lcd_clk);
+
/* Check if any channel is enabled. */
for (win = 0; win WINDOWS_NR; win++) {
u32 val = readl(ctx-regs + WINCON(win));
@@ -265,12 +271,22 @@ static void fimd_clear_channel(struct fimd_context *ctx)
/* Wait for vsync, as disable channel takes effect at next vsync */
if (ch_enabled) {
- unsigned int state = ctx-suspended;
-
- ctx-suspended = 0;
- fimd_wait_for_vblank(ctx-crtc);
- ctx-suspended = state;
+ const struct exynos_drm_crtc_ops *ops = ctx-crtc-ops;
+
+ ctx-suspended = false;
+ if (ops-enable_vblank)
+ ops-enable_vblank(ctx-crtc);
+ if (ops-wait_for_vblank)
+ ops-wait_for_vblank(ctx-crtc);
+ if (ops-disable_vblank)
+ ops-disable_vblank(ctx-crtc);
+ ctx-suspended = true;
}
+
+ clk_disable_unprepare(ctx-lcd_clk);
+ clk_disable_unprepare(ctx-bus_clk);
+
+ pm_runtime_put(ctx-dev);
}
static int fimd_iommu_attach_devices(struct fimd_context *ctx,
--
1.9.2
--
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 v3 (alternative) 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changelog:
v3 (alternative):
- araranged code by moving fimd_{enable,disable}_vblank functions before
fimd_clear_channel to avoid forward declaration usage
v2:
- rebased onto latest exynos-drm-next branch with atomic mode setting
patches applied.
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 130 +--
1 file changed, 71 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 96618534358e..f490895a8b02 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -196,6 +196,62 @@ static inline struct fimd_driver_data
*drm_fimd_get_driver_data(
return (struct fimd_driver_data *)of_id-data;
}
+static int fimd_enable_vblank(struct exynos_drm_crtc *crtc)
+{
+ struct fimd_context *ctx = crtc-ctx;
+ u32 val;
+
+ if (ctx-suspended)
+ return -EPERM;
+
+ if (!test_and_set_bit(0, ctx-irq_flags)) {
+ val = readl(ctx-regs + VIDINTCON0);
+
+ val |= VIDINTCON0_INT_ENABLE;
+
+ if (ctx-i80_if) {
+ val |= VIDINTCON0_INT_I80IFDONE;
+ val |= VIDINTCON0_INT_SYSMAINCON;
+ val = ~VIDINTCON0_INT_SYSSUBCON;
+ } else {
+ val |= VIDINTCON0_INT_FRAME;
+
+ val = ~VIDINTCON0_FRAMESEL0_MASK;
+ val |= VIDINTCON0_FRAMESEL0_VSYNC;
+ val = ~VIDINTCON0_FRAMESEL1_MASK;
+ val |= VIDINTCON0_FRAMESEL1_NONE;
+ }
+
+ writel(val, ctx-regs + VIDINTCON0);
+ }
+
+ return 0;
+}
+
+static void fimd_disable_vblank(struct exynos_drm_crtc *crtc)
+{
+ struct fimd_context *ctx = crtc-ctx;
+ u32 val;
+
+ if (ctx-suspended)
+ return;
+
+ if (test_and_clear_bit(0, ctx-irq_flags)) {
+ val = readl(ctx-regs + VIDINTCON0);
+
+ val = ~VIDINTCON0_INT_ENABLE;
+
+ if (ctx-i80_if) {
+ val = ~VIDINTCON0_INT_I80IFDONE;
+ val = ~VIDINTCON0_INT_SYSMAINCON;
+ val = ~VIDINTCON0_INT_SYSSUBCON;
+ } else
+ val = ~VIDINTCON0_INT_FRAME;
+
+ writel(val, ctx-regs + VIDINTCON0);
+ }
+}
+
static void fimd_wait_for_vblank(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc-ctx;
@@ -248,6 +304,12 @@ static void fimd_clear_channel(struct fimd_context *ctx)
DRM_DEBUG_KMS(%s\n, __FILE__);
+ /* Hardware is in unknown state, so ensure it gets enabled properly */
+ pm_runtime_get_sync(ctx-dev);
+
+ clk_prepare_enable(ctx-bus_clk);
+ clk_prepare_enable(ctx-lcd_clk);
+
/* Check if any channel is enabled. */
for (win = 0; win WINDOWS_NR; win++) {
u32 val = readl(ctx-regs + WINCON(win));
@@ -265,12 +327,17 @@ static void fimd_clear_channel(struct fimd_context *ctx)
/* Wait for vsync, as disable channel takes effect at next vsync */
if (ch_enabled) {
- unsigned int state = ctx-suspended;
-
- ctx-suspended = 0;
+ ctx-suspended = false;
+ fimd_enable_vblank(ctx-crtc);
fimd_wait_for_vblank(ctx-crtc);
- ctx-suspended = state;
+ fimd_disable_vblank(ctx-crtc);
+ ctx-suspended = true;
}
+
+ clk_disable_unprepare(ctx-lcd_clk);
+ clk_disable_unprepare(ctx-bus_clk);
+
+ pm_runtime_put(ctx-dev);
}
static int fimd_iommu_attach_devices(struct fimd_context *ctx,
@@ -434,61 +501,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
writel(val, ctx-regs + VIDCON0);
}
-static int fimd_enable_vblank(struct exynos_drm_crtc *crtc)
-{
- struct fimd_context *ctx = crtc-ctx;
- u32 val;
-
- if (ctx-suspended)
- return -EPERM;
-
- if (!test_and_set_bit(0, ctx-irq_flags)) {
- val = readl(ctx-regs + VIDINTCON0);
-
- val |= VIDINTCON0_INT_ENABLE;
-
- if (ctx-i80_if) {
- val |= VIDINTCON0_INT_I80IFDONE;
- val |= VIDINTCON0_INT_SYSMAINCON;
- val = ~VIDINTCON0_INT_SYSSUBCON;
- } else {
- val
Re: [PATCH 2/3] ARM: dts: fix the clock-frequency of rinato board's panel
2015-06-12 18:27 GMT+09:00 Hyungwon Hwang human.hw...@samsung.com: On Fri, 12 Jun 2015 18:23:18 +0900 Krzysztof Kozlowski k.kozlow...@samsung.com wrote: 2015-06-12 18:03 GMT+09:00 Hyungwon Hwang human.hw...@samsung.com: Because of recent update, proper clock-frequency becomes mandatory for validating the mode of panel. This clock-frequency must be set appropriately for getting required frame rate. Signed-off-by: Hyungwon Hwang human.hw...@samsung.com Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com Is it a bugfix? The property is mandatory right now? With recent kernel, yes. It is mandatory for the mode to be become available. So it looks like bugfix. Can you resend the patch with: 1. cc-stable and fixes tags, 2. observable bug/issue/error (error from dmesg would be enough)? It looks quite similar to 242ddf0429 Best regards, Krzysztof -- 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 3/3] drm/exynos: initialize VIDCON0 when fimd is disabled
When the fimd is disabled by fimd_disable(), enabled overlay layers also are disabled. If clocks for fimd are enabled by fimd_enable() on this case, it can lead IOMMU page fault. The reason is that VIDCON0_ENVID and VIDCON0_ENVID_F bits of VIDCON0 register are set still even though fimd is disabled, so it may continue display output of prior when clocks for fimd are enabled again. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index b45e09b..3b0e0f6 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -791,6 +791,8 @@ static void fimd_disable(struct exynos_drm_crtc *crtc) for (i = 0; i WINDOWS_NR; i++) fimd_win_disable(crtc, i); + writel(0, ctx-regs + VIDCON0); + clk_disable_unprepare(ctx-lcd_clk); clk_disable_unprepare(ctx-bus_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
Re: [PATCH v2 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
Hello,
On 2015-06-11 17:04, Inki Dae wrote:
On 2015년 06월 03일 17:26, Marek Szyprowski wrote:
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 96618534358e..3ec9d4299a86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -242,12 +242,21 @@ static void fimd_enable_shadow_channel_path(struct
fimd_context *ctx,
writel(val, ctx-regs + SHADOWCON);
}
+static int fimd_enable_vblank(struct exynos_drm_crtc *crtc);
+static void fimd_disable_vblank(struct exynos_drm_crtc *crtc);
You can remove abvoe declarations. See the below comment.
+
static void fimd_clear_channel(struct fimd_context *ctx)
{
unsigned int win, ch_enabled = 0;
DRM_DEBUG_KMS(%s\n, __FILE__);
+ /* Hardware is in unknown state, so ensure it gets enabled properly */
+ pm_runtime_get_sync(ctx-dev);
+
+ clk_prepare_enable(ctx-bus_clk);
+ clk_prepare_enable(ctx-lcd_clk);
+
/* Check if any channel is enabled. */
for (win = 0; win WINDOWS_NR; win++) {
u32 val = readl(ctx-regs + WINCON(win));
@@ -265,12 +274,17 @@ static void fimd_clear_channel(struct fimd_context *ctx)
/* Wait for vsync, as disable channel takes effect at next vsync */
if (ch_enabled) {
- unsigned int state = ctx-suspended;
-
- ctx-suspended = 0;
+ ctx-suspended = false;
+ fimd_enable_vblank(ctx-crtc);
I think you can call enable_vblank callback instead of
fimd_enable_vblank function because ctx object has exynos_crtc object.
i.e.,
struct exynos_drm_crtc_ops *ops = ctx-crtc-ops;
...
if (ops-enable_vblank)
ops-enable_vblank(ctx-crtc);
...
Well, I don't like such indirect calls to known functions, but if you prefer
this approach I will send an updated patch in a minute. There is also
alternative
way of getting rid of forward declarations. Code of fimd_enable_vblank and
fimd_disable_vblank can be moved closer to fimd_wait_vblank function.
I will also send such alternative patch. Feel free to select the one
that better
fits your preferences.
fimd_wait_for_vblank(ctx-crtc);
- ctx-suspended = state;
+ fimd_disable_vblank(ctx-crtc);
Ditto.
Thanks,
Inki Dae
+ ctx-suspended = true;
}
+
+ clk_disable_unprepare(ctx-lcd_clk);
+ clk_disable_unprepare(ctx-bus_clk);
+
+ pm_runtime_put(ctx-dev);
}
static int fimd_iommu_attach_devices(struct fimd_context *ctx,
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
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/3] ARM: dts: Add the reference node for syscon to mipi phy for Exynos3250
2015-06-12 18:03 GMT+09:00 Hyungwon Hwang human.hw...@samsung.com: Exynos mipi phy driver needs syscon node to be probed successfully. Signed-off-by: Hyungwon Hwang human.hw...@samsung.com --- arch/arm/boot/dts/exynos3250.dtsi | 1 + 1 file changed, 1 insertion(+) Thanks for the patch but actually Beata Michalska (+CC) sent it also before [0]. The only thing stopping from applying this was 'reg' field which should be removed. However I am still waiting for that resubmit. [0] http://linux-arm-kernel.infradead.narkive.com/tGUK806c/patch-arm-dts-update-video-phy-node-with-syscon-phandle-for-exynos3250 Best regards, Krzysztof -- 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/3] ARM: dts: fix the clock-frequency of rinato board's panel
2015-06-12 18:03 GMT+09:00 Hyungwon Hwang human.hw...@samsung.com: Because of recent update, proper clock-frequency becomes mandatory for validating the mode of panel. This clock-frequency must be set appropriately for getting required frame rate. Signed-off-by: Hyungwon Hwang human.hw...@samsung.com Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com Is it a bugfix? The property is mandatory right now? Best regards, Krzysztof -- 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 2/3] ARM: dts: fix the clock-frequency of rinato board's panel
Because of recent update, proper clock-frequency becomes mandatory
for validating the mode of panel. This clock-frequency must be set
appropriately for getting required frame rate.
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b99068..75aba40 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -181,7 +181,7 @@
display-timings {
timing-0 {
- clock-frequency = 0;
+ clock-frequency = 460;
hactive = 320;
vactive = 320;
hfront-porch = 1;
--
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 2/3] ARM: dts: fix the clock-frequency of rinato board's panel
On Fri, 12 Jun 2015 18:23:18 +0900 Krzysztof Kozlowski k.kozlow...@samsung.com wrote: 2015-06-12 18:03 GMT+09:00 Hyungwon Hwang human.hw...@samsung.com: Because of recent update, proper clock-frequency becomes mandatory for validating the mode of panel. This clock-frequency must be set appropriately for getting required frame rate. Signed-off-by: Hyungwon Hwang human.hw...@samsung.com Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com Is it a bugfix? The property is mandatory right now? With recent kernel, yes. It is mandatory for the mode to be become available. Best regards, Hyungwon Hwang Best regards, Krzysztof -- 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 2/3] drm/exynos: remove chained calls to enable
With atomic modesetting all the control for CRTC, Planes, Encoders and
Connectors should come from DRM core, so the driver is not allowed to
enable or disable planes from inside the crtc_enable()/disable() call.
But it needs to disable planes with crtc_disable in exynos driver
internally. Because crtc is disabled before plane is disabled, it means
plane_disable just returns without any register changes, then we cannot
be sure setting register to disable plane when crtc is disable.
This patch removes this chainned calls to enable plane from exynos hw
drivers code letting only DRM core touch planes except to disable plane.
Also it leads eliminable enabled and resume of struct exynos_drm_plane.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Tested-by: Marek Szyprowski m.szyprow...@samsung.com
---
This patch was modified from original patch of Gustavo Padovan -
http://www.spinics.net/lists/linux-samsung-soc/msg45351.html
v2 changes:
- add 1/3 additional patch to remove waiting vblank in mixer.
- rebase this from 1/3 patch.
- add 3/3 additional patch to fix IOMMU page fault of fimd.
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 63 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 5 ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 63 +++---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 27 -
drivers/gpu/drm/exynos/exynos_mixer.c | 38 ++
5 files changed, 16 insertions(+), 180 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..f73ceae 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -410,11 +410,8 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
plane = ctx-planes[win];
- /* If suspended, enable this on resume */
- if (ctx-suspended) {
- plane-resume = true;
+ if (ctx-suspended)
return;
- }
/*
* SHADOWCON/PRTCON register is used for enabling timing.
@@ -506,8 +503,6 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
val = readl(ctx-regs + DECON_UPDATE);
val |= DECON_UPDATE_STANDALONE_F;
writel(val, ctx-regs + DECON_UPDATE);
-
- plane-enabled = true;
}
static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
@@ -521,11 +516,8 @@ static void decon_win_disable(struct exynos_drm_crtc
*crtc, unsigned int win)
plane = ctx-planes[win];
- if (ctx-suspended) {
- /* do not resume this window*/
- plane-resume = false;
+ if (ctx-suspended)
return;
- }
/* protect windows */
decon_shadow_protect_win(ctx, win, true);
@@ -541,49 +533,6 @@ static void decon_win_disable(struct exynos_drm_crtc
*crtc, unsigned int win)
val = readl(ctx-regs + DECON_UPDATE);
val |= DECON_UPDATE_STANDALONE_F;
writel(val, ctx-regs + DECON_UPDATE);
-
- plane-enabled = false;
-}
-
-static void decon_window_suspend(struct decon_context *ctx)
-{
- struct exynos_drm_plane *plane;
- int i;
-
- for (i = 0; i WINDOWS_NR; i++) {
- plane = ctx-planes[i];
- plane-resume = plane-enabled;
- if (plane-enabled)
- decon_win_disable(ctx-crtc, i);
- }
-}
-
-static void decon_window_resume(struct decon_context *ctx)
-{
- struct exynos_drm_plane *plane;
- int i;
-
- for (i = 0; i WINDOWS_NR; i++) {
- plane = ctx-planes[i];
- plane-enabled = plane-resume;
- plane-resume = false;
- }
-}
-
-static void decon_apply(struct decon_context *ctx)
-{
- struct exynos_drm_plane *plane;
- int i;
-
- for (i = 0; i WINDOWS_NR; i++) {
- plane = ctx-planes[i];
- if (plane-enabled)
- decon_win_commit(ctx-crtc, i);
- else
- decon_win_disable(ctx-crtc, i);
- }
-
- decon_commit(ctx-crtc);
}
static void decon_init(struct decon_context *ctx)
@@ -625,14 +574,13 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
if (test_and_clear_bit(0, ctx-irq_flags))
decon_enable_vblank(ctx-crtc);
- decon_window_resume(ctx);
-
- decon_apply(ctx);
+ decon_commit(ctx-crtc);
}
static void decon_disable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc-ctx;
+ int i;
if (ctx-suspended)
return;
@@ -642,7 +590,8 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
* suspend that connector. Otherwise we might try to scan from
* a destroyed buffer later.
*/
- decon_window_suspend(ctx);
[PATCH v2 1/3] drm/exynos: remove to call mixer_wait_for_vblank
The reason waiting vblank is to be power gated and disabled clocks after dma operation is completed. The dma operation is stopped already before be power gated and clocks are disabled when mixer is disabled by commit 381be025ac1a6(drm/exynos: stop mixer before gating clocks during poweroff). Don't need to wait vblank anymore. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- drivers/gpu/drm/exynos/exynos_mixer.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 6bab717..f93f038 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1010,7 +1010,6 @@ static void mixer_window_suspend(struct mixer_context *ctx) plane-resume = plane-enabled; mixer_win_disable(ctx-crtc, i); } - mixer_wait_for_vblank(ctx-crtc); } static void mixer_window_resume(struct mixer_context *ctx) -- 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
[PATCH 1/3] ARM: dts: Add the reference node for syscon to mipi phy for Exynos3250
Exynos mipi phy driver needs syscon node to be probed successfully.
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index e3bfb11..f8c02dd 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -140,6 +140,7 @@
compatible = samsung,s5pv210-mipi-video-phy;
reg = 0x10020710 8;
#phy-cells = 1;
+ syscon = pmu_system_controller;
};
pd_cam: cam-power-domain@10023C00 {
--
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 01/15] ARM: kill off set_irq_flags usage
On 10.06.2015 03:26, Rob Herring wrote: set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID - !IRQ_NOREQUEST IRQF_PROBE - !IRQ_NOPROBE IRQF_NOAUTOEN - IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also set IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring r...@kernel.org Cc: Russell King li...@arm.linux.org.uk Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Cc: Gregory Clement gregory.clem...@free-electrons.com Cc: Hans Ulli Kroll ulli.kr...@googlemail.com Cc: Shawn Guo shawn@linaro.org Cc: Sascha Hauer ker...@pengutronix.de Cc: Imre Kaloz ka...@openwrt.org Cc: Krzysztof Halasa khal...@piap.pl Cc: Greg Ungerer g...@uclinux.org Cc: Roland Stigge sti...@antcom.de Cc: Tony Lindgren t...@atomide.com Cc: Daniel Mack dan...@zonque.org Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: Robert Jarzmik robert.jarz...@free.fr Cc: Simtec Linux Team li...@simtec.co.uk Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Wan ZongShun mcuos@gmail.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org --- arch/arm/common/it8152.c | 2 +- arch/arm/common/locomo.c | 2 +- arch/arm/common/sa.c | 4 ++-- arch/arm/mach-davinci/cp_intc.c | 2 +- arch/arm/mach-dove/irq.c | 2 +- arch/arm/mach-ebsa110/core.c | 2 +- arch/arm/mach-footbridge/common.c| 2 +- arch/arm/mach-footbridge/isa-irq.c | 8 arch/arm/mach-gemini/gpio.c | 2 +- arch/arm/mach-gemini/irq.c | 2 +- arch/arm/mach-imx/3ds_debugboard.c | 2 +- arch/arm/mach-imx/mach-mx31ads.c | 2 +- arch/arm/mach-iop13xx/irq.c | 2 +- arch/arm/mach-iop32x/irq.c | 2 +- arch/arm/mach-iop33x/irq.c | 2 +- arch/arm/mach-ixp4xx/common.c| 2 +- arch/arm/mach-ks8695/irq.c | 2 +- arch/arm/mach-lpc32xx/irq.c | 2 +- arch/arm/mach-netx/generic.c | 2 +- arch/arm/mach-omap1/fpga.c | 2 +- arch/arm/mach-omap1/irq.c| 2 +- arch/arm/mach-pxa/balloon3.c | 2 +- arch/arm/mach-pxa/irq.c | 1 - arch/arm/mach-pxa/lpd270.c | 2 +- arch/arm/mach-pxa/pcm990-baseboard.c | 2 +- arch/arm/mach-pxa/pxa3xx.c | 2 +- arch/arm/mach-pxa/viper.c| 2 +- arch/arm/mach-pxa/zeus.c | 2 +- arch/arm/mach-rpc/ecard.c| 2 +- arch/arm/mach-rpc/irq.c | 16 arch/arm/mach-s3c24xx/bast-irq.c | 2 +- arch/arm/mach-s3c64xx/common.c | 2 +- arch/arm/mach-sa1100/irq.c | 1 - arch/arm/mach-sa1100/neponset.c | 4 ++-- arch/arm/mach-w90x900/irq.c | 2 +- 35 files changed, 45 insertions(+), 47 deletions(-) For the s3c24xx and s3c64xx it looks fine: Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof -- 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 00/21] On-demand device registration
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.06.2015 um 14:30 schrieb Linus Walleij: Certainly it is possible to create deadlocks in this scenario, but the scope is not to create an ubreakable system. IAnd what happens if you run into a deadlock? Do you print you've lost, try changing your kernel config in some output hidden by a splash-screen? ;) Sorry it sounds like a blanket argument, the fact that there are mutexes in the kernel makes it possible to deadlock, it doesn't mean we don't use mutexes. Some programming problems are just like such. Yours, Linus Walleij -- 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 v10 00/17] drm/exynos: atomic modesetting support
On 06/11/2015 11:01 PM, Gustavo Padovan wrote: Hi Joonyoung, 2015-06-11 Joonyoung Shim jy0922.s...@samsung.com: On 06/10/2015 10:36 PM, Gustavo Padovan wrote: Hi Marek, 2015-06-10 Marek Szyprowski m.szyprow...@samsung.com: Hello, On 2015-06-01 17:04, Gustavo Padovan wrote: From: Gustavo Padovan gustavo.pado...@collabora.co.uk Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. Thanks for this patchses, however I've noticed a problem after applying them. The issue gets revealed when support for IOMMU is enabled. I've did my tests with Exynos HDMI driver on Odroid U3 board. To demonstrated the issue I've added following additional debug in the exynos mixer driver in mixer_graph_buffer() function: pr_info(dma addr %pad plane-src_width %d plane-src_height %d\n, plane-dma_addr[0], plane-src_width, plane-src_height); Before applying patches setting 640x480 mode and getting back to 1920x1080 console generates following log: # modetest -M exynos -s 23:640x480 setting mode 640x480-60Hz@XR24 on connectors 23, crtc 21 [ 3860.617151] dma 0xbc50 plane-src_width 640 plane-src_height 480 ^C [ 3870.555232] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 [ 3870.565696] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 After applying atomic modesetting patchset: # modetest -M exynos -s 24:640x480 [ 142.540122] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 [ 142.550726] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 setting mode 640x480-60Hz@XR24 on connectors 24, crtc 22 [ 142.643672] dma 0xbc50 plane-src_width 1920 plane-src_height 1080 [ 142.759982] dma 0xbc50 plane-src_width 640 plane-src_height 480 ^C [ 154.986040] dma 0xbbd0 plane-src_width 1920 plane-src_height 1080 As you can see from the above log, mixer_graph_buffer function is called several times. 0xbbd0 is the DMA address of the 1920x1080 framebuffer and 0xbc50 is the DMA address of the allocated 640x480 buffer. mixer_graph_buffer() is first called with the new DMA address of the framebuffer, but with the old mode parameters (1920x1080 size) and then in the next call it updates the plane parameters to the correct values (size changed to 640x480). When IOMMU is not used, this can be easily missed, but after enabling IOMMU support, any DMA access to unallocated address causes IOMMU PAGE FAULT. Here it will happen after changing DMA address of the buffer without changing the size. A quick workaround to resolve this multiple calls to mixer_graph_buffer() with partially updated mode values is to remove calls to mixer_window_suspend/mixer_window_resume from mixer_disable and mixer_disable functions, but I expect that this is not the right approach. Probably the same problem can be observed with Exynos FIMD driver. Gustavo: could you check if mixer_enable functions should really call mixer_window_resume function, which in turn calls mixer_win_commit, which calls mixer_graph_buffer with partially updated display buffer data? It should not, you are right. This is actually the correct fix. Atomic modesetting should not do chained calls, e.g., crtc_disable calling plane_disable. This change was already in my plan actually, but as I had IOMMU disabled I didn't see it here, and I didn't create this patch yet. Right, but it needs that crtc_disable calls plane_disable in exynos driver internally. Because crtc is disabled before plane is disabled, it means plane_disable just returns without any register changes, then we cannot be sure setting register to disable plane when crtc is disable. I think a solution is enough only to eliminate calling xxx_resume function in exynos driver function when enable plane, we can remove it because it's called to enable plane from drm atomic modeset framework. I think this should work. We really need to disable the planes before the crtc is disabled, for FIMD for example, the overlay planes are removed from the screen if we remove the _suspend call. I'll sent a new patch to remove only the resume part from all our crtc drivers. I sent patchset related, is it same with which you try? 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 v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hello Sudeep,
On 06/12/2015 01:54 PM, Sudeep Holla wrote:
On 12/06/15 12:27, Javier Martinez Canillas wrote:
Hello Sudeep,
Thanks a lot for the feedback.
On 06/12/2015 12:10 PM, Sudeep Holla wrote:
On 12/06/15 06:43, Javier Martinez Canillas wrote:
The Exynos interrupt combiner IP loses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Not sure if you need this. IMO it's not clean and redundant though I
admit many drivers do exactly same thing. I am trying to remove or point
out those redundant code as irqchip core has options/flags to do what
you need. I assume there are no wakeup sources connected to this
Yes, there are wakeup sources connected to this combiner. As Krzysztof
said some wakeup sources use a GPIO line as IRQ whose interrupt parent
is the combiner. As an example the Power gpio-key and cros_ec keyboard
for both Exynos5250 Snow and Exynos5420 Peach Pit/Pi.
Both drivers/input/keyboard/gpio_keysc and drivers/mfd/cros_ec.c do the
right thing though and call {enable,disable}_irq_wake() on the S2R path.
And in fact, the peripherals resume the system after a suspend but after
resume, interrupts are not triggered anymore.
I agree for the wakeup source, but I need to go through the irqchip core
again to understand this better.
combiner. Setting irqchip flags should solve this problem. A
simple patch below should do the job ?
I don't see how the below patch is going to work for the case I'm
trying to solve. If I understand correctly, the
IRQCHIP_MASK_ON_SUSPEND flag is used to force masking non wakeup
interrupt in the suspend path (instead of just disabling the
interrupts on suspend and not masking at the hardware level)
It also takes re-enables all the IRQs in the resume path that were
disabled on the suspend path.
Ok, I only saw that a call to mask_irq was made in suspend_device_irq [0]
if IRQCHIP_MASK_ON_SUSPEND was set but I didn't see the inverse operation
in the resume path. But now looking at irq_enable() I see that the IRQ is
unmasked if it was disabled so that's why is not needed.
But my problem is not about interrupts needed to be masked on suspend
but the opposite, that interrupts have to be unmasked on resume since
the IP loses its state so after a resume, interrupts are not
triggered anymore.
As I mentioned above this happens for all non-wake up interrupts.
However this needs to done for wake up interrupts IIUC. BTW if these
Well both interrupts that are a wakeup source and those that are not,
don't work after a resume. IOW, all the interrupts whose source is the
combiner are not working.
registers are lost assuming the combiner was powered down, even the
status register will be lost and you will not know exactly the wakeup
reason right ?
Good question, I didn't find in the documentation I've access to that
this happen but just found through experimentation that the IRQ enable
set register values are lost after a resume and that saving/restoring
the values makes the interrupts to be triggered again.
So I also don't see how implementing irq_set_wake() as you suggested
is going to work. Maybe we need a IRQCHIP_UNMASK_ON_RESUME flag for
this case?
IIRC these combiner feeds to main interrupt controller and you need to
make sure that interrupt is set as wakeup if required. Right ? so you
may still need irq_set_wake IMO.
Yes, I agree that is good to have a irq_set_wake callback, what is still
not clear to me is if is needed to solve this particular issue or not.
Regards,
Sudeep
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/kernel/irq/pm.c#L90
--
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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
On 12.06.2015 19:10, Sudeep Holla wrote:
On 12/06/15 06:43, Javier Martinez Canillas wrote:
The Exynos interrupt combiner IP loses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Not sure if you need this. IMO it's not clean and redundant though I
admit many drivers do exactly same thing. I am trying to remove or point
out those redundant code as irqchip core has options/flags to do what
you need. I assume there are no wakeup sources connected to this
combiner.
It may have wake up sources connected. Correct me if I am wrong but (at
least) on Exynos5250 combiner takes care of gpx1 GPIO pins which may be
external interrupts (e.g. power key on Exynos5250 Snow). I didn't check
other boards.
Best regards,
Krzysztof
Setting irqchip flags should solve this problem. A simple
patch below should do the job ?
--8
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..c0bcec59f829 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -111,6 +111,7 @@ static struct irq_chip combiner_chip = {
#ifdef CONFIG_SMP
.irq_set_affinity = combiner_set_affinity,
#endif
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
--
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 00/21] On-demand device registration
Am 12.06.2015 um 13:19 schrieb Alexander Holler: Am 12.06.2015 um 09:25 schrieb Linus Walleij: On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.06.2015 um 14:30 schrieb Linus Walleij: Certainly it is possible to create deadlocks in this scenario, but the scope is not to create an ubreakable system. IAnd what happens if you run into a deadlock? Do you print you've lost, try changing your kernel config in some output hidden by a splash-screen? ;) Sorry it sounds like a blanket argument, the fact that there are mutexes in the kernel makes it possible to deadlock, it doesn't mean we don't use mutexes. Some programming problems are just like such. I'm not talking about specific deadlocks through mutexes. I'm talking about what happens when driver A needs driver B which needs driver A. How do you recognise and handle that with your instrumented on-demand device initialization? Such a circular dependency might happen by just adding a new fucntion call or by changing the kernel configuration. And with the on-demand stuff, the possibility that the developer introducing this new (maybe optional) call will never hit such a circular dependency is high. So you will end up with a never ending stream of problem reports whenever someone introduced such a circular dependecy without having noticed it. And to come back to specific deadlocks, if you are extending function calls from something former simple to something which might initialize a whole bunch of drivers, needing maybe seconds, I wouldn't say this is a blanket argument, but a real thread. Keep in mind, that the possibility that a function call ends up with initializing a whole bunch of other drivers, is not determined statically, but depends on the configuration and runtime behaviour of the actual system the on-demand stuff actually happens. E.g. if driver A is faster one system that driver B, the whole bunch of drivers might become initialized by a call in driver A. But if driver B was faster on the developers system (or the system is configured to first init driver B), than the whole bunch of drivers might have become initialized by driver B on the developers system. Thus he never might have hit a possible problem when the whole bunch of drivers got initialized in driver A. That means it isn't always a good idea to create dynamic systems (like on-demand device initialization), because it's very hard to foresee and correctly handle their runtime behaviour. Alexander Holler -- 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: exynos4412: Audio dies after one day on kernel 4.0
On Wed, Jun 10, 2015 at 05:22:07PM +0900, Krzysztof Kozlowski wrote: I can now say for sure that the commits 88987d2c75 and aee4d1fac8 are the cause for the problem. Audio was working now for 7 days. +CC Vinod Gabriel, I sent a patch which should fix the issue. Could you give it a try? Of course don't revert the other patches and don't use other workarounds. Just apply the patch on clean (vanilla would be the best) kernel. [RFT PATCH] dmaengine: Fix choppy sound because of unimplemented resume I have already applied this one, can you check the -next and see if this issue is seen -- ~Vinod -- 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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
On 12/06/15 11:42, Krzysztof Kozlowski wrote: On 12.06.2015 19:10, Sudeep Holla wrote: On 12/06/15 06:43, Javier Martinez Canillas wrote: The Exynos interrupt combiner IP loses its state when the SoC enters into a low power state during a Suspend-to-RAM. This means that if a IRQ is used as a source, the interrupts for the devices are disabled when the system is resumed from a sleep state so are not triggered. Save the interrupt enable set register for each combiner group and restore it after resume to make sure that the interrupts are enabled. Not sure if you need this. IMO it's not clean and redundant though I admit many drivers do exactly same thing. I am trying to remove or point out those redundant code as irqchip core has options/flags to do what you need. I assume there are no wakeup sources connected to this combiner. It may have wake up sources connected. Correct me if I am wrong but (at least) on Exynos5250 combiner takes care of gpx1 GPIO pins which may be external interrupts (e.g. power key on Exynos5250 Snow). I didn't check other boards. In that case, this irqchip should implement irq_set_wake and the driver implementing power key should use enable_irq_wake in the suspend path. Just saving all the mask/enable registers is not scalable solution and also useless if it's just one or to interrupts that are very few IRQs registered/actively being used. Regards, Sudeep -- 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
Boot hangs after Starting kernel... message [odroid u3]
Hello everyone, I'm just trying to get my kernel built for my Odroid U3, but no matter whether I use 4.0.x or the latest code from arm-soc repository 4.1.0-rc3, it ends at this message during boot: ### U-Boot 2015.07-rc1-00408-g012681b (May 30 2015 - 17:49:11 +) CPU:Exynos4412@1000MHz Model: Odroid based on Exynos4412 DRAM: 2 GiB ERROR: regulator-name of dev: ldo18, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo19, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo23, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo24, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo26, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: buck9, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ldo20@VDDQ_EMMC_1.8V: set 180 uV; enabling ldo22@VDDQ_EMMC_2.8V: set 280 uV; enabling ldo21@TFLASH_2.8V: set 280 uV; enabling MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1 Net: No ethernet found. Hit any key to stop autoboot: 0 reading boot.scr 1143 bytes read in 18 ms (61.5 KiB/s) ## Executing script at 40408000 reading zImage-4.1 2497840 bytes read in 141 ms (16.9 MiB/s) reading exynos4412-odroidu3.dtb 54489 bytes read in 25 ms (2.1 MiB/s) Kernel image @ 0x40008000 [ 0x00 - 0x261d30 ] ## Flattened Device Tree blob at 41f0 Booting using the fdt blob at 0x41f0 reserving fdt memory region: addr=41f0 size=e000 Using Device Tree in place at 41f0, end 41f10fff Starting kernel ... ### The error messages during uboot loading just appear because there is something missing in it's RC, but don't think it is the reason, because a old build (3.19.x) just boots. Sadly my serial output does not give better error messages, so I'm asking here, because google'ing around didn't point me to any solutions. Do you have any hints why that happens? My .config can be found here - http://pastebin.com/qRLmtmmt . Is there a way to get early error messages during boot? 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 v3 (alternative) 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
On 2015년 06월 12일 18:07, Marek Szyprowski wrote:
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changelog:
v3 (alternative):
- araranged code by moving fimd_{enable,disable}_vblank functions before
fimd_clear_channel to avoid forward declaration usage
Marek,
For the iommu and atomic feature test, I merged below patches in
addition and tested them.
[PATCH v2 1/3] drm/exynos: remove to call mixer_wait_for_vblank
[PATCH v2 2/3] drm/exynos: remove chained calls to enable
[PATCH v2 3/3] drm/exynos: initialize VIDCON0 when fimd is disabled
However, I see below one warning log,
[1.227115] [drm] Initialized drm 1.1.0 20060810
[1.235852] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
vidi_component_ops)
[1.253548] [ cut here ]
[1.256700] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1718
drm_handle_vblank+0x2a0/0x308()
[1.265800] Modules linked in:
[1.268844] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-rc4-00574-gf8eb363-dirty #1412
[1.277085] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.283184] [c0015464] (unwind_backtrace) from [c00123c0]
(show_stack+0x10/0x14)
[1.288540] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[1.23] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[1.28] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.288891] [drm] No driver support for vblank timestamp query.
[1.288932] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[1.324248] [c00123c0] (show_stack) from [c0528f74]
(dump_stack+0x84/0xc4)
[1.331437] [c0528f74] (dump_stack) from [c00246ac]
(warn_slowpath_common+0x80/0xb0)
[1.339504] [c00246ac] (warn_slowpath_common) from [c0024778]
(warn_slowpath_null+0x1c/0x24)
[1.348270] [c0024778] (warn_slowpath_null) from [c029c898]
(drm_handle_vblank+0x2a0/0x308)
[1.356965] [c029c898] (drm_handle_vblank) from [c02b8c80]
(fimd_irq_handler+0x78/0xd0)
[1.365292] [c02b8c80] (fimd_irq_handler) from [c00608f8]
(handle_irq_event_percpu+0x78/0x134)
[1.374231] [c00608f8] (handle_irq_event_percpu) from [c00609f0]
(handle_irq_event+0x3c/0x5c)
[1.374244] [c00609f0] (handle_irq_event) from [c0063698]
(handle_level_irq+0xc4/0x13c)
[1.374256] [c0063698] (handle_level_irq) from [c005ff7c]
(generic_handle_irq+0x2c/0x3c)
[1.374269] [c005ff7c] (generic_handle_irq) from [c02214ec]
(combiner_handle_cascade_irq+0x94/0x100)
[1.374281] [c02214ec] (combiner_handle_cascade_irq) from
[c005ff7c] (generic_handle_irq+0x2c/0x3c)
[1.374290] [c005ff7c] (generic_handle_irq) from [c0060248]
(__handle_domain_irq+0x7c/0xec)
[1.374300] [c0060248] (__handle_domain_irq) from [c0009434]
(gic_handle_irq+0x30/0x68)
And below one page fault error when modetest is terminated,
# modetest -M exynos -v -s 31@29:720x1280
setting mode 720x1280-60Hz@XR24 on connectors 31, crtc 29
freq: 59.99Hz
[ 34.831025] PAGE FAULT occurred at 0x2040 by 11e2.sysmmu(Page
table base: 0x6e324000)
[ 34.838072] Lv1 entry: 0x6e92dc01
[ 34.841489] [ cut here ]
[ 34.846058] kernel BUG at drivers/iommu/exynos-iommu.c:364!
[ 34.851614] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 34.857428] Modules linked in:
[ 34.860472] CPU: 0 PID: 6 Comm: kworker/u8:0 Tainted: GW
4.1.0-rc4-00574-gf8eb363-dirty #1412
[ 34.870188] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 34.876273] Workqueue: events_unbound async_run_entry_fn
[ 34.881560] task: ee879540 ti: ee8a2000 task.ti: ee8a2000
[ 34.886946] PC is at exynos_sysmmu_irq+0x184/0x208
[ 34.891716] LR is at exynos_sysmmu_irq+0xd4/0x208
[ 34.896404] pc : [c02880d0]lr : [c0288020]psr: 6193
[ 34.896404] sp : ee8a3c00 ip : fp : eeacbc10
[ 34.907860] r10: c07c27ef r9 : 0204 r8 : 2040
[ 34.913068] r7 : ee324000 r6 : ee9b3428 r5 : ee9b3410 r4 :
[ 34.919577] r3 : 6e92dc01 r2 : 6e92dc01 r1 : eea55810 r0 : eeb0a000
[ 34.926089] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 34.933466] Control: 10c5387d Table: 6dd2c04a DAC: 0015
[ 34.939195] Process kworker/u8:0 (pid: 6, stack limit = 0xee8a2210)
[ 34.945444] Stack: (0xee8a3c00 to 0xee8a4000)
[ 34.949788] 3c00: ee8a3c0c c0049df8 6e324000 0003d4f3
ee9b13c0 ee84ad20
[ 34.957947] 3c20: 0026 ee84acc0 c00608f8 6093
eef84580 ee84acc0 ee84ad20
[ 34.966106]
Re: [PATCH v3 (alternative) 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
Hello,
On 2015-06-12 14:10, Inki Dae wrote:
On 2015년 06월 12일 18:07, Marek Szyprowski wrote:
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changelog:
v3 (alternative):
- araranged code by moving fimd_{enable,disable}_vblank functions before
fimd_clear_channel to avoid forward declaration usage
Marek,
For the iommu and atomic feature test, I merged below patches in
addition and tested them.
[PATCH v2 1/3] drm/exynos: remove to call mixer_wait_for_vblank
[PATCH v2 2/3] drm/exynos: remove chained calls to enable
[PATCH v2 3/3] drm/exynos: initialize VIDCON0 when fimd is disabled
However, I see below one warning log,
[1.227115] [drm] Initialized drm 1.1.0 20060810
[1.235852] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
vidi_component_ops)
[1.253548] [ cut here ]
[1.256700] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1718
drm_handle_vblank+0x2a0/0x308()
[1.265800] Modules linked in:
[1.268844] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-rc4-00574-gf8eb363-dirty #1412
[1.277085] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.283184] [c0015464] (unwind_backtrace) from [c00123c0]
(show_stack+0x10/0x14)
[1.288540] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[1.23] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[1.28] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.288891] [drm] No driver support for vblank timestamp query.
[1.288932] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[1.324248] [c00123c0] (show_stack) from [c0528f74]
(dump_stack+0x84/0xc4)
[1.331437] [c0528f74] (dump_stack) from [c00246ac]
(warn_slowpath_common+0x80/0xb0)
[1.339504] [c00246ac] (warn_slowpath_common) from [c0024778]
(warn_slowpath_null+0x1c/0x24)
[1.348270] [c0024778] (warn_slowpath_null) from [c029c898]
(drm_handle_vblank+0x2a0/0x308)
[1.356965] [c029c898] (drm_handle_vblank) from [c02b8c80]
(fimd_irq_handler+0x78/0xd0)
[1.365292] [c02b8c80] (fimd_irq_handler) from [c00608f8]
(handle_irq_event_percpu+0x78/0x134)
[1.374231] [c00608f8] (handle_irq_event_percpu) from [c00609f0]
(handle_irq_event+0x3c/0x5c)
[1.374244] [c00609f0] (handle_irq_event) from [c0063698]
(handle_level_irq+0xc4/0x13c)
[1.374256] [c0063698] (handle_level_irq) from [c005ff7c]
(generic_handle_irq+0x2c/0x3c)
[1.374269] [c005ff7c] (generic_handle_irq) from [c02214ec]
(combiner_handle_cascade_irq+0x94/0x100)
[1.374281] [c02214ec] (combiner_handle_cascade_irq) from
[c005ff7c] (generic_handle_irq+0x2c/0x3c)
[1.374290] [c005ff7c] (generic_handle_irq) from [c0060248]
(__handle_domain_irq+0x7c/0xec)
[1.374300] [c0060248] (__handle_domain_irq) from [c0009434]
(gic_handle_irq+0x30/0x68)
And below one page fault error when modetest is terminated,
# modetest -M exynos -v -s 31@29:720x1280
setting mode 720x1280-60Hz@XR24 on connectors 31, crtc 29
freq: 59.99Hz
[ 34.831025] PAGE FAULT occurred at 0x2040 by 11e2.sysmmu(Page
table base: 0x6e324000)
[ 34.838072] Lv1 entry: 0x6e92dc01
[ 34.841489] [ cut here ]
[ 34.846058] kernel BUG at drivers/iommu/exynos-iommu.c:364!
[ 34.851614] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 34.857428] Modules linked in:
[ 34.860472] CPU: 0 PID: 6 Comm: kworker/u8:0 Tainted: GW
4.1.0-rc4-00574-gf8eb363-dirty #1412
[ 34.870188] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 34.876273] Workqueue: events_unbound async_run_entry_fn
[ 34.881560] task: ee879540 ti: ee8a2000 task.ti: ee8a2000
[ 34.886946] PC is at exynos_sysmmu_irq+0x184/0x208
[ 34.891716] LR is at exynos_sysmmu_irq+0xd4/0x208
[ 34.896404] pc : [c02880d0]lr : [c0288020]psr: 6193
[ 34.896404] sp : ee8a3c00 ip : fp : eeacbc10
[ 34.907860] r10: c07c27ef r9 : 0204 r8 : 2040
[ 34.913068] r7 : ee324000 r6 : ee9b3428 r5 : ee9b3410 r4 :
[ 34.919577] r3 : 6e92dc01 r2 : 6e92dc01 r1 : eea55810 r0 : eeb0a000
[ 34.926089] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 34.933466] Control: 10c5387d Table: 6dd2c04a DAC: 0015
[ 34.939195] Process kworker/u8:0 (pid: 6, stack limit = 0xee8a2210)
[ 34.945444] Stack: (0xee8a3c00 to 0xee8a4000)
[ 34.949788] 3c00: ee8a3c0c c0049df8 6e324000 0003d4f3
ee9b13c0 ee84ad20
[ 34.957947] 3c20: 0026 ee84acc0 c00608f8 6093
eef84580
[PATCH v2] ARM: dts: fix the clock-frequency of rinato board's panel
After the commit abc0b1447d4974963548777a5ba4a4457c82c426
(drm: Perform basic sanity checks on probed modes), proper
clock-frequency becomes mandatory for validating the mode of panel.
The display does not work if there is no mode validated. Also, this
clock-frequency must be set appropriately for getting required frame
rate.
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b99068..75aba40 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -181,7 +181,7 @@
display-timings {
timing-0 {
- clock-frequency = 0;
+ clock-frequency = 460;
hactive = 320;
vactive = 320;
hfront-porch = 1;
--
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 00/21] On-demand device registration
Am 12.06.2015 um 09:25 schrieb Linus Walleij: On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.06.2015 um 14:30 schrieb Linus Walleij: Certainly it is possible to create deadlocks in this scenario, but the scope is not to create an ubreakable system. IAnd what happens if you run into a deadlock? Do you print you've lost, try changing your kernel config in some output hidden by a splash-screen? ;) Sorry it sounds like a blanket argument, the fact that there are mutexes in the kernel makes it possible to deadlock, it doesn't mean we don't use mutexes. Some programming problems are just like such. I'm not talking about specific deadlocks through mutexes. I'm talking about what happens when driver A needs driver B which needs driver A. How do you recognise and handle that with your instrumented on-demand device initialization? Such a circular dependency might happen by just adding a new fucntion call or by changing the kernel configuration. And with the on-demand stuff, the possibility that the developer introducing this new (maybe optional) call will never hit such a circular dependency is high. So you will end up with a never ending stream of problem reports whenever someone introduced such a circular dependecy without having noticed it. And to come back to specific deadlocks, if you are extending function calls from something former simple to something which might initialize a whole bunch of drivers, needing maybe seconds, I wouldn't say this is a blanket argument, but a real thread. Alexander Holler -- 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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hello Sudeep,
Thanks a lot for the feedback.
On 06/12/2015 12:10 PM, Sudeep Holla wrote:
On 12/06/15 06:43, Javier Martinez Canillas wrote:
The Exynos interrupt combiner IP loses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Not sure if you need this. IMO it's not clean and redundant though I
admit many drivers do exactly same thing. I am trying to remove or point
out those redundant code as irqchip core has options/flags to do what
you need. I assume there are no wakeup sources connected to this
Yes, there are wakeup sources connected to this combiner. As Krzysztof
said some wakeup sources use a GPIO line as IRQ whose interrupt parent
is the combiner. As an example the Power gpio-key and cros_ec keyboard
for both Exynos5250 Snow and Exynos5420 Peach Pit/Pi.
Both drivers/input/keyboard/gpio_keysc and drivers/mfd/cros_ec.c do the
right thing though and call {enable,disable}_irq_wake() on the S2R path.
And in fact, the peripherals resume the system after a suspend but after
resume, interrupts are not triggered anymore.
combiner. Setting irqchip flags should solve this problem. A simple
patch below should do the job ?
I don't see how the below patch is going to work for the case I'm trying to
solve. If I understand correctly, the IRQCHIP_MASK_ON_SUSPEND flag is used
to force masking non wakeup interrupt in the suspend path (instead of just
disabling the interrupts on suspend and not masking at the hardware level)
But my problem is not about interrupts needed to be masked on suspend but
the opposite, that interrupts have to be unmasked on resume since the IP
loses its state so after a resume, interrupts are not triggered anymore.
So I also don't see how implementing irq_set_wake() as you suggested is
going to work. Maybe we need a IRQCHIP_UNMASK_ON_RESUME flag for this case?
--8
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..c0bcec59f829 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -111,6 +111,7 @@ static struct irq_chip combiner_chip = {
#ifdef CONFIG_SMP
.irq_set_affinity = combiner_set_affinity,
#endif
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
Best regards,
Javier
--
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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
On 12/06/15 06:43, Javier Martinez Canillas wrote:
The Exynos interrupt combiner IP loses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Not sure if you need this. IMO it's not clean and redundant though I
admit many drivers do exactly same thing. I am trying to remove or point
out those redundant code as irqchip core has options/flags to do what
you need. I assume there are no wakeup sources connected to this
combiner. Setting irqchip flags should solve this problem. A simple
patch below should do the job ?
--8
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..c0bcec59f829 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -111,6 +111,7 @@ static struct irq_chip combiner_chip = {
#ifdef CONFIG_SMP
.irq_set_affinity = combiner_set_affinity,
#endif
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
--
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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
On 12/06/15 12:27, Javier Martinez Canillas wrote:
Hello Sudeep,
Thanks a lot for the feedback.
On 06/12/2015 12:10 PM, Sudeep Holla wrote:
On 12/06/15 06:43, Javier Martinez Canillas wrote:
The Exynos interrupt combiner IP loses its state when the SoC enters
into a low power state during a Suspend-to-RAM. This means that if a
IRQ is used as a source, the interrupts for the devices are disabled
when the system is resumed from a sleep state so are not triggered.
Save the interrupt enable set register for each combiner group and
restore it after resume to make sure that the interrupts are enabled.
Not sure if you need this. IMO it's not clean and redundant though I
admit many drivers do exactly same thing. I am trying to remove or point
out those redundant code as irqchip core has options/flags to do what
you need. I assume there are no wakeup sources connected to this
Yes, there are wakeup sources connected to this combiner. As Krzysztof
said some wakeup sources use a GPIO line as IRQ whose interrupt parent
is the combiner. As an example the Power gpio-key and cros_ec keyboard
for both Exynos5250 Snow and Exynos5420 Peach Pit/Pi.
Both drivers/input/keyboard/gpio_keysc and drivers/mfd/cros_ec.c do the
right thing though and call {enable,disable}_irq_wake() on the S2R path.
And in fact, the peripherals resume the system after a suspend but after
resume, interrupts are not triggered anymore.
I agree for the wakeup source, but I need to go through the irqchip core
again to understand this better.
combiner. Setting irqchip flags should solve this problem. A
simple patch below should do the job ?
I don't see how the below patch is going to work for the case I'm
trying to solve. If I understand correctly, the
IRQCHIP_MASK_ON_SUSPEND flag is used to force masking non wakeup
interrupt in the suspend path (instead of just disabling the
interrupts on suspend and not masking at the hardware level)
It also takes re-enables all the IRQs in the resume path that were
disabled on the suspend path.
But my problem is not about interrupts needed to be masked on suspend
but the opposite, that interrupts have to be unmasked on resume since
the IP loses its state so after a resume, interrupts are not
triggered anymore.
As I mentioned above this happens for all non-wake up interrupts.
However this needs to done for wake up interrupts IIUC. BTW if these
registers are lost assuming the combiner was powered down, even the
status register will be lost and you will not know exactly the wakeup
reason right ?
So I also don't see how implementing irq_set_wake() as you suggested
is going to work. Maybe we need a IRQCHIP_UNMASK_ON_RESUME flag for
this case?
IIRC these combiner feeds to main interrupt controller and you need to
make sure that interrupt is set as wakeup if required. Right ? so you
may still need irq_set_wake IMO.
Regards,
Sudeep
--
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: Boot hangs after Starting kernel... message [odroid u3]
Hello, On 2015-06-12 14:00, Thomas-Karl Pietrowski wrote: Hello everyone, I'm just trying to get my kernel built for my Odroid U3, but no matter whether I use 4.0.x or the latest code from arm-soc repository 4.1.0-rc3, it ends at this message during boot: ### U-Boot 2015.07-rc1-00408-g012681b (May 30 2015 - 17:49:11 +) CPU:Exynos4412@1000MHz Model: Odroid based on Exynos4412 DRAM: 2 GiB ERROR: regulator-name of dev: ldo18, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo19, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo23, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo24, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: ldo26, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ERROR: regulator-name of dev: buck9, has nonunique value: nc at drivers/power/regulator/regulator-uclass.c:294/regulator_post_bind() ldo20@VDDQ_EMMC_1.8V: set 180 uV; enabling ldo22@VDDQ_EMMC_2.8V: set 280 uV; enabling ldo21@TFLASH_2.8V: set 280 uV; enabling MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1 Net: No ethernet found. Hit any key to stop autoboot: 0 reading boot.scr 1143 bytes read in 18 ms (61.5 KiB/s) ## Executing script at 40408000 reading zImage-4.1 2497840 bytes read in 141 ms (16.9 MiB/s) reading exynos4412-odroidu3.dtb 54489 bytes read in 25 ms (2.1 MiB/s) Kernel image @ 0x40008000 [ 0x00 - 0x261d30 ] ## Flattened Device Tree blob at 41f0 Booting using the fdt blob at 0x41f0 reserving fdt memory region: addr=41f0 size=e000 Using Device Tree in place at 41f0, end 41f10fff Starting kernel ... ### The error messages during uboot loading just appear because there is something missing in it's RC, but don't think it is the reason, because a old build (3.19.x) just boots. Sadly my serial output does not give better error messages, so I'm asking here, because google'ing around didn't point me to any solutions. Do you have any hints why that happens? My .config can be found here - http://pastebin.com/qRLmtmmt . Is there a way to get early error messages during boot? Please goto 'Kernel hacking' page and enable 'Kernel low-level debugging functions' with 'Use Samsung S3C UART 1 for low-level debug' and then also enable 'Early printk'. Then add 'earlyprintk' to your kernel cmd line. I hope you are using the exynos4412-odroidu3.dtb compiled from the same kernel tree as zImage. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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: exynos4412: Audio dies after one day on kernel 4.0
On 06/10/2015 10:22 AM, Krzysztof Kozlowski wrote:
2015-06-09 20:25 GMT+09:00 gabr...@unseen.is:
On 06/03/2015 02:05 AM, Krzysztof Kozlowski wrote:
On 03.06.2015 04:51, gabr...@unseen.is wrote:
On 05/31/2015 08:47 AM, Krzysztof Kozlowski wrote:
2015-05-31 2:32 GMT+09:00 gabr...@unseen.is:
Hello,
I've been successfully using a self compiled linux kernel until version
3.19 together with Debian Stretch.
After upgrading the kernel to version 4.0 I see strange messages in the
logs i.e.
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: ALSA woke us up to write new data to the device, but there
was actually nothing to write!
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: Most likely this is a bug in the ALSA driver
'snd_soc_simple_card'. Please report this issue to the ALSA developers.
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent
snd_pcm_avail() returned 0 or another value min_avail.
I can easily play sound in perfect quality for approx the first 24h.
After that time the sound becomes distorted and is choppy/crackling.
After rebooting then the sound is optimal again.
I have tried to use kernel 4.0 with almost exactly the same
configuration than for 3.19 to no avail.
Then somebody on
http://forum.odroid.com/viewtopic.php?f=82t=13281p=91186 gave me the
hint that the followin patch might solve the issue:
https://github.com/prahal/linux/commit/5e60cfc9fa5101a346e29ef5f944fbbad300c72d
The patch did help something. I can now still play music after 2 days
but what happens is that each time I turn on music I get a choppy sound
for some time. That means the sound comes clear but every 2 seconds the
sound pauses for a fraction of a second. Which is somewhat comparable to
the issue earlier but without the heavy crackling - and that this goes
away after a couple of minutes.
But furthermore the sound has now simple cracklings. One in two second
approx. and they do not disappear.
Does anybody have an idea what could be the matter here?
Thanks in advance.
+Cc Robert, dmaengine list.
Bisecting would be helpful. You could also try reverting following
commits:
88987d2c75
aee4d1fac8
Other possible test case would be disabling runtime PM for pl330 DMA
driver:
for i in /sys/bus/amba/drivers/dma-pl330/*.[amp]dma/power ; do
echo on ${i}/control
done
Thanks a lot Krzysztof,
I have reverted 88987d2c75 and aee4d1fac8 from 4.0.4 and I have still
audio working after 1 and 1/2 day. Unluckily the alsa error message
occured still once but they don't seem to be the issue here.
+CC Marek,
Robert, Marek, do you have any idea for the cause?
I can now say for sure that the commits 88987d2c75 and aee4d1fac8 are
the cause for the problem. Audio was working now for 7 days.
+CC Vinod
Gabriel,
I sent a patch which should fix the issue. Could you give it a try? Of
course don't revert the other patches and don't use other workarounds.
Just apply the patch on clean (vanilla would be the best) kernel.
[RFT PATCH] dmaengine: Fix choppy sound because of unimplemented resume
hi krzysztof,
thanks a lot for your work. having only that patch applied unfortunately
brought back the problem after something more than one day. the sound
became choppy/noisy again. I will now compile the -next kernel and give
it a try.
best regards,
gabriel
--
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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hi, On Fri, Jun 12, 2015 at 12:36 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: registers are lost assuming the combiner was powered down, even the status register will be lost and you will not know exactly the wakeup reason right ? Good question, I didn't find in the documentation I've access to that this happen but just found through experimentation that the IRQ enable set register values are lost after a resume and that saving/restoring the values makes the interrupts to be triggered again. I'll share here too the findings I mentioned over IRC. As you suggested I add some printouts and noticed that the ISTRn (Interrupt Status) registers values are indeed preserved on resume so I can know for example if the wakeup source was the power gpio-key or cros_ec keyboard. I've checked the values of the registers against the Exynos manual and they corresponds to the interrupt sources in each case so the values are correct. So as you said, it seems that is not that the IP block loses its state on S2R but that something is blindly writing the IESRn (Interrupt Enable Set) registers. I'll postulate an alternate theory here. You can tell me if you buy it or if you think I've been out in the sun too long. Let's say that the interrupt combiner's status registers show the raw status as asserted by whatever is hooked up to the combiner. This means that even if the combiner got reset we could still read the status register and get the status of the source. Imagine that the combiner is like a GPIO bank. If you reset the GPIO bank, you'll lose all kinds of config (input vs. output, edge interrupt status, maybe pulls, etc). ...but you can still read the state asserted by an external source, right? In this case the combiner's interrupt source is 'EINT 11'. ...and I'm pretty sure that the controller managine 'EINT 11' _doesn't_ lose power across suspend/resume... I'll further bolster my theory by saying that _almost nothing_ in the exynos keeps power across suspend/resume. The UART? Nope. The GPIO controllers? Nuh-uh. The GIC? Sorry, but no. The clock tree? It might be nice, but you're out of luck. ...so it would make me terribly surprised to see the combiner keep power. To reduce the possible s/w components that could be doing this, I booted a signed FIT image directly using the RO U-Boot instead of chain loading a mainline nv-uboot. In this configuration I've the same issue so it seems that if something is zeroing those registers on S2R, this can't be changed without void the warranty of these machines. I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that they have a very similar solution than my patch, the IESRn are also saved but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead or registering a syscore ops but the idea is basically the same. Yup, you can see where kliegs added it in https://chromium-review.googlesource.com/#/c/27964/. As per the comments in that CL, this was probably broken in: 063bd6f ARM: EXYNOS: Remove GIC save restore function I have to take a look to the U-boot that is shipped on the device, I think the correct branch is [1] but I'm not sure if that is the correct one. It is the right one. If U-Boot were touching this (which would greatly surprise me) it should be here: arch/arm/include/asm/arch-exynos/cpu.h ...and it's not. Doing a grep for '1044' (the combiner base address) doesn't find anything in U-Boot either, which makes it less likely. ...and it's even less likely since the amount of code that is in U-Boot that runs at resume time is a very small subset and I'm fairly familiar with it and I would have remembered it touching the combiner. It's POSSIBLE that the internal ROM in exynos is clobbering this, but as per above it seems crazy unlikely and I think it's just losing power. -Doug -- 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 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend
Hello Sudeep, On 06/12/2015 02:57 PM, Javier Martinez Canillas wrote: On 06/12/2015 01:54 PM, Sudeep Holla wrote: [snip] registers are lost assuming the combiner was powered down, even the status register will be lost and you will not know exactly the wakeup reason right ? Good question, I didn't find in the documentation I've access to that this happen but just found through experimentation that the IRQ enable set register values are lost after a resume and that saving/restoring the values makes the interrupts to be triggered again. I'll share here too the findings I mentioned over IRC. As you suggested I add some printouts and noticed that the ISTRn (Interrupt Status) registers values are indeed preserved on resume so I can know for example if the wakeup source was the power gpio-key or cros_ec keyboard. I've checked the values of the registers against the Exynos manual and they corresponds to the interrupt sources in each case so the values are correct. So as you said, it seems that is not that the IP block loses its state on S2R but that something is blindly writing the IESRn (Interrupt Enable Set) registers. To reduce the possible s/w components that could be doing this, I booted a signed FIT image directly using the RO U-Boot instead of chain loading a mainline nv-uboot. In this configuration I've the same issue so it seems that if something is zeroing those registers on S2R, this can't be changed without void the warranty of these machines. I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that they have a very similar solution than my patch, the IESRn are also saved but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead or registering a syscore ops but the idea is basically the same. I have to take a look to the U-boot that is shipped on the device, I think the correct branch is [1] but I'm not sure if that is the correct one. Best regards, Javier [0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/common.c#657 [1]: https://chromium.googlesource.com/chromiumos/third_party/u-boot firmware-pit-4482.B -- 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: exynos4412: Audio dies after one day on kernel 4.0
W dniu 13.06.2015 o 06:48, gabr...@unseen.is pisze:
On 06/10/2015 10:22 AM, Krzysztof Kozlowski wrote:
2015-06-09 20:25 GMT+09:00 gabr...@unseen.is:
On 06/03/2015 02:05 AM, Krzysztof Kozlowski wrote:
On 03.06.2015 04:51, gabr...@unseen.is wrote:
On 05/31/2015 08:47 AM, Krzysztof Kozlowski wrote:
2015-05-31 2:32 GMT+09:00 gabr...@unseen.is:
Hello,
I've been successfully using a self compiled linux kernel until version
3.19 together with Debian Stretch.
After upgrading the kernel to version 4.0 I see strange messages in the
logs i.e.
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: ALSA woke us up to write new data to the device, but there
was actually nothing to write!
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: Most likely this is a bug in the ALSA driver
'snd_soc_simple_card'. Please report this issue to the ALSA developers.
May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent
snd_pcm_avail() returned 0 or another value min_avail.
I can easily play sound in perfect quality for approx the first 24h.
After that time the sound becomes distorted and is choppy/crackling.
After rebooting then the sound is optimal again.
I have tried to use kernel 4.0 with almost exactly the same
configuration than for 3.19 to no avail.
Then somebody on
http://forum.odroid.com/viewtopic.php?f=82t=13281p=91186 gave me the
hint that the followin patch might solve the issue:
https://github.com/prahal/linux/commit/5e60cfc9fa5101a346e29ef5f944fbbad300c72d
The patch did help something. I can now still play music after 2 days
but what happens is that each time I turn on music I get a choppy sound
for some time. That means the sound comes clear but every 2 seconds the
sound pauses for a fraction of a second. Which is somewhat comparable to
the issue earlier but without the heavy crackling - and that this goes
away after a couple of minutes.
But furthermore the sound has now simple cracklings. One in two second
approx. and they do not disappear.
Does anybody have an idea what could be the matter here?
Thanks in advance.
+Cc Robert, dmaengine list.
Bisecting would be helpful. You could also try reverting following
commits:
88987d2c75
aee4d1fac8
Other possible test case would be disabling runtime PM for pl330 DMA
driver:
for i in /sys/bus/amba/drivers/dma-pl330/*.[amp]dma/power ; do
echo on ${i}/control
done
Thanks a lot Krzysztof,
I have reverted 88987d2c75 and aee4d1fac8 from 4.0.4 and I have still
audio working after 1 and 1/2 day. Unluckily the alsa error message
occured still once but they don't seem to be the issue here.
+CC Marek,
Robert, Marek, do you have any idea for the cause?
I can now say for sure that the commits 88987d2c75 and aee4d1fac8 are
the cause for the problem. Audio was working now for 7 days.
+CC Vinod
Gabriel,
I sent a patch which should fix the issue. Could you give it a try? Of
course don't revert the other patches and don't use other workarounds.
Just apply the patch on clean (vanilla would be the best) kernel.
[RFT PATCH] dmaengine: Fix choppy sound because of unimplemented resume
hi krzysztof,
thanks a lot for your work. having only that patch applied unfortunately
brought back the problem after something more than one day. the sound
became choppy/noisy again. I will now compile the -next kernel and give
it a try.
Thanks, I'll try to reproduce the issue on my Odroid. Can you share more
details how to reproduce it? The audio must play continuously or just
from time to time but the board must be turned on for more than one day?
Best regards,
Krzysztof
--
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/9] tests/exynos: clean struct connector
On 10 June 2015 at 14:42, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote:
Remove all unused struct members.
Mentioning if they were used at some point in the past will be great.
Thanks
Emil
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 64dacfa..6af9277 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -65,17 +65,9 @@ struct fimg2d_test_case {
struct connector {
uint32_t id;
char mode_str[64];
- char format_str[5];
- unsigned int fourcc;
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
- int pipe;
- int plane_zpos;
- unsigned int fb_id[2], current_fb_id;
- struct timeval start;
-
- int swap_count;
};
static void connector_find_mode(int fd, struct connector *c,
@@ -750,8 +742,6 @@ int main(int argc, char **argv)
if (ret 0)
goto err_destroy_buffer;
- con.plane_zpos = -1;
-
memset(bo-vaddr, 0xff, screen_width * screen_height * 4);
ret = drm_set_crtc(dev, con, fb_id);
--
2.0.5
--
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 8/9] tests/exynos: remove connector_find_plane
On 10 June 2015 at 14:42, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote: No test uses DRM planes at the moment so this function is never called. Similar to the other patch - mention if this been used previously. I'm assuming that the exynos guys might have some work stashed which depends on this ? -Emil -- 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/9] exynos: fimg2d: fix return codes
Hello Emil, Emil Velikov wrote: On 10 June 2015 at 14:42, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote: Even if flushing the command buffer doesn't succeed, the G2D calls would still return zero. Fix this by just passing the flush return code. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- exynos/exynos_fimg2d.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 86ae898..5ea42e6 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -330,9 +330,7 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, bitblt.data.fast_solid_color_fill_en = 1; g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -415,9 +413,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src, rop4.data.unmasked_rop3 = G2D_ROP3_SRC; g2d_add_cmd(ctx, ROP4_REG, rop4.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -527,9 +523,7 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -636,9 +630,7 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -766,7 +758,5 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); Strictly speaking g2d_add_cmd() can fail, and all the functions that build upon it. In the latter case most ignore the return value which is a bit bad. That plus the fact that these are part of the public API makes things easier to misuse. I'm totally aware of that. In fact I've already rewritten the error checking logic. But that would be for a later series. I prefer to do this in small steps, in particular because I see the tendency that nobody from Samsung reviews the larger patches anyway. Or any patches at all. And yes, I'm voicing my frustration here... One way to avoid all this is to implement an internal function that does the size checks ahead of time, and drop them from g2d_add_cmd(), apart from this patch. I'm doing something different, which however results in more or less the same thing. The nouveau mesa drivers do a similar thing - see PUSH_SPACE(). -Emil With best wishes, Tobias -- 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/9] tests/exynos: clean struct connector
Hello Emil,
Emil Velikov wrote:
On 10 June 2015 at 14:42, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote:
Remove all unused struct members.
Mentioning if they were used at some point in the past will be great.
OK, I'll take a look at git history but AFAIK it is not.
With best wishes,
Tobias
Thanks
Emil
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 64dacfa..6af9277 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -65,17 +65,9 @@ struct fimg2d_test_case {
struct connector {
uint32_t id;
char mode_str[64];
- char format_str[5];
- unsigned int fourcc;
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
- int pipe;
- int plane_zpos;
- unsigned int fb_id[2], current_fb_id;
- struct timeval start;
-
- int swap_count;
};
static void connector_find_mode(int fd, struct connector *c,
@@ -750,8 +742,6 @@ int main(int argc, char **argv)
if (ret 0)
goto err_destroy_buffer;
- con.plane_zpos = -1;
-
memset(bo-vaddr, 0xff, screen_width * screen_height * 4);
ret = drm_set_crtc(dev, con, fb_id);
--
2.0.5
--
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 6/9] tests/exynos: remove struct fimg2d_test_case
Hello Emil, Emil Velikov wrote: On 10 June 2015 at 14:42, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote: It doesn't make sense to keep this structure, since we can just call all tests directly. Seems like it was designed in mind of having another test case. Perhaps the exynos guys cannot really upstream it (licensing or other issues) ? might be. But why should we care about that anyway? My personal guess: Big giant code bomb which noone bothered to check. ;) With best wishes, Tobias -Emil -- 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 01/15] ARM: kill off set_irq_flags usage
On Fri, 12 Jun 2015, Rob Herring wrote: On Fri, Jun 12, 2015 at 9:05 AM, Hans Ulli Kroll ulli.kr...@googlemail.com wrote: On Tue, 9 Jun 2015, Rob Herring wrote: set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID - !IRQ_NOREQUEST IRQF_PROBE - !IRQ_NOPROBE IRQF_NOAUTOEN - IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also set IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. for mach-gemini Signed-off-by: Hans Ulli Kroll ulli.kr...@googlemail.com You mean acked-by, right? Rob Yeah Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com Ulli -- 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 (alternative) 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
On 2015년 06월 12일 21:10, Inki Dae wrote:
On 2015년 06월 12일 18:07, Marek Szyprowski wrote:
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changelog:
v3 (alternative):
- araranged code by moving fimd_{enable,disable}_vblank functions before
fimd_clear_channel to avoid forward declaration usage
Marek,
For the iommu and atomic feature test, I merged below patches in
addition and tested them.
[PATCH v2 1/3] drm/exynos: remove to call mixer_wait_for_vblank
[PATCH v2 2/3] drm/exynos: remove chained calls to enable
[PATCH v2 3/3] drm/exynos: initialize VIDCON0 when fimd is disabled
However, I see below one warning log,
[1.227115] [drm] Initialized drm 1.1.0 20060810
[1.235852] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
vidi_component_ops)
[1.253548] [ cut here ]
[1.256700] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1718
drm_handle_vblank+0x2a0/0x308()
[1.265800] Modules linked in:
[1.268844] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.1.0-rc4-00574-gf8eb363-dirty #1412
[1.277085] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.283184] [c0015464] (unwind_backtrace) from [c00123c0]
(show_stack+0x10/0x14)
[1.288540] exynos-drm exynos-drm: bound 11c0.fimd (ops
fimd_component_ops)
[1.23] exynos-drm exynos-drm: bound 11c8.dsi (ops
exynos_dsi_component_ops)
[1.28] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.288891] [drm] No driver support for vblank timestamp query.
[1.288932] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[1.324248] [c00123c0] (show_stack) from [c0528f74]
(dump_stack+0x84/0xc4)
[1.331437] [c0528f74] (dump_stack) from [c00246ac]
(warn_slowpath_common+0x80/0xb0)
[1.339504] [c00246ac] (warn_slowpath_common) from [c0024778]
(warn_slowpath_null+0x1c/0x24)
[1.348270] [c0024778] (warn_slowpath_null) from [c029c898]
(drm_handle_vblank+0x2a0/0x308)
[1.356965] [c029c898] (drm_handle_vblank) from [c02b8c80]
(fimd_irq_handler+0x78/0xd0)
[1.365292] [c02b8c80] (fimd_irq_handler) from [c00608f8]
(handle_irq_event_percpu+0x78/0x134)
[1.374231] [c00608f8] (handle_irq_event_percpu) from [c00609f0]
(handle_irq_event+0x3c/0x5c)
[1.374244] [c00609f0] (handle_irq_event) from [c0063698]
(handle_level_irq+0xc4/0x13c)
[1.374256] [c0063698] (handle_level_irq) from [c005ff7c]
(generic_handle_irq+0x2c/0x3c)
[1.374269] [c005ff7c] (generic_handle_irq) from [c02214ec]
(combiner_handle_cascade_irq+0x94/0x100)
[1.374281] [c02214ec] (combiner_handle_cascade_irq) from
[c005ff7c] (generic_handle_irq+0x2c/0x3c)
[1.374290] [c005ff7c] (generic_handle_irq) from [c0060248]
(__handle_domain_irq+0x7c/0xec)
[1.374300] [c0060248] (__handle_domain_irq) from [c0009434]
(gic_handle_irq+0x30/0x68)
And below one page fault error when modetest is terminated,
# modetest -M exynos -v -s 31@29:720x1280
setting mode 720x1280-60Hz@XR24 on connectors 31, crtc 29
freq: 59.99Hz
[ 34.831025] PAGE FAULT occurred at 0x2040 by 11e2.sysmmu(Page
table base: 0x6e324000)
[ 34.838072] Lv1 entry: 0x6e92dc01
[ 34.841489] [ cut here ]
[ 34.846058] kernel BUG at drivers/iommu/exynos-iommu.c:364!
[ 34.851614] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 34.857428] Modules linked in:
[ 34.860472] CPU: 0 PID: 6 Comm: kworker/u8:0 Tainted: GW
4.1.0-rc4-00574-gf8eb363-dirty #1412
[ 34.870188] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 34.876273] Workqueue: events_unbound async_run_entry_fn
[ 34.881560] task: ee879540 ti: ee8a2000 task.ti: ee8a2000
[ 34.886946] PC is at exynos_sysmmu_irq+0x184/0x208
[ 34.891716] LR is at exynos_sysmmu_irq+0xd4/0x208
[ 34.896404] pc : [c02880d0]lr : [c0288020]psr: 6193
[ 34.896404] sp : ee8a3c00 ip : fp : eeacbc10
[ 34.907860] r10: c07c27ef r9 : 0204 r8 : 2040
[ 34.913068] r7 : ee324000 r6 : ee9b3428 r5 : ee9b3410 r4 :
[ 34.919577] r3 : 6e92dc01 r2 : 6e92dc01 r1 : eea55810 r0 : eeb0a000
[ 34.926089] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 34.933466] Control: 10c5387d Table: 6dd2c04a DAC: 0015
[ 34.939195] Process kworker/u8:0 (pid: 6, stack limit = 0xee8a2210)
[ 34.945444] Stack: (0xee8a3c00 to 0xee8a4000)
[ 34.949788] 3c00: ee8a3c0c c0049df8 6e324000 0003d4f3
Re: [PATCH 1/9] exynos: fimg2d: fix return codes
On 10 June 2015 at 14:42, Tobias Jakobi tjak...@math.uni-bielefeld.de wrote: Even if flushing the command buffer doesn't succeed, the G2D calls would still return zero. Fix this by just passing the flush return code. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- exynos/exynos_fimg2d.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 86ae898..5ea42e6 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -330,9 +330,7 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, bitblt.data.fast_solid_color_fill_en = 1; g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -415,9 +413,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src, rop4.data.unmasked_rop3 = G2D_ROP3_SRC; g2d_add_cmd(ctx, ROP4_REG, rop4.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -527,9 +523,7 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -636,9 +630,7 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -766,7 +758,5 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); Strictly speaking g2d_add_cmd() can fail, and all the functions that build upon it. In the latter case most ignore the return value which is a bit bad. That plus the fact that these are part of the public API makes things easier to misuse. One way to avoid all this is to implement an internal function that does the size checks ahead of time, and drop them from g2d_add_cmd(), apart from this patch. The nouveau mesa drivers do a similar thing - see PUSH_SPACE(). -Emil -- 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: Feedback on hardware support for Odroid U3
Am Freitag, 12. Juni 2015, 17:46:11 schrieb Mateusz Krawczuk: Could you send your config and log using gist.github.com, because pastebin.com is forbidden by company IT. Mateusz Krawczuk Samsung RD Institute Poland W dniu 12.06.2015 o 15:53, Thomas Pietrowski pisze: Hello again, first after fixing my booting problems I now get different warnings after boot. - config: http://pastebin.com/MHUu51pF - log: http://pastebin.com/9YMgMmFL - repo: arm-soc I read the last days that you are still working on the clk drivers, so as these warnings appear to be related to that you might be interested on them. Additionally my CPU fan it running at full RPM all the time. I checked the temperature just to be sure and it says it's 20°C. Is this problem known or can I help debugging it? Of course I can. Didn't know about this restriction. -config: https://gist.github.com/thopiekar/440059953391ccadc324 -log: https://gist.github.com/thopiekar/061d12802a4346eb783f -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: fimd: fix page fault issue with iommu
This patch resolves page fault issue with iommu and atomic feature when modetest test application is terminated. ENWIN_F field of WINCONx register enables or disable a dma channel to each hardware overlay - the value of the field will be updated to real register after vsync. So this patch makes sure the dma channel is disabled by waiting for vsync one time after clearing shadow registers to all dma channels. Below shows the page fault issue: setting mode 720x1280-60Hz@XR24 on connectors 31, crtc 29 freq: 59.99Hz [ 34.831025] PAGE FAULT occurred at 0x2040 by 11e2.sysmmu(Page table base: 0x6e324000) [ 34.838072] Lv1 entry: 0x6e92dc01 [ 34.841489] [ cut here ] [ 34.846058] kernel BUG at drivers/iommu/exynos-iommu.c:364! [ 34.851614] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 34.857428] Modules linked in: --snip-- [ 35.210894] [c02880d0] (exynos_sysmmu_irq) from [c00608f8] (handle_irq_event_percpu+0x78/0x134) [ 35.219914] [c00608f8] (handle_irq_event_percpu) from [c00609f0] (handle_irq_event+0x3c/0x5c) [ 35.228768] [c00609f0] (handle_irq_event) from [c0063698] (handle_level_irq+0xc4/0x13c) [ 35.237101] [c0063698] (handle_level_irq) from [c005ff7c] (generic_handle_irq+0x2c/0x3c) [ 35.245521] [c005ff7c] (generic_handle_irq) from [c02214ec] (combiner_handle_cascade_irq+0x94/0x100) [ 35.254980] [c02214ec] (combiner_handle_cascade_irq) from [c005ff7c] (generic_handle_irq+0x2c/0x3c) [ 35.264353] [c005ff7c] (generic_handle_irq) from [c0060248] (__handle_domain_irq+0x7c/0xec) [ 35.273034] [c0060248] (__handle_domain_irq) from [c0009434] (gic_handle_irq+0x30/0x68) [ 35.281366] [c0009434] (gic_handle_irq) from [c0012ec0] (__irq_svc+0x40/0x74) Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index fda62da..4bac303 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -813,6 +813,10 @@ static void fimd_disable(struct exynos_drm_crtc *crtc) for (i = 0; i WINDOWS_NR; i++) fimd_win_disable(crtc, i); + fimd_enable_vblank(crtc); + fimd_wait_for_vblank(crtc); + fimd_disable_vblank(crtc); + writel(0, ctx-regs + VIDCON0); clk_disable_unprepare(ctx-lcd_clk); -- 1.7.9.5 -- 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
Feedback on hardware support for Odroid U3
Hello again, first after fixing my booting problems I now get different warnings after boot. - config: http://pastebin.com/MHUu51pF - log: http://pastebin.com/9YMgMmFL - repo: arm-soc I read the last days that you are still working on the clk drivers, so as these warnings appear to be related to that you might be interested on them. Additionally my CPU fan it running at full RPM all the time. I checked the temperature just to be sure and it says it's 20°C. Is this problem known or can I help debugging it? -- 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 6/9] tests/exynos: remove struct fimg2d_test_case
It doesn't make sense to keep this structure, since we
can just call all tests directly. An inspection of the
git history shows that no code ever used this
abstraction in the past.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 42 +--
1 file changed, 5 insertions(+), 37 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 080d178..de6a2b7 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -37,30 +37,6 @@
static unsigned int screen_width, screen_height;
-/*
- * A structure to test fimg2d hw.
- *
- * @solid_fill: fill given color data to source buffer.
- * @copy: copy source to destination buffer.
- * @copy_with_scale: copy source to destination buffer scaling up or
- * down properly.
- * @blend: blend source to destination buffer.
- */
-struct fimg2d_test_case {
- int (*solid_fill)(struct exynos_device *dev, struct exynos_bo *dst);
- int (*copy)(struct exynos_device *dev, struct exynos_bo *src,
- struct exynos_bo *dst, enum e_g2d_buf_type);
- int (*copy_with_scale)(struct exynos_device *dev,
- struct exynos_bo *src, struct exynos_bo *dst,
- enum e_g2d_buf_type);
- int (*blend)(struct exynos_device *dev,
- struct exynos_bo *src, struct exynos_bo *dst,
- enum e_g2d_buf_type);
- int (*checkerboard)(struct exynos_device *dev,
- struct exynos_bo *src, struct exynos_bo *dst,
- enum e_g2d_buf_type);
-};
-
struct connector {
uint32_t id;
char mode_str[64];
@@ -630,14 +606,6 @@ fail:
return ret;
}
-static struct fimg2d_test_case test_case = {
- .solid_fill = g2d_solid_fill_test,
- .copy = g2d_copy_test,
- .copy_with_scale = g2d_copy_with_scale_test,
- .blend = g2d_blend_test,
- .checkerboard = g2d_checkerboard_test,
-};
-
static void usage(char *name)
{
fprintf(stderr, usage: %s [-s]\n, name);
@@ -747,7 +715,7 @@ int main(int argc, char **argv)
if (ret 0)
goto err_rm_fb;
- ret = test_case.solid_fill(dev, bo);
+ ret = g2d_solid_fill_test(dev, bo);
if (ret 0) {
fprintf(stderr, failed to solid fill operation.\n);
goto err_rm_fb;
@@ -761,7 +729,7 @@ int main(int argc, char **argv)
goto err_rm_fb;
}
- ret = test_case.copy(dev, src, bo, G2D_IMGBUF_GEM);
+ ret = g2d_copy_test(dev, src, bo, G2D_IMGBUF_GEM);
if (ret 0) {
fprintf(stderr, failed to test copy operation.\n);
goto err_free_src;
@@ -769,7 +737,7 @@ int main(int argc, char **argv)
wait_for_user_input(0);
- ret = test_case.copy_with_scale(dev, src, bo, G2D_IMGBUF_GEM);
+ ret = g2d_copy_with_scale_test(dev, src, bo, G2D_IMGBUF_GEM);
if (ret 0) {
fprintf(stderr, failed to test copy and scale operation.\n);
goto err_free_src;
@@ -777,7 +745,7 @@ int main(int argc, char **argv)
wait_for_user_input(0);
- ret = test_case.checkerboard(dev, src, bo, G2D_IMGBUF_GEM);
+ ret = g2d_checkerboard_test(dev, src, bo, G2D_IMGBUF_GEM);
if (ret 0) {
fprintf(stderr, failed to issue checkerboard test.\n);
goto err_free_src;
@@ -794,7 +762,7 @@ int main(int argc, char **argv)
* Disable the test for now, until the kernel code has been sanitized.
*/
#if 0
- ret = test_case.blend(dev, src, bo, G2D_IMGBUF_USERPTR);
+ ret = g2d_blend_test(dev, src, bo, G2D_IMGBUF_USERPTR);
if (ret 0)
fprintf(stderr, failed to test blend operation.\n);
--
2.0.5
--
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 5/9] tests/exynos: remove unused define
It doesn't make sense to limit the number of test cases anyway. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- tests/exynos/exynos_fimg2d_test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/exynos/exynos_fimg2d_test.c b/tests/exynos/exynos_fimg2d_test.c index 6af9277..080d178 100644 --- a/tests/exynos/exynos_fimg2d_test.c +++ b/tests/exynos/exynos_fimg2d_test.c @@ -34,7 +34,6 @@ #include exynos_fimg2d.h #define DRM_MODULE_NAMEexynos -#define MAX_TEST_CASE 8 static unsigned int screen_width, screen_height; -- 2.0.5 -- 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 7/9] tests/exynos: simplify drm_set_crtc
We can just return 'ret' here, the goto serves no purpose.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index de6a2b7..1ec7340 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -150,14 +150,9 @@ static int drm_set_crtc(struct exynos_device *dev, struct
connector *c,
ret = drmModeSetCrtc(dev-fd, c-crtc,
fb_id, 0, 0, c-id, 1, c-mode);
- if (ret) {
+ if (ret)
drmMsg(failed to set mode: %s\n, strerror(errno));
- goto err;
- }
-
- return 0;
-err:
return ret;
}
--
2.0.5
--
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 8/9] tests/exynos: remove connector_find_plane
No test uses DRM planes at the moment so this function
is never called. Inspection of the git history shows
that DRM planes were also never used in these tests
in the past.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
tests/exynos/exynos_fimg2d_test.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 1ec7340..59de4ba 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -112,37 +112,6 @@ static void connector_find_mode(int fd, struct connector
*c,
c-crtc = c-encoder-crtc_id;
}
-static int connector_find_plane(int fd, unsigned int *plane_id)
-{
- drmModePlaneRes *plane_resources;
- drmModePlane *ovr;
- int i;
-
- plane_resources = drmModeGetPlaneResources(fd);
- if (!plane_resources) {
- fprintf(stderr, drmModeGetPlaneResources failed: %s\n,
- strerror(errno));
- return -1;
- }
-
- for (i = 0; i plane_resources-count_planes; i++) {
- plane_id[i] = 0;
-
- ovr = drmModeGetPlane(fd, plane_resources-planes[i]);
- if (!ovr) {
- fprintf(stderr, drmModeGetPlane failed: %s\n,
- strerror(errno));
- continue;
- }
-
- if (ovr-possible_crtcs (1 0))
- plane_id[i] = ovr-plane_id;
- drmModeFreePlane(ovr);
- }
-
- return 0;
-}
-
static int drm_set_crtc(struct exynos_device *dev, struct connector *c,
unsigned int fb_id)
{
--
2.0.5
--
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 9/9] tests/exynos: handle G2D_IMGBUF_COLOR in switch statements
This fixes a compiler warning about missing handling of enum values in the switch statements. Also remove the silent mapping to G2D_IMGBUF_GEM when an unknown buffer type is encountered. We have full control about the type here, and if it's unknown then we obviously have a bug in the code. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- tests/exynos/exynos_fimg2d_test.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/tests/exynos/exynos_fimg2d_test.c b/tests/exynos/exynos_fimg2d_test.c index 59de4ba..8794dac 100644 --- a/tests/exynos/exynos_fimg2d_test.c +++ b/tests/exynos/exynos_fimg2d_test.c @@ -270,9 +270,10 @@ static int g2d_copy_test(struct exynos_device *dev, struct exynos_bo *src, src_img.user_ptr[0].userptr = userptr; src_img.user_ptr[0].size = size; break; + case G2D_IMGBUF_COLOR: default: - type = G2D_IMGBUF_GEM; - break; + ret = -EFAULT; + goto fail; } printf(copy test with %s.\n, @@ -306,6 +307,7 @@ err_free_userptr: if (userptr) free((void *)userptr); +fail: g2d_fini(ctx); return ret; @@ -349,9 +351,10 @@ static int g2d_copy_with_scale_test(struct exynos_device *dev, src_img.user_ptr[0].userptr = userptr; src_img.user_ptr[0].size = size; break; + case G2D_IMGBUF_COLOR: default: - type = G2D_IMGBUF_GEM; - break; + ret = -EFAULT; + goto fail; } printf(copy and scale test with %s.\n, @@ -390,6 +393,7 @@ err_free_userptr: if (userptr) free((void *)userptr); +fail: g2d_fini(ctx); return 0; @@ -435,9 +439,10 @@ static int g2d_blend_test(struct exynos_device *dev, src_img.user_ptr[0].userptr = userptr; src_img.user_ptr[0].size = size; break; + case G2D_IMGBUF_COLOR: default: - type = G2D_IMGBUF_GEM; - break; + ret = -EFAULT; + goto fail; } printf(blend test with %s.\n, @@ -487,6 +492,7 @@ err_free_userptr: if (userptr) free((void *)userptr); +fail: g2d_fini(ctx); return 0; @@ -532,6 +538,7 @@ static int g2d_checkerboard_test(struct exynos_device *dev, src_img.user_ptr[0].userptr = (unsigned long)checkerboard; src_img.user_ptr[0].size = img_w * img_h * 4; break; + case G2D_IMGBUF_COLOR: default: ret = -EFAULT; goto fail; -- 2.0.5 -- 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 2/9] tests/exynos: replace return by break
The 'usage' function already does exit(0), so that this 'return -EINVAL' is never called. Just put a break there to avoid confusion. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- tests/exynos/exynos_fimg2d_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/exynos/exynos_fimg2d_test.c b/tests/exynos/exynos_fimg2d_test.c index e64bb32..64dacfa 100644 --- a/tests/exynos/exynos_fimg2d_test.c +++ b/tests/exynos/exynos_fimg2d_test.c @@ -689,7 +689,7 @@ int main(int argc, char **argv) break; default: usage(argv[0]); - return -EINVAL; + break; } } -- 2.0.5 -- 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 0/9] drm/exynos: cleanups and small fixes for libdrm
Hello, I've split off the Exynos specific bits, so this is just some cleanups and small fixes. Everything can be reviewed without knowledge about the Exynos platform. My hope is that I can get at least some of the patches from my last series upstream. With best wishes, Tobias Changes in v2: - Made it clear that the error handling is currently 'unsatisfactory', but that this is going to be adressed in a later patch. - Point out that removed code also wasn't used anywhere in the past (by inspection of git history). Tobias Jakobi (9): exynos: fimg2d: fix return codes tests/exynos: replace return by break exynos/fimg2d: simplify g2d_fini() tests/exynos: clean struct connector tests/exynos: remove unused define tests/exynos: remove struct fimg2d_test_case tests/exynos: simplify drm_set_crtc tests/exynos: remove connector_find_plane tests/exynos: handle G2D_IMGBUF_COLOR in switch statements exynos/exynos_fimg2d.c| 23 ++-- tests/exynos/exynos_fimg2d_test.c | 112 +++--- 2 files changed, 26 insertions(+), 109 deletions(-) -- 2.0.5 -- 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 1/9] exynos: fimg2d: fix return codes
Even if flushing the command buffer doesn't succeed, the G2D calls would still return zero. Fix this by just passing the flush return code. In fact error handling currently ignores the fact that g2d_add_cmd() can fail. This is going to be handled in a later patch. Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de --- exynos/exynos_fimg2d.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 86ae898..5ea42e6 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -330,9 +330,7 @@ g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img, bitblt.data.fast_solid_color_fill_en = 1; g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -415,9 +413,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src, rop4.data.unmasked_rop3 = G2D_ROP3_SRC; g2d_add_cmd(ctx, ROP4_REG, rop4.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -527,9 +523,7 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -636,9 +630,7 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } /** @@ -766,7 +758,5 @@ g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src, pt.data.y = dst_y + dst_h; g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val); - g2d_flush(ctx); - - return 0; + return g2d_flush(ctx); } -- 2.0.5 -- 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 3/9] exynos/fimg2d: simplify g2d_fini()
free()ing a nullptr is a noop, so remove the check.
Signed-off-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
---
exynos/exynos_fimg2d.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 5ea42e6..24a06d0 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -254,8 +254,7 @@ struct g2d_context *g2d_init(int fd)
void g2d_fini(struct g2d_context *ctx)
{
- if (ctx)
- free(ctx);
+ free(ctx);
}
/**
--
2.0.5
--
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
