[PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
Hi, This patch series removes the use of Exynos5250 specific support from exynos-cpufreq driver and enables the use of cpufreq-dt driver for this platform. The exynos-cpufreq driver itself is also removed as it is no longer used/needed after Exynos5250 support removal. This patch series has been tested on Exynos5250 based Arndale board. Depends on: - next-20150330 branch of linux-next kernel tree - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210 platform [1] - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform [2] - [PATCH] cpufreq: exynos: remove dead -need_apll_change method [3] [1] http://www.kernelhub.org/?msg=721136p=2 [2] http://marc.info/?l=linux-pmm=142868881101873w=2 [3] https://lkml.org/lkml/2015/3/27/574 Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (1): cpufreq: exynos: remove Exynos5250 specific cpufreq driver support Thomas Abraham (3): clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock ARM: dts: Exynos5250: add CPU OPP and regulator supply property ARM: Exynos: switch to using generic cpufreq driver for Exynos5250 arch/arm/boot/dts/exynos5250-arndale.dts |4 + arch/arm/boot/dts/exynos5250-smdk5250.dts |4 + arch/arm/boot/dts/exynos5250-snow.dts |4 + arch/arm/boot/dts/exynos5250-spring.dts |4 + arch/arm/boot/dts/exynos5250.dtsi | 22 +++ arch/arm/mach-exynos/exynos.c |1 + drivers/clk/samsung/clk-exynos5250.c | 31 + drivers/cpufreq/Kconfig.arm | 22 --- drivers/cpufreq/Makefile |3 - drivers/cpufreq/exynos-cpufreq.c | 203 drivers/cpufreq/exynos-cpufreq.h | 67 - drivers/cpufreq/exynos5250-cpufreq.c | 210 - include/dt-bindings/clock/exynos5250.h|1 + 13 files changed, 71 insertions(+), 505 deletions(-) delete mode 100644 drivers/cpufreq/exynos-cpufreq.c delete mode 100644 drivers/cpufreq/exynos-cpufreq.h delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- 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
[PATCH 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
From: Thomas Abraham thomas...@samsung.com
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5250.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
- moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/clk/samsung/clk-exynos5250.c | 31 +++
include/dt-bindings/clock/exynos5250.h |1 +
2 files changed, 32 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 70ec3d2..d87f34d 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -19,6 +19,7 @@
#include linux/syscore_ops.h
#include clk.h
+#include clk-cpu.h
#define APLL_LOCK 0x0
#define APLL_CON0 0x100
@@ -748,6 +749,32 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud) \
+ apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \
+((periph) 12) | ((acp) 8) | ((cpud) 4)))
+#define E5250_CPU_DIV1(hpm, copy) \
+ (((hpm) 4) | (copy))
+
+static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[] __initconst =
{
+ { 170, E5250_CPU_DIV0(5, 3, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 160, E5250_CPU_DIV0(4, 1, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 150, E5250_CPU_DIV0(4, 1, 7, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 140, E5250_CPU_DIV0(4, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 130, E5250_CPU_DIV0(3, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 120, E5250_CPU_DIV0(3, 1, 5, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 110, E5250_CPU_DIV0(3, 1, 5, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 100, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 90, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 80, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 70, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 60, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 50, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 40, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 30, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 20, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = samsung,clock-xxti, .data = (void *)0, },
{ },
@@ -797,6 +824,10 @@ static void __init exynos5250_clk_init(struct device_node
*np)
ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(ctx, exynos5250_gate_clks,
ARRAY_SIZE(exynos5250_gate_clks));
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5250_armclk_d, ARRAY_SIZE(exynos5250_armclk_d),
+ CLK_CPU_HAS_DIV1);
/*
* Enable arm clock down (in idle) and set arm divider
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 4273891d..8183d1c 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL 6
#define CLK_FOUT_EPLL 7
#define CLK_FOUT_VPLL 8
+#define CLK_ARM_CLK9
/* gate for special clocks (sclk) */
#define CLK_SCLK_CAM_BAYER 128
--
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
[PATCH 2/4] ARM: dts: Exynos5250: add CPU OPP and regulator supply property
From: Thomas Abraham thomas...@samsung.com
For Exynos5250 platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific
cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
- added CPU regulator supply property for Google Spring board
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Andreas Faerber afaer...@suse.de
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Andreas Farber afaer...@suse.de
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/boot/dts/exynos5250-arndale.dts |4
arch/arm/boot/dts/exynos5250-smdk5250.dts |4
arch/arm/boot/dts/exynos5250-snow.dts |4
arch/arm/boot/dts/exynos5250-spring.dts |4
arch/arm/boot/dts/exynos5250.dtsi | 22 ++
5 files changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7e728a1..c64cec3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -560,3 +560,7 @@
status = okay;
samsung,exynos-sataphy-i2c-phandle = sata_phy_i2c;
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index bc27cc2..d91db82 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -410,3 +410,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 2657e84..700bbc8 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -301,6 +301,10 @@
vdd_pll-supply = ldo8_reg;
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
i2c_0 {
status = okay;
samsung,i2c-sda-delay = 100;
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index d03f9b8..38b54d9 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -99,6 +99,10 @@
vdd_pll-supply = ldo8_reg;
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
i2c_0 {
status = okay;
samsung,i2c-sda-delay = 100;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 257e2f1..c1f7811 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -63,6 +63,28 @@
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
+
+ operating-points =
+ 170 130
+ 160 125
+ 150 1225000
+ 140 120
+ 130 115
+ 120 1125000
+ 110 110
+ 100 1075000
+90 105
+80 1025000
+70 1012500
+60 100
+50 975000
+40 95
+30 937500
+20 925000
+ ;
cooling-min-level = 15;
cooling-max-level = 9;
#cooling-cells = 2; /* min followed by max */
--
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
[PATCH 3/4] ARM: Exynos: switch to using generic cpufreq driver for Exynos5250
From: Thomas Abraham thomas...@samsung.com
The new CPU clock type allows the use of generic CPUfreq driver.
Switch Exynos5250 to using generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/mach-exynos/exynos.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 637d862..4b03a32 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -206,6 +206,7 @@ struct cpufreq_dt_platform_data cpufreq_dt_pd = {
static const struct of_device_id exynos_cpufreq_matches[] = {
{ .compatible = samsung,exynos4210, .data = cpufreq-dt },
+ { .compatible = samsung,exynos5250, .data = cpufreq-dt },
{ /* sentinel */ }
};
--
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
Re: [PATCH 1/1] mmc: pwrseq: Fix error code propagation in mmc_pwrseq_simple_alloc()
On 04/13/2015 11:07 PM, Javier Martinez Canillas wrote: If the struct mmc_pwrseq_match .alloc function used to allocate a struct mmc_pwrseq fails, the error is propagated to mmc_of_parse(). But instead of returning the error code in pwrseq, host-pwrseq is returned which will always be 0. So mmc_of_parse() succeeds even if the pwrseq .alloc function failed and host-pwrseq is NULL. This makes the SDIO device to not be powered if the power sequencing .alloc functions wants to be deferred due a missing resource because the mmc controller driver probe did wrongly succeed. Fixes: 0f12a0ce4ce4a (mmc: pwrseq: simplify alloc/free hooks) Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I obviously overlooked that one. Thanks for fixing it. Reviewed-by: Alexandre Courbot acour...@nvidia.com -- 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] drm/exynos: remove unnecessary calls to disable_plane()
2015-04-13 Joonyoung Shim jy0922.s...@samsung.com:
Hi,
On 04/11/2015 03:57 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 8
2 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 519c569..9bf25ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -47,8 +47,6 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_plane *plane;
- int ret;
if (!exynos_crtc-enabled)
return;
@@ -64,15 +62,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc
*crtc)
exynos_crtc-ops-dpms(exynos_crtc, DRM_MODE_DPMS_OFF);
exynos_crtc-enabled = false;
-
- drm_for_each_legacy_plane(plane, crtc-dev-mode_config.plane_list) {
- if (plane-crtc != crtc)
- continue;
-
- ret = plane-funcs-disable_plane(plane);
- if (ret)
- DRM_ERROR(Failed to disable plane %d\n, ret);
- }
If remove here disable codes, when crtc is disabled, enabled overlay
planes may not be disabled.
E.g, user can remove fb of crtc via DRM_IOCTL_MODE_RMFB ioctl, then crtc
is disabled but overlay planes no.
That not true anymore with atomic modesetting, the overlay planes are also
disabled, so we should let the atomic core solve this and remove these pieces
of code from here.
Gustavo
--
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 buffer size calculation
Commit adacb228d72b9529f8de0769cc33414c3012054d (drm: Exynos: Respect framebuffer pitch for FIMD/Mixer) changed the way of buffer size calcularion: it replaced fb_width by fb_pitch entry. fb_pitch however already contains '(win_data-bpp 3)' factor, so it should be removed from final buffer size calculation formula. This patch fixes this issue, solving possible IOMMU page fault caused by FIMD module accessing memory outside of the given display buffer. Signed-off by: Marek Szyprowski m.szyprow...@samsung.com CC: sta...@vger.kernel.org # v4.0+ --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 0e93ed792224..f29a13e0524c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -689,7 +689,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc, unsigned int win) writel(val, ctx-regs + VIDWx_BUF_START(win, 0)); /* buffer end address */ - size = plane-pitch * plane-crtc_height * (plane-bpp 3); + size = plane-pitch * plane-crtc_height; val = (unsigned long)(dma_addr + size); writel(val, ctx-regs + VIDWx_BUF_END(win, 0)); -- 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
Re: [PATCH] drm/exynos: fimd: fix buffer size calculation
On 2015년 04월 13일 16:28, Marek Szyprowski wrote: Commit adacb228d72b9529f8de0769cc33414c3012054d (drm: Exynos: Respect framebuffer pitch for FIMD/Mixer) changed the way of buffer size calcularion: it replaced fb_width by fb_pitch entry. fb_pitch however already contains '(win_data-bpp 3)' factor, so it should be removed from final buffer size calculation formula. This patch fixes this issue, solving possible IOMMU page fault caused by FIMD module accessing memory outside of the given display buffer. This fixup had already been posted by Daniel Stone, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next Thanks, Inki Dae Signed-off by: Marek Szyprowski m.szyprow...@samsung.com CC: sta...@vger.kernel.org # v4.0+ --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 0e93ed792224..f29a13e0524c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -689,7 +689,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc, unsigned int win) writel(val, ctx-regs + VIDWx_BUF_START(win, 0)); /* buffer end address */ - size = plane-pitch * plane-crtc_height * (plane-bpp 3); + size = plane-pitch * plane-crtc_height; val = (unsigned long)(dma_addr + size); writel(val, ctx-regs + VIDWx_BUF_END(win, 0)); -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH 1/1] ARM: dts: Add LEDs on odroid XU3 board
This patch adds the RGB-LED on XU3 as 3 gpio-leds.
It is derived from hardkernel's 3.10 tree.
Tested-by: Anand Moon linux.am...@gmail.com
Signed-off-by: Markus Reichl m.rei...@fivetechno.de
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index a519c86..0a32302 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -278,6 +278,30 @@
rtc@101E {
status = okay;
};
+
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = blue:heartbeart;
+ gpios = gpb2 2 0;
+ default-state = off;
+ linux,default-trigger = heartbeat;
+ };
+
+ eMMC {
+ label = green:eMMC;
+ gpios = gpb2 1 0;
+ default-state = off;
+ linux,default-trigger = mmc0;
+ };
+
+ microSD {
+ label = red:microSD;
+ gpios = gpx2 3 0;
+ default-state = off;
+ linux,default-trigger = mmc1;
+ };
+ };
};
hdmi {
--
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
--
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] drm/exynos: remove unnecessary calls to disable_plane()
Hi,
On 04/11/2015 03:57 AM, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The planes are already disabled by the drm_atomic_helper_commit() code
so we don't need to disable the in these two places.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 8
2 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 519c569..9bf25ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -47,8 +47,6 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct drm_plane *plane;
- int ret;
if (!exynos_crtc-enabled)
return;
@@ -64,15 +62,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
exynos_crtc-ops-dpms(exynos_crtc, DRM_MODE_DPMS_OFF);
exynos_crtc-enabled = false;
-
- drm_for_each_legacy_plane(plane, crtc-dev-mode_config.plane_list) {
- if (plane-crtc != crtc)
- continue;
-
- ret = plane-funcs-disable_plane(plane);
- if (ret)
- DRM_ERROR(Failed to disable plane %d\n, ret);
- }
If remove here disable codes, when crtc is disabled, enabled overlay
planes may not be disabled.
E.g, user can remove fb of crtc via DRM_IOCTL_MODE_RMFB ioctl, then crtc
is disabled but overlay planes no.
Thanks.
}
static bool
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 0648ba4..7b89fd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -81,17 +81,9 @@ static void exynos_drm_encoder_disable(struct drm_encoder
*encoder)
{
struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
struct exynos_drm_display *display = exynos_encoder-display;
- struct drm_plane *plane;
- struct drm_device *dev = encoder-dev;
if (display-ops-dpms)
display-ops-dpms(display, DRM_MODE_DPMS_OFF);
-
- /* all planes connected to this encoder should be also disabled. */
- drm_for_each_legacy_plane(plane, dev-mode_config.plane_list) {
- if (plane-crtc (plane-crtc == encoder-crtc))
- plane-funcs-disable_plane(plane);
- }
}
static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
--
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/1] ARM: dts: Make DP a consumer of DISP1 power domain on Exynos5420
2015-04-13 5:30 GMT+09:00 Javier Martinez Canillas javier.marti...@collabora.co.uk: Commit ea08de16eb1b (ARM: dts: Add DISP1 power domain for exynos5420) added a device node for the Exynos5420 DISP1 power domain but dit not make the DP controller a consumer of that power domain. This causes an Unhandled fault: imprecise external abort error if the exynos-dp driver tries to access the DP controller registers and the PD was turned off. This lead to a kernel panic and a complete system hang. Make the DP controller device node a consumer of the DISP1 power domain to ensure that the PD is turned on when the exynos-dp driver is probed. Fixes: ea08de16eb1b (ARM: dts: Add DISP1 power domain for exynos5420) Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Hello, This latent bug was not exposed before since drivers for other devices marked as DISP1 power domain consumers were probed before exynos-dp so the PD was already on which made possible to access the DP registers. But regulator: Defer lookup of supply to regulator_get [0] that is in linux-next from a couple of days now, changed the order on which the drivers' probes succeed so the PD was disabled during exynos-dp probe. Exynos5420 machines with a display such as the Exynos5420 Peach Pit and Exynos5800 Peach Pi were failing to boot due this issue, i.e: [1]. Olof, Could you please confirm $subject fixes the issue catched by your farm? Krzysztof, This patch conflicts with your Exynos5 phandle notation cleanup [2] but I preferred to send it on top of linux-next instead of making your series a dependency since it fixes a very important bug that had caused -next to be broken on these matchines for days now. Sure, I don't mind. My patchset is just a cleanup so it can wait and should not block important stuff. 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 v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark,
On 04/13/2015 07:56 PM, Mark Rutland wrote:
Hi Chanwoo,
Could you please reply to the below?
Without an answer I'm going to have to ask for the patch to be unqueued
for the moment, and I'd prefer that we came to a solution instead.
I'm sorry about late reply.
Thanks,
Mark.
On Tue, Apr 07, 2015 at 11:25:27AM +0100, Mark Rutland wrote:
I'm very worried about adding a DT that's known broken, especially when
we have no idea as to if/when the FW will be fixed judging from prior
replies.
As I replied, I can not fix the FW because I don't have any code of FW.
Surely you are able to contact those who do?
I don't have any solution to fix it on Linux kernel level.
So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
I disagree. I do not want to add a DT that is known to be broken;
especially when we have no idea how to fix it. It creates long-term
maintenance pain for everyone, and marginal gain for few. A comment does
nothing to aid the end-user.
So NAK to the PSCI node and PSCI enable method in this dts until we
either have a working firmware, or a reasonable mechanism to handle the
deficiency.
There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
To fix this issue, we must need the help of firmware developer.
But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
I didn't ask any help to firmware engineer because I didn't know who firmware
engineer
and also didn't access the source code. If I knew the engineer and can access
them,
I would have asked some help to them or inquired the reason about CPU0 not
hotplugged.
Also, as I mentioned on previous mail, all Exynos SoCs can not turn
off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.
Is there a particular reason that CPU0 cannot be hotplugged?
Unfortunately, I don't know correctly why Exynos SoC cannot hotplug the CPU0.
But, IMHO, SoC had to maintain at least online core for operation.
Just Exynos SoC has remained the CPU0 as at least online core.
In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: dts: Refactor Exynos5 boards for phandle notation
2015-04-13 5:07 GMT+09:00 Arnd Bergmann a...@arndb.de:
On Sunday 12 April 2015 21:24:47 Krzysztof Kozlowski wrote:
The phandle notation reduces possible mistakes when overriding nodes
by child board files and reduces duplication of addresses.
The patchset refactors Exynos5 boards to use the phandle way.
Tested by comparison of decompiled DTB for each commit.
The patches look fine, but the description is wrong as you are not
using 'phandles' here, you are using 'labels'.
Heh, I suspected this but some docs I found referred to label { ...
} also as a phandle. Thanks for pointing this out. I'll respin.
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 v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Chanwoo,
Could you please reply to the below?
Without an answer I'm going to have to ask for the patch to be unqueued
for the moment, and I'd prefer that we came to a solution instead.
Thanks,
Mark.
On Tue, Apr 07, 2015 at 11:25:27AM +0100, Mark Rutland wrote:
I'm very worried about adding a DT that's known broken, especially when
we have no idea as to if/when the FW will be fixed judging from prior
replies.
As I replied, I can not fix the FW because I don't have any code of FW.
Surely you are able to contact those who do?
I don't have any solution to fix it on Linux kernel level.
So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
I disagree. I do not want to add a DT that is known to be broken;
especially when we have no idea how to fix it. It creates long-term
maintenance pain for everyone, and marginal gain for few. A comment does
nothing to aid the end-user.
So NAK to the PSCI node and PSCI enable method in this dts until we
either have a working firmware, or a reasonable mechanism to handle the
deficiency.
There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
To fix this issue, we must need the help of firmware developer.
But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
Also, as I mentioned on previous mail, all Exynos SoCs can not turn
off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.
Is there a particular reason that CPU0 cannot be hotplugged?
In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] mmc: pwrseq: Fix error code propagation in mmc_pwrseq_simple_alloc()
If the struct mmc_pwrseq_match .alloc function used to allocate a
struct mmc_pwrseq fails, the error is propagated to mmc_of_parse().
But instead of returning the error code in pwrseq, host-pwrseq is
returned which will always be 0. So mmc_of_parse() succeeds even if
the pwrseq .alloc function failed and host-pwrseq is NULL.
This makes the SDIO device to not be powered if the power sequencing
.alloc functions wants to be deferred due a missing resource because
the mmc controller driver probe did wrongly succeed.
Fixes: 0f12a0ce4ce4a (mmc: pwrseq: simplify alloc/free hooks)
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/mmc/core/pwrseq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/pwrseq.c b/drivers/mmc/core/pwrseq.c
index ab2129781161..4c1d1757dbf9 100644
--- a/drivers/mmc/core/pwrseq.c
+++ b/drivers/mmc/core/pwrseq.c
@@ -73,7 +73,7 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
pwrseq = match-alloc(host, pdev-dev);
if (IS_ERR(pwrseq)) {
- ret = PTR_ERR(host-pwrseq);
+ ret = PTR_ERR(pwrseq);
goto err;
}
--
2.1.4
--
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 RESEND] ARM: dts: exynos4412: Enable AX88760 USB hub on Origen board
Enable the Origen's usb phy and ohci devices in the device tree. Also
add the samsung,vbus-gpio property to enable the GPX3(5) gpio pin so
the AX88760 hub is powered.
Signed-off-by: Matthew Leach matt...@mattleach.net
---
arch/arm/boot/dts/exynos4412-origen.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index bd8b730..c810ca3 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -531,4 +531,19 @@
clock-frequency = 2400;
};
};
+
+ exynos-usbphy@125B {
+ status = okay;
+ };
+
+ ehci@1258 {
+ samsung,vbus-gpio = gpx3 5 1;
+ status = okay;
+ port@1{
+ status = okay;
+ };
+ port@2 {
+ status = okay;
+ };
+ };
};
--
2.3.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 v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
So NAK to the PSCI node and PSCI enable method in this dts until we
either have a working firmware, or a reasonable mechanism to handle the
deficiency.
There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
To fix this issue, we must need the help of firmware developer.
But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
I didn't ask any help to firmware engineer because I didn't know who firmware
engineer
and also didn't access the source code. If I knew the engineer and can access
them,
I would have asked some help to them or inquired the reason about CPU0 not
hotplugged.
You must have acquired the firmware (or board(s) with the firmware
preloaded) from somewhere. Surely you can work backwards from there to
file a bug report and/or inquire as to who you need to speak to...
Mark.
--
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
