Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Andreas, On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote: Hi Ajay, Am 28.07.2014 08:13, schrieb Ajay kumar: On 7/27/14, Andreas Färber afaer...@suse.de wrote: Am 25.07.2014 21:22, schrieb Ajay Kumar: This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. I'm trying to test this with a modified exynos5250-spring DT based off kgene's for-next branch due to DT, and I run into the following: CC drivers/gpu/drm/bridge/ptn3460.o drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’: drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of function ‘drm_connector_register’ [-Werror=implicit-function-declaration] drm_connector_register(ptn_bridge-connector); ^ Hope this might help: http://www.spinics.net/lists/dri-devel/msg60578.html That fixed my build, thanks. Unfortunately the most I got on Spring with attached DT was a blank screen with a white horizontal line in the middle. Then, I think bridge chip is working fine. You just need to configure the proper mode for FIMD. You can see backlight also, right? Do I need to specify a specific panel model for Spring? Yes! Try using chunghwa,claa101wb01 as compatible string for panel node. For testing I re-applied your iommu patches (which btw fail now for 5420 due to disp_pd) but didn't know what to do about your panel-lvds regulator patch now that it's gone. Ignore that regulator patch. Also, please attach the bootlog if possible after trying this. Regards, Ajay -- 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 V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
On snow, the bridge chip provides the display mode instead of the panel.
That is why display was working for me.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Ok. I will resend DT patches removing simple-panel fallback.
Regards,
Ajay
--
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 V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
Hi Andreas,
On Tue, Jul 29, 2014 at 4:59 PM, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/vendor-prefixes.txt|1 +
.../devicetree/bindings/video/bridge/ps8622.txt| 19 +
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/ps8622.c| 602
5 files changed, 633 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..b4a99cc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ nxp NXP Semiconductors
onnn ON Semiconductor Corp.
opencoresOpenCores.org
panasonicPanasonic Corporation
+parade Parade Technologies Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
plathome Plat'Home Co., Ltd.
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..fdeafb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,19 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: parade,ps8622 or parade,ps8625
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+
+Example:
+ ps8622-bridge@48 {
Nit: Shouldn't this be lvds-bridge like in 7/8 or something else not
derived from the specific model? Applies to the DT series as well.
Right. I will fix this while sending the next series.
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1
+ };
[...]
diff --git a/drivers/gpu/drm/bridge/ps8622.c
b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..ec60fcf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,602 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
[...]
+MODULE_AUTHOR(Vincent Palatin vpala...@chromium.org);
+MODULE_DESCRIPTION(Parade ps8622 eDP-LVDS converter driver);
+MODULE_LICENSE(GPL);
GPL v2?
Ok. Will change it.
Regards,
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: exynos4: remove duplicate div_core2 divider clock instantiation
The 'div_core2' clock and the 'arm_clk' divider clocks are instances of
the same divider clock. So remove the 'arm_clk' clock instance.
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
This patch is based on for-next branch of Samsung clock tree.
drivers/clk/samsung/clk-exynos4.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index ac163d7..8617f49 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -719,7 +719,7 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_periph, div_core2, DIV_CPU0, 12, 3),
DIV(0, div_atb, mout_core, DIV_CPU0, 16, 3),
DIV(0, div_pclk_dbg, div_atb, DIV_CPU0, 20, 3),
- DIV(0, div_core2, div_core, DIV_CPU0, 28, 3),
+ DIV(CLK_ARM_CLK, div_core2, div_core, DIV_CPU0, 28, 3),
DIV(0, div_copy, mout_hpm, DIV_CPU1, 0, 3),
DIV(0, div_hpm, div_copy, DIV_CPU1, 4, 3),
DIV(0, div_clkout_cpu, mout_clkout_cpu, CLKOUT_CMU_CPU, 8, 6),
@@ -769,7 +769,6 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_spi_pre2, div_spi2, DIV_PERIL2, 8, 8),
DIV(0, div_audio1, mout_audio1, DIV_PERIL4, 0, 4),
DIV(0, div_audio2, mout_audio2, DIV_PERIL4, 16, 4),
- DIV(CLK_ARM_CLK, arm_clk, div_core2, DIV_CPU0, 28, 3),
DIV(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3),
DIV_F(0, div_mipi_pre0, div_mipi0, DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
@@ -1486,7 +1485,7 @@ static void __init exynos4_clk_init(struct device_node
*np,
exynos4_soc == EXYNOS4210 ? Exynos4210 : Exynos4x12,
_get_rate(sclk_apll), _get_rate(sclk_mpll),
_get_rate(sclk_epll), _get_rate(sclk_vpll),
- _get_rate(arm_clk));
+ _get_rate(div_core2));
}
--
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 v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
Changes since v8: - Fixes suggested by Tomasz Figa. This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq drivers and enables the use of cpufreq-cpu0 driver for these platforms. This series also enables cpufreq support for Exynos5420 using arm_big_little cpufreq driver. This patch series is dependent on two other patches 1. ARM: dts: add CPU nodes for Exynos4 SoCs - https://lkml.org/lkml/2014/7/21/315 2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt - http://www.spinics.net/lists/arm-kernel/msg351134.html 3. clk: exynos4: remove duplicate div_core2 divider clock instantiation - http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34859.html Thomas Abraham (6): clk: samsung: add infrastructure to register cpu clocks clk: samsung: add cpu clock configuration data and instantiate cpu clock ARM: dts: Exynos: add CPU OPP and regulator supply property ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support clk: samsung: remove unused clock aliases and update clock flags arch/arm/boot/dts/exynos4210-origen.dts |4 + arch/arm/boot/dts/exynos4210-trats.dts |4 + arch/arm/boot/dts/exynos4210-universal_c210.dts |4 + arch/arm/boot/dts/exynos4210.dtsi | 14 +- 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.dtsi | 25 +- arch/arm/boot/dts/exynos5420.dtsi | 38 +++ arch/arm/mach-exynos/exynos.c | 24 +- drivers/clk/samsung/Makefile|2 +- drivers/clk/samsung/clk-cpu.c | 335 +++ drivers/clk/samsung/clk-cpu.h | 91 ++ drivers/clk/samsung/clk-exynos4.c | 63 +++-- drivers/clk/samsung/clk-exynos5250.c| 44 ++- drivers/clk/samsung/clk-exynos5420.c| 72 - drivers/cpufreq/Kconfig.arm | 22 -- drivers/cpufreq/Makefile|2 - drivers/cpufreq/exynos4210-cpufreq.c| 184 - drivers/cpufreq/exynos5250-cpufreq.c| 210 -- include/dt-bindings/clock/exynos5250.h |1 + include/dt-bindings/clock/exynos5420.h |2 + 22 files changed, 690 insertions(+), 463 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c 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 v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
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 Exynos4210,
Exynos5250 and Exynos5420.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c | 15 +++
drivers/clk/samsung/clk-exynos5250.c | 25 ++
drivers/clk/samsung/clk-exynos5420.c | 45
include/dt-bindings/clock/exynos5250.h |1 +
include/dt-bindings/clock/exynos5420.h |2 ++
5 files changed, 88 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 8617f49..101f549 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -19,6 +19,7 @@
#include linux/syscore_ops.h
#include clk.h
+#include clk-cpu.h
/* Exynos4 clock controller register offsets */
#define SRC_LEFTBUS0x4200
@@ -1355,6 +1356,16 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst = {
+ { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
+ { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
+ { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
+ { 0 },
+};
+
static void __init exynos4_core_down_clock(enum exynos4_soc soc)
{
unsigned int tmp;
@@ -1458,6 +1469,10 @@ static void __init exynos4_clk_init(struct device_node
*np,
samsung_clk_register_fixed_factor(ctx,
exynos4210_fixed_factor_clks,
ARRAY_SIZE(exynos4210_fixed_factor_clks));
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_core_p4210[0], mout_core_p4210[1], 0x14200,
+ e4210_armclk_d, ARRAY_SIZE(e4210_armclk_d),
+ CLK_CPU_NEEDS_DEBUG_ALT_DIV | CLK_CPU_HAS_DIV1);
} else {
samsung_clk_register_mux(ctx, exynos4x12_mux_clks,
ARRAY_SIZE(exynos4x12_mux_clks));
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 70ec3d2..e19e365 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,26 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+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 +818,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,
[PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific cpufreq driver
to using generic cpufreq drivers.
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
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/boot/dts/exynos4210-origen.dts |4 +++
arch/arm/boot/dts/exynos4210-trats.dts |4 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts |4 +++
arch/arm/boot/dts/exynos4210.dtsi | 14 -
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.dtsi | 25 ++-
arch/arm/boot/dts/exynos5420.dtsi | 38 +++
9 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index f767c42..887dded 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -334,3 +334,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = buck1_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..66119dd 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -446,3 +446,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = varm_breg;
+};
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3a..bf0a39c 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -492,3 +492,7 @@
mdma1 {
reg = 0x1284 0x1000;
};
+
+cpu0 {
+ cpu0-supply = vdd_arm_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63..69bac07 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,10 +35,22 @@
#address-cells = 1;
#size-cells = 0;
- cpu@900 {
+ cpu0: cpu@900 {
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0x900;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 16;
+
+ operating-points =
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
+ ;
};
cpu@901 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
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
+
[PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
drivers/clk/samsung/Makefile |2 +-
drivers/clk/samsung/clk-cpu.c | 335 +
drivers/clk/samsung/clk-cpu.h | 91 +++
3 files changed, 427 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/samsung/clk-cpu.c
create mode 100644 drivers/clk/samsung/clk-cpu.h
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 6fb4bc6..8909c93 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -2,7 +2,7 @@
# Samsung Clock specific Makefile
#
-obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..009a21b
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham thomas...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility function to register CPU clock for Samsung
+ * Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or a
+ * group of CPUs. The CPU clock is typically derived from a hierarchy of clock
+ * blocks which includes mux and divider blocks. There are a number of other
+ * auxiliary clocks supplied to the CPU domain such as the debug blocks and AXI
+ * clock for CPU domain. The rates of these auxiliary clocks are related to the
+ * CPU clock rate and this relation is usually specified in the hardware manual
+ * of the SoC or supplied after the SoC characterization.
+ *
+ * The below implementation of the CPU clock allows the rate changes of the CPU
+ * clock and the corresponding rate changes of the auxillary clocks of the CPU
+ * domain. The platform clock driver provides a clock register configuration
+ * for each configurable rate which is then used to program the clock hardware
+ * registers to acheive a fast co-oridinated rate change for all the CPU domain
+ * clocks.
+ *
+ * On a rate change request for the CPU clock, the rate change is propagated
+ * upto the PLL supplying the clock to the CPU domain clock blocks. While the
+ * CPU domain PLL is reconfigured, the CPU domain clocks are driven using an
+ * alternate clock source. If required, the alternate clock source is divided
+ * down in order to keep the output clock rate within the previous OPP limits.
+*/
+
+#include linux/errno.h
+#include clk-cpu.h
+
+#define E4210_SRC_CPU 0x0
+#define E4210_STAT_CPU 0x200
+#define E4210_DIV_CPU0 0x300
+#define E4210_DIV_CPU1 0x304
+#define E4210_DIV_STAT_CPU00x400
+#define E4210_DIV_STAT_CPU10x404
+
+#define E4210_DIV0_RATIO0_MASK 0x7
+#define E4210_DIV1_HPM_MASK(0x7 4)
+#define E4210_DIV1_COPY_MASK (0x7 0)
+#define E4210_MUX_HPM_MASK (1 20)
+#define E4210_DIV0_ATB_SHIFT 16
+#define E4210_DIV0_ATB_MASK(DIV_MASK E4210_DIV0_ATB_SHIFT)
+
+#define MAX_DIV8
+#define DIV_MASK 7
+#define DIV_MASK_ALL 0x
+#define MUX_MASK 7
+
+/*
+ * Helper function to wait until divider(s) have stabilized after the divider
+ * value has changed.
+ */
+static void wait_until_divider_stable(void __iomem *div_reg, unsigned long
mask)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(10);
+
+ do {
+ if (!(readl(div_reg) mask))
+ return;
+ } while (time_before(jiffies, timeout));
+
+ pr_err(%s: timeout in divider stablization\n, __func__);
+}
+
+/*
+ * Helper function to wait until mux has stabilized after the mux selection
+ * value was changed.
+ */
+static void wait_until_mux_stable(void __iomem *mux_reg, u32 mux_pos,
+ unsigned long mux_value)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(10);
+
+ do {
+ if (((readl(mux_reg) mux_pos) MUX_MASK) == mux_value)
+ return;
+ } while (time_before(jiffies, timeout));
+
+ pr_err(%s: re-parenting mux timed-out\n, __func__);
+}
+
+/* common round rate callback useable for all types of CPU clocks */
[PATCH v9 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
Exynos4210 and Exynos5250 based platforms have switched over to use generic
cpufreq drivers for cpufreq functionality. So the Exynos specific cpufreq
drivers for these platforms can be removed.
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/cpufreq/Kconfig.arm | 22
drivers/cpufreq/Makefile |2 -
drivers/cpufreq/exynos4210-cpufreq.c | 184 -
drivers/cpufreq/exynos5250-cpufreq.c | 210 --
4 files changed, 418 deletions(-)
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7364a53..f81fc3e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -28,17 +28,6 @@ config ARM_VEXPRESS_SPC_CPUFREQ
config ARM_EXYNOS_CPUFREQ
bool
-config ARM_EXYNOS4210_CPUFREQ
- bool SAMSUNG EXYNOS4210
- depends on CPU_EXYNOS4210
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS4210
- SoC (S5PV310 or S5PC210).
-
- If in doubt, say N.
-
config ARM_EXYNOS4X12_CPUFREQ
bool SAMSUNG EXYNOS4x12
depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
@@ -50,17 +39,6 @@ config ARM_EXYNOS4X12_CPUFREQ
If in doubt, say N.
-config ARM_EXYNOS5250_CPUFREQ
- bool SAMSUNG EXYNOS5250
- depends on SOC_EXYNOS5250
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS5250
- SoC.
-
- If in doubt, say N.
-
config ARM_EXYNOS5440_CPUFREQ
bool SAMSUNG EXYNOS5440
depends on SOC_EXYNOS5440
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..fac36ef 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,9 +52,7 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) +=
arm_big_little_dt.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
deleted file mode 100644
index 61a5431..000
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4210 - CPU frequency scaling support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/slab.h
-#include linux/cpufreq.h
-#include linux/of.h
-#include linux/of_address.h
-
-#include exynos-cpufreq.h
-
-static struct clk *cpu_clk;
-static struct clk *moutcore;
-static struct clk *mout_mpll;
-static struct clk *mout_apll;
-static struct exynos_dvfs_info *cpufreq;
-
-static unsigned int exynos4210_volt_table[] = {
- 125, 115, 105, 975000, 95,
-};
-
-static struct cpufreq_frequency_table exynos4210_freq_table[] = {
- {0, L0, 1200 * 1000},
- {0, L1, 1000 * 1000},
- {0, L2, 800 * 1000},
- {0, L3, 500 * 1000},
- {0, L4, 200 * 1000},
- {0, 0, CPUFREQ_TABLE_END},
-};
-
-static struct apll_freq apll_freq_4210[] = {
- /*
-* values:
-* freq
-* clock divider for CORE, COREM0, COREM1, PERIPH, ATB, PCLK_DBG, APLL,
RESERVED
-* clock divider for COPY, HPM, RESERVED
-* PLL M, P, S
-*/
- APLL_FREQ(1200, 0, 3, 7, 3, 4, 1, 7, 0, 5, 0, 0, 150, 3, 1),
- APLL_FREQ(1000, 0, 3, 7, 3, 4, 1, 7, 0, 4, 0, 0, 250, 6, 1),
- APLL_FREQ(800, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 200, 6, 1),
- APLL_FREQ(500, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 250, 6, 2),
- APLL_FREQ(200, 0, 1, 3, 1, 3, 1, 0, 0, 3, 0, 0, 200, 6, 3),
-};
-
-static void exynos4210_set_clkdiv(unsigned int div_index)
-{
- unsigned int tmp;
-
- /* Change Divider - CPU0 */
-
- tmp = apll_freq_4210[div_index].clk_div_cpu0;
-
- __raw_writel(tmp, cpufreq-cmu_regs + EXYNOS4_CLKDIV_CPU);
-
- do {
- tmp = __raw_readl(cpufreq-cmu_regs + EXYNOS4_CLKDIV_STATCPU);
- } while
[PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.
Suggested-by: Tomasz Figa t.f...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 493dbc2..e61bb36 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -281,6 +281,28 @@ static void __init exynos_init_irq(void)
exynos_map_pmu();
}
+static const struct of_device_id exynos_cpufreq_matches[] = {
+ { .compatible = samsung,exynos5420, .data = arm-bL-cpufreq-dt },
+ { .compatible = samsung,exynos5250, .data = cpufreq-cpu0 },
+ { .compatible = samsung,exynos4210, .data = cpufreq-cpu0 },
+ { .compatible = samsung,exynos5440, .data = exynos5440-cpufreq },
+ { /* sentinel */ }
+};
+
+static void __init exynos_cpufreq_init(void)
+{
+ struct device_node *root = of_find_node_by_path(/);
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos_cpufreq_matches, root);
+ if (!match) {
+ platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ return;
+ }
+
+ platform_device_register_simple(match-data, -1, NULL, 0);
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -320,7 +342,7 @@ static void __init exynos_dt_machine_init(void)
of_machine_is_compatible(samsung,exynos5250))
platform_device_register(exynos_cpuidle);
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ exynos_cpufreq_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
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 v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers,
the unused clock aliases can be removed. In addition to this, the individual
clock blocks which are now encapsulated with the consolidate CPU clock type
can now be marked with read-only flags.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c| 48 +-
drivers/clk/samsung/clk-exynos5250.c | 19 --
drivers/clk/samsung/clk-exynos5420.c | 27 ---
3 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 101f549..04619a1 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -578,7 +578,8 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, mout_fimd1, group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(0, mout_mipi1, group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, sclk_mpll, mout_mpll_p, SRC_CPU, 8, 1),
- MUX(CLK_MOUT_CORE, mout_core, mout_core_p4210, SRC_CPU, 16, 1),
+ MUX_F(CLK_MOUT_CORE, mout_core, mout_core_p4210, SRC_CPU, 16, 1, 0,
+ CLK_MUX_READ_ONLY),
MUX(0, mout_hpm, mout_core_p4210, SRC_CPU, 20, 1),
MUX(CLK_SCLK_VPLL, sclk_vpll, sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, mout_fimc0, group1_p4210, SRC_CAM, 0, 4),
@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_clkout_rightbus, mout_clkout_rightbus,
CLKOUT_CMU_RIGHTBUS, 8, 6),
- DIV(0, div_core, mout_core, DIV_CPU0, 0, 3),
- DIV(0, div_corem0, div_core2, DIV_CPU0, 4, 3),
- DIV(0, div_corem1, div_core2, DIV_CPU0, 8, 3),
- DIV(0, div_periph, div_core2, DIV_CPU0, 12, 3),
- DIV(0, div_atb, mout_core, DIV_CPU0, 16, 3),
- DIV(0, div_pclk_dbg, div_atb, DIV_CPU0, 20, 3),
- DIV(CLK_ARM_CLK, div_core2, div_core, DIV_CPU0, 28, 3),
- DIV(0, div_copy, mout_hpm, DIV_CPU1, 0, 3),
- DIV(0, div_hpm, div_copy, DIV_CPU1, 4, 3),
+ DIV_F(0, div_core, mout_core, DIV_CPU0, 0, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_corem0, div_core2, DIV_CPU0, 4, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_corem1, div_core2, DIV_CPU0, 8, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_periph, div_core2, DIV_CPU0, 12, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_atb, mout_core, DIV_CPU0, 16, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_pclk_dbg, div_atb, DIV_CPU0, 20, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(CLK_ARM_CLK, div_core2, div_core, DIV_CPU0, 28, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_copy, mout_hpm, DIV_CPU1, 0, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
+ DIV_F(0, div_hpm, div_copy, DIV_CPU1, 4, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV(0, div_clkout_cpu, mout_clkout_cpu, CLKOUT_CMU_CPU, 8, 6),
DIV(0, div_fimc0, mout_fimc0, DIV_CAM, 0, 4),
@@ -770,7 +780,8 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
DIV(0, div_spi_pre2, div_spi2, DIV_PERIL2, 8, 8),
DIV(0, div_audio1, mout_audio1, DIV_PERIL4, 0, 4),
DIV(0, div_audio2, mout_audio2, DIV_PERIL4, 16, 4),
- DIV(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3),
+ DIV_F(CLK_SCLK_APLL, sclk_apll, mout_apll, DIV_CPU0, 24, 3,
+ CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
DIV_F(0, div_mipi_pre0, div_mipi0, DIV_LCD0, 20, 4,
CLK_SET_RATE_PARENT, 0),
DIV_F(0, div_mmc_pre0, div_mmc0, DIV_FSYS1, 8, 8,
@@ -1187,17 +1198,10 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
0),
};
-static struct samsung_clock_alias exynos4_aliases[] __initdata = {
+static struct samsung_clock_alias exynos4x12_aliases[] __initdata = {
ALIAS(CLK_MOUT_CORE, NULL, moutcore),
ALIAS(CLK_ARM_CLK, NULL, armclk),
ALIAS(CLK_SCLK_APLL, NULL, mout_apll),
-};
-
-static struct samsung_clock_alias exynos4210_aliases[] __initdata = {
- ALIAS(CLK_SCLK_MPLL, NULL, mout_mpll),
-};
-
-static struct samsung_clock_alias exynos4x12_aliases[] __initdata = {
ALIAS(CLK_MOUT_MPLL_USER_C, NULL, mout_mpll),
};
@@ -1464,8 +1468,6 @@ static void __init exynos4_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos4210_div_clks));
samsung_clk_register_gate(ctx, exynos4210_gate_clks,
Re: [RFC 3/5] regulator: core: Only apply constraints if available on list voltage
Hello Mark, thanks a lot for all your feedback. On 07/29/2014 07:18 PM, Mark Brown wrote: On Tue, Jul 29, 2014 at 06:28:57PM +0200, Javier Martinez Canillas wrote: But for load switches that don't define a voltage output, the parent supply voltage is used so the constraints should only be applied if they were defined for the child regulators. No, think about what you're doing here and why we're filtering out unsettable voltages - this causes problems for consumers on regulators that don't have any ability to vary voltages since they will now be able to list voltages that they can't select. Understood. Thanks for the explanation. I would also expect any regulator where the supplied devices are able to vary the voltage to explicitly provide a constraint even if the implementation is done in a parent regulator. There may be constraints on the child supply which aren't directly present on the parent supply and can be ignored if the child supply is turned off. Agreed, if I explicitly set the voltage constraints on the child supply then this patch is indeed not needed. 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: [RFC 5/5] ARM: dts: Improve Peach Pit and Pi power scheme model
On 07/29/2014 07:20 PM, Mark Brown wrote: On Tue, Jul 29, 2014 at 06:28:59PM +0200, Javier Martinez Canillas wrote: The DeviceTree files for the Peach Pit and Pi machines have a simplistic model of the connections between the different regulators since not all the tps65090 regulators get their input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 parent supply is indded VDC but the fet1-6 get their input supply from the DCDC1 and DCDC2 output voltage rails. Acked-by: Mark Brown broo...@linaro.org Thanks. This *should* be independent of the rest of this series. Yes, it is independent as I explained in the cover letter. I just added in the series since it was an RFC and I wanted you to have the complete picture. I'll post it as an separate patch with your ack, sorry if this may cause an inconvenience to you. 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: [RFC 4/5] regulator: tps65090: Set voltage for fixed regulators
On 07/29/2014 07:36 PM, Mark Brown wrote: On Tue, Jul 29, 2014 at 06:28:58PM +0200, Javier Martinez Canillas wrote: +#define tps65090_REG_VAR(_id, _sname, en_reg, _en_bits, _ops) \ +tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 0, 0, _ops) I'd expect this to describe a variable regulator when in fact it seems it describes a switch with no regulation. Better name please. Yes, when writing the patch I thought of a switch as a non-fixed regulator whose output voltage is variable and depend on its input supply voltage. That's why I used VAR but I agree that is a bad name and I'll change it. Thanks a lot and 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: [RFC 1/5] regulator: core: Get voltage from parent if not available
On 07/29/2014 08:26 PM, Mark Brown wrote: On Tue, Jul 29, 2014 at 06:28:55PM +0200, Javier Martinez Canillas wrote: Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So the drivers for Applied, thanks. The term load switch is a bit unusual - they're usually just called switches (or sometimes FETs since that tends to be the implementation). Thanks, I used the terminology from the tps65090 data manual [0] that refers these components as load switches all around the document. Although they are called FETs indeed in the tables and register names. Best regards, Javier [0]: http://www.ti.com/lit/gpn/tps65090 -- 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 V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
On snow, the bridge chip provides the display mode instead of the panel.
That is why display was working for me.
Okay, I suppose under some circumstances that might make sense. Although
it's still always the panel that dictates the display timings, so the
panel node needs to have a panel model specific compatible value with a
matching entry in the panel-simple driver so that it can even be used in
setups without a bridge.
One other thing: how does the bridge know which mode to drive? I suspect
that it can drive more than one mode? Can it freely be configured or
does it have a predefined set of modes? If the latter, then according to
what you said above there needs to be a way to configure the bridge (via
DT?) so that it reports the mode matching the panel. I wonder if that
should be handled completely in code, so that for example a bridge has a
panel attached it can use the panel's .get_modes() and select a matching
mode among the set that it supports.
Thierry
pgpIFkEXWHADN.pgp
Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Sat, Jul 26, 2014 at 12:52:02AM +0530, Ajay Kumar wrote: This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. Hi Ajay, I very much like where this is going. There are a few rough edges still, but generally this is pretty much what I had imagined. Thanks for bearing with me. Generally I think it would be safer to restructure some of the patches a little so that they can be more easily applied and keep bisectability. I'll go into more detail in the individual patches. Thierry pgpngbWhNwIVA.pgp Description: PGP signature
Re: [PATCH V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines
On Sat, Jul 26, 2014 at 12:52:03AM +0530, Ajay Kumar wrote: Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BACKLIGHT_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BACKLIGHT_EN -- stop video data -- poweroff LCD unit/LCD_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only two callbacks, i.e panel_enable and panel_disable are supported. This patch adds: -- prepare callback which can be called before the actual video data is on, and then call the enable callback after the video data is available. -- unprepare callback which can be called after the video data is off, and use disable callback to do something before switching off the video data. Now, we can easily map the above scenario as shown below: poweron LCD unit/LCD_EN = prepare callback poweron LED unit/BACKLIGHT_EN = enable callback poweroff LED unit/BACKLIGHT_EN = disable callback poweroff LCD unit/LCD_EN = unprepare callback Also, a helper function for get_modes is added. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- include/drm/drm_panel.h | 26 ++ 1 file changed, 26 insertions(+) I had already decided to apply an earlier version that you posted (I think the only difference was that it didn't have the inline implementation for drm_panel_get_modes() yet), reworded the commit message a little (to be less specific about LED, LCD and backlight units) and added some kerneldoc for struct drm_panel_funcs. What I propose is to merge that patch (I'll hopefully push it today so that it shows up in tomorrow's linux-next) and then apply a separate patch to add drm_panel_get_modes(). Do you have any objections to that? Thierry pgpZsIGJBIQXI.pgp Description: PGP signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree
at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
On snow, the bridge chip provides the display mode instead of the panel.
That is why display was working for me.
Okay, I suppose under some circumstances that might make sense. Although
it's still always the panel that dictates the display timings, so the
panel node needs to have a panel model specific compatible value with a
matching entry in the panel-simple driver so that it can even be used in
setups without a bridge.
Well, I am okay with adding the compatible value for specific panel model
because simple-panel alone cannot provide width/height of the panel.
One other thing: how does the bridge know which mode to drive? I suspect
that it can drive more than one mode? Can it freely be configured or
does it have a predefined set of modes? If the latter, then according to
what you said above there needs to be a way to configure the bridge (via
DT?) so that it reports the mode matching the panel. I wonder if that
should be handled completely in code, so that for example a bridge has a
panel attached it can use the panel's .get_modes() and select a matching
mode among the set that it supports.
ptn3460 supports a standard list of edid-emulation ids.
As of now, we receive that as a DT entry.
And, these are the list of emulation ids supported:
| Value | Resolution | Description
| 0 | 1024x768 | NXP Generic
| 1 | 1920x1080 | NXP Generic
| 2 | 1920x1080 | NXP Generic
| 3 | 1600x900 | Samsung LTM200KT
| 4 | 1920x1080 | Samsung LTM230HT
| 5 | 1366x768 | NXP Generic
| 6 | 1600x900 | ChiMei M215HGE
As you can see, the same resolutions have different emulator ids.
May be, it depends on panel vendor also. I am really not sure if we can do this.
For snow(which has 1366x768 panel), we set edid-emulation as 5.
Ajay
--
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 V6 1/8] drm/panel: Add prepare, unprepare and get_modes routines
On Wed, Jul 30, 2014 at 3:30 PM, Thierry Reding thierry.red...@gmail.com wrote: On Sat, Jul 26, 2014 at 12:52:03AM +0530, Ajay Kumar wrote: Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BACKLIGHT_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BACKLIGHT_EN -- stop video data -- poweroff LCD unit/LCD_EN With existing callbacks for drm panel, we cannot accomodate such panels, since only two callbacks, i.e panel_enable and panel_disable are supported. This patch adds: -- prepare callback which can be called before the actual video data is on, and then call the enable callback after the video data is available. -- unprepare callback which can be called after the video data is off, and use disable callback to do something before switching off the video data. Now, we can easily map the above scenario as shown below: poweron LCD unit/LCD_EN = prepare callback poweron LED unit/BACKLIGHT_EN = enable callback poweroff LED unit/BACKLIGHT_EN = disable callback poweroff LCD unit/LCD_EN = unprepare callback Also, a helper function for get_modes is added. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- include/drm/drm_panel.h | 26 ++ 1 file changed, 26 insertions(+) I had already decided to apply an earlier version that you posted (I think the only difference was that it didn't have the inline implementation for drm_panel_get_modes() yet), reworded the commit message a little (to be less specific about LED, LCD and backlight units) and added some kerneldoc for struct drm_panel_funcs. What I propose is to merge that patch (I'll hopefully push it today so that it shows up in tomorrow's linux-next) and then apply a separate patch to add drm_panel_get_modes(). Do you have any objections to that? I am okay with that. drm_panel_get_modes() will come as a separate patch. Ajay -- 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 V6 2/8] drm/panel: Add support for prepare and unprepare routines
On Sat, Jul 26, 2014 at 12:52:04AM +0530, Ajay Kumar wrote:
Now that we have 2 new callbacks(prepare and unprepare) for drm_panel,
make changes in all the drm drivers which use the drm_panel framework
to support the new callbacks.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 +++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c |7 +
drivers/gpu/drm/panel/panel-ld9040.c| 18 +--
drivers/gpu/drm/panel/panel-s6e8aa0.c | 18 +--
drivers/gpu/drm/panel/panel-simple.c| 51
---
drivers/gpu/drm/tegra/output.c |2 ++
6 files changed, 85 insertions(+), 19 deletions(-)
I'd prefer for this to be split up into patches per panel and per
display driver. The reason is that if this patch is merged as-is, then
if it's ever determined to cause a regression it'll be difficult to find
out which change exactly caused this.
But to not break bisectability you'll need to be careful in how you
break up the patches. I think the following should work:
- for each panel driver, implement dummy .prepare() and
.unprepare() that return 0
- for each display driver, make use of drm_panel_prepare() and
drm_panel_unprepare()
- for each panel driver, properly implement .prepare() and
.unprepare() (presumably by moving code out of .enable() and
.disable(), respectively)
I have a couple more comments below about the ordering of the .prepare()
vs. .enable() and .disable() vs. .unprepare() calls.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..2f58e45 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1333,6 +1333,12 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
if (ret 0)
return ret;
+ ret = drm_panel_prepare(dsi-panel);
+ if (ret 0) {
+ exynos_dsi_poweroff(dsi);
+ return ret;
+ }
+
ret = drm_panel_enable(dsi-panel);
if (ret 0) {
exynos_dsi_poweroff(dsi);
@@ -1354,6 +1360,7 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
exynos_dsi_set_display_enable(dsi, false);
drm_panel_disable(dsi-panel);
+ drm_panel_unprepare(dsi-panel);
exynos_dsi_poweroff(dsi);
I don't know Exynos very well, so this may be completely wrong, but
should disable_panel_prepare() be called much earlier than
drm_panel_enable() and drm_panel_unprepare() much later than
drm_panel_disable()? With the above the result is still the same, so
you'll get the same glitches as without their separation.
Without knowing exactly what Exynos does in the above, I'd expect the
correct sequence to be something like this:
ret = exynos_dsi_power_on(dsi);
if (ret 0)
return ret;
ret = drm_panel_prepare(dsi-panel);
if (ret 0) {
exynos_dsi_poweroff(dsi);
return ret;
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
ret = drm_panel_enable(dsi-panel);
if (ret 0) {
/* perhaps undo exynos_dsi_set_display_enable() here? */
exynos_dsi_poweroff(dsi);
return ret;
}
And for disable:
drm_panel_disable(dsi-panel);
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi-panel);
exynos_dsi_poweroff(dsi);
Perhaps I should quote the kerneldoc that I added for drm_panel_funcs to
underline why I think this is important:
/**
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
* return the number of modes added
*
* The .prepare() function is typically called before the display controller
* starts to transmit video data. Panel drivers can use this to turn the panel
* on and wait for it to become ready. If additional configuration is required
* (via a control bus such as I2C, SPI or DSI for example) this is a good time
* to do that.
*
* After the display controller has started transmitting video data, it's safe
* to call the .enable() function. This will typically enable the backlight to
* make the image on screen visible. Some panels require a certain amount of
* time or frames before the image is displayed. This function is responsible
* for taking this into account before enabling the backlight to avoid visual
* glitches.
*
* Before stopping video transmission from the display controller it can be
* necessary to turn off the panel to avoid visual glitches. This is done in
* the .disable() function.
Re: [RFC 3/5] regulator: core: Only apply constraints if available on list voltage
On Wed, Jul 30, 2014 at 10:49:25AM +0200, Javier Martinez Canillas wrote: On 07/29/2014 07:18 PM, Mark Brown wrote: I would also expect any regulator where the supplied devices are able to vary the voltage to explicitly provide a constraint even if the implementation is done in a parent regulator. There may be constraints on the child supply which aren't directly present on the parent supply and can be ignored if the child supply is turned off. Agreed, if I explicitly set the voltage constraints on the child supply then this patch is indeed not needed. We will, however, need some code to pass the child supply constraints on to the parent. signature.asc Description: Digital signature
Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
Add panel_desc structure for auo_b133htn01 eDP panel.
Also, modify the panel_simple routines to support timing_parameter
delays if mentioned in the panel_desc structure.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/auo,b133htn01.txt|7 +++
drivers/gpu/drm/panel/panel-simple.c | 47
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
I think this should be two patches, one which adds the delay parameters
and another which adds support for the new panel.
diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
new file mode 100644
index 000..302226b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 13.3 FHD (1920x1080) color TFT-LCD panel
+
+Required properties:
+- compatible: should be auo,b133htn01
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index fb0cfe2..cbbb1b8 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -41,6 +41,13 @@ struct panel_desc {
unsigned int width;
unsigned int height;
} size;
+
+ struct {
+ unsigned int prepare_stage_delay;
+ unsigned int enable_stage_delay;
+ unsigned int disable_stage_delay;
+ unsigned int unprepare_stage_delay;
+ } timing_parameter;
These are overly long in my opinion, how about:
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
? Oh, and this should probably mention that it's in milliseconds. On
that note, do you think we'll ever need microsecond resolution? I don't
think I've ever seen a panel datasheet mentioning that kind of
granularity.
struct panel_simple {
@@ -105,6 +112,8 @@ static int panel_simple_unprepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p-enable_gpio, 0);
regulator_disable(p-supply);
+ if (p-desc)
Should have a blank line between regulator_disable(...) and if
Also it's not useful to check for p-desc, really, since it's a bug if
that is NULL.
However I think it would be good to check for the delay being set, like
so:
if (p-desc-delay.unprepare)
msleep(p-desc-delay.unprepare);
I'm not sure about the placement of the delay here, see below for more.
@@ -142,6 +154,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
return err;
}
+ if (p-desc)
+ msleep(p-desc-timing_parameter.prepare_stage_delay);
+
if (p-enable_gpio)
gpiod_set_value_cansleep(p-enable_gpio, 1);
Should the delay not be *after* all steps in prepare have been
performed? That way drivers can use it to specify the time that a panel
needs to internally become ready after they've been power up (for
example).
@@ -157,6 +172,8 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p-backlight_enabled)
return 0;
+ if (p-desc)
+ msleep(p-desc-timing_parameter.enable_stage_delay);
if (p-backlight) {
p-backlight-props.power = FB_BLANK_UNBLANK;
backlight_update_status(p-backlight);
I think here the delay makes sense where it is because it allows the
panel driver to wait for a given amount of time (after video data has
been sent by the display controller) until the first good frame is
visible.
In general I think it would be good to have a description of these in
the struct panel_desc structure, something like this perhaps:
/**
* @prepare: the time (in milliseconds) that it takes for the panel
* to become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel
* to display the first valid frame after starting to
* receive video data
* @disable: the time (in milliseconds) that it takes for the panel
* to turn the display off (no content is visible)
* @unprepare: ???
*/
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
For prepare and enable delays this would mean that they should take
effect at the very end of the .prepare() and .enable() functions,
respectively. For disable in means that it should be at the end (for
Re: [PATCH V6 4/8] drm/exynos: Move DP setup into commit()
On Sat, Jul 26, 2014 at 12:52:06AM +0530, Ajay Kumar wrote: This patch moves the DP training and video enable from the hotplug handler into commit(). I don't think I can comment on this one, but perhaps the commit message should describe why it's doing this rather than just parroting what the code does. Thierry pgp53ZMDR0kJW.pgp Description: PGP signature
Re: [PATCH V6 5/8] drm/exynos: dp: Modify driver to support drm_panel
On Sat, Jul 26, 2014 at 12:52:07AM +0530, Ajay Kumar wrote:
[...]
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
@@ -887,6 +885,12 @@ static void exynos_dp_commit(struct exynos_drm_display
*display)
struct exynos_dp_device *dp = display-ctx;
int ret;
+ /* Keep backlight disabled while we configure video */
+ if (dp-panel) {
+ if (drm_panel_disable(dp-panel))
+ DRM_ERROR(failed to disable panel backlight\n);
+ }
drm_panel_disable() already gracefully handles the dp-panel == NULL
case, so no need to check for it explicitly. But perhaps you do that
only because panel support is optional and you want to avoid the
error message if it isn't set up. In that case it's probably fine to
leave this as-is.
But you should change the comment and error message, since you don't
know what exactly drm_panel_disable() does.
And it might be useful to print the error code while at it, it might
help save some debugging time in the future.
The same comments apply to most of the remainder of the file, but it
looks good to me otherwise.
Thierry
pgp1OYPd1FI1l.pgp
Description: PGP signature
[PATCHv8 2/5] ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++--
arch/arm/boot/dts/exynos4412-origen.dts |8 ++--
arch/arm/boot/dts/exynos4412-trats2.dts |8 ++--
arch/arm/boot/dts/exynos5250-arndale.dts | 18 +
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 +++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 +
arch/arm/boot/dts/exynos5250-snow.dts |6 ++
arch/arm/boot/dts/exynos5260-xyref5260.dts| 18 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 +
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 ---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 16 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 ---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 ---
13 files changed, 51 insertions(+), 141 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..778aec6 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -45,17 +45,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
regulator_p3v3 {
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e925c9f..de15114 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -137,17 +137,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
codec@1340 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 7787844..65ab885 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -520,7 +520,6 @@
mmc@1255 {
num-slots = 1;
- supports-highspeed;
broken-cd;
non-removable;
card-detect-delay = 200;
@@ -532,11 +531,8 @@
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
status = okay;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
serial@1380 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..42a3590 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -401,7 +401,6 @@
mmc_0: mmc@1220 {
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -410,17 +409,13 @@
vmmc-supply = mmc_reg;
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
mmc_2: mmc@1222 {
status = okay;
num-slots = 1;
- supports-highspeed;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -428,12
[PATCHv8 3/5] ARM: dts: socfpga: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Dinh Nguyen dingu...@altera.com
---
arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_cyclone5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_vt.dts|9 +++--
3 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi
b/arch/arm/boot/dts/socfpga_arria5.dtsi
index 12d1c2c..468fc4c 100644
--- a/arch/arm/boot/dts/socfpga_arria5.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
@@ -29,13 +29,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
sysmgr@ffd08000 {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index bf51182..1ee03c4 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -30,13 +30,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff702000 {
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 09792b4..f9345e0 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -43,13 +43,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff70 {
--
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
[PATCHv8 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Replaced the disable-wp into host's quirks.
(Because the slot-node is removed at dt-file.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/host/dw_mmc.c |8 +++-
include/linux/mmc/dw_mmc.h |2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..8d9edc6 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -997,7 +997,10 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
int gpio_ro = mmc_gpio_get_ro(mmc);
/* Use platform get_ro function, else try on board write protect */
- if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+ if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) {
+ dev_warn(slot-host-dev, Recommend not to use 'disable-wp'
+ into slot-node. Change your dt-file!!);
+ } else if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)
read_only = 0;
else if (!IS_ERR_VALUE(gpio_ro))
read_only = gpio_ro;
@@ -2238,6 +2241,9 @@ static struct dw_mci_of_quirks {
{
.quirk = broken-cd,
.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
+ }, {
+ .quirk = disable-wp,
+ .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
},
};
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index babaea9..29ce014 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -213,6 +213,8 @@ struct dw_mci_dma_ops {
#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
/* Unreliable card detection */
#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
+/* No write protect */
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT BIT(4)
/* Slot level quirks */
/* This slot has no write protect */
--
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
[PATCHv8 4/5] ARM: dts: rockchip: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Reviewed-by: Heiko Stuebner he...@sntech.de
Acked-by: Seungwon Jeon tgih@samsung.com
---
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index afb3273..ecea889 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -59,12 +59,8 @@
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_cd sd0_bus4;
vmmc-supply = vcc_sd0;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
dwmmc@10218000 { /* wifi */
@@ -74,12 +70,8 @@
pinctrl-names = default;
pinctrl-0 = sd1_clk sd1_cmd sd1_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
gpio-keys {
--
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
[PATCHv8 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.
Since used the mmc_of_parse(), didn't parse the sub-node. So we can remove the sub-node, because almost SoC used the only one card per a host. And supports-highspeed can be replaced to cap-mmc/sd-highspeed property. Changelog V8: - Add the warning message to notice that slot-node was removed. (As Doug's suggestion) Changelog V7: - Fixed typo and modified the commit message. Changelog V6: - Fixed Wrong bit control for host's quirks and rename. - Add Acked-by for each SoC maintainers. Changelog V5: - Rebased on v3.16-rc4. - Add Acked-by. Changelog V4: - Fix the checkpatch error. Changelog V3: - Fix the wrong bus-width value. - Use the slot-host-quirks instead of brq-quirks. - Add tested-by and reviewd-by. Changelog V2: - Add the mmc: dw_mmc: replace disable-wp from slot's quirks to host's quirk Jaehoon Chung (5): mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc ARM: dts: socfpga: unuse the slot-node and deprecated the supports-highspeed for dw-mmc ARM: dts: rockchip: unuse the slot-node and deprecated the supports-highspeed for dw-mmc mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 - .../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 - .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 - arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++ arch/arm/boot/dts/exynos4412-origen.dts|8 ++ arch/arm/boot/dts/exynos4412-trats2.dts|8 ++ arch/arm/boot/dts/exynos5250-arndale.dts | 18 -- arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 -- arch/arm/boot/dts/exynos5250-snow.dts |6 ++--- arch/arm/boot/dts/exynos5260-xyref5260.dts | 18 -- arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 -- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 +++- arch/arm/boot/dts/exynos5420-peach-pit.dts | 16 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 +++- arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 +++- arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16 +++- arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++ arch/arm/boot/dts/socfpga_cyclone5.dtsi|9 +++ arch/arm/boot/dts/socfpga_vt.dts |9 +++ drivers/mmc/host/dw_mmc.c |8 +- include/linux/mmc/dw_mmc.h |2 ++ 22 files changed, 88 insertions(+), 198 deletions(-) -- 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
[PATCHv8 1/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
Almost SoCs use one slot per host controller.
(Even if controller can support the multiple slot, Recommend to use one slot
per host controller.)
Don't use the slot-node and deprecate the supports-highspeed property.
Instead, use the cap-mmc/sd-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
.../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 +
.../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 +---
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 +---
3 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 532b1d4..6cd3525 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -46,13 +46,14 @@ Required Properties:
- if CIU clock divider value is 0 (that is divide by 1), both tx and rx
phase shift clocks should be 0.
-Required properties for a slot:
+Required properties for a slot (Deprecated - Recommend to use one slot per
host):
* gpios: specifies a list of gpios used for command, clock and data bus. The
first gpio is the command line and the second gpio is the clock line. The
rest of the gpios (depending on the bus-width property) are the data lines in
no particular order. The format of the gpio specifier depends on the gpio
controller.
+(Deprecated - Refer to
Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)
Example:
@@ -69,21 +70,13 @@ Example:
dwmmc0@1220 {
num-slots = 1;
- supports-highspeed;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
- gpc1 0 2 3 3, gpc1 1 2 3 3,
- gpc1 2 2 3 3, gpc1 3 2 3 3,
- gpc0 3 2 3 3, gpc0 4 2 3 3,
- gpc0 5 2 3 3, gpc0 6 2 3 3;
- };
+ bus-width = 8;
};
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index e5bc49f..3b35449 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -34,13 +34,11 @@ Example:
num-slots = 1;
vmmc-supply = ldo12;
fifo-depth = 0x100;
- supports-highspeed;
pinctrl-names = default;
pinctrl-0 = sd_pmx_pins sd_cfg_func1 sd_cfg_func2;
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- cd-gpios = gpio10 3 0;
- };
+ bus-width = 4;
+ disable-wp;
+ cd-gpios = gpio10 3 0;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 2d4a725..346c609 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -67,7 +67,8 @@ Optional properties:
* card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.
-* supports-highspeed: Enables support for high speed cards (up to 50MHz)
+* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to
50MHz)
+ (use cap-mmc-highspeed or cap-sd-highspeed
instead)
* broken-cd: as documented in mmc core bindings.
@@ -98,14 +99,11 @@ board specific portions as listed below.
clock-frequency = 4;
clock-freq-min-max = 40 2;
num-slots = 1;
- supports-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
vmmc-supply = buck8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
--
1.7.9.5
--
To unsubscribe from this list: send
Re: [PATCH V6 2/8] drm/panel: Add support for prepare and unprepare routines
On Wed, Jul 30, 2014 at 4:02 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:04AM +0530, Ajay Kumar wrote:
Now that we have 2 new callbacks(prepare and unprepare) for drm_panel,
make changes in all the drm drivers which use the drm_panel framework
to support the new callbacks.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 +++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c |7 +
drivers/gpu/drm/panel/panel-ld9040.c| 18 +--
drivers/gpu/drm/panel/panel-s6e8aa0.c | 18 +--
drivers/gpu/drm/panel/panel-simple.c| 51
---
drivers/gpu/drm/tegra/output.c |2 ++
6 files changed, 85 insertions(+), 19 deletions(-)
I'd prefer for this to be split up into patches per panel and per
display driver. The reason is that if this patch is merged as-is, then
if it's ever determined to cause a regression it'll be difficult to find
out which change exactly caused this.
But to not break bisectability you'll need to be careful in how you
break up the patches. I think the following should work:
- for each panel driver, implement dummy .prepare() and
.unprepare() that return 0
- for each display driver, make use of drm_panel_prepare() and
drm_panel_unprepare()
- for each panel driver, properly implement .prepare() and
.unprepare() (presumably by moving code out of .enable() and
.disable(), respectively)
I will try this. With this approach, compilation should not fail.
I have a couple more comments below about the ordering of the .prepare()
vs. .enable() and .disable() vs. .unprepare() calls.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..2f58e45 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1333,6 +1333,12 @@ static int exynos_dsi_enable(struct exynos_dsi *dsi)
if (ret 0)
return ret;
+ ret = drm_panel_prepare(dsi-panel);
+ if (ret 0) {
+ exynos_dsi_poweroff(dsi);
+ return ret;
+ }
+
ret = drm_panel_enable(dsi-panel);
if (ret 0) {
exynos_dsi_poweroff(dsi);
@@ -1354,6 +1360,7 @@ static void exynos_dsi_disable(struct exynos_dsi *dsi)
exynos_dsi_set_display_enable(dsi, false);
drm_panel_disable(dsi-panel);
+ drm_panel_unprepare(dsi-panel);
exynos_dsi_poweroff(dsi);
I don't know Exynos very well, so this may be completely wrong, but
should disable_panel_prepare() be called much earlier than
drm_panel_enable() and drm_panel_unprepare() much later than
drm_panel_disable()? With the above the result is still the same, so
you'll get the same glitches as without their separation.
Actually, I have not worked on DSI panels.
And till now, these DSI panels have been working with just the
enable/disable callback. So, I thought it might not really cause a
glitch/garbage on the screen.
I just placed the new panel calls so that basic working will not be broken.
It would be great if someone can test this on exynos boards with DSI panels :(
Inki/Andrej?
Anyways, now there is a kerneldoc which explains all these calls,
I will rearrange the panel calls.
Without knowing exactly what Exynos does in the above, I'd expect the
correct sequence to be something like this:
ret = exynos_dsi_power_on(dsi);
if (ret 0)
return ret;
ret = drm_panel_prepare(dsi-panel);
if (ret 0) {
exynos_dsi_poweroff(dsi);
return ret;
}
exynos_dsi_set_display_mode(dsi);
exynos_dsi_set_display_enable(dsi, true);
ret = drm_panel_enable(dsi-panel);
if (ret 0) {
/* perhaps undo exynos_dsi_set_display_enable() here? */
exynos_dsi_poweroff(dsi);
return ret;
}
And for disable:
drm_panel_disable(dsi-panel);
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi-panel);
exynos_dsi_poweroff(dsi);
Perhaps I should quote the kerneldoc that I added for drm_panel_funcs to
underline why I think this is important:
/**
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
* return the number of modes added
*
* The .prepare() function is typically called before the display controller
* starts to transmit video data. Panel drivers can use this to turn the panel
* on and wait for it to become ready. If additional configuration is required
* (via a
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
This patch tries to seperate drm_bridge implementation
into 2 parts, a drm part and a non_drm part.
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling drm_bridge_add_for_lookup.
The parent encoder driver waits till the bridge is available in the
lookup table(by calling of_drm_find_bridge) and then continues with
its initialization.
The encoder driver should call drm_bridge_attach_encoder to pass on
the drm_device and the encoder pointers to the bridge object.
Now that the drm_device pointer is available, the encoder then calls
bridge-funcs-post_encoder_init to allow the bridge to continue
registering itself with the drm core.
Also, non driver model based ptn3460 driver is removed in this patch.
Why is it removed in this patch? Can't you do this incrementally rather
than remove the driver in this patch and add it again later? If you do
it this way then we'll always have this one commit where devices that
have a ptn3460 don't work, so it becomes impossible to bisect across
this commit.
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
[...]
+int drm_bridge_add_for_lookup(struct drm_bridge *bridge)
+{
+ mutex_lock(bridge_lock);
+ list_add_tail(bridge-head, bridge_lookup);
+ mutex_unlock(bridge_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_bridge_add_for_lookup);
+
+void drm_bridge_remove_from_lookup(struct drm_bridge *bridge)
+{
+ mutex_lock(bridge_lock);
+ list_del_init(bridge-head);
+ mutex_unlock(bridge_lock);
+}
+EXPORT_SYMBOL(drm_bridge_remove_from_lookup);
The _for_lookup and _from_lookup suffixes aren't useful in my
opinion.
+int drm_bridge_attach_encoder(struct drm_bridge *bridge,
+ struct drm_encoder *encoder)
And this could simply be drm_bridge_attach() since we'll only ever
want to attach it to encoders.
+{
+ if (!bridge || !encoder)
+ return -EINVAL;
+
+ if (bridge-encoder)
+ return -EBUSY;
+
+ encoder-bridge = bridge;
+ bridge-encoder = encoder;
+ bridge-drm_dev = encoder-dev;
Should this function perhaps call the bridge's -post_encoder_init()?
And it should probably call drm_bridge_init() too, since the DRM device
is now available.
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
Maybe since you're introducing a new drm_bridge.c file above already it
would make sense to move out existing drm_bridge related code in a
preparatory patch?
Maybe Sean or Rob can comment on whether there was a specific reason to
include it in drm_crtc.c in the first place.
@@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct
drm_bridge *bridge,
if (ret)
goto out;
- bridge-dev = dev;
- bridge-funcs = funcs;
+ bridge-drm_dev = dev;
This sets -drm_dev, but it was already set in drm_bridge_attach(), so I
think that's one more argument to call this function when attaching.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
@@ -1370,7 +1361,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
- struct device_node *panel_node;
+ struct device_node *panel_node, *bridge_node;
Nit: I don't think you'll need two variables here, since once you've
obtained the real panel or bridge objects you no longer need the OF
nodes.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e529b68..e5a41ad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -619,6 +619,7 @@ struct drm_plane {
/**
* drm_bridge_funcs - drm_bridge control functions
+ * @post_encoder_init: called by the parent encoder
Maybe rename this to attach to make it more obvious when exactly it's
called?
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this
bridge
* @disable: Called right before encoder prepare, disables the bridge
* @post_disable: Called right after encoder prepare, for lockstepped disable
@@ -628,6 +629,7 @@ struct drm_plane {
* @destroy: make object go away
*/
struct drm_bridge_funcs {
+ int (*post_encoder_init)(struct drm_bridge *bridge);
bool (*mode_fixup)(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
@@ -648,15 +650,19 @@ struct drm_bridge_funcs {
* @base: base mode object
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
+ * @connector_polled: polled flag needed for registering connector
Can you explain why this new field is needed? It seems like a
Re: [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Am 30.07.2014 10:07, schrieb Thomas Abraham:
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific cpufreq driver
to using generic cpufreq drivers.
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
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/boot/dts/exynos4210-origen.dts |4 +++
arch/arm/boot/dts/exynos4210-trats.dts |4 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts |4 +++
arch/arm/boot/dts/exynos4210.dtsi | 14 -
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.dtsi | 25 ++-
arch/arm/boot/dts/exynos5420.dtsi | 38
+++
9 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index f767c42..887dded 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -334,3 +334,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = buck1_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..66119dd 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -446,3 +446,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = varm_breg;
+};
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3a..bf0a39c 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -492,3 +492,7 @@
mdma1 {
reg = 0x1284 0x1000;
};
+
+cpu0 {
+ cpu0-supply = vdd_arm_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63..69bac07 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,10 +35,22 @@
#address-cells = 1;
#size-cells = 0;
- cpu@900 {
+ cpu0: cpu@900 {
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0x900;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 16;
+
+ operating-points =
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
Nit: Here you left-align the columns ...
+ ;
};
cpu@901 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
+
+ operating-points =
+
Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
Add panel_desc structure for auo_b133htn01 eDP panel.
Also, modify the panel_simple routines to support timing_parameter
delays if mentioned in the panel_desc structure.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/auo,b133htn01.txt|7 +++
drivers/gpu/drm/panel/panel-simple.c | 47
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt
I think this should be two patches, one which adds the delay parameters
and another which adds support for the new panel.
Ok. Will split it.
diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
new file mode 100644
index 000..302226b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 13.3 FHD (1920x1080) color TFT-LCD panel
+
+Required properties:
+- compatible: should be auo,b133htn01
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index fb0cfe2..cbbb1b8 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -41,6 +41,13 @@ struct panel_desc {
unsigned int width;
unsigned int height;
} size;
+
+ struct {
+ unsigned int prepare_stage_delay;
+ unsigned int enable_stage_delay;
+ unsigned int disable_stage_delay;
+ unsigned int unprepare_stage_delay;
+ } timing_parameter;
These are overly long in my opinion, how about:
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
Ok, will use this.
? Oh, and this should probably mention that it's in milliseconds. On
that note, do you think we'll ever need microsecond resolution? I don't
think I've ever seen a panel datasheet mentioning that kind of
granularity.
Nope. All in milliseconds.
struct panel_simple {
@@ -105,6 +112,8 @@ static int panel_simple_unprepare(struct drm_panel
*panel)
gpiod_set_value_cansleep(p-enable_gpio, 0);
regulator_disable(p-supply);
+ if (p-desc)
Should have a blank line between regulator_disable(...) and if
Also it's not useful to check for p-desc, really, since it's a bug if
that is NULL.
Well, I added this check because I used just the simple-panel compatible
for panel node on snow. This check won't be needed anymore.
However I think it would be good to check for the delay being set, like
so:
if (p-desc-delay.unprepare)
msleep(p-desc-delay.unprepare);
Ok, will change it.
I'm not sure about the placement of the delay here, see below for more.
@@ -142,6 +154,9 @@ static int panel_simple_prepare(struct drm_panel *panel)
return err;
}
+ if (p-desc)
+ msleep(p-desc-timing_parameter.prepare_stage_delay);
+
if (p-enable_gpio)
gpiod_set_value_cansleep(p-enable_gpio, 1);
Should the delay not be *after* all steps in prepare have been
performed? That way drivers can use it to specify the time that a panel
needs to internally become ready after they've been power up (for
example).
Right. I will move that delay down.
@@ -157,6 +172,8 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p-backlight_enabled)
return 0;
+ if (p-desc)
+ msleep(p-desc-timing_parameter.enable_stage_delay);
if (p-backlight) {
p-backlight-props.power = FB_BLANK_UNBLANK;
backlight_update_status(p-backlight);
I think here the delay makes sense where it is because it allows the
panel driver to wait for a given amount of time (after video data has
been sent by the display controller) until the first good frame is
visible.
Exactly!
In general I think it would be good to have a description of these in
the struct panel_desc structure, something like this perhaps:
/**
* @prepare: the time (in milliseconds) that it takes for the panel
* to become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel
* to display the first valid frame after starting to
* receive video data
* @disable: the time (in milliseconds) that it takes for the panel
* to turn the display off (no content is visible)
* @unprepare: the time (in milliseconds) that it
Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1e2f96c..0b12d16 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,4 +6,14 @@ config DRM_BRIDGE
menu bridge chips
depends on DRM_BRIDGE
+
+config DRM_PTN3460
+ tristate NXP ptn3460 eDP/LVDS bridge
+ depends on DRM DRM_BRIDGE
I don't think you need these two dependencies any longer since they are
implicit in the bridge chips menu.
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
[...]
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+#include drm/drm_panel.h
These should be ordered alphabetically, but they are already this way in
the original driver, so the reordering can be a separate patch.
+struct ptn3460_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge *bridge;
I think it would be much more natural for ptn3460_bridge to embed struct
drm_bridge rather than store a pointer to it.
+ struct drm_panel *panel;
+ struct edid *edid;
+ struct gpio_desc *gpio_pd_n;
+ struct gpio_desc *gpio_rst_n;
+ u32 edid_emulation;
+ bool enabled;
+};
+
+static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
+ u8 *buf, int len)
+{
+ int ret;
+
+ ret = i2c_master_send(ptn_bridge-client, addr, 1);
+ if (ret = 0) {
+ DRM_ERROR(Failed to send i2c command, ret=%d\n, ret);
+ return ret;
+ }
+
+ ret = i2c_master_recv(ptn_bridge-client, buf, len);
+ if (ret = 0) {
+ DRM_ERROR(Failed to recv i2c data, ret=%d\n, ret);
+ return ret;
+ }
This isn't introduced by this patch, but doesn't this require locking so
that this is an atomic transaction?
Perhaps it could be rewritten using i2c_smbus_read_block_data()?
+static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
+ char val)
+{
+ int ret;
+ char buf[2];
+
+ buf[0] = addr;
+ buf[1] = val;
+
+ ret = i2c_master_send(ptn_bridge-client, buf, ARRAY_SIZE(buf));
+ if (ret = 0) {
+ DRM_ERROR(Failed to send i2c command, ret=%d\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
Same here, this looks like it could be i2c_smbus_write_byte_data().
+static int ptn3460_select_edid(struct ptn3460_bridge *ptn_bridge)
+{
+ int ret;
+ char val;
+
+ /* Load the selected edid into SRAM (accessed at PTN3460_EDID_ADDR) */
+ ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
+ ptn_bridge-edid_emulation);
+ if (ret) {
+ DRM_ERROR(Failed to transfer edid to sram, ret=%d\n, ret);
+ return ret;
+ }
+
+ /* Enable EDID emulation and select the desired EDID */
+ val = 1 PTN3460_EDID_ENABLE_EMULATION |
+ ptn_bridge-edid_emulation PTN3460_EDID_EMULATION_SELECTION;
+
+ ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
+ if (ret) {
+ DRM_ERROR(Failed to write edid value, ret=%d\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
s/edid/EDID/ in the above (and below, too), but again the original
driver had this, so it can be a separate patch.
+static void ptn3460_pre_enable(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
If you embed drm_bridge within ptn3460_bridge then you can use the much
more canonical container_of() macro (or rather a driver-specific inline
function that wraps it) and no longer need the drm_bridge.driver_private
field.
+ int ret;
+
+ if (ptn_bridge-enabled)
+ return;
+
+ gpiod_set_value(ptn_bridge-gpio_pd_n, 1);
+
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 0);
+ udelay(10);
This shouldn't be using udelay(), usleep_range(10, 20) (or similar)
would be better. Again, can be a separate patch.
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 1);
It also seems like you've converted to using the gpiod_*() API, but the
driver previously used gpio_is_valid() to check that both PD and RST
pins had valid GPIOs associated with them. The device tree binding said
that they are required, though.
So this patch actually does the right thing by making them non-optional
but it also changes behaviour from the original. Like I said earlier, I
would very much prefer that this conversion be split into separate
patches rather than one patch that removes the old driver and a second
patch that adds a new one. It makes it really difficult to tell what's
really changing, breaks bisectability and generally makes our lives
miserable.
+
+ drm_panel_prepare(ptn_bridge-panel);
This should
Re: [PATCH V6 4/8] drm/exynos: Move DP setup into commit()
On Wed, Jul 30, 2014 at 4:22 PM, Thierry Reding thierry.red...@gmail.com wrote: On Sat, Jul 26, 2014 at 12:52:06AM +0530, Ajay Kumar wrote: This patch moves the DP training and video enable from the hotplug handler into commit(). I don't think I can comment on this one, but perhaps the commit message should describe why it's doing this rather than just parroting what the code does. Actually, this patch adds the missing commit callback for dp encoder. I will add proper commit message. Ajay -- 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] media: v4l2: make allocation algorithm more robust and flexible
Hi Zhaowei, On Wed, Jul 30, 2014 at 9:39 AM, Zhaowei Yuan zhaowei.y...@samsung.com wrote: Current algorithm relies on the fact that caller will align the size to PAGE_SIZE, otherwise order will be decreased to negative when remain size is less than PAGE_SIZE, it makes the function hard to be migrated. This patch sloves the hidden problem. Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index adefc31..40d18aa 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf, order = get_order(size); /* Dont over allocate*/ - if ((PAGE_SIZE order) size) + if (order 0 (PAGE_SIZE order) size) order--; If size is not page aligned, then wouldn't decrementing the order under-allocate the memory? -- Regards, Sachin. -- 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: [PATCHv7 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.
Am 28.07.2014 04:29, schrieb Jaehoon Chung: Since used the mmc_of_parse(), didn't parse the sub-node. So we can remove the sub-node, because almost SoC used the only one card per a host. And supports-highspeed can be replaced to cap-mmc/sd-highspeed property. Chnagelog V7: - Fixed typo and modified the commit message. Changelog V6: - Fixed Wrong bit control for host's quirks and rename. - Add Acked-by for each SoC maintainers. Changelog V5: - Rebased on v3.16-rc4. - Add Acked-by. Changelog V4: - Fix the checkpatch error. Changelog V3: - Fix the wrong bus-width value. - Use the slot-host-quirks instead of brq-quirks. - Add tested-by and reviewd-by. Changelog V2: - Add the mmc: dw_mmc: replace disable-wp from slot's quirks to host's quirk Jaehoon Chung (5): mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc ARM: dts: socfpga: unuse the slot-node and deprecated the supports-highspeed for dw-mmc ARM: dts: rockchip: unuse the slot-node and deprecated the supports-highspeed for dw-mmc Nit: 3x s/deprecated/deprecate/g to align tenses? (Sorry, I got interrupted during previous review pass.) Regards, Andreas mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 - .../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 - .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 - arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++ arch/arm/boot/dts/exynos4412-origen.dts|8 ++ arch/arm/boot/dts/exynos4412-trats2.dts|8 ++ arch/arm/boot/dts/exynos5250-arndale.dts | 18 -- arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 -- arch/arm/boot/dts/exynos5250-snow.dts |6 ++--- arch/arm/boot/dts/exynos5260-xyref5260.dts | 18 -- arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 -- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 +++- arch/arm/boot/dts/exynos5420-peach-pit.dts | 16 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 +++- arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 +++- arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16 +++- arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++ arch/arm/boot/dts/socfpga_cyclone5.dtsi|9 +++ arch/arm/boot/dts/socfpga_vt.dts |9 +++ drivers/mmc/host/dw_mmc.c | 12 - include/linux/mmc/dw_mmc.h |6 ++--- 22 files changed, 86 insertions(+), 208 deletions(-) -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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: [PATCHv7 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Am 28.07.2014 04:29, schrieb Jaehoon Chung: Replaced the disable-wp into host's quirks. Replace is wrong here and in $subject. Relocate? Move? (Because the slot-node is removed at dt-file.) in dt-file? Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com --- drivers/mmc/host/dw_mmc.c | 12 +--- include/linux/mmc/dw_mmc.h |6 ++ 2 files changed, 7 insertions(+), 11 deletions(-) Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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: [PATCHv7 1/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
Am 28.07.2014 04:29, schrieb Jaehoon Chung: Almost SoCs use one slot per host controller. Still has Almost SoCs - I had suggested to insert all, but I think you mean Most SoCs. (Even if controller can support the multiple slot, Recommend to use one slot per host controller.) Don't use the slot-node and deprecate the supports-highspeed property. Instead, use the cap-mmc/sd-highspeed. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Reviewed-by: Tushar Behera trbli...@gmail.com Reviewed-by: Ulf Hansson ulf.hans...@linaro.org Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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: [PATCHv8 4/5] ARM: dts: rockchip: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
Hi,
Am Mittwoch, 30. Juli 2014, 20:05:09 schrieb Jaehoon Chung:
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Reviewed-by: Heiko Stuebner he...@sntech.de
Acked-by: Seungwon Jeon tgih@samsung.com
we might get a conflict, with recent Rockchip-specific devicetree changes [0].
So depending on when the core changes of this series land, this patch
might use a respin.
Heiko
[0]
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=rockchip/dtid=fcbbf965254ff1693c26a5646e4e62adc3a6118d
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=rockchip/dtid=b09e35a388ad23eb90497a352b8e5e5cb4b97bf2
---
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts index afb3273..ecea889 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -59,12 +59,8 @@
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_cd sd0_bus4;
vmmc-supply = vcc_sd0;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
dwmmc@10218000 { /* wifi */
@@ -74,12 +70,8 @@
pinctrl-names = default;
pinctrl-0 = sd1_clk sd1_cmd sd1_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
gpio-keys {
--
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: [PATCHv7 2/5] ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
Am 28.07.2014 04:29, schrieb Jaehoon Chung:
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced to cap-sd/mmc-highspeed.
s/replaced to/replaced with/
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++--
arch/arm/boot/dts/exynos4412-origen.dts |8 ++--
arch/arm/boot/dts/exynos4412-trats2.dts |8 ++--
arch/arm/boot/dts/exynos5250-arndale.dts | 18 +
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26
+++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 +
arch/arm/boot/dts/exynos5250-snow.dts |6 ++
arch/arm/boot/dts/exynos5260-xyref5260.dts| 18 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 +
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 ---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 16 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 ---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 ---
13 files changed, 51 insertions(+), 141 deletions(-)
[...]
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 89ac90f..af51361 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -248,7 +248,6 @@
mmc@1220 {
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -256,44 +255,33 @@
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_cd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
mmc@1222 {
num-slots = 1;
- supports-highspeed;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- wp-gpios = gpc2 1 0;
- };
+ bus-width = 4;
+ wp-gpios = gpc2 1 0;
+ cap-sd-highspeed;
};
mmc@1223 {
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
/* See board-specific dts files for pin setup */
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-sd-highspeed;
};
spi_1: spi@12d3 {
[...]
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 079fdf9..17d8f53 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -329,10 +329,8 @@
*/
mmc@1223 {
status = okay;
- slot@0 {
- pinctrl-names = default;
- pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
- };
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
};
i2c@12CD {
Since you said you are targeting 3.16 still, FYI Doug asked me to do the
same change for 3.17 in my Spring series for correctness reasons. So we
shouldn't have merge conflict there.
However, we are also dropping exynos5250-cros-common.dtsi, so at some
point the above changes will need to be merged into -snow.dts as
conflict resolution.
[...]
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index 7275bbd..be3e025 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -40,33 +40,25 @@
mmc_0 {
status = okay;
num-slots = 1;
- supports-highspeed;
+ cap-mmc-highspeed;
broken-cd;
Re: [PATCH v2 4/4] ARM: dts: exynos5250: Add Spring device tree
Hi Doug,
Am 25.07.2014 18:02, schrieb Doug Anderson:
Andreas,
On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote:
+ gpio-keys {
+ compatible = gpio-keys;
+
+ power {
+ label = Power;
+ gpios = gpx1 3 1;
+ linux,code = 116; /* KEY_POWER */
+ gpio-key,wakeup;
+ };
Is the lid switch not working?
No, I don't see any reaction at least. I notice that 3.8 has pinctrls on
gpio-keys directly though...
Where is your pinctrl?
Maybe that's what you mean here?
Can you match this in sort order with snow to make diffs easier?
Done.
+ };
+};
+
+i2c_0 {
+ status = okay;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 378000;
+
+ s5m8767_pmic@66 {
+ compatible = samsung,s5m8767-pmic;
+ reg = 0x66;
+ interrupt-parent = gpx3;
+ interrupts = 2 0;
+ pinctrl-names = default;
+ pinctrl-0 = s5m8767_irq s5m8767_dvs s5m8767_ds;
+ wakeup-source;
+
+ s5m8767,pmic-buck-dvs-gpios = gpd1 0 1, /* DVS1 */
+ gpd1 1 1, /* DVS2 */
+ gpd1 2 1; /* DVS3 */
+
+ s5m8767,pmic-buck-ds-gpios = gpx2 3 1, /* SET1 */
+gpx2 4 1, /* SET2 */
+gpx2 5 1; /* SET3 */
+
+ /*
+* The following arrays of DVS voltages are not used, since
we are
+* not using GPIOs to control PMIC bucks, but they must be
defined
+* to please the driver.
+*/
+ s5m8767,pmic-buck2-dvs-voltage = 135, 130,
+125, 120,
+115, 110,
+100, 95;
+
+ s5m8767,pmic-buck3-dvs-voltage = 110, 110,
+110, 110,
+100, 100,
+100, 100;
+
+ s5m8767,pmic-buck4-dvs-voltage = 120, 120,
+120, 120,
+120, 120,
+120, 120;
+
+ clocks {
+ compatible = samsung,s5m8767-clk;
+ #clock-cells = 1;
+ clock-output-names = en32khz_ap,
+en32khz_cp,
+en32khz_bt;
+ };
+
+ regulators {
+ s5m_ldo4_reg: LDO4 {
+ regulator-name = P1.0V_LDO_OUT4;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ op_mode = 0;
+ };
+
+ s5m_ldo5_reg: LDO5 {
+ regulator-name = P1.0V_LDO_OUT5;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ op_mode = 0;
+ };
+
+ s5m_ldo6_reg: LDO6 {
+ regulator-name = vdd_mydp;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ op_mode = 3;
+ };
+
+ s5m_ldo7_reg: LDO7 {
+ regulator-name = P1.1V_LDO_OUT7;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ regulator-always-on;
+ op_mode = 3;
+ };
+
+ s5m_ldo8_reg: LDO8 {
+ regulator-name = P1.0V_LDO_OUT8;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 100;
+ regulator-always-on;
+ op_mode = 3;
+ };
+
+ s5m_ldo10_reg: LDO10 {
+
Re: [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
On Sat, Jul 26, 2014 at 12:52:10AM +0530, Ajay Kumar wrote:
[...]
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..b4a99cc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ nxp NXP Semiconductors
onnn ON Semiconductor Corp.
opencoresOpenCores.org
panasonicPanasonic Corporation
+parade Parade Technologies Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
plathome Plat'Home Co., Ltd.
I think it's a good idea to turn this into a separate patch to avoid
conflicts.
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..fdeafb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,19 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: parade,ps8622 or parade,ps8625
+ - reg: first i2c address of the bridge
I'm not sure what the deal is with devices that use more than one I2C
addresses. It would be good to hear from the device tree maintainers on
how to handle those. Technically each address is a separate device. This
is also mirrored in the Linux kernel's implementation of the I2C bus,
where it looks wrong to access more than a single address (since the
core only marks one of them used). So technically it's valid for
userspace to access any but the first page of this device.
+ - sleep-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
This should explain what these GPIOs are used for.
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+
+Example:
+ ps8622-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1
+ };
Same here. It's usually best to make this a patch separate from the
driver. Not because of conflicts, but because it makes it easier for DT
reviewers to find the relevant pieces to look at.
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 0b12d16..d73e474 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -16,4 +16,14 @@ config DRM_PTN3460
help
ptn3460 eDP-LVDS bridge chip driver.
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on DRM DRM_BRIDGE
Aagin, these are unnecessary.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d1b5daa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
Please keep these sorted alphabetically.
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
[...]
+#include linux/module.h
+#include linux/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
These too.
+struct ps8622_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge *bridge;
Should be embedded.
+ struct drm_panel *panel;
+ struct regulator *v12;
+ struct backlight_device *bl;
+ struct mutex enable_mutex;
I don't quite understand what this protects. Can you explain?
+struct ps8622_device_data {
+ u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+ .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+ .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) \
+ (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error T2.min + T1.max must be less than T2.max + T1.min
+#endif
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+ int ret;
+ struct i2c_adapter *adap = client-adapter;
+ struct i2c_msg msg;
+ u8 data[] = {reg, val};
+
+ msg.addr = client-addr + page;
+ msg.flags = 0;
+ msg.len = sizeof(data);
+
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Wed, Jul 30, 2014 at 03:54:13PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 3:10 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
Hi Thierry,
On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree
at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for
exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
On snow, the bridge chip provides the display mode instead of the panel.
That is why display was working for me.
Okay, I suppose under some circumstances that might make sense. Although
it's still always the panel that dictates the display timings, so the
panel node needs to have a panel model specific compatible value with a
matching entry in the panel-simple driver so that it can even be used in
setups without a bridge.
Well, I am okay with adding the compatible value for specific panel model
because simple-panel alone cannot provide width/height of the panel.
One other thing: how does the bridge know which mode to drive? I suspect
that it can drive more than one mode? Can it freely be configured or
does it have a predefined set of modes? If the latter, then according to
what you said above there needs to be a way to configure the bridge (via
DT?) so that it reports the mode matching the panel. I wonder if that
should be handled completely in code, so that for example a bridge has a
panel attached it can use the panel's .get_modes() and select a matching
mode among the set that it supports.
ptn3460 supports a standard list of edid-emulation ids.
As of now, we receive that as a DT entry.
And, these are the list of emulation ids supported:
| Value | Resolution | Description
| 0 | 1024x768 | NXP Generic
| 1 | 1920x1080 | NXP Generic
| 2 | 1920x1080 | NXP Generic
| 3 | 1600x900 | Samsung LTM200KT
| 4 | 1920x1080 | Samsung LTM230HT
| 5 | 1366x768 | NXP Generic
| 6 | 1600x900 | ChiMei M215HGE
As you can see, the same resolutions have different emulator ids.
May be, it depends on panel vendor also. I am really not sure if we can do
this.
For snow(which has 1366x768 panel), we set edid-emulation as 5.
Well, modes 1, 2 and 4 as well as modes 3 and 6 must differ in some
ways, otherwise there wouldn't be
Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
On Wed, Jul 30, 2014 at 05:02:11PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
Add panel_desc structure for auo_b133htn01 eDP panel.
Also, modify the panel_simple routines to support timing_parameter
delays if mentioned in the panel_desc structure.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/auo,b133htn01.txt|7 +++
drivers/gpu/drm/panel/panel-simple.c | 47
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/auo,b133htn01.txt
I think this should be two patches, one which adds the delay parameters
and another which adds support for the new panel.
Ok. Will split it.
I was going to propose that I split this up myself so you no longer have
to worry about it. I can easily apply the changes we discussed. But if
you prefer to keep it in one series that works for me too.
In general I think it would be good to have a description of these in
the struct panel_desc structure, something like this perhaps:
/**
* @prepare: the time (in milliseconds) that it takes for the panel
* to become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel
* to display the first valid frame after starting to
* receive video data
* @disable: the time (in milliseconds) that it takes for the panel
* to turn the display off (no content is visible)
* @unprepare: the time (in milliseconds) that it takes for the
panel
to power down itself completely.
*/
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
For prepare and enable delays this would mean that they should take
effect at the very end of the .prepare() and .enable() functions,
respectively. For disable in means that it should be at the end (for
example to take into account the time it takes for backlight to
completely turn off). For unprepare I have no idea what we would need it
for. And the new panel that you're adding in this patch doesn't use it
either, so perhaps it can just be left out (for now)?
Actually, there was a typo.
That should have been .unprepare_stage_delay = 50.
This is needed because panels need some delay before powering
them on again.
As in, assume you are doing a test to turn on/off display continuously,
Then, the delay between
(N - 1)th cycle poweroff to Nth cycle poweron should be at least 500ms.
That's what the datasheet says! And, somehow 50ms works fine for me.
Okay, that makes sense then.
Thierry
pgp72TbKeux9f.pgp
Description: PGP signature
Re: [PATCH v6 10/14] drm/panel: add S6E3FA0 driver
On 22/07/14 06:41, YoungJun Cho wrote: Yes, this command is related with Nokia. Last Friday, I met panel vendor guy for some issues. At the break time, I asked him for about this Read IDs(04H), why it is not included in DCS specification. He said that this command was originated by Nokia. In feature phone times, most of panel vendors wanted their panels to be used by Nokia and Nokia wanted this command, so most of panel vendors still provide this command traditionally. This is my understanding also. I think the whole MIPI DCS spec originated from Nokia's command set. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 3/8] drm/panel: simple: Add support for auo_b133htn01 panel
On Wed, Jul 30, 2014 at 7:00 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Jul 30, 2014 at 05:02:11PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 4:21 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:05AM +0530, Ajay Kumar wrote:
Add panel_desc structure for auo_b133htn01 eDP panel.
Also, modify the panel_simple routines to support timing_parameter
delays if mentioned in the panel_desc structure.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/panel/auo,b133htn01.txt|7 +++
drivers/gpu/drm/panel/panel-simple.c | 47
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/auo,b133htn01.txt
I think this should be two patches, one which adds the delay parameters
and another which adds support for the new panel.
Ok. Will split it.
I was going to propose that I split this up myself so you no longer have
to worry about it. I can easily apply the changes we discussed. But if
you prefer to keep it in one series that works for me too.
Well, you can only take in the delay structure as of now.
Ajay
In general I think it would be good to have a description of these in
the struct panel_desc structure, something like this perhaps:
/**
* @prepare: the time (in milliseconds) that it takes for the panel
* to become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel
* to display the first valid frame after starting to
* receive video data
* @disable: the time (in milliseconds) that it takes for the panel
* to turn the display off (no content is visible)
* @unprepare: the time (in milliseconds) that it takes for the
panel
to power down itself completely.
*/
struct {
unsigned int prepare;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;
For prepare and enable delays this would mean that they should take
effect at the very end of the .prepare() and .enable() functions,
respectively. For disable in means that it should be at the end (for
example to take into account the time it takes for backlight to
completely turn off). For unprepare I have no idea what we would need it
for. And the new panel that you're adding in this patch doesn't use it
either, so perhaps it can just be left out (for now)?
Actually, there was a typo.
That should have been .unprepare_stage_delay = 50.
This is needed because panels need some delay before powering
them on again.
As in, assume you are doing a test to turn on/off display continuously,
Then, the delay between
(N - 1)th cycle poweroff to Nth cycle poweron should be at least 500ms.
That's what the datasheet says! And, somehow 50ms works fine for me.
Okay, that makes sense then.
Thierry
--
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 v6 10/14] drm/panel: add S6E3FA0 driver
On 22/07/14 10:49, Thierry Reding wrote: But what I was trying to say is that if the Read IDs command isn't an official DCS command, maybe it would be a better idea to use the DDB instead. I assume that even if it isn't the same information it would at least be a superset and therefore a suitable replacement. Only if DDB commands work on that panel =). Even if a panel supports DCS, it doesn't mean it supports all the commands. Also, does it really matter which one to use inside a panel driver? I don't really see any pros nor cons with either option. Except, of course, if using one of those makes the driver's code simpler. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v3 0/4] ARM: dts: exynos: Prepare Spring
Hello, Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15 based attempts by Stephan and me that broke for 3.16, I've prepared a device tree for the HP Chromebook 11 aka Google Spring. v3 mainly does style cleanups, aligning Snow and Spring better. Not yet enabled are trackpad, Wifi and sound. My rebasing branch for testing is here: https://github.com/afaerber/linux/commits/spring-next Regards, Andreas v1 - v2: * Dropped 3 documentation patches from series: 2 picked up, https://patchwork.kernel.org/patch/4397271/ https://patchwork.kernel.org/patch/4397291/ 1 already sent separately as v2, pending. https://patchwork.kernel.org/patch/4424881/ * Minimized and beautified Spring device tree and to some degree Snow as well. See individual patches. v2 - v3: * Rebased: Two -cros-common cleanup patches were already applied * Lots of small cleanups for both Snow and Spring * Enabled I2S in Spring for symmetry * Added lid-switch and gpio-keys pinctrls to Spring Andreas Färber (4): ARM: dts: Fix MMC pinctrl for exynos5250-snow ARM: dts: Fold exynos5250-cros-common into exynos5250-snow ARM: dts: Clean up exynos5250-snow ARM: dts: Add exynos5250-spring device tree arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/exynos5250-cros-common.dtsi | 164 arch/arm/boot/dts/exynos5250-snow.dts | 338 ++-- arch/arm/boot/dts/exynos5250-spring.dts | 539 ++ 4 files changed, 770 insertions(+), 272 deletions(-) delete mode 100644 arch/arm/boot/dts/exynos5250-cros-common.dtsi create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] ARM: dts: Fix MMC pinctrl for exynos5250-snow
The pinctrl properties should be on the device directly and not on the
slot sub-node.
Reported-by: Doug Anderson diand...@chromium.org
Cc: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
v3: New (Doug Anderson)
Redundant with Jaehoon Chung's general slot@0 deprecation,
in case that hits the tree earlier.
arch/arm/boot/dts/exynos5250-snow.dts | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index f2b8c4116541..eb437f6afec1 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -240,10 +240,8 @@
*/
mmc@1223 {
status = okay;
- slot@0 {
- pinctrl-names = default;
- pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
- };
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
};
i2c@12CD {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] ARM: dts: Add exynos5250-spring device tree
Adds initial support for the HP Chromebook 11.
Cc: Vincent Palatin vpala...@chromium.org
Cc: Doug Anderson diand...@chromium.org
Cc: Stephan van Schaik step...@synkhronix.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2 - v3:
* Use GPIO_ACTIVE_{LOW,HIGH} (Doug Anderson)
* Use symbolic KEY_POWER instead of comment
* Moved hsic_reset to new USB3503 node's reset-gpios (Vincent Palatin)
* Use dp_hpd_gpio for dp-controller (Doug Anderson, Ajay Kumar)
* Override sd1_{clk,cmd,cd,bus4} pinctrl similar to Snow (Doug Anderson)
* Added ec_irq pinctrl for cros_ec (Doug Anderson)
* Reordered nodes to minimize diff against Snow (Doug Anderson)
* Dropped obsolete mmc_2 override (Doug Anderson)
* Added lid-switch node (Doug Anderson)
* Added gpio-keys pinctrl (Doug Anderson)
* Added bootargs to avoid empty /chosen node and to document console setting
* Renamed s5m8767_pmic node to avoid underscore
* Use new style for overriding inherited pinctrl nodes, too
* Enable i2s0 node
v1 - v2:
* Use label-based overriding/extension of nodes. (Doug Anderson)
* Dropped tps65090 for now, until we know where to place it.
* Dropped non-Spring nodes from -cros-common.dtsi rather than disabling them.
* Enabled a missing MMC node for access to internal storage.
* Dropped display-timings from dp-controller node. (Ajay Kumar)
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5250-spring.dts | 539
2 files changed, 540 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 80a781f76e88..dec4c292f63d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index ..bcca892bf2ff
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,539 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
+#include exynos5250.dtsi
+
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250, samsung,exynos5;
+
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ bootargs = console=tty1;
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+ pinctrl-names = default;
+ pinctrl-0 = power_key_irq, lid_irq;
+
+ power {
+ label = Power;
+ gpios = gpx1 3 GPIO_ACTIVE_LOW;
+ linux,code = KEY_POWER;
+ gpio-key,wakeup;
+ };
+
+ lid-switch {
+ label = Lid;
+ gpios = gpx3 5 GPIO_ACTIVE_LOW;
+ linux,input-type = 5; /* EV_SW */
+ linux,code = 0; /* SW_LID */
+ debounce-interval = 1;
+ gpio-key,wakeup;
+ };
+ };
+
+ usb3_vbus_reg: regulator-usb3 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpe1 0 GPIO_ACTIVE_LOW;
+ enable-active-high;
+ };
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx1 1 GPIO_ACTIVE_HIGH;
+ };
+
+ usb-hub {
+ compatible = smsc,usb3503a;
+ reset-gpios = hsic_reset;
+ };
+
+ fixed-rate-clocks {
+ xxti {
+ compatible = samsung,clock-xxti;
+ clock-frequency = 2400;
+ };
+ };
+
+ hdmi {
+ hpd-gpio = gpx3 7 GPIO_ACTIVE_HIGH;
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_hpd_irq;
+ phy = hdmiphy;
+ ddc = i2c_2;
+ hdmi-en-supply = s5m_ldo8_reg;
+ vdd-supply = s5m_ldo8_reg;
+ vdd_osc-supply = s5m_ldo10_reg;
+ vdd_pll-supply = s5m_ldo8_reg;
+ };
+
+ fimd@1440 {
+ status = okay;
+ samsung,invert-vclk;
+ };
+
+
[PATCH v3 2/4] ARM: dts: Fold exynos5250-cros-common into exynos5250-snow
The remaining common ChromeOS pieces are fairly minor.
Suggested-by: Doug Anderson diand...@chromium.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2 - v3:
* Renamed subject to match Kukjin's style
* Rebased onto MMC pinctrl bug fix (Doug Anderson)
v2: New (Doug Anderson)
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 164 --
arch/arm/boot/dts/exynos5250-snow.dts | 164 +++---
2 files changed, 145 insertions(+), 183 deletions(-)
delete mode 100644 arch/arm/boot/dts/exynos5250-cros-common.dtsi
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
deleted file mode 100644
index e603e9c70142..
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ /dev/null
@@ -1,164 +0,0 @@
-/*
- * Common device tree include for all Exynos 5250 boards based off of Daisy.
- *
- * Copyright (c) 2012 Google, Inc
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-/ {
- aliases {
- };
-
- memory {
- reg = 0x4000 0x8000;
- };
-
- chosen {
- };
-
- pinctrl@1140 {
- /*
-* Disabled pullups since external part has its own pullups and
-* double-pulling gets us out of spec in some cases.
-*/
- i2c2_bus: i2c2-bus {
- samsung,pin-pud = 0;
- };
- };
-
- i2c@12C6 {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 378000;
- };
-
- i2c@12C7 {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 378000;
- };
-
- i2c@12C8 {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 66000;
-
- hdmiddc@50 {
- compatible = samsung,exynos4210-hdmiddc;
- reg = 0x50;
- };
- };
-
- i2c@12C9 {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 66000;
- };
-
- i2c@12CA {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 66000;
- };
-
- i2c@12CB {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 66000;
- };
-
- i2c@12CD {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 66000;
- };
-
- i2c@12CE {
- status = okay;
- samsung,i2c-sda-delay = 100;
- samsung,i2c-max-bus-freq = 378000;
-
- hdmiphy: hdmiphy@38 {
- compatible = samsung,exynos4212-hdmiphy;
- reg = 0x38;
- };
- };
-
- mmc@1220 {
- num-slots = 1;
- supports-highspeed;
- broken-cd;
- card-detect-delay = 200;
- samsung,dw-mshc-ciu-div = 3;
- samsung,dw-mshc-sdr-timing = 2 3;
- samsung,dw-mshc-ddr-timing = 1 2;
- pinctrl-names = default;
- pinctrl-0 = sd0_clk sd0_cmd sd0_cd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
- };
-
- mmc@1222 {
- num-slots = 1;
- supports-highspeed;
- card-detect-delay = 200;
- samsung,dw-mshc-ciu-div = 3;
- samsung,dw-mshc-sdr-timing = 2 3;
- samsung,dw-mshc-ddr-timing = 1 2;
- pinctrl-names = default;
- pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- wp-gpios = gpc2 1 0;
- };
- };
-
- mmc@1223 {
- num-slots = 1;
- supports-highspeed;
- broken-cd;
- card-detect-delay = 200;
- samsung,dw-mshc-ciu-div = 3;
- samsung,dw-mshc-sdr-timing = 2 3;
- samsung,dw-mshc-ddr-timing = 1 2;
- /* See board-specific dts files for pin setup */
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
- };
-
- spi_1: spi@12d3 {
- status = okay;
- samsung,spi-src-clk = 0;
- num-cs = 1;
- };
-
- hdmi {
-
[PATCH v3 3/4] ARM: dts: Clean up exynos5250-snow
Use the new style of referencing inherited nodes and use symbolic names.
Suggested-by: Doug Anderson diand...@chromium.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
v3: New (Doug Anderson)
arch/arm/boot/dts/exynos5250-snow.dts | 182 +-
1 file changed, 90 insertions(+), 92 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1c36cd72905f..2ed6cb04a2db 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -9,6 +9,8 @@
*/
/dts-v1/;
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
#include exynos5250.dtsi
/ {
@@ -30,85 +32,19 @@
status = okay;
};
- pinctrl@1140 {
- ec_irq: ec-irq {
- samsung,pins = gpx1-6;
- samsung,pin-function = 0;
- samsung,pin-pud = 0;
- samsung,pin-drv = 0;
- };
-
- sd3_clk: sd3-clk {
- samsung,pin-drv = 0;
- };
-
- sd3_cmd: sd3-cmd {
- samsung,pin-pud = 3;
- samsung,pin-drv = 0;
- };
-
- sd3_bus4: sd3-bus-width4 {
- samsung,pin-drv = 0;
- };
-
- max98095_en: max98095-en {
- samsung,pins = gpx1-7;
- samsung,pin-function = 0;
- samsung,pin-pud = 3;
- samsung,pin-drv = 0;
- };
-
- tps65090_irq: tps65090-irq {
- samsung,pins = gpx2-6;
- samsung,pin-function = 0;
- samsung,pin-pud = 0;
- samsung,pin-drv = 0;
- };
-
- usb3_vbus_en: usb3-vbus-en {
- samsung,pins = gpx2-7;
- samsung,pin-function = 1;
- samsung,pin-pud = 0;
- samsung,pin-drv = 0;
- };
-
- hdmi_hpd_irq: hdmi-hpd-irq {
- samsung,pins = gpx3-7;
- samsung,pin-function = 0;
- samsung,pin-pud = 1;
- samsung,pin-drv = 0;
- };
- };
-
- pinctrl@1340 {
- arb_their_claim: arb-their-claim {
- samsung,pins = gpe0-4;
- samsung,pin-function = 0;
- samsung,pin-pud = 3;
- samsung,pin-drv = 0;
- };
-
- arb_our_claim: arb-our-claim {
- samsung,pins = gpf0-3;
- samsung,pin-function = 1;
- samsung,pin-pud = 0;
- samsung,pin-drv = 0;
- };
- };
-
gpio-keys {
compatible = gpio-keys;
power {
label = Power;
- gpios = gpx1 3 1;
- linux,code = 116; /* KEY_POWER */
+ gpios = gpx1 3 GPIO_ACTIVE_LOW;
+ linux,code = KEY_POWER;
gpio-key,wakeup;
};
lid-switch {
label = Lid;
- gpios = gpx3 5 1;
+ gpios = gpx3 5 GPIO_ACTIVE_LOW;
linux,input-type = 5; /* EV_SW */
linux,code = 0; /* SW_LID */
debounce-interval = 1;
@@ -129,8 +65,8 @@
i2c-parent = {/i2c@12CA};
- our-claim-gpio = gpf0 3 1;
- their-claim-gpios = gpe0 4 1;
+ our-claim-gpio = gpf0 3 GPIO_ACTIVE_LOW;
+ their-claim-gpios = gpe0 4 GPIO_ACTIVE_LOW;
slew-delay-us = 10;
wait-retry-us = 3000;
wait-free-us = 5;
@@ -239,19 +175,6 @@
};
};
- i2c@12CD {
- max98095: codec@11 {
- compatible = maxim,max98095;
- reg = 0x11;
- pinctrl-0 = max98095_en;
- pinctrl-names = default;
- };
- };
-
- i2s0: i2s@0383 {
- status = okay;
- };
-
sound {
compatible = google,snow-audio-max98095;
@@ -265,18 +188,14 @@
regulator-name = P5.0V_USB3CON;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
- gpio = gpx2 7 0;
+ gpio = gpx2 7 GPIO_ACTIVE_HIGH;
pinctrl-names = default;
pinctrl-0 = usb3_vbus_en;
enable-active-high;
};
- phy@1210 {
- vbus-supply = usb3_vbus_reg;
- };
-
Re: [PATCH] media: v4l2: make alloction alogthim more robust and flexible
Hi, A few trivial typos: s/alloction/allocation/ s/alogthim/algorithm/ Am 30.07.2014 05:55, schrieb Zhaowei Yuan: Current algothim relies on the fact that caller will align the s/algothim/algorithm/ size to PAGE_SIZE, otherwise order will be decreased to negative when remain size is less than PAGE_SIZE, it makes the function s/remain/remaining/ hard to be migrated. This patch sloves the hidden problem. s/sloves/solves/ Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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 0/4] ARM: dts: exynos: Prepare Spring
Am 30.07.2014 15:50, schrieb Andreas Färber:
Hello,
Based on the preinstalled 3.8 based ChromeOS kernel and previous 3.15
based attempts by Stephan and me that broke for 3.16, I've prepared a
device tree for the HP Chromebook 11 aka Google Spring.
v3 mainly does style cleanups, aligning Snow and Spring better.
And for your review convenience I attach the Snow vs. Spring diff.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--- arch/arm/boot/dts/exynos5250-snow.dts 2014-07-30 15:45:47.83417 +0200
+++ arch/arm/boot/dts/exynos5250-spring.dts 2014-07-30 16:10:06.715001113 +0200
@@ -1,12 +1,13 @@
/*
- * Google Snow board device tree source
+ * Google Spring board device tree source
*
- * Copyright (c) 2012 Google, Inc
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
-*/
+ */
/dts-v1/;
#include dt-bindings/gpio/gpio.h
@@ -14,26 +15,21 @@
#include exynos5250.dtsi
/ {
- model = Google Snow;
- compatible = google,snow, samsung,exynos5250, samsung,exynos5;
-
- aliases {
- i2c104 = i2c_104;
- };
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250, samsung,exynos5;
memory {
reg = 0x4000 0x8000;
};
chosen {
- };
-
- rtc@101E {
- status = okay;
+ bootargs = console=tty1;
};
gpio-keys {
compatible = gpio-keys;
+ pinctrl-names = default;
+ pinctrl-0 = power_key_irq, lid_irq;
power {
label = Power;
@@ -52,145 +48,12 @@
};
};
- vbat: vbat-fixed-regulator {
- compatible = regulator-fixed;
- regulator-name = vbat-supply;
- regulator-boot-on;
- };
-
- i2c-arbitrator {
- compatible = i2c-arb-gpio-challenge;
- #address-cells = 1;
- #size-cells = 0;
-
- i2c-parent = {/i2c@12CA};
-
- our-claim-gpio = gpf0 3 GPIO_ACTIVE_LOW;
- their-claim-gpios = gpe0 4 GPIO_ACTIVE_LOW;
- slew-delay-us = 10;
- wait-retry-us = 3000;
- wait-free-us = 5;
-
- pinctrl-names = default;
- pinctrl-0 = arb_our_claim arb_their_claim;
-
- /* Use ID 104 as a hint that we're on physical bus 4 */
- i2c_104: i2c@0 {
- reg = 0;
- #address-cells = 1;
- #size-cells = 0;
-
- battery: sbs-battery@b {
-compatible = sbs,sbs-battery;
-reg = 0xb;
-sbs,poll-retry-count = 1;
- };
-
- cros_ec: embedded-controller {
-compatible = google,cros-ec-i2c;
-reg = 0x1e;
-interrupts = 6 0;
-interrupt-parent = gpx1;
-pinctrl-names = default;
-pinctrl-0 = ec_irq;
-wakeup-source;
- };
-
- power-regulator {
-compatible = ti,tps65090;
-reg = 0x48;
-
-/*
- * Config irq to disable internal pulls
- * even though we run in polling mode.
- */
-pinctrl-names = default;
-pinctrl-0 = tps65090_irq;
-
-vsys1-supply = vbat;
-vsys2-supply = vbat;
-vsys3-supply = vbat;
-infet1-supply = vbat;
-infet2-supply = vbat;
-infet3-supply = vbat;
-infet4-supply = vbat;
-infet5-supply = vbat;
-infet6-supply = vbat;
-infet7-supply = vbat;
-vsys-l1-supply = vbat;
-vsys-l2-supply = vbat;
-
-regulators {
- dcdc1 {
- ti,enable-ext-control;
- };
- dcdc2 {
- ti,enable-ext-control;
- };
- dcdc3 {
- ti,enable-ext-control;
- };
- fet1 {
- regulator-name = vcd_led;
- ti,overcurrent-wait = 3;
- };
- tps65090_fet2: fet2 {
- regulator-name = video_mid;
- regulator-always-on;
- ti,overcurrent-wait = 3;
- };
- fet3 {
- regulator-name = wwan_r;
- regulator-always-on;
- ti,overcurrent-wait = 3;
- };
- fet4 {
- regulator-name = sdcard;
- ti,overcurrent-wait = 3;
- };
- fet5 {
- regulator-name = camout;
- regulator-always-on;
- ti,overcurrent-wait = 3;
- };
- fet6 {
- regulator-name = lcd_vdd;
- ti,overcurrent-wait = 3;
- };
- tps65090_fet7: fet7 {
- regulator-name = video_mid_1a;
- regulator-always-on;
- ti,overcurrent-wait = 3;
- };
- ldo1 {
- };
- ldo2 {
- };
-};
-
-charger {
- compatible = ti,tps65090-charger;
-};
- };
- };
- };
-
- sound {
- compatible = google,snow-audio-max98095;
-
- samsung,model = Snow-I2S-MAX98095;
- samsung,i2s-controller = i2s0;
- samsung,audio-codec = max98095;
- };
-
usb3_vbus_reg: regulator-usb3 {
compatible = regulator-fixed;
regulator-name = P5.0V_USB3CON;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
- gpio = gpx2 7 GPIO_ACTIVE_HIGH;
- pinctrl-names = default;
- pinctrl-0 = usb3_vbus_en;
+ gpio = gpe1 0 GPIO_ACTIVE_LOW;
enable-active-high;
};
@@ -198,6 +61,11 @@
samsung,vbus-gpio = gpx1 1 GPIO_ACTIVE_HIGH;
};
+ usb-hub {
+ compatible
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
This patch tries to seperate drm_bridge implementation
into 2 parts, a drm part and a non_drm part.
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling drm_bridge_add_for_lookup.
The parent encoder driver waits till the bridge is available in the
lookup table(by calling of_drm_find_bridge) and then continues with
its initialization.
The encoder driver should call drm_bridge_attach_encoder to pass on
the drm_device and the encoder pointers to the bridge object.
Now that the drm_device pointer is available, the encoder then calls
bridge-funcs-post_encoder_init to allow the bridge to continue
registering itself with the drm core.
Also, non driver model based ptn3460 driver is removed in this patch.
Why is it removed in this patch? Can't you do this incrementally rather
than remove the driver in this patch and add it again later? If you do
it this way then we'll always have this one commit where devices that
have a ptn3460 don't work, so it becomes impossible to bisect across
this commit.
Ok. I will try to modify ptn3460 to support driver model in this patch itself.
And then, adding panel support, converting it to gpiod interface and other
cleanups should follow.
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
[...]
+int drm_bridge_add_for_lookup(struct drm_bridge *bridge)
+{
+ mutex_lock(bridge_lock);
+ list_add_tail(bridge-head, bridge_lookup);
+ mutex_unlock(bridge_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_bridge_add_for_lookup);
+
+void drm_bridge_remove_from_lookup(struct drm_bridge *bridge)
+{
+ mutex_lock(bridge_lock);
+ list_del_init(bridge-head);
+ mutex_unlock(bridge_lock);
+}
+EXPORT_SYMBOL(drm_bridge_remove_from_lookup);
The _for_lookup and _from_lookup suffixes aren't useful in my
opinion.
Ok. I will just remove the suffix.
+int drm_bridge_attach_encoder(struct drm_bridge *bridge,
+ struct drm_encoder *encoder)
And this could simply be drm_bridge_attach() since we'll only ever
want to attach it to encoders.
Right.
+{
+ if (!bridge || !encoder)
+ return -EINVAL;
+
+ if (bridge-encoder)
+ return -EBUSY;
+
+ encoder-bridge = bridge;
+ bridge-encoder = encoder;
+ bridge-drm_dev = encoder-dev;
Should this function perhaps call the bridge's -post_encoder_init()?
And it should probably call drm_bridge_init() too, since the DRM device
is now available.
This will cleanup some code in both the drivers. I will change it.
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
Maybe since you're introducing a new drm_bridge.c file above already it
would make sense to move out existing drm_bridge related code in a
preparatory patch?
Maybe Sean or Rob can comment on whether there was a specific reason to
include it in drm_crtc.c in the first place.
@@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct
drm_bridge *bridge,
if (ret)
goto out;
- bridge-dev = dev;
- bridge-funcs = funcs;
+ bridge-drm_dev = dev;
This sets -drm_dev, but it was already set in drm_bridge_attach(), so I
think that's one more argument to call this function when attaching.
Point accepted.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
[...]
@@ -1370,7 +1361,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
- struct device_node *panel_node;
+ struct device_node *panel_node, *bridge_node;
Nit: I don't think you'll need two variables here, since once you've
obtained the real panel or bridge objects you no longer need the OF
nodes.
Right.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e529b68..e5a41ad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -619,6 +619,7 @@ struct drm_plane {
/**
* drm_bridge_funcs - drm_bridge control functions
+ * @post_encoder_init: called by the parent encoder
Maybe rename this to attach to make it more obvious when exactly it's
called?
post_encoder_attach?
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this
bridge
* @disable: Called right before encoder prepare, disables the bridge
* @post_disable: Called right after encoder prepare, for lockstepped
disable
@@ -628,6 +629,7 @@ struct drm_plane {
* @destroy: make object go away
*/
struct drm_bridge_funcs {
+ int (*post_encoder_init)(struct drm_bridge *bridge);
bool (*mode_fixup)(struct drm_bridge *bridge,
[PATCH 1/3] clk: exynos5410: Add the definitions of new clock registers
Added clock register definitions for the majority of the relevant clocks inside the SoC, including the definitions of all PLL's clocks. The definitions are now ordered by name, in order to make the driver more readable and reduce the chances of potential conflicts when adding new entries. The different register groups (SRC, DIV, PLL, GATE, etc) are separated by a blank line. Signed-off-by: Humberto Silva Naves hsna...@gmail.com --- drivers/clk/samsung/clk-exynos5410.c | 144 -- 1 file changed, 122 insertions(+), 22 deletions(-) diff --git a/drivers/clk/samsung/clk-exynos5410.c b/drivers/clk/samsung/clk-exynos5410.c index 231475b..72a533e 100644 --- a/drivers/clk/samsung/clk-exynos5410.c +++ b/drivers/clk/samsung/clk-exynos5410.c @@ -19,39 +19,139 @@ #include clk.h -#define APLL_LOCK 0x0 -#define APLL_CON0 0x100 -#define CPLL_LOCK 0x10020 -#define CPLL_CON0 0x10120 -#define MPLL_LOCK 0x4000 -#define MPLL_CON0 0x4100 -#define BPLL_LOCK 0x20010 -#define BPLL_CON0 0x20110 -#define KPLL_LOCK 0x28000 -#define KPLL_CON0 0x28100 +#define APLL_CON0 0x100 +#define APLL_LOCK 0x0 +#define BPLL_CON0 0x20110 +#define BPLL_LOCK 0x20010 +#define CPLL_CON0 0x10120 +#define CPLL_CON1 0x10124 +#define CPLL_LOCK 0x10020 +#define DPLL_CON0 0x10128 +#define DPLL_CON1 0x1012C +#define DPLL_LOCK 0x10030 +#define EPLL_CON0 0x10130 +#define EPLL_CON1 0x10134 +#define EPLL_CON2 0x10138 +#define EPLL_LOCK 0x10040 +#define IPLL_CON0 0x10150 +#define IPLL_CON1 0x10154 +#define IPLL_LOCK 0x10060 +#define KPLL_CON0 0x28100 +#define KPLL_LOCK 0x28000 +#define MPLL_CON0 0x4100 +#define MPLL_LOCK 0x4000 +#define VPLL_CON0 0x10140 +#define VPLL_CON1 0x10144 +#define VPLL_CON2 0x10148 +#define VPLL_LOCK 0x10050 -#define SRC_CPU0x200 -#define DIV_CPU0 0x500 +#define SRC_CDREX 0x20200 +#define SRC_CPERI0 0x4200 #define SRC_CPERI1 0x4204 -#define DIV_TOP0 0x10510 -#define DIV_TOP1 0x10514 -#define DIV_FSYS1 0x1054c -#define DIV_FSYS2 0x10550 -#define DIV_PERIC0 0x10558 +#define SRC_CPU0x200 +#define SRC_DISP0_00x10224 +#define SRC_DISP0_10x10228 +#define SRC_DISP1_00x1022C +#define SRC_DISP1_10x10230 +#define SRC_FSYS 0x10244 +#define SRC_GSCL 0x10220 +#define SRC_KFC0x28200 +#define SRC_MAU0x10240 +#define SRC_PERIC0 0x10250 +#define SRC_PERIC1 0x10254 #define SRC_TOP0 0x10210 #define SRC_TOP1 0x10214 #define SRC_TOP2 0x10218 -#define SRC_FSYS 0x10244 -#define SRC_PERIC0 0x10250 +#define SRC_TOP3 0x1021C + +#define SRC_MASK_DISP0_0 0x10324 +#define SRC_MASK_DISP0_1 0x10328 +#define SRC_MASK_DISP1_0 0x1032C +#define SRC_MASK_DISP1_1 0x10330 #define SRC_MASK_FSYS 0x10340 +#define SRC_MASK_GEN 0x10344 +#define SRC_MASK_GSCL 0x10320 +#define SRC_MASK_MAU 0x10334 #define SRC_MASK_PERIC00x10350 +#define SRC_MASK_PERIC10x10354 +#define SRC_MASK_TOP 0x10310 + +#define DIV_CDREX 0x20500 +#define DIV_CDREX2 0x20504 +#define DIV_CPERI0 0x4500 +#define DIV_CPERI1 0x4504 +#define DIV_CPU0 0x500 +#define DIV_CPU1 0x504 +#define DIV_DISP0_00x10524 +#define DIV_DISP0_10x10528 +#define DIV_DISP1_00x1052C +#define DIV_DISP1_10x10530 +#define DIV_FSYS0 0x10548 +#define DIV_FSYS1 0x1054C +#define DIV_FSYS2 0x10550 +#define DIV_FSYS3 0x10554 +#define DIV_GEN0x1053C +#define DIV_GSCL 0x10520 +#define DIV_G2D0x8500 +#define DIV_ISP0 0x0C300 +#define DIV_ISP1 0x0C304 +#define DIV_ISP2 0x0C308 +#define DIV_KFC0 0x28500 +#define DIV_MAU0x10544 +#define DIV_PERIC0 0x10558 +#define DIV_PERIC1 0x1055C +#define DIV_PERIC2 0x10560 +#define DIV_PERIC3 0x10564 +#define DIV_PERIC4 0x10568 +#define DIV_PERIC5 0x1056C +#define DIV_TOP0 0x10510 +#define DIV_TOP1 0x10514
[PATCH 3/3] clk: exynos5410: Added clocks BPLL, DPLL, EPLL, IPLL, MPLL, and VPLL
Added the remaining PLL clocks, and also registered the configuration
tables with the PLL coefficients for the supported frequencies.
These frequency tables are valid when a 24MHz clock is supplied as the
input clock source (which I believe is always the case). Furthermore,
the corresponding constants for these PLL clocks were addded to the
dt-bindings header file. While at it, the constant definitions were
reordered alphabetically.
Signed-off-by: Humberto Silva Naves hsna...@gmail.com
---
drivers/clk/samsung/clk-exynos5410.c | 128 +---
include/dt-bindings/clock/exynos5410.h | 12 ++-
2 files changed, 127 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c
index aaca65d..7f4b3ea 100644
--- a/drivers/clk/samsung/clk-exynos5410.c
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -156,9 +156,10 @@
/* list of PLLs */
enum exynos5410_plls {
- apll, cpll, mpll,
- bpll, kpll,
- nr_plls /* number of PLLs */
+ apll, bpll, cpll,
+ dpll, epll, ipll,
+ kpll, mpll, vpll,
+ nr_plls /* number of PLLs */
};
static void __iomem *reg_base;
@@ -398,17 +399,126 @@ static struct samsung_gate_clock exynos5410_gate_clks[]
__initdata = {
SRC_MASK_PERIC0, 8, CLK_SET_RATE_PARENT, 0),
};
+static struct samsung_pll_rate_table apll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_35XX_RATE(rate, m, p, s) */
+ PLL_35XX_RATE(21, 175, 2, 0),
+ PLL_35XX_RATE(20, 250, 3, 0),
+ PLL_35XX_RATE(19, 475, 6, 0),
+ PLL_35XX_RATE(18, 225, 3, 0),
+ PLL_35XX_RATE(17, 425, 6, 0),
+ PLL_35XX_RATE(16, 200, 3, 0),
+ PLL_35XX_RATE(15, 250, 4, 0),
+ PLL_35XX_RATE(14, 175, 3, 0),
+ PLL_35XX_RATE(13, 325, 6, 0),
+ PLL_35XX_RATE(12, 100, 2, 0),
+ PLL_35XX_RATE(11, 275, 3, 1),
+ PLL_35XX_RATE(10, 250, 3, 1),
+ PLL_35XX_RATE(9, 150, 2, 1),
+ PLL_35XX_RATE(8, 200, 3, 1),
+ PLL_35XX_RATE(7, 175, 3, 1),
+ PLL_35XX_RATE(6, 100, 2, 1),
+ PLL_35XX_RATE(5, 250, 3, 2),
+ PLL_35XX_RATE(4, 200, 3, 2),
+ PLL_35XX_RATE(3, 100, 2, 2),
+ PLL_35XX_RATE(2, 200, 3, 3),
+ { },
+};
+
+static struct samsung_pll_rate_table cpll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_35XX_RATE(rate, m, p, s) */
+ PLL_35XX_RATE(66600, 222, 4, 1),
+ PLL_35XX_RATE(64000, 160, 3, 1),
+ PLL_35XX_RATE(32000, 160, 3, 2),
+ { },
+};
+
+static struct samsung_pll_rate_table dpll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_35XX_RATE(rate, m, p, s) */
+ PLL_35XX_RATE(6, 200, 4, 1),
+ { },
+};
+
+static struct samsung_pll_rate_table epll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_36XX_RATE(rate, m, p, s, k) */
+ PLL_36XX_RATE(6, 100, 2, 1, 0),
+ PLL_36XX_RATE(4, 200, 3, 2, 0),
+ PLL_36XX_RATE(2, 200, 3, 3, 0),
+ PLL_36XX_RATE(180633600, 301, 5, 3, -3670),
+ PLL_36XX_RATE( 67737600, 452, 5, 5, -27263),
+ PLL_36XX_RATE( 49152000, 197, 3, 5, -25690),
+ PLL_36XX_RATE( 45158401, 181, 3, 5, -24012),
+ { },
+};
+
+static struct samsung_pll_rate_table ipll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_35XX_RATE(rate, m, p, s, k) */
+ PLL_35XX_RATE(86400, 288, 4, 1),
+ PLL_35XX_RATE(66600, 222, 4, 1),
+ PLL_35XX_RATE(43200, 288, 4, 2),
+ { },
+};
+
+static struct samsung_pll_rate_table kpll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_35XX_RATE(rate, m, p, s) */
+ PLL_35XX_RATE(15, 250, 4, 0),
+ PLL_35XX_RATE(14, 175, 3, 0),
+ PLL_35XX_RATE(13, 325, 6, 0),
+ PLL_35XX_RATE(12, 100, 2, 0),
+ PLL_35XX_RATE(11, 275, 3, 1),
+ PLL_35XX_RATE(10, 250, 3, 1),
+ PLL_35XX_RATE(9, 150, 2, 1),
+ PLL_35XX_RATE(8, 200, 3, 1),
+ PLL_35XX_RATE(7, 175, 3, 1),
+ PLL_35XX_RATE(6, 100, 2, 1),
+ PLL_35XX_RATE(5, 250, 3, 2),
+ PLL_35XX_RATE(4, 200, 3, 2),
+ PLL_35XX_RATE(3, 100, 2, 2),
+ PLL_35XX_RATE(2, 200, 3, 3),
+ { },
+};
+
+static struct samsung_pll_rate_table vpll_24mhz_tbl[] __initdata = {
+ /* sorted in descending order */
+ /* PLL_36XX_RATE(rate, m, p, s, k) */
+ PLL_36XX_RATE(88000, 220, 3, 1, 0),
+ PLL_36XX_RATE(64000, 160, 3, 1, 0),
+ PLL_36XX_RATE(53200, 133, 3, 1, 0),
+
[PATCH 2/3] clk: exynos5410: Add suspend/resume handling
This patch implements all the necessary code that handles register
saving and restoring during a suspend/resume cycle.
To make this possible, the local variable reg_base from the function
exynos5410_clk_init was changed to global.
Signed-off-by: Humberto Silva Naves hsna...@gmail.com
---
drivers/clk/samsung/clk-exynos5410.c | 132 +-
1 file changed, 131 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c
index 72a533e..aaca65d 100644
--- a/drivers/clk/samsung/clk-exynos5410.c
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -16,6 +16,7 @@
#include linux/clk-provider.h
#include linux/of.h
#include linux/of_address.h
+#include linux/syscore_ops.h
#include clk.h
@@ -160,6 +161,134 @@ enum exynos5410_plls {
nr_plls /* number of PLLs */
};
+static void __iomem *reg_base;
+
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *exynos5410_save;
+
+/*
+ * list of controller registers to be saved and restored during a
+ * suspend/resume cycle.
+ */
+static unsigned long exynos5410_clk_regs[] __initdata = {
+ SRC_CDREX,
+ SRC_CPERI0,
+ SRC_CPERI1,
+ SRC_CPU,
+ SRC_DISP0_0,
+ SRC_DISP0_1,
+ SRC_DISP1_0,
+ SRC_DISP1_1,
+ SRC_FSYS,
+ SRC_GSCL,
+ SRC_KFC,
+ SRC_MAU,
+ SRC_PERIC0,
+ SRC_PERIC1,
+ SRC_TOP0,
+ SRC_TOP1,
+ SRC_TOP2,
+ SRC_TOP3,
+
+ DIV_CDREX,
+ DIV_CDREX2,
+ DIV_CPU0,
+ DIV_CPERI1,
+ DIV_DISP0_0,
+ DIV_DISP0_1,
+ DIV_DISP1_0,
+ DIV_DISP1_1,
+ DIV_FSYS0,
+ DIV_FSYS1,
+ DIV_FSYS2,
+ DIV_GEN,
+ DIV_GSCL,
+ DIV_G2D,
+ DIV_KFC0,
+ DIV_MAU,
+ DIV_PERIC0,
+ DIV_PERIC1,
+ DIV_PERIC2,
+ DIV_PERIC3,
+ DIV_PERIC4,
+ DIV_PERIC5,
+ DIV_TOP0,
+ DIV_TOP1,
+ DIV_TOP2,
+ DIV_TOP3,
+
+ GATE_BUS_DISP1,
+ GATE_BUS_FSYS0,
+
+ GATE_IP_CDREX,
+ GATE_IP_CORE,
+ GATE_IP_DISP0,
+ GATE_IP_DISP1,
+ GATE_IP_FSYS,
+ GATE_IP_GEN,
+ GATE_IP_GSCL0,
+ GATE_IP_GSCL1,
+ GATE_IP_G2D,
+ GATE_IP_G3D,
+ GATE_IP_MFC,
+ GATE_IP_PERIC,
+ GATE_IP_PERIS,
+
+ GATE_TOP_SCLK_DISP1,
+ GATE_TOP_SCLK_FSYS,
+ GATE_TOP_SCLK_GSCL,
+ GATE_TOP_SCLK_MAU,
+ GATE_TOP_SCLK_PERIC,
+
+ GATE_BUS_DISP1,
+ GATE_BUS_FSYS0,
+
+ GATE_SCLK_CPU,
+
+ SRC_MASK_DISP0_0,
+ SRC_MASK_DISP1_0,
+ SRC_MASK_FSYS,
+ SRC_MASK_MAU,
+ SRC_MASK_PERIC0,
+ SRC_MASK_PERIC1,
+};
+
+static int exynos5410_clk_suspend(void)
+{
+ samsung_clk_save(reg_base, exynos5410_save,
+ ARRAY_SIZE(exynos5410_clk_regs));
+
+ return 0;
+}
+
+static void exynos5410_clk_resume(void)
+{
+ samsung_clk_restore(reg_base, exynos5410_save,
+ ARRAY_SIZE(exynos5410_clk_regs));
+}
+
+static struct syscore_ops exynos5410_clk_syscore_ops = {
+ .suspend = exynos5410_clk_suspend,
+ .resume = exynos5410_clk_resume,
+};
+
+static void exynos5410_clk_sleep_init(void)
+{
+ exynos5410_save = samsung_clk_alloc_reg_dump(exynos5410_clk_regs,
+ ARRAY_SIZE(exynos5410_clk_regs));
+ if (!exynos5410_save) {
+ pr_warn(%s: failed to allocate sleep save data, no sleep
support!\n,
+ __func__);
+ return;
+ }
+
+ register_syscore_ops(exynos5410_clk_syscore_ops);
+}
+#else
+static void exynos5410_clk_sleep_init(void) {}
+#endif
+
+
/* list of all parent clocks */
PNAME(apll_p) = { fin_pll, fout_apll, };
PNAME(bpll_p) = { fin_pll, fout_bpll, };
@@ -286,7 +415,6 @@ static struct samsung_pll_clock exynos5410_plls[nr_plls]
__initdata = {
static void __init exynos5410_clk_init(struct device_node *np)
{
struct samsung_clk_provider *ctx;
- void __iomem *reg_base;
reg_base = of_iomap(np, 0);
if (!reg_base)
@@ -304,6 +432,8 @@ static void __init exynos5410_clk_init(struct device_node
*np)
samsung_clk_register_gate(ctx, exynos5410_gate_clks,
ARRAY_SIZE(exynos5410_gate_clks));
+ exynos5410_clk_sleep_init();
+
samsung_clk_of_add_provider(np, ctx);
pr_debug(Exynos5410: clock setup completed.\n);
--
1.7.10.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
Re: [PATCH v6 10/14] drm/panel: add S6E3FA0 driver
On Wed, Jul 30, 2014 at 04:44:21PM +0300, Tomi Valkeinen wrote: On 22/07/14 10:49, Thierry Reding wrote: But what I was trying to say is that if the Read IDs command isn't an official DCS command, maybe it would be a better idea to use the DDB instead. I assume that even if it isn't the same information it would at least be a superset and therefore a suitable replacement. Only if DDB commands work on that panel =). Even if a panel supports DCS, it doesn't mean it supports all the commands. Indeed. I was perhaps a little naïve and assumed this was such a great standard command that every panel simply had to support it. But so far I haven't yet come across a single panel that does... Also, does it really matter which one to use inside a panel driver? I don't really see any pros nor cons with either option. Except, of course, if using one of those makes the driver's code simpler. Yeah, at this point I don't see why the read IDs command shouldn't be used. It's somewhat unfortunate that it isn't mentioned in the DCS specification at all, but specifications are only as useful to the degree that they get implemented... My hope had been that we would be able to automatically probe for panels using the DDB, but it seems like that's not a practicable idea given the almost non-existent support for it. So as long as we can standardize on common APIs rather than per-driver implementations, I'm good. Thierry pgpWVUoQnB97F.pgp Description: PGP signature
Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
On Wed, Jul 30, 2014 at 08:01:44PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
This patch tries to seperate drm_bridge implementation
into 2 parts, a drm part and a non_drm part.
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling drm_bridge_add_for_lookup.
The parent encoder driver waits till the bridge is available in the
lookup table(by calling of_drm_find_bridge) and then continues with
its initialization.
The encoder driver should call drm_bridge_attach_encoder to pass on
the drm_device and the encoder pointers to the bridge object.
Now that the drm_device pointer is available, the encoder then calls
bridge-funcs-post_encoder_init to allow the bridge to continue
registering itself with the drm core.
Also, non driver model based ptn3460 driver is removed in this patch.
Why is it removed in this patch? Can't you do this incrementally rather
than remove the driver in this patch and add it again later? If you do
it this way then we'll always have this one commit where devices that
have a ptn3460 don't work, so it becomes impossible to bisect across
this commit.
Ok. I will try to modify ptn3460 to support driver model in this patch itself.
And then, adding panel support, converting it to gpiod interface and other
cleanups should follow.
I think it should even be possible to do this in more separate steps.
For example you could add the new bridge infrastructure without touching
any of the existing drivers (so that they are completely unaffected by
the changes) and then start converting one by one.
For some of the changes this may be difficult (such as the dev -
drm_dev rename to make room for the new struct device *dev). But that
could for example be done in a preparatory patch that first renames the
field, so that the infrastructure patch can add the new field without
renaming any fields and therefore needing changes to drivers directly.
The goal of that whole exercise is to allow display drivers to keep
working with the existing API (ptn3460_init()) while we convert the
bridge drivers to register with the new framework. Then we can more
safely convert each display driver individually to make use of the new
framework and once all drivers have been converted the old API can
simply be removed.
That way there should be no impact on existing functionality at any
point.
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
Maybe since you're introducing a new drm_bridge.c file above already it
would make sense to move out existing drm_bridge related code in a
preparatory patch?
Maybe Sean or Rob can comment on whether there was a specific reason to
include it in drm_crtc.c in the first place.
@@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct
drm_bridge *bridge,
if (ret)
goto out;
- bridge-dev = dev;
- bridge-funcs = funcs;
+ bridge-drm_dev = dev;
This sets -drm_dev, but it was already set in drm_bridge_attach(), so I
think that's one more argument to call this function when attaching.
Point accepted.
I forgot to mention earlier. drm_dev seems redundant to me. I'd go with
just drm.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e529b68..e5a41ad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -619,6 +619,7 @@ struct drm_plane {
/**
* drm_bridge_funcs - drm_bridge control functions
+ * @post_encoder_init: called by the parent encoder
Maybe rename this to attach to make it more obvious when exactly it's
called?
post_encoder_attach?
post_encoder_ doesn't contain much information, or even ambiguous
information. What does post encoder mean? A bridge is always
attached to an encoder, so encoder can be dropped. Now post has
implications as to the time when it is called, but does it mean after
the encoder has been initialized, or after the encoder has been removed?
Simply attach means it's called by the parent encoder to initialize
the bridge once it's been attached to an encoder. So obviously it's
after the encoder has been initialized. attach has all he information
required. Any prefix is redundant in my opinion and removing prefixes
gives shorter names and reduces the number of keypresses.
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this
bridge
* @disable: Called right before encoder prepare, disables the bridge
* @post_disable: Called right after encoder prepare, for lockstepped
disable
@@ -628,6 +629,7 @@ struct drm_plane {
* @destroy: make object go away
*/
struct drm_bridge_funcs {
+ int (*post_encoder_init)(struct drm_bridge *bridge);
Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1e2f96c..0b12d16 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,4 +6,14 @@ config DRM_BRIDGE
menu bridge chips
depends on DRM_BRIDGE
+
+config DRM_PTN3460
+ tristate NXP ptn3460 eDP/LVDS bridge
+ depends on DRM DRM_BRIDGE
I don't think you need these two dependencies any longer since they are
implicit in the bridge chips menu.
Ok.
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
[...]
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/delay.h
+#include drm/drm_panel.h
These should be ordered alphabetically, but they are already this way in
the original driver, so the reordering can be a separate patch.
This can be done later.
+struct ptn3460_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge *bridge;
I think it would be much more natural for ptn3460_bridge to embed struct
drm_bridge rather than store a pointer to it.
Right. As you said, we can eliminate driver_private and use container_of.
+ struct drm_panel *panel;
+ struct edid *edid;
+ struct gpio_desc *gpio_pd_n;
+ struct gpio_desc *gpio_rst_n;
+ u32 edid_emulation;
+ bool enabled;
+};
+
+static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
+ u8 *buf, int len)
+{
+ int ret;
+
+ ret = i2c_master_send(ptn_bridge-client, addr, 1);
+ if (ret = 0) {
+ DRM_ERROR(Failed to send i2c command, ret=%d\n, ret);
+ return ret;
+ }
+
+ ret = i2c_master_recv(ptn_bridge-client, buf, len);
+ if (ret = 0) {
+ DRM_ERROR(Failed to recv i2c data, ret=%d\n, ret);
+ return ret;
+ }
This isn't introduced by this patch, but doesn't this require locking so
that this is an atomic transaction?
Perhaps it could be rewritten using i2c_smbus_read_block_data()?
Well, I am not quite aware of i2c functions. I will have a look into it though.
+static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
+ char val)
+{
+ int ret;
+ char buf[2];
+
+ buf[0] = addr;
+ buf[1] = val;
+
+ ret = i2c_master_send(ptn_bridge-client, buf, ARRAY_SIZE(buf));
+ if (ret = 0) {
+ DRM_ERROR(Failed to send i2c command, ret=%d\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
Same here, this looks like it could be i2c_smbus_write_byte_data().
+static int ptn3460_select_edid(struct ptn3460_bridge *ptn_bridge)
+{
+ int ret;
+ char val;
+
+ /* Load the selected edid into SRAM (accessed at PTN3460_EDID_ADDR) */
+ ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_SRAM_LOAD_ADDR,
+ ptn_bridge-edid_emulation);
+ if (ret) {
+ DRM_ERROR(Failed to transfer edid to sram, ret=%d\n, ret);
+ return ret;
+ }
+
+ /* Enable EDID emulation and select the desired EDID */
+ val = 1 PTN3460_EDID_ENABLE_EMULATION |
+ ptn_bridge-edid_emulation PTN3460_EDID_EMULATION_SELECTION;
+
+ ret = ptn3460_write_byte(ptn_bridge, PTN3460_EDID_EMULATION_ADDR, val);
+ if (ret) {
+ DRM_ERROR(Failed to write edid value, ret=%d\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
s/edid/EDID/ in the above (and below, too), but again the original
driver had this, so it can be a separate patch.
This can be done later.
+static void ptn3460_pre_enable(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
If you embed drm_bridge within ptn3460_bridge then you can use the much
more canonical container_of() macro (or rather a driver-specific inline
function that wraps it) and no longer need the drm_bridge.driver_private
field.
Agreed.
+ int ret;
+
+ if (ptn_bridge-enabled)
+ return;
+
+ gpiod_set_value(ptn_bridge-gpio_pd_n, 1);
+
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 0);
+ udelay(10);
This shouldn't be using udelay(), usleep_range(10, 20) (or similar)
would be better. Again, can be a separate patch.
+ gpiod_set_value(ptn_bridge-gpio_rst_n, 1);
It also seems like you've converted to using the gpiod_*() API, but the
driver previously used gpio_is_valid() to check that both PD and RST
pins had valid GPIOs associated with them. The device tree binding said
that they are required, though.
So this patch actually does the right thing by making them non-optional
but it also changes behaviour from the original. Like I said earlier, I
would very much prefer that
Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding thierry.red...@gmail.com
wrote:
On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
+int ptn3460_post_encoder_init(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ int ret;
+
+ /* bridge is attached to encoder.
+ * safe to remove it from the bridge_lookup table.
+ */
+ drm_bridge_remove_from_lookup(bridge);
No, you should never do this. First, you're not adding it back to the
registry when the bridge is detached, so unloading and reloading the
display driver will fail. Second there should never be a need to remove
it from the registry as long as the driver itself is loaded. If you're
concerned about a single bridge being used multiple times, there's
already code to handle that in your previous patch:
int drm_bridge_attach_encoder(...)
{
...
if (bridge-encoder)
return -EBUSY;
...
}
Generally the registry should contain a list of bridges that have been
registered, whether they're used or not is irrelevant.
I was just wondering if it is ok to have a node in two independent lists?
bridge_lookup_table and the other mode_config.bridge_list?
Oh, it reuses the head field for the registry. I hadn't noticed before.
No, you certainly can't have the same node in two lists. Honestly I
don't quite understand why there was a need to expose drm_bridge as a
drm_mode_object in the first place since it's never exported to
userspace.
So I think that perhaps we could simply get rid of the base field and
not tie in drm_bridge objects with the DRM object as we currently do.
But until Sean or Rob comment on this it might be better to simply add
another struct list_head field for the registry. That way both can
coexist and we can independently still decide to remove the base and
head fields if they're no longer needed.
+ ret = drm_connector_init(bridge-drm_dev, ptn_bridge-connector,
+ ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR(Failed to initialize connector with drm\n);
+ return ret;
+ }
+ drm_connector_helper_add(ptn_bridge-connector,
+ ptn3460_connector_helper_funcs);
+ drm_connector_register(ptn_bridge-connector);
+ drm_mode_connector_attach_encoder(ptn_bridge-connector,
+ bridge-encoder);
+
+ if (ptn_bridge-panel)
+ drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+
+ return ret;
+}
I'm thinking that eventually we'll want to register the connector only
when a panel is attached to the bridge. This will only become important
when we implement bridge chaining because if you instantiate a connector
for each bridge then you'll get a list of connectors for the DRM device
representing the output of each bridge rather than just the final one
that goes to the display.
So, do not initialize connector if there is no panel? and, get_modes
via panel instead of doing it by edid-emulation?
If there's no panel, then there's nothing to connect the connector to,
so it's unneeded. Also if you have chained bridges, then each bridge
would expose a connector and it would become impossible to choose the
correct one. So only the final bridge in the chain should instantiate
the connector.
.get_modes() still needs to be done from the bridge because that is the
most closely connected to the display controller and therefore dictates
the timing that the display controller needs to generate.
Querying the panel's .get_modes() might be useful to figure out which
emulation mode to use in the bridge.
Thierry
pgpOZm7FP41dr.pgp
Description: PGP signature
Re: [PATCHv8 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Jaehoon,
On Wed, Jul 30, 2014 at 4:05 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Replaced the disable-wp into host's quirks.
(Because the slot-node is removed at dt-file.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/host/dw_mmc.c |8 +++-
include/linux/mmc/dw_mmc.h |2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..8d9edc6 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -997,7 +997,10 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
int gpio_ro = mmc_gpio_get_ro(mmc);
/* Use platform get_ro function, else try on board write protect */
- if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+ if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) {
+ dev_warn(slot-host-dev, Recommend not to use 'disable-wp'
+ into slot-node. Change your dt-file!!);
+ } else if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)
This isn't what I meant. I meant that
DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT should continue to work normally
but print a warning once at bootup. In other words, this code should
be:
- if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+ if ((slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) ||
+ (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)) {
Then add the warning in dw_mci_of_get_slot_quirks which is only
called once at init time. You can warn if ANY slot quirks are
actually applied, like:
for (idx = 0; idx ARRAY_SIZE(of_slot_quirks); idx++)
if (of_get_property(np, of_slot_quirks[idx].quirk, NULL)) {
dev_warn(dev, Slot quirk %s is deprecated\n, of_slot_quirks[idx].quirk);
quirks |= of_slot_quirks[idx].id;
}
read_only = 0;
else if (!IS_ERR_VALUE(gpio_ro))
read_only = gpio_ro;
@@ -2238,6 +2241,9 @@ static struct dw_mci_of_quirks {
{
.quirk = broken-cd,
.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
+ }, {
+ .quirk = disable-wp,
+ .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
},
};
If you fix it like I say, then this patch should actually be patch #2
in your series and can be applied _before_ the device tree files.
That means you could land patch #1 and patch #2 right away without
even getting acks for the dts changes. ...and if the dts changes have
conflicts they can be resolved later without blocking this patch.
-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: [PATCHv8 1/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed
Jaehoon, On Wed, Jul 30, 2014 at 4:05 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Almost SoCs use one slot per host controller. (Even if controller can support the multiple slot, Recommend to use one slot per host controller.) Don't use the slot-node and deprecate the supports-highspeed property. Instead, use the cap-mmc/sd-highspeed. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Reviewed-by: Tushar Behera trbli...@gmail.com Reviewed-by: Ulf Hansson ulf.hans...@linaro.org Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com Reviewed-by: Doug Anderson diand...@chromium.org -- 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: [PATCHv8 2/5] ARM: dts: exynos: unuse the slot-node and deprecated the supports-highspeed for dw-mmc
Jaehoon,
On Wed, Jul 30, 2014 at 4:05 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..42a3590 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -401,7 +401,6 @@
mmc_0: mmc@1220 {
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -410,17 +409,13 @@
vmmc-supply = mmc_reg;
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
mmc_2: mmc@1222 {
status = okay;
num-slots = 1;
- supports-highspeed;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -428,12 +423,9 @@
vmmc-supply = mmc_reg;
pinctrl-names = default;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
+ cap-sd-highspeed;
It seems like you ought to include cap-mmc-highspeed in addition to
cap-sd-highspeed, but I could be wrong. I know that I have some
full-sized MMC cards (not eMMC) that can be plugged into an SD card
slot. I know that the SD/MMC slot on this port only has 4 pins on
exynos5250, but I think you can still run MMC highspeed on 4 pins,
right?
-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 V6 6/8] drm/bridge: Modify drm_bridge core to support driver model
On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Jul 30, 2014 at 08:01:44PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 4:49 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Sat, Jul 26, 2014 at 12:52:08AM +0530, Ajay Kumar wrote:
This patch tries to seperate drm_bridge implementation
into 2 parts, a drm part and a non_drm part.
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling drm_bridge_add_for_lookup.
The parent encoder driver waits till the bridge is available in the
lookup table(by calling of_drm_find_bridge) and then continues with
its initialization.
The encoder driver should call drm_bridge_attach_encoder to pass on
the drm_device and the encoder pointers to the bridge object.
Now that the drm_device pointer is available, the encoder then calls
bridge-funcs-post_encoder_init to allow the bridge to continue
registering itself with the drm core.
Also, non driver model based ptn3460 driver is removed in this patch.
Why is it removed in this patch? Can't you do this incrementally rather
than remove the driver in this patch and add it again later? If you do
it this way then we'll always have this one commit where devices that
have a ptn3460 don't work, so it becomes impossible to bisect across
this commit.
Ok. I will try to modify ptn3460 to support driver model in this patch
itself.
And then, adding panel support, converting it to gpiod interface and other
cleanups should follow.
I think it should even be possible to do this in more separate steps.
For example you could add the new bridge infrastructure without touching
any of the existing drivers (so that they are completely unaffected by
the changes) and then start converting one by one.
For some of the changes this may be difficult (such as the dev -
drm_dev rename to make room for the new struct device *dev). But that
could for example be done in a preparatory patch that first renames the
field, so that the infrastructure patch can add the new field without
renaming any fields and therefore needing changes to drivers directly.
The goal of that whole exercise is to allow display drivers to keep
working with the existing API (ptn3460_init()) while we convert the
bridge drivers to register with the new framework. Then we can more
safely convert each display driver individually to make use of the new
framework and once all drivers have been converted the old API can
simply be removed.
That way there should be no impact on existing functionality at any
point.
As of now only exynos_dp uses ptn3460_init.
And, also only 2 drivers use drm_bridge_init.
It should be really easy to bisect if something goes wrong.
Still, I will try to divide it so that each patch contains minimal change.
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
Maybe since you're introducing a new drm_bridge.c file above already it
would make sense to move out existing drm_bridge related code in a
preparatory patch?
Maybe Sean or Rob can comment on whether there was a specific reason to
include it in drm_crtc.c in the first place.
@@ -1012,8 +1010,7 @@ int drm_bridge_init(struct drm_device *dev, struct
drm_bridge *bridge,
if (ret)
goto out;
- bridge-dev = dev;
- bridge-funcs = funcs;
+ bridge-drm_dev = dev;
This sets -drm_dev, but it was already set in drm_bridge_attach(), so I
think that's one more argument to call this function when attaching.
Point accepted.
I forgot to mention earlier. drm_dev seems redundant to me. I'd go with
just drm.
Ok.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e529b68..e5a41ad 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -619,6 +619,7 @@ struct drm_plane {
/**
* drm_bridge_funcs - drm_bridge control functions
+ * @post_encoder_init: called by the parent encoder
Maybe rename this to attach to make it more obvious when exactly it's
called?
post_encoder_attach?
post_encoder_ doesn't contain much information, or even ambiguous
information. What does post encoder mean? A bridge is always
attached to an encoder, so encoder can be dropped. Now post has
implications as to the time when it is called, but does it mean after
the encoder has been initialized, or after the encoder has been removed?
Simply attach means it's called by the parent encoder to initialize
the bridge once it's been attached to an encoder. So obviously it's
after the encoder has been initialized. attach has all he information
required. Any prefix is redundant in my opinion and removing prefixes
gives shorter names and reduces the number of keypresses.
Finally, what name it should have?
* @mode_fixup: Try to fixup (or reject
Re: [PATCH V2 7/8] drm/bridge: Add i2c based driver for ptn3460 bridge
On Wed, Jul 30, 2014 at 9:10 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Wed, Jul 30, 2014 at 08:46:44PM +0530, Ajay kumar wrote:
On Wed, Jul 30, 2014 at 5:35 PM, Thierry Reding thierry.red...@gmail.com
wrote:
On Sat, Jul 26, 2014 at 12:52:09AM +0530, Ajay Kumar wrote:
[...]
+int ptn3460_post_encoder_init(struct drm_bridge *bridge)
+{
+ struct ptn3460_bridge *ptn_bridge = bridge-driver_private;
+ int ret;
+
+ /* bridge is attached to encoder.
+ * safe to remove it from the bridge_lookup table.
+ */
+ drm_bridge_remove_from_lookup(bridge);
No, you should never do this. First, you're not adding it back to the
registry when the bridge is detached, so unloading and reloading the
display driver will fail. Second there should never be a need to remove
it from the registry as long as the driver itself is loaded. If you're
concerned about a single bridge being used multiple times, there's
already code to handle that in your previous patch:
int drm_bridge_attach_encoder(...)
{
...
if (bridge-encoder)
return -EBUSY;
...
}
Generally the registry should contain a list of bridges that have been
registered, whether they're used or not is irrelevant.
I was just wondering if it is ok to have a node in two independent lists?
bridge_lookup_table and the other mode_config.bridge_list?
Oh, it reuses the head field for the registry. I hadn't noticed before.
No, you certainly can't have the same node in two lists. Honestly I
don't quite understand why there was a need to expose drm_bridge as a
drm_mode_object in the first place since it's never exported to
userspace.
So I think that perhaps we could simply get rid of the base field and
not tie in drm_bridge objects with the DRM object as we currently do.
But until Sean or Rob comment on this it might be better to simply add
another struct list_head field for the registry. That way both can
coexist and we can independently still decide to remove the base and
head fields if they're no longer needed.
Ok. What shall I name the new list_head?
+ ret = drm_connector_init(bridge-drm_dev, ptn_bridge-connector,
+ ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
+ if (ret) {
+ DRM_ERROR(Failed to initialize connector with drm\n);
+ return ret;
+ }
+ drm_connector_helper_add(ptn_bridge-connector,
+ ptn3460_connector_helper_funcs);
+ drm_connector_register(ptn_bridge-connector);
+ drm_mode_connector_attach_encoder(ptn_bridge-connector,
+ bridge-encoder);
+
+ if (ptn_bridge-panel)
+ drm_panel_attach(ptn_bridge-panel, ptn_bridge-connector);
+
+ return ret;
+}
I'm thinking that eventually we'll want to register the connector only
when a panel is attached to the bridge. This will only become important
when we implement bridge chaining because if you instantiate a connector
for each bridge then you'll get a list of connectors for the DRM device
representing the output of each bridge rather than just the final one
that goes to the display.
So, do not initialize connector if there is no panel? and, get_modes
via panel instead of doing it by edid-emulation?
If there's no panel, then there's nothing to connect the connector to,
so it's unneeded. Also if you have chained bridges, then each bridge
would expose a connector and it would become impossible to choose the
correct one. So only the final bridge in the chain should instantiate
the connector.
Since there is only a single bridge when it comes to ptn3460/ps8622, lets
not talk about chaining of bridges now.
And, I agree that if there is no panel, then no need to register connector.
.get_modes() still needs to be done from the bridge because that is the
most closely connected to the display controller and therefore dictates
the timing that the display controller needs to generate.
Querying the panel's .get_modes() might be useful to figure out which
emulation mode to use in the bridge.
But, get_modes from panel returns me only the no_of_modes but
not the actual mode structure. How do I compare the list of supported
emulation modes?
Ajay
--
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 0/4] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled
Hi Bartlomiej, I tried to apply this patchset on top of next-20140708 but it does not apply. Do you have a more recent version ? Thanks in advance -- Daniel On 07/09/2014 07:17 PM, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series adds support for AFTR idle mode on boards with secure firmware enabled and allows EXYNOS cpuidle driver usage on Exynos4x12 SoCs. It has been tested on Trats2 board (using Exynos4412 SoC with secure firmware enabled) on which AFTR mode reduces power consumption by ~12% when EXYNOS cpuidle driver is enabled (in both cases the default exynos_defconfig config is used and CPU1-3 are offlined). v3: - rebased on top of next-20140708 + http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html (with rejects fixed) http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32808.html http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32991.html (with rejects fixed in patch #2) - addressed review comments from Tomasz Figa and Daniel Lezcano Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (4): ARM: EXYNOS: PM: replace EXYNOS_BOOT_VECTOR_* macros by static inlines ARM: EXYNOS: add AFTR mode support to firmware do_idle method ARM: EXYNOS: cpuidle: add secure firmware support to AFTR mode code ARM: EXYNOS: cpuidle: allow driver usage on Exynos4x12 SoCs arch/arm/include/asm/firmware.h | 2 +- arch/arm/mach-exynos/common.h| 7 ++- arch/arm/mach-exynos/exynos.c| 3 ++- arch/arm/mach-exynos/firmware.c | 36 ++-- arch/arm/mach-exynos/pm.c| 39 +-- drivers/cpuidle/cpuidle-exynos.c | 6 +++--- 6 files changed, 67 insertions(+), 26 deletions(-) -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay,
Am 30.07.2014 08:21, schrieb Ajay kumar:
On Tue, Jul 29, 2014 at 4:51 PM, Andreas Färber afaer...@suse.de wrote:
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Then, I think bridge chip is working fine.
You just need to configure the proper mode for FIMD.
You can see backlight also, right?
Do I need to specify a specific panel model for Spring?
Yes! Try using chunghwa,claa101wb01 as compatible string for
panel node.
With just your v6 applied plus updated DT patch (attached) [1], I see
backlight and a black screen (no white line any more). dmesg attached.
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
Ignore that regulator patch.
Also, please attach the bootlog if possible after trying this.
If I further apply the IOMMU patches [2], I get no backlight nor USB and
thus can't obtain a boot log.
Regards,
Andreas
[1] https://github.com/afaerber/linux/commits/spring-next
[2] https://github.com/afaerber/linux/commits/spring-bridge.v6
P.S. Note that your Snow DT patch will conflict with my Snow cleanups,
shuffling some nodes around: https://patchwork.kernel.org/patch/4649471/
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 64fdedabdfcfa5ac8ec97ab647ccfdd4520430d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 6d1d175e910e..8baad7ebe739 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -90,6 +90,10 @@
samsung,invert-vclk;
};
+ panel: panel {
+ compatible = chunghwa,claa101wb01;
+ };
+
dp-controller@145B {
status = okay;
pinctrl-names = default;
@@ -101,6 +105,7 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 1;
samsung,hpd-gpio = gpc3 0 GPIO_ACTIVE_HIGH;
+ bridge = ps8622;
};
};
@@ -405,6 +410,17 @@
status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
+
+ ps8622: lvds-bridge@08 {
+ compatible = parade,ps8622;
+ reg = 0x08;
+ sleep-gpios = gpc3 6 0;
+ reset-gpios = gpc3 1 0;
+ lane-count = 1;
+ panel = panel;
+ pinctrl-names = default;
+ pinctrl-0 = ps8622_gpios;
+ };
};
i2c_8 {
@@ -461,11 +477,18 @@
pinctrl_0 {
dp_hpd_gpio: dp-hpd-gpio {
samsung,pins = gpc3-0;
- samsung,pin-function = 1;
+ samsung,pin-function = 0;
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
+ ps8622_gpios: ps8622-gpios {
+ samsung,pins = gpc3-1, gpc3-6;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
s5m8767_dvs: s5m8767-dvs {
samsung,pins = gpd1-0, gpd1-1, gpd1-2;
samsung,pin-function = 0;
--
1.9.3
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.16.0-rc6+ (andr...@chrome11.site) (gcc version
4.8.2 20140404 [gcc-4_8-branch revision 209122] (SUSE Linux) ) #23 SMP PREEMPT
Wed Jul 30 20:11:19 CEST 2014
[0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=30c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] Machine model: Google Spring
[0.00] cma: CMA: reserved 64 MiB at 6b80
[0.00] Forcing write-allocate cache policy for SMP
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 523264
[0.00] free_area_init_node: node 0, pgdat c066b400, node_mem_map
ea7dc000
[0.00] Normal zone: 1520 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 194560 pages, LIFO batch:31
[0.00] HighMem zone: 2568 pages used for memmap
[0.00] HighMem zone: 328704 pages, LIFO batch:31
[0.00] PERCPU: Embedded 7
[PATCH v3] Documentation: devicetree: Fix tps65090 typos in example
Specification and existing device trees use vsys-l{1,2}-supply,
not vsys_l{1,2}-supply. Fix the example to match the specification.
Reviewed-by: Doug Anderson diand...@chromium.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Fixes: 21d2202158e9 (mfd: tps65090: add DT support for tps65090)
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2 - v3:
* Added Fixes header
* + regulator and mfd maintainers
v1 - v2:
* More verbose commit message (requested by Mark Rutland)
Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt
b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 340980239ea9..ca69f5e3040c 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -45,8 +45,8 @@ Example:
infet5-supply = some_reg;
infet6-supply = some_reg;
infet7-supply = some_reg;
- vsys_l1-supply = some_reg;
- vsys_l2-supply = some_reg;
+ vsys-l1-supply = some_reg;
+ vsys-l2-supply = some_reg;
regulators {
dcdc1 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very Urgent............
Greetings from gulf region Thanks for the e-mail. I am very interested on funding lucrative business partnership with you acting as the manager and sole controller of the investment while i remain a silent investor for a period of ten yrs , though I am only looking at investment opportunities within the range you specified for a start. You can reply me here (fmoris...@yahoo.com) Let me know your thought asap Regards Financial Consultant Mr.Fabian Morision -- 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/3] ARM: EXYNOS: Fix Exynos5410 boot
Hi, On Sun, Jul 27, 2014 at 5:39 PM, Kukjin Kim kgene@samsung.com wrote: Andreas Färber wrote: Am 27.07.2014 14:22, schrieb Andreas Färber: Hello, This mini-series unbreaks booting on 5410 based ODROID-XU. Since I do not have access to a TRM, the address is a guess based on 5250 and 5410. Such a node was not present in the 3.14 downstream tree. s/5410/5420/ OK. Regards, Andreas Andreas Färber (3): Documentation: devicetree: Document exynos5410 PMU ARM: dts: exynos: Add PMU to Exynos5410 ARM: EXYNOS: Add support for Exynos5410 PMU Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + arch/arm/boot/dts/exynos5410.dtsi | 5 + arch/arm/mach-exynos/exynos.c | 1 + 3 files changed, 7 insertions(+) Andreas, thanks. I'll apply this whole series. We're getting close to the merge window. I'd prefer not to have to start reverting samsung code to recover from these regressions, so please send this up very soon. -Olof -- 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/3] ARM: EXYNOS: Fix Exynos5410 boot
Olof Johansson wrote: Hi, Hi Olof, On Sun, Jul 27, 2014 at 5:39 PM, Kukjin Kim kgene@samsung.com wrote: Andreas Färber wrote: Am 27.07.2014 14:22, schrieb Andreas Färber: Hello, This mini-series unbreaks booting on 5410 based ODROID-XU. Since I do not have access to a TRM, the address is a guess based on 5250 and 5410. Such a node was not present in the 3.14 downstream tree. s/5410/5420/ OK. Regards, Andreas Andreas Färber (3): Documentation: devicetree: Document exynos5410 PMU ARM: dts: exynos: Add PMU to Exynos5410 ARM: EXYNOS: Add support for Exynos5410 PMU Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + arch/arm/boot/dts/exynos5410.dtsi | 5 + arch/arm/mach-exynos/exynos.c | 1 + 3 files changed, 7 insertions(+) Andreas, thanks. I'll apply this whole series. We're getting close to the merge window. I'd prefer not to have to start reverting samsung code to recover from these regressions, so please send this up very soon. Thanks for your gentle reminder. BTW I'm waiting for exynos5250-spring support from Andreas and I'd like to get confirmation about that from Doug. And I'm looking at s2r related patches now. OK, I will send out current samsung tree tonight in my time anyway. - Kukjin -- 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 v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
On Wed, Jul 30, 2014 at 4:58 PM, Andreas Färber afaer...@suse.de wrote:
Am 30.07.2014 10:07, schrieb Thomas Abraham:
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific cpufreq driver
to using generic cpufreq drivers.
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
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/boot/dts/exynos4210-origen.dts |4 +++
arch/arm/boot/dts/exynos4210-trats.dts |4 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts |4 +++
arch/arm/boot/dts/exynos4210.dtsi | 14 -
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.dtsi | 25 ++-
arch/arm/boot/dts/exynos5420.dtsi | 38
+++
9 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index f767c42..887dded 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -334,3 +334,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = buck1_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..66119dd 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -446,3 +446,7 @@
};
};
};
+
+cpu0 {
+ cpu0-supply = varm_breg;
+};
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3a..bf0a39c 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -492,3 +492,7 @@
mdma1 {
reg = 0x1284 0x1000;
};
+
+cpu0 {
+ cpu0-supply = vdd_arm_reg;
+};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63..69bac07 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,10 +35,22 @@
#address-cells = 1;
#size-cells = 0;
- cpu@900 {
+ cpu0: cpu@900 {
device_type = cpu;
compatible = arm,cortex-a9;
reg = 0x900;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 16;
+
+ operating-points =
+ 120 125
+ 100 115
+ 80 1075000
+ 50 975000
+ 40 975000
+ 20 95
Nit: Here you left-align the columns ...
+ ;
};
cpu@901 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
+
+
Re: [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Thomas,
On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham ta.oma...@gmail.com wrote:
Hi Doug,
On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham thomas...@samsung.com
wrote:
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
Where did the 14 number come from? My old calculations show that
with lock time of 270 ad P up to 6 we were at 67.5us lock time.
I measured the time taken by clk_set_rate call in the cpufreq driver
using do_gettimeofday(). The time taken to change the clock speed was
between 87us to 134us for Exynos5420. So I just took the worst case
time of 140us. Also, the time taken to change the CPU clock speed
includes the settling time for changes to dividers and mux clock
blocks.
Interesting. I wonder why the difference between my earlier
calculations. It seems just about double. :-/
+ 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
+ ;
};
cpu@1 {
device_type = cpu;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..3154b4c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,8 +59,26 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu-cluster.0;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
+
+ operating-points =
+ 180 125
+ 170 1212500
+ 160 1175000
+ 150 1137500
+ 140 1112500
+ 130 1062500
+ 120 1037500
+ 110 1012500
+ 100 987500
+90 962500
+80 937500
+70 912500
+ ;
};
cpu1: cpu@1 {
@@ -69,6 +87,7 @@
reg = 0x1;
clock-frequency = 18;
Re: [PATCH 0/3] ARM: EXYNOS: Fix Exynos5410 boot
Hi Kukjin, Am 31.07.2014 03:10, schrieb Kukjin Kim: Olof Johansson wrote: Hi, Hi Olof, On Sun, Jul 27, 2014 at 5:39 PM, Kukjin Kim kgene@samsung.com wrote: Andreas Färber wrote: Am 27.07.2014 14:22, schrieb Andreas Färber: Hello, This mini-series unbreaks booting on 5410 based ODROID-XU. Since I do not have access to a TRM, the address is a guess based on 5250 and 5410. Such a node was not present in the 3.14 downstream tree. s/5410/5420/ OK. Regards, Andreas Andreas Färber (3): Documentation: devicetree: Document exynos5410 PMU ARM: dts: exynos: Add PMU to Exynos5410 ARM: EXYNOS: Add support for Exynos5410 PMU Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + arch/arm/boot/dts/exynos5410.dtsi | 5 + arch/arm/mach-exynos/exynos.c | 1 + 3 files changed, 7 insertions(+) Andreas, thanks. I'll apply this whole series. We're getting close to the merge window. I'd prefer not to have to start reverting samsung code to recover from these regressions, so please send this up very soon. Thanks for your gentle reminder. BTW I'm waiting for exynos5250-spring support from Andreas and I'd like to get confirmation about that from Doug. And I'm looking at s2r related patches now. OK, I will send out current samsung tree tonight in my time anyway. That would be kind. Patches 2-3 in spring v3 should be non-functional snow refactorings for you to consider, but untested by me; patch 1 you could skip if you modify patch 2, if necessary. As for patch 4, you can see from my spring-next branch [1] how I am successfully testing it with a TEST_ONLY patch: For simplefb usage I comment out the /dp-controller node to avoid drm/exynos detection (not enabling the driver in the user's .config would be an alternative); when I run into issues with the drm during testing, I can usually ssh in via USB ethernet/wifi. In the dmesg for drm/exynos bridge series testing [2] (which I guess is not gonna hit 3.17 any more?) I noticed that the USB3503 /usb-hub node new in v3 is not working yet (complains about lack of #gpio-cells, I guess for my reset-gpios property), not sure how to fix, so we/you could probably just drop that node - preparing to test that now. As for the rest of patch 4, it's a new DT, so we could fix up any remaining bugs during 3.17 RC cycle, if it looks sane to you guys now. I had replied to two series - namely cpufreq [3] and dwmmc [4] - where merge conflicts might arise. Let me know if you need a respin for anything. Regards, Andreas [1] https://github.com/afaerber/linux/commits/spring-next [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34927.html [3] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34807.html [4] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34898.html -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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 v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
On Thu, Jul 31, 2014 at 9:23 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham ta.oma...@gmail.com wrote:
Hi Doug,
On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham thomas...@samsung.com
wrote:
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
Where did the 14 number come from? My old calculations show that
with lock time of 270 ad P up to 6 we were at 67.5us lock time.
I measured the time taken by clk_set_rate call in the cpufreq driver
using do_gettimeofday(). The time taken to change the clock speed was
between 87us to 134us for Exynos5420. So I just took the worst case
time of 140us. Also, the time taken to change the CPU clock speed
includes the settling time for changes to dividers and mux clock
blocks.
Interesting. I wonder why the difference between my earlier
calculations. It seems just about double. :-/
In your calculation, only the PLL lock time is being considered. But
the 140us latency is for the whole clk_set_rate() call.
+ 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
+ ;
};
cpu@1 {
device_type = cpu;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..3154b4c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,8 +59,26 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu-cluster.0;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
+
+ operating-points =
+ 180 125
+ 170 1212500
+ 160 1175000
+ 150 1137500
+ 140 1112500
+ 130 1062500
+ 120 1037500
+ 110 1012500
+ 100 987500
+90 962500
+80 937500
+70 912500
+
Re: [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Thomas,
On Wed, Jul 30, 2014 at 9:06 PM, Thomas Abraham ta.oma...@gmail.com wrote:
On Thu, Jul 31, 2014 at 9:23 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham ta.oma...@gmail.com wrote:
Hi Doug,
On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson diand...@chromium.org
wrote:
Thomas,
On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham thomas...@samsung.com
wrote:
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
Where did the 14 number come from? My old calculations show that
with lock time of 270 ad P up to 6 we were at 67.5us lock time.
I measured the time taken by clk_set_rate call in the cpufreq driver
using do_gettimeofday(). The time taken to change the clock speed was
between 87us to 134us for Exynos5420. So I just took the worst case
time of 140us. Also, the time taken to change the CPU clock speed
includes the settling time for changes to dividers and mux clock
blocks.
Interesting. I wonder why the difference between my earlier
calculations. It seems just about double. :-/
In your calculation, only the PLL lock time is being considered. But
the 140us latency is for the whole clk_set_rate() call.
+ 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
+ ;
};
cpu@1 {
device_type = cpu;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..3154b4c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,8 +59,26 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu-cluster.0;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
+
+ operating-points =
+ 180 125
+ 170 1212500
+ 160 1175000
+ 150 1137500
+ 140 1112500
+ 130 1062500
+ 120 1037500
+ 110 1012500
+ 100 987500
+90 962500
+
Re: [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
On Thu, Jul 31, 2014 at 9:38 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Jul 30, 2014 at 9:06 PM, Thomas Abraham ta.oma...@gmail.com wrote:
On Thu, Jul 31, 2014 at 9:23 AM, Doug Anderson diand...@chromium.org wrote:
Thomas,
On Wed, Jul 30, 2014 at 8:21 PM, Thomas Abraham ta.oma...@gmail.com wrote:
Hi Doug,
On Thu, Jul 31, 2014 at 6:07 AM, Doug Anderson diand...@chromium.org
wrote:
Thomas,
On Wed, Jul 30, 2014 at 1:07 AM, Thomas Abraham thomas...@samsung.com
wrote:
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..3b12a97 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -575,3 +575,7 @@
usb-phy = usb2_phy;
};
};
+
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index b4b35ad..f07e834 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -414,3 +414,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 f2b8c41..91acca7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -509,4 +509,8 @@
};
};
+cpu0 {
+ cpu0-supply = buck2_reg;
+};
+
#include cros-ec-keyboard.dtsi
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..97b282c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -58,11 +58,34 @@
#address-cells = 1;
#size-cells = 0;
- cpu@0 {
+ cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 14;
Where did the 14 number come from? My old calculations show that
with lock time of 270 ad P up to 6 we were at 67.5us lock time.
I measured the time taken by clk_set_rate call in the cpufreq driver
using do_gettimeofday(). The time taken to change the clock speed was
between 87us to 134us for Exynos5420. So I just took the worst case
time of 140us. Also, the time taken to change the CPU clock speed
includes the settling time for changes to dividers and mux clock
blocks.
Interesting. I wonder why the difference between my earlier
calculations. It seems just about double. :-/
In your calculation, only the PLL lock time is being considered. But
the 140us latency is for the whole clk_set_rate() call.
+ 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
+ ;
};
cpu@1 {
device_type = cpu;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..3154b4c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,8 +59,26 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu-cluster.0;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
+
+ operating-points =
+ 180 125
+ 170 1212500
+ 160 1175000
+ 150 1137500
+ 140 1112500
+ 130 1062500
+ 120 1037500
+ 110 1012500
+
Re: [RFC 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
Kukjin, Am 28.07.2014 14:18, schrieb Andreas Färber: Hello, This series adds a dedicated ODROID-XU device tree and enhances it with LED configuration, to match the downstream 3.14 based behavior. It had turned out less trivial than I initially thought as the whole pinctrl stuff is still missing. I thus cherry-pick two downstream commits. Hakjoo, can you please reply with a Signed-off-by to your patches so that we can get them into upstream? Thanks in advance! FTR, Hakjoo Kim did reply with signed off patches (thanks again!) and updated their branch accordingly: https://github.com/hardkernel/linux/commits/odroid-3.14.y-linaro https://github.com/hardkernel/linux/commit/53edc3da0d1da287517681b47daf36679637b6ba https://github.com/hardkernel/linux/commit/afdc310e47e4d1799719566bfb5a47c55141a7cb Andreas Färber (3): ARM: dts: exynos5410: Clean up SMDK5410 indentation ARM: dts: exynos5410: Prepare ODROID-XU device tree The functional changes below haven't been reviewed yet, but could you consider applying trivial patches 1-2? Regards, Andreas ARM: dts: exynos5410: Add ODROID-XU LEDs Hakjoo Kim (2): pinctrl: exynos: add exynos5410 SoC specific data ARM: dts: add pinctrl support to Exynos5410 .../bindings/pinctrl/samsung-pinctrl.txt | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/exynos5410-odroidxu.dts | 111 ++ arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 408 + arch/arm/boot/dts/exynos5410-smdk5410.dts | 6 +- arch/arm/boot/dts/exynos5410.dtsi | 32 ++ drivers/pinctrl/pinctrl-exynos.c | 126 +++ drivers/pinctrl/pinctrl-samsung.c | 2 + drivers/pinctrl/pinctrl-samsung.h | 1 + 9 files changed, 685 insertions(+), 3 deletions(-) create mode 100644 arch/arm/boot/dts/exynos5410-odroidxu.dts create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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
[PATCHv9 5/5] ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Reviewed-by: Heiko Stuebner he...@sntech.de
Acked-by: Seungwon Jeon tgih@samsung.com
---
arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index afb3273..ecea889 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -59,12 +59,8 @@
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_cd sd0_bus4;
vmmc-supply = vcc_sd0;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
dwmmc@10218000 { /* wifi */
@@ -74,12 +70,8 @@
pinctrl-names = default;
pinctrl-0 = sd1_clk sd1_cmd sd1_bus4;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- disable-wp;
- };
+ bus-width = 4;
+ disable-wp;
};
gpio-keys {
--
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
[PATCHv9 4/5] ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Dinh Nguyen dingu...@altera.com
---
arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_cyclone5.dtsi |9 +++--
arch/arm/boot/dts/socfpga_vt.dts|9 +++--
3 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi
b/arch/arm/boot/dts/socfpga_arria5.dtsi
index 12d1c2c..468fc4c 100644
--- a/arch/arm/boot/dts/socfpga_arria5.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
@@ -29,13 +29,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
sysmgr@ffd08000 {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index bf51182..1ee03c4 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -30,13 +30,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff702000 {
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 09792b4..f9345e0 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -43,13 +43,10 @@
dwmmc0@ff704000 {
num-slots = 1;
- supports-highspeed;
broken-cd;
-
- slot@0 {
- reg = 0;
- bus-width = 4;
- };
+ bus-width = 4;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
ethernet@ff70 {
--
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
[PATCHv9 3/5] ARM: dts: exynos: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
dw-mmc controller can support multiple slots.
But, there are no use-cases anywhere. So we don't need to support the
slot-node for dw-mmc controller.
And supports-highspeed property in dw-mmc is deprecated.
supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Reviewed-by: Tushar Behera trbli...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++--
arch/arm/boot/dts/exynos4412-origen.dts |8 ++--
arch/arm/boot/dts/exynos4412-trats2.dts |8 ++--
arch/arm/boot/dts/exynos5250-arndale.dts | 18 +
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 +++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 +
arch/arm/boot/dts/exynos5250-snow.dts |6 ++
arch/arm/boot/dts/exynos5260-xyref5260.dts| 18 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 +
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 ---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 16 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 ---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 ---
13 files changed, 51 insertions(+), 141 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..778aec6 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -45,17 +45,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
regulator_p3v3 {
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e925c9f..de15114 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -137,17 +137,13 @@
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
codec@1340 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 7787844..65ab885 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -520,7 +520,6 @@
mmc@1255 {
num-slots = 1;
- supports-highspeed;
broken-cd;
non-removable;
card-detect-delay = 200;
@@ -532,11 +531,8 @@
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
status = okay;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
serial@1380 {
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f5..42a3590 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -401,7 +401,6 @@
mmc_0: mmc@1220 {
status = okay;
num-slots = 1;
- supports-highspeed;
broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -410,17 +409,13 @@
vmmc-supply = mmc_reg;
pinctrl-names = default;
pinctrl-0 = sd0_clk sd0_cmd sd0_bus4 sd0_bus8;
-
- slot@0 {
- reg = 0;
- bus-width = 8;
- };
+ bus-width = 8;
+ cap-mmc-highspeed;
};
mmc_2: mmc@1222 {
status = okay;
num-slots = 1;
- supports-highspeed;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -428,12
[PATCHv9 1/5] mmc: dw_mmc: Slot quirk disable-wp is deprecated.
Slot quirks disable-wp is deprecated.
Instead, use the host quirk disable-wp.
(Because the slot-node is removed in dt-file.)
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Tested-by: Sachin Kamat sachin.ka...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/host/dw_mmc.c | 11 +--
include/linux/mmc/dw_mmc.h |2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..47b52cc 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -997,7 +997,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
int gpio_ro = mmc_gpio_get_ro(mmc);
/* Use platform get_ro function, else try on board write protect */
- if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
+ if ((slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) ||
+ (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (!IS_ERR_VALUE(gpio_ro))
read_only = gpio_ro;
@@ -2021,8 +2022,11 @@ static int dw_mci_of_get_slot_quirks(struct device *dev,
u8 slot)
/* get quirks */
for (idx = 0; idx ARRAY_SIZE(of_slot_quirks); idx++)
- if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL)) {
+ dev_warn(dev, Slot quirk %s is deprecated\n,
+ of_slot_quirks[idx].quirk);
quirks |= of_slot_quirks[idx].id;
+ }
return quirks;
}
@@ -2238,6 +2242,9 @@ static struct dw_mci_of_quirks {
{
.quirk = broken-cd,
.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
+ }, {
+ .quirk = disable-wp,
+ .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
},
};
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index babaea9..29ce014 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -213,6 +213,8 @@ struct dw_mci_dma_ops {
#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
/* Unreliable card detection */
#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
+/* No write protect */
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT BIT(4)
/* Slot level quirks */
/* This slot has no write protect */
--
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
[PATCHv9 0/5] ARM: remove the sub-node and deprecate supports-highspeed property for dwmmc.
Since used the mmc_of_parse(), didn't parse the sub-node. So we can remove the sub-node, because almost SoC used the only one card per a host. And supports-highspeed can be replaced with cap-mmc/sd-highspeed property. Changelog V9: - Fix typos. - Relocated the warning message. - Change patch's sequence. Changelog V8: - Add the warning message to notice that slot-node was removed. (As Doug's suggestion) Changelog V7: - Fixed typo and modified the commit message. Changelog V6: - Fixed Wrong bit control for host's quirks and rename. - Add Acked-by for each SoC maintainers. Changelog V5: - Rebased on v3.16-rc4. - Add Acked-by. Changelog V4: - Fix the checkpatch error. Changelog V3: - Fix the wrong bus-width value. - Use the slot-host-quirks instead of brq-quirks. - Add tested-by and reviewd-by. Changelog V2: - Add the mmc: dw_mmc: replace disable-wp from slot's quirks to host's quirk Jaehoon Chung (5): mmc: dw_mmc: Slot quirk disable-wp is deprecated. mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed ARM: dts: exynos: unuse the slot-node and deprecate the supports-highspeed for dw-mmc ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 17 - .../devicetree/bindings/mmc/k3-dw-mshc.txt | 12 - .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 12 - arch/arm/boot/dts/exynos4412-odroidx.dts |8 ++ arch/arm/boot/dts/exynos4412-origen.dts|8 ++ arch/arm/boot/dts/exynos4412-trats2.dts|8 ++ arch/arm/boot/dts/exynos5250-arndale.dts | 18 -- arch/arm/boot/dts/exynos5250-cros-common.dtsi | 26 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 18 -- arch/arm/boot/dts/exynos5250-snow.dts |6 ++--- arch/arm/boot/dts/exynos5260-xyref5260.dts | 18 -- arch/arm/boot/dts/exynos5410-smdk5410.dts | 18 -- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 16 +++- arch/arm/boot/dts/exynos5420-peach-pit.dts | 16 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 16 +++- arch/arm/boot/dts/exynos5800-peach-pi.dts | 16 +++- arch/arm/boot/dts/rk3066a-bqcurie2.dts | 16 +++- arch/arm/boot/dts/socfpga_arria5.dtsi |9 +++ arch/arm/boot/dts/socfpga_cyclone5.dtsi|9 +++ arch/arm/boot/dts/socfpga_vt.dts |9 +++ drivers/mmc/host/dw_mmc.c | 11 +++-- include/linux/mmc/dw_mmc.h |2 ++ 22 files changed, 90 insertions(+), 199 deletions(-) -- 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] ARM: exynos_defconfig: Enable PL330 DMA
We are getting a system hang on Arndale-Octa board if PL330_DMA is not enabled. The issue is related to [1]. AUDSS block provides the clock for audio DMA controller. Any operation on this clock requires that the clock to AUDSS block be enabled. In current configuration, the clock is gated during late boot process when all unused clocks are disabled. When PL330_DMA is enabled, the 'apb_pclk' is enabled/disabled during amba_probe(). Otherwise, this clock is also disabled during late boot. If the AUDSS block clock is disabled by then, we get a system hang. [1] https://lkml.org/lkml/2014/6/11/32 Signed-off-by: Tushar Behera tusha...@samsung.com --- arch/arm/configs/exynos_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e07a227..c5888e8 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -109,6 +109,8 @@ CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_S3C=y +CONFIG_DMADEVICES=y +CONFIG_PL330_DMA=y CONFIG_COMMON_CLK_MAX77686=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y -- 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
