Re: [PATCH 2/2] cpufreq: Remove exynos_sort_descend_freq_table in exynos5440-cpufreq.c
On 29 April 2014 11:44, Amit Kachhap amit.kach...@gmail.com wrote: In the frequency table dts file, the frequencies are arranged in descending order which maps 1 to 1 with other frequency parameter to be calculated and programmed in some registers. But the OPP library works by generating the frequencies in ascending order which breaks the above logic. Ideally i should expect frequency values in same order as what is supplied. So OPP library should not change the order or should take input flags flags like, dev_pm_opp_init_cpufreq_table(TABLE_ORDER_ASCEND| TABLE_ORDER_DESCEND|TABLE_ORDER_ORIGINAL ) Looks a good idea :) This is what I wrote in another thread: What I would recommend is, use .driver_data field to hold what has to be written to hardware for any frequency. And then simply use driver_data instead of index. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: dts: Add PD entry to MFC codec on 5420
PD entry was missing in MFC codec node.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos5420.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6f662b5cc90d..2fd36b0a7568 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -131,6 +131,7 @@
interrupts = 0 96 0;
clocks = clock CLK_MFC;
clock-names = mfc;
+ samsung,power-domain = mfc_pd;
};
mmc_0: mmc@1220 {
--
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: [PATCHv2] ARM: dts: exynos4: clean up arm-pmu node
On 04/25/2014 07:35 AM, Chanho Park wrote:
This patch cleans a arm-pmu node up for exynos4. Only exynos4412 series
boards have four pmu interrupts. Rest of exynos4 boards, except 4412, have
only
two pmu interrupts. Thus, we can define two interrupts in the
exynos4.dtsi and extends the interrupts only exynos4412.dtsi.
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
Tested on Exynos4210 based Origen and Exynos4412 based Origenquad boards.
Tested-by: Tushar Behera tushar.beh...@linaro.org
Changes from v1:
- Remove duplicated properties in exynos4412.dtsi(Comment from Tomasz Figa)
arch/arm/boot/dts/exynos4.dtsi| 6 ++
arch/arm/boot/dts/exynos4210.dtsi | 6 --
arch/arm/boot/dts/exynos4412.dtsi | 4
arch/arm/boot/dts/exynos4x12.dtsi | 6 --
4 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0401f4d..b43dc24 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -105,6 +105,12 @@
reg = 0x1044 0x1000;
};
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupt-parent = combiner;
+ interrupts = 2 2, 3 2;
+ };
+
sys_reg: syscon@1001 {
compatible = samsung,exynos4-sysreg, syscon;
reg = 0x1001 0x400;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cb0e768d..e19c154 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -75,12 +75,6 @@
#clock-cells = 1;
};
- pmu {
- compatible = arm,cortex-a9-pmu;
- interrupt-parent = combiner;
- interrupts = 2 2, 3 2;
- };
-
pinctrl_0: pinctrl@1140 {
compatible = samsung,exynos4210-pinctrl;
reg = 0x1140 0x1000;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index a40b6e2..7b75762 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,10 @@
samsung,combiner-nr = 20;
};
+ pmu {
+ interrupts = 2 2, 3 2, 18 2, 19 2;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x4000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306..b730a74 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,12 +31,6 @@
mshc0 = mshc_0;
};
- pmu {
- compatible = arm,cortex-a9-pmu;
- interrupt-parent = combiner;
- interrupts = 2 2, 3 2, 18 2, 19 2;
- };
-
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
--
Tushar Behera
--
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-RESEND] ARM: dts: Add arm-pmu node for exynos4412
Hi Tushar,
-Original Message-
From: Tushar Behera [mailto:tushar.beh...@linaro.org]
Sent: Tuesday, April 29, 2014 3:08 PM
To: Chanho Park; kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org; thomas.abra...@linaro.org; linux-
arm-ker...@lists.infradead.org; Kyungmin Park
Subject: Re: [PATCH-RESEND] ARM: dts: Add arm-pmu node for exynos4412
On 08/09/2013 04:11 PM, Chanho Park wrote:
The Exynos4412 has 4 cpus and each has a performance counter.
Thus, we should define 4 interrupts which are combined by irq-combiner
for arm
pmu.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4412.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index e743e67..cfad655 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -35,6 +35,12 @@
0 107 0, 0 108 0, 0 48 0, 0 42 0;
};
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupt-parent = combiner;
+ interrupts = 2 2, 3 2, 18 2, 19 2;
+ };
+
mct@1005 {
compatible = samsung,exynos4412-mct;
reg = 0x1005 0x800;
Tested on Exynos4412 based Origen-Quad board. You would required to
rebase it on latest code though.
Tested-by: Tushar Behera tushar.beh...@linaro.org
You took old patch which I cannot remember now:) Actually, arm-pmu support
for exynos4412 was already merged in the latest code.[1]. I sent a clean-up
patch recently[2]. It could be more readable for exynos4412.
Thanks.
[1] : https://lkml.org/lkml/2014/3/12/27
[2] : http://www.spinics.net/linux/lists/arm-kernel/msg325565.html
Best Regards,
Chanho Park
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] cpufreq: Remove exynos_sort_descend_freq_table in exynos5440-cpufreq.c
Thanks to Amit Kachhap Viresh Kumar -Original Message- From: Viresh Kumar [mailto:viresh.ku...@linaro.org] Sent: Tuesday, April 29, 2014 3:21 PM To: Amit Kachhap Cc: Jonghwan Choi; Kukjin Kim; linux-samsung-soc; Rafael J. Wysocki; linux-arm-ker...@lists.infradead.org; open list:CPU FREQUENCY DRI... Subject: Re: [PATCH 2/2] cpufreq: Remove exynos_sort_descend_freq_table in exynos5440-cpufreq.c On 29 April 2014 11:44, Amit Kachhap amit.kach...@gmail.com wrote: In the frequency table dts file, the frequencies are arranged in descending order which maps 1 to 1 with other frequency parameter to be calculated and programmed in some registers. But the OPP library works by generating the frequencies in ascending order which breaks the above logic. Ideally i should expect frequency values in same order as what is supplied. So OPP library should not change the order or should take input flags flags like, dev_pm_opp_init_cpufreq_table(TABLE_ORDER_ASCEND| TABLE_ORDER_DESCEND|TABLE_ORDER_ORIGINAL ) Looks a good idea :) This is what I wrote in another thread: What I would recommend is, use .driver_data field to hold what has to be written to hardware for any frequency. And then simply use driver_data instead of index. -- 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: [RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
On 04/28/2014 09:26 PM, Lee Jones wrote: This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) So I just took a look at the code as zero changes looks suspicious to me. The driver can not simply be copied and pasted into the MFD subsystem in its current state. The fundamental question is; is this chip actually an MFD? What does it do besides Power Management? Exynos PMU chip controls different power states of Exynos, so mainly it does power management related stuff. Apart from this it has few registers which controls PHY of various IP blocks of Exynos such as USB, HDMI, ADC etc. But these phy controlling register are currently being accessed via syscon driver provided regmap APIs. For same the same reason Exynos PMU has second compatibility string as syscon. diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 2f60c90..79559b4 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -27,6 +27,7 @@ config ARCH_EXYNOS4 select PM_GENERIC_DOMAINS if PM_RUNTIME select S5P_DEV_MFC select MFD_SYSCON + select MFD_EXYNOS_PMU help Samsung EXYNOS4 SoCs based systems @@ -38,6 +39,7 @@ config ARCH_EXYNOS5 select HAVE_SMP select PINCTRL select MFD_SYSCON + select MFD_EXYNOS_PMU help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index a656dbe..19fdf17 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -18,8 +18,6 @@ obj-$(CONFIG_PM_SLEEP)+= pm.o sleep.o obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o obj-$(CONFIG_CPU_IDLE)+= cpuidle.o -obj-$(CONFIG_ARCH_EXYNOS) += pmu.o - obj-$(CONFIG_SMP) += platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..fd48870 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1203,6 +1203,15 @@ config MFD_STW481X in various ST Microelectronics and ST-Ericsson embedded Nomadik series. +config MFD_EXYNOS_PMU + tristate Support Exynos Power Managment Unit + depends on ARM || ARM64 + help + Exynos SoC have Power Management Unit (PMU) which controls power and + operation state of Exynos SoC in two different ways. This driver + provides impmentation of PMU driver and provides basic functionality + required during these operation state. + menu Multimedia Capabilities Port drivers depends on ARCH_SA1100 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 2851275..7c43d07 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -166,3 +166,4 @@ obj-$(CONFIG_MFD_RETU) += retu-mfd.o obj-$(CONFIG_MFD_AS3711) += as3711.o obj-$(CONFIG_MFD_AS3722) += as3722.o obj-$(CONFIG_MFD_STW481X) += stw481x.o +obj-$(CONFIG_MFD_EXYNOS_PMU) += exynos-pmu.o diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/mfd/exynos-pmu.c similarity index 100% rename from arch/arm/mach-exynos/pmu.c rename to drivers/mfd/exynos-pmu.c -- Best Regards, Pankaj Dubey -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
On 04/29/2014 02:37 AM, Catalin Marinas wrote: On Mon, Apr 28, 2014 at 01:26:46PM +0100, Lee Jones wrote: This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) So I just took a look at the code as zero changes looks suspicious to me. The driver can not simply be copied and pasted into the MFD subsystem in its current state. The fundamental question is; is this chip actually an MFD? What does it do besides Power Management? I looked at the code briefly as well and I don't think it matches the mfd idea. Maybe it could be merged together with arch/arm/mach-exynos/pm.c and moved to drivers/power/ or a more appropriate directory for platform_suspend_ops. Well I was also not quite sure about if drivers/mfd is proper place for Exynos PMU, so I posted this patch as RFC. If it does not seems matching with drivers/mfd idea, will it be suitable for drivers/power/ or should I go for something like drivers/soc/samsung? Regarding your second point about merging this code with mach-exynos/pm.c We have plan for this but, I would like to get it done via a separate patch series as mach-exynos/pm.c has a lot of dependencies and requires significant modifications. So this work can be treated as a first step towards that direction. -- Best Regards, Pankaj Dubey -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RESEND] ARM: dts: Add arm-pmu node for exynos4412
On 04/29/2014 12:26 PM, Chanho Park wrote:
Hi Tushar,
-Original Message-
From: Tushar Behera [mailto:tushar.beh...@linaro.org]
Sent: Tuesday, April 29, 2014 3:08 PM
To: Chanho Park; kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org; thomas.abra...@linaro.org; linux-
arm-ker...@lists.infradead.org; Kyungmin Park
Subject: Re: [PATCH-RESEND] ARM: dts: Add arm-pmu node for exynos4412
On 08/09/2013 04:11 PM, Chanho Park wrote:
The Exynos4412 has 4 cpus and each has a performance counter.
Thus, we should define 4 interrupts which are combined by irq-combiner
for arm
pmu.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos4412.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index e743e67..cfad655 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -35,6 +35,12 @@
0 107 0, 0 108 0, 0 48 0, 0 42 0;
};
+ pmu {
+ compatible = arm,cortex-a9-pmu;
+ interrupt-parent = combiner;
+ interrupts = 2 2, 3 2, 18 2, 19 2;
+ };
+
mct@1005 {
compatible = samsung,exynos4412-mct;
reg = 0x1005 0x800;
Tested on Exynos4412 based Origen-Quad board. You would required to
rebase it on latest code though.
Tested-by: Tushar Behera tushar.beh...@linaro.org
You took old patch which I cannot remember now:) Actually, arm-pmu support
for exynos4412 was already merged in the latest code.[1]. I sent a clean-up
patch recently[2]. It could be more readable for exynos4412.
Thanks.
I realized that a little late. I have replied to the new patch with my
Tested-by.
[1] : https://lkml.org/lkml/2014/3/12/27
[2] : http://www.spinics.net/linux/lists/arm-kernel/msg325565.html
Best Regards,
Chanho Park
--
Tushar Behera
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3 3/5] mfd: tps65090: Stop caching most registers
On Mon, 28 Apr 2014, Doug Anderson wrote: Lee, On Mon, Apr 28, 2014 at 4:57 AM, Lee Jones lee.jo...@linaro.org wrote: Nearly all of the registers in tps65090 combine control bits and status bits. Turn off caching of all registers except the select few that can be cached. Lee, I don't mind if I apply this and send a pull request to you or I pull a tag from you with this in - what's easiest for you? I'm happy to do it. Doug, Can you send the patch-set again with all of the *-bys and ensure I'm on TO or CC please? It looks as if you've already applied 1, 3, and 4. I've sent up 2 and 5 again with collected tags. https://patchwork.kernel.org/patch/4042761/ https://patchwork.kernel.org/patch/4042751/ I think we have this sorted now. I sent a pull-request to Mark this morning. Thanks! I'll keep an eye on linux-next to make sure everything is there. It sounds like the charger patch https://patchwork.kernel.org/patch/4042751/ wasn't picked up by anyone. I'll see if I can find someone to take that. Luckily that can be applied independently of everything else (it just won't fix everything till all the patches are together). You still need an Ack from Anton before I can apply that. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver
On 04/29/2014 03:02 PM, YoungJun Cho wrote:
Hi Laurent,
Thank you for sharing your idea.
On 04/29/2014 12:05 AM, Laurent Pinchart wrote:
Hi YoungJun,
On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569
++
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
[snip]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
[snip]
+static int s6e3fa0_get_modes(struct drm_panel *panel)
+{
+struct drm_connector *connector = panel-connector;
+struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+struct drm_display_mode *mode;
+
+mode = drm_mode_create(connector-dev);
+if (!mode) {
+DRM_ERROR(failed to create a new display mode\n);
+return 0;
+}
+
+drm_display_mode_from_videomode(ctx-vm, mode);
+mode-width_mm = ctx-width_mm;
+mode-height_mm = ctx-height_mm;
+connector-display_info.width_mm = mode-width_mm;
+connector-display_info.height_mm = mode-height_mm;
+
+mode-type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+mode-private = (void *)ctx-cpu_timings;
Wouldn't it make sense to create a new get_interface_params (or
similar)
operation for drm_panel to query interface configuration parameters
instead of shoving it in the mode private field ?
You mean new get_interface_params operation is different from
get_modes() ?
Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.
I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.
Could you explain it in more detail?
The idea is that the interface parameters (RD/WR signals timings in
this case,
but this could also include MIPI DSI lane configuration or any other
kind of
physical interface parameters) are distinct from the video modes.
Yes. The RD/WR signals timings are distinct from the video modes,
but in my opinion, others are covered by video mode already.
Do you see a need to tie tie interface parameters with
drm_display_mode ? Can
they be mode-specific ? In any case I'd like not to use the private
field of
drm_display_mode. If we need to tie both information together then it
should
be done in a standard way.
I think this cpu-mode-timings is in struct drm_display_mode
(NOT by *private) and requires drm_display_mode_from_cpumode()
because the drm_display_mode_from_videomode() covers only video mode.
I'll try implement it as soon as possible.
For your information, there are two modes in MIPI DSI specification,
which are video mode and command mode.
And CS, RD/WR timings are related with MIPI DBI specification,
VSYNC, HSYNC timings are related with MIPI DPI specification.
So I think all things relevant with command mode should be arranged
the name of command mode(NOT CPU mode, like video mode NOT RGB mode)
in MIPI DSI, and we don't need to consider MIPI DBI like we do MIPI DPI
for video mode.
Thank you.
Best regards YJ
Thank you,
Best regards YJ.
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/4] ARM: dts: exynos4: add exynos_usbphy node
Hi Chanho,
On 25 April 2014 12:29, Chanho Park chanho61.p...@samsung.com wrote:
This patch enables a exynos_usbphy node for exynos4 SoCs.
A exynos4x12 usb phy node is almost same with 4210's one
except compatible string and pmu syscon.
Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi| 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 5 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 264066f..5f9b23b 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -278,6 +278,16 @@
status = disabled;
};
+ exynos_usbphy: exynos-usbphy@125B {
+ compatible = samsung,exynos4210-usb2-phy;
+ reg = 0x125B 0x100;
+ samsung,pmureg-phandle = pmu_system_controller;
+ clocks = clock CLK_USB_DEVICE, clock CLK_XUSBXTI;
+ clock-names = phy, ref;
+ status = disabled;
For readability it is better if status line is the last entry of the node.
---
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESUBMIT RFC PATCH v2 3/3] drivers: mfd: Add support for Exynos PMU driver
This patch moves Exynos PMU driver implementation from arm/mach-exynos to drivers/mfd. This driver is mainly used for setting misc bits of register from PMU IP of Exynos SoC which will be required to configure before Suspend/Resume. Currently all these settings are done in arch/arm/mach-exynos/pmu.c but moving ahead for ARM64 based SoC support, there is a need of DT based implementation of PMU driver. This driver uses already existing DT binding information. CC: Sangbeom Kim sbki...@samsung.com CC: Samuel Ortiz sa...@linux.intel.com CC: Lee Jones lee.jo...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/Kconfig |2 ++ arch/arm/mach-exynos/Makefile |2 -- drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c |0 5 files changed, 12 insertions(+), 2 deletions(-) rename arch/arm/mach-exynos/pmu.c = drivers/mfd/exynos-pmu.c (100%) So I just took a look at the code as zero changes looks suspicious to me. The driver can not simply be copied and pasted into the MFD subsystem in its current state. The fundamental question is; is this chip actually an MFD? What does it do besides Power Management? Exynos PMU chip controls different power states of Exynos, so mainly it does power management related stuff. Apart from this it has few registers which controls PHY of various IP blocks of Exynos such as USB, HDMI, ADC etc. But these phy controlling register are currently being accessed via syscon driver provided regmap APIs. For same the same reason Exynos PMU has second compatibility string as syscon. I suggest that this is not suitable for the MFD subsystem then. Try drivers/power. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 2/4] ARM: dts: exynos4: add exynos_usbphy node
Hi Sachin,
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Tuesday, April 29, 2014 6:23 PM
To: Chanho Park
Cc: Kukjin Kim; linux-samsung-soc; Tomasz Figa; Kamil Debski;
devicet...@vger.kernel.org
Subject: Re: [PATCHv2 2/4] ARM: dts: exynos4: add exynos_usbphy node
Hi Chanho,
On 25 April 2014 12:29, Chanho Park chanho61.p...@samsung.com wrote:
This patch enables a exynos_usbphy node for exynos4 SoCs.
A exynos4x12 usb phy node is almost same with 4210's one
except compatible string and pmu syscon.
Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi| 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 5 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index 264066f..5f9b23b 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -278,6 +278,16 @@
status = disabled;
};
+ exynos_usbphy: exynos-usbphy@125B {
+ compatible = samsung,exynos4210-usb2-phy;
+ reg = 0x125B 0x100;
+ samsung,pmureg-phandle = pmu_system_controller;
+ clocks = clock CLK_USB_DEVICE, clock CLK_XUSBXTI;
+ clock-names = phy, ref;
+ status = disabled;
For readability it is better if status line is the last entry of the
node.
Yes. It could be more readable it is in the last line. I'll update it in next
patch.
Thanks.
Best Regards,
Chanho Park
--
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 11/15] ASoC: WM0010 needs SPI
From: Arnd Bergmann a...@arndb.de The missing dependency can lead to build errors, so make it explicit in Kconfig. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: alsa-de...@alsa-project.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- sound/soc/samsung/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 9fd6f62..99cc196 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -201,7 +201,7 @@ config SND_SOC_SPEYSIDE select SND_SAMSUNG_I2S select SND_SOC_WM8996 select SND_SOC_WM9081 - select SND_SOC_WM0010 + select SND_SOC_WM0010 if SPI select SND_SOC_WM1250_EV1 config SND_SOC_TOBERMORY @@ -217,7 +217,7 @@ config SND_SOC_BELLS select SND_SOC_WM5102 select SND_SOC_WM5110 select SND_SOC_WM9081 - select SND_SOC_WM0010 + select SND_SOC_WM0010 if SPI select SND_SOC_WM1250_EV1 config SND_SOC_LOWLAND -- 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 07/15] ASoC: UDA1380 needs I2C
From: Arnd Bergmann a...@arndb.de The UDA1380 driver needs I2C to be enabled, so SND_SOC_SAMSUNG_H1940_UDA1380 and SND_SOC_SAMSUNG_RX1950_UDA1380 also require this. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: alsa-de...@alsa-project.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- sound/soc/samsung/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 0c5e9e2..b09b5a4 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -130,7 +130,7 @@ config SND_SOC_SAMSUNG_SIMTEC_HERMES config SND_SOC_SAMSUNG_H1940_UDA1380 tristate Audio support for the HP iPAQ H1940 - depends on SND_SOC_SAMSUNG ARCH_H1940 + depends on SND_SOC_SAMSUNG ARCH_H1940 I2C select SND_S3C24XX_I2S select SND_SOC_UDA1380 help @@ -138,7 +138,7 @@ config SND_SOC_SAMSUNG_H1940_UDA1380 config SND_SOC_SAMSUNG_RX1950_UDA1380 tristate Audio support for the HP iPAQ RX1950 - depends on SND_SOC_SAMSUNG MACH_RX1950 + depends on SND_SOC_SAMSUNG MACH_RX1950 I2C select SND_S3C24XX_I2S select SND_SOC_UDA1380 help -- 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 10/15] ASoC: TLV320AIC23 and Simtec Hermes audio
From: Arnd Bergmann a...@arndb.de This codec requires I2C to be enabled, so any other option that selects it should also depend on I2C. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: alsa-de...@alsa-project.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- sound/soc/samsung/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index b09b5a4..9fd6f62 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -116,14 +116,14 @@ config SND_SOC_SAMSUNG_SIMTEC config SND_SOC_SAMSUNG_SIMTEC_TLV320AIC23 tristate SoC I2S Audio support for TLV320AIC23 on Simtec boards - depends on SND_SOC_SAMSUNG ARCH_S3C24XX + depends on SND_SOC_SAMSUNG ARCH_S3C24XX I2C select SND_S3C24XX_I2S select SND_SOC_TLV320AIC23_I2C select SND_SOC_SAMSUNG_SIMTEC config SND_SOC_SAMSUNG_SIMTEC_HERMES tristate SoC I2S Audio support for Simtec Hermes board - depends on SND_SOC_SAMSUNG ARCH_S3C24XX + depends on SND_SOC_SAMSUNG ARCH_S3C24XX I2C select SND_S3C24XX_I2S select SND_SOC_TLV320AIC3X select SND_SOC_SAMSUNG_SIMTEC -- 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 13/15] ASoC: SND_S3C_DMA_LEGACY needs S3C24XX_DMA
From: Arnd Bergmann a...@arndb.de SND_S3C_DMA_LEGACY can only be set on S3C24xx, which does not (yet) support the dmaengine framework, so samsung_dma_get_ops() fails to link if S3C24XX_DMA is disabled: sound/built-in.o: In function `dma_hw_params': :(.text+0x7f310): undefined reference to `s3c_dma_get_ops' sound/built-in.o: In function `s3c_ac97_trigger': :(.text+0x7f7f0): undefined reference to `s3c_dma_get_ops' sound/built-in.o: In function `s3c_ac97_mic_trigger': :(.text+0x7f884): undefined reference to `s3c_dma_get_ops' sound/built-in.o: In function `s3c2412_i2s_trigger': :(.text+0x80944): undefined reference to `s3c2410_dma_ctrl' This makes sure S3C24XX_DMA is always enabled when we need it, just like we do it for the same dependency in SND_S3C24XX_I2S, which has the same problem. Selecting S3C2410_DMA as we did before does not actually have the intended effect, since that one is only used on the s3c2410 and s3c2442 SoCs of the s3c24xx family, but not the others, so we can remove this from Kconfig. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: alsa-de...@alsa-project.org --- sound/soc/samsung/Kconfig |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 99cc196..7b610a8 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -1,7 +1,6 @@ config SND_SOC_SAMSUNG tristate ASoC support for Samsung depends on PLAT_SAMSUNG - select S3C2410_DMA if ARCH_S3C24XX select S3C64XX_PL080 if ARCH_S3C64XX select SND_S3C_DMA if !ARCH_S3C24XX select SND_S3C_DMA_LEGACY if ARCH_S3C24XX @@ -15,11 +14,11 @@ config SND_S3C_DMA tristate config SND_S3C_DMA_LEGACY + select S3C24XX_DMA tristate config SND_S3C24XX_I2S tristate - select S3C24XX_DMA config SND_S3C_I2SV2_SOC tristate @@ -27,7 +26,6 @@ config SND_S3C_I2SV2_SOC config SND_S3C2412_SOC_I2S tristate select SND_S3C_I2SV2_SOC - select S3C2410_DMA config SND_SAMSUNG_PCM tristate @@ -83,7 +81,6 @@ config SND_SOC_SAMSUNG_SMDK_WM8994 config SND_SOC_SAMSUNG_SMDK2443_WM9710 tristate SoC AC97 Audio support for SMDK2443 - WM9710 depends on SND_SOC_SAMSUNG MACH_SMDK2443 - select S3C2410_DMA select AC97_BUS select SND_SOC_AC97_CODEC select SND_SAMSUNG_AC97 @@ -94,7 +91,6 @@ config SND_SOC_SAMSUNG_SMDK2443_WM9710 config SND_SOC_SAMSUNG_LN2440SBC_ALC650 tristate SoC AC97 Audio support for LN2440SBC - ALC650 depends on SND_SOC_SAMSUNG ARCH_S3C24XX - select S3C2410_DMA select AC97_BUS select SND_SOC_AC97_CODEC select SND_SAMSUNG_AC97 -- 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 03/15] ASoC: SMDK_WM8580_PCM needs REGMAP_I2C
From: Arnd Bergmann a...@arndb.de This adds a missing dependency for SND_SOC_SMDK_WM8580_PCM to require REGMAP_I2C to be enabled, avoiding possible build erorrs. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: alsa-de...@alsa-project.org --- sound/soc/samsung/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index 14568be..0c5e9e2 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -64,6 +64,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750 config SND_SOC_SAMSUNG_SMDK_WM8580 tristate SoC I2S Audio support for WM8580 on SMDK depends on SND_SOC_SAMSUNG (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDK6440 || MACH_SMDK6450 || MACH_SMDKV210 || MACH_SMDKC110) + depends on REGMAP_I2C select SND_SOC_WM8580 select SND_SAMSUNG_I2S help @@ -178,6 +179,7 @@ config SND_SOC_SAMSUNG_SMDK_SPDIF config SND_SOC_SMDK_WM8580_PCM tristate SoC PCM Audio support for WM8580 on SMDK depends on SND_SOC_SAMSUNG (MACH_SMDK6450 || MACH_SMDKV210 || MACH_SMDKC110) + depends on REGMAP_I2C select SND_SOC_WM8580 select SND_SAMSUNG_PCM help -- 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 04/15] ASoC: samsung-idma: avoid 64-bit division
From: Arnd Bergmann a...@arndb.de dma_addr_t may be 64 bit wide, which causes a build failure when doing a division on it. Here it is safe to cast to an u32 type, which avoids the problem. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: alsa-de...@alsa-project.org --- sound/soc/samsung/idma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/idma.c b/sound/soc/samsung/idma.c index 3d5cf15..e9891b4 100644 --- a/sound/soc/samsung/idma.c +++ b/sound/soc/samsung/idma.c @@ -274,7 +274,7 @@ static irqreturn_t iis_irq(int irqno, void *dev_id) addr = readl(idma.regs + I2SLVL0ADDR) - idma.lp_tx_addr; addr += prtd-periodsz; - addr %= (prtd-end - prtd-start); + addr %= (u32)(prtd-end - prtd-start); addr += idma.lp_tx_addr; writel(addr, idma.regs + I2SLVL0ADDR); -- 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 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT
From: Arnd Bergmann a...@arndb.de Building ARM randconfig got into a situation where CONFIG_INPUT is turned off and SND_SOC_ALL_CODECS is turned on, which failed for two codecs trying to use the input subsystem. Some other drivers also select one of these codecs and consequently need an explicit dependency added. Appending to the dependency list seems the easiest way out, since this is not a practical limitation. If anyone really needs to build these codecs for a kernel with no input support, a more sophisticated solution can be implemented. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood l...@slimlogic.co.uk Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: Lars-Peter Clausen l...@metafoo.de Cc: Timur Tabi ti...@tabi.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: alsa-de...@alsa-project.org --- sound/soc/codecs/Kconfig |8 sound/soc/fsl/Kconfig |2 +- sound/soc/samsung/Kconfig |2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index f0e8401..d4260d3 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -40,7 +40,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_ALC5632 if I2C select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC select SND_SOC_CS42L51 if I2C - select SND_SOC_CS42L52 if I2C + select SND_SOC_CS42L52 if I2C INPUT select SND_SOC_CS42L73 if I2C select SND_SOC_CS4270 if I2C select SND_SOC_CS4271 if SND_SOC_I2C_AND_SPI @@ -127,7 +127,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_WM8955 if I2C select SND_SOC_WM8960 if I2C select SND_SOC_WM8961 if I2C - select SND_SOC_WM8962 if I2C + select SND_SOC_WM8962 if I2C INPUT select SND_SOC_WM8971 if I2C select SND_SOC_WM8974 if I2C select SND_SOC_WM8978 if I2C @@ -282,7 +282,7 @@ config SND_SOC_CS42L51 config SND_SOC_CS42L52 tristate Cirrus Logic CS42L52 CODEC - depends on I2C + depends on I2C INPUT config SND_SOC_CS42L73 tristate Cirrus Logic CS42L73 CODEC @@ -598,7 +598,7 @@ config SND_SOC_WM8961 config SND_SOC_WM8962 tristate Wolfson Microelectronics WM8962 CODEC - depends on I2C + depends on I2C INPUT config SND_SOC_WM8971 tristate diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 338a916..f4069d0 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -187,7 +187,7 @@ config SND_SOC_EUKREA_TLV320 config SND_SOC_IMX_WM8962 tristate SoC Audio support for i.MX boards with wm8962 - depends on OF I2C + depends on OF I2C INPUT select SND_SOC_WM8962 select SND_SOC_IMX_PCM_DMA select SND_SOC_IMX_AUDMUX diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index f2e2891..14568be 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -204,7 +204,7 @@ config SND_SOC_SPEYSIDE config SND_SOC_TOBERMORY tristate Audio support for Wolfson Tobermory - depends on SND_SOC_SAMSUNG MACH_WLF_CRAGG_6410 + depends on SND_SOC_SAMSUNG MACH_WLF_CRAGG_6410 INPUT select SND_SAMSUNG_I2S select SND_SOC_WM8962 -- 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 2/9] drm/panel: add pre_enable and post_disable routines
ping! On Fri, Apr 25, 2014 at 11:46 PM, Ajay kumar ajayn...@gmail.com wrote: On Fri, Apr 25, 2014 at 11:34 AM, Ajay kumar ajayn...@gmail.com wrote: On Friday, April 25, 2014, Thierry Reding thierry.red...@gmail.com wrote: On Thu, Apr 24, 2014 at 12:56:02AM +0530, Ajay kumar wrote: Thierry, On Wed, Apr 23, 2014 at 1:12 PM, Thierry Reding thierry.red...@gmail.com wrote: On Wed, Apr 23, 2014 at 09:29:15AM +0200, Daniel Vetter wrote: [...] Imo this makes sense, especially if we go through with the idea talked about yesterday of creating a drm_bridge to wrap-up a drm_panel with sufficient isolation between all components. I'm not at all comfortable with these. The names are totally confusing. Next somebody will need to do something after the panel has been enabled and we'll have to introduce .post_enable() and .pre_disable() functions. And worse, what if somebody needs something to be done between .pre_enable() and .enable()? .post_pre_enable()? Where does it end? According to the above description the only reason why we need this is to avoid visible glitches when the panel is already on, but the video stream hasn't started yet. If that's the only reason why we need this, then perhaps adding a way for a panel to expose the associated backlight would be better? Actually, we need not expose the entire backlight device. AFAIK, the glitch is caused when you enable BL_EN before there is valid video data. So, one way to mask off the glitch is to follow this sequence: -- power up the panel. -- start video data, (start PWM here or) -- (start PWM here), enable backlight That's very difficult to get right, isn't it? Even if you have fine- grained control over what to enable you still need a way to determine _when_ it's safe to enable the backlight. Typically I guess that would be the duration of one frame (or perhaps 2, depending on when the panel syncs to the video signal). We need not determine, its already present in LVDS datasheet. The LVDS datasheet says at least 200ms delay is needed from Valid data to BL on. Perhaps it could even by sync'ed to the VBLANK? No. vblanks are related to crtc. And the bridge/panel driver should be independent of vblank. The problem is that the above scenario cannot be mapped to panel-simple driver. IMO, panel_simple should provide enable/disable controls both for LCD and backlight. something like panel_simple_lcd_enable/panel_simple_led_enable, and panel_simple_lcd_disable/panel_simple_led_disable. That's not what the simple panel driver can do. If we want this it needs to be solved in a generic way for all panels since they all need to use the drm_panel_*() functions to abstract away the details from drivers that use the panels. Right. So only I have added pre_enable and post_disable callbacks. Using that name won't harm existing panel drivers and still addresses our requirement. Regards, Ajay Thierry : Are you really ok with the new callback names? like pre_enable and post_disable? Adding those new callbacks really won't harm the existing panels anyhow. Daniel, Rob : I think I have given sufficient amount of information as to why the concept of drm_panel_bridge fails and why we cannot have callbacks for drm_panel inside crtc helpers or any other generic place. Please let me know your final opinion so that I can start reworking on this series. Thanks and regards, Ajay Kumar -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] i.MX6 PCIe binding change and MSI support
Hi Bjorn, Am Freitag, den 25.04.2014, 08:39 -0600 schrieb Bjorn Helgaas: [...] PCI: designware: split Exynos and i.MX bindings ARM: dts: imx6: update pcie to bring in line with new binding PCI: imx6: use new clock names PCI: imx6: drop old irq mapping PCI: imx6: rip out optional (and unused) irqs PCI: designware: make MSI isr shared irq aware PCI: imx6: add support for MSI What's the status of all these? I would normally apply patches 4-8 of this series through my tree, given the appropriate acks, but I haven't seen those yet. And I'm not sure what dependencies there are between the non-PCI patches and the PCI ones. It's a complete binding change, so applying one part without the other is going to horribly break things. So I would at least want to see an ack for the binding change on the i.MX side from Shawn and Richard. This will need some follow on patches, as some boards adding PCIe using the old binding have cropped up in linux-next, but I can do the patches on short notice if everyone agrees to merge this patchset. The designware part is pretty simple and doesn't change anything for other users than i.MX. Though I would like to see an ack from Jingoo for those. I have some more stuff in the pipes regarding multiple MSI irqs, that depend on this series and also the Keystone people are waiting for this to be applied in order to consolidate the clock handling of the designware core driver, so it would be nice to get this moving again. OK, just poke me again when you're ready for me to do something with these. As both Richard and Jingoo gave their ack for the respective patches I think this is good to go in and I would expect all the PCI patches to go through your tree for 3.16. Shawn, if you are not okay with this change, please speak up now. Otherwise please pick the dts change for 3.16. I'll go over linux-next and prepare the patches to fix up the boards there. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 6/7] i2c: ChromeOS EC tunnel driver
Hi,
just a basic review to keep things rolling...
On the original Samsung ARM Chromebook these devices were on an I2C
bus that was shared between the AP and the EC and arbitrated using
some extranal GPIOs (see i2c-arb-gpio-challenge).
The original arbitration scheme worked well enough but had some
downsides:
* It was nonstandard (not using standard I2C multimaster)
* It only worked if the EC-AP communication was I2C
* It was relatively hard to debug problems (hard to tell if i2c issues
were caused by the EC, the AP, or some device on the bus).
On the HP Chromebook 11 the design was changed to:
This paragraph would be a nice update for the gpio-arbitration docs.
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
The bindings should independently be sent to the devicetree list.
new file mode 100644
index 000..898f030
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,39 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+==
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC). To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like
google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+Optional child nodes:
+- One node per I2C device connected to the tunnelled I2C bus.
+
+
+Example:
+ cros-ec@0 {
+ compatible = google,cros-ec-spi;
+
+ ...
+
+ i2c-tunnel {
+ compatible = google,cros-ec-i2c-tunnel;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ google,remote-bus = 0;
+
+ battery: sbs-battery@b {
+ compatible = sbs,sbs-battery;
+ reg = 0xb;
+ sbs,poll-retry-count = 1;
+ };
+ };
+ }
Can the tunnel have n busses? How to represent them then? I think the
remote-bus property should go in favor of proper sub-nodes? Wouldn't it
also be more generic to have the tunnel node seperate and reference the
tunnel-mechanism (spi here) as a phandle?
+/**
+ * ec_i2c_construct_message - construct a message to go to the EC
+ *
+ * This function effectively stuffs the standard i2c_msg format of Linux into
+ * a format that the EC understands.
+ *
+ * @buf: The buffer to fill. Can pass NULL to count how many bytes the
message
+ * would be.
I wonder about this NULL thing. That means the size is calculated twice.
Why not make two functions instead, one fir size calc, one for setting
up?
+/**
+ * ec_i2c_parse_response - Parse a response from the EC
+ *
+ * We'll take the EC's response and copy it back into msgs.
+ *
+ * @buf: The buffer to parse. Can pass NULL to count how many bytes we
expect
+ *the response to be. Otherwise we assume that the right number of
+ *bytes are available.
Ditto.
+ result = bus-ec-command_sendrecv(bus-ec, EC_CMD_I2C_PASSTHRU,
+request, request_len,
+response, response_len);
This function pointer should be checked against NULL in probe, I
think.
+static int ec_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct cros_ec_device *ec = dev_get_drvdata(pdev-dev.parent);
+ struct device *dev = pdev-dev;
+ struct ec_i2c_device *bus = NULL;
+ u32 remote_bus;
+ int err;
+
+ dev_dbg(dev, Probing\n);
Drop. Device core has it already.
+
+ if (!np) {
+ dev_err(dev, no device node\n);
+ return -ENOENT;
+ }
Can this happen?
+
+ bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+ if (bus == NULL) {
+ dev_err(dev, cannot allocate bus device\n);
No need for error strings when allocating.
+ return -ENOMEM;
+ }
+
+ dev_dbg(dev, ChromeOS EC I2C tunnel adapter\n);
Drop. Device core debug has it, too.
+
+ return err;
+}
+
+static int ec_i2c_remove(struct platform_device *dev)
+{
+ struct ec_i2c_device *bus = platform_get_drvdata(dev);
+
+ platform_set_drvdata(dev, NULL);
Not needed.
+
+ i2c_del_adapter(bus-adap);
+
+ return 0;
+}
+
Regards,
Wolfram
signature.asc
Description: Digital signature
Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver
Hi Andrzej, Laurent, Thierry.
CCing Steffen Trumtrar,
On 04/29/2014 05:35 PM, YoungJun Cho wrote:
On 04/29/2014 03:02 PM, YoungJun Cho wrote:
Hi Laurent,
Thank you for sharing your idea.
On 04/29/2014 12:05 AM, Laurent Pinchart wrote:
Hi YoungJun,
On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569
++
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
[snip]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
index 000..1282678
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
[snip]
+static int s6e3fa0_get_modes(struct drm_panel *panel)
+{
+struct drm_connector *connector = panel-connector;
+struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
+struct drm_display_mode *mode;
+
+mode = drm_mode_create(connector-dev);
+if (!mode) {
+DRM_ERROR(failed to create a new display mode\n);
+return 0;
+}
+
+drm_display_mode_from_videomode(ctx-vm, mode);
+mode-width_mm = ctx-width_mm;
+mode-height_mm = ctx-height_mm;
+connector-display_info.width_mm = mode-width_mm;
+connector-display_info.height_mm = mode-height_mm;
+
+mode-type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+mode-private = (void *)ctx-cpu_timings;
Wouldn't it make sense to create a new get_interface_params (or
similar)
operation for drm_panel to query interface configuration parameters
instead of shoving it in the mode private field ?
You mean new get_interface_params operation is different from
get_modes() ?
Till now, struct drm_display_mode and most of mode relevant APIs are
only for video interface.
And CPU interface also needs video mode configurations.
I have a plan to implement the CPU interface relevant APIs like video
mode ones, but I think they should be used under current DRM mode APIs
like fill_modes, get_modes and so on.
So after that implementation, this private field will be replaced by
new ones.
Could you explain it in more detail?
The idea is that the interface parameters (RD/WR signals timings in
this case,
but this could also include MIPI DSI lane configuration or any other
kind of
physical interface parameters) are distinct from the video modes.
Yes. The RD/WR signals timings are distinct from the video modes,
but in my opinion, others are covered by video mode already.
Do you see a need to tie tie interface parameters with
drm_display_mode ? Can
they be mode-specific ? In any case I'd like not to use the private
field of
drm_display_mode. If we need to tie both information together then it
should
be done in a standard way.
I think this cpu-mode-timings is in struct drm_display_mode
(NOT by *private) and requires drm_display_mode_from_cpumode()
because the drm_display_mode_from_videomode() covers only video mode.
I'll try implement it as soon as possible.
For your information, there are two modes in MIPI DSI specification,
which are video mode and command mode.
And CS, RD/WR timings are related with MIPI DBI specification,
VSYNC, HSYNC timings are related with MIPI DPI specification.
So I think all things relevant with command mode should be arranged
the name of command mode(NOT CPU mode, like video mode NOT RGB mode)
in MIPI DSI, and we don't need to consider MIPI DBI like we do MIPI DPI
for video mode.
First, for MIPI command mode, hactive and vactive are only required.
Sorry Andrzej for confusing reply.
I have to modify exynos fimd pixel clock calculating function.
Second, for generic MIPI command mode timing support, commandmode.c and
of_commandmode.c are required in drivers/video.
And the struct drm_panel_command_mode_timings should be moved into
commandmode.h as struct commandmode.
And the last(this is important and I need your ideas), adds this command
mode timings into struct display_timing.
From hierarchical aspects, display_timing(s) should contain command
mode timings too, but it only contains video mode timings.
If I do it, current video mode relevant DTs will be broken.
So IMHO it is required to rename of_*_display_timing() as
of_*_videomode_timing() and add of_*_commandmode_timing() into
of_display_timing.c.
And should add command mode
Re: [PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls
On Mon, Apr 28, 2014 at 9:08 AM, Ajay kumar ajayn...@gmail.com wrote:
Daniel,
On Sun, Apr 27, 2014 at 6:25 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Apr 25, 2014 at 8:17 AM, Ajay kumar ajayn...@gmail.com wrote:
We can call panel_enable/disable at the right point. Even the bridge chips
expect the same. So, I am not ok with combining the bridge and panel and
calling the fxn pointers from crtc_helpers.
So, either we leave it the way it is in this patch (call drm_panel
functions at right points) or
we don't use drm_panel to control the panel sequence and instead use few DT
properties and regulators, inside the bridge chip driver.
That wasn't really suggested, but instead the idea was to provide a
default drm_bridge which wraps the drm_panel so that you could more
easily chain them up.
What do you mean by default drm_bridge?
I just want to clear few things. Let me explain what I have understood:
What I understand is that Rob wants me to create a common
structure which wraps up drm_panel and drm_bridge into a single structure:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */ == Really not sure why
this is needed!
};
static void drm_panel_bridge_enable(struct drm_bridge *bridge)
{
struct drm_panel_bridge *pb = to_panel_bridge(bridge);
if (pb-bridge)
pb-bridge-funcs-enable(pb-bridge);
pb-panel-funcs-enable(pb-panel);
}
And now, the above function becomes a common function
(also with an ordering issue btw panel and bridge).
Where do we keep it? And, where do we call it from?
my proposal involves no change to crtc helpers. The later variation
(with composite_bridge so you could choose the order) would have a
sequence along the lines of:
crtc helpers:
+ bridge_funcs-enable(): - composite_bridge_enable()
+ cbridge-b1-funcs-enable(): - ptn3460_bridge_enable()
+ cbridge-b2-funcs-enable(): - panel_bridge_enable();
+ pbridge-panel-funcs-enable(): - foo_panel_enable()
or if the order needs to be swapped you can use ptn3460_bridge as b2
and panel bridge as b1.
BR,
-R
Also I'm not really happy that the bridge callbacks have been added to
the drm helpers (I'd prefer if driver callbacks would bear that
responsibility). But you can always create your own drm_bridge
integration.
Do you mean, the bridge calls should be moved out of common drm_helper
functions and called from platform specific drivers instead?
In any case your concern that drivers need to control
when certain callbacks are called is shared by everyone here afaics.
And I also don't see any issues with Rob's proposal in this regard.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Please let me know if my understanding is correct and correct me if
there is a misconception.
Regards,
Ajay Kumar
--
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 2/7] arm64: Decouple page size from level of translation tables
Jungseok, On Tue, Apr 29, 2014 at 05:59:20AM +0100, Jungseok Lee wrote: +choice + prompt Level of translation tables + default ARM64_3_LEVELS if ARM64_4K_PAGES + default ARM64_2_LEVELS if ARM64_64K_PAGES + help + Allows level of translation tables. + +config ARM64_2_LEVELS + bool 2 level + depends on ARM64_64K_PAGES + help + This feature enables 2 levels of translation tables. + +config ARM64_3_LEVELS + bool 3 level + depends on ARM64_4K_PAGES + help + This feature enables 3 levels of translation tables. + +endchoice As I mentioned previously (http://www.spinics.net/linux/lists/arm-kernel/msg319552.html), just expose options for the VA space bits rather than the number of levels. You can still keep the number of levels config options but not visible in menuconfig (though I think you could also hide them in some header and avoid config altogether). The VA bits config options can be: VA_BITS_39 if 4K (3 levels) VA_BITS_42 if 64K (2 levels) VA_BITS_47 if 16K (3 levels) VA_BITS_48 if 4K || 16K || 64K (4/4/3 levels depending on page size) That's more meaningful to people configuring the kernel. -- Catalin -- 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 3/7] arm64: Introduce a kernel configuration option for VA_BITS
On Tue, Apr 29, 2014 at 05:59:23AM +0100, Jungseok Lee wrote: +config ARM64_VA_BITS + int Virtual address space size + range 39 39 if ARM64_4K_PAGES ARM64_3_LEVELS + range 42 42 if ARM64_64K_PAGES ARM64_2_LEVELS + help + This feature is determined by a combination of page size and + level of translation tables. OK, so you are doing the VA bits selection already. But see my other email about setting only exposing this and hiding the number of levels (though number of levels can be mentioned in the help). -- Catalin -- 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 4/7] arm64: Add a description on 48-bit address space with 4KB pages
On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote: --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses 3 levels and 4 levels of translation tables with +the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB) +virtual addresses, respectively, for both user and kernel. With 64KB +pages, only 2 levels of translation tables are used but the memory layout +is the same. Any reason why we couldn't use 48-bit address space with 64K pages (implying 3 levels)? -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 4KB pages + 4 levels: + +StartEnd SizeUse +--- + 256TB user + + 7bfe~124TB vmalloc BTW, maybe as a separate patch we should change the end to be exclusive. It becomes harder to modify (I've been through this a few times already ;)) and even follow the changes. -- Catalin -- 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 v3 PATCH v2 10/16] drm/exynos: dsi: add driver data to support Exynos5420
On 27 April 2014 07:20, YoungJun Cho yj44@samsung.com wrote:
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Changelog v2:
- Moves exynos_dsi_enable_clocks() after exynos_dsi_reset()
(commented by Andrzej Hajda)
- Splits D-PHY control setting routines from PLL setting one
(commented by Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 154
++-
1 file changed, 132 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 4a918ec..c18dba3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/irq.h
+#include linux/of_device.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
@@ -54,9 +55,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1
*/
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) 0xf) 0)
@@ -200,6 +204,21 @@
#define DSIM_PLL_M(x) ((x) 4)
#define DSIM_PLL_S(x) ((x) 1)
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x) ((x) 8)
+#define DSIM_PHYTIMING_HS_EXIT(x) ((x) 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)((x) 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x) ((x) 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x) ((x) 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) 0)
+
#define DSI_MAX_BUS_WIDTH 4
#define DSI_NUM_VIRTUAL_CHANNELS 4
#define DSI_TX_FIFO_SIZE 2048
@@ -233,6 +252,12 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_INITIALIZED BIT(1)
#define DSIM_STATE_CMD_LPM BIT(2)
+struct exynos_dsi_driver_data {
Shouldn't this be static?
+ unsigned int plltmr_reg;
+
nit: stray blank line
+ unsigned int has_freqband:1;
+};
+
snip
+static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
+{
+ struct exynos_dsi_driver_data *driver_data = dsi-driver_data;
+ u32 reg;
+
+ if (driver_data-has_freqband)
+ return;
+
+ /* B D-PHY */
+ reg = 0x0af 0x1ff;
Please use macros instead of magic numbers.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 PATCH 08/16] drm/exynos: fimd: support I80 interface
Hi YoungJun, On 27 April 2014 07:20, YoungJun Cho yj44@samsung.com wrote: To support MIPI DSI command mode interface, FIMD should do followings: - Sets LCD block configuration for I80 interface. - Uses lcd_sys as an IRQ resource and sets relevant IRQ configuration. - Implements trigger feature which transfers image date if there is page flip request, and implements TE handler to call trigger function. - Sets CPU mode timings configuration. - Sets ideal(pixel) clock is 2 times faster than the original one to generate frame done IRQ prior to the next TE signal. ... + + reg = readl(timing_base + TRIGCON); + reg |= 1 0 | 1 1; What does this signify? Can't this be OR'd directly with 3? -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On 04/28/2014 06:02 PM, Simon Horman wrote: On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: Since we now automatically enable early BRESP in core L2C-310 code when we detect a Cortex-A9, we don't need platforms/SoCs to set this bit explicitly. Instead, they should seek to preserve the value of bit 30 in the auxiliary control register. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I would prefer if this patch was broken out into individual patches for each board or SoC file and that they were then picked up by their respective platform maintainers. Likewise for patch 66/97. Although it is only for shmobile I would prefer it broken out. There are far too many dependencies in this series to break out the board file patches to be merged separately; it'd take either a whole bunch of kernel releases to merge it all that way, or a twisty maze of tiny topic branches cross-merged all over the place. Neither option is realistic. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq
Anton, On Wed, Apr 23, 2014 at 8:56 AM, Doug Anderson diand...@chromium.org wrote: On the ARM Chromebook tps65090 has two masters: the AP (the main processor running linux) and the EC (the embedded controller). The AP is allowed to mess with FETs but the EC is in charge of charge control. The tps65090 interupt line is routed to both the AP and the EC, which can cause quite a headache. Having two people adjusting masks and acking interrupts is a recipe for disaster. In the shipping kernel we had a hack to have the AP pay attention to the IRQ but not to ack it. It also wasn't supposed to configure the IRQ in any way. That hack allowed us to detect when the device was charging without messing with the EC's state. The current tps65090 infrastructure makes the above difficult, and it was a bit of a hack to begin with. Rather than uglify the driver to support it, just extend the driver's existing notion of no irq to the charger. This makes the charger code poll every 2 seconds for AC detect, which is sufficient. For proper functioning, requires (mfd: tps65090: Don't tell child devices we have an IRQ if we don't). If we don't have that patch we'll simply fail to probe on devices without an interrupt (just like we did before this patch). Signed-off-by: Doug Anderson diand...@chromium.org --- Changes in v3: None Changes in v2: - Split noirq (polling mode) changes into MFD and charger drivers/power/tps65090-charger.c | 76 +++- 1 file changed, 59 insertions(+), 17 deletions(-) All the rest of this series has been acked and applied. Do you have time to review this patch? Thanks! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] devfreq: exynos5: Use devm_devfreq_* function using device resource management
Hi Chanwoo,
On 25 April 2014 14:38, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch uses devm_devfreq_add_device()/devm_devfreq_register_opp_notifier()
to control automatically the resource of devfreq.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Manish Badarkhe badarkhe.man...@gmail.com
Cc: Abhilash Kesavan a.kesa...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
drivers/devfreq/exynos/exynos5_bus.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index ab54a69..1f622f8 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -165,11 +165,6 @@ static int exynos5_int_get_dev_status(struct device *dev,
}
static void exynos5_int_exit(struct device *dev)
{
- struct platform_device *pdev = container_of(dev, struct
platform_device,
- dev);
- struct busfreq_data_int *data = platform_get_drvdata(pdev);
-
- devfreq_unregister_opp_notifier(dev, data-devfreq);
}
Do you need an empty function?
static struct devfreq_dev_profile exynos5_devfreq_int_profile = {
@@ -343,30 +338,29 @@ static int exynos5_busfreq_int_probe(struct
platform_device *pdev)
busfreq_mon_reset(ppmu_data);
- data-devfreq = devfreq_add_device(dev, exynos5_devfreq_int_profile,
+ data-devfreq = devm_devfreq_add_device(dev,
exynos5_devfreq_int_profile,
simple_ondemand, NULL);
-
if (IS_ERR(data-devfreq)) {
err = PTR_ERR(data-devfreq);
No need of err. return PTR_ERR(data-devfreq);
- goto err_devfreq_add;
+ return err;
}
- devfreq_register_opp_notifier(dev, data-devfreq);
+ err = devm_devfreq_register_opp_notifier(dev, data-devfreq);
+ if (err 0) {
+ dev_err(dev, Failed to register opp notifier\n);
+ return err;
+ }
err = register_pm_notifier(data-pm_notifier);
if (err) {
dev_err(dev, Failed to setup pm notifier\n);
- goto err_devfreq_add;
+ return err;
}
/* TODO: Add a new QOS class for int/mif bus */
pm_qos_add_request(data-int_req, PM_QOS_NETWORK_THROUGHPUT, -1);
return 0;
-
-err_devfreq_add:
- devfreq_remove_device(data-devfreq);
- return err;
}
static int exynos5_busfreq_int_remove(struct platform_device *pdev)
@@ -375,7 +369,6 @@ static int exynos5_busfreq_int_remove(struct
platform_device *pdev)
pm_qos_remove_request(data-int_req);
unregister_pm_notifier(data-pm_notifier);
- devfreq_remove_device(data-devfreq);
return 0;
}
--
1.8.0
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/7] arm64: mm: Implement 4 levels of translation tables
On Tue, Apr 29, 2014 at 05:59:33AM +0100, Jungseok Lee wrote: diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 0fd5650..03ec424 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -37,8 +37,9 @@ /* * swapper_pg_dir is the virtual address of the initial page table. We place - * the page tables 3 * PAGE_SIZE below KERNEL_RAM_VADDR. The idmap_pg_dir has - * 2 pages and is placed below swapper_pg_dir. + * the page tables 3 * PAGE_SIZE (2 or 3 levels) or 4 * PAGE_SIZE (4 levels) + * below KERNEL_RAM_VADDR. The idmap_pg_dir has 2 pages (2 or 3 levels) or + * 3 pages (4 levels) and is placed below swapper_pg_dir. */ #define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET) @@ -46,8 +47,13 @@ #error KERNEL_RAM_VADDR must start at 0xXXX8 #endif +#ifdef CONFIG_ARM64_4_LEVELS +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) +#else #define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) #define IDMAP_DIR_SIZE (2 * PAGE_SIZE) +#endif Mark Rutland was doing some clean-up of this code to no longer place swapper_pg_dir and idmap_pg_dir below the kernel image. I'm not sure whether the patches ended up on the list yet (not a problem for now, just a slight change for your patches). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3 5/5] regulator: tps65090: Make FETs more reliable by adding retries
On Wed, Apr 23, 2014 at 08:56:05AM -0700, Doug Anderson wrote: An issue was discovered with tps65090 where sometimes the FETs wouldn't actually turn on when requested (they would report overcurrent). The most problematic FET was the one used for the LCD Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/3] [media] s5p-mfc: Core support to add v8 decoder
Hi Arun, On 23 April 2014 18:27, Arun Kumar K arun...@samsung.com wrote: From: Kiran AVND avnd.ki...@samsung.com This patch adds variant data and core support for V8 decoder. This patch also adds the register definition file for new firmware version v8 for MFC. Signed-off-by: Kiran AVND avnd.ki...@samsung.com Signed-off-by: Pawel Osciak posc...@chromium.org Signed-off-by: Arun Kumar K arun...@samsung.com --- ... + +/* Returned value register for specific setting */ +#define S5P_FIMV_D_RET_PICTURE_TAG_TOP_V8 0xf674 +#define S5P_FIMV_D_RET_PICTURE_TAG_BOT_V8 0xf678 +#define S5P_FIMV_D_MVC_VIEW_ID_V8 0xf6d8 + +/* SEI related information */ +#define S5P_FIMV_D_FRAME_PACK_SEI_AVAIL_V8 0xf6dc + +/* MFCv8 Context buffer sizes */ +#define MFC_CTX_BUF_SIZE_V8(30 * SZ_1K)/* 30KB */ Please include header file for size macros. ... }; diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h index 48a14b5..f0e63f5 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h @@ -23,8 +23,7 @@ #include media/v4l2-ioctl.h #include media/videobuf2-core.h #include regs-mfc.h -#include regs-mfc-v6.h -#include regs-mfc-v7.h +#include regs-mfc-v8.h /* Definitions related to MFC memory */ @@ -705,5 +704,6 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx); #define IS_TWOPORT(dev)(dev-variant-port_num == 2 ? 1 : 0) #define IS_MFCV6_PLUS(dev) (dev-variant-version = 0x60 ? 1 : 0) #define IS_MFCV7(dev) (dev-variant-version = 0x70 ? 1 : 0) Is MFC v8 superset of MFC v7? +#define IS_MFCV8(dev) (dev-variant-version = 0x80 ? 1 : 0) -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/7] arm64: Use pr_* instead of printk
On Mon, Apr 28 2014 at 09:59:14 PM, Jungseok Lee jays@samsung.com wrote:
This patch fixed the following checkpatch complaint as using pr_*
instead of printk.
WARNING: printk() should include KERN_ facility level
Cc: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm64/kernel/traps.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..0484e81 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -65,7 +65,7 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
fs = get_fs();
set_fs(KERNEL_DS);
- printk(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
+ pr_emerg(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
Currently this printk is being called with lvl=KERN_EMERG or lvl=. In
the case of lvl=KERN_EMERG leaving lvl in is redundant. In the case of
lvl= this is a behavioral change (printing to a different log
level). Was this intended?
for (first = bottom ~31; first top; first += 32) {
unsigned long p;
@@ -83,7 +83,7 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
sprintf(str + i * 9, );
}
}
- printk(%s%04lx:%s\n, lvl, first 0x, str);
+ pr_emerg(%s%04lx:%s\n, lvl, first 0x, str);
Ditto
}
set_fs(fs);
@@ -124,7 +124,7 @@ static void dump_instr(const char *lvl, struct pt_regs
*regs)
break;
}
}
- printk(%sCode: %s\n, lvl, str);
+ pr_emerg(%sCode: %s\n, lvl, str);
Ditto. Also called with with lvl=KERN_INFO.
Mitch
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] ASoC: SAMSUNG: Add sound card driver for Snow board
On Fri, Apr 25, 2014 at 09:46:11AM +0530, Tushar Behera wrote: On 04/24/2014 07:09 PM, Mark Brown wrote: defined. Why is that? Also, why is the secondary I2S playback stream not supported (this may be a reason to restrict to only the one I2S interface)? AFAICS, I2S driver doesn't support secondary DAI with DT (dai type is always TYPE_PRI in case of DT). Hence I could not find a setup to test secondary dai with this board. OK, that should be fixed at some point. I will hopefully be able to look at this myself on the Arndale Octa though (or Chromebook or Arndale once XCLKOUT is implemented). signature.asc Description: Digital signature
Re: [RFC v3 PATCH v2 10/16] drm/exynos: dsi: add driver data to support Exynos5420
Hi Sachin,
Thank you for comment.
I'll fix.
Thank you.
Best regards YJ
On 04/30/2014 12:26 AM, Sachin Kamat wrote:
On 27 April 2014 07:20, YoungJun Cho yj44@samsung.com wrote:
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Changelog v2:
- Moves exynos_dsi_enable_clocks() after exynos_dsi_reset()
(commented by Andrzej Hajda)
- Splits D-PHY control setting routines from PLL setting one
(commented by Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 154 ++-
1 file changed, 132 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 4a918ec..c18dba3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/irq.h
+#include linux/of_device.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
@@ -54,9 +55,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) 0xf) 0)
@@ -200,6 +204,21 @@
#define DSIM_PLL_M(x) ((x) 4)
#define DSIM_PLL_S(x) ((x) 1)
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x) ((x) 8)
+#define DSIM_PHYTIMING_HS_EXIT(x) ((x) 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)((x) 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x) ((x) 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x) ((x) 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) 0)
+
#define DSI_MAX_BUS_WIDTH 4
#define DSI_NUM_VIRTUAL_CHANNELS 4
#define DSI_TX_FIFO_SIZE 2048
@@ -233,6 +252,12 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_INITIALIZED BIT(1)
#define DSIM_STATE_CMD_LPM BIT(2)
+struct exynos_dsi_driver_data {
Shouldn't this be static?
+ unsigned int plltmr_reg;
+
nit: stray blank line
+ unsigned int has_freqband:1;
+};
+
snip
+static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
+{
+ struct exynos_dsi_driver_data *driver_data = dsi-driver_data;
+ u32 reg;
+
+ if (driver_data-has_freqband)
+ return;
+
+ /* B D-PHY */
+ reg = 0x0af 0x1ff;
Please use macros instead of magic numbers.
--
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 v3 PATCH 08/16] drm/exynos: fimd: support I80 interface
Hi Sachin, Thank you for comment. I'll fix. Thank you. Best regards YJ On 04/30/2014 12:35 AM, Sachin Kamat wrote: Hi YoungJun, On 27 April 2014 07:20, YoungJun Cho yj44@samsung.com wrote: To support MIPI DSI command mode interface, FIMD should do followings: - Sets LCD block configuration for I80 interface. - Uses lcd_sys as an IRQ resource and sets relevant IRQ configuration. - Implements trigger feature which transfers image date if there is page flip request, and implements TE handler to call trigger function. - Sets CPU mode timings configuration. - Sets ideal(pixel) clock is 2 times faster than the original one to generate frame done IRQ prior to the next TE signal. ... + + reg = readl(timing_base + TRIGCON); + reg |= 1 0 | 1 1; What does this signify? Can't this be OR'd directly with 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 5/5] devfreq: exynos5: Use devm_devfreq_* function using device resource management
Hi Sachin,
On 04/30/2014 01:54 AM, Sachin Kamat wrote:
Hi Chanwoo,
On 25 April 2014 14:38, Chanwoo Choi cw00.c...@samsung.com wrote:
This patch uses
devm_devfreq_add_device()/devm_devfreq_register_opp_notifier()
to control automatically the resource of devfreq.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Manish Badarkhe badarkhe.man...@gmail.com
Cc: Abhilash Kesavan a.kesa...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
drivers/devfreq/exynos/exynos5_bus.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index ab54a69..1f622f8 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -165,11 +165,6 @@ static int exynos5_int_get_dev_status(struct device
*dev,
}
static void exynos5_int_exit(struct device *dev)
{
- struct platform_device *pdev = container_of(dev, struct
platform_device,
- dev);
- struct busfreq_data_int *data = platform_get_drvdata(pdev);
-
- devfreq_unregister_opp_notifier(dev, data-devfreq);
}
Do you need an empty function?
exynos5_init_exit() function would be removed because this function is not
necessary.
static struct devfreq_dev_profile exynos5_devfreq_int_profile = {
@@ -343,30 +338,29 @@ static int exynos5_busfreq_int_probe(struct
platform_device *pdev)
busfreq_mon_reset(ppmu_data);
- data-devfreq = devfreq_add_device(dev, exynos5_devfreq_int_profile,
+ data-devfreq = devm_devfreq_add_device(dev,
exynos5_devfreq_int_profile,
simple_ondemand, NULL);
-
if (IS_ERR(data-devfreq)) {
err = PTR_ERR(data-devfreq);
No need of err. return PTR_ERR(data-devfreq);
OK, I'll fix it.
- goto err_devfreq_add;
+ return err;
}
- devfreq_register_opp_notifier(dev, data-devfreq);
+ err = devm_devfreq_register_opp_notifier(dev, data-devfreq);
+ if (err 0) {
+ dev_err(dev, Failed to register opp notifier\n);
+ return err;
+ }
err = register_pm_notifier(data-pm_notifier);
if (err) {
dev_err(dev, Failed to setup pm notifier\n);
- goto err_devfreq_add;
+ return err;
}
/* TODO: Add a new QOS class for int/mif bus */
pm_qos_add_request(data-int_req, PM_QOS_NETWORK_THROUGHPUT, -1);
return 0;
-
-err_devfreq_add:
- devfreq_remove_device(data-devfreq);
- return err;
}
static int exynos5_busfreq_int_remove(struct platform_device *pdev)
@@ -375,7 +369,6 @@ static int exynos5_busfreq_int_remove(struct
platform_device *pdev)
pm_qos_remove_request(data-int_req);
unregister_pm_notifier(data-pm_notifier);
- devfreq_remove_device(data-devfreq);
return 0;
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/7] arm64: Introduce a kernel configuration option for VA_BITS
On Tuesday, April 29, 2014 11:45 PM, Catalin Marinas wrote: On Tue, Apr 29, 2014 at 05:59:23AM +0100, Jungseok Lee wrote: +config ARM64_VA_BITS + int Virtual address space size + range 39 39 if ARM64_4K_PAGES ARM64_3_LEVELS + range 42 42 if ARM64_64K_PAGES ARM64_2_LEVELS + help + This feature is determined by a combination of page size and + level of translation tables. OK, so you are doing the VA bits selection already. But see my other email about setting only exposing this and hiding the number of levels (though number of levels can be mentioned in the help). Okay. I will hide the number of levels. Best Regards Jungseok Lee -- 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/7] arm64: Use pr_* instead of printk
On Wednesday, April 30, 2014 5:35 AM, Mitchel Humpherys wrote: On Mon, Apr 28 2014 at 09:59:14 PM, Jungseok Lee jays@samsung.com wrote: This patch fixed the following checkpatch complaint as using pr_* instead of printk. WARNING: printk() should include KERN_ facility level Cc: Catalin Marinas catalin.mari...@arm.com Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com --- arch/arm64/kernel/traps.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index 7ffaddd..0484e81 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -65,7 +65,7 @@ static void dump_mem(const char *lvl, const char *str, unsigned long bottom, fs = get_fs(); set_fs(KERNEL_DS); - printk(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top); + pr_emerg(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top); Currently this printk is being called with lvl=KERN_EMERG or lvl=. In the case of lvl=KERN_EMERG leaving lvl in is redundant. In the case of lvl= this is a behavioral change (printing to a different log level). Was this intended? No intention. I will drop the change in the next version. Thanks!! Best Regards Jungseok Lee -- 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 6/7] arm64: mm: Implement 4 levels of translation tables
On Wednesday, April 30, 2014 2:04 AM, Catalin Marinas wrote: On Tue, Apr 29, 2014 at 05:59:33AM +0100, Jungseok Lee wrote: diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 0fd5650..03ec424 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -37,8 +37,9 @@ /* * swapper_pg_dir is the virtual address of the initial page table. We place - * the page tables 3 * PAGE_SIZE below KERNEL_RAM_VADDR. The idmap_pg_dir has - * 2 pages and is placed below swapper_pg_dir. + * the page tables 3 * PAGE_SIZE (2 or 3 levels) or 4 * PAGE_SIZE (4 + levels) + * below KERNEL_RAM_VADDR. The idmap_pg_dir has 2 pages (2 or 3 + levels) or + * 3 pages (4 levels) and is placed below swapper_pg_dir. */ #define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET) @@ -46,8 +47,13 @@ #error KERNEL_RAM_VADDR must start at 0xXXX8 #endif +#ifdef CONFIG_ARM64_4_LEVELS +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) +#else #define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) #define IDMAP_DIR_SIZE (2 * PAGE_SIZE) +#endif Mark Rutland was doing some clean-up of this code to no longer place swapper_pg_dir and idmap_pg_dir below the kernel image. I'm not sure whether the patches ended up on the list yet (not a problem for now, just a slight change for your patches). I don't see those patches in the mailing list yet. I will keep it in mind. Thanks. Best Regards Jungseok Lee -- 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 2/7] arm64: Decouple page size from level of translation tables
On Tuesday, April 29, 2014 11:41 PM, Catalin Marinas wrote: Jungseok, Hi, Catalin On Tue, Apr 29, 2014 at 05:59:20AM +0100, Jungseok Lee wrote: +choice + prompt Level of translation tables + default ARM64_3_LEVELS if ARM64_4K_PAGES + default ARM64_2_LEVELS if ARM64_64K_PAGES + help + Allows level of translation tables. + +config ARM64_2_LEVELS + bool 2 level + depends on ARM64_64K_PAGES + help + This feature enables 2 levels of translation tables. + +config ARM64_3_LEVELS + bool 3 level + depends on ARM64_4K_PAGES + help + This feature enables 3 levels of translation tables. + +endchoice As I mentioned previously (http://www.spinics.net/linux/lists/arm-kernel/msg319552.html), just expose options for the VA space bits rather than the number of levels. You can still keep the number of levels config options but not visible in menuconfig (though I think you could also hide them in some header and avoid config altogether). The VA bits config options can be: VA_BITS_39 if 4K (3 levels) VA_BITS_42 if 64K (2 levels) VA_BITS_47 if 16K (3 levels) VA_BITS_48 if 4K || 16K || 64K (4/4/3 levels depending on page size) That's more meaningful to people configuring the kernel. Okay, I will revise VA_BITS config as hiding the number of levels. Best Regards Jungseok Lee -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, Tomasz,
On Mon, Apr 28, 2014 at 11:47 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Does this patch looks Ok now ?
Actually we plan to get this in for 3.16, so if things are good we can
get a go ahead for this :-)
Changes from v6:
- Addressed review comments:
-- Sorted config entries in Kconfig and Makefile
-- Made #define to_usbdrd_phy(inst) to a static inline routine.
-- Restructured exynos5_rate_to_clk() as suggested.
-- Amended 'val' field for regmap_update_bits() in the routine
exynos5_usbdrd_phy_isol().
-- Removed sentinel entry from exynos5_usbdrd_phy_cfg[] struct.
-- Removed check for 'match' entry in probe().
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 627
4 files changed, 679 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..daa1707 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -159,6 +159,17 @@ config PHY_EXYNOS5250_USB2
particular SoC is compiled in the driver. In case of Exynos 5250
four
phys are available - device, host, HSIC0 and HSIC.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
config PHY_XGENE
tristate APM X-Gene 15Gbps PHY support
depends on HAS_IOMEM OF (ARM64 || COMPILE_TEST)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..333ba98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_PHY_SAMSUNG_USB2)+=
phy-samsung-usb2.o
obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2)
Re: [PATCH 04/15] ASoC: samsung-idma: avoid 64-bit division
On 04/29/2014 04:48 PM, Xia Kaixu wrote: From: Arnd Bergmann a...@arndb.de dma_addr_t may be 64 bit wide, which causes a build failure when doing a division on it. Here it is safe to cast to an u32 type, which avoids the problem. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Xia Kaixu kaixu@linaro.org Cc: Mark Brown broo...@kernel.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Sangbeom Kim sbki...@samsung.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: alsa-de...@alsa-project.org --- Tested with ARM_LPAE enabled. Without this patch, getting following error. sound/built-in.o: In function `iis_irq': sound/soc/samsung/idma.c:277: undefined reference to `__aeabi_uldivmod' Tested-by: Tushar Behera tushar.beh...@linaro.org sound/soc/samsung/idma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/idma.c b/sound/soc/samsung/idma.c index 3d5cf15..e9891b4 100644 --- a/sound/soc/samsung/idma.c +++ b/sound/soc/samsung/idma.c @@ -274,7 +274,7 @@ static irqreturn_t iis_irq(int irqno, void *dev_id) addr = readl(idma.regs + I2SLVL0ADDR) - idma.lp_tx_addr; addr += prtd-periodsz; - addr %= (prtd-end - prtd-start); + addr %= (u32)(prtd-end - prtd-start); addr += idma.lp_tx_addr; writel(addr, idma.regs + I2SLVL0ADDR); -- Tushar Behera -- 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 Resend] ARM: EXYNOS: Map SYSRAM address through DT
Hi Heiko, On 16 April 2014 22:55, Heiko Stübner he...@sntech.de wrote: Hi, Am Mittwoch, 16. April 2014, 16:35:36 schrieb Arnd Bergmann: On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote: Instead of hardcoding the SYSRAM details for each SoC, pass this information through device tree (DT) and make the code SoC agnostic. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- Rebased on latest linux-next. Thanks for sending this again. I'd like Heiko to have a look and provide an Ack if he's happy with it. It seems similar to what he did with the SRAM for mach-rockchip, and if it is we should use the same binding that he introduced, which would be a minor variation of this. The sram binding is derived from the generic reserved-memory bindings to enable the sram in general to be used generically through the sram driver, while still retaining some areas for special purposes, like the smp-trampoline in my case. From my reading of platsmp.c, it looks like offset+0x4 starts the so called boot-registesr, which get the smp-start-address written to. So I guess it all depends on what is contained in the rest of the sysram. If it is all covered with such special registers or other special uses, the code below is fine. But if the most of the area is just general purpose sram, a solution like on rockchip might be nicer - i.e. handling the sysram via the sram driver and declaring a reserved section for the boot registers. Thanks for your inputs. In our case, we use sram for secondary boot addresses but could not find any other general purpose use. So, depending on the above: Acked-by: Heiko Stuebner he...@sntech.de So I believe your ack applies to our case :). Thanks again. -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Hi,
On Mon, Apr 28, 2014 at 9:11 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 28 Apr 2014, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
---
+static int exynos_ohci_phy_enable(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
+ int i;
+ int ret = 0;
- if (exynos_ohci-phy)
- usb_phy_init(exynos_ohci-phy);
+ if (exynos_ohci-phy) {
+ ret = usb_phy_init(exynos_ohci-phy);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; ret == 0 i PHY_NUMBER; i++)
+ if (exynos_ohci-phy_g[i])
+ ret = phy_power_on(exynos_ohci-phy_g[i]);
+ if (ret)
+ for (i--; i = 0; i--)
+ if (exynos_ohci-phy_g[i])
+ phy_power_off(exynos_ohci-phy_g[i]);
Do you want to call usb_phy_shutdown() at this point?
Yes, you are right. We should be calling usb_phy_shutdown() here. But
the two phy-provider
drivers should never work together, so one of the above PHYs will not exist.
Anyways, for code correctness too, we should be doing as you suggested.
I will change this.
+
+ return ret;
}
-static void exynos_ohci_phy_disable(struct device *dev)
+static int exynos_ohci_phy_disable(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
+ int i;
+ int ret = 0;
if (exynos_ohci-phy)
usb_phy_shutdown(exynos_ohci-phy);
+
+ for (i = 0; i PHY_NUMBER; i++)
+ if (exynos_ohci-phy_g[i])
+ ret = phy_power_off(exynos_ohci-phy_g[i]);
+
+ return ret;
}
This return value is practically meaningless. It is the status from
the last PHY only; any errors involving the other PHYs have been lost.
You may as well make this function return void.
Right, i will make this function return void and remove 'ret' from it.
@@ -210,13 +302,18 @@ static int exynos_ohci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
+ int ret;
clk_prepare_enable(exynos_ohci-clk);
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
- exynos_ohci_phy_enable(dev);
+ ret = exynos_ohci_phy_enable(dev);
+ if (ret) {
+ dev_err(dev, Failed to enable USB phy\n);
Do you want to call clk_disable_unprepare() here?
Yes, we should be calling clk_disable_unprepate() here to avoid the
warning in the next suspend cycle.
--
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 v12 00/31] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Mon, Apr 28, 2014 at 2:04 PM, Arnd Bergmann a...@arndb.de wrote: On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote: The current exynos-iommu(System MMU) driver does not work autonomously since it is lack of support for power management of peripheral blocks. For example, MFC device driver must ensure that its System MMU is disabled before MFC block is power-down not to invalidate IOTLB in the System MMU when I/O memory mapping is changed. Because a System MMU resides in the same H/W block, access to control registers of System MMU while the H/W block is turned off must be prohibited. This set of changes solves the above problem with setting each System MMUs as the parent of the device which owns the System MMU to receive the information when the device is turned off or turned on. Another big change to the driver is the support for devicetree. The bindings for System MMU is described in Documentation/devicetree/bindings/arm/samsung/system-mmu.txt Sorry I've been absent from the review so far. Most of the patches seem entirely reasonable to me, but I'm worried about the DT binding aspect. We are going to see more systems shipping with IOMMUs now, and we are seeing an increasing number of submissions for 64-bit systems. We really have to work out what the DT representation for IOMMUs should look like in general before adding another ad-hod implementation that is private to one driver. Hi Arnd, No issues. Its good that finally you are here :) I am going through the possibilities for new bindings that you mentioned in the other thread. -- [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU Exynos IOMMU driver is pretty simple with only one exception, some devices are using multiple IOMMUs. From starting (of this patch set), we were trying to fix three major issues. [1] How to control the probing order of required IOMMU(s) for a given device and a device itself. [2] Handling multiple IOMMUs for one device. [3] Generic DT bindings to link Device and IOMMUs. I have gone through the implementation of Tegra SMMU driver by Hiroshi Doyu -- [PATCHv7 00/12] Unifying SMMU driver among Tegra SoCs [https://lkml.org/lkml/2013/12/12/74] For the first point [1], -- Tegra implementation tries to fix this issue with these two patches -- iommu/of: check if dependee iommu is ready or not [http://patchwork.ozlabs.org/patch/300560/] -- driver/core: populate devices in order for IOMMUs [http://patchwork.ozlabs.org/patch/300558/] I can follow this driver if this approach is acceptable. For the second point [2] -- Currently we are handling this issue by providing same mapping for all IOMMUs linked to the same device. And current Exynos drivers doesn't have any special implementation to handle this case differently. I thought of understanding how Tegra SMMU driver is handling this case. Frankly speaking, I didn't understand how its done there. For the third point [3] --- As Tegra SMMU driver is inline with the discussion in other thread, we can follow the same bindings, unless the discussion takes us in the other direction. KyongHo Cho is the author for this driver and hope he has more inputs. Regards, Shaik Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/12] ARM: EXYNOS: Make exynos machine_ops as static
As machine function ops are used only in this file let's make
them static.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 3d69e8d..06dcce5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -198,7 +198,7 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos_restart(enum reboot_mode mode, const char *cmd)
+static void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
u32 val = 0x1;
@@ -239,7 +239,7 @@ void __init exynos_cpufreq_init(void)
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
}
-void __init exynos_init_late(void)
+static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
@@ -300,7 +300,7 @@ static void __init exynos_map_io(void)
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
}
-void __init exynos_init_io(void)
+static void __init exynos_init_io(void)
{
debug_ll_io_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 v3 04/12] ARM: EXYNOS: Move SYSREG definition into sys-reg specific file.
From: Young-Gun Jang yg1004.j...@samsung.com While making PMU implementation to be device tree based, there are few register offsets related with SYSREG present in regs-pmu.h, so let's make a new header file regs-sys.h to keep all such SYSREG related register offsets and remove them from regs-pmu.h Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/exynos.c |1 + arch/arm/mach-exynos/pm.c |1 + arch/arm/mach-exynos/regs-pmu.h |3 --- arch/arm/mach-exynos/regs-sys.h | 22 ++ 4 files changed, 24 insertions(+), 3 deletions(-) create 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 9315bd8..a7b45db 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -31,6 +31,7 @@ #include common.h #include mfc.h #include regs-pmu.h +#include regs-sys.h #define L2_AUX_VAL 0x7C470001 #define L2_AUX_MASK 0xC200 diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c index b380d48..f445c49 100644 --- a/arch/arm/mach-exynos/pm.c +++ b/arch/arm/mach-exynos/pm.c @@ -36,6 +36,7 @@ #include common.h #include regs-pmu.h +#include regs-sys.h /** * struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index 6c1d2db..b68b5cc 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -15,7 +15,6 @@ #include mach/map.h #define S5P_PMUREG(x) (S5P_VA_PMU + (x)) -#define S5P_SYSREG(x) (S3C_VA_SYS + (x)) #define S5P_CENTRAL_SEQ_CONFIGURATION S5P_PMUREG(0x0200) @@ -178,8 +177,6 @@ /* For EXYNOS5 */ -#define EXYNOS5_SYS_I2C_CFG S5P_SYSREG(0x0234) - #define EXYNOS5_AUTO_WDTRESET_DISABLE S5P_PMUREG(0x0408) #define EXYNOS5_MASK_WDTRESET_REQUEST S5P_PMUREG(0x040C) diff --git a/arch/arm/mach-exynos/regs-sys.h b/arch/arm/mach-exynos/regs-sys.h new file mode 100644 index 000..84332b0 --- /dev/null +++ b/arch/arm/mach-exynos/regs-sys.h @@ -0,0 +1,22 @@ +/* + * 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)) + +/* For EXYNOS5 */ +#define EXYNOS5_SYS_I2C_CFGS5P_SYSREG(0x0234) + +#endif /* __ASM_ARCH_REGS_SYS_H */ -- 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 v3 08/12] ARM: EXYNOS: Remove linux/bug.h from pmu.c
This patch removes unnecessary header file inclusion from pmu.c. Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/pmu.c |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c index 05c7ce1..4c3453a 100644 --- a/arch/arm/mach-exynos/pmu.c +++ b/arch/arm/mach-exynos/pmu.c @@ -11,7 +11,6 @@ #include linux/io.h #include linux/kernel.h -#include linux/bug.h #include plat/cpu.h -- 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 v3 12/12] ARM: EXYNOS: Move PMU specific definitions from common.h
From: Young-Gun Jang yg1004.j...@samsung.com
This patch moves PMU specific definitions into a new file
as exynos-pmu.h. This will help in making PMU implementation
independent of common.h header.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h | 17 -
arch/arm/mach-exynos/exynos-pmu.h | 31 +++
arch/arm/mach-exynos/pm.c |1 +
arch/arm/mach-exynos/pmu.c|2 +-
4 files changed, 33 insertions(+), 18 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 2922f20..8f45a35 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -35,24 +35,7 @@ extern struct smp_operations exynos_smp_ops;
extern void exynos_cpu_die(unsigned int cpu);
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END (-1U)
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
extern unsigned long l2x0_regs_phys;
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern void exynos_enter_aftr(void);
extern struct regmap *get_exynos_pmuregmap(void);
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..16ff036
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+#define PMU_TABLE_END (-1U)
+
+enum sys_powerdown {
+ SYS_AFTR,
+ SYS_LPA,
+ SYS_SLEEP,
+ NUM_SYS_POWERDOWN,
+};
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ unsigned int val[NUM_SYS_POWERDOWN];
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index ee427d7..a7a1b7f 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -38,6 +38,7 @@
#include common.h
#include regs-pmu.h
#include regs-sys.h
+#include exynos-pmu.h
static struct regmap *pmu_regmap;
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 030df96..1570761 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -16,7 +16,7 @@
#include linux/slab.h
#include linux/mfd/syscon.h
-#include common.h
+#include exynos-pmu.h
#include regs-pmu.h
struct exynos_pmu_data {
--
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 v3 05/12] ARM: EXYNOS: Remove file path from comment section
Many files under arm/mach-exynos are having file path in file comment section which is invalid now. So for better code maintainability let's remove them. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/headsmp.S |2 -- arch/arm/mach-exynos/hotplug.c |3 +-- arch/arm/mach-exynos/include/mach/memory.h |3 +-- arch/arm/mach-exynos/platsmp.c |3 +-- 4 files changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-exynos/headsmp.S b/arch/arm/mach-exynos/headsmp.S index cdd9d91..698c57f 100644 --- a/arch/arm/mach-exynos/headsmp.S +++ b/arch/arm/mach-exynos/headsmp.S @@ -1,6 +1,4 @@ /* - * linux/arch/arm/mach-exynos4/headsmp.S - * * Cloned from linux/arch/arm/mach-realview/headsmp.S * * Copyright (c) 2003 ARM Limited diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 5eead53..73b0b5c 100644 --- a/arch/arm/mach-exynos/hotplug.c +++ b/arch/arm/mach-exynos/hotplug.c @@ -1,5 +1,4 @@ -/* linux arch/arm/mach-exynos4/hotplug.c - * +/* * Cloned from linux/arch/arm/mach-realview/hotplug.c * * Copyright (C) 2002 ARM Ltd. diff --git a/arch/arm/mach-exynos/include/mach/memory.h b/arch/arm/mach-exynos/include/mach/memory.h index 2a4cdb7..e19df1f 100644 --- a/arch/arm/mach-exynos/include/mach/memory.h +++ b/arch/arm/mach-exynos/include/mach/memory.h @@ -1,5 +1,4 @@ -/* linux/arch/arm/mach-exynos4/include/mach/memory.h - * +/* * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. * http://www.samsung.com * diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 03e5e9f..29c2286 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -1,5 +1,4 @@ -/* linux/arch/arm/mach-exynos4/platsmp.c - * +/* * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd. * http://www.samsung.com * -- 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 v3 03/12] ARM: EXYNOS: Cleanup mach-exynos/common.h file
Remove unused and unwanted declarations from mach-exynos/common.h Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/common.h |9 - 1 file changed, 9 deletions(-) diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index 30123a0..8a4aa0b 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -15,15 +15,6 @@ #include linux/reboot.h #include linux/of.h -void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1); - -struct map_desc; -void exynos_init_io(void); -void exynos_restart(enum reboot_mode mode, const char *cmd); -void exynos_cpuidle_init(void); -void exynos_cpufreq_init(void); -void exynos_init_late(void); - void exynos_firmware_init(void); #ifdef CONFIG_PINCTRL_EXYNOS -- 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 v3 02/12] ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine
As exynos_cpuidle_init and exynos_cpufreq_init function have just one lines
of code for registering platform devices. We can move these lines to
exynos_dt_machine_init and delete exynos_cpuidle_init and exynos_cpufreq_init
function. This will help in reducing lines of code in exynos.c, making it
more cleaner.
Suggested-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 06dcce5..9315bd8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -226,19 +226,6 @@ static struct platform_device exynos_cpuidle = {
.id= -1,
};
-void __init exynos_cpuidle_init(void)
-{
- if (soc_is_exynos5440())
- return;
-
- platform_device_register(exynos_cpuidle);
-}
-
-void __init exynos_cpufreq_init(void)
-{
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
-}
-
static void __init exynos_init_late(void)
{
if (of_machine_is_compatible(samsung,exynos5440))
@@ -367,8 +354,10 @@ static void __init exynos_dt_machine_init(void)
}
}
- exynos_cpuidle_init();
- exynos_cpufreq_init();
+ if (!soc_is_exynos5440())
+ platform_device_register(exynos_cpuidle);
+
+ platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
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 v3 11/12] ARM: EXYNOS: Add platform driver support for Exynos PMU.
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform_device support by registering static platform device.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
bind PMU configuration and SoC specific initialization function.
- Probe function will scan DT and based on matching PMU compatibility
string initialize pmu_context which will be platform_data for driver.
- Obtain PMU regmap handle using syscon_regmap_lookup_by_phandle so
that we can reduce dependency over machine header files.
- Separate each SoC's PMU initialization function and make it as part of
platform data.
- It also removes uses of soc_is_exynos() thus making PMU implementation
independent of plat/cpu.h.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
---
arch/arm/mach-exynos/pmu.c | 280 +++-
1 file changed, 224 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..030df96 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* EXYNOS - CPU PMU(Power Management Unit) support
@@ -9,20 +9,33 @@
* published by the Free Software Foundation.
*/
-#include linux/io.h
-#include linux/kernel.h
+#include linux/module.h
#include linux/regmap.h
-
-#include plat/cpu.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/mfd/syscon.h
#include common.h
#include regs-pmu.h
-static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+ struct device *dev;
+ struct exynos_pmu_data *pmu_data;
+ struct regmap *pmu_regmap;
+};
+
+static struct exynos_pmu_context *pmu_context;
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
- /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
{ S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
{ S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
@@ -216,7 +229,7 @@ static const struct exynos_pmu_conf exynos4412_pmu_config[]
= {
};
static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
- /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+ /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
{ EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
{ EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
{ EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0,
0x0} },
@@ -339,7 +352,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
EXYNOS5_ISP_ARM_OPTION,
};
-static void exynos5_init_pmu(void)
+void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
unsigned int tmp;
@@ -348,81 +361,236 @@ static void exynos5_init_pmu(void)
* Enable both SC_FEEDBACK and SC_COUNTER
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
- regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_read(pmu_context-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
tmp |= (EXYNOS5_USE_SC_FEEDBACK |
EXYNOS5_USE_SC_COUNTER);
- regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+ regmap_write(pmu_context-pmu_regmap,
+ exynos5_list_both_cnt_feed[i], tmp);
}
/*
* SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
*/
- regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_read(pmu_context-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
- regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+ regmap_write(pmu_context-pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
/*
* Disable WFI/WFE on XXX_OPTION
*/
for (i = 0 ; i ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
- tmp = regmap_read(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
- tmp);
+ tmp = regmap_read(pmu_context-pmu_regmap,
+
[PATCH v3 10/12] ARM: EXYNOS: Move mach/map.h inclusion from regs-pmu.h to platsmp.c
As we have removed static mappings from regs-pmu.h it does not need map.h anymore. But platsmp.c needed this and till now it got included indirectly. So lets move header inclusion of mach/map.h from regs-pmu.h to platsmp.c. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-exynos/platsmp.c |1 + arch/arm/mach-exynos/regs-pmu.h |2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 375ea4e..8f3b866 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -27,6 +27,7 @@ #include asm/firmware.h #include plat/cpu.h +#include mach/map.h #include common.h #include regs-pmu.h diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index a72b1bc..1d83c7e 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -12,8 +12,6 @@ #ifndef __ASM_ARCH_REGS_PMU_H #define __ASM_ARCH_REGS_PMU_H __FILE__ -#include mach/map.h - #define S5P_CENTRAL_SEQ_CONFIGURATION 0x0200 #define S5P_CENTRAL_LOWPWR_CFG (1 16) -- 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 v3 00/12] ARM: Exynos: PMU cleanup and refactoring for using DT
This patch series, does some minor cleanup of exynos machine files. It also modifies Exynos Power Management Unit (PMU) related code for converting it into a platform_driver. This is also preparation for moving PMU related code out of machine folder into a either drivers/mfd, or drivers/power or some other suitable place so that ARM64 based SoC can utilize common piece of code. These patches require change in Exynos SoC dtsi files, which has been posted as separate patch series [2] These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) branch and on top of Daniel Lezcano's Exynos cpuidle refactor patches [3]. These patches depends on following three patch series: [1] mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 [2] Add PMU node for Exynos SoCs http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29329.html [3] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085 We have tested these patches on SMDK5250 board for System boot and Arndale (Exynos5250) board for System boot and PMU initialization and S2R. For testing on Arndale (Exynos5250) board: Tested-by: Pankaj Dubey pankaj.du...@samsung.com Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed exynos_cpuidle_init and exynos_cpufreq_init code as suggested by Tomasz Figa. - Removed early mapping of PMU base address from exynos.c and removed get_exynos_pmuaddr function. Instead of this added code in platsmp.c to get PMU base address using of_iomap as suggested by Tomasz Figa. - Converted PMU implementation into platform_driver by using static platform_device method. Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Added patch: Make exynos machine_ops as static. For making more cleanup in mach-exynos/common.h as suggested by Tomasz Figa. - Addressed comments of Tomasz Figa for cleaning mach-exynos/common.h. - Updated patch: Remove file path from comment section As suggested by Michel Simek, instead of updating file path lets remove them from each file under mach-exynos. Even though Kukjin pointed out that there is similar patch pending from Sachin/Tushar but since I could not find I have included this here. If I have missed something please point to any existing such patch. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of exynos_pmu_base, as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that early_syscon_init requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as smp_secondary_init will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Added patch: Remove linux/bug.h from pmu.c. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Move mach/map.h inclusion from regs-pmu.h to platsmp.c - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to drivers/mfd folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as samsung, exynosxxx-pmu, syscon, once we enable MFD_SYSCON config option, current syscon driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using syscon_early_regmap_lookup_by_phandle. If there is any better solution please suggest. Pankaj Dubey (8): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine ARM: EXYNOS: Cleanup mach-exynos/common.h file ARM: EXYNOS: Remove file path from comment section ARM: EXYNOS: Remove linux/bug.h from pmu.c ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Move mach/map.h inclusion from regs-pmu.h to platsmp.c ARM: EXYNOS: Add platform driver support for Exynos PMU. Young-Gun Jang (4): ARM: EXYNOS: Move SYSREG definition into sys-reg specific file. ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Move PMU specific definitions from common.h
[PATCH v3 06/12] ARM: EXYNOS: Remove regs-pmu.h header dependency from pm_domain
From: Young-Gun Jang yg1004.j...@samsung.com
Current pm_domain.c file uses S5P_INT_LOCAL_PWR_EN definition from
regs-pmu.h and hence needs to include this header file. As there is
no other user of S5P_INT_LOCAL_PWR_EN definition other than pm_domain,
to remove regs-pmu.h header file dependency from pm_domain.c it's
better we define this definition in pm_domain.c file itself and thus it
will help in removing header file inclusion from pm_domain.c.
Also removing S5P_ prefix from macro.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/pm_domains.c |8
arch/arm/mach-exynos/regs-pmu.h |1 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index fe6570e..e45d288 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -22,7 +22,7 @@
#include linux/of_platform.h
#include linux/sched.h
-#include regs-pmu.h
+#define INT_LOCAL_PWR_EN 0x7
/*
* Exynos specific wrapper around the generic power domain
@@ -44,13 +44,13 @@ static int exynos_pd_power(struct generic_pm_domain
*domain, bool power_on)
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd-base;
- pwr = power_on ? S5P_INT_LOCAL_PWR_EN : 0;
+ pwr = power_on ? INT_LOCAL_PWR_EN : 0;
__raw_writel(pwr, base);
/* Wait max 1ms */
timeout = 10;
- while ((__raw_readl(base + 0x4) S5P_INT_LOCAL_PWR_EN) != pwr) {
+ while ((__raw_readl(base + 0x4) INT_LOCAL_PWR_EN) != pwr) {
if (!timeout) {
op = (power_on) ? enable : disable;
pr_err(Power domain %s %s failed\n, domain-name, op);
@@ -172,7 +172,7 @@ static __init int exynos4_pm_init_power_domain(void)
platform_set_drvdata(pdev, pd);
- on = __raw_readl(pd-base + 0x4) S5P_INT_LOCAL_PWR_EN;
+ on = __raw_readl(pd-base + 0x4) INT_LOCAL_PWR_EN;
pm_genpd_init(pd-pd, NULL, !on);
}
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index b68b5cc..fd8a19d 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -116,7 +116,6 @@
#define S5P_PAD_RET_EBIB_OPTIONS5P_PMUREG(0x31A8)
#define S5P_CORE_LOCAL_PWR_EN 0x3
-#define S5P_INT_LOCAL_PWR_EN 0x7
/* Only for EXYNOS4210 */
#define S5P_CMU_CLKSTOP_LCD1_LOWPWRS5P_PMUREG(0x1154)
--
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 v3 09/12] ARM: EXYNOS: Refactored code for using PMU address via DT
Under arm/mach-exynos many files are using PMU register offsets.
Since we have added support for accessing PMU base address via DT,
now we can remove PMU mapping from exynosX_iodesc. Let's convert
all these access using either of iomapped address or regmap handle.
This will help us in removing static mapping of PMU base address
as well as help in reducing dependency over machine header files.
Thus helping for migration of PMU implementation from machine to
driver folder which can be reused for ARM64 bsed SoC.
CC: Ben Dooks ben-li...@fluff.org
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Arnd Bergmann a...@arndb.de
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/common.h|4 +-
arch/arm/mach-exynos/exynos.c| 19 +-
arch/arm/mach-exynos/hotplug.c |4 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/platsmp.c | 38 +-
arch/arm/mach-exynos/pm.c| 77 ++--
arch/arm/mach-exynos/pmu.c | 40 +-
arch/arm/mach-exynos/regs-pmu.h | 506 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |1 -
9 files changed, 362 insertions(+), 330 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 33a2bee..2922f20 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -37,7 +37,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END (-1U)
enum sys_powerdown {
SYS_AFTR,
@@ -48,7 +48,7 @@ enum sys_powerdown {
extern unsigned long l2x0_regs_phys;
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 9045fd6..a59b122 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -20,6 +20,7 @@
#include linux/platform_device.h
#include linux/pm_domain.h
#include linux/mfd/syscon.h
+#include linux/regmap.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -66,11 +67,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -194,11 +190,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -206,7 +197,7 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
{
struct device_node *np;
u32 val = 0x1;
- void __iomem *addr = EXYNOS_SWRESET;
+ void __iomem *addr = NULL;
if (of_machine_is_compatible(samsung,exynos5440)) {
u32 status;
@@ -219,9 +210,9 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
val = __raw_readl(addr);
val = (val 0x) | (status 0x);
- }
-
- __raw_writel(val, addr);
+ __raw_writel(val, addr);
+ } else
+ regmap_write(exynos_pmu_regmap, EXYNOS_SWRESET, val);
}
static struct platform_device exynos_cpuidle = {
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 73b0b5c..0243ef3 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -13,6 +13,7 @@
#include linux/errno.h
#include linux/smp.h
#include linux/io.h
+#include linux/regmap.h
#include asm/cacheflush.h
#include asm/cp15.h
@@ -91,11 +92,12 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
+ struct regmap *pmu_regmap = get_exynos_pmuregmap();
for (;;) {
/* make cpu1 to be turned off at next WFI command */
if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ regmap_write(pmu_regmap, S5P_ARM_CORE1_CONFIGURATION,
0);
/*
* here's the WFI
diff --git a/arch/arm/mach-exynos/include/mach/map.h
[PATCH v3 07/12] ARM: EXYNOS: Add support for mapping PMU base address via DT
From: Young-Gun Jang yg1004.j...@samsung.com
Add support for mapping Samsung Power Management Unit (PMU)
base address from device tree. This patch also adds helper
function as get_exynos_pmuregmap. This function can be used
by other machine files such as pm.c, hotplug.c for accessing
PMU regmap handle.
Signed-off-by: Young-Gun Jang yg1004.j...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/Kconfig |2 ++
arch/arm/mach-exynos/common.h |2 ++
arch/arm/mach-exynos/exynos.c | 39 +++
3 files changed, 43 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..2f60c90 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -26,6 +26,7 @@ config ARCH_EXYNOS4
select PINCTRL
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
+ select MFD_SYSCON
help
Samsung EXYNOS4 SoCs based systems
@@ -36,6 +37,7 @@ config ARCH_EXYNOS5
select HAVE_ARM_SCU if SMP
select HAVE_SMP
select PINCTRL
+ select MFD_SYSCON
help
Samsung EXYNOS5 (Cortex-A15) SoC based systems
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 8a4aa0b..33a2bee 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -55,4 +55,6 @@ struct exynos_pmu_conf {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern void exynos_enter_aftr(void);
+extern struct regmap *get_exynos_pmuregmap(void);
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a7b45db..9045fd6 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -19,6 +19,7 @@
#include linux/of_platform.h
#include linux/platform_device.h
#include linux/pm_domain.h
+#include linux/mfd/syscon.h
#include asm/cacheflush.h
#include asm/hardware/cache-l2x0.h
@@ -36,6 +37,8 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static struct regmap *exynos_pmu_regmap;
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -260,6 +263,14 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
return 1;
}
+static const struct of_device_id exynos_dt_pmu_match[] = {
+ { .compatible = samsung,exynos4210-pmu },
+ { .compatible = samsung,exynos4212-pmu },
+ { .compatible = samsung,exynos4412-pmu },
+ { .compatible = samsung,exynos5250-pmu },
+ {},
+};
+
/*
* exynos_map_io
*
@@ -327,6 +338,32 @@ static int __init exynos4_l2x0_cache_init(void)
}
early_initcall(exynos4_l2x0_cache_init);
+
+struct regmap *get_exynos_pmuregmap()
+{
+ return exynos_pmu_regmap;
+}
+
+void __init exynos_map_pmu(void)
+{
+ struct device_node *np = NULL;
+
+ early_syscon_init();
+
+ np = of_find_matching_node(NULL, exynos_dt_pmu_match);
+
+ if (!np) {
+ pr_err(Failed to find PMU node\n);
+ return;
+ } else {
+ exynos_pmu_regmap = syscon_early_regmap_lookup_by_phandle(np,
+ samsung,syscon-phandle);
+ }
+
+ if (IS_ERR(exynos_pmu_regmap))
+ pr_err(failed to find exynos_pmu_regmap\n);
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -355,6 +392,8 @@ static void __init exynos_dt_machine_init(void)
}
}
+ exynos_map_pmu();
+
if (!soc_is_exynos5440())
platform_device_register(exynos_cpuidle);
--
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
