[PATCH] drm/exynos: fix exynos_drm_component_del
This patch resolves the issue that component object isn't removed correctly. A given component object couldn't be placed to head of drm_component_list so all component objects added to the drm_component_list should be checked to remove the given component object. Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index c5cb8b6..0e4813b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -473,8 +473,6 @@ void exynos_drm_component_del(struct device *dev, list_del(cdev-list); kfree(cdev); } - - break; } mutex_unlock(drm_component_lock); -- 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 v6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver
Let's handle i2c interrupt re-configuration in i2c driver. This will
help us in removing some soc specific checks from machine files and
will help in removing static iomapping of SYS register in exynos.c
Also handle saving and restoring of SYS_I2C_CFG register during
suspend and resume of i2c driver.
CC: Wolfram Sang w...@the-dreams.de
CC: linux-...@vger.kernel.org
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
This patch is created from following patch series V5(1/2).
https://patchwork.kernel.org/patch/5354131/
DT and machine (mach-exynos) changes will be posted separately.
drivers/i2c/busses/i2c-s3c2410.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 6524477..09a6bac 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -35,6 +35,8 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/pinctrl/consumer.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include asm/irq.h
@@ -87,6 +89,9 @@
/* Max time to wait for bus to become idle after a xfer (in us) */
#define S3C2410_IDLE_TIMEOUT 5000
+/* Exynos5 Sysreg offset */
+#define EXYNOS5_SYS_I2C_CFG0x0234
+
/* i2c controller state */
enum s3c24xx_i2c_state {
STATE_IDLE,
@@ -123,6 +128,8 @@ struct s3c24xx_i2c {
#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
struct notifier_block freq_transition;
#endif
+ struct regmap *sysreg;
+ unsigned intsys_i2c_cfg;
};
static struct platform_device_id s3c24xx_driver_ids[] = {
@@ -1071,6 +1078,7 @@ static void
s3c24xx_i2c_parse_dt(struct device_node *np, struct s3c24xx_i2c *i2c)
{
struct s3c2410_platform_i2c *pdata = i2c-pdata;
+ int id;
if (!np)
return;
@@ -1080,6 +1088,21 @@ s3c24xx_i2c_parse_dt(struct device_node *np, struct
s3c24xx_i2c *i2c)
of_property_read_u32(np, samsung,i2c-slave-addr, pdata-slave_addr);
of_property_read_u32(np, samsung,i2c-max-bus-freq,
(u32 *)pdata-frequency);
+ /*
+* Exynos5's legacy i2c controller and new high speed i2c
+* controller have muxed interrupt sources. By default the
+* interrupts for 4-channel HS-I2C controller are enabled.
+* If nodes for first four channels of legacy i2c controller
+* are available then re-configure the interrupts via the
+* system register.
+*/
+ id = of_alias_get_id(np, i2c);
+ i2c-sysreg = syscon_regmap_lookup_by_phandle(np,
+ samsung,sysreg-phandle);
+ if (IS_ERR(i2c-sysreg))
+ return;
+
+ regmap_update_bits(i2c-sysreg, EXYNOS5_SYS_I2C_CFG, BIT(id), 0);
}
#else
static void
@@ -1260,6 +1283,9 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
i2c-suspended = 1;
+ if (!IS_ERR(i2c-sysreg))
+ regmap_read(i2c-sysreg, EXYNOS5_SYS_I2C_CFG,
i2c-sys_i2c_cfg);
+
return 0;
}
@@ -1268,6 +1294,9 @@ static int s3c24xx_i2c_resume_noirq(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
+ if (!IS_ERR(i2c-sysreg))
+ regmap_write(i2c-sysreg, EXYNOS5_SYS_I2C_CFG,
i2c-sys_i2c_cfg);
+
clk_prepare_enable(i2c-clk);
s3c24xx_i2c_init(i2c);
clk_disable_unprepare(i2c-clk);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12
Hi Kukjin,
Lukasz Majewski wrote:
+ Bart, Tomasz and MLs
Hi Lukasz,
Please post including MLs, even resending.
Will apply for v3.19, and just note that you asked me to apply this
for 3.18 in personal talk but I couldn't see any requirements for
fixes-3.18. If I'm missing something, please let me know.
The thing is that by default Exynos 4412 (trats2) can run with modified
cpufreq to support SW governed overclocking (BOOST).
To provide safe BOOST operation, TMU (thermal) _must_ be configured.
Configuration is not possible when trats2 DTS lacks of those patches.
So, yes there is a requirement to add those patches to v3.18 (if not
possible please add it to v3.19).
Thanks,
Kukjin
The TMU device tree node definition for Exynos4x12 family of SoCs.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Reviewed-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi index 861bb91..2e9f1f7 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -271,4 +271,14 @@
compatible = samsung,exynos4x12-usb2-phy;
samsung,sysreg-phandle = sys_reg;
};
+
+ tmu@100C {
+ compatible = samsung,exynos4412-tmu;
+ interrupt-parent = combiner;
+ interrupts = 2 4;
+ reg = 0x100C 0x100;
+ clocks = clock 383;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
};
--
2.0.0.rc2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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 v6 2/2] ARM: EXYNOS: Remove i2c sys configuration related code
As all these code has been moved into i2c driver, now we can
safely remove them from machine files.
CC: Russell King li...@arm.linux.org.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 39 ++-
arch/arm/mach-exynos/include/mach/map.h |3 ---
arch/arm/mach-exynos/pm.c |3 ++-
arch/arm/mach-exynos/regs-sys.h | 22 -
arch/arm/mach-exynos/suspend.c |7 --
5 files changed, 4 insertions(+), 70 deletions(-)
delete mode 100644 arch/arm/mach-exynos/regs-sys.h
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c13d083..2c84439 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -27,20 +27,16 @@
#include asm/mach/map.h
#include asm/memory.h
+#include mach/map.h
+
#include common.h
#include mfc.h
#include regs-pmu.h
-#include regs-sys.h
void __iomem *pmu_base_addr;
static struct map_desc exynos4_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S3C_VA_SYS,
- .pfn= __phys_to_pfn(EXYNOS4_PA_SYSCON),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_SROMC,
.pfn= __phys_to_pfn(EXYNOS4_PA_SROMC),
.length = SZ_4K,
@@ -70,11 +66,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
static struct map_desc exynos5_iodesc[] __initdata = {
{
- .virtual= (unsigned long)S3C_VA_SYS,
- .pfn= __phys_to_pfn(EXYNOS5_PA_SYSCON),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_SROMC,
.pfn= __phys_to_pfn(EXYNOS5_PA_SROMC),
.length = SZ_4K,
@@ -213,32 +204,6 @@ static void __init exynos_init_irq(void)
static void __init exynos_dt_machine_init(void)
{
- struct device_node *i2c_np;
- const char *i2c_compat = samsung,s3c2440-i2c;
- unsigned int tmp;
- int id;
-
- /*
-* Exynos5's legacy i2c controller and new high speed i2c
-* controller have muxed interrupt sources. By default the
-* interrupts for 4-channel HS-I2C controller are enabled.
-* If node for first four channels of legacy i2c controller
-* are available then re-configure the interrupts via the
-* system register.
-*/
- if (soc_is_exynos5()) {
- for_each_compatible_node(i2c_np, NULL, i2c_compat) {
- if (of_device_is_available(i2c_np)) {
- id = of_alias_get_id(i2c_np, i2c);
- if (id 4) {
- tmp = readl(EXYNOS5_SYS_I2C_CFG);
- writel(tmp ~(0x1 id),
- EXYNOS5_SYS_I2C_CFG);
- }
- }
- }
- }
-
/*
* This is called from smp_prepare_cpus if we've built for SMP, but
* we still need to set it up for PM and firmware ops if not.
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 1ad3f49..de3ae59 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -24,9 +24,6 @@
#define EXYNOS_PA_CHIPID 0x1000
-#define EXYNOS4_PA_SYSCON 0x1001
-#define EXYNOS5_PA_SYSCON 0x10050100
-
#define EXYNOS4_PA_CMU 0x1003
#define EXYNOS5_PA_CMU 0x1001
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 86f3ecd..dfc8594 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -23,12 +23,13 @@
#include asm/smp_scu.h
#include asm/suspend.h
+#include mach/map.h
+
#include plat/pm-common.h
#include common.h
#include exynos-pmu.h
#include regs-pmu.h
-#include regs-sys.h
static inline void __iomem *exynos_boot_vector_addr(void)
{
diff --git a/arch/arm/mach-exynos/regs-sys.h b/arch/arm/mach-exynos/regs-sys.h
deleted file mode 100644
index 84332b0..000
--- a/arch/arm/mach-exynos/regs-sys.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS - system register definition
- *
- * 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.
-*/
-
-#ifndef __ASM_ARCH_REGS_SYS_H
-#define __ASM_ARCH_REGS_SYS_H __FILE__
-
-#include mach/map.h
-
-#define S5P_SYSREG(x) (S3C_VA_SYS + (x))
[PATCH v6 1/2] i2c: s3c2410: add Sysreg phandle to i2c device nodes
This patch adds syscon based phandle to i2c device nodes of exynos5250 and exynos5420. These phandles will be used to save restore i2c sysreg configuration register during s2r from i2c driver. CC: Rob Herring robh...@kernel.org CC: Randy Dunlap rdun...@infradead.org CC: Russell King li...@arm.linux.org.uk CC: devicet...@vger.kernel.org CC: linux-...@vger.kernel.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- .../devicetree/bindings/i2c/i2c-s3c2410.txt|1 + arch/arm/boot/dts/exynos5250.dtsi |4 arch/arm/boot/dts/exynos5420.dtsi |4 3 files changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt index 278de8e..89b3250 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt @@ -32,6 +32,7 @@ Optional properties: specified, default value is 0. - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not specified, the default value in Hz is 10. + - samsung,sysreg-phandle - handle to syscon used to control the system registers Example: diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 0a588b4..d45a07e 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -293,6 +293,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c0_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; @@ -306,6 +307,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c1_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; @@ -319,6 +321,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c2_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; @@ -332,6 +335,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c3_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 8617a03..90bf401 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -560,6 +560,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c0_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; @@ -573,6 +574,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c1_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; @@ -586,6 +588,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c2_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; @@ -599,6 +602,7 @@ clock-names = i2c; pinctrl-names = default; pinctrl-0 = i2c3_bus; + samsung,sysreg-phandle = sysreg_system_controller; status = disabled; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver
On Saturday 22 November 2014 06:18 AM, Kukjin Kim wrote: Wolfram Sang wrote: Hi Wolfram, I usually don't take DTS patches. They should go via arm-soc. Please say so if there are reasons I should take them. I CC'ed to you because same patch contains changes in i2c driver. Yes, those should absolutely go via my I2C tree. You need to make a seperate patch out of the dts changes which then also should go via samsung-soc, unless Kukjin says he really wants to go the via I2C. But I guess the latter will just create merge conflicts. Hmm...I think, Pankaj needs to submit separated patches 1) driver change, 2) dt change and then 3) remove change. And 2nd and 3rd changes should be handed in Samsung tree together after landing 1) change in -next. Of course, 1) change should be handled in i2c tree ;) Thanks for review and guidance. I separated i2c driver changes and posted it as v6 here [1]. DT changes and mach-exynos removal of i2c settings have been posted as v6 here [2]. Please do review and if OK let's get it merged. [1]: i2c-driver: https://patchwork.kernel.org/patch/5363981/ [2]: mach-exynos: http://comments.gmane.org/gmane.linux.kernel.samsung-soc/40155 Thanks, Pankaj Dubey Thanks, 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
drm/exynos: vidi: add component support
This patch adds component support for vidi driver.
vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.
This patch fixes below error also,
# echo 1 /sys/devices/platform/exynos-drm-vidi/connection
[ 55.618529] [ cut here ]
[ 55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203
exynos_drm_crtc_dpms+0x88/0x17c()
[ 55.631268] Modules linked in:
[ 55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7
#1154
[ 55.641885] [c0014400] (unwind_backtrace) from [c0011570]
(show_stack+0x10/0x14)
[ 55.649597] [c0011570] (show_stack) from [c04764f4]
(dump_stack+0x84/0xc4)
[ 55.656802] [c04764f4] (dump_stack) from [c00218b8]
(warn_slowpath_common+0x6c/0x88)
[ 55.664866] [c00218b8] (warn_slowpath_common) from [c0021970]
(warn_slowpath_null+0x1c/0x24)
[ 55.673632] [c0021970] (warn_slowpath_null) from [c027a780]
(exynos_drm_crtc_dpms+0x88/0x17c)
[ 55.682482] [c027a780] (exynos_drm_crtc_dpms) from [c027a910]
(exynos_drm_crtc_commit+0x14/0x44)
[ 55.691622] [c027a910] (exynos_drm_crtc_commit) from [c025521c]
(drm_crtc_helper_set_mode+0x3d0/0x51c)
[ 55.701233] [c025521c] (drm_crtc_helper_set_mode) from [c0255d68]
(drm_crtc_helper_set_config+0x87c/0x9dc)
[ 55.711230] [c0255d68] (drm_crtc_helper_set_config) from [c026afa8]
(drm_mode_set_config_internal+0x58/0xd4)
[ 55.721380] [c026afa8] (drm_mode_set_config_internal) from [c025c208]
(restore_fbdev_mode+0xcc/0xec)
[ 55.730834] [c025c208] (restore_fbdev_mode) from [c025c244]
(drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[ 55.741424] [c025c244] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[c025e0a8] (drm_fb_helper_set_par+0x1c/0x60)
[ 55.752271] [c025e0a8] (drm_fb_helper_set_par) from [c025e174]
(drm_fb_helper_hotplug_event+0x88/0xc4)
[ 55.761906] [c025e174] (drm_fb_helper_hotplug_event) from [c02571c4]
(drm_helper_hpd_irq_event+0xc8/0x134)
[ 55.771898] [c02571c4] (drm_helper_hpd_irq_event) from [c028e27c]
(vidi_store_connection+0x90/0xc8)
[ 55.781268] [c028e27c] (vidi_store_connection) from [c0125f80]
(kernfs_fop_write+0xc0/0x180)
[ 55.790045] [c0125f80] (kernfs_fop_write) from [c00cdf60]
(vfs_write+0xa0/0x1ac)
[ 55.797757] [c00cdf60] (vfs_write) from [c00ce468] (SyS_write+0x44/0x9c)
[ 55.804790] [c00ce468] (SyS_write) from [c000e6a0]
(ret_fast_syscall+0x0/0x30)
[ 55.812328] ---[ end trace 3c0fe4386702d4dd ]---
This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 61 ++
1 file changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3b6fdd6..45899fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@
#include linux/kernel.h
#include linux/platform_device.h
+#include linux/component.h
#include drm/exynos_drm.h
@@ -48,11 +49,11 @@ struct vidi_win_data {
struct vidi_context {
struct exynos_drm_manager manager;
struct exynos_drm_display display;
+ struct platform_device *pdev;
struct drm_device *drm_dev;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connectorconnector;
- struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -560,9 +561,10 @@ static struct exynos_drm_display_ops vidi_display_ops = {
.create_connector = vidi_create_connector,
};
-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
{
struct vidi_context *ctx = dev_get_drvdata(dev);
+ struct drm_device *drm_dev = data;
struct drm_crtc *crtc = ctx-crtc;
int ret;
@@ -584,9 +586,18 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
+
+static void vidi_unbind(struct device *dev, struct device *master, void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+ .bind = vidi_bind,
+ .unbind = vidi_unbind,
+};
+
static int vidi_probe(struct platform_device *pdev)
{
- struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;
@@ -599,6 +610,17 @@
[PATCH] drm/exynos: vidi: add component support
This patch adds component support for vidi driver.
vidi driver is a kms driver so it doesn't need to be registered
to exynos_drm_subdrv_list. For this, it changes for the component
framework to be used for vidi driver.
This patch fixes below error also,
# echo 1 /sys/devices/platform/exynos-drm-vidi/connection
[ 55.618529] [ cut here ]
[ 55.621960] WARNING: CPU: 0 PID: 1397 at drivers/gpu/drm/drm_irq.c:1203
exynos_drm_crtc_dpms+0x88/0x17c()
[ 55.631268] Modules linked in:
[ 55.634278] CPU: 0 PID: 1397 Comm: sh Not tainted 3.18.0-rc2-146253-g31449d7
#1154
[ 55.641885] [c0014400] (unwind_backtrace) from [c0011570]
(show_stack+0x10/0x14)
[ 55.649597] [c0011570] (show_stack) from [c04764f4]
(dump_stack+0x84/0xc4)
[ 55.656802] [c04764f4] (dump_stack) from [c00218b8]
(warn_slowpath_common+0x6c/0x88)
[ 55.664866] [c00218b8] (warn_slowpath_common) from [c0021970]
(warn_slowpath_null+0x1c/0x24)
[ 55.673632] [c0021970] (warn_slowpath_null) from [c027a780]
(exynos_drm_crtc_dpms+0x88/0x17c)
[ 55.682482] [c027a780] (exynos_drm_crtc_dpms) from [c027a910]
(exynos_drm_crtc_commit+0x14/0x44)
[ 55.691622] [c027a910] (exynos_drm_crtc_commit) from [c025521c]
(drm_crtc_helper_set_mode+0x3d0/0x51c)
[ 55.701233] [c025521c] (drm_crtc_helper_set_mode) from [c0255d68]
(drm_crtc_helper_set_config+0x87c/0x9dc)
[ 55.711230] [c0255d68] (drm_crtc_helper_set_config) from [c026afa8]
(drm_mode_set_config_internal+0x58/0xd4)
[ 55.721380] [c026afa8] (drm_mode_set_config_internal) from [c025c208]
(restore_fbdev_mode+0xcc/0xec)
[ 55.730834] [c025c208] (restore_fbdev_mode) from [c025c244]
(drm_fb_helper_restore_fbdev_mode_unlocked+0x1c/0x30)
[ 55.741424] [c025c244] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[c025e0a8] (drm_fb_helper_set_par+0x1c/0x60)
[ 55.752271] [c025e0a8] (drm_fb_helper_set_par) from [c025e174]
(drm_fb_helper_hotplug_event+0x88/0xc4)
[ 55.761906] [c025e174] (drm_fb_helper_hotplug_event) from [c02571c4]
(drm_helper_hpd_irq_event+0xc8/0x134)
[ 55.771898] [c02571c4] (drm_helper_hpd_irq_event) from [c028e27c]
(vidi_store_connection+0x90/0xc8)
[ 55.781268] [c028e27c] (vidi_store_connection) from [c0125f80]
(kernfs_fop_write+0xc0/0x180)
[ 55.790045] [c0125f80] (kernfs_fop_write) from [c00cdf60]
(vfs_write+0xa0/0x1ac)
[ 55.797757] [c00cdf60] (vfs_write) from [c00ce468] (SyS_write+0x44/0x9c)
[ 55.804790] [c00ce468] (SyS_write) from [c000e6a0]
(ret_fast_syscall+0x0/0x30)
[ 55.812328] ---[ end trace 3c0fe4386702d4dd ]---
This issue occurs when modeset to vidi is tried in case that drm_vblank_init
is called prior to crtc creation of vidi driver. In this case, crtc number
of vidi is invalid so any requests with the crtc number will fail.
This patch guarantees drm_vblank_init to be called after all kms drivers
are ready by using component framework.
Signed-off-by: Inki Dae inki@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 61 ++
1 file changed, 45 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 3b6fdd6..45899fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@
#include linux/kernel.h
#include linux/platform_device.h
+#include linux/component.h
#include drm/exynos_drm.h
@@ -48,11 +49,11 @@ struct vidi_win_data {
struct vidi_context {
struct exynos_drm_manager manager;
struct exynos_drm_display display;
+ struct platform_device *pdev;
struct drm_device *drm_dev;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connectorconnector;
- struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -560,9 +561,10 @@ static struct exynos_drm_display_ops vidi_display_ops = {
.create_connector = vidi_create_connector,
};
-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
{
struct vidi_context *ctx = dev_get_drvdata(dev);
+ struct drm_device *drm_dev = data;
struct drm_crtc *crtc = ctx-crtc;
int ret;
@@ -584,9 +586,18 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
+
+static void vidi_unbind(struct device *dev, struct device *master, void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+ .bind = vidi_bind,
+ .unbind = vidi_unbind,
+};
+
static int vidi_probe(struct platform_device *pdev)
{
- struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;
@@ -599,6 +610,17 @@
Re: screen blank causing lockup in exynos-reference/exynos5-v3.18-rc2
Hi Kevin, On Sat, Nov 22, 2014 at 12:53 AM, Kevin Hilman khil...@kernel.org wrote: Hi Ajay, AJAY KUMAR RAMAKRISHNA SHYMALAMMA ajaykumar...@samsung.com writes: I tried to reproduce the issue which you reported, but I am sorry I am not able to reproduce it. I tried with my patches for DRM on top of Linux-next. I don't see the issue on linux-next either. As I mentioned in the original post, I only see it on the v3.18 branch in the exynos-reference tree. While checking the issue along with Ajay on exynos5-v3.18-rc2 branch on exynos-reference tree, we found out the culprit to be FIMD-SYSMMU. The IOMMU on exynos systems is still WIP, and that's the reason it is disabled in exynos_defconfig too. So we have a small workaround in this branch to stop using FIMD-SYSMMUs. Now, at the bootup time things are OK, since the FIMD-SMMU clocks (CLK_SMMU_FIMD**) are still available. But after bootup all unused clocks are disabled (since we don't want to use clk_ignore_unused in boot arguments), and the consequent blanking-unblanking causes the system to hang. So we have pushed a patch on the same branch exynos5-v3.18-rc2 which sets CLK_IGNORE_UNUSED flag for these SMMU_FIMD** clocks. This fixes the issue of hang what we were seeing. There's another branch exynos5-v3.18-rc5 available, and we have pushed the same patch on that branch too. Please test on your side, and do let us know if things are working fine for you. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Sun, Nov 23, 2014 at 12:26 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: Hello Vivek On Wed, Nov 19, 2014 at 1:03 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Thanks for testing. You are welcome Kukjin, Sorry for not adding Kukjin to the list and thereby for the delay about this patch. No worries but I'm not sure if Kukjin is aware of this patch. I see he has been applying other patches but didn't pick $subject. Right, Maybe you can resend it to Kukjin just to be sure he will have it in his mailbox? Posted a RESEND version of this patch. Thanks again for noticing. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver
On Mon, Nov 24, 2014 at 02:03:38PM +0530, Pankaj Dubey wrote: Let's handle i2c interrupt re-configuration in i2c driver. This will help us in removing some soc specific checks from machine files and will help in removing static iomapping of SYS register in exynos.c Also handle saving and restoring of SYS_I2C_CFG register during suspend and resume of i2c driver. CC: Wolfram Sang w...@the-dreams.de CC: linux-...@vger.kernel.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Applied to for-next, thanks! signature.asc Description: Digital signature
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
Hell Krzysztof, On 11/22/2014 11:21 AM, Krzysztof Kozlowski wrote: By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? Oh crap... I'll look at it on Monday. However I don't have Peach Pi so any information would be useful. Can you post dmesg and your config? (is it exynos_defconfig?) Yes, I'm using exynos_defconfig. I'm testing with latest linux-next, HEAD: commit ed6778a (Add linux-next specific files for 20141121) The boot log of the hang in the Exynos5420 Peach Pit is sent as an attachment. CONFIG_SND_SOC_SNOW was enabled and without clk_ignore_unused. Additionally can you boot the board with DMATEST enabled (without reverting my commit so probably with clk_ignore_unsed and with SND_SNOW disabled) and run dmatest on all channels? Something like: echo 2000 /sys/module/dmatest/parameters/timeout echo 2 /sys/module/dmatest/parameters/iterations for i in `ls /sys/class/dma/` do echo $i /sys/module/dmatest/parameters/channel echo 1 /sys/module/dmatest/parameters/run done ... and post these results also. I'm attaching the log of the tests as well. To run the test CONFIG_SND_SOC_SNOW was disabled and booted with clk_ignore_unused. I will test it on Arndale Octa, maybe the cause is the same. Unfortunately it seems Arndale Octa does not have any sound enabled in DTS so it may be hard to test I2S bus (which is used by audio). Ok, please let me know if you need anything else from me. Best regards, Krzysztof Best regards, Javier U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach CPU:Exynos5420@1800MHz Board: Google Peach Pit, rev 9.0 I2C: ready DRAM: 2 GiB PMIC max77802-pmic initialized CPU:Exynos5420@1800MHz TPS65090 PMIC EC init MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB In:cros-ec-keyb Out: lcd Err: lcd SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB ELOG: Event(17) added with size 13 Net: No ethernet found. Hit any key to stop autoboot: 0 reading uImage 3336553 bytes read in 163 ms (19.5 MiB/s) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux Created: 2014-11-24 8:30:31 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3336489 Bytes = 3.2 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... Timer summary in microseconds: MarkElapsed Stage 0 0 reset 3,471,164 3,471,164 board_init_f 3,567,283 96,119 board_init_r 3,712,040144,757 id=64 3,714,761 2,721 main_loop 4,063,547348,786 bootm_start 4,063,549 2 id=1 4,069,252 5,703 id=2 4,069,254 2 id=3 4,123,769 54,515 id=4 4,123,770 1 id=5 4,123,772 2 id=6 4,123,773 1 id=14 4,225,455101,682 id=7 4,225,465 10 id=15 4,229,519 4,054 start_kernel Accumulated time: 6,956 SPI read cleanup_before_linux_select: Console recording failed (1) [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.18.0-rc5-next-20141121 (javier@minerva) (gcc vers ion 4.6.3 (Debian 4.6.3-14) ) #87 SMP PREEMPT Mon Nov 24 09:09:36 CET 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Google Peach Pit Rev 6+ [0.00] Ignoring memory range 0x2000 - 0x4000 [0.00] cma: Reserved 64 MiB at 0x9c00 [0.00] Memory policy: Data cache writealloc [0.00] On node 0 totalpages: 393216 [0.00] free_area_init_node: node 0, pgdat c067a000, node_mem_map eebf600 0 [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: 1552 pages used for memmap [0.00] HighMem zone: 198656 pages, LIFO batch:31 [0.00] PERCPU: Embedded 9 pages/cpu @eeb7e000 s7616 r8192 d21056 u36864 [0.00] pcpu-alloc: s7616 r8192 d21056 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [0.00] Built 1 zonelists in
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On 11/24/2014 10:38 AM, Javier Martinez Canillas wrote: Hell Krzysztof An unfortunate typo, this was Hello of course :-) 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: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pią, 2014-11-21 at 21:49 +0100, Javier Martinez Canillas wrote: Hello Kevin, On 11/21/2014 05:38 PM, Kevin Hilman wrote: So, I see two different boot failures on the Peach Pi[t] Chromebooks: 1) next20141121 boot fails due snd-soc-snow Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further but still fails with the second issue: 2) next20141121 boot hangs if unused clocks are disabled. I tried to root cause these two issues but didn't see anything evident so I'll find a last known good commit and bisect. If anyone has an idea of the possible causes for these issues that would be appreciated. FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot failures in next-20141121 on the exynos5420-arndale-octa[1]. Adding clk_ignore_unused gets things booting there as well. What's interesting is that my exynos5422-odroid-xu3 is booting fine as well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as exynos5410-smdk5410) Whatever the issue, it definietly seems like a problem that was came through a driver/subsystem tree because that these boards are all booting fine with Kukjin's for-next, arm-soc/for-next and mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without clk_ignore_unused.) For example, just looking at peach-pi across all these trees[2], you can see that it's only failing in linux-next. By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? OK, I got some ideas (no need to run tests mentioned in my previous email). Apparently the mout_audss clock (or one of its parents up to EPLL clock) must be enabled. Configuration like this works: $ cat /sys/kernel/debug/clk/clk_summary fout_epll 11 1 0 0 mout_sclk_epll 11 1 0 0 mout_mau_epll_clk 11 1 0 0 mau_epll 11 1 0 0 mout_audss12 1 0 0 dout_srp 01 1 0 0 adma01 1 0 0 srp_clk 00 1 0 0 dout_aud_bus 00 1 0 0 i2s_bus 00 1 0 0 mout_i2s 00 1 0 0 dout_i2s00 1 0 0 sclk_i2s 00 1 0 0 Reverting my patch enables the adma clock which effectively enables mout_audss. Now I have to find the answer which driver uses epll/audss without enabling it explicitly... Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Ajay, On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote: On 11/21/2014 06:32 PM, Ajay kumar wrote: Hi, I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Thanks for forward porting your patches to linux-next. Unfortunately I won't have time to test them until Monday but I wonder why you didn't have the boot issues that we have with next-20141121. I tested your ToT patches on top of next-20141121, this is my git log: 93fe3d7 Revert Revert ARM: exynos_defconfig: Enable options for display panel support 552f74e ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints dbbc293 ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge f29a649 Documentation: bridge: Add documentation for ps8622 DT properties 6ade887 Documentation: devicetree: Add vendor prefix for parade d81c42d Documentation: drm: bridge: move to video/bridge 50b9828 drm/bridge: ptn3460: use gpiod interface 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach f3cf063 drm/bridge: ptn3460: support drm_panel cab682b drm/exynos: dp: support drm_bridge 6e78916 drm/bridge: ptn3460: Convert to i2c driver model 93f4b5f drm/bridge: make bridge registration independent of drm flow 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init eb6996e drm/bridge: ptn3460: Few trivial cleanups c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 51b2c75 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I found that the commit ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) had to be reverted in order to boot linux-next. Display works but I needed to revert the mentioned commit, otherwise the boot hangs as reported before. I'm using exynos_defconfig and this kernel command line: console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw 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: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pon, 2014-11-24 at 10:38 +0100, Javier Martinez Canillas wrote: Hell Krzysztof, On 11/22/2014 11:21 AM, Krzysztof Kozlowski wrote: By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? Oh crap... I'll look at it on Monday. However I don't have Peach Pi so any information would be useful. Can you post dmesg and your config? (is it exynos_defconfig?) Yes, I'm using exynos_defconfig. I'm testing with latest linux-next, HEAD: commit ed6778a (Add linux-next specific files for 20141121) The boot log of the hang in the Exynos5420 Peach Pit is sent as an attachment. CONFIG_SND_SOC_SNOW was enabled and without clk_ignore_unused. Additionally can you boot the board with DMATEST enabled (without reverting my commit so probably with clk_ignore_unsed and with SND_SNOW disabled) and run dmatest on all channels? Something like: echo 2000 /sys/module/dmatest/parameters/timeout echo 2 /sys/module/dmatest/parameters/iterations for i in `ls /sys/class/dma/` do echo $i /sys/module/dmatest/parameters/channel echo 1 /sys/module/dmatest/parameters/run done ... and post these results also. I'm attaching the log of the tests as well. To run the test CONFIG_SND_SOC_SNOW was disabled and booted with clk_ignore_unused. I will test it on Arndale Octa, maybe the cause is the same. Unfortunately it seems Arndale Octa does not have any sound enabled in DTS so it may be hard to test I2S bus (which is used by audio). Ok, please let me know if you need anything else from me. Thanks! I replied before seeing your response. Anyway the dmatests are the same I got on Arndale Octa. It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Jingoo Han jg1@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Kukjin Kim kg...@kernel.org
---
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420.dtsi |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
dp_phy: video-phy@10040720 {
compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040720 4;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
dp_phy: video-phy@10040728 {
- compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040728 4;
+ compatible = samsung,exynos5420-dp-video-phy;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
It seems like these nodes have been in the Linux tree since 3.12 and
3.17, respectively and these changes break backwards-compatibility. Has
anyone thought about the possible consequences?
Although, looking more closely it seems like this isn't the first time
that backwards-compatibility was broken in these files, so perhaps
nobody cares...
Thierry
pgpeEV_fqr4kQ.pgp
Description: PGP signature
Re: [PATCH RESEND 1/7] clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi
On 24/11/14 08:30, Andrzej Hajda wrote:
sclk_hdmiphy clock is generated by HDMI-PHY and depends on hdmi gate clock.
The patch models this dependency using parent/child hirerarchy.
The patch fixes issue with system hangs during mixer device access, mixer uses
sclk_hdmiphy descendant clock.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
I guess it can be merged as a bug fix, however it's not an ideal
solution. The proper approach would be probably to have the HDMIPHY
driver exposing a clk object. Unfortunately there seems to be
no sufficiently documented hardware control sequences available
for such a fine-grained hardware control.
---
drivers/clk/samsung/clk-exynos4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 940f028..88e8c6b 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -505,7 +505,7 @@ static struct samsung_fixed_rate_clock
exynos4_fixed_rate_ext_clks[] __initdata
/* fixed rate clocks generated inside the soc */
static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata
= {
FRATE(0, sclk_hdmi24m, NULL, CLK_IS_ROOT, 2400),
- FRATE(CLK_SCLK_HDMIPHY, sclk_hdmiphy, NULL, CLK_IS_ROOT, 2700),
+ FRATE(CLK_SCLK_HDMIPHY, sclk_hdmiphy, hdmi, 0, 2700),
FRATE(0, sclk_usbphy0, NULL, CLK_IS_ROOT, 4800),
};
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
Hi,
On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Jingoo Han jg1@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Kukjin Kim kg...@kernel.org
---
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420.dtsi |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
dp_phy: video-phy@10040720 {
compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040720 4;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
dp_phy: video-phy@10040728 {
- compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040728 4;
+ compatible = samsung,exynos5420-dp-video-phy;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
It seems like these nodes have been in the Linux tree since 3.12 and
3.17, respectively and these changes break backwards-compatibility. Has
anyone thought about the possible consequences?
Sorry for my ignorance, but i have a doubt.
If the bindings and device node both are being changed in the same kernel
version (as fixes),
so that the stable will have both; then the only scenerio of backward
compatibility comes when kernel is upgraded but not dtbs.
Does such upgradation makes sense for distros ?
Although, looking more closely it seems like this isn't the first time
that backwards-compatibility was broken in these files, so perhaps
nobody cares...
Thierry
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Mon, Nov 24, 2014 at 04:17:18PM +0530, Vivek Gautam wrote:
Hi,
On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Jingoo Han jg1@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Kukjin Kim kg...@kernel.org
---
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420.dtsi |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
dp_phy: video-phy@10040720 {
compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040720 4;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
dp_phy: video-phy@10040728 {
- compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040728 4;
+ compatible = samsung,exynos5420-dp-video-phy;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
It seems like these nodes have been in the Linux tree since 3.12 and
3.17, respectively and these changes break backwards-compatibility. Has
anyone thought about the possible consequences?
Sorry for my ignorance, but i have a doubt.
If the bindings and device node both are being changed in the same kernel
version (as fixes),
so that the stable will have both; then the only scenerio of backward
compatibility comes when kernel is upgraded but not dtbs.
Correct.
Does such upgradation makes sense for distros ?
Yes. Back at the time a decision was made that device trees need to be
stable ABI because eventually they'd be shipped with the device rather
than the distribution. As such it may not at all be possible to update
them (they could be in some sort of ROM).
For that reason new kernels need to keep working with old DTBs unless an
argument can be made that would justify breaking things. I don't think I
have ever seen anyone win such an argument. One of the rare exceptions
that I know of is if you can prove that a given hardware block has never
been used in an upstream kernel, then changing the DTB in backwards-
incompatible ways would be okay because you wouldn't be breaking things
for existing users.
Thierry
pgpMb7BlOEiAw.pgp
Description: PGP signature
[PATCHv3 0/3] ARM: dts: add the support of Exynos3250-based Monk board
This patchset adds the support of Exynos3250-based Monk board and Exynos-based boards compatible string and description to remove build warning. Also, this patchset includes a patch which remove unused dt node for command line in Exynos3250-based Rinato dts file. Changes from v2: - Include new patches by Chanwoo Choi with following patch[1] [1] http://www.spinics.net/lists/arm-kernel/msg368443.html Changes from v1: - Fix minor issue Chanwoo Choi (2): ARM: exynos: Add Exynos-based boards compatible string and description ARM: dts: Remove unused command line from Exynos3250-based Rinato board Youngjun Cho (1): ARM: dts: add board dts file for Exynos3250-based Monk board .../devicetree/bindings/arm/samsung-boards.txt | 19 +- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/exynos3250-monk.dts | 579 + arch/arm/boot/dts/exynos3250-rinato.dts| 4 - 4 files changed, 595 insertions(+), 10 deletions(-) create mode 100644 arch/arm/boot/dts/exynos3250-monk.dts -- 1.8.5.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
[PATCHv3 3/3] ARM: dts: Remove unused command line from Exynos3250-based Rinato board
This patch removes unused dt node of command line from Exynos3250-based
Rinato board because kernel use the command line from bootloader.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 84380fa..80aa8b4 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -28,10 +28,6 @@
reg = 0x4000 0x1ff0;
};
- chosen {
- bootargs = console=ttySAC1,115200N8 root=/dev/mmcblk0p15
rootwait earlyprintk panic=5;
- };
-
firmware@0205F000 {
compatible = samsung,secure-firmware;
reg = 0x0205F000 0x1000;
--
1.8.5.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
[PATCHv3 2/3] ARM: dts: add board dts file for Exynos3250-based Monk board
From: Youngjun Cho yj44@samsung.com
This patch adds new board dts file to support Samsung Monk board which is
based on Exynos3250 SoC and has different H/W configuration from Rinato.
This patch is based on linux-samsung.git for-next branch and depends on
[PATCHv2 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato board
Changes from v1:
- The 'memory' entries coalesce into one entry
- Removes useless space
- Puts voltage-regulator-0 under the root node
This dts file support following features:
- eMMC
- Main PMIC (Samsung S2MPS14)
- Interface PMIC (Maxim MAX77836, MUIC, fuel-gauge, charger)
- RTC of Exynos3250
- ADC of Exynos3250 with NTC thermistor
- I2S of Exynos3250
- TMU of Exynos3250
- Secure firmware for Exynos3250 secondary cpu boot
- Serial ports of Exynos3250
- gpio-key for power key
Signed-off-by: Youngjun Cho yj44@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/arm/samsung-boards.txt | 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/exynos3250-monk.dts | 579 +
3 files changed, 582 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/exynos3250-monk.dts
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 1f8287e..43589d2 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -2,6 +2,7 @@
Required root node properties:
- compatible = should be one or more of the following.
+ - samsung,monk- for Exynos3250-based Samsung Simband board.
- samsung,rinato - for Exynos3250-based Samsung Gear2 board.
- samsung,smdkv310- for Exynos4210-based Samsung SMDKV310 eval
board.
- samsung,trats - for Exynos4210-based Tizen Reference board.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91cd4d0..0e4839e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,7 +67,8 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
+ exynos3250-rinato.dtb \
exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
new file mode 100644
index 000..24822aa
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -0,0 +1,579 @@
+/*
+ * Samsung's Exynos3250 based Monk board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Monk board which is based on
+ * Samsung Exynos3250 SoC.
+ *
+ * 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 exynos3250.dtsi
+#include dt-bindings/input/input.h
+
+/ {
+ model = Samsung Monk board;
+ compatible = samsung,monk, samsung,exynos3250, samsung,exynos3;
+
+ aliases {
+ i2c7 = i2c_max77836;
+ };
+
+ memory {
+ reg = 0x4000 0x1ff0;
+ };
+
+ firmware@0205F000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x0205F000 0x1000;
+ };
+
+ gpio_keys {
+ compatible = gpio-keys;
+
+ power_key {
+ interrupt-parent = gpx2;
+ interrupts = 7 0;
+ gpios = gpx2 7 1;
+ linux,code = KEY_POWER;
+ label = power key;
+ debounce-interval = 10;
+ gpio-key,wakeup;
+ };
+ };
+
+ vemmc_reg: voltage-regulator-0 {
+ compatible = regulator-fixed;
+ regulator-name = V_EMMC_2.8V-fixed;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ gpio = gpk0 2 0;
+ enable-active-high;
+ };
+
+ i2c_max77836: i2c-gpio-0 {
+ compatible = i2c-gpio;
+ gpios = gpd0 2 0, gpd0 3 0;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ max77836: subpmic@25 {
+ compatible = maxim,max77836;
+ interrupt-parent = gpx1;
+ interrupts = 5 0;
[PATCHv3 1/3] ARM: exynos: Add Exynos-based boards compatible string and description
This patch adds the missing compatible/description of Exynos-based boards to remove following build warning. WARNING: DT compatible string samsung,... appears un-documented -- check ./Documentation/devicetree/bindings/ Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- .../devicetree/bindings/arm/samsung-boards.txt | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt index 2168ed3..1f8287e 100644 --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt @@ -1,11 +1,19 @@ -* Samsung's Exynos4210 based SMDKV310 evaluation board - -SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC. +* Samsung's Exynos SoC based boards Required root node properties: - compatible = should be one or more of the following. -(a) samsung,smdkv310 - for Samsung's SMDKV310 eval board. -(b) samsung,exynos4210 - for boards based on Exynos4210 SoC. + - samsung,rinato - for Exynos3250-based Samsung Gear2 board. + - samsung,smdkv310- for Exynos4210-based Samsung SMDKV310 eval board. + - samsung,trats - for Exynos4210-based Tizen Reference board. + - samsung,universal_c210 - for Exynos4210-based Samsung board. + - samsung,smdk4412, - for Exynos4412-based Samsung SMDK4412 eval board. + - samsung,trats2 - for Exynos4412-based Tizen Reference board. + - samsung,smdk5250- for Exynos5250-based Samsung SMDK5250 eval board. + - samsung,xyref5260 - for Exynos5260-based Samsung board. + - samsung,smdk5410- for Exynos5410-based Samsung SMDK5410 eval board. + - samsung,smdk5420- for Exynos5420-based Samsung SMDK5420 eval board. + - samsung,sd5v1 - for Exynos5440-based Samsung board. + - samsung,ssdk5440- for Exynos5440-based Samsung board. Optional: - firmware node, specifying presence and type of secure firmware: -- 1.8.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: rt5631: Fixing compilation warning when DT is disabled
On Mon, Nov 24, 2014 at 12:48:31PM +0530, D Krishna Mohan wrote: Attaching the patch with changes suggested by Uwe. Though there is another patch which I submitted, but I leave it to Mark Brown as to which patch to pick. Please send patches in the format covered in SubmittingPatches, the tools can't apply this. signature.asc Description: Digital signature
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
Hello Krzysztof, On 11/24/2014 11:13 AM, Krzysztof Kozlowski wrote: Ok, please let me know if you need anything else from me. Thanks! I replied before seeing your response. Anyway the dmatests are the same I got on Arndale Octa. It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. 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: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, On 11/24/2014 11:13 AM, Krzysztof Kozlowski wrote: Ok, please let me know if you need anything else from me. Thanks! I replied before seeing your response. Anyway the dmatests are the same I got on Arndale Octa. It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: rt5631: Fixing compilation warning when DT is disabled
Fixes the following compilation warning:
Warning: 'rt5631_i2c_dt_ids' defined but not used - when DT is not used.
Signed-off-by: Claude Youn claude.y...@gmail.com
Signed-off-by: Krishna Mohan Dani krishna...@samsung.com
---
sound/soc/codecs/rt5631.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/rt5631.c b/sound/soc/codecs/rt5631.c
index 3b7d5e4..5c65915 100644
--- a/sound/soc/codecs/rt5631.c
+++ b/sound/soc/codecs/rt5631.c
@@ -1691,7 +1691,7 @@ static const struct i2c_device_id rt5631_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, rt5631_i2c_id);
-static struct of_device_id rt5631_i2c_dt_ids[] = {
+static struct of_device_id rt5631_i2c_dt_ids[] __maybe_unused = {
{ .compatible = realtek,rt5631},
{ .compatible = realtek,alc5631},
{ }
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
On Mon, Nov 24, 2014 at 4:26 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Nov 24, 2014 at 04:17:18PM +0530, Vivek Gautam wrote:
Hi,
On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Jingoo Han jg1@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Kukjin Kim kg...@kernel.org
---
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420.dtsi |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
dp_phy: video-phy@10040720 {
compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040720 4;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
dp_phy: video-phy@10040728 {
- compatible = samsung,exynos5250-dp-video-phy;
- reg = 0x10040728 4;
+ compatible = samsung,exynos5420-dp-video-phy;
+ samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 0;
};
It seems like these nodes have been in the Linux tree since 3.12 and
3.17, respectively and these changes break backwards-compatibility. Has
anyone thought about the possible consequences?
Sorry for my ignorance, but i have a doubt.
If the bindings and device node both are being changed in the same kernel
version (as fixes),
so that the stable will have both; then the only scenerio of backward
compatibility comes when kernel is upgraded but not dtbs.
Correct.
Does such upgradation makes sense for distros ?
Yes. Back at the time a decision was made that device trees need to be
stable ABI because eventually they'd be shipped with the device rather
than the distribution. As such it may not at all be possible to update
them (they could be in some sort of ROM).
For that reason new kernels need to keep working with old DTBs unless an
argument can be made that would justify breaking things. I don't think I
have ever seen anyone win such an argument.
One of the rare exceptions
that I know of is if you can prove that a given hardware block has never
been used in an upstream kernel, then changing the DTB in backwards-
incompatible ways would be okay because you wouldn't be breaking things
for existing users.
I am pretty sure about the Chrome devices (which have not been
upgraded to any kernel after
3.8).
Probably Javier may have better knowledge.
Javier, is there any other device using upstream kernel post 3.12 (any
arndale octa based) ?
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
Hello Vivek, Thierry, On 11/24/2014 12:29 PM, Vivek Gautam wrote: Yes. Back at the time a decision was made that device trees need to be stable ABI because eventually they'd be shipped with the device rather than the distribution. As such it may not at all be possible to update them (they could be in some sort of ROM). For that reason new kernels need to keep working with old DTBs unless an argument can be made that would justify breaking things. I don't think I have ever seen anyone win such an argument. Although uncommon, there are cases when breaking a DT backward compatibility could make sense IMHO. For example the DT binding for the SPI controller found on Samsung SoCs (s3c64xx) used a custom binding to specify the chip select (CS) line. Later the binding was changed in mainline breaking backward compatibility and the breakage was not noticed in a year even when the change not only broke backward compatibility but also was wrong. So the options were to a) keep the buggy DT which also broke backward compact, b) revert to the old binding breaking any DTS that were added the last year, c) break backward compatibility again but take the opportunity to fix the binding for good by dropping device specific bindings and use standard ones. At the end it was decided that c) was the least bad option and was made in commit 306972c (spi: s3c64xx: use the generic SPI cs-gpios property). One of the rare exceptions that I know of is if you can prove that a given hardware block has never been used in an upstream kernel, then changing the DTB in backwards- incompatible ways would be okay because you wouldn't be breaking things for existing users. I am pretty sure about the Chrome devices (which have not been upgraded to any kernel after 3.8). Probably Javier may have better knowledge. Correct. The Exynos based Chromebooks are using a 3.8 kernel and the FDT shipped can't be used with a mainline kernel since it used out-of-tree drivers whose DT bindings were changed during review to upstream inclusion. Also, the stock boot-loader loads a FIT image which has a kernel and FDT bundled in the same image so in that case the FDT has to be shipped with the Linux kernel anyways. Javier, is there any other device using upstream kernel post 3.12 (any arndale octa based) ? Sorry, I don't know if there are other Exynos devices using a more recent kernel but AFAICT the DT binding for the Exynos Display Port was changed recently (v3.17) in a non-backward compatible way with commit 5f1dcd8 (drm/exynos: dp: Modify driver to support drm_panel). So anyone using a more recent kernel will have to update the FDT to have display working. Also display does not work for many Exynos5 devices that have an eDP to LVDS bridge chip for example so I think is safe to assume that anything related to the Exynos DP (like the DP PHY) would still not have a stable DT binding. 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
[PATCH RFC v2 00/12] soc: samsung: Modify and enhance power domain driver
Posting this series as RFC to get more clarity as lot of power domain related
discussion is happening in mailing lists.
This patch series[1 - 12] performs several implementations as listed below,
1) Converts power domain driver to platform driver.
2) Registers this driver as MFD client driver.
3) Moves them into driver/soc/samsung folder.
4) Add parent power domain parsing code.
5) Updates the reparenting feature to make it more generic.
6) A feature to turn clocks on during pm domain off/on. There can be
different set of clocks to be turned on. The patches in Rafael's tree allows
a single list only.
7) Code added to preserve the clocks rates during power domain on/off
sequence.
8) Restructured the exynos PD on/off handlers and added exynos7 support.
The power domain DT node may look something like,
mfc_pd: power-domain@10044060 {
compatible = samsung,exynos4210-pd, samsung,exynos7-pd-mfc;
reg = 0x10044060 0x20;
pd-parent-clock-names = tclk0, pclk0, clk0;
pd-parent-clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK333,
clock CLK_MOUT_USER_ACLK333;
pd-on-en-clock-names = clk0, clk1;
pd-on-en-clocks = clock CLK_IP1, clock CLK_IP2,
pd-off-en-clock-names = clk0, clk1, clk3;
pd-off-en-clocks = clock CLK_IP1, clock CLK_IP2, clock CLK_IP3;
pd-rate-clock-names = clk0, clk1;
pd-rate-clocks = clock CLK_IP1, clock CLK_IP2,
parents = pd_top;
#power-domain-cells = 0;
};
Changes from v1:
* Removed PM domain notifier features.
* Removed clock save/restore through those notifiers.
* link for v1 is http://www.spinics.net/lists/linux-samsung-soc/msg38442.html.
This patch series depends on exynos pmu patches posted earlier.
http://lkml.org/lkml/2014/11/23/221
Amit Daniel Kachhap (12):
arm: exynos: Add platform driver support for power domain driver
soc: exynos: Move exynos power domain file to driver/soc/samsung
folder
soc: samsung: exynos-pmu: Register exynos pd driver as a mfd client
soc: samsung: Re-structure PMU driver to create pd on/off handlers
soc: samsung: pm_domain: Use unique compatible name for power domain
driver: soc: exynos-pmu: Add exynos7 power domain on/off ops
PM / Domains: export pm_genpd_lookup_name
soc: samsung: pm_domain: Add support for parent power domain
drivers: soc: pm_domain: Modify the parent clocks bindings
drivers: soc: samsung: Add support for clock enabling in power domain
drivers: soc: samsung: Add support for clock rate save/restore in
power domain
arm64: Kconfig: Enable PM_GENERIC_DOMAINS for exynos7
.../bindings/arm/exynos/power_domain.txt | 45 +-
arch/arm/mach-exynos/Makefile |1 -
arch/arm/mach-exynos/pm_domains.c | 166 ---
arch/arm64/Kconfig |1 +
drivers/base/power/domain.c|3 +-
drivers/soc/samsung/Kconfig|9 +
drivers/soc/samsung/Makefile |3 +-
drivers/soc/samsung/exynos-pmu.c | 185 +++
drivers/soc/samsung/pm_domains.c | 510
include/linux/pm_domain.h |7 +
include/linux/soc/samsung/exynos-pmu.h | 15 +
include/linux/soc/samsung/exynos-regs-pmu.h| 26 +
12 files changed, 794 insertions(+), 177 deletions(-)
delete mode 100644 arch/arm/mach-exynos/pm_domains.c
create mode 100644 drivers/soc/samsung/pm_domains.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
Re: [PATCH 1/3] drm/exynos: free DP if probe fails to find a panel or bridge
2014-11-22 Inki Dae inki@samsung.com:
2014-11-21 8:54 GMT+09:00 Gustavo Padovan gust...@padovan.org:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
DP was leaked everytime function returns EPROBE_DEFER, free it before
returning.
It seems that you misunderstood devm_* api.
Yeah, I though it would only free memory at unload of the module but it also
free it when the probe fails.
Thanks,
Inki Dae
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 85762cf..6fd4a46 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device
*pdev)
if (panel_node) {
dp-panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
- if (!dp-panel)
- return -EPROBE_DEFER;
+ if (!dp-panel) {
+ ret = -EPROBE_DEFER;
+ goto free_dp;
+ }
}
endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
@@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device
*pdev)
if (bridge_node) {
dp-bridge = of_drm_find_bridge(bridge_node);
of_node_put(bridge_node);
- if (!dp-bridge)
- return -EPROBE_DEFER;
- } else
- return -EPROBE_DEFER;
+ if (!dp-bridge) {
+ ret = -EPROBE_DEFER;
+ goto free_dp;
+ }
+ } else {
+ ret = -EPROBE_DEFER;
+ goto free_dp;
+ }
}
exynos_dp_display.ctx = dp;
@@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device
*pdev)
exynos_drm_component_del(pdev-dev,
EXYNOS_DEVICE_TYPE_CONNECTOR);
+free_dp:
+ devm_kfree(dev, dp);
+
return ret;
}
--
1.9.3
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Gustavo
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Linus Walleij linus.wall...@linaro.org
---
This patch was part of series:
[PATCH 00/11] Exynos7: Adding USB 3.0 support
https://lkml.org/lkml/2014/11/21/247
Changes since V1:
- Added support for all pin banks which are part of BUS1 pin controller.
drivers/pinctrl/samsung/pinctrl-exynos.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..44e60dc 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, gpr3, 0x0c),
};
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, gpf0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpf1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(4, 0x060, gpf2, 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, gpf3, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, gpf4, 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0c0, gpf5, 0x14),
+ EXYNOS_PIN_BANK_EINTG(5, 0x0e0, gpg1, 0x18),
+ EXYNOS_PIN_BANK_EINTG(5, 0x100, gpg2, 0x1c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x120, gph1, 0x20),
+ EXYNOS_PIN_BANK_EINTG(3, 0x140, gpv6, 0x24),
+};
+
const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
__initconst = {
.pin_banks = exynos7_pin_banks7,
.nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 8 BUS1 data */
+ .pin_banks = exynos7_pin_banks8,
+ .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
+ .eint_gpio_init = exynos_eint_gpio_init,
},
};
--
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
[PATCH RFC v2 01/12] arm: exynos: Add platform driver support for power domain driver
This patch modifies Exynos Power Domain driver initialization
implementation in following way:
- Added platform driver support and probe function where Exynos PM
Domain driver will finally register itself as MFD PMU client driver.
In this way,all the Exynos power domains are probed once and registered
with the power domain subsystem.
- Existing DT bindings are used.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c | 40 +++--
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 20f2671..5cb5440 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -105,25 +105,17 @@ static int exynos_pd_power_off(struct generic_pm_domain
*domain)
return exynos_pd_power(domain, false);
}
-static __init int exynos4_pm_init_power_domain(void)
+static int exynos_power_domain_probe(struct platform_device *pdev)
{
- struct platform_device *pdev;
struct device_node *np;
for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
struct exynos_pm_domain *pd;
int on, i;
- struct device *dev;
- pdev = of_find_device_by_node(np);
- dev = pdev-dev;
-
- pd = kzalloc(sizeof(*pd), GFP_KERNEL);
- if (!pd) {
- pr_err(%s: failed to allocate memory for domain\n,
- __func__);
+ pd = devm_kzalloc(pdev-dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
return -ENOMEM;
- }
pd-pd.name = kstrdup(np-name, GFP_KERNEL);
pd-name = pd-pd.name;
@@ -131,7 +123,7 @@ static __init int exynos4_pm_init_power_domain(void)
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
- pd-oscclk = clk_get(dev, oscclk);
+ pd-oscclk = of_clk_get_by_name(np, oscclk);
if (IS_ERR(pd-oscclk))
goto no_clk;
@@ -139,11 +131,11 @@ static __init int exynos4_pm_init_power_domain(void)
char clk_name[8];
snprintf(clk_name, sizeof(clk_name), clk%d, i);
- pd-clk[i] = clk_get(dev, clk_name);
+ pd-clk[i] = of_clk_get_by_name(np, clk_name);
if (IS_ERR(pd-clk[i]))
break;
snprintf(clk_name, sizeof(clk_name), pclk%d, i);
- pd-pclk[i] = clk_get(dev, clk_name);
+ pd-pclk[i] = of_clk_get_by_name(np, clk_name);
if (IS_ERR(pd-pclk[i])) {
clk_put(pd-clk[i]);
pd-clk[i] = ERR_PTR(-EINVAL);
@@ -163,4 +155,22 @@ no_clk:
return 0;
}
-arch_initcall(exynos4_pm_init_power_domain);
+
+static const struct platform_device_id exynos_power_domain_id[] = {
+ { exynos-pmu-pd},
+ { },
+};
+
+static struct platform_driver exynos_power_domain_driver = {
+ .driver = {
+ .name = exynos-pd,
+ },
+ .probe = exynos_power_domain_probe,
+ .id_table = exynos_power_domain_id,
+};
+
+static int __init exynos_power_domain_init(void)
+{
+ return platform_driver_register(exynos_power_domain_driver);
+}
+postcore_initcall(exynos_power_domain_init);
--
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 RFC v2 02/12] soc: exynos: Move exynos power domain file to driver/soc/samsung folder
This patch moves arch/arm/mach-exynos/pm_domains.c to driver/soc/samsung
folder. In this way it can be used for both arm and arm64 platforms.
This file is moved in this directory as this driver is soc specific and
only used by exynos platforms.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
arch/arm/mach-exynos/Makefile |1 -
drivers/soc/samsung/Kconfig|9 +
drivers/soc/samsung/Makefile |3 ++-
.../soc/samsung}/pm_domains.c |0
4 files changed, 11 insertions(+), 2 deletions(-)
rename {arch/arm/mach-exynos = drivers/soc/samsung}/pm_domains.c (100%)
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index b91b382..9ea6c54 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -13,7 +13,6 @@ obj-$(CONFIG_ARCH_EXYNOS) += exynos.o exynos-smc.o
firmware.o
obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
obj-$(CONFIG_PM_SLEEP) += suspend.o
-obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 6855cc4..2bb33e7 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -17,4 +17,13 @@ config EXYNOS_PMU
functionality like initialisation and transition to various low power
states.
+config EXYNOS_POWER_DOMAIN
+ tristate Support Exynos PM Power Domain
+ depends on ARCH_EXYNOS PM_GENERIC_DOMAINS
+ default y
+ help
+ Exynos SOC have power domain gating support. This driver implements
+ that functionality and registers all the necessary hooks to the
+ generic power domain core kernel infrastructure.
+
endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 5a879c6..61ccd51 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o
+obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o
+obj-$(CONFIG_EXYNOS_POWER_DOMAIN) += pm_domains.o
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/drivers/soc/samsung/pm_domains.c
similarity index 100%
rename from arch/arm/mach-exynos/pm_domains.c
rename to drivers/soc/samsung/pm_domains.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 RFC v2 03/12] soc: samsung: exynos-pmu: Register exynos pd driver as a mfd client
This is used to probe exynos power domain. This method can be also used
for probing other PMU client drivers like pm sleep etc. Currently no
platform data is supplied but can be easily extended when required.
Reviewed-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/soc/samsung/exynos-pmu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index cb9e356..da77c7e 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -10,6 +10,7 @@
*/
#include linux/io.h
+#include linux/mfd/core.h
#include linux/of.h
#include linux/of_address.h
#include linux/platform_device.h
@@ -21,6 +22,10 @@
#define PMU_TABLE_END (-1U)
+enum pmu_mfd_list {
+ MFD_PD,
+ MFD_MAX,
+};
struct exynos_pmu_conf {
unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
@@ -38,6 +43,7 @@ struct exynos_pmu_data {
struct exynos_pmu_context {
struct device *dev;
const struct exynos_pmu_data *pmu_data;
+ struct mfd_cell cells[MFD_MAX];
};
static void __iomem *pmu_base_addr;
@@ -1220,6 +1226,7 @@ static int exynos_pmu_probe(struct platform_device *pdev)
const struct of_device_id *match;
struct device *dev = pdev-dev;
struct resource *res;
+ struct mfd_cell *cell;
int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1249,6 +1256,17 @@ static int exynos_pmu_probe(struct platform_device *pdev)
if (ret)
dev_warn(dev, can't register restart handler err=%d\n, ret);
+ /* Initialize and invoke mfd clients */
+ cell = pmu_context-cells[MFD_PD];
+ cell-name = exynos-pmu-pd;
+
+ ret = mfd_add_devices(pdev-dev, pdev-id, pmu_context-cells, MFD_MAX,
+ NULL, 0, NULL);
+ if (ret) {
+ dev_err(pdev-dev, fail to register client devices\n);
+ return ret;
+ }
+
dev_dbg(dev, Exynos PMU Driver probe done\n);
return 0;
}
--
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 RFC v2 04/12] soc: samsung: Re-structure PMU driver to create pd on/off handlers
This patch moves PD domain on/off implementation inside the PMU driver.
The handlers will be supplied via the MFD platform data. Power domains
are basically sparse memories in the Exynos PMU controllers, so with
this restructuring all the register access operations reside inside pmu
file.
This restructuring will be useful for SoC's where certain extra
operation need to implemented along with PD on/off operation or if
some PD registers are different. There is no functionality change for the
existing SoC's.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/soc/samsung/exynos-pmu.c| 62 +++
drivers/soc/samsung/pm_domains.c| 50 -
include/linux/soc/samsung/exynos-pmu.h | 15 +++
include/linux/soc/samsung/exynos-regs-pmu.h |9
4 files changed, 115 insertions(+), 21 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index da77c7e..e690f65 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -34,6 +34,7 @@ struct exynos_pmu_conf {
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
const struct exynos_pmu_conf *pmu_config_extra;
+ struct exynos_pmu_pd_ops *pd_ops;
void (*pmu_init)(void);
void (*powerdown_conf)(enum sys_powerdown);
@@ -44,6 +45,7 @@ struct exynos_pmu_context {
struct device *dev;
const struct exynos_pmu_data *pmu_data;
struct mfd_cell cells[MFD_MAX];
+ struct pmu_dev_client_data mfd_data[MFD_MAX];
};
static void __iomem *pmu_base_addr;
@@ -880,6 +882,52 @@ void exynos_sys_powerup_conf(enum sys_powerdown mode)
pmu_data-powerup_conf(mode);
}
+static int __exynos_pd_poweron_off(bool power_on, const char *pd_name,
+ void __iomem *pd_addr, int conf_val)
+{
+ unsigned int timeout, pwr;
+ char *op;
+
+ /* Wait max 1ms */
+ timeout = 10;
+ pwr = power_on ? conf_val : 0;
+
+ writel_relaxed(pwr, pd_addr + EXYNOS_PD_CONFIG);
+
+ while ((readl_relaxed(pd_addr + EXYNOS_PD_STATUS) conf_val) != pwr) {
+ if (!timeout) {
+ op = (power_on) ? enable : disable;
+ pr_err(Power domain %s %s failed\n, pd_name, op);
+ return -ETIMEDOUT;
+ }
+ timeout--;
+ cpu_relax();
+ usleep_range(80, 100);
+ }
+ return 0;
+}
+
+static int exynos_pd_poweron(const char *pd_name, void __iomem *pd_addr)
+{
+ return __exynos_pd_poweron_off(true, pd_name, pd_addr,
+ EXYNOS_INT_LOCAL_PWR_EN);
+}
+
+static int exynos_pd_poweroff(const char *pd_name, void __iomem *pd_addr)
+{
+ return __exynos_pd_poweron_off(false, pd_name, pd_addr,
+ EXYNOS_INT_LOCAL_PWR_EN);
+}
+
+static bool exynos_pd_status(void __iomem *pd_addr)
+{
+ unsigned int val;
+
+ val = readl_relaxed(pd_addr + EXYNOS_PD_STATUS)
+ EXYNOS_INT_LOCAL_PWR_EN;
+ return val ? true : false;
+}
+
static void exynos5250_pmu_init(void)
{
unsigned int value;
@@ -1154,29 +1202,40 @@ static void exynos7_pmu_init(void)
}
}
+static struct exynos_pmu_pd_ops exynos_pd_ops = {
+ .pd_on = exynos_pd_poweron,
+ .pd_off = exynos_pd_poweroff,
+ .pd_status = exynos_pd_status,
+};
+
static const struct exynos_pmu_data exynos4210_pmu_data = {
.pmu_config = exynos4210_pmu_config,
+ .pd_ops = exynos_pd_ops,
};
static const struct exynos_pmu_data exynos4212_pmu_data = {
.pmu_config = exynos4x12_pmu_config,
+ .pd_ops = exynos_pd_ops,
};
static const struct exynos_pmu_data exynos4412_pmu_data = {
.pmu_config = exynos4x12_pmu_config,
.pmu_config_extra = exynos4412_pmu_config,
+ .pd_ops = exynos_pd_ops,
};
static const struct exynos_pmu_data exynos5250_pmu_data = {
.pmu_config = exynos5250_pmu_config,
.pmu_init = exynos5250_pmu_init,
.powerdown_conf = exynos5_powerdown_conf,
+ .pd_ops = exynos_pd_ops,
};
static struct exynos_pmu_data exynos5420_pmu_data = {
.pmu_config = exynos5420_pmu_config,
.pmu_init = exynos5420_pmu_init,
.powerdown_conf = exynos5420_powerdown_conf,
+ .pd_ops = exynos_pd_ops,
};
static const struct exynos_pmu_data exynos7_pmu_data = {
@@ -1259,6 +1318,9 @@ static int exynos_pmu_probe(struct platform_device *pdev)
/* Initialize and invoke mfd clients */
cell = pmu_context-cells[MFD_PD];
cell-name = exynos-pmu-pd;
+ pmu_context-mfd_data[MFD_PD].ops = pmu_context-pmu_data-pd_ops;
+ cell-platform_data = pmu_context-mfd_data[MFD_PD];
+
[PATCH V2 2/2] arm64: exynos: Add bus1 pinctrl node on exynos7
BUS1 pinctrl provides gpios for usb and power regulator
available on exynos7-espresso board. So add relevant device
node for pinctrl-bus1.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
This patch was part of series:
[PATCH 00/11] Exynos7: Adding USB 3.0 support
https://lkml.org/lkml/2014/11/21/247
Changes since V1:
- Added support for all pin banks which are part of BUS1 pin controller.
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 82 +++
arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
2 files changed, 89 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 2eef4a2..c367f0a 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -335,6 +335,88 @@
};
};
+pinctrl_bus1 {
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf2: gpf2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf3: gpf3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf4: gpf4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf5: gpf5 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpg1: gpg1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpg2: gpg2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gph1: gph1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpv6: gpv6 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
+
pinctrl_nfc {
gpj0: gpj0 {
gpio-controller;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 1d9e4c9..e633b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -26,6 +26,7 @@
pinctrl5 = pinctrl_ese;
pinctrl6 = pinctrl_fsys0;
pinctrl7 = pinctrl_fsys1;
+ pinctrl8 = pinctrl_bus1;
};
cpus {
@@ -242,6 +243,12 @@
interrupts = 0 383 0;
};
+ pinctrl_bus1: pinctrl@1487 {
+ compatible = samsung,exynos7-pinctrl;
+ reg = 0x1487 0x1000;
+ interrupts = 0 384 0;
+ };
+
pinctrl_nfc: pinctrl@14cd {
compatible = samsung,exynos7-pinctrl;
reg = 0x14cd 0x1000;
--
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
[PATCH RFC v2 05/12] soc: samsung: pm_domain: Use unique compatible name for power domain
This patch adds support for second optional compatible complate name. If
this compatible name is present then this name will be used to create
the Power Domain and not the DT node name. This will be useful to carry
out any power domain specific changes in the PD on/off handlers for new
SoCs.
This change will not affect the existing DT bindings.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt |8
drivers/soc/samsung/pm_domains.c | 10 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index abde1ea..00ebda1 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -12,6 +12,8 @@ Required Properties:
must be 0.
Optional Properties:
+- compatible: This is a second compatible name and gives the complete Power
+ Domain name like samsung,exynos7-pd-mfc.
- clocks: List of clock handles. The parent clocks of the input clocks to the
devices in this power domain are set to oscclk before power gating
and restored back after powering on a domain. This is required for
@@ -43,5 +45,11 @@ Example:
#power-domain-cells = 0;
};
+ mfc_pd: power-domain@10044060 {
+ compatible = samsung,exynos4210-pd, samsung,exynos7-pd-mfc;
+ reg = 0x10044060 0x20;
+ #power-domain-cells = 0;
+ };
+
See Documentation/devicetree/bindings/power/power_domain.txt for description
of consumer-side bindings.
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index 69bc8b1..f4f2a6c 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -120,12 +120,20 @@ static int exynos_power_domain_probe(struct
platform_device *pdev)
struct exynos_pm_domain *pd;
int i;
bool on;
+ const char *name;
pd = devm_kzalloc(pdev-dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
return -ENOMEM;
- pd-pd.name = kstrdup(np-name, GFP_KERNEL);
+ /*
+* Check if second compatible name found then use as power
+* domain name or else use the DT node name as before.
+*/
+ if (of_property_read_string_index(np, compatible, 1, name))
+ name = np-name;
+
+ pd-pd.name = kstrdup(name, GFP_KERNEL);
pd-name = pd-pd.name;
pd-base = of_iomap(np, 0);
pd-pd.power_off = exynos_pd_power_off;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
[adding Tushar Behera and Doug Anderson to cc list] Hello, On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). This issue started to look extremely familiar to me so I searched in my mail inbox and found that the same problem was previously reported by Kevin a couple of months ago [0] and Tushar provided a fix [1]. I tested linux-next + [1] and that indeed fixes the hang on Peach. To save you a click, the problem as explained by Tushar is that the AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when the output of AUDSS mux is gated, no operations can be made on the clocks provided by MAU block. For some reason the kernel just oops so it seems to be a H/W errata? Mike was not fond about the solution proposed in [1] but something along those lines would be needed maybe Tushar can comment on that. Vivek and Ajay, As explained in [0], you are not facing this issue because your RW U-Boot seems to predate when audio support was enabled by default. Can you try executing sound init in the U-Boot prompt and see if that triggers the hang for you? Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 06/12] driver: soc: exynos-pmu: Add exynos7 power domain on/off ops
This patch uses the restructuring done in PD handlers and adds PD
on/off/status handlers for exynos7. In this SoC, some extra settings
need to be done prior to turning on/off power domains. Some of those
settings are also different from different power domains so is uses
the power domain compatible name feature to distinguish between power
domains.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/soc/samsung/exynos-pmu.c| 105 +++
include/linux/soc/samsung/exynos-regs-pmu.h | 17 +
2 files changed, 122 insertions(+)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index e690f65..b9631d5 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -1202,6 +1202,104 @@ static void exynos7_pmu_init(void)
}
}
+static int exynos7_pd_extraconf_base(const char *pd_name)
+{
+ if (!pd_name)
+ return -EINVAL;
+
+ if (!strcmp(samsung,exynos7-pd-mfc, pd_name))
+ return EXYNOS7_CLKRUN_CMU_MFC_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-hevc, pd_name))
+ return EXYNOS7_CLKRUN_CMU_HEVC_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-mscl, pd_name))
+ return EXYNOS7_CLKRUN_CMU_MSCL_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-g2d, pd_name))
+ return EXYNOS7_CLKRUN_CMU_G2D_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-fsys0, pd_name))
+ return EXYNOS7_CLKRUN_CMU_FSYS0_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-fsys1, pd_name))
+ return EXYNOS7_CLKRUN_CMU_FSYS1_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-aud, pd_name))
+ return EXYNOS7_CLKRUN_CMU_AUD_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-disp, pd_name))
+ return EXYNOS7_CLKRUN_CMU_DISP_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-vpp, pd_name))
+ return EXYNOS7_CLKRUN_CMU_VPP_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-vpp, pd_name))
+ return EXYNOS7_CLKRUN_CMU_VPP_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-isp0, pd_name))
+ return EXYNOS7_CLKRUN_CMU_ISP0_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-isp1, pd_name))
+ return EXYNOS7_CLKRUN_CMU_ISP1_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-cam0, pd_name))
+ return EXYNOS7_CLKRUN_CMU_CAM0_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-cam1, pd_name))
+ return EXYNOS7_CLKRUN_CMU_CAM1_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-g3d, pd_name))
+ return EXYNOS7_CLKRUN_CMU_CAM1_SYS_PWR_REG;
+
+ pr_err(%s: Unsupported power domain\n, pd_name);
+ return 0;
+}
+
+static int exynos7_pd_powerdown(const char *pd_name, void __iomem *pd_addr)
+{
+ int off_base = exynos7_pd_extraconf_base(pd_name);
+
+ if (!off_base)
+ return -EINVAL;
+
+ /* Initialise the pd extraconf registers */
+ pmu_raw_writel(0, off_base + EXYNOS7_CLKRUN_CMU_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_CLKSTOP_CMU_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_DISABLE_PLL_CMU_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_RESET_LOGIC_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_MEMORY_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_RESET_CMU_PD_SYS_PWR_REG);
+
+ if (!strcmp(samsung,exynos7-pd-fsys0, pd_name) ||
+ !strcmp(samsung,exynos7-pd-fsys1, pd_name))
+ pmu_raw_writel(1,
+ off_base + EXYNOS7_RESET_SLEEP_PD_SYS_PWR_REG);
+
+ if (!strcmp(samsung,exynos7-pd-aud, pd_name)) {
+ pmu_raw_writel(0, EXYNOS7_PAD_RETENTION_AUD_SYS_PWR_REG);
+ pmu_raw_writel(0, EXYNOS7_GPIO_MODE_AUD_SYS_PWR_REG);
+ }
+
+ writel_relaxed((EXYNOS7_USE_PROLONGED_LOGIC_RESET |
+ EXYNOS7_USE_SC_FEEDBACK), pd_addr + EXYNOS_PD_OPTION);
+
+ return 0;
+}
+
+static int exynos7_pd_poweron(const char *pd_name, void __iomem *pd_addr)
+{
+ if (exynos7_pd_powerdown(pd_name, pd_addr))
+ return -EINVAL;
+
+ return __exynos_pd_poweron_off(true, pd_name, pd_addr,
+ EXYNOS7_INT_LOCAL_PWR_EN);
+}
+
+static int exynos7_pd_poweroff(const char *pd_name, void __iomem *pd_addr)
+{
+ if (exynos7_pd_powerdown(pd_name, pd_addr))
+ return -EINVAL;
+
+ return __exynos_pd_poweron_off(false, pd_name, pd_addr,
+ EXYNOS7_INT_LOCAL_PWR_EN);
+}
+
+static bool exynos7_pd_status(void __iomem *pd_addr)
+{
+ unsigned int val;
+
+ val = readl_relaxed(pd_addr + EXYNOS_PD_STATUS)
+ EXYNOS7_INT_LOCAL_PWR_EN;
+ return val ? true : false;
+}
+
static struct exynos_pmu_pd_ops
[PATCH RFC v2 07/12] PM / Domains: export pm_genpd_lookup_name
This API may be needed to set the power domain parent/child relationship
in the power domain platform driver. The parent relationship is
generally set after the child power domain is registered with the power
domain subsystem. In this case, pm_genpd_lookup_name API might be
useful.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/base/power/domain.c |3 ++-
include/linux/pm_domain.h |7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index fb83d4a..b0e1c2f 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -49,7 +49,7 @@
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);
-static struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
+struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
{
struct generic_pm_domain *genpd = NULL, *gpd;
@@ -66,6 +66,7 @@ static struct generic_pm_domain *pm_genpd_lookup_name(const
char *domain_name)
mutex_unlock(gpd_list_lock);
return genpd;
}
+EXPORT_SYMBOL_GPL(pm_genpd_lookup_name);
struct generic_pm_domain *dev_to_genpd(struct device *dev)
{
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 2e0e06d..aedcec3 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -150,6 +150,8 @@ extern int pm_genpd_name_poweron(const char *domain_name);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
+
+extern struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name);
#else
static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev)
@@ -221,6 +223,11 @@ static inline int pm_genpd_name_poweron(const char
*domain_name)
{
return -ENOSYS;
}
+static inline
+struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
+{
+ return NULL;
+}
#define simple_qos_governor NULL
#define pm_domain_always_on_gov NULL
#endif
--
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 RFC v2 08/12] soc: samsung: pm_domain: Add support for parent power domain
This patch adds supports for parent power domain. This will ensure
invoking of parent/child power domain on/off in a correct sequence.
In exynos7 SOC's, power domain controllers have parent and child
hierarchy.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt |2 +
drivers/soc/samsung/pm_domains.c | 43 +++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 00ebda1..0160bdc 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -24,6 +24,7 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
+- parents: phandle of parent power domains.
Node of a device using power domains must have a samsung,power-domain property
defined with a phandle to respective power domain.
@@ -48,6 +49,7 @@ Example:
mfc_pd: power-domain@10044060 {
compatible = samsung,exynos4210-pd, samsung,exynos7-pd-mfc;
reg = 0x10044060 0x20;
+ parents = pd_top;
#power-domain-cells = 0;
};
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index f4f2a6c..89e2fd5 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -25,10 +25,10 @@
#include linux/soc/samsung/exynos-pmu.h
#define MAX_CLK_PER_DOMAIN 4
+#define MAX_PARENT_POWER_DOMAIN10
static struct exynos_pmu_pd_ops *pd_ops;
-
/*
* Exynos specific wrapper around the generic power domain
*/
@@ -169,6 +169,47 @@ no_clk:
of_genpd_add_provider_simple(np, pd-pd);
}
+ /* Assign the child power domains to their parents */
+ for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
+ struct device_node *parent_np;
+ int i;
+ struct generic_pm_domain *child_domain, *parent_domain;
+ const char *name;
+
+ if (of_property_read_string_index(np, compatible, 1,
+ name)) {
+ /* Second entry not found, use the node name*/
+ name = np-name;
+ }
+
+ child_domain = pm_genpd_lookup_name(name);
+ if (!child_domain)
+ continue;
+ /* search parents in device tree */
+ for (i = 0; i MAX_PARENT_POWER_DOMAIN; i++) {
+ parent_np = of_parse_phandle(np, parents, i);
+ if (!parent_np)
+ break;
+
+ if (of_property_read_string_index(parent_np,
+ compatible, 1, name)) {
+ /* Second entry not found, use the node name*/
+ name = parent_np-name;
+ }
+
+ parent_domain = pm_genpd_lookup_name(name);
+ if (!parent_domain)
+ break;
+ if (pm_genpd_add_subdomain(parent_domain, child_domain))
+ pr_warn(%s failed to add subdomain: %s\n,
+ parent_domain-name,
+ child_domain-name);
+ else
+ pr_info(%s has as child subdomain: %s.\n,
+ parent_domain-name,
+ child_domain-name);
+ }
+ }
return 0;
}
--
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 RFC v2 09/12] drivers: soc: pm_domain: Modify the parent clocks bindings
This patch updates the parent clock bindings to make it more generic.
The current bindings limits the transient parent clocks to just one
clock as oscclk. This patch extends it to allow any clock as
intermediate parent clock.
The reparent clock sets are of form tclkX, pclkX, clkX where X:0-9.
Because of this change only exynos5420 SoC DT bindings are affected.
The complete example is shown in the DT documentation section.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt | 18 +-
drivers/soc/samsung/pm_domains.c | 199 +---
2 files changed, 145 insertions(+), 72 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 0160bdc..8d913b9 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -13,17 +13,17 @@ Required Properties:
Optional Properties:
- compatible: This is a second compatible name and gives the complete Power
- Domain name like samsung,exynos7-pd-mfc.
-- clocks: List of clock handles. The parent clocks of the input clocks to the
- devices in this power domain are set to oscclk before power gating
+ Domain name like samsung,exynos7-pd-mfc
+- pd-parent-clocks: List of clock handles. The parent clocks of the input
clocks to
+ the devices in this power domain are set to tclk before power gating
and restored back after powering on a domain. This is required for
all domains which are powered on and off and not required for unused
domains.
-- clock-names: The following clocks can be specified:
- - oscclk: Oscillator clock.
+- pd-parent-clock-names: The following clocks can be specified:
+ - tclkN: Transient/Temporary parent clock.
- pclkN, clkN: Pairs of parent of input clock and input clock to the
- devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
- are supported currently.
+ devices in this power domain.
+ Maximum of 10 sets (N = 0 to 9) are supported.
- parents: phandle of parent power domains.
Node of a device using power domains must have a samsung,power-domain property
@@ -40,9 +40,9 @@ Example:
mfc_pd: power-domain@10044060 {
compatible = samsung,exynos4210-pd;
reg = 0x10044060 0x20;
- clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK333,
+ pd-parent-clocks = clock CLK_FIN_PLL, clock
CLK_MOUT_SW_ACLK333,
clock CLK_MOUT_USER_ACLK333;
- clock-names = oscclk, pclk0, clk0;
+ pd-parent-clock-names = tclk0, pclk0, clk0;
#power-domain-cells = 0;
};
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index 89e2fd5..96196f8 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -24,11 +24,18 @@
#include linux/sched.h
#include linux/soc/samsung/exynos-pmu.h
-#define MAX_CLK_PER_DOMAIN 4
+#define MAX_CLK_PER_DOMAIN 30
#define MAX_PARENT_POWER_DOMAIN10
static struct exynos_pmu_pd_ops *pd_ops;
+struct clk_parent_list {
+ struct clk **clks;
+ struct clk **parent_clks;
+ struct clk **trans_clks;
+ unsigned int count;
+};
+
/*
* Exynos specific wrapper around the generic power domain
*/
@@ -37,65 +44,152 @@ struct exynos_pm_domain {
char const *name;
bool is_off;
struct generic_pm_domain pd;
- struct clk *oscclk;
- struct clk *clk[MAX_CLK_PER_DOMAIN];
- struct clk *pclk[MAX_CLK_PER_DOMAIN];
+ struct clk_parent_list *clk_parent;
};
-static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
+static struct clk *exynos_pd_clk_get(struct device_node *np,
+ char *initial_property, char *clk_name)
{
- struct exynos_pm_domain *pd;
- void __iomem *base;
- int ret = 0;
+ struct of_phandle_args clkspec;
+ struct clk *clk;
+ int rc, index;
+ char name[32];
+
+ sprintf(name, %s-clock-names, initial_property);
+ index = of_property_match_string(np, name, clk_name);
+ if (index 0)
+ return ERR_PTR(-EINVAL);
+
+ sprintf(name, %s-clocks, initial_property);
+
+ rc = of_parse_phandle_with_args(np, name, #clock-cells, index,
+ clkspec);
+ if (rc)
+ return ERR_PTR(rc);
+
+ clk = of_clk_get_from_provider(clkspec);
+ of_node_put(clkspec.np);
+ return clk;
+}
- pd = container_of(domain, struct exynos_pm_domain, pd);
- base = pd-base;
+static int pd_init_parent_clocks(struct platform_device *pdev,
+ struct device_node *np, struct exynos_pm_domain *pd)
+{
+ struct
Re: [PATCH v4 0/5] exynos: Move pmu driver to driver/soc folder and add exynos7 support
Hi,
On Monday, November 24, 2014 07:36:10 AM Amit Daniel Kachhap wrote:
This patch series [1 - 5] performs,
1) Moves pmu driver to driver/soc/samsung folder. This is needed as exynos7 is
an arm64 based platform and hence PMU driver should be in driver folder.
Some discussion happened about this in the v1 version. Finally adding it in
driver/soc folder as it too SoC specific and not a general driver.
Entire discussion can be found here (A).
2) Add exynos7 PMU support.
Some months ago (when the work on moving PMU driver out of mach-exynos
started) I asked how much code would be shared between arm32 and arm64
SoCs. Now it seems that the code in question is minimal so I still
wonder whether it is really worth to have a common driver (please note
that in case of arm32 kernel all arm64 PMU code is just a dead code,
similarly for arm64 kernel and arm32 PMU code). Would it be possible
to do the analysis of the additional source code needed vs saved code
in the resulting binary for the case of having separate drivers?
Could you also please take a look into fixing patch #4 to be compatible
with http://lkml.iu.edu/hypermail/linux/kernel/1407.1/00298.html ?
(It seems that just adding separate struct exynos_pmu_conf_extra for
-pmu_config_extra shold be okay.)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
3) Enables the driver for 32bit arm exynos platforms.
Changes from V3:
* Fixed Kconfig as per Russell feedback
* Rebased the series against Pankaj SoC restart consolidation patches (D) as
per
Kukjin request.
* Link to V3 can be found here (C)
Changes from V2:
* Added review comment changes suggested by Pankaj.
* Removed mfd client support in this patch series. This will be added later in
the power domain patch series.
* Link to V2 can be found here (B)
Changes from V1:
* Move pmu driver in driver/soc/samsung folder
* Removed the power domain features. They will posted as a separate series.
* Added exynos7 PMU support.
* Link to v1 can be found here (A)
This complete patch series is rebased on Kukjin for-next tree.
(A) - http://www.spinics.net/lists/linux-samsung-soc/msg38442.html
(B) - http://www.spinics.net/lists/arm-kernel/msg375910.html
(C) - http://www.spinics.net/lists/linux-samsung-soc/msg39237.html
(D) - http://www.spinics.net/lists/linux-samsung-soc/msg39095.html
Amit Daniel Kachhap (5):
ARM: EXYNOS: Move pmu specific header files under linux/soc/samsung
drivers: soc: Add support for Exynos PMU driver
driver: soc: exynos-pmu: Add an API to be called after wakeup
drivers: soc: exynos-pmu: Add support for Exynos7
arm: exynos: Select SOC_SAMSUNG config option
.../devicetree/bindings/arm/samsung/pmu.txt|1 +
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/Makefile |2 +-
arch/arm/mach-exynos/exynos.c |2 +-
arch/arm/mach-exynos/mcpm-exynos.c |2 +-
arch/arm/mach-exynos/platsmp.c |2 +-
arch/arm/mach-exynos/pm.c |4 +-
arch/arm/mach-exynos/suspend.c |4 +-
drivers/soc/Kconfig|1 +
drivers/soc/Makefile |1 +
drivers/soc/samsung/Kconfig| 20 +
drivers/soc/samsung/Makefile |1 +
.../pmu.c = drivers/soc/samsung/exynos-pmu.c | 442
+++-
.../linux/soc/samsung}/exynos-pmu.h|1 +
.../linux/soc/samsung/exynos-regs-pmu.h| 273
15 files changed, 744 insertions(+), 13 deletions(-)
create mode 100644 drivers/soc/samsung/Kconfig
create mode 100644 drivers/soc/samsung/Makefile
rename arch/arm/mach-exynos/pmu.c = drivers/soc/samsung/exynos-pmu.c (64%)
rename {arch/arm/mach-exynos = include/linux/soc/samsung}/exynos-pmu.h (89%)
rename arch/arm/mach-exynos/regs-pmu.h =
include/linux/soc/samsung/exynos-regs-pmu.h (63%)
--
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 RFC v2 11/12] drivers: soc: samsung: Add support for clock rate save/restore in power domain
While turning power domain to on/off, some clocks rates might change and
need to be saved/restored in the Exynos7 SOC. This patch adds the
framework for saving those clocks before power off and restoring it back
after power on operation.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt |7 ++
drivers/soc/samsung/pm_domains.c | 74
2 files changed, 81 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index c48769e..97fec1b 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -32,6 +32,11 @@ Optional Properties:
before turning off a power domain.
- pd-off-en-clock-names: clocks can be specified as,
- clkN: N can vary between 0-30.
+- pd-rate-clocks: List of clock handles. The rates of these clocks are required
+ to be saved before turning off a power domain and restoring after
turning
+ on a power domain.
+- pd-rate-clock-names: clocks can be specified as,
+ - clkN: N can vary between 0-30.
- parents: phandle of parent power domains.
Node of a device using power domains must have a samsung,power-domain property
@@ -55,6 +60,8 @@ Example:
pd-on-en-clock-names = clk0, clk1;
pd-off-en-clocks = clock CLK_IP1, clock CLK_IP2,
pd-off-en-clock-names = clk0, clk1;
+ pd-rate-clocks = clock CLK_IP3, clock CLK_IP4,
+ pd-rate-clock-names = clk0, clk1;
#power-domain-cells = 0;
};
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index 5407eb7..a235277 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -36,6 +36,12 @@ struct clk_enable_list {
unsigned int en_status;
};
+struct clk_rate_list {
+ struct clk **clks;
+ unsigned int *rates;
+ unsigned int count;
+};
+
struct clk_parent_list {
struct clk **clks;
struct clk **parent_clks;
@@ -53,6 +59,7 @@ struct exynos_pm_domain {
struct generic_pm_domain pd;
struct clk_enable_list *clk_pd_on;
struct clk_enable_list *clk_pd_off;
+ struct clk_rate_list *clk_rate;
struct clk_parent_list *clk_parent;
};
@@ -198,6 +205,49 @@ static int pd_init_parent_clocks(struct platform_device
*pdev,
return 0;
}
+static int pd_init_rate_clocks(struct platform_device *pdev,
+ struct device_node *np, struct exynos_pm_domain *pd)
+{
+ struct clk_rate_list *list;
+ char propname[32], clk_name[8];
+ int count, i;
+ struct clk *clk = ERR_PTR(-ENOENT);
+
+ list = devm_kzalloc(pdev-dev, sizeof(*list), GFP_KERNEL);
+ if (!list)
+ return -ENOMEM;
+
+ pd-clk_rate = list;
+ snprintf(propname, sizeof(propname), pd-rate-clock-names);
+
+ count = of_property_count_strings(np, propname);
+ if (!count || count MAX_CLK_PER_DOMAIN)
+ return -EINVAL;
+
+ list-count = count;
+ list-clks = devm_kzalloc(pdev-dev, sizeof(*list-clks) * count,
+ GFP_KERNEL);
+ if (!list-clks)
+ return -ENOMEM;
+
+ list-rates = devm_kzalloc(pdev-dev, sizeof(list-rates) * count,
+ GFP_KERNEL);
+ if (!list-rates)
+ return -ENOMEM;
+
+ for (i = 0; i count; i++) {
+ snprintf(clk_name, sizeof(clk_name), clk%d, i);
+ clk = exynos_pd_clk_get(np, pd-rate, clk_name);
+ if (IS_ERR(clk)) {
+ dev_err(pdev-dev, %s clock not found\n, clk_name);
+ return -EINVAL;
+ }
+ list-clks[i] = clk;
+ }
+ dev_info(pdev-dev, pd rate clocks initialised\n);
+ return 0;
+}
+
static void exynos_pd_poweron_prepare(struct exynos_pm_domain *pd)
{
struct clk_enable_list *en_list;
@@ -220,6 +270,7 @@ static void exynos_pd_post_poweron(struct exynos_pm_domain
*pd)
{
struct clk_parent_list *p_list;
struct clk_enable_list *en_list;
+ struct clk_rate_list *rt_list;
int i;
p_list = pd-clk_parent;
@@ -229,6 +280,17 @@ static void exynos_pd_post_poweron(struct exynos_pm_domain
*pd)
clk_set_parent(p_list-clks[i], p_list-parent_clks[i]);
}
+ rt_list = pd-clk_rate;
+ if (rt_list) {
+ /* restore the rate from the rate clock list */
+ for (i = 0; i rt_list-count; i++) {
+ if (!rt_list-rates[i])
+ continue;
+ clk_set_rate(rt_list-clks[i], rt_list-rates[i]);
+ rt_list-rates[i] = 0;
+ }
+
[PATCH RFC v2 12/12] arm64: Kconfig: Enable PM_GENERIC_DOMAINS for exynos7
Use power domain driver for Exynos7 SOC's Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm64/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 30bd4d5..b102d0b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -154,6 +154,7 @@ config ARCH_EXYNOS7 bool ARMv8 based Samsung Exynos7 select ARCH_EXYNOS select COMMON_CLK_SAMSUNG + select PM_GENERIC_DOMAINS help This enables support for Samsung Exynos7 SoC family -- 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 RFC v2 10/12] drivers: soc: samsung: Add support for clock enabling in power domain
While turning power domain to on/off, some clocks need to be enabled
in the Exynos7 SOC. This patch adds the framework for enabling those
clocks before on/off and restoring it back after the operation. Also
these list of clocks may be different for on/off operation so not using
the generic pm domain suspend/resume interface.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt | 12 ++
drivers/soc/samsung/pm_domains.c | 138 +++-
2 files changed, 146 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 8d913b9..c48769e 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -24,6 +24,14 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain.
Maximum of 10 sets (N = 0 to 9) are supported.
+- pd-on-en-clocks: List of clock handles. These clocks are required to enabled
+ before turning on a power domain.
+- pd-on-en-clock-names: clocks can be specified as,
+ - clkN: N can vary between 0-30.
+- pd-off-en-clocks: List of clock handles. These clocks are required to enabled
+ before turning off a power domain.
+- pd-off-en-clock-names: clocks can be specified as,
+ - clkN: N can vary between 0-30.
- parents: phandle of parent power domains.
Node of a device using power domains must have a samsung,power-domain property
@@ -43,6 +51,10 @@ Example:
pd-parent-clocks = clock CLK_FIN_PLL, clock
CLK_MOUT_SW_ACLK333,
clock CLK_MOUT_USER_ACLK333;
pd-parent-clock-names = tclk0, pclk0, clk0;
+ pd-on-en-clocks = clock CLK_IP1, clock CLK_IP2,
+ pd-on-en-clock-names = clk0, clk1;
+ pd-off-en-clocks = clock CLK_IP1, clock CLK_IP2,
+ pd-off-en-clock-names = clk0, clk1;
#power-domain-cells = 0;
};
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index 96196f8..5407eb7 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -18,6 +18,7 @@
#include linux/slab.h
#include linux/pm_domain.h
#include linux/clk.h
+#include linux/clk-provider.h
#include linux/delay.h
#include linux/of_address.h
#include linux/of_platform.h
@@ -29,6 +30,12 @@
static struct exynos_pmu_pd_ops *pd_ops;
+struct clk_enable_list {
+ struct clk **clks;
+ unsigned int count;
+ unsigned int en_status;
+};
+
struct clk_parent_list {
struct clk **clks;
struct clk **parent_clks;
@@ -44,6 +51,8 @@ struct exynos_pm_domain {
char const *name;
bool is_off;
struct generic_pm_domain pd;
+ struct clk_enable_list *clk_pd_on;
+ struct clk_enable_list *clk_pd_off;
struct clk_parent_list *clk_parent;
};
@@ -72,6 +81,55 @@ static struct clk *exynos_pd_clk_get(struct device_node *np,
return clk;
}
+static int pd_init_enable_clocks(struct platform_device *pdev,
+ struct device_node *np, bool on, struct exynos_pm_domain *pd)
+{
+ struct clk_enable_list *list;
+ char propname[32], clk_name[8];
+ int count, i;
+ struct clk *clk = ERR_PTR(-ENOENT);
+
+ list = devm_kzalloc(pdev-dev, sizeof(*list), GFP_KERNEL);
+ if (!list)
+ return -ENOMEM;
+
+ if (on) {
+ pd-clk_pd_on = list;
+ snprintf(propname, sizeof(propname), pd-on-en-clock-names);
+ } else {
+ pd-clk_pd_off = list;
+ snprintf(propname, sizeof(propname), pd-off-en-clock-names);
+ }
+
+ count = of_property_count_strings(np, propname);
+ if (!count || count MAX_CLK_PER_DOMAIN)
+ return -EINVAL;
+
+ list-count = count;
+ list-clks = devm_kzalloc(pdev-dev, sizeof(*list-clks) * count,
+ GFP_KERNEL);
+ if (!list-clks)
+ return -ENOMEM;
+
+ if (on)
+ snprintf(propname, sizeof(propname), pd-on-en);
+ else
+ snprintf(propname, sizeof(propname), pd-off-en);
+
+ for (i = 0; i count; i++) {
+ snprintf(clk_name, sizeof(clk_name), clk%d, i);
+ clk = exynos_pd_clk_get(np, propname, clk_name);
+ if (IS_ERR(clk)) {
+ dev_err(pdev-dev, %s clock not found\n, clk_name);
+ return -EINVAL;
+ }
+ list-clks[i] = clk;
+ }
+ dev_info(pdev-dev, pd %s enable clocks initialised\n,
+ on ? on : off);
+ return 0;
+}
+
static int pd_init_parent_clocks(struct platform_device *pdev,
struct
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On Mon, Nov 24, 2014 at 6:46 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: [adding Tushar Behera and Doug Anderson to cc list] Hello, On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). This issue started to look extremely familiar to me so I searched in my mail inbox and found that the same problem was previously reported by Kevin a couple of months ago [0] and Tushar provided a fix [1]. I tested linux-next + [1] and that indeed fixes the hang on Peach. To save you a click, the problem as explained by Tushar is that the AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when the output of AUDSS mux is gated, no operations can be made on the clocks provided by MAU block. For some reason the kernel just oops so it seems to be a H/W errata? Mike was not fond about the solution proposed in [1] but something along those lines would be needed maybe Tushar can comment on that. Vivek and Ajay, As explained in [0], you are not facing this issue because your RW U-Boot seems to predate when audio support was enabled by default. We are using one from Google's build-bot: U-Boot 2013.04-g1eced1c (Nov 20 2014 - 21:27:46) for Peach Can you try executing sound init in the U-Boot prompt and see if that triggers the hang for you? But yes, doing *sound init* do trigger the hang. Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On 20/11/14 03:48, Viresh Kumar wrote: Oh, you are still alive? I thought you were about to get married :) Just kidding !! On 20 November 2014 00:58, Sudeep Holla sudeep.ho...@arm.com wrote: Sorry for raising this issue always with Exynos cpufreq drivers. IMO the bindings for arm-bL-cpufreq-dt is broken. Currently no one is using it and it's better to fix it before we have a real user of it. Hmm, yeah if we can. I haven't found a easy way to go ahead and then got caught in other activities. Agreed, it's not easy but needs to be fixed :) If you look at the binding document for it[1], it has a fixme which shouldn't have been there at first place. It assumes the ordering of CPU's specified in the DT and the logical index allocation to them. Ok, I believe the FIXME is a bit outdated. From the code I can see only this limitation. - For every cluster, the cpu which boots up first should carry the OPPs. Otherwise there is no restriction on ordering of CPUs. Not entirely true, it assuming the fact that the logical index provided by the OS is completely based on the ordering in the DT. - I believe CPUs boot in the order they are present in DT except for the boot CPU. So, the first node for every cluster should have it. Correct ? Then we can update the fixme. No, I disagree as you trying to implicitly depend on the logic Linux uses to assign logical index. It can be changed any time, and depending on it might break things in future which can't be fixed easily later especially if it's DT related. It even breaks for hotplug especially if you hotplug-in back in different order. Hmm, I never thought about it. But yes the CPU with the OPPs should be the first one to come back. How can you assume that ? I can write a simple test which hot-plugs out all the CPUs in the (esp. multi-cluster) system in ascending order of logical index and hot-plug back in descending order. Then the above logic fails. We can work around that probably, but it's better to fix the binding. I failed to grab much attention in my previous attempts to address this[2]. Viresh also started a discussion more recently[3]. They are just stuck and went nowhere :( The platforms needing it have to get involved in such discussions to make any progress. Regards, Sudeep -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pon, 2014-11-24 at 14:16 +0100, Javier Martinez Canillas wrote: [adding Tushar Behera and Doug Anderson to cc list] Hello, On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). This issue started to look extremely familiar to me so I searched in my mail inbox and found that the same problem was previously reported by Kevin a couple of months ago [0] and Tushar provided a fix [1]. I tested linux-next + [1] and that indeed fixes the hang on Peach. To save you a click, the problem as explained by Tushar is that the AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when the output of AUDSS mux is gated, no operations can be made on the clocks provided by MAU block. For some reason the kernel just oops so it seems to be a H/W errata? Mike was not fond about the solution proposed in [1] but something along those lines would be needed maybe Tushar can comment on that. Vivek and Ajay, As explained in [0], you are not facing this issue because your RW U-Boot seems to predate when audio support was enabled by default. Can you try executing sound init in the U-Boot prompt and see if that triggers the hang for you? Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html Thank you for digging this out. It looks like mau_epll is needed to keep audio powered on... Disabling the adma device (from DT) helps. But then $ cat /sys/kernel/debug/clk/clk_summary stops working. Just like ISP clocks (need to keep ISP domain on to read clk_summary). When mau_epll is disabled all of reads and writes to Audio registers fail. When system tries to disable unused adma clock it stucks because Audio domain is off... Still this is strange. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: Add regulator-haptic device node for exynos3250-rinato
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 84380fa..da03005 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -104,6 +104,13 @@
};
};
};
+
+ haptics {
+ compatible = regulator-haptic;
+ haptic-supply = motor_reg;
+ min-microvolt = 110;
+ max-microvolt = 270;
+ };
};
adc {
--
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 v2 1/2] Input: add regulator haptic driver
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/input/regulator-haptic.txt | 24 ++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/regulator-haptic.c | 247
include/linux/input/regulator-haptic.h | 30 +++
5 files changed, 313 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..5a44e8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings
+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+
+Required Properties:
+ - compatible : Should be regulator-haptic
+ - haptic-supply : Power supply to the haptic motor.
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+Example:
+
+ haptics {
+ compatible = regulator-haptic;
+ haptic-supply = motor_regulator;
+ max-microvolt = 270;
+ min-microvolt = 110;
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_REGULATOR_HAPTIC
+ tristate regulator haptics support
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_RETU_PWRBUTTON
tristate Retu Power button Driver
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..c61dd99
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,247 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim jaewon02@samsung.com
+ * Author: Hyunhee Kim hyunhee@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.
+ */
+
+#include linux/input.h
+#include linux/input/regulator-haptic.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct regulator *regulator;
+ struct work_struct work;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int max_volt;
+ unsigned int min_volt;
+ unsigned int intensity;
+ unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
state)
+{
+ int error;
+
+ if (haptic-enabled == state)
+ return;
+
+ if (state)
+ error = regulator_enable(haptic-regulator);
+ else
+ error = regulator_disable(haptic-regulator);
+
[PATCH v2 0/2] Add regulator-haptic driver
This patch series adds regulator-haptic driver. The regulator-haptic has haptic motor and it is controlled by voltage of regulator via force feedback framework. Changes in v2: - remove driver owner - merge enable/disable function - support platform data - fix wrong suspends_state check in regulator_haptic_resume() Jaewon Kim (2): Input: add regulator haptic driver ARM: dts: Add regulator-haptic device node for exynos3250-rinato .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ arch/arm/boot/dts/exynos3250-rinato.dts|7 + drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 247 include/linux/input/regulator-haptic.h | 30 +++ 6 files changed, 320 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c create mode 100644 include/linux/input/regulator-haptic.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
Hi All, On 21/11/14 14:31, Thomas Abraham wrote: Changes since v11: - Rebased on top of git://linuxtv.org/snawrocki/samsung.git for-v3.19-exynos-clk This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq drivers and enables the use of cpufreq-dt driver for these platforms. This series also enables cpufreq support for Exynos5420 using arm_big_little cpufreq driver. This series is based on the following branch. git://linuxtv.org/snawrocki/samsung.git for-v3.19-exynos-clk This series depends on the following patch which can be picked from git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git samsung/dt e540920cf21c (ARM: dts: add CPU nodes for Exynos4 SoCs). This patch series has been tested on Exynos4210/5250/5420 based boards. Tomasz Figa had plans to take this in the Samsung clock tree for v3.19 (http://www.spinics.net/lists/linux-samsung-soc/msg37933.html). Sylwester, could you consider to merge this in your tree? This patch series has already conflicts in arch/arm/boot/dts/ with the arm-soc tree. It touches quite many files at arch/arm. Perhaps we could still have it merged through Kukjin's and arm-soc tree ? Feel free to add for the whole series: Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/2] Fix Arndale Octa/Peach Pi boot on Audio subsystem clocks
Hi, This is initial idea to solve dependency between AudioSS clocks and main clock controller on Exynos platform. This solves boot failure of Peach Pi/Pit and Arndale Octa [1]. It is only RFC/proof of concept because I would like to hear whether this is good direction to solve this particular issue (especially that it touches main clk api). [1] http://www.spinics.net/lists/linux-samsung-soc/msg39331.html Best regards, Krzysztof Kozlowski Krzysztof Kozlowski (2): clk: Allow overriding generic ops for clocks clk: samsung: Fix clock disable failure because domain being gated drivers/clk/clk-gate.c | 16 ++-- drivers/clk/samsung/clk-exynos-audss.c | 69 +++--- include/linux/clk-provider.h | 5 +++ 3 files changed, 74 insertions(+), 16 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/2] clk: samsung: Fix clock disable failure because domain being gated
Audio subsystem clocks are located in separate block. If parent clock
(from main clock domain) 'mau_epll' is gated then any read or write to
audss registers will block.
This was observed on Exynos 5420 platforms (Arndale Octa and Peach
Pi/Pit) after introducing runtime PM to pl330 DMA driver. After that
commit the 'mau_epll' was gated (no users). The system hang on disabling
unused clocks from audss block.
Whenever system wants to operate on audss clock it has to enable epll
clock.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reported-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reported-by: Kevin Hilman khil...@kernel.org
---
drivers/clk/samsung/clk-exynos-audss.c | 69 +++---
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
index acce708ace18..d10286f30b4f 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -29,6 +29,7 @@ static DEFINE_SPINLOCK(lock);
static struct clk **clk_table;
static void __iomem *reg_base;
static struct clk_onecell_data clk_data;
+struct clk *pll_in;
#define ASS_CLK_SRC 0x0
#define ASS_CLK_DIV 0x4
@@ -75,6 +76,48 @@ static const struct of_device_id exynos_audss_clk_of_match[]
= {
{},
};
+static int audss_clk_gate_enable(struct clk_hw *hw)
+{
+ int ret;
+
+ if (!IS_ERR(pll_in))
+ clk_prepare_enable(pll_in);
+ ret = clk_gate_ops.enable(hw);
+ if (!IS_ERR(pll_in))
+ clk_disable_unprepare(pll_in);
+
+ return ret;
+}
+
+static void audss_clk_gate_disable(struct clk_hw *hw)
+{
+ if (!IS_ERR(pll_in))
+ clk_prepare_enable(pll_in);
+ clk_gate_ops.disable(hw);
+ if (!IS_ERR(pll_in))
+ clk_disable_unprepare(pll_in);
+}
+
+static int audss_clk_gate_is_enabled(struct clk_hw *hw)
+{
+ int ret;
+
+ if (!IS_ERR(pll_in))
+ clk_prepare_enable(pll_in);
+ ret = clk_gate_ops.is_enabled(hw);
+ if (!IS_ERR(pll_in))
+ clk_disable_unprepare(pll_in);
+
+ return ret;
+}
+
+/* TODO: Also mux and div */
+const struct clk_ops audss_clk_gate_ops = {
+ .enable = audss_clk_gate_enable,
+ .disable = audss_clk_gate_disable,
+ .is_enabled = audss_clk_gate_is_enabled,
+};
+
/* register exynos_audss clocks */
static int exynos_audss_clk_probe(struct platform_device *pdev)
{
@@ -83,7 +126,7 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
const char *mout_audss_p[] = {fin_pll, fout_epll};
const char *mout_i2s_p[] = {mout_audss, cdclk0, sclk_audio0};
const char *sclk_pcm_p = sclk_pcm0;
- struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
+ struct clk *pll_ref, *cdclk, *sclk_audio, *sclk_pcm_in;
const struct of_device_id *match;
enum exynos_audss_clk_type variant;
@@ -145,33 +188,33 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
mout_i2s, 0, reg_base + ASS_CLK_DIV, 8, 4, 0,
lock);
- clk_table[EXYNOS_SRP_CLK] = clk_register_gate(NULL, srp_clk,
+ clk_table[EXYNOS_SRP_CLK] = clk_register_gate_ops(NULL, srp_clk,
dout_srp, CLK_SET_RATE_PARENT,
- reg_base + ASS_CLK_GATE, 0, 0, lock);
+ reg_base + ASS_CLK_GATE, 0, 0, lock,
audss_clk_gate_ops);
- clk_table[EXYNOS_I2S_BUS] = clk_register_gate(NULL, i2s_bus,
+ clk_table[EXYNOS_I2S_BUS] = clk_register_gate_ops(NULL, i2s_bus,
dout_aud_bus, CLK_SET_RATE_PARENT,
- reg_base + ASS_CLK_GATE, 2, 0, lock);
+ reg_base + ASS_CLK_GATE, 2, 0, lock,
audss_clk_gate_ops);
- clk_table[EXYNOS_SCLK_I2S] = clk_register_gate(NULL, sclk_i2s,
+ clk_table[EXYNOS_SCLK_I2S] = clk_register_gate_ops(NULL, sclk_i2s,
dout_i2s, CLK_SET_RATE_PARENT,
- reg_base + ASS_CLK_GATE, 3, 0, lock);
+ reg_base + ASS_CLK_GATE, 3, 0, lock,
audss_clk_gate_ops);
- clk_table[EXYNOS_PCM_BUS] = clk_register_gate(NULL, pcm_bus,
+ clk_table[EXYNOS_PCM_BUS] = clk_register_gate_ops(NULL, pcm_bus,
sclk_pcm, CLK_SET_RATE_PARENT,
- reg_base + ASS_CLK_GATE, 4, 0, lock);
+ reg_base + ASS_CLK_GATE, 4, 0, lock,
audss_clk_gate_ops);
sclk_pcm_in = devm_clk_get(pdev-dev, sclk_pcm_in);
if (!IS_ERR(sclk_pcm_in))
sclk_pcm_p = __clk_get_name(sclk_pcm_in);
- clk_table[EXYNOS_SCLK_PCM] = clk_register_gate(NULL, sclk_pcm,
+ clk_table[EXYNOS_SCLK_PCM] = clk_register_gate_ops(NULL, sclk_pcm,
[RFC 1/2] clk: Allow overriding generic ops for clocks
For clocks depending on some other clock domain one may want to perform
specific ops before actual enable/disable of gate clock. Allow such case
by accepting supplied ops in new exported function:
clk_register_gate_ops().
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/clk/clk-gate.c | 16 +---
include/linux/clk-provider.h | 5 +
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 51fd87fb7ba6..51802af2d9e7 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -117,11 +117,12 @@ EXPORT_SYMBOL_GPL(clk_gate_ops);
* @bit_idx: which bit in the register controls gating of this clock
* @clk_gate_flags: gate-specific flags for this clock
* @lock: shared register lock for this clock
+ * @ops: clk_ops to use for this clock
*/
-struct clk *clk_register_gate(struct device *dev, const char *name,
+struct clk *clk_register_gate_ops(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
void __iomem *reg, u8 bit_idx,
- u8 clk_gate_flags, spinlock_t *lock)
+ u8 clk_gate_flags, spinlock_t *lock, const struct clk_ops *ops)
{
struct clk_gate *gate;
struct clk *clk;
@@ -142,7 +143,7 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
}
init.name = name;
- init.ops = clk_gate_ops;
+ init.ops = ops;
init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ? parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
@@ -161,4 +162,13 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
return clk;
}
+EXPORT_SYMBOL_GPL(clk_register_gate_ops);
+
+struct clk *clk_register_gate(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 bit_idx,
+ u8 clk_gate_flags, spinlock_t *lock)
+{
+ return clk_register_gate_ops(dev, name, parent_name, flags, reg,
bit_idx, clk_gate_flags, lock, clk_gate_ops);
+}
EXPORT_SYMBOL_GPL(clk_register_gate);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index be21af149f11..6cfc77a9f339 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -290,11 +290,16 @@ struct clk_gate {
#define CLK_GATE_HIWORD_MASK BIT(1)
extern const struct clk_ops clk_gate_ops;
+struct clk *clk_register_gate_ops(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 bit_idx,
+ u8 clk_gate_flags, spinlock_t *lock, const struct clk_ops *ops);
struct clk *clk_register_gate(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
void __iomem *reg, u8 bit_idx,
u8 clk_gate_flags, spinlock_t *lock);
+
struct clk_div_table {
unsigned intval;
unsigned intdiv;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: screen blank causing lockup in exynos-reference/exynos5-v3.18-rc2
Hi Vivek, Vivek Gautam gautamvivek1...@gmail.com writes: On Sat, Nov 22, 2014 at 12:53 AM, Kevin Hilman khil...@kernel.org wrote: Hi Ajay, AJAY KUMAR RAMAKRISHNA SHYMALAMMA ajaykumar...@samsung.com writes: I tried to reproduce the issue which you reported, but I am sorry I am not able to reproduce it. I tried with my patches for DRM on top of Linux-next. I don't see the issue on linux-next either. As I mentioned in the original post, I only see it on the v3.18 branch in the exynos-reference tree. While checking the issue along with Ajay on exynos5-v3.18-rc2 branch on exynos-reference tree, we found out the culprit to be FIMD-SYSMMU. The IOMMU on exynos systems is still WIP, and that's the reason it is disabled in exynos_defconfig too. So we have a small workaround in this branch to stop using FIMD-SYSMMUs. Now, at the bootup time things are OK, since the FIMD-SMMU clocks (CLK_SMMU_FIMD**) are still available. But after bootup all unused clocks are disabled (since we don't want to use clk_ignore_unused in boot arguments), and the consequent blanking-unblanking causes the system to hang. So we have pushed a patch on the same branch exynos5-v3.18-rc2 which sets CLK_IGNORE_UNUSED flag for these SMMU_FIMD** clocks. This fixes the issue of hang what we were seeing. There's another branch exynos5-v3.18-rc5 available, and we have pushed the same patch on that branch too. Please test on your side, and do let us know if things are working fine for you. I've tested the -rc5 branch, and I'm not seeing this issue anymore. Thanks, Kevin -- 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] ASoC: rt5631: Fixing compilation warning when DT is disabled
On Mon, Nov 24, 2014 at 04:52:42PM +0530, Krishna Mohan Dani wrote: Fixes the following compilation warning: Warning: 'rt5631_i2c_dt_ids' defined but not used - when DT is not used. This doesn't apply, please check and resend. signature.asc Description: Digital signature
Re: [PATCH] ASoC: Arndale: Add machine device tree binding documentation for Arndale board
On Mon, Nov 24, 2014 at 12:21:51PM +0530, Krishna Mohan Dani wrote: Document the device tree binding for the Arndale board based machine driver. This is adding binding documentation but I'm not seeing the matching driver - please send the two together. signature.asc Description: Digital signature
[PATCH] drm/exynos: Fix exynos_dpi_remove() parameter
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
exynos_dpi_remove() should receive a exynos_drm_display but when
DRM_EXYNOS_DPI was disabled it was receiving a struct device resulting in
ia compiler warning.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 2e4e91b..2e50634 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -307,7 +307,10 @@ int exynos_dpi_remove(struct exynos_drm_display *display);
#else
static inline struct exynos_drm_display *
exynos_dpi_probe(struct device *dev) { return NULL; }
-static inline int exynos_dpi_remove(struct device *dev) { return 0; }
+static inline int exynos_dpi_remove(struct exynos_drm_display *display)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_DRM_EXYNOS_VIDI
--
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: [RFC 0/2] Fix Arndale Octa/Peach Pi boot on Audio subsystem clocks
Hello Krzysztof, On 11/24/2014 04:18 PM, Krzysztof Kozlowski wrote: Hi, This is initial idea to solve dependency between AudioSS clocks and main clock controller on Exynos platform. This solves boot failure of Peach Pi/Pit and Arndale Octa [1]. I tested this series on an Exynos5420 Peach Pit but I still have the boot hang so it doesn't solve the issue on this board. I'm using linux-next + your patches with exynos_defconfig and without the clk_ignore_unused command line parameter. 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
[PATCH 1/4] drm/exynos: move to_exynos_crtc() macro to main header
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
With this change we allow other pieces of the code to use this macro.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 45026e6..c8a3169 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -20,9 +20,6 @@
#include exynos_drm_encoder.h
#include exynos_drm_plane.h
-#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
- drm_crtc)
-
enum exynos_crtc_mode {
CRTC_MODE_NORMAL, /* normal mode */
CRTC_MODE_BLANK,/* The private plane of crtc is blank */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 2e4e91b..9e14ae6f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -23,6 +23,9 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
+ drm_crtc)
+
/* This enumerates device type. */
enum exynos_drm_device_type {
EXYNOS_DEVICE_TYPE_NONE,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] drm/exynos: remove struct exynos_drm_overlay
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
struct exynos_drm_overlay has no practical advantage nor serves as
important piece of the exynos API design. The only place it was used
was inside the struct exynos_plane which was just causing a extra
access overhead. Users had to access the overlay first and just then
get the plane information it contains.
This patch merges struct exynos_drm_overlay into struct exynos_plane.
It also renames struct exynos_plane to struct exynos_drm_plane.
The rational is to cut one step to access plane information.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 +++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 44
drivers/gpu/drm/exynos/exynos_drm_plane.c | 85 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 38 +++---
drivers/gpu/drm/exynos/exynos_mixer.c | 50 +-
6 files changed, 112 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index e353d35..dbd4227 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -24,7 +24,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device *dev,
int pipe);
void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);
void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
- struct exynos_drm_overlay *overlay);
+ struct exynos_drm_plane *plane);
void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos);
void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index ffef077..ae0dce7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -25,6 +25,7 @@
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
drm_crtc)
+#define to_exynos_plane(x) container_of(x, struct exynos_drm_plane, base)
/* This enumerates device type. */
enum exynos_drm_device_type {
@@ -47,6 +48,7 @@ enum exynos_drm_output_type {
/*
* Exynos drm common overlay structure.
*
+ * @base: plane object
* @fb_x: offset x on a framebuffer to be displayed.
* - the unit is screen coordinates.
* @fb_y: offset y on a framebuffer to be displayed.
@@ -76,11 +78,14 @@ enum exynos_drm_output_type {
* @local_path: in case of lcd type, local path mode on or off.
* @transparency: transparency on or off.
* @activated: activated or not.
+ * @enabled: enabled or not.
*
* this structure is common to exynos SoC and its contents would be copied
* to hardware specific overlay info.
*/
-struct exynos_drm_overlay {
+
+struct exynos_drm_plane {
+ struct drm_plane base;
unsigned int fb_x;
unsigned int fb_y;
unsigned int fb_width;
@@ -107,6 +112,7 @@ struct exynos_drm_overlay {
bool local_path:1;
bool transparency:1;
bool activated:1;
+ bool enabled:1;
};
/*
@@ -188,7 +194,7 @@ struct exynos_drm_manager_ops {
void (*disable_vblank)(struct exynos_drm_manager *mgr);
void (*wait_for_vblank)(struct exynos_drm_manager *mgr);
void (*win_mode_set)(struct exynos_drm_manager *mgr,
- struct exynos_drm_overlay *overlay);
+ struct exynos_drm_plane *plane);
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e5810d1..abd2ca9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -518,44 +518,44 @@ static void fimd_disable_vblank(struct exynos_drm_manager
*mgr)
}
static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
- struct exynos_drm_overlay *overlay)
+ struct exynos_drm_plane *plane)
{
struct fimd_context *ctx = mgr_to_fimd(mgr);
struct fimd_win_data *win_data;
int win;
unsigned long offset;
- if (!overlay) {
- DRM_ERROR(overlay is NULL\n);
+ if (!plane) {
+ DRM_ERROR(plane is NULL\n);
return;
}
- win = overlay-zpos;
+ win = plane-zpos;
if (win == DEFAULT_ZPOS)
win = ctx-default_win;
if (win 0 || win = WINDOWS_NR)
return;
- offset = overlay-fb_x * (overlay-bpp 3);
- offset += overlay-fb_y * overlay-pitch;
+ offset =
[PATCH 3/4] drm/exynos: remove exynos_drm_crtc_plane_* wrappers
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
This functions were doing nothing but calling a manager op function,
so remove them and call the manager directly.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 33 ---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 ++
2 files changed, 15 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e74b6fe..13c7ba5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -410,39 +410,6 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
*dev, int pipe)
spin_unlock_irqrestore(dev-event_lock, flags);
}
-void exynos_drm_crtc_plane_mode_set(struct drm_crtc *crtc,
- struct exynos_drm_overlay *overlay)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)-manager;
-
- if (manager-ops-win_mode_set)
- manager-ops-win_mode_set(manager, overlay);
-}
-
-void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int zpos)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)-manager;
-
- if (manager-ops-win_commit)
- manager-ops-win_commit(manager, zpos);
-}
-
-void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)-manager;
-
- if (manager-ops-win_enable)
- manager-ops-win_enable(manager, zpos);
-}
-
-void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos)
-{
- struct exynos_drm_manager *manager = to_exynos_crtc(crtc)-manager;
-
- if (manager-ops-win_disable)
- manager-ops-win_disable(manager, zpos);
-}
-
void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
{
struct exynos_drm_manager *manager;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c7045a66..7d76861 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -76,6 +76,7 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct
drm_crtc *crtc,
uint32_t src_w, uint32_t src_h)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
+ struct exynos_drm_manager *manager = to_exynos_crtc(crtc)-manager;
struct exynos_drm_overlay *overlay = exynos_plane-overlay;
unsigned int actual_w;
unsigned int actual_h;
@@ -141,7 +142,8 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct
drm_crtc *crtc,
plane-crtc = crtc;
- exynos_drm_crtc_plane_mode_set(crtc, overlay);
+ if (manager-ops-win_mode_set)
+ manager-ops-win_mode_set(manager, overlay);
return 0;
}
@@ -150,26 +152,35 @@ void exynos_plane_commit(struct drm_plane *plane)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_overlay *overlay = exynos_plane-overlay;
+ struct exynos_drm_manager *manager =
to_exynos_crtc(plane-crtc)-manager;
- exynos_drm_crtc_plane_commit(plane-crtc, overlay-zpos);
+ if (manager-ops-win_commit)
+ manager-ops-win_commit(manager, overlay-zpos);
}
void exynos_plane_dpms(struct drm_plane *plane, int mode)
{
struct exynos_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_overlay *overlay = exynos_plane-overlay;
+ struct exynos_drm_manager *manager;
if (mode == DRM_MODE_DPMS_ON) {
if (exynos_plane-enabled)
return;
- exynos_drm_crtc_plane_enable(plane-crtc, overlay-zpos);
+ manager = to_exynos_crtc(plane-crtc)-manager;
+ if (manager-ops-win_enable)
+ manager-ops-win_enable(manager, overlay-zpos);
+
exynos_plane-enabled = true;
} else {
if (!exynos_plane-enabled)
return;
- exynos_drm_crtc_plane_disable(plane-crtc, overlay-zpos);
+ manager = to_exynos_crtc(plane-crtc)-manager;
+ if (manager-ops-win_disable)
+ manager-ops-win_disable(manager, overlay-zpos);
+
exynos_plane-enabled = false;
}
}
--
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 2/4] drm/exynos: expose struct exynos_drm_crtc
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Let other pieces of the driver access struct exynos_drm_crtc as well.
struct exynos_drm_manager will be merged into struct exynos_drm_crtc, in
the sense we will move all its members to exynos_drm_crtc, so to start
this conversion exynos_drm_crtc need to be exposed as well.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 30 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 30 ++
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c8a3169..e74b6fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -20,36 +20,6 @@
#include exynos_drm_encoder.h
#include exynos_drm_plane.h
-enum exynos_crtc_mode {
- CRTC_MODE_NORMAL, /* normal mode */
- CRTC_MODE_BLANK,/* The private plane of crtc is blank */
-};
-
-/*
- * Exynos specific crtc structure.
- *
- * @drm_crtc: crtc object.
- * @manager: the manager associated with this crtc
- * @pipe: a crtc index created at load() with a new crtc object creation
- * and the crtc object would be set to private-crtc array
- * to get a crtc object corresponding to this pipe from private-crtc
- * array when irq interrupt occurred. the reason of using this pipe is that
- * drm framework doesn't support multiple irq yet.
- * we can refer to the crtc to current hardware interrupt occurred through
- * this pipe value.
- * @dpms: store the crtc dpms value
- * @mode: store the crtc mode value
- */
-struct exynos_drm_crtc {
- struct drm_crtc drm_crtc;
- struct exynos_drm_manager *manager;
- unsigned intpipe;
- unsigned intdpms;
- enum exynos_crtc_mode mode;
- wait_queue_head_t pending_flip_queue;
- atomic_tpending_flip;
-};
-
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 9e14ae6f..ffef077 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -215,6 +215,36 @@ struct exynos_drm_manager {
struct exynos_drm_manager_ops *ops;
};
+enum exynos_crtc_mode {
+ CRTC_MODE_NORMAL, /* normal mode */
+ CRTC_MODE_BLANK,/* The private plane of crtc is blank */
+};
+
+/*
+ * Exynos specific crtc structure.
+ *
+ * @drm_crtc: crtc object.
+ * @manager: the manager associated with this crtc
+ * @pipe: a crtc index created at load() with a new crtc object creation
+ * and the crtc object would be set to private-crtc array
+ * to get a crtc object corresponding to this pipe from private-crtc
+ * array when irq interrupt occurred. the reason of using this pipe is that
+ * drm framework doesn't support multiple irq yet.
+ * we can refer to the crtc to current hardware interrupt occurred through
+ * this pipe value.
+ * @dpms: store the crtc dpms value
+ * @mode: store the crtc mode value
+ */
+struct exynos_drm_crtc {
+ struct drm_crtc drm_crtc;
+ struct exynos_drm_manager *manager;
+ unsigned intpipe;
+ unsigned intdpms;
+ enum exynos_crtc_mode mode;
+ wait_queue_head_t pending_flip_queue;
+ atomic_tpending_flip;
+};
+
struct exynos_drm_g2d_private {
struct device *dev;
struct list_headinuse_cmdlist;
--
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] drm/exynos: avoid leak if exynos_dpi_probe() fails
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The component must be deleted if the probe fails.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1bf52ab..abd2ca9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1215,8 +1215,10 @@ static int fimd_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
ctx-display = exynos_dpi_probe(dev);
- if (IS_ERR(ctx-display))
- return PTR_ERR(ctx-display);
+ if (IS_ERR(ctx-display)) {
+ ret = PTR_ERR(ctx-display);
+ goto err_del_component;
+ }
pm_runtime_enable(dev);
--
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: [PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
Hi Thomas,
Thomas Abraham thomas...@samsung.com writes:
Changes since v11:
- Rebased on top of git://linuxtv.org/snawrocki/samsung.git
for-v3.19-exynos-clk
Thanks for rebasing/reposting.
This patch series removes the use of Exynos4210 and Exynos5250 specific
cpufreq
drivers and enables the use of cpufreq-dt driver for these platforms. This
series also enables cpufreq support for Exynos5420 using arm_big_little
cpufreq
driver.
This series is based on the following branch.
git://linuxtv.org/snawrocki/samsung.git for-v3.19-exynos-clk
This series depends on the following patch which can be picked from
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git samsung/dt
e540920cf21c (ARM: dts: add CPU nodes for Exynos4 SoCs).
This patch series has been tested on Exynos4210/5250/5420 based boards.
Tomasz Figa had plans to take this in the Samsung clock tree for v3.19
(http://www.spinics.net/lists/linux-samsung-soc/msg37933.html).
Sylwester, could you consider to merge this in your tree?
I tested this on exynos5800-peach-pi, and noticed a few things.
First, since voltage scaling is not currently supported, the CPU cluster
regulators (vdd_arm, and vdd_kfc) have to be set at sufficietnly high
voltage to support all the OPPs, otherwise things will likely hang. I
think you should include something like the patch below[1] in this
series as well.
Second, as with earlier versions of this series, I'm still seeing lots
of wait_until_divider_stable: timeout in divider stablization messages
coming out when running powertop.
Speaking of powertop, in the frequency stats tab, I'm not seeing 0%
time spent in all the P-states, so not sure what's going on there. The
stats/time_in_state sysfs files under cpufreq seem to show the right
values, so I'm not sure what's going on with powertop there.
Kevin
[1]
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index e8fdda827fc9..5160735aad3b 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -195,8 +195,8 @@
buck2_reg: BUCK2 {
regulator-name = vdd_arm;
- regulator-min-microvolt = 80;
- regulator-max-microvolt = 150;
+ regulator-min-microvolt = 125;
+ regulator-max-microvolt = 125;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
@@ -230,8 +230,8 @@
buck6_reg: BUCK6 {
regulator-name = vdd_kfc;
- regulator-min-microvolt = 80;
- regulator-max-microvolt = 150;
+ regulator-min-microvolt = 1275000;
+ regulator-max-microvolt = 1275000;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = 12500;
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 | 26 +++-
drivers/clk/samsung/Makefile|2 +-
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 +
20 files changed, 266 insertions(+), 463 deletions(-)
delete mode 100644
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? -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 v2 2/2] ARM: dts: Add regulator-haptic device node for exynos3250-rinato
On 11/24/2014 11:50 PM, Jaewon Kim wrote:
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
arch/arm/boot/dts/exynos3250-rinato.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 84380fa..da03005 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -104,6 +104,13 @@
};
};
};
+
+ haptics {
+ compatible = regulator-haptic;
+ haptic-supply = motor_reg;
+ min-microvolt = 110;
+ max-microvolt = 270;
+ };
};
adc {
Looks good to me.
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] Input: add regulator haptic driver
On 11/24/2014 11:50 PM, Jaewon Kim wrote:
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Looks good to me.
I tested this patch on Exynos3250-based Rinato (Samsung Gear2) board.
Tested-by: Chanwoo Choi cw00.c...@samsung.com
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
---
.../devicetree/bindings/input/regulator-haptic.txt | 24 ++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/regulator-haptic.c | 247
include/linux/input/regulator-haptic.h | 30 +++
5 files changed, 313 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..5a44e8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings
+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+
+Required Properties:
+ - compatible : Should be regulator-haptic
+ - haptic-supply : Power supply to the haptic motor.
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+Example:
+
+ haptics {
+ compatible = regulator-haptic;
+ haptic-supply = motor_regulator;
+ max-microvolt = 270;
+ min-microvolt = 110;
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_REGULATOR_HAPTIC
+ tristate regulator haptics support
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_RETU_PWRBUTTON
tristate Retu Power button Driver
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE)+= powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..c61dd99
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,247 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim jaewon02@samsung.com
+ * Author: Hyunhee Kim hyunhee@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.
+ */
+
+#include linux/input.h
+#include linux/input/regulator-haptic.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+
+#define MAX_MAGNITUDE_SHIFT 16
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct regulator *regulator;
+ struct work_struct work;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int max_volt;
+ unsigned int min_volt;
+ unsigned int intensity;
+ unsigned int magnitude;
+};
+
+static void
Re: [RFC 1/2] clk: Allow overriding generic ops for clocks
Quoting Krzysztof Kozlowski (2014-11-24 07:18:31)
For clocks depending on some other clock domain one may want to perform
specific ops before actual enable/disable of gate clock. Allow such case
by accepting supplied ops in new exported function:
clk_register_gate_ops().
If you are not going to use the gate_ops, why use the gate clock at all?
You can create a platform-specific clock type which uses the ops you
specify.
Regards,
Mike
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/clk/clk-gate.c | 16 +---
include/linux/clk-provider.h | 5 +
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 51fd87fb7ba6..51802af2d9e7 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -117,11 +117,12 @@ EXPORT_SYMBOL_GPL(clk_gate_ops);
* @bit_idx: which bit in the register controls gating of this clock
* @clk_gate_flags: gate-specific flags for this clock
* @lock: shared register lock for this clock
+ * @ops: clk_ops to use for this clock
*/
-struct clk *clk_register_gate(struct device *dev, const char *name,
+struct clk *clk_register_gate_ops(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
void __iomem *reg, u8 bit_idx,
- u8 clk_gate_flags, spinlock_t *lock)
+ u8 clk_gate_flags, spinlock_t *lock, const struct clk_ops
*ops)
{
struct clk_gate *gate;
struct clk *clk;
@@ -142,7 +143,7 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
}
init.name = name;
- init.ops = clk_gate_ops;
+ init.ops = ops;
init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ? parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
@@ -161,4 +162,13 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
return clk;
}
+EXPORT_SYMBOL_GPL(clk_register_gate_ops);
+
+struct clk *clk_register_gate(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 bit_idx,
+ u8 clk_gate_flags, spinlock_t *lock)
+{
+ return clk_register_gate_ops(dev, name, parent_name, flags, reg,
bit_idx, clk_gate_flags, lock, clk_gate_ops);
+}
EXPORT_SYMBOL_GPL(clk_register_gate);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index be21af149f11..6cfc77a9f339 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -290,11 +290,16 @@ struct clk_gate {
#define CLK_GATE_HIWORD_MASK BIT(1)
extern const struct clk_ops clk_gate_ops;
+struct clk *clk_register_gate_ops(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 bit_idx,
+ u8 clk_gate_flags, spinlock_t *lock, const struct clk_ops
*ops);
struct clk *clk_register_gate(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
void __iomem *reg, u8 bit_idx,
u8 clk_gate_flags, spinlock_t *lock);
+
struct clk_div_table {
unsigned intval;
unsigned intdiv;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html I'm not surprised that 5420 has issues, but I have not seen any external aborts on neither Chromebook that I have in my farm. Sounds like the secondary cpus should be disabled on those device trees instead, doesn't it? -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] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html I'm not surprised that 5420 has issues, but I have not seen any external aborts on neither Chromebook that I have in my farm. Sounds like the secondary cpus should be disabled on those device trees instead, doesn't it? Er, cluster, not cpus. -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] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
Olof Johansson wrote: On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420- arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422- odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html Hmm...his report was in Sep...I think it should be fine with current -next? To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk which has different bootloader, I couldn't test it...I'll try to make a test farm like you guys... I'm not surprised that 5420 has issues, but I have not seen any Sorry. external aborts on neither Chromebook that I have in my farm. Sounds like the secondary cpus should be disabled on those device trees instead, doesn't it? Er, cluster, not cpus. - 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] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html I'm not surprised that 5420 has issues, but I have not seen any external aborts on neither Chromebook that I have in my farm. Sounds like the secondary cpus should be disabled on those device trees instead, doesn't it? That's possible. Unfortunately, I've gotten very little support from Samsung on this and it was originally reported 2.5 months ago[2], so I think that the 5420 MCPM should be disabled until they can propose the right fix, and actually test it. Also, I tried disabling some CPUs at boot time, but the exynos5422-odroid-xu3 wont' even boot with nr_cpus=1 or 4 (or anything less than 8) Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller
Hi Mark, OK. I don't have provision to test on this board. I will try to test on older boards by disabling manual mode. I tested on exynos5420 peach-pit by enabling auto mode. I used dd command to read 1MB data from spi flash and I compared the result with manual mode. Both are same. I also tested this patch with Javier Martinez Canillas patches for enabling spidev nodes from http://www.spinics.net/lists/linux-samsung-soc/msg39057.html. I read 4MB flashdata from spi by enabling auto mode and compared the result. They look same. Do want some extra tests need to be done for this patch or is it okey? Thanks padma -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Mon, Nov 24, 2014 at 5:50 PM, Kukjin Kim kg...@kernel.org wrote: Olof Johansson wrote: On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420- arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422- odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html Hmm...his report was in Sep...I think it should be fine with current -next? No, it is still broken in linux-next (as I stated above.) Moreover, earlier in this thread you mentioned you were merging some MCPM patches that should address this, but did not respond when I asked which patches you thing should address this issue To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk which has different bootloader, I couldn't test it...I'll try to make a test farm like you guys... Do you have some colleagues with any other 542x hardware? I had assumed that linux-next was being better tested on the publicaly available, and widely available boards like odroid-xu3 and Chromebook2, but I've come to realize the hard way that that is not the case. You mention your board has a different bootloader. Do you suspect there's a bootloader issue on these other platforms? If so, could you elaborate on possible fixes? I'm more than willing to test any proposed fixes, but I'm not familiar enough yet with these SoCs to figure out the underlying issues alone. Until you have a working board farm, you could start having a closer look at the boot logs we're already producing. Admittedly linux-next broken in many ways besides this one for exynos currently, but it has been having these imprecise aborts well before the other recent issues. Also, It's very possible that this issue is not even MCPM related at all, and MCPM is just uncovering a previously hidden bug. It would be very helpful if people more familiar with this hardware and SoC would investigate bug reports like these. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Andreas, On Mon, Nov 24, 2014 at 8:35 PM, Andreas Färber afaer...@suse.de wrote: Hi, Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas: On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote: On 11/21/2014 06:32 PM, Ajay kumar wrote: I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Thanks for forward porting your patches to linux-next. Unfortunately I won't have time to test them until Monday but I wonder why you didn't have the boot issues that we have with next-20141121. I tested your ToT patches on top of next-20141121, this is my git log: 93fe3d7 Revert Revert ARM: exynos_defconfig: Enable options for display panel support 552f74e ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints dbbc293 ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge f29a649 Documentation: bridge: Add documentation for ps8622 DT properties 6ade887 Documentation: devicetree: Add vendor prefix for parade d81c42d Documentation: drm: bridge: move to video/bridge 50b9828 drm/bridge: ptn3460: use gpiod interface 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach f3cf063 drm/bridge: ptn3460: support drm_panel cab682b drm/exynos: dp: support drm_bridge 6e78916 drm/bridge: ptn3460: Convert to i2c driver model 93f4b5f drm/bridge: make bridge registration independent of drm flow 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init eb6996e drm/bridge: ptn3460: Few trivial cleanups c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 51b2c75 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I found that the commit ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) had to be reverted in order to boot linux-next. Display works but I needed to revert the mentioned commit, otherwise the boot hangs as reported before. I'm using exynos_defconfig and this kernel command line: console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw I tested Spring with next-20141124, and finally got it to work! :) That's great to hear! Thanks a lot, Ajay and Javier! To be on the safe side, I reverted the patch pointed out by Javier and was still using clk_ignore_unused. Ajay, note that your rebased Snow patch has the last hunk indented one level too deep. Ahh, right. I just saw that. I am not sure if these patches go in just like this, or I need to rebase on top of kukjin's for-next or some other branch/tree! Will take care of this, then. I'll post a cleaned-up bridge patch for Spring later. Ok, AFAIK, peach_pit DT properties can be reused. 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] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
Hello Kevin, On Tue, Nov 25, 2014 at 8:50 AM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 5:50 PM, Kukjin Kim kg...@kernel.org wrote: Olof Johansson wrote: On Mon, Nov 24, 2014 at 5:37 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 5:35 PM, Kevin Hilman khil...@kernel.org wrote: On Mon, Nov 24, 2014 at 4:25 PM, Olof Johansson o...@lixom.net wrote: On Mon, Nov 24, 2014 at 11:51 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin, On Mon, Nov 10, 2014 at 11:35 AM, Kevin Hilman khil...@kernel.org wrote: Kukjin Kim kg...@kernel.org writes: Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts during boot testing, causing various userspace startup failures. Disable until it has gotten more testing. Cc: Kukjin Kim kgene@samsung.com, Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk, Cc: Sachin Kamat sachin.ka...@samsung.com, Cc: Doug Anderson diand...@chromium.org, Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com, Cc: Krzysztof Kozlowski k.kozlow...@samsung.com, Cc: Tushar Behera tushar.beh...@linaro.org, Cc: sta...@vger.kernel.org # v3.17+ Signed-off-by: Kevin Hilman khil...@linaro.org --- This has been reported by a few people[1], but not investigated or fixed, so it's time to disable this feature until it can be fixed. Hi Kevin, Yeah I agree with your opinion. But as you can see my tree, I've queued regarding mcpm patches for 3.19 will be shown in -next in this weekend. Which of the recently queued patches are expected to address the imprecise abort issue? I'd be happy to test them out. Exynos5 MCPM is still broken in linux-next and still causing an imprecise abort. What is the status of $SUBJECT patch? Anyway let me apply this into -fixes and then let's enable after test its functionality in -next in a couple of days. Yes, I think this needs to be applied until these aborts are understood and fixed. Is anyone at Samsung actually looking into these MCPM issues? Hi Kevin, What hardware are you having problems with? 5420 or 5422/5800? Yes. :) exynos5420-arndale-octa: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5420- arndale-octa.html exynos5422-odroid-xu3: http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc6/arm-exynos_defconfig/boot-exynos5422- odroid-xu3.html My boot tests seem to pass fine because I have such a minimal userspace, but Tyler Baker reported that with a real userspace, he can't boot to a shell: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286203.html Hmm...his report was in Sep...I think it should be fine with current -next? No, it is still broken in linux-next (as I stated above.) Moreover, earlier in this thread you mentioned you were merging some MCPM patches that should address this, but did not respond when I asked which patches you thing should address this issue To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk which has different bootloader, I couldn't test it...I'll try to make a test farm like you guys... Do you have some colleagues with any other 542x hardware? I had assumed that linux-next was being better tested on the publicaly available, and widely available boards like odroid-xu3 and Chromebook2, but I've come to realize the hard way that that is not Are you seeing this on Chromebook2 (Peach-Pi 5800) too ? the case. You mention your board has a different bootloader. Do you suspect there's a bootloader issue on these other platforms? If so, could you elaborate on possible fixes? I'm more than willing to test any proposed fixes, but I'm not familiar enough yet with these SoCs to figure out the underlying issues alone. Until you have a working board farm, you could start having a closer look at the boot logs we're already producing. Admittedly linux-next broken in many ways besides this one for exynos currently, but it has been having these imprecise aborts well before the other recent issues. Also, It's very possible that this issue is not even MCPM related at all, and MCPM is just uncovering a previously hidden bug. It would be very helpful if people more familiar with this hardware and SoC would investigate bug reports like these. The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and Chromebook Peach-Pit) work fine with MCPM enabled. I am not sure why it is failing only on the above mentioned boards as there is nothing specific to them in the MCPM back-end. I assume that when you default to platsmp (on disabling MCPM), the non-working boards boot all cores upto userspace without any issues ? Based on the timeline (problems started about 2.5 months back), there have only been a couple of changes in the 5420 MCPM back-end.
[RFC] ARM: exynos: MCPM: [is this a] fix for secondary boot on 5422?
From: Kevin Hilman khil...@linaro.org Using the current exynos_defconfig on the exynos5422-odroid-xu3, only 6 of 8 CPUs come online with MCPM boot. CPU0 is an A7, CPUs 1-4 are A15s and CPU5-7 are the other A7s, but with the current code, CPUs 5 and 7 do not boot: [...] Exynos MCPM support installed CPU1: update cpu_capacity 1535 CPU1: thread -1, cpu 0, socket 0, mpidr 8000 CPU2: update cpu_capacity 1535 CPU2: thread -1, cpu 1, socket 0, mpidr 8001 CPU3: update cpu_capacity 1535 CPU3: thread -1, cpu 2, socket 0, mpidr 8002 CPU4: update cpu_capacity 1535 CPU4: thread -1, cpu 3, socket 0, mpidr 8003 CPU5: failed to come online CPU6: update cpu_capacity 448 CPU6: thread -1, cpu 2, socket 1, mpidr 8102 CPU7: failed to come online Brought up 6 CPUs CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x13) CPU: This may indicate a broken bootloader or firmware. Thanks to a tip from Abhilash, this patch gets all 8 CPUs booting again, but the warning about CPUs started in inconsistent modes remains. Also, not being terribly familiar with Exynos internals, it's not at all obvious to me why this register write (done for *all* secondaries) makes things work works for the 2 secondary CPUs that didn't come online. It's also not obvious whether this is the right general fix, since it doesn't seem to be needed on other 542x or 5800 platforms. I suspect the right fix is in the bootloader someplace, but not knowing this hardware well, I'm not sure if the fix is in u-boot proper, or somewhere in the binary blobs (bl1/bl2/tz) that start before u-boot. The u-boot I'm using is from the hardkernel u-boot repo[1], and I'd welcome any suggestions to try. I'm able to rebuild my own u-boot from there, but only have binaries for bl1/bl2/tz. [1] branch odroidxu3-v2012.07 of: https://github.com/hardkernel/u-boot.git Cc: Mauro Ribeiro mauro.ribe...@hardkernel.com Cc: Abhilash Kesavan a.kesa...@samsung.com, Cc: Andrew Bresticker abres...@chromium.org Cc: Doug Anderson diand...@chromium.org Cc: Nicolas Pitre nicolas.pi...@linaro.org Signed-off-by: Kevin Hilman khil...@linaro.org --- arch/arm/mach-exynos/mcpm-exynos.c | 2 ++ arch/arm/mach-exynos/regs-pmu.h| 1 + 2 files changed, 3 insertions(+) diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c index b0d3c2e876fb..612a770d5284 100644 --- a/arch/arm/mach-exynos/mcpm-exynos.c +++ b/arch/arm/mach-exynos/mcpm-exynos.c @@ -88,6 +88,8 @@ static int exynos_power_up(unsigned int cpu, unsigned int cluster) cluster = EXYNOS5420_NR_CLUSTERS) return -EINVAL; + pmu_raw_writel(0x1, S5P_PMU_SPARE2); + /* * Since this is called with IRQs enabled, and no arch_spin_lock_irq * variant exists, we need to disable IRQs manually here. diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index b5f4406fc1b5..70d9eb5a4fcc 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -49,6 +49,7 @@ #define S5P_INFORM50x0814 #define S5P_INFORM60x0818 #define S5P_INFORM70x081C +#define S5P_PMU_SPARE2 0x0908 #define S5P_PMU_SPARE3 0x090C #define EXYNOS_IROM_DATA2 0x0988 -- 2.1.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: [PATCH RFC v2 06/12] driver: soc: exynos-pmu: Add exynos7 power domain on/off ops
On 24 November 2014 at 14:04, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch uses the restructuring done in PD handlers and adds PD
on/off/status handlers for exynos7. In this SoC, some extra settings
need to be done prior to turning on/off power domains. Some of those
settings are also different from different power domains so is uses
the power domain compatible name feature to distinguish between power
domains.
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/soc/samsung/exynos-pmu.c| 105
+++
include/linux/soc/samsung/exynos-regs-pmu.h | 17 +
2 files changed, 122 insertions(+)
diff --git a/drivers/soc/samsung/exynos-pmu.c
b/drivers/soc/samsung/exynos-pmu.c
index e690f65..b9631d5 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -1202,6 +1202,104 @@ static void exynos7_pmu_init(void)
}
}
+static int exynos7_pd_extraconf_base(const char *pd_name)
+{
+ if (!pd_name)
+ return -EINVAL;
+
+ if (!strcmp(samsung,exynos7-pd-mfc, pd_name))
+ return EXYNOS7_CLKRUN_CMU_MFC_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-hevc, pd_name))
+ return EXYNOS7_CLKRUN_CMU_HEVC_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-mscl, pd_name))
+ return EXYNOS7_CLKRUN_CMU_MSCL_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-g2d, pd_name))
+ return EXYNOS7_CLKRUN_CMU_G2D_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-fsys0, pd_name))
+ return EXYNOS7_CLKRUN_CMU_FSYS0_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-fsys1, pd_name))
+ return EXYNOS7_CLKRUN_CMU_FSYS1_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-aud, pd_name))
+ return EXYNOS7_CLKRUN_CMU_AUD_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-disp, pd_name))
+ return EXYNOS7_CLKRUN_CMU_DISP_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-vpp, pd_name))
+ return EXYNOS7_CLKRUN_CMU_VPP_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-vpp, pd_name))
+ return EXYNOS7_CLKRUN_CMU_VPP_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-isp0, pd_name))
+ return EXYNOS7_CLKRUN_CMU_ISP0_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-isp1, pd_name))
+ return EXYNOS7_CLKRUN_CMU_ISP1_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-cam0, pd_name))
+ return EXYNOS7_CLKRUN_CMU_CAM0_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-cam1, pd_name))
+ return EXYNOS7_CLKRUN_CMU_CAM1_SYS_PWR_REG;
+ else if (!strcmp(samsung,exynos7-pd-g3d, pd_name))
+ return EXYNOS7_CLKRUN_CMU_CAM1_SYS_PWR_REG;
I think we should move away from using strings to find a matching PM
domain. Instead we should use a enum/define pointing to the PM domain
in an array of PM domains, or similar.
The UX500 SOC initial support for PM domains is queued for 3.19 and is
currently available in linux-next. You may want to get some
inspiration from that approach.
+
+ pr_err(%s: Unsupported power domain\n, pd_name);
+ return 0;
+}
+
+static int exynos7_pd_powerdown(const char *pd_name, void __iomem *pd_addr)
+{
Considering the suggestion above and to move away from using strings
like this; this function could take a pointer to the PM domain instead
of a string and the __iomem, right!?
+ int off_base = exynos7_pd_extraconf_base(pd_name);
+
+ if (!off_base)
+ return -EINVAL;
+
+ /* Initialise the pd extraconf registers */
+ pmu_raw_writel(0, off_base + EXYNOS7_CLKRUN_CMU_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_CLKSTOP_CMU_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_DISABLE_PLL_CMU_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_RESET_LOGIC_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_MEMORY_PD_SYS_PWR_REG);
+ pmu_raw_writel(0, off_base + EXYNOS7_RESET_CMU_PD_SYS_PWR_REG);
+
+ if (!strcmp(samsung,exynos7-pd-fsys0, pd_name) ||
+ !strcmp(samsung,exynos7-pd-fsys1, pd_name))
+ pmu_raw_writel(1,
+ off_base +
EXYNOS7_RESET_SLEEP_PD_SYS_PWR_REG);
+
+ if (!strcmp(samsung,exynos7-pd-aud, pd_name)) {
+ pmu_raw_writel(0, EXYNOS7_PAD_RETENTION_AUD_SYS_PWR_REG);
+ pmu_raw_writel(0, EXYNOS7_GPIO_MODE_AUD_SYS_PWR_REG);
+ }
+
+ writel_relaxed((EXYNOS7_USE_PROLONGED_LOGIC_RESET |
+ EXYNOS7_USE_SC_FEEDBACK), pd_addr + EXYNOS_PD_OPTION);
+
+ return 0;
+}
+
+static int exynos7_pd_poweron(const char *pd_name, void __iomem *pd_addr)
+{
+ if (exynos7_pd_powerdown(pd_name, pd_addr))
+
Re: [PATCH RFC v2 07/12] PM / Domains: export pm_genpd_lookup_name
On 24 November 2014 at 14:04, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This API may be needed to set the power domain parent/child relationship
in the power domain platform driver. The parent relationship is
generally set after the child power domain is registered with the power
domain subsystem. In this case, pm_genpd_lookup_name API might be
useful.
I think this is a step in the wrong direction. Instead we should be
working on removing the name based APIs from genpd.
The proper way should be to pass the PM domain as a parameter to the
APIs instead.
Kind regards
Uffe
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
drivers/base/power/domain.c |3 ++-
include/linux/pm_domain.h |7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index fb83d4a..b0e1c2f 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -49,7 +49,7 @@
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);
-static struct generic_pm_domain *pm_genpd_lookup_name(const char
*domain_name)
+struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
{
struct generic_pm_domain *genpd = NULL, *gpd;
@@ -66,6 +66,7 @@ static struct generic_pm_domain *pm_genpd_lookup_name(const
char *domain_name)
mutex_unlock(gpd_list_lock);
return genpd;
}
+EXPORT_SYMBOL_GPL(pm_genpd_lookup_name);
struct generic_pm_domain *dev_to_genpd(struct device *dev)
{
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 2e0e06d..aedcec3 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -150,6 +150,8 @@ extern int pm_genpd_name_poweron(const char *domain_name);
extern struct dev_power_governor simple_qos_governor;
extern struct dev_power_governor pm_domain_always_on_gov;
+
+extern struct generic_pm_domain *pm_genpd_lookup_name(const char
*domain_name);
#else
static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev)
@@ -221,6 +223,11 @@ static inline int pm_genpd_name_poweron(const char
*domain_name)
{
return -ENOSYS;
}
+static inline
+struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
+{
+ return NULL;
+}
#define simple_qos_governor NULL
#define pm_domain_always_on_gov NULL
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 08/12] soc: samsung: pm_domain: Add support for parent power domain
On 24 November 2014 at 14:04, Amit Daniel Kachhap
amit.dan...@samsung.com wrote:
This patch adds supports for parent power domain. This will ensure
invoking of parent/child power domain on/off in a correct sequence.
In exynos7 SOC's, power domain controllers have parent and child
hierarchy.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt |2 +
drivers/soc/samsung/pm_domains.c | 43
+++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 00ebda1..0160bdc 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -24,6 +24,7 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
+- parents: phandle of parent power domains.
Node of a device using power domains must have a samsung,power-domain
property
defined with a phandle to respective power domain.
@@ -48,6 +49,7 @@ Example:
mfc_pd: power-domain@10044060 {
compatible = samsung,exynos4210-pd,
samsung,exynos7-pd-mfc;
reg = 0x10044060 0x20;
+ parents = pd_top;
#power-domain-cells = 0;
};
This seems like a good and generic approach to describe that a PM
domain could have a parent. I would suggest to rename it, such it
reflects its a PM domain binding though.
So, maybe we can add this as a common DT binding for the generic PM
domain instead of having it as Exynos specific?
Kind regards
Uffe
--
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
