Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled
Quoting Tushar Behera (2014-07-10 23:18:54) On 06/13/2014 02:39 AM, Mike Turquette wrote: Quoting Tushar Behera (2014-06-12 00:29:23) On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette mturque...@linaro.org wrote: Quoting Tushar Behera (2014-06-10 22:32:17) When the output clock of AUDSS mux is disabled, we are getting kernel oops while doing a clk_get() on other clocks provided by AUDSS. Though user manual doesn't specify this dependency, we came across this issue while disabling the parent of AUDSS mux clocks. Hi Tushar, Can you help me understand better what the actual problem is? What is the root cause of the kernel oops? Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock. As per observation, when the output of AUDSS mux is gated, we are not able to do any operation on the clocks provided by MAU block (mostly the clocks used by ADMA and audio blocks). I tried to get a datasheet for Exynos 54xx but could not find it. I even looked at the public 5250 data sheet, but it is completely missing Chapter 34, Audio Subsystem, which apparently contains Figure 34-3, Clock names and clock tree diagram of MAUDIO_BLK. So without any clue about your hardware (not for lack of trying) I would guess that somewhere in the parent hierarchy you have an interface clock which must be enabled in order for you to touch the registers pertaining to the downstream audio clocks. Yes, right. As per observation, we need to keep the output of AUDSS mux enabled to access the registers present in MAU block. The right way to handle this requires two steps: 1) model your interface clock in the Linux clock framework if you haven't already (I assume it is a gate clock, or the child of a gate clock) The interface clock is already part of the clock framework. Great! 2) the clk_ops callbacks for the affected audio clocks should wrap their operations (i.e. critical secion) with a clk_enable/clk_disable pair, where the clock being enables/disable is the interface clock mentioned above in #1 The CCF is reentrant, so you can do this by simply using the top-level clk.h API from within your clk_ops callbacks. Right now, the clocks are registered with clk_register_mux, clk_register_div and clk_register_gate calls which in turn set appropriate clk_ops callbacks. If I need to wrap the register access during these clk_ops callbacks with clk_enable/clk_disable of interface lock, I would have to reimplement the clk_ops callbacks in clk-exynos-audss driver. Is that the approach that you are suggesting? Is there another way? This is one of the reasons why I don't like the basic clock types being subclassed by clock drivers. It's a brittle design that tends to fall over as soon as the basic clock types don't do what you need. And don't even get me started on how ugly clk-composite.c is! ;-) One hack you can do is to subclass the clk_ops for each of the basic clock types you use and add .prepare and .unprepare callbacks to them which enable/disable the interface clock. Some examples of this are merged and it may be what your clock driver does already. However this may not be very optimal if your consumer driver simply calls clk_prepare_enable at probe-time and never turns the interface clock off again... I might be totally wrong about the cause of the hang, but that's my best guess based on everyone's bug reports. There are 5 gate clocks within MAU block. While disabling the unused clocks, if CLK_MAU_EPLL is disabled first, then we are getting this system hang. Right. Then your accesses to the clock control register need to be protected by a clk_enable/clk_disable critical section. Regards, Mike Regards, Mike You mention calling clk_get on child clocks of the AUDSS mux fails, but I cannot imagine why. How can the enable/disable state of a clock affect the ability to clk_get other clocks? I might have a little vogue while updating the commit message (mentioning about clk_get which surely is only a s/w operation), but there is definitely some issue with handling those clocks under given scenario. I am on leave till end of this week, so I will update you more with the logs on Monday. Thanks, -- Tushar ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 0/3] drm/exynos: Allow module to be autoloaded
On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: On 2014년 07월 28일 23:45, Sjoerd Simons wrote: Hey Inki, On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: On 2014년 07월 28일 17:30, Sjoerd Simons wrote: Sorry for late, I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? The background for this is that I'm building a distribution-style multiplatform kernel, that is to say a kernel which can boot on a big set of different ARM boards. As such, the intention is to keep the core zImage as small as possible and essentially build things as far as possible as loadable modules. So in a sense, all of the hardware is hotplugged, depending on which board the kernel is actually booted on! For that use-case, exynosdrm needs to be able to build as a module (which it already can!) and it needs the required meta-data for userspace to know when it should be loaded. The latter is what my patch adds. It seems that you want that module data of sub drivers are added by depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some hot-plug system should use modules.xxxmap file to find the proper driver to load. Yes. I would like the module to export its module alias information for the subdrivers such that depmod can add it to its databases and the normal module autoloading mechanisms work as intended. Note that in my case, some hot-plug system is really just udev, not something special.. Ok, then does exynos drm driver is loaded well with your patches? It is indeed. My concern is that device_id of exynos drm core driver , exynos_drm_drv.c, wouldn't be exported to userspace, which means that exynos drm subsystem aren't bound by component framework because most sub drivers except vidi are bound by component interfaces of exynos drm core: exynos drm drv is not device tree base driver. This patchset doesn't change how that works. Really all it does is to tell userspace which devices exynosdrm supports. From the kernel side of things, there is no difference between the module being loaded based on that information vs. it being loaded by hand. -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v7 1/6] clk: samsung: add infrastructure to register cpu clocks
On 29.07.2014 07:35, Thomas Abraham wrote:
Hi Tomasz,
Thanks for your review comments. I have made most of the changes you
have suggested. The suggested modifications which I did not include is
marked below.
On Sat, Jul 19, 2014 at 6:25 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
Please see my comments inline.
On 14.07.2014 15:38, Thomas Abraham wrote:
[snip]
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
new file mode 100644
index 000..0d62968
--- /dev/null
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -0,0 +1,576 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Thomas Abraham thomas...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This file contains the utility functions to register the CPU clocks
+ * for Samsung platforms.
I'd expect few words here or in separate comment on how the code works,
i.e. assumptions made, most important procedures, etc. This is a complex
piece of code for quite complex hardware, so proper documentation is
essential.
+*/
+
+#include linux/errno.h
+#include clk.h
+
+#define E4210_SRC_CPU0x0
+#define E4210_STAT_CPU 0x200
+#define E4210_DIV_CPU0 0x300
+#define E4210_DIV_CPU1 0x304
+#define E4210_DIV_STAT_CPU0 0x400
+#define E4210_DIV_STAT_CPU1 0x404
+
+#define MAX_DIV 8
+#define DIV_MASK 7
+#define DIV_MASK_ALL 0x
+#define MUX_MASK 7
+
+#define E4210_DIV0_RATIO0_MASK 0x7
+#define E4210_DIV1_HPM_MASK ((0x7 4) | (0x7 0))
This mask contains two fields, doesn't it? I'd say it would be better
for readability if you split it.
+#define E4210_MUX_HPM_MASK (1 20)
+#define E4210_DIV0_ATB_SHIFT 16
+#define E4210_DIV0_ATB_MASK (DIV_MASK E4210_DIV0_ATB_SHIFT)
+
+#define E4210_CPU_DIV0(apll, pclk_dbg, atb, periph, corem1, corem0) \
+ (((apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \
+ ((periph) 12) | ((corem1) 8) | ((corem0) 4))
+#define E4210_CPU_DIV1(hpm, copy)\
+ (((hpm) 4) | ((copy) 0))
+
+#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud)
\
+ (((apll 24) | (pclk_dbg 20) | (atb 16) | \
+ (periph 12) | (acp 8) | (cpud 4)))
+#define E5250_CPU_DIV1(hpm, copy)\
+ (((hpm) 4) | (copy))
+
+#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud)\
+ (((apll 24) | (pclk_dbg 20) | (atb 16) | \
+ (cpud 4)))
+#define E5420_KFC_DIV(kpll, pclk, aclk)
\
+ (((kpll 24) | (pclk 20) | (aclk 4)))
Again, used macro arguments should always be surrounded with parentheses.
+
+enum cpuclk_type {
+ EXYNOS4210,
+ EXYNOS5250,
+ EXYNOS5420,
+};
+
+/**
+ * struct exynos4210_cpuclk_data: config data to setup cpu clocks.
It seems like this could be used for all Exynos SoCs, so probably should
be called exynos_cpuclk_data.
+ * @prate: frequency of the primary parent clock (in KHz).
+ * @div0: value to be programmed in the div_cpu0 register.
+ * @div1: value to be programmed in the div_cpu1 register.
+ *
+ * This structure holds the divider configuration data for dividers in the
CPU
+ * clock domain. The parent frequency at which these divider values are
valid is
+ * specified in @prate. The @prate is the frequency of the primary parent
clock.
+ * For CPU clock domains that do not have a DIV1 register, the @div1 member
+ * is optional.
+ */
+struct exynos4210_cpuclk_data {
+ unsigned long prate;
+ unsigned intdiv0;
+ unsigned intdiv1;
+};
+
+/**
+ * struct exynos_cpuclk: information about clock supplied to a CPU core.
+ * @hw: handle between CCF and CPU clock.
+ * @alt_parent: alternate parent clock to use when switching the speed
+ * of the primary parent clock.
+ * @ctrl_base: base address of the clock controller.
+ * @offset: offset from the ctrl_base address where the CPU clock div/mux
+ * registers can be accessed.
+ * @lock: cpu clock domain register access lock.
+ * @type: type of the CPU clock.
+ * @data: optional data which the actual instantiation of this clock
+ * can use.
+ * @clk_nb: clock notifier registered for changes in clock speed of the
+ * primary parent clock.
+ * @pre_rate_cb: callback function to handle PRE_RATE_CHANGE notification
+ * of the primary parent clock.
+ * @post_rate_cb: callback function to handle POST_RATE_CHANGE notification
+ * of the primary parent clock.
+ *
+ * This structure holds information required for programming the cpu clock
for
Re: [PATCH v8 1/6] clk: samsung: add infrastructure to register cpu clocks
Hi Thomas, On 29.07.2014 07:28, Thomas Abraham wrote: The CPU clock provider supplies the clock to the CPU clock domain. The composition and organization of the CPU clock provider could vary among Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers and gates. This patch defines a new clock type for CPU clock provider and adds infrastructure to register the CPU clock providers for Samsung platforms. Cc: Tomasz Figa t.f...@samsung.com Signed-off-by: Thomas Abraham thomas...@samsung.com --- drivers/clk/samsung/Makefile |2 +- drivers/clk/samsung/clk-cpu.c | 335 + drivers/clk/samsung/clk-cpu.h | 91 +++ 3 files changed, 427 insertions(+), 1 deletion(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h Thanks for keeping up with review comments. Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 v8 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
Hi Thomas,
Just few minor comments for things I probably missed before.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -1356,6 +1357,16 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst = {
+ { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
+ { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
+ { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
I have noticed that the old driver does not have this operating point.
While it is probably OK to add this one and even few more for all
possible APLL settings, I am interested in how you obtained the values
for DIV0 and DIV1 registers for this configuration.
+ { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
+ { 0 },
+};
[snip]
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 4273891..855d809 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL6
#define CLK_FOUT_EPLL7
#define CLK_FOUT_VPLL8
+#define CLK_ARM_CLK 12
Why 12 not 9?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 07/29/2014 02:57 AM, YoungJun Cho wrote:
Hi Andrzej,
On 07/29/2014 01:09 AM, Andrzej Hajda wrote:
On 07/28/2014 04:00 AM, Inki Dae wrote:
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.
What do you mean by command data? It could be:
- all transfer in command mode of operations,
- transfer initialized by the driver by writing to DSIM registers.
The 2nd one.
MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.
What is the meaning of this flag in case of command mode of operation?
I'm also not sure that there is a case to transfer image data in Low
Power Mode, but this flag is not related with 'command mode' only.
Inki may consider generic condition.
Maybe it would be better to create flags based on source of data/FIFOs:
- commands send by SFR registers,
- commands generated from data sent from Display Controller.
And above two flags can be combined together to transfer command and video
data to Panel device.
MIPI DSI spec says,
the host processor controls the desired mode of clock operation.
Host protocol and applications control Clock Lane operating mode
(High Speed or Low Power mode). System designers are responsible
for understanding the clock requirements for peripherals attached
to DSI and controlling clock behavior in accordance with those
requirements.
Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.
Is this requirement for initial commands, or for all commands.
Btw what is the mode of operation of nt35502a? What flags do you need
for it?
The nt35502a panel is video(RGB) mode panel and it requires low power
mode for initial commands, which means to initialize nt35502a panel, the
initial commands are transferred by LP mode(Not HS mode).
And after initialization, its other features like gamma control or etc
could be controlled in HS mode.
It sounds similar to my tc358764 bridge driver [1]. The difference is that
it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM.
As I understand nt35502a requires also different driving of
TxRequestHSClk signal
and this seems to me unrelated to LPM. As LPM is not related at all with
HS clock, AFAIK.
Regards
Andrzej
[1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559
Thank you.
Best regards YJ
Changelog v2: just add more descriptions.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_mipi_dsi.c |3 +++
include/drm/drm_mipi_dsi.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi-mode_flags MIPI_DSI_MODE_CMD_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops-transfer(dsi-host, msg);
}
Shouldn't this be also the same for dcs read?
Anyway I think check in the DSIM should be used instead, as panel driver
can issue other dsi transfers without MIPI_DSI_MSG_USE_LPM flag set.
Regards
Andrzej
EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host
*host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
___
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: [PATCH v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Thomas,
Other than the same question about 400 MHz OPP for Exynos4210, I have
also few more inline.
On 29.07.2014 07:28, Thomas Abraham wrote:
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific cpufreq driver
to using generic cpufreq drivers.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/boot/dts/exynos4210-origen.dts |6
arch/arm/boot/dts/exynos4210-trats.dts |6
arch/arm/boot/dts/exynos4210-universal_c210.dts |6
arch/arm/boot/dts/exynos4210.dtsi | 12 +++
arch/arm/boot/dts/exynos5250-arndale.dts|6
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6
arch/arm/boot/dts/exynos5250-smdk5250.dts |6
arch/arm/boot/dts/exynos5250.dtsi | 23 ++
arch/arm/boot/dts/exynos5420-smdk5420.dts |6
There are more Exynos5420-based boards supported in mainline. If you do
not have necessary data and/or hardware to fully enable the new driver
on them, you should add responsible people on Cc list, so at least they
know they have one more item on their TODO list. Added them for you.
arch/arm/boot/dts/exynos5420.dtsi | 38
+++
10 files changed, 115 insertions(+)
[snip]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..876247a 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -63,6 +63,29 @@
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 20;
Where does this latency value comes from? How did you calculate it?
For example, on Exynos4210, for all operating points added by your
patches, the highest PLL locking latency will be 60uS, because the
highest PDIV value would be 6 and PLL lock time is PDIV*240 ticks of 24
MHz reference clock.
+
+ operating-points =
+ 170 130
+ 160 125
[snip]
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6052aa9..084e587 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -24,6 +24,12 @@
bootargs = console=ttySAC2,115200 init=/linuxrc;
};
+ cpus {
Is there no regulator for cpu0?
+ cpu@4 {
+ cpu0-supply = buck6_reg;
+ };
+ };
+
fixed-rate-clocks {
oscclk {
compatible = samsung,exynos5420-oscclk;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..1116d55 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
[snip]
cpu1: cpu@1 {
@@ -69,6 +87,7 @@
reg = 0x1;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 20;
Do you need to specify this property for every CPU or rather just for
those which have operating points specified?
Best regards,
Tomasz
--
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 v8 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
On 29.07.2014 07:28, Thomas Abraham wrote: The new CPU clock type allows the use of generic CPUfreq drivers. So for Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420, which did not have CPUfreq driver support, enable the use of generic CPUfreq driver. Suggested-by: Tomasz Figa t.f...@samsung.com Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Thomas Abraham thomas...@samsung.com --- arch/arm/mach-exynos/exynos.c | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 v8 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
[CC Bart]
On 29.07.2014 07:28, Thomas Abraham wrote:
Exynos4210 and Exynos5250 based platforms have switched over to use generic
cpufreq drivers for cpufreq functionality. So the Exynos specific cpufreq
drivers for these platforms can be removed.
Cc: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/cpufreq/Kconfig.arm | 22
drivers/cpufreq/Makefile |2 -
drivers/cpufreq/exynos4210-cpufreq.c | 184 -
drivers/cpufreq/exynos5250-cpufreq.c | 210
--
4 files changed, 418 deletions(-)
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7364a53..f81fc3e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -28,17 +28,6 @@ config ARM_VEXPRESS_SPC_CPUFREQ
config ARM_EXYNOS_CPUFREQ
bool
-config ARM_EXYNOS4210_CPUFREQ
- bool SAMSUNG EXYNOS4210
- depends on CPU_EXYNOS4210
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS4210
- SoC (S5PV310 or S5PC210).
-
- If in doubt, say N.
-
config ARM_EXYNOS4X12_CPUFREQ
bool SAMSUNG EXYNOS4x12
depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
@@ -50,17 +39,6 @@ config ARM_EXYNOS4X12_CPUFREQ
If in doubt, say N.
-config ARM_EXYNOS5250_CPUFREQ
- bool SAMSUNG EXYNOS5250
- depends on SOC_EXYNOS5250
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS5250
- SoC.
-
- If in doubt, say N.
-
config ARM_EXYNOS5440_CPUFREQ
bool SAMSUNG EXYNOS5440
depends on SOC_EXYNOS5440
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..fac36ef 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,9 +52,7 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) +=
arm_big_little_dt.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
deleted file mode 100644
index 61a5431..000
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4210 - CPU frequency scaling support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/module.h
-#include linux/kernel.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/slab.h
-#include linux/cpufreq.h
-#include linux/of.h
-#include linux/of_address.h
-
-#include exynos-cpufreq.h
-
-static struct clk *cpu_clk;
-static struct clk *moutcore;
-static struct clk *mout_mpll;
-static struct clk *mout_apll;
-static struct exynos_dvfs_info *cpufreq;
-
-static unsigned int exynos4210_volt_table[] = {
- 125, 115, 105, 975000, 95,
-};
-
-static struct cpufreq_frequency_table exynos4210_freq_table[] = {
- {0, L0, 1200 * 1000},
- {0, L1, 1000 * 1000},
- {0, L2, 800 * 1000},
- {0, L3, 500 * 1000},
- {0, L4, 200 * 1000},
- {0, 0, CPUFREQ_TABLE_END},
-};
-
-static struct apll_freq apll_freq_4210[] = {
- /*
- * values:
- * freq
- * clock divider for CORE, COREM0, COREM1, PERIPH, ATB, PCLK_DBG, APLL,
RESERVED
- * clock divider for COPY, HPM, RESERVED
- * PLL M, P, S
- */
- APLL_FREQ(1200, 0, 3, 7, 3, 4, 1, 7, 0, 5, 0, 0, 150, 3, 1),
- APLL_FREQ(1000, 0, 3, 7, 3, 4, 1, 7, 0, 4, 0, 0, 250, 6, 1),
- APLL_FREQ(800, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 200, 6, 1),
- APLL_FREQ(500, 0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 250, 6, 2),
- APLL_FREQ(200, 0, 1, 3, 1, 3, 1, 0, 0, 3, 0, 0, 200, 6, 3),
-};
-
-static void exynos4210_set_clkdiv(unsigned int div_index)
-{
- unsigned int tmp;
-
- /* Change Divider - CPU0 */
-
- tmp = apll_freq_4210[div_index].clk_div_cpu0;
-
- __raw_writel(tmp, cpufreq-cmu_regs + EXYNOS4_CLKDIV_CPU);
-
- do {
- tmp = __raw_readl(cpufreq-cmu_regs +
Re: [PATCH v8 6/6] clk: samsung: remove unused clock aliases and update clock flags
Hi Thomas,
You can find few comments inline.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
^^^
Keep in mind that following clocks are common for Exynos4210 and
Exynos4x12. Have you tested this series on a board based on Exynos4212
or 4412 to verify that it does not break the legacy driver? (I would
test it myself, but I am on holidays at the moment.)
DIV(0, div_clkout_rightbus, mout_clkout_rightbus,
CLKOUT_CMU_RIGHTBUS, 8, 6),
- DIV(0, div_core, mout_core, DIV_CPU0, 0, 3),
- DIV(0, div_corem0, div_core2, DIV_CPU0, 4, 3),
- DIV(0, div_corem1, div_core2, DIV_CPU0, 8, 3),
- DIV(0, div_periph, div_core2, DIV_CPU0, 12, 3),
[snip]
@@ -1501,7 +1507,7 @@ static void __init exynos4_clk_init(struct device_node
*np,
exynos4_soc == EXYNOS4210 ? Exynos4210 : Exynos4x12,
_get_rate(sclk_apll), _get_rate(sclk_mpll),
_get_rate(sclk_epll), _get_rate(sclk_vpll),
- _get_rate(arm_clk));
+ _get_rate(armclk));
This will not work on Exynos4412, because there is no armclk added for
this SoC. My suggestion is to simply keep name of the clock as is, move
current arm_clk divider to Exynos4x12-specific clocks and register
Exynos4210 CPU clock as arm_clk.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas Färber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
+
dp-controller@145B {
status = okay;
pinctrl-names = default;
- pinctrl-0 = dp_hpd;
+ pinctrl-0 = dp_hpd_gpio;
samsung,color-space = 0;
samsung,dynamic-range = 0;
samsung,ycbcr-coeff = 0;
@@ -75,6 +79,7 @@
samsung,link-rate = 0x0a;
samsung,lane-count = 1;
samsung,hpd-gpio = gpc3 0 0;
+ bridge = ps8622;
};
fixed-rate-clocks {
@@ -387,6 +392,17 @@
status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
+
+ ps8622: ps8622-bridge@08 {
+ compatible = parade,ps8622;
+ reg = 0x08;
+ sleep-gpios = gpc3 6 0;
+ reset-gpios = gpc3 1 0;
+ lane-count = 1;
+ panel = panel;
+ pinctrl-names = default;
+ pinctrl-0 = ps8622_gpios;
+ };
};
i2c_8 {
@@ -450,6 +466,20 @@
samsung,pin-pud = 0;
};
+ dp_hpd_gpio: dp-hpd-gpio {
+ samsung,pins = gpc3-0;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
+
+ ps8622_gpios: ps8622-gpios {
+ samsung,pins = gpc3-1, gpc3-6;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
s5m8767_dvs: s5m8767-dvs {
samsung,pins = gpd1-0, gpd1-1, gpd1-2;
samsung,pin-function = 0;
--
1.9.3
Re: [PATCH V6 8/8] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
Am 25.07.2014 21:22, schrieb Ajay Kumar:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/vendor-prefixes.txt|1 +
.../devicetree/bindings/video/bridge/ps8622.txt| 19 +
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/ps8622.c| 602
5 files changed, 633 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 46a311e..b4a99cc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -96,6 +96,7 @@ nxp NXP Semiconductors
onnn ON Semiconductor Corp.
opencoresOpenCores.org
panasonicPanasonic Corporation
+parade Parade Technologies Inc.
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
plathome Plat'Home Co., Ltd.
diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt
b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
new file mode 100644
index 000..fdeafb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/ps8622.txt
@@ -0,0 +1,19 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: parade,ps8622 or parade,ps8625
+ - reg: first i2c address of the bridge
+ - sleep-gpios: OF device-tree gpio specification
+ - reset-gpios: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+
+Example:
+ ps8622-bridge@48 {
Nit: Shouldn't this be lvds-bridge like in 7/8 or something else not
derived from the specific model? Applies to the DT series as well.
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpios = gpc3 6 1 0 0;
+ reset-gpios = gpc3 1 1 0 0;
+ lane-count = 1
+ };
[...]
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..ec60fcf
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,602 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
[...]
+MODULE_AUTHOR(Vincent Palatin vpala...@chromium.org);
+MODULE_DESCRIPTION(Parade ps8622 eDP-LVDS converter driver);
+MODULE_LICENSE(GPL);
GPL v2?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Thierry
pgpIi7FlD727t.pgp
Description: PGP signature
Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 07/29/2014 05:42 AM, Inki Dae wrote:
On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
On 07/28/2014 04:00 AM, Inki Dae wrote:
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Changelog v2: Enable High Speed clock only in case of stand by request.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
*dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi-lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi-mode_flags MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi
*dsi)
writel(reg, dsi-reg_base + DSIM_PHYTIMING2_REG);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi-reg_base + DSIM_CLKCTRL_REG);
+
+ reg = ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
+}
+
I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
it works with and without the bit set.
If you can test thmorstat board, you will face with that its panel is
not worked.
So it means this panel requires proper driving of this bit, but it does
not prove it is
LPM related.
So I start to suspect this bit is not just for simply enable/disable HS
clock as function name suggests, do you know what is its
exact meaning? The specs are quite succinct on it.
HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
This sounds very strange. DSI specs and D-PHY specs says clearly
that LPM transmissions are unrelated to HS clock [1][2]. Even timing
diagrams
in Exynos specs shows no dependency of LPM transmissions on HS clock.
And the
description of TxRequestHsClk bit says HS clock request for HS transfer
at clock lane (Turn
on HS clock).
Maybe different flag should be used to describe your panel requirements
regarding this bit.
It would be good to see the real initialization sequence in form of
pseudo-code or better in the driver.
[1]: MIPI DSI: Note that in Low Power signaling mode, LP clock is
functionally embedded in the data signals. When LP
data transmission ends, the clock effectively stops and subsequent LP
clocks are not available to the
peripheral. The peripheral shall not require additional bits, bytes, or
packets from the host processor in
order to complete processing or pipeline movement of received data in LP
mode transmissions. There are a
variety of ways to meet this requirement. For example, the peripheral
may generate its own clock or it may
require the host processor to keep the HS serial clock running.
[2]: MIPI D-PHY: The data is self-clocked by the applied bit encoding
and does not rely on the Clock Lane.
Regards
Andrzej
On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
in DSIM_ESCMODE register
which seems to be related to flags you have introduced:
- DSIM_CMD_LPDT_LP - transmit commands in LP mode,
- DSIM_TX_LPDT_LP - transmit data in LP mode.
As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
that host can transmit command and also image data to Panel in Low Power
Mode. So these flags are specific to MIPI-DSI controller of Exynos.
The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
This flag is set only when command msg transmission is requested by
Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
transmit command and also image.
Thanks,
Inki Dae
you use the latter?
Regards
Andrzej
static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
{
u32 reg;
@@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct
exynos_dsi *dsi, bool enable)
{
u32 reg;
+ if (!(dsi-mode_flags MIPI_DSI_MODE_VIDEO_LPM) enable)
+ exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi-reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+panel: panel {
+compatible = simple-panel;
+};
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:36:46PM +0200, Thierry Reding wrote:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT based off
kgene's for-next branch due to DT, and I run into the following:
CC drivers/gpu/drm/bridge/ptn3460.o
drivers/gpu/drm/bridge/ptn3460.c: In function
‘ptn3460_post_encoder_init’:
drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
function ‘drm_connector_register’ [-Werror=implicit-function-declaration]
drm_connector_register(ptn_bridge-connector);
^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html
That fixed my build, thanks.
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
For testing I re-applied your iommu patches (which btw fail now for 5420
due to disp_pd) but didn't know what to do about your panel-lvds
regulator patch now that it's gone.
If I don't apply this series, then commenting out the dp-controller node
gets me a working display with simplefb as before.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Done.
Thierry
pgpymGXgkzERW.pgp
Description: PGP signature
Re: [PATCH v8 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
Hi Tomasz,
On Tue, Jul 29, 2014 at 3:43 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
Just few minor comments for things I probably missed before.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -1356,6 +1357,16 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst = {
+ { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
+ { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
+ { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
I have noticed that the old driver does not have this operating point.
While it is probably OK to add this one and even few more for all
possible APLL settings, I am interested in how you obtained the values
for DIV0 and DIV1 registers for this configuration.
I found these values from an old internal repo. So far no trouble seen
with these values in all the testing.
+ { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
+ { 0 },
+};
[snip]
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 4273891..855d809 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL6
#define CLK_FOUT_EPLL7
#define CLK_FOUT_VPLL8
+#define CLK_ARM_CLK 12
Why 12 not 9?
Exynos4 uses 12 and so just wanted to keep it same for Exynos5250 as well.
Thanks,
Thomas.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
Am 29.07.2014 13:36, schrieb Thierry Reding:
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
Hi Ajay,
Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas Färber afaer...@suse.de wrote:
Am 25.07.2014 21:22, schrieb Ajay Kumar:
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have tested this after adding few DT changes for exynos5250-snow,
exynos5420-peach-pit and exynos5800-peach-pi boards.
I'm trying to test this with a modified exynos5250-spring DT
[...]
Unfortunately the most I got on Spring with attached DT was a blank
screen with a white horizontal line in the middle.
Do I need to specify a specific panel model for Spring?
[...]
From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20F=C3=A4rber?= afaer...@suse.de
Date: Sun, 27 Jul 2014 21:58:06 +0200
Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
[AF: Redone for v6]
Signed-off-by: Andreas F??rber afaer...@suse.de
---
arch/arm/boot/dts/exynos5250-spring.dts | 32
+++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index 687dfab86bc8..517b1ff2bfdf 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -64,10 +64,14 @@
vdd_pll-supply = s5m_ldo8_reg;
};
+ panel: panel {
+ compatible = simple-panel;
+ };
You can't do this. simple-panel isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Okay, that means the Snow DT is wrong, too:
https://patchwork.kernel.org/patch/4625441/
And the others specify it as fallback:
https://patchwork.kernel.org/patch/4625461/
https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Thierry
pgpKwO2bAVLF_.pgp
Description: PGP signature
Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
Am 29.07.2014 10:05, schrieb Sjoerd Simons: On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: On 2014년 07월 28일 23:45, Sjoerd Simons wrote: On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: On 2014년 07월 28일 17:30, Sjoerd Simons wrote: I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? The background for this is that I'm building a distribution-style multiplatform kernel, that is to say a kernel which can boot on a big set of different ARM boards. As such, the intention is to keep the core zImage as small as possible and essentially build things as far as possible as loadable modules. So in a sense, all of the hardware is hotplugged, depending on which board the kernel is actually booted on! For that use-case, exynosdrm needs to be able to build as a module (which it already can!) and it needs the required meta-data for userspace to know when it should be loaded. The latter is what my patch adds. It seems that you want that module data of sub drivers are added by depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some hot-plug system should use modules.xxxmap file to find the proper driver to load. Yes. I would like the module to export its module alias information for the subdrivers such that depmod can add it to its databases and the normal module autoloading mechanisms work as intended. Note that in my case, some hot-plug system is really just udev, not something special.. +1 here. While I haven't tested this on my Exynos devices yet since I'm still working on -next kernels there, here's an example of such a 3.16 config: http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default Of the platforms enabled, all drivers are configured as modules where possible, to keep kernel size small, and dracut (or kiwi) is used to generate an initrd that makes available the modules. So it would certainly be good to have the DRM auto-load somehow, without the user having to manually touch config files. In particular when I think of the Chromebooks, where Wifi needs configuration on first boot and no serial console is accessible. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Tomasz,
On Tue, Jul 29, 2014 at 4:01 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
Other than the same question about 400 MHz OPP for Exynos4210, I have
also few more inline.
On 29.07.2014 07:28, Thomas Abraham wrote:
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific cpufreq driver
to using generic cpufreq drivers.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/boot/dts/exynos4210-origen.dts |6
arch/arm/boot/dts/exynos4210-trats.dts |6
arch/arm/boot/dts/exynos4210-universal_c210.dts |6
arch/arm/boot/dts/exynos4210.dtsi | 12 +++
arch/arm/boot/dts/exynos5250-arndale.dts|6
arch/arm/boot/dts/exynos5250-cros-common.dtsi |6
arch/arm/boot/dts/exynos5250-smdk5250.dts |6
arch/arm/boot/dts/exynos5250.dtsi | 23 ++
arch/arm/boot/dts/exynos5420-smdk5420.dts |6
There are more Exynos5420-based boards supported in mainline. If you do
not have necessary data and/or hardware to fully enable the new driver
on them, you should add responsible people on Cc list, so at least they
know they have one more item on their TODO list. Added them for you.
Thanks!. Will do that next time.
arch/arm/boot/dts/exynos5420.dtsi | 38
+++
10 files changed, 115 insertions(+)
[snip]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..876247a 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -63,6 +63,29 @@
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 20;
Where does this latency value comes from? How did you calculate it?
For example, on Exynos4210, for all operating points added by your
patches, the highest PLL locking latency will be 60uS, because the
highest PDIV value would be 6 and PLL lock time is PDIV*240 ticks of 24
MHz reference clock.
Since the CPU clock is a composite clock with dividers and muxes, the
latency includes the settling time for these clock blocks as well. I
have not made any measurements of the clock transition latency.
+
+ operating-points =
+ 170 130
+ 160 125
[snip]
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6052aa9..084e587 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -24,6 +24,12 @@
bootargs = console=ttySAC2,115200 init=/linuxrc;
};
+ cpus {
Is there no regulator for cpu0?
This was a mistake. I did not intend to add regulator for cpu4 as well
but somehow I missed it. I will remove it in the next version.
+ cpu@4 {
+ cpu0-supply = buck6_reg;
+ };
+ };
+
fixed-rate-clocks {
oscclk {
compatible = samsung,exynos5420-oscclk;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index cb2b70e..1116d55 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
[snip]
cpu1: cpu@1 {
@@ -69,6 +87,7 @@
reg = 0x1;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 20;
Do you need to specify this property for every CPU or rather just for
those which have operating points specified?
The big.little cpufreq driver expects each CPU to have the clock
latency specified.
Thanks,
Thomas.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
On 29.07.2014 13:46, Thomas Abraham wrote:
Hi Tomasz,
On Tue, Jul 29, 2014 at 3:43 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
Just few minor comments for things I probably missed before.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -1356,6 +1357,16 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst = {
+ { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
+ { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
+ { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
I have noticed that the old driver does not have this operating point.
While it is probably OK to add this one and even few more for all
possible APLL settings, I am interested in how you obtained the values
for DIV0 and DIV1 registers for this configuration.
I found these values from an old internal repo. So far no trouble seen
with these values in all the testing.
OK.
+ { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
+ { 0 },
+};
[snip]
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 4273891..855d809 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL6
#define CLK_FOUT_EPLL7
#define CLK_FOUT_VPLL8
+#define CLK_ARM_CLK 12
Why 12 not 9?
Exynos4 uses 12 and so just wanted to keep it same for Exynos5250 as well.
There is no need to align those numbers between different bindings,
because preprocessor macros are used anyway and leaving holes between
clocks only makes the namespace harder to maintain.
Best regards,
Tomasz
--
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 v8 6/6] clk: samsung: remove unused clock aliases and update clock flags
Hi Tomasz,
On Tue, Jul 29, 2014 at 4:14 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
You can find few comments inline.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
^^^
Keep in mind that following clocks are common for Exynos4210 and
Exynos4x12. Have you tested this series on a board based on Exynos4212
or 4412 to verify that it does not break the legacy driver? (I would
test it myself, but I am on holidays at the moment.)
Thanks for taking time to have a look at this series. I have tested
this series with the old cpufreq driver for Exynos4412 on an
Origen4412 board and it works fine. These divider clocks are not
directly used or referenced by the legacy cpufreq driver. So I marked
them as read-only here.
DIV(0, div_clkout_rightbus, mout_clkout_rightbus,
CLKOUT_CMU_RIGHTBUS, 8, 6),
- DIV(0, div_core, mout_core, DIV_CPU0, 0, 3),
- DIV(0, div_corem0, div_core2, DIV_CPU0, 4, 3),
- DIV(0, div_corem1, div_core2, DIV_CPU0, 8, 3),
- DIV(0, div_periph, div_core2, DIV_CPU0, 12, 3),
[snip]
@@ -1501,7 +1507,7 @@ static void __init exynos4_clk_init(struct device_node
*np,
exynos4_soc == EXYNOS4210 ? Exynos4210 : Exynos4x12,
_get_rate(sclk_apll), _get_rate(sclk_mpll),
_get_rate(sclk_epll), _get_rate(sclk_vpll),
- _get_rate(arm_clk));
+ _get_rate(armclk));
This will not work on Exynos4412, because there is no armclk added for
this SoC. My suggestion is to simply keep name of the clock as is, move
current arm_clk divider to Exynos4x12-specific clocks and register
Exynos4210 CPU clock as arm_clk.
Ok. Will do this in the next version.
Thanks,
Thomas.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
On Tue, Jul 29, 2014 at 5:34 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 29.07.2014 13:46, Thomas Abraham wrote:
Hi Tomasz,
On Tue, Jul 29, 2014 at 3:43 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
Just few minor comments for things I probably missed before.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -1356,6 +1357,16 @@ static struct samsung_pll_clock
exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst =
{
+ { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
+ { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
+ { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
+ { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
I have noticed that the old driver does not have this operating point.
While it is probably OK to add this one and even few more for all
possible APLL settings, I am interested in how you obtained the values
for DIV0 and DIV1 registers for this configuration.
I found these values from an old internal repo. So far no trouble seen
with these values in all the testing.
OK.
+ { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
+ { 0 },
+};
[snip]
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 4273891..855d809 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL6
#define CLK_FOUT_EPLL7
#define CLK_FOUT_VPLL8
+#define CLK_ARM_CLK 12
Why 12 not 9?
Exynos4 uses 12 and so just wanted to keep it same for Exynos5250 as well.
There is no need to align those numbers between different bindings,
because preprocessor macros are used anyway and leaving holes between
clocks only makes the namespace harder to maintain.
Ok. I will fix this.
Thanks,
Thomas.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014년 07월 29일 20:39, Andrzej Hajda wrote:
On 07/29/2014 05:42 AM, Inki Dae wrote:
On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
On 07/28/2014 04:00 AM, Inki Dae wrote:
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Changelog v2: Enable High Speed clock only in case of stand by request.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
*dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi-lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi-mode_flags MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi
*dsi)
writel(reg, dsi-reg_base + DSIM_PHYTIMING2_REG);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi-reg_base + DSIM_CLKCTRL_REG);
+
+ reg = ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
+}
+
I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
it works with and without the bit set.
If you can test thmorstat board, you will face with that its panel is
not worked.
So it means this panel requires proper driving of this bit, but it does
not prove it is
LPM related.
So I start to suspect this bit is not just for simply enable/disable HS
clock as function name suggests, do you know what is its
exact meaning? The specs are quite succinct on it.
HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
This sounds very strange. DSI specs and D-PHY specs says clearly
that LPM transmissions are unrelated to HS clock [1][2]. Even timing
diagrams
in Exynos specs shows no dependency of LPM transmissions on HS clock.
And the
description of TxRequestHsClk bit says HS clock request for HS transfer
at clock lane (Turn
on HS clock).
There are three System power states of D-PHY, Low-Power mode, High-Speed
mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
Lane. Therefore, to use HS mode, HS clock should be enabled. On the
other hand, LP mode needs only 10MHz (max).
So do you really think LP mode will be worked well with HS clock
enabled? The purpose of LP mode is to reduce power consumption while
transmitting data. Can you reduce the power consumption in LP mode with
HS clock enabled?
Thanks,
Inki Dae
Maybe different flag should be used to describe your panel requirements
regarding this bit.
It would be good to see the real initialization sequence in form of
pseudo-code or better in the driver.
[1]: MIPI DSI: Note that in Low Power signaling mode, LP clock is
functionally embedded in the data signals. When LP
data transmission ends, the clock effectively stops and subsequent LP
clocks are not available to the
peripheral. The peripheral shall not require additional bits, bytes, or
packets from the host processor in
order to complete processing or pipeline movement of received data in LP
mode transmissions. There are a
variety of ways to meet this requirement. For example, the peripheral
may generate its own clock or it may
require the host processor to keep the HS serial clock running.
[2]: MIPI D-PHY: The data is self-clocked by the applied bit encoding
and does not rely on the Clock Lane.
Regards
Andrzej
On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
in DSIM_ESCMODE register
which seems to be related to flags you have introduced:
- DSIM_CMD_LPDT_LP - transmit commands in LP mode,
- DSIM_TX_LPDT_LP - transmit data in LP mode.
As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
that host can transmit command and also image data to Panel in Low Power
Mode. So these flags are specific to MIPI-DSI controller of Exynos.
The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
This flag is set only when command msg transmission is requested by
Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
and
Re: [PATCH v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Thomas,
Am 29.07.2014 07:28, schrieb Thomas Abraham:
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 89ac90f..34bb31c 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -19,6 +19,12 @@
chosen {
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = buck2_reg;
+ };
+ };
+
pinctrl@1140 {
/*
* Disabled pullups since external part has its own pullups and
I've been instructed to dismantle this .dtsi file, so please place this
into exynos5250-snow.dts. It's probably wrong here anyway, since Spring
doesn't use the max77686 but an s5m6787 PMIC.
How do I find out which -supply to specify here for Spring?
Also, wouldn't it make sense to assign a cpu0 label in exynos.dtsi
to override it via cpu0 { ... };?
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
On 29.07.2014 14:00, Thomas Abraham wrote:
[snip]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 492e1ef..876247a 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -63,6 +63,29 @@
compatible = arm,cortex-a15;
reg = 0;
clock-frequency = 17;
+
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu;
+ clock-latency = 20;
Where does this latency value comes from? How did you calculate it?
For example, on Exynos4210, for all operating points added by your
patches, the highest PLL locking latency will be 60uS, because the
highest PDIV value would be 6 and PLL lock time is PDIV*240 ticks of 24
MHz reference clock.
Since the CPU clock is a composite clock with dividers and muxes, the
latency includes the settling time for these clock blocks as well. I
have not made any measurements of the clock transition latency.
It might be more reasonable to find out correct latency values instead
of specifying a rather random number.
+
+ operating-points =
+ 170 130
+ 160 125
[snip]
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6052aa9..084e587 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -24,6 +24,12 @@
bootargs = console=ttySAC2,115200 init=/linuxrc;
};
+ cpus {
Is there no regulator for cpu0?
This was a mistake. I did not intend to add regulator for cpu4 as well
but somehow I missed it. I will remove it in the next version.
cpu1: cpu@1 {
@@ -69,6 +87,7 @@
reg = 0x1;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 20;
Do you need to specify this property for every CPU or rather just for
those which have operating points specified?
The big.little cpufreq driver expects each CPU to have the clock
latency specified.
OK, apparently this is the case, even though it seems a bit
unreasonable, as they all share the same clock.
Best regards,
Tomasz
--
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 v8 6/6] clk: samsung: remove unused clock aliases and update clock flags
On 29.07.2014 14:04, Thomas Abraham wrote:
Hi Tomasz,
On Tue, Jul 29, 2014 at 4:14 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Thomas,
You can find few comments inline.
On 29.07.2014 07:28, Thomas Abraham wrote:
[snip]
@@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
^^^
Keep in mind that following clocks are common for Exynos4210 and
Exynos4x12. Have you tested this series on a board based on Exynos4212
or 4412 to verify that it does not break the legacy driver? (I would
test it myself, but I am on holidays at the moment.)
Thanks for taking time to have a look at this series. I have tested
this series with the old cpufreq driver for Exynos4412 on an
Origen4412 board and it works fine. These divider clocks are not
directly used or referenced by the legacy cpufreq driver. So I marked
them as read-only here.
OK.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Second batch of cleanups for cros_ec
Hi Javier, Am 28.07.2014 14:19, schrieb Javier Martinez Canillas: The patches in this series are authored by different people (all on cc) and consist of the following: Andrew Bresticker (3): mfd: cros_ec: stop calling -cmd_xfer() directly mfd: cros_ec: move locking into cros_ec_cmd_xfer mfd: cros_ec: wait for completion of commands that return IN_PROGRESS Derek Basehore (1): i2c: i2c-cros-ec-tunnel: Set retries to 3 Doug Anderson (1): mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC Todd Broch (2): mfd: cros_ec: Instantiate sub-devices from device tree Input: cros_ec_keyb: Optimize ghosting algorithm. When you submit other people's patches, I believe you still need to sign them off as submitter. In particular when you rebased them. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014년 07월 29일 20:59, Andreas Färber wrote: Am 29.07.2014 10:05, schrieb Sjoerd Simons: On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: On 2014년 07월 28일 23:45, Sjoerd Simons wrote: On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: On 2014년 07월 28일 17:30, Sjoerd Simons wrote: I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? The background for this is that I'm building a distribution-style multiplatform kernel, that is to say a kernel which can boot on a big set of different ARM boards. As such, the intention is to keep the core zImage as small as possible and essentially build things as far as possible as loadable modules. So in a sense, all of the hardware is hotplugged, depending on which board the kernel is actually booted on! For that use-case, exynosdrm needs to be able to build as a module (which it already can!) and it needs the required meta-data for userspace to know when it should be loaded. The latter is what my patch adds. It seems that you want that module data of sub drivers are added by depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some hot-plug system should use modules.xxxmap file to find the proper driver to load. Yes. I would like the module to export its module alias information for the subdrivers such that depmod can add it to its databases and the normal module autoloading mechanisms work as intended. Note that in my case, some hot-plug system is really just udev, not something special.. +1 here. While I haven't tested this on my Exynos devices yet since I'm still working on -next kernels there, here's an example of such a 3.16 config: http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default Of the platforms enabled, all drivers are configured as modules where possible, to keep kernel size small, and dracut (or kiwi) is used to generate an initrd that makes available the modules. So it would certainly be good to have the DRM auto-load somehow, without the user having to manually touch config files. In particular when I think of the Chromebooks, where Wifi needs configuration on first boot and no serial console is accessible. Got it. will merge them. However, I'm not sure that Exynos drm should have hot-plug feature such as PCI base devices: all devices covered by Exynos drm framework cannot attached and detached to and from machine. Thanks, Inki Dae Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] mfd: cros_ec: Instantiate sub-devices from device tree
Hi Javier, Am 28.07.2014 14:19, schrieb Javier Martinez Canillas: From: Todd Broch tbr...@chromium.org If the EC device tree node has sub-nodes, try to instantiate them as MFD sub-devices. We can configure the EC features provided by the board. Signed-off-by: Todd Broch tbr...@chromium.org This is provoking the blunt question: What sub-devices is it good for? I.e., do you have a matching DT patchset that adds such devices? In particular I'm wondering whether that would help with the tps65090 on Spring? It's a power-regulator sub-node of cros-ec in 3.8. Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Andreas,
On Tue, Jul 29, 2014 at 5:38 PM, Andreas Färber afaer...@suse.de wrote:
Hi Thomas,
Am 29.07.2014 07:28, schrieb Thomas Abraham:
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 89ac90f..34bb31c 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -19,6 +19,12 @@
chosen {
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = buck2_reg;
+ };
+ };
+
pinctrl@1140 {
/*
* Disabled pullups since external part has its own pullups and
I've been instructed to dismantle this .dtsi file, so please place this
into exynos5250-snow.dts. It's probably wrong here anyway, since Spring
doesn't use the max77686 but an s5m6787 PMIC.
Ok, I will move this to exynos5250-snow.dts.
How do I find out which -supply to specify here for Spring?
This information can be found in the Spring board schematic.
Also, wouldn't it make sense to assign a cpu0 label in exynos.dtsi
to override it via cpu0 { ... };?
Sorry, I did not understand the question.
Thanks,
Thomas.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Thomas,
Am 29.07.2014 14:35, schrieb Thomas Abraham:
On Tue, Jul 29, 2014 at 5:38 PM, Andreas Färber afaer...@suse.de wrote:
Am 29.07.2014 07:28, schrieb Thomas Abraham:
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 89ac90f..34bb31c 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -19,6 +19,12 @@
chosen {
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = buck2_reg;
+ };
+ };
+
pinctrl@1140 {
/*
* Disabled pullups since external part has its own pullups
and
I've been instructed to dismantle this .dtsi file, so please place this
into exynos5250-snow.dts. It's probably wrong here anyway, since Spring
doesn't use the max77686 but an s5m6787 PMIC.
Ok, I will move this to exynos5250-snow.dts.
How do I find out which -supply to specify here for Spring?
This information can be found in the Spring board schematic.
Are those available publicly somewhere? I guess not...
Also, wouldn't it make sense to assign a cpu0 label in exynos.dtsi
to override it via cpu0 { ... };?
Sorry, I did not understand the question.
Instead of adding
cpus { cpu@0 { ... }; };
to the board's / node, I am suggesting you do in the SoC's .dtsi:
- cpu@0 {
+ cpu0: cpu@0 {
and then in the board's file after / { ... }; add the following:
cpu0 {
cpu0-supply = buck2_reg;
};
This is the new preferred way to override or extend inherited nodes, I
am told. (cpu0 should be inserted in alphabetical order then.)
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Doug,
Am 25.07.2014 18:02, schrieb Doug Anderson:
On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote:
+/*
+ * On Snow we've got SIP WiFi and so can keep drive strengths low to
+ * reduce EMI.
+ */
+mmc_3 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
This actually looks like a bug on snow. I don't think these pinctrl
statements are taking effect and I think they belong at the mmc level,
not the slot level. That's not a new bug introduced by you, though.
Mind fixing it? You've already got it right for Spring mmc_1.
I was taught never to mix code movements with functional changes, as it
hides them even if mentioned in the commit message. Would you like me to
fix it pre- or post-move? Post-move would be easiest for me. ;)
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property
Hi Andreas,
On Tue, Jul 29, 2014 at 6:12 PM, Andreas Färber afaer...@suse.de wrote:
Hi Thomas,
Am 29.07.2014 14:35, schrieb Thomas Abraham:
On Tue, Jul 29, 2014 at 5:38 PM, Andreas Färber afaer...@suse.de wrote:
Am 29.07.2014 07:28, schrieb Thomas Abraham:
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 89ac90f..34bb31c 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -19,6 +19,12 @@
chosen {
};
+ cpus {
+ cpu@0 {
+ cpu0-supply = buck2_reg;
+ };
+ };
+
pinctrl@1140 {
/*
* Disabled pullups since external part has its own pullups
and
I've been instructed to dismantle this .dtsi file, so please place this
into exynos5250-snow.dts. It's probably wrong here anyway, since Spring
doesn't use the max77686 but an s5m6787 PMIC.
Ok, I will move this to exynos5250-snow.dts.
How do I find out which -supply to specify here for Spring?
This information can be found in the Spring board schematic.
Are those available publicly somewhere? I guess not...
I am not sure if it is available publicly. Doug (Cc'ed on this email)
might have it.
Also, wouldn't it make sense to assign a cpu0 label in exynos.dtsi
to override it via cpu0 { ... };?
Sorry, I did not understand the question.
Instead of adding
cpus { cpu@0 { ... }; };
to the board's / node, I am suggesting you do in the SoC's .dtsi:
- cpu@0 {
+ cpu0: cpu@0 {
and then in the board's file after / { ... }; add the following:
cpu0 {
cpu0-supply = buck2_reg;
};
This is the new preferred way to override or extend inherited nodes, I
am told. (cpu0 should be inserted in alphabetical order then.)
Okay, thanks for the clarification. I will update as per the preferred way.
Thanks,
Thomas.
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Second batch of cleanups for cros_ec
Hi Andreas, On 07/29/2014 02:27 PM, Andreas Färber wrote: Hi Javier, Am 28.07.2014 14:19, schrieb Javier Martinez Canillas: The patches in this series are authored by different people (all on cc) and consist of the following: Andrew Bresticker (3): mfd: cros_ec: stop calling -cmd_xfer() directly mfd: cros_ec: move locking into cros_ec_cmd_xfer mfd: cros_ec: wait for completion of commands that return IN_PROGRESS Derek Basehore (1): i2c: i2c-cros-ec-tunnel: Set retries to 3 Doug Anderson (1): mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC Todd Broch (2): mfd: cros_ec: Instantiate sub-devices from device tree Input: cros_ec_keyb: Optimize ghosting algorithm. When you submit other people's patches, I believe you still need to sign them off as submitter. In particular when you rebased them. You are right. I thought that given that I only rebased the patches and removed changes for files that are not yet in mainline I shouldn't add my s-o-b. But looking at the Developer's Certificate of Origin 1.1 rule (b) it seems that I should had added my s-o-b as well. Regards, Andreas Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] thermal: exynos: various cleanups
On Mon, Jul 28, 2014 at 08:30:53PM +0530, amit daniel kachhap wrote: Hi Eduardo, Hello Amit, Please reject this entire series as this is not re-based recently. Actually two point trimming which this series seeks to remove is used by exynos3250 and is in Rui's tree (https://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=nextid=1fe56dc16a3dab400206443f70ae158c8f595c42). Yeah, that was my original concern when I first looked this series. However, as I saw a couple of your acks I thought you would be in sync with Bartlomiej. I agree with Bartlomiej that we need to keep the kernel code in very good shape, but if we are removing features for the sake of reducing LOCs and we end up dropping support to known chips, I definitely won't agree. Can you guys please reach a common agreement on these cleanups? Bartlomiej, best thing to do is to sync your work on top of Rui's tree. For now I am dropping this series from my -next branch. :-( Thanks, Amit D On Mon, Jul 28, 2014 at 8:07 PM, Eduardo Valentin edubez...@gmail.com wrote: On Tue, Jun 17, 2014 at 07:27:16PM +0200, Bartlomiej Zolnierkiewicz wrote: Hi, This patch series contains various cleanups for EXYNOS thermal driver. Overall it decreases driver's LOC by 12%. It is based on next-20140617 kernel. It should not cause any functionality changes. Changes since v1: - synced patches against next-20140617 - merged patch thermal: exynos: remove unused defines into thermal: exynos: remove unused struct exynos_tmu_registers entries one (per request from Eduardo) - improved patch descriptions for patches #1-5 - fixed documentation for pdata-gain and pdata-reference_voltage - added Reviewed-by from Amit to patches #6, #7 and #10 - added missing Acked-by from Kyungmin Park Pulled the series. Thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (9): thermal: exynos: remove unused struct exynos_tmu_registers entries thermal: exynos: remove dead code for HW_MODE calibration thermal: exynos: remove dead code for TYPE_TWO_POINT_TRIMMING calibration thermal: exynos: remove redundant pdata checks from exynos_tmu_initialize() thermal: exynos: remove redundant threshold_code checks from exynos_tmu_initialize() thermal: exynos: simplify temp_to_code() and code_to_temp() thermal: exynos: cache non_hw_trigger_levels in pdata thermal: exynos: remove redundant pdata checks from exynos_tmu_control() thermal: exynos: remove identical values from exynos*_tmu_registers structures drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 181 drivers/thermal/samsung/exynos_tmu.h| 90 +--- drivers/thermal/samsung/exynos_tmu_data.c | 64 + drivers/thermal/samsung/exynos_tmu_data.h | 33 + 5 files changed, 41 insertions(+), 328 deletions(-) -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm 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-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Hi Javier and Doug,
Am 25.07.2014 19:02, schrieb Javier Martinez Canillas:
On Fri, Jul 25, 2014 at 6:43 PM, Doug Anderson diand...@chromium.org wrote:
On Fri, Jul 25, 2014 at 9:35 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Andreas,
On Fri, Jul 18, 2014 at 7:20 PM, Andreas Färber afaer...@suse.de wrote:
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ };
+
Is there a reason for an empty chosen node? Same for the Spring DTS.
I know that the bootloader (U-Boot) fills this in. I'd have to double
check how the bootloader handles the node not being there to begin
with.
Yes, U-Boot fills this but if the node does not exist in the FDT, it
creates one. Take a look at fdt_chosen() in common/fdt_support.c [0].
So I think it's better to just remove it since is empty.
Hm, in different context it was stated that device trees shouldn't rely
on bootloader behavior (for a /memory node on Zynq we ended up
specifying the size cell with the real value despite U-Boot overriding
it to a lesser value).
Can we instead settle on filling this node with defaults? :)
bootargs = console=tty1; would be my choice for Spring. Would that be
applicable for Snow as well?
Not sure how to specify that via linux,stdout-path property.
I believe this would be a follow-up patch either way.
Since there's at least two series out there trying to fiddle with
-cros-common.dtsi, including one that drops the slot sub-node of the MMC
and one that adds CPU power supply, it would be nice if we can get the
-cros-common parts sorted out and applied. Can you ack/review 1-2?
Should I squash them in a v3?
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] Input: cros_ec_keyb: Optimize ghosting algorithm.
Am 28.07.2014 14:19, schrieb Javier Martinez Canillas: From: Todd Broch tbr...@chromium.org Previous algorithm was a bit conservative and complicating with respect to identifying key ghosting. This CL uses the bitops hamming weight function (hweight8) to count the number of matching rows for colM colN. If that number is 1 ghosting is present. Additionally it removes NULL keys and our one virtual keypress KEY_BATTERY from consideration as these inputs are never physical keypresses. Signed-off-by: Todd Broch tbr...@chromium.org Reviewed-by: Vincent Palatin vpala...@chromium.org Reviewed-by: Luigi Semenzato semenz...@chromium.org This seems to fix my Ctrl+O problems on Spring reported a while ago, Tested-by: Andreas Färber afaer...@suse.de Thanks, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 10/14] drm/panel: add S6E3FA0 driver
Hi Thierry,
Sorry for late reply.
I implemented common DSI helper functions and tested in s6e3fa0 panel
(I should test with other panels).
The helper function prototypes are like below:
int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
u16 size);
int mipi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dcs_set_display_off(struct mipi_dsi_device *dsi);
int mipi_dcs_set_display_on(struct mipi_dsi_device *dsi);
int mipi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
enum mipi_dcs_tear_mode {
MIPI_DCS_TEAR_MODE_VBLANK,
MIPI_DCS_TEAR_MODE_HVBLANK,
};
int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dcs_tear_mode mode);
Last time you recommended to implement mipi_dcs_set_tear_on() unrelated
with mipi_dsi_dcs_write().
As you know, the only difference between mipi_dcs_xxx() except
mipi_dcs_set_tear_on() is data(dcs command).
So I think it's better to use mipi_dsi_dcs_write() instead.
Do you agree?
And one more thing.
From my point of view there is no initialization sequence in simple
panel driver, so this and s6e8aa0 panel couldn't use that interface.
The s6e3fa0 and s6e8aa0 are very similar so I think it is possible to
combine together like simple panel driver.
I want to ask you for advice on this.
Thank you.
Best regards YJ
On 07/22/2014 12:56 PM, YoungJun Cho wrote:
Hi Thierry,
Now I understand what you mean.
I'll implement common DSI helper functions.
Thank you.
Best regards YJ
On 07/21/2014 06:35 PM, Thierry Reding wrote:
On Fri, Jul 18, 2014 at 10:49:35AM +0900, YoungJun Cho wrote:
Hi Thierry,
Thank you a lot for kind comments.
On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
[...]
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
[...]
+static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0
*ctx,
+unsigned int size)
+{
+struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx-dev);
+const struct mipi_dsi_host_ops *ops = dsi-host-ops;
+
+if (ops ops-transfer) {
+unsigned char buf[] = {size, 0};
+struct mipi_dsi_msg msg = {
+.channel = dsi-channel,
+.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
+.tx_len = sizeof(buf),
+.tx_buf = buf
+};
+
+ops-transfer(dsi-host, msg);
+}
+}
The Set Maximum Return Packet Size command is a standard command, so
please turn that into a generic function exposed by the DSI core.
For this and below standard DCS commands, you want to use generic
functions,
but I have no idea for that.
Could you explain more detail?
The goal should be to make these standard DCS commands available to all
DSI peripherals, so the implementation should look something like this:
static int mipi_dsi_set_maximum_return_packet_size(struct
mipi_dsi_device *dsi,
u16 size)
{
struct mipi_dsi_msg msg;
if (!dsi-ops || !dsi-ops-transfer)
return -ENOSYS;
memset(msg, 0, sizeof(msg));
msg.channel = dsi-channel;
msg.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE;
msg.tx_len = sizeof(size);
msg.tx_buf = size;
return dsi-ops-transfer(dsi-host, msg);
}
The above is somewhat special, since it isn't DCS. For DCS I'd suggest a
common prefix, like so:
enum mipi_dcs_tear_mode {
MIPI_DCS_TEAR_VBLANK,
MIPI_DCS_TEAR_BLANK,
};
static int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dcs_tear_mode mode)
{
u8 data[2] = { MIPI_DSI_DCS_SET_TEAR_ON, mode };
struct mipi_dsi_msg msg;
if (!dsi-ops || !dsi-ops-transfer)
return -ENOSYS;
memset(msg, 0, sizeof(msg));
msg.channel = dsi-channel;
msg.type = MIPI_DSI_DCS_SHORT_WRITE_PARAM;
msg.tx_len = sizeof(data);
msg.tx_buf = data;
return dsi-ops-transfer(dsi-host, msg);
}
Thierry
___
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: [PATCH] media: s5p_mfc: remove unnecessary calling to function video_devdata()
On 23/07/14 06:06, Zhaowei Yuan wrote: Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Applied to my tree, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 07/29/2014 02:08 PM, Inki Dae wrote:
On 2014년 07월 29일 20:39, Andrzej Hajda wrote:
On 07/29/2014 05:42 AM, Inki Dae wrote:
On 2014년 07월 29일 00:50, Andrzej Hajda wrote:
On 07/28/2014 04:00 AM, Inki Dae wrote:
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Changelog v2: Enable High Speed clock only in case of stand by request.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
*dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi-lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi-mode_flags MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct
exynos_dsi *dsi)
writel(reg, dsi-reg_base + DSIM_PHYTIMING2_REG);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi-reg_base + DSIM_CLKCTRL_REG);
+
+ reg = ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi-reg_base + DSIM_CLKCTRL_REG);
+}
+
I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
it works with and without the bit set.
If you can test thmorstat board, you will face with that its panel is
not worked.
So it means this panel requires proper driving of this bit, but it does
not prove it is
LPM related.
So I start to suspect this bit is not just for simply enable/disable HS
clock as function name suggests, do you know what is its
exact meaning? The specs are quite succinct on it.
HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
This sounds very strange. DSI specs and D-PHY specs says clearly
that LPM transmissions are unrelated to HS clock [1][2]. Even timing
diagrams
in Exynos specs shows no dependency of LPM transmissions on HS clock.
And the
description of TxRequestHsClk bit says HS clock request for HS transfer
at clock lane (Turn
on HS clock).
There are three System power states of D-PHY, Low-Power mode, High-Speed
mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
Lane. Therefore, to use HS mode, HS clock should be enabled. On the
other hand, LP mode needs only 10MHz (max).
So do you really think LP mode will be worked well with HS clock
enabled? The purpose of LP mode is to reduce power consumption while
transmitting data. Can you reduce the power consumption in LP mode with
HS clock enabled?
As MIPI specs says All DSI transmitters and receivers shall support
continuous clock
behavior on the Clock Lane, and optionally may support non-continuous
clock behavior
and For continuous clock behavior, the Clock Lane remains in high-speed
mode generating
active clock signals between HS data packet transmissions.
This means that HS clock should be on even in LP mode, unless panel
supports non-continuous clock
behavior. For signaling non-continuous clock capability there is
MIPI_DSI_CLOCK_NON_CONTINUOUS flag already.
Regards
Andrzej
Thanks,
Inki Dae
Maybe different flag should be used to describe your panel requirements
regarding this bit.
It would be good to see the real initialization sequence in form of
pseudo-code or better in the driver.
[1]: MIPI DSI: Note that in Low Power signaling mode, LP clock is
functionally embedded in the data signals. When LP
data transmission ends, the clock effectively stops and subsequent LP
clocks are not available to the
peripheral. The peripheral shall not require additional bits, bytes, or
packets from the host processor in
order to complete processing or pipeline movement of received data in LP
mode transmissions. There are a
variety of ways to meet this requirement. For example, the peripheral
may generate its own clock or it may
require the host processor to keep the HS serial clock running.
[2]: MIPI D-PHY: The data is self-clocked by the applied bit encoding
and does not rely on the Clock Lane.
Regards
Andrzej
On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
in DSIM_ESCMODE register
which seems to be related to flags you have
Re: [PATCH] media: s5p_mfc: Check the right pointer after allocation
On 23/07/14 06:05, Zhaowei Yuan wrote: It should be bank2_virt to be checked after dma allocation instead of dev-fw_virt_addr. This patch is not applicable to the media master branch [1]. Additionally, AFAICS dma_alloc_coherent return value should be tested for NULL, rather than for ERR_PTR() value. It seems you have some incorrect changes in your tree, which this patch depends on. [1] http://git.linuxtv.org/cgit.cgi/media_tree.git -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] mfd: cros_ec: Instantiate sub-devices from device tree
Hello Andreas, On 07/29/2014 02:34 PM, Andreas Färber wrote: Hi Javier, Am 28.07.2014 14:19, schrieb Javier Martinez Canillas: From: Todd Broch tbr...@chromium.org If the EC device tree node has sub-nodes, try to instantiate them as MFD sub-devices. We can configure the EC features provided by the board. Signed-off-by: Todd Broch tbr...@chromium.org This is provoking the blunt question: What sub-devices is it good for? I.e., do you have a matching DT patchset that adds such devices? For Peach Pit and Pi, the matching DTS changes is [0]. But answering your question it is to instantiate the subdevices that can be child nodes of either cros-ec-spi or cros-ec-i2c. So for the devices that are directly connected to the EC Cortex-M through i2c. In particular I'm wondering whether that would help with the tps65090 on Spring? It's a power-regulator sub-node of cros-ec in 3.8. Spring is a little more complicated since the EC in Spring don't have the full EC_CMD_I2C_PASSTHRU. So the downstream Chrome OS 3.8 kernel has a forked tps65090 driver (drivers/regulator/cros_ec-tps65090.c) that talks directly with the cros_ec MFD driver, you can get more info from [1] in the About Spring section. Thanks, Andreas Best regards, Javier [0]: https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/commit/?h=for-nextid=8060098bbb564d27a287057a93d4fe3bfd266290 [1]: http://code.google.com/p/chromium/issues/detail?id=391797 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
On Tue, Jul 29, 2014 at 11:17:10AM +0900, Chanwoo Choi wrote:
This patch add TMU (Thermal Management Unit) dt node to monitor the high
temperature for Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Eduardo Valentin edubez...@gmail.com
---
This patch has a dependency on following patch [1] which supporting the TMU
of Exynos3250:
[1]
https://git.kernel.org/cgit/linux/kernel/git/rzhang/linux.git/commit/?h=nextid=1fe56dc16a3dab400206443f70ae158c8f595c42
Changes from v1:
- Remove duplicate 'interrupt-parent' property.
arch/arm/boot/dts/exynos3250.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 77a06df..41a260a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -168,6 +168,15 @@
status = disabled;
};
+ tmu: tmu@100C {
+ compatible = samsung,exynos3250-tmu;
+ reg = 0x100C 0x100;
+ interrupts = 0 216 0;
+ clocks = cmu CLK_TMU_APBIF;
+ clock-names = tmu_apbif;
+ status = disabled;
+ };
+
gic: interrupt-controller@10481000 {
compatible = arm,cortex-a15-gic;
#interrupt-cells = 3;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] thermal: samsung: Add TMU support for Exynos3250 SoC
On Tue, Jul 22, 2014 at 11:41:56AM +0530, amit daniel kachhap wrote:
On Mon, Jul 21, 2014 at 11:34 AM, Zhang Rui rui.zh...@intel.com wrote:
On Fri, 2014-07-18 at 09:00 +0900, Chanwoo Choi wrote:
This patch adds the registers, bit fields and compatible strings
required to support for the 1 TMU channels on Exynos3250.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
[Add MUX address setting bits by Jonghwa Lee]
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Amit Daniel Kachhapamit.dan...@samsung.com
Eduardo and Amit,
do you have any comments on this?
The changes looks fine to me. I already reviewed these patches earlier.
Bartlomiej, can you please rebase your work on top of this one?
thanks,
Amit
thanks,
rui
---
.../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
drivers/thermal/samsung/exynos_tmu.c | 7 +-
drivers/thermal/samsung/exynos_tmu.h | 3 +-
drivers/thermal/samsung/exynos_tmu_data.c | 89
++
drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
5 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index c949092..ae738f5 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -3,6 +3,7 @@
** Required properties:
- compatible : One of the following:
+samsung,exynos3250-tmu
samsung,exynos4412-tmu
samsung,exynos4210-tmu
samsung,exynos5250-tmu
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index d7ca9f4..a2a08ea 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -505,6 +505,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static const struct of_device_id exynos_tmu_match[] = {
{
+ .compatible = samsung,exynos3250-tmu,
+ .data = (void *)EXYNOS3250_TMU_DRV_DATA,
+ },
+ {
.compatible = samsung,exynos4210-tmu,
.data = (void *)EXYNOS4210_TMU_DRV_DATA,
},
@@ -677,7 +681,8 @@ static int exynos_tmu_probe(struct platform_device
*pdev)
goto err_clk_sec;
}
- if (pdata-type == SOC_ARCH_EXYNOS4210 ||
+ if (pdata-type == SOC_ARCH_EXYNOS3250 ||
+ pdata-type == SOC_ARCH_EXYNOS4210 ||
pdata-type == SOC_ARCH_EXYNOS4412 ||
pdata-type == SOC_ARCH_EXYNOS5250 ||
pdata-type == SOC_ARCH_EXYNOS5260 ||
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index edd08cf..1b4a644 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -40,7 +40,8 @@ enum calibration_mode {
};
enum soc_type {
- SOC_ARCH_EXYNOS4210 = 1,
+ SOC_ARCH_EXYNOS3250 = 1,
+ SOC_ARCH_EXYNOS4210,
SOC_ARCH_EXYNOS4412,
SOC_ARCH_EXYNOS5250,
SOC_ARCH_EXYNOS5260,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index c1d81dc..aa8e0de 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
exynos4210_default_tmu_data = {
};
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+static const struct exynos_tmu_registers exynos3250_tmu_registers = {
+ .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
+ .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
+ .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
+ .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
+ .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
+ .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
+ .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
+ .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
+ .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
+ .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
+ .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
+ .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
+ .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
+ .tmu_status = EXYNOS_TMU_REG_STATUS,
+ .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
+ .threshold_th0 = EXYNOS_THD_TEMP_RISE,
+ .threshold_th1 = EXYNOS_THD_TEMP_FALL,
+ .tmu_inten = EXYNOS_TMU_REG_INTEN,
+ .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
+ .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
+ .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
+ .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
+ .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
+
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Hello Andreas, On Tue, Jul 29, 2014 at 3:00 PM, Andreas Färber afaer...@suse.de wrote: Hi Javier and Doug, Hm, in different context it was stated that device trees shouldn't rely on bootloader behavior (for a /memory node on Zynq we ended up specifying the size cell with the real value despite U-Boot overriding it to a lesser value). Well is not strictly the same, the memory node is a hardware description while the chosen node is one of those exceptional nodes that don't represent a real device. Also the usage for the memory node is marked as required in ePAR while the later is marked as optional. Can we instead settle on filling this node with defaults? :) bootargs = console=tty1; would be my choice for Spring. Would that be applicable for Snow as well? Not sure how to specify that via linux,stdout-path property. I believe this would be a follow-up patch either way. Since there's at least two series out there trying to fiddle with -cros-common.dtsi, including one that drops the slot sub-node of the MMC and one that adds CPU power supply, it would be nice if we can get the -cros-common parts sorted out and applied. Can you ack/review 1-2? Should I squash them in a v3? A sensible default makes sense to me and yes it should be a follow-up patch anyways. Thanks, Andreas -- Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Andreas,
On Tue, Jul 29, 2014 at 5:45 AM, Andreas Färber afaer...@suse.de wrote:
Doug,
Am 25.07.2014 18:02, schrieb Doug Anderson:
On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote:
+/*
+ * On Snow we've got SIP WiFi and so can keep drive strengths low to
+ * reduce EMI.
+ */
+mmc_3 {
+ status = okay;
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3;
+ samsung,dw-mshc-ddr-timing = 1 2;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 4;
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
This actually looks like a bug on snow. I don't think these pinctrl
statements are taking effect and I think they belong at the mmc level,
not the slot level. That's not a new bug introduced by you, though.
Mind fixing it? You've already got it right for Spring mmc_1.
I was taught never to mix code movements with functional changes, as it
hides them even if mentioned in the commit message. Would you like me to
fix it pre- or post-move? Post-move would be easiest for me. ;)
Agreed. Sorry for implying that it belonged as part of this patch.
I'd be happy if it was somewhere in the series, ideally before you
introduce the Spring device tree so diffs are cleaner for it. I don't
care if it's pre-move or post-move.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: exynos5250: Fold common ChromeOS parts into Snow
Andreas,
On Tue, Jul 29, 2014 at 6:00 AM, Andreas Färber afaer...@suse.de wrote:
Hi Javier and Doug,
Am 25.07.2014 19:02, schrieb Javier Martinez Canillas:
On Fri, Jul 25, 2014 at 6:43 PM, Doug Anderson diand...@chromium.org wrote:
On Fri, Jul 25, 2014 at 9:35 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Andreas,
On Fri, Jul 18, 2014 at 7:20 PM, Andreas Färber afaer...@suse.de wrote:
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ };
+
Is there a reason for an empty chosen node? Same for the Spring DTS.
I know that the bootloader (U-Boot) fills this in. I'd have to double
check how the bootloader handles the node not being there to begin
with.
Yes, U-Boot fills this but if the node does not exist in the FDT, it
creates one. Take a look at fdt_chosen() in common/fdt_support.c [0].
So I think it's better to just remove it since is empty.
Hm, in different context it was stated that device trees shouldn't rely
on bootloader behavior (for a /memory node on Zynq we ended up
specifying the size cell with the real value despite U-Boot overriding
it to a lesser value).
Can we instead settle on filling this node with defaults? :)
bootargs = console=tty1; would be my choice for Spring. Would that be
applicable for Snow as well?
Personally I think that there's not a lot of use for including
bootargs. Every single person will need different bootargs since
everyone will have a different boot source (eMMC partitioin 0, eMMC
partition3, SD card, USB, etc). You have to rely on the bootloader
for _something_.
Not sure how to specify that via linux,stdout-path property.
I believe this would be a follow-up patch either way.
Right
Since there's at least two series out there trying to fiddle with
-cros-common.dtsi, including one that drops the slot sub-node of the MMC
and one that adds CPU power supply, it would be nice if we can get the
-cros-common parts sorted out and applied. Can you ack/review 1-2?
Should I squash them in a v3?
Yeah, it will be a fight to see who gets landed first... :-P
I was thinking you were going to spin the patches and I'd do another
batch of review, but I think I can mark the first two as Reveiwed-by
if it's helpful to you. Let me do one more double-check when I get to
my desk.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: dts: exynos5250: cypress,cyapa trackpad is Snow only
Andreas, On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote: Move it from exynos5250-cros-common.dtsi to exynos5250-snow.dts. Spring does not need it, it uses an Atmel maXTouch instead. Signed-off-by: Andreas Färber afaer...@suse.de --- v2: New (Doug Anderson) arch/arm/boot/dts/exynos5250-cros-common.dtsi | 8 arch/arm/boot/dts/exynos5250-snow.dts | 10 ++ 2 files changed, 10 insertions(+), 8 deletions(-) Reviewed-by: Doug Anderson diand...@chromium.org Kukjin could apply this now if he wanted to avoid future conflicts. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: dts: exynos5250: max77686 is Snow only
Andreas, On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färber afaer...@suse.de wrote: Move it from exynos5250-cros-common.dtsi to exynos5250-snow.dts. Spring does not need it, it uses an s5m8767 instead. Signed-off-by: Andreas Färber afaer...@suse.de --- v2: New (Doug Anderson) arch/arm/boot/dts/exynos5250-cros-common.dtsi | 151 - arch/arm/boot/dts/exynos5250-snow.dts | 155 ++ 2 files changed, 155 insertions(+), 151 deletions(-) Personally I would have squashed patches 1-3, but I don't have a problem with it being broken up and it does mean that the mondo patch is smaller, so... Reviewed-by: Doug Anderson diand...@chromium.org Kukjin could apply this now if he wanted to avoid future conflicts. -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
[RFC 0/5] Get voltage from parent if not available on child
Hello,
The motivation for this series is that some regulators are
really just switches that provide as output voltage what is
supplied to them as input voltage. These components can be
only switched on and off so the drivers usually implements
a subset of the possible regulator operations. That is only
.enable, .disable and .is_enabled but no .{get,list}_voltage
But there is code that assume all regulators can provide
their output voltage so if one of these load switches are
used as an input supply a call to regulator_get_voltage() or
regulator_list_voltage() will fail.
As an example in [0] mmc_regulator_get_supply() is used to
obtain the vmmc supply but on Peach Pit and Pi boards this
is tps65090 fet4 which is a load switch so the call to
mmc_regulator_get_ocrmask() fails since it tries to obtain
the regulator voltage count and list.
mmc_regulator_set_ocr() function fails as well since it calls
regulator_get_voltage() which the driver does not implement.
Since this seems to be a general issue we can pass through
and query the parent supply voltage when a child regulator
does not implement the handlers to obtain its output voltage.
The series have been tested on a Exynos 5420 Peach Pit board
and is composed of the following patches:
Javier Martinez Canillas (5):
regulator: core: Get voltage from parent if not available
regulator: core: Allow to get voltage count and list from parent
regulator: core: Only apply constraints if available on list voltage
regulator: tps65090: Set voltage for fixed regulators
ARM: dts: Improve Peach Pit and Pi power scheme model
arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 +--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 +--
drivers/regulator/core.c | 31 ---
drivers/regulator/tps65090-regulator.c | 34 ++
4 files changed, 56 insertions(+), 33 deletions(-)
Patch 1 adds support to get the voltage of the parent supply
while patch 2 does the same for selector count and selector.
Patch 3 only applies the constraints when querying a selector
if there were constraints defined for this regulator. Otherwise
the constraints of the parent supply will be applied when
calling regulator_list_voltage() for the parent supply. Patch
4 adds information about the voltage output for the fixed
regulators found on the tps65090 since these are parent supply
of the fets load switches. Finally patch 5 models the real
relation between regulators in the Peach Pit and Pi boards
instead of the simplistic model that is implemented now.
This last patch should not be merged with the series but since
is a RFC I included so it can be tested on Peach boards and
to provide the complete picture.
Best regards,
Javier
[0]: https://patchwork.kernel.org/patch/4401231/
[1]: http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L1253
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/5] ARM: dts: Improve Peach Pit and Pi power scheme model
The DeviceTree files for the Peach Pit and Pi machines have a simplistic model of the connections between the different regulators since not all the tps65090 regulators get their input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 parent supply is indded VDC but the fet1-6 get their input supply from the DCDC1 and DCDC2 output voltage rails. This information has to be present in the DTS since fets are switches that don't provide an output voltage so when this is needed, the parent input supply voltage is queried. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index 7656a42..acc2936 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -367,12 +367,12 @@ vsys2-supply = vbat; vsys3-supply = vbat; infet1-supply = vbat; - infet2-supply = vbat; - infet3-supply = vbat; - infet4-supply = vbat; - infet5-supply = vbat; - infet6-supply = vbat; - infet7-supply = vbat; + infet2-supply = tps65090_dcdc1; + infet3-supply = tps65090_dcdc2; + infet4-supply = tps65090_dcdc2; + infet5-supply = tps65090_dcdc2; + infet6-supply = tps65090_dcdc2; + infet7-supply = tps65090_dcdc1; vsys-l1-supply = vbat; vsys-l2-supply = vbat; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index 5f3e54f..6b83b98 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -365,12 +365,12 @@ vsys2-supply = vbat; vsys3-supply = vbat; infet1-supply = vbat; - infet2-supply = vbat; - infet3-supply = vbat; - infet4-supply = vbat; - infet5-supply = vbat; - infet6-supply = vbat; - infet7-supply = vbat; + infet2-supply = tps65090_dcdc1; + infet3-supply = tps65090_dcdc2; + infet4-supply = tps65090_dcdc2; + infet5-supply = tps65090_dcdc2; + infet6-supply = tps65090_dcdc2; + infet7-supply = tps65090_dcdc1; vsys-l1-supply = vbat; vsys-l2-supply = vbat; -- 2.0.0.rc2 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/5] regulator: core: Only apply constraints if available on list voltage
If a selector can't be used on a platform due to voltage constraints,
regulator_list_voltage() returns 0. Doing this unconditionally made
sense since constraints were set in machine_constraints_voltage() at
regulator registration time.
But for load switches that don't define a voltage output, the parent
supply voltage is used so the constraints should only be applied if
they were defined for the child regulators.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index a3c3785..7472535 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2228,9 +2228,11 @@ int regulator_list_voltage(struct regulator *regulator,
unsigned selector)
}
if (ret 0) {
- if (ret rdev-constraints-min_uV)
+ if (rdev-constraints-min_uV
+ ret rdev-constraints-min_uV)
ret = 0;
- else if (ret rdev-constraints-max_uV)
+ else if (rdev-constraints-max_uV
+ret rdev-constraints-max_uV)
ret = 0;
}
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/5] regulator: tps65090: Set voltage for fixed regulators
According to the tps65090 data manual [0], the DCDC1 and DCDC2
step-down converters and the LDO's have a fixed output voltage.
Add this information to the driver since these fixed regulators
be used as input supply for load switches which don't provide
an output voltage and their parent supply voltage is used.
[0]: http://www.ti.com/lit/gpn/tps65090
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/tps65090-regulator.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2064b3f..919f5ce 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -192,12 +192,14 @@ static struct regulator_ops tps65090_fet_control_ops = {
static struct regulator_ops tps65090_ldo_ops = {
};
-#define tps65090_REG_DESC(_id, _sname, _en_reg, _en_bits, _ops)\
+#define tps65090_REG_DESC(_id, _sname, _en_reg, _en_bits, _nvolt, _volt, _ops)
\
{ \
.name = TPS65090_RAILS#_id, \
.supply_name = _sname, \
.id = TPS65090_REGULATOR_##_id, \
+ .n_voltages = _nvolt, \
.ops = _ops, \
+ .fixed_uV = _volt, \
.enable_reg = _en_reg, \
.enable_val = _en_bits, \
.enable_mask = _en_bits,\
@@ -205,39 +207,45 @@ static struct regulator_ops tps65090_ldo_ops = {
.owner = THIS_MODULE, \
}
+#define tps65090_REG_FIX(_id, _sname, en_reg, _en_bits, _volt, _ops) \
+ tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 1, _volt, _ops)
+
+#define tps65090_REG_VAR(_id, _sname, en_reg, _en_bits, _ops) \
+ tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 0, 0, _ops)
+
static struct regulator_desc tps65090_regulator_desc[] = {
- tps65090_REG_DESC(DCDC1, vsys1, 0x0C, BIT(CTRL_EN_BIT),
+ tps65090_REG_FIX(DCDC1, vsys1, 0x0C, BIT(CTRL_EN_BIT), 500,
tps65090_reg_control_ops),
- tps65090_REG_DESC(DCDC2, vsys2, 0x0D, BIT(CTRL_EN_BIT),
+ tps65090_REG_FIX(DCDC2, vsys2, 0x0D, BIT(CTRL_EN_BIT), 330,
tps65090_reg_control_ops),
- tps65090_REG_DESC(DCDC3, vsys3, 0x0E, BIT(CTRL_EN_BIT),
+ tps65090_REG_VAR(DCDC3, vsys3, 0x0E, BIT(CTRL_EN_BIT),
tps65090_reg_control_ops),
- tps65090_REG_DESC(FET1, infet1, 0x0F,
+ tps65090_REG_VAR(FET1, infet1, 0x0F,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET2, infet2, 0x10,
+ tps65090_REG_VAR(FET2, infet2, 0x10,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET3, infet3, 0x11,
+ tps65090_REG_VAR(FET3, infet3, 0x11,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET4, infet4, 0x12,
+ tps65090_REG_VAR(FET4, infet4, 0x12,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET5, infet5, 0x13,
+ tps65090_REG_VAR(FET5, infet5, 0x13,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET6, infet6, 0x14,
+ tps65090_REG_VAR(FET6, infet6, 0x14,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(FET7, infet7, 0x15,
+ tps65090_REG_VAR(FET7, infet7, 0x15,
BIT(CTRL_EN_BIT) | BIT(CTRL_PG_BIT),
tps65090_fet_control_ops),
- tps65090_REG_DESC(LDO1, vsys-l1, 0, 0,
+ tps65090_REG_FIX(LDO1, vsys-l1, 0, 0, 500,
tps65090_ldo_ops),
- tps65090_REG_DESC(LDO2, vsys-l2, 0, 0,
+ tps65090_REG_FIX(LDO2, vsys-l2, 0, 0, 330,
tps65090_ldo_ops),
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 5/5] ARM: dts: Improve Peach Pit and Pi power scheme model
On Tue, Jul 29, 2014 at 06:28:59PM +0200, Javier Martinez Canillas wrote: The DeviceTree files for the Peach Pit and Pi machines have a simplistic model of the connections between the different regulators since not all the tps65090 regulators get their input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7 parent supply is indded VDC but the fet1-6 get their input supply from the DCDC1 and DCDC2 output voltage rails. Acked-by: Mark Brown broo...@linaro.org This *should* be independent of the rest of this series. signature.asc Description: Digital signature
Re: [RFC 4/5] regulator: tps65090: Set voltage for fixed regulators
On Tue, Jul 29, 2014 at 06:28:58PM +0200, Javier Martinez Canillas wrote: +#define tps65090_REG_VAR(_id, _sname, en_reg, _en_bits, _ops) \ + tps65090_REG_DESC(_id, _sname, en_reg, _en_bits, 0, 0, _ops) I'd expect this to describe a variable regulator when in fact it seems it describes a switch with no regulation. Better name please. signature.asc Description: Digital signature
Re: [PATCHv7 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Jaehoon, On Sun, Jul 27, 2014 at 7:29 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Replaced the disable-wp into host's quirks. (Because the slot-node is removed at dt-file.) Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com --- drivers/mmc/host/dw_mmc.c | 12 +--- include/linux/mmc/dw_mmc.h |6 ++ 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 1ac227c..4a4f66f 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -997,7 +997,7 @@ static int dw_mci_get_ro(struct mmc_host *mmc) int gpio_ro = mmc_gpio_get_ro(mmc); /* Use platform get_ro function, else try on board write protect */ - if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) + if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) It doesn't seem like it would be hard to include support for the old binding (and just print a warning). Then this could land ahead of the device tree changes. Generally I think we're supposed to keep support for old device trees if possible (except in extreme cases). -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: [RFC 1/5] regulator: core: Get voltage from parent if not available
On Tue, Jul 29, 2014 at 06:28:55PM +0200, Javier Martinez Canillas wrote: Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So the drivers for Applied, thanks. The term load switch is a bit unusual - they're usually just called switches (or sometimes FETs since that tends to be the implementation). signature.asc Description: Digital signature
Re: [RFC 2/5] regulator: core: Allow to get voltage count and list from parent
On Tue, Jul 29, 2014 at 06:28:56PM +0200, Javier Martinez Canillas wrote: Load switches are modeled as regulators but they just provide the voltage of their parent input supply. So, the drivers for these switches usually neither provide a .list_voltage handler not set a .n_voltages count. But there is code in the kernel that assumes that all regulators should be able to provide this information (e.g: cpufreq and mmc subsystems). Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH -next] ASoC: samsung: Fix return value check in s3c2412_iis_dev_probe()
On Sun, Jul 20, 2014 at 11:43:07AM +0800, weiyj...@163.com wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn In case of error, the function devm_ioremap_resource() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Also remove redundant return value check of platform_get_resource(). Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
On 07/29/14 13:27, Thomas Abraham wrote:
The IRQB interrupt pin of MAX77686 PMIC is connected to GPX3[2] pin of
Exynos5250 on the Exynos5250 SMDK board. Specify this connection using
interrupts property for the max77686 pmic node.
Signed-off-by: Thomas Abrahamthomas...@samsung.com
---
arch/arm/boot/dts/exynos5250-smdk5250.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 695f5ad..cf38808 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -50,6 +50,8 @@
max77686@09 {
compatible = maxim,max77686;
reg =0x09;
+ interrupt-parent =gpx3;
+ interrupts =2 0;
voltage-regulators {
ldo1_reg: LDO1 {
Applied, thanks.
- Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: dts: Add TMU dt node and missing data for Exynos3250
On 07/29/14 11:17, Chanwoo Choi wrote: This patchset add TMU (Thermal Management Unit) dt node and missing pinctrl property of uart0/1. Also, this patchset remove duplcate 'interrupt-parent' property for code clean. Chanwoo Choi (3): ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250 ARM: dts: Remove duplicate 'interrput-parent' property for Exynos3250 ARM: dts: Add missing pinctrl for uart0/1 for Exynos3250 arch/arm/boot/dts/exynos3250.dtsi | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) Applied this whole series, thanks. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: dts: exynos5250: cypress,cyapa trackpad is Snow only
On 07/30/14 01:16, Doug Anderson wrote: Andreas, On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färberafaer...@suse.de wrote: Move it from exynos5250-cros-common.dtsi to exynos5250-snow.dts. Spring does not need it, it uses an Atmel maXTouch instead. Signed-off-by: Andreas Färberafaer...@suse.de --- v2: New (Doug Anderson) arch/arm/boot/dts/exynos5250-cros-common.dtsi | 8 arch/arm/boot/dts/exynos5250-snow.dts | 10 ++ 2 files changed, 10 insertions(+), 8 deletions(-) Reviewed-by: Doug Andersondiand...@chromium.org Kukjin could apply this now if he wanted to avoid future conflicts. OK, I read your comments on another this series and I've applied 1/4 and 2/4 as per your suggestion with your reviewed by tag ;) And I think, Andreas is going to re-spin remains for exynos5250-spring based on updated my -next? Thanks, Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] ARM: dts: exynos5250: cypress,cyapa trackpad is Snow only
Am 30.07.2014 01:06, schrieb Kukjin Kim: On 07/30/14 01:16, Doug Anderson wrote: On Fri, Jul 18, 2014 at 10:20 AM, Andreas Färberafaer...@suse.de wrote: Move it from exynos5250-cros-common.dtsi to exynos5250-snow.dts. Spring does not need it, it uses an Atmel maXTouch instead. Signed-off-by: Andreas Färberafaer...@suse.de --- v2: New (Doug Anderson) arch/arm/boot/dts/exynos5250-cros-common.dtsi | 8 arch/arm/boot/dts/exynos5250-snow.dts | 10 ++ 2 files changed, 10 insertions(+), 8 deletions(-) Reviewed-by: Doug Andersondiand...@chromium.org Kukjin could apply this now if he wanted to avoid future conflicts. OK, I read your comments on another this series and I've applied 1/4 and 2/4 as per your suggestion with your reviewed by tag ;) Thanks. And I think, Andreas is going to re-spin remains for exynos5250-spring based on updated my -next? Yes. Please don't apply 3/4, I'm fixing a duplicate hdmi node. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Hi, Doug. Thanks for review. On 07/30/2014 03:01 AM, Doug Anderson wrote: Jaehoon, On Sun, Jul 27, 2014 at 7:29 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Replaced the disable-wp into host's quirks. (Because the slot-node is removed at dt-file.) Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com --- drivers/mmc/host/dw_mmc.c | 12 +--- include/linux/mmc/dw_mmc.h |6 ++ 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 1ac227c..4a4f66f 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -997,7 +997,7 @@ static int dw_mci_get_ro(struct mmc_host *mmc) int gpio_ro = mmc_gpio_get_ro(mmc); /* Use platform get_ro function, else try on board write protect */ - if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) + if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) It doesn't seem like it would be hard to include support for the old binding (and just print a warning). Then this could land ahead of the device tree changes. Generally I think we're supposed to keep support for old device trees if possible (except in extreme cases). Ok, I see. I will add the Warning message like this. (Recommend not to use the slot-node...) Then Developers can change the device-tree, right. Today, i will send the patch. If you have any other comment, let me know, plz. I want to merge this patch-set into 3.16. Best Regards, Jaehoon Chung -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: [RESEND][PATCHv2 0/3] Fix for buggy u-boot memory banks
On Mon, 28 Jul 2014 11:56:42 -0700, Laura Abbott lau...@codeaurora.org wrote: On 7/26/2014 2:20 PM, Rob Herring wrote: On Tue, Jul 15, 2014 at 12:03 PM, Laura Abbott lau...@codeaurora.org wrote: Hi, This is a resend of the series to fix the uboot bug exposed by the removal of meminfo. I haven't gotten any acks though. Is the bug with ATAGs that get converted to DT in the decompressor or u-boot puts the wrong info in DT directly? I believe it's u-boot putting the wrong info in DT directly. See http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266782.html I've picked up this series with some very minor changes. I'll ask Linus to pull it into v3.16 as a last minute fix. g. -- 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] media: v4l2: make alloction alogthim more robust and flexible
Current algothim relies on the fact that caller will align the size to PAGE_SIZE, otherwise order will be decreased to negative when remain size is less than PAGE_SIZE, it makes the function hard to be migrated. This patch sloves the hidden problem. Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index adefc31..40d18aa 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf, order = get_order(size); /* Dont over allocate*/ - if ((PAGE_SIZE order) size) + if (order 0 (PAGE_SIZE order) size) order--; pages = NULL; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 5/5] mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk
Jaehoon, On Tue, Jul 29, 2014 at 7:47 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi, Doug. Thanks for review. On 07/30/2014 03:01 AM, Doug Anderson wrote: Jaehoon, On Sun, Jul 27, 2014 at 7:29 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Replaced the disable-wp into host's quirks. (Because the slot-node is removed at dt-file.) Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Tested-by: Sachin Kamat sachin.ka...@samsung.com Acked-by: Seungwon Jeon tgih@samsung.com --- drivers/mmc/host/dw_mmc.c | 12 +--- include/linux/mmc/dw_mmc.h |6 ++ 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 1ac227c..4a4f66f 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -997,7 +997,7 @@ static int dw_mci_get_ro(struct mmc_host *mmc) int gpio_ro = mmc_gpio_get_ro(mmc); /* Use platform get_ro function, else try on board write protect */ - if (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) + if (slot-host-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) It doesn't seem like it would be hard to include support for the old binding (and just print a warning). Then this could land ahead of the device tree changes. Generally I think we're supposed to keep support for old device trees if possible (except in extreme cases). Ok, I see. I will add the Warning message like this. (Recommend not to use the slot-node...) That seems reasonable. Then Developers can change the device-tree, right. Right. Then this can land even ahead of the dts changes and you could change them one at a time (if you wanted) once you have the proper acks. Today, i will send the patch. If you have any other comment, let me know, plz. I want to merge this patch-set into 3.16. I haven't done a full review, but generally this looked pretty sane to me. It seems like it might be too late for 3.16 but I'm no expert on the subject. -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
