Re: [PATCH 1/3] regulator: s2mps11: Refactor setting ramp delay
Hi Krzysztof,
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Prepare for merging the s2mpa01 regulator driver into s2mps11 by:
1. Adding common id for buck regulators.
2. Splitting shared ramp delay settings to match S2MPA01.
3. Adding a configuration of registers for setting ramp delay for each
buck regulator.
The functionality of the driver should not change as this patch only
prepares for supporting S2MPA01 device.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/regulator/s2mps11.c | 210
++--
1 file changed, 144 insertions(+), 66 deletions(-)
[snip]
- if (ramp_delay s2mps11-ramp_delay34)
- s2mps11-ramp_delay34 = ramp_delay;
+ if (ramp_delay s2mps11-ramp_delay3)
+ s2mps11-ramp_delay3 = ramp_delay;
else
- ramp_delay = s2mps11-ramp_delay34;
-
- ramp_shift = S2MPS11_BUCK34_RAMP_SHIFT;
- ramp_reg = S2MPS11_REG_RAMP;
+ ramp_delay = s2mps11-ramp_delay3;
break;
case S2MPS11_BUCK4:
- enable_shift = S2MPS11_BUCK4_RAMP_EN_SHIFT;
if (!ramp_delay) {
ramp_enable = 0;
break;
}
- if (ramp_delay s2mps11-ramp_delay34)
- s2mps11-ramp_delay34 = ramp_delay;
+ if (ramp_delay s2mps11-ramp_delay4)
+ s2mps11-ramp_delay4 = ramp_delay;
else
- ramp_delay = s2mps11-ramp_delay34;
-
- ramp_shift = S2MPS11_BUCK34_RAMP_SHIFT;
- ramp_reg = S2MPS11_REG_RAMP;
+ ramp_delay = s2mps11-ramp_delay4;
Main rationale behind shared value is completely omitted here, in
other cases also,
after just giving a NOTE in documentation asking user to make sure to
pass same value.
It doesn't seem safe, simply leaving a scope of stability issue (in
case ramp_delay3 ramp_delay4).
Regards,
Yadwinder
--
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 13/18] ARM: dts: s6e3fa0: add DT bindings
Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Regards Andrzej Even the Exynos DSI Master bindings[0] say that these two are not at all the same thing: port node: - reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port; Am I missing something here? Thierry [0]: https://www.kernel.org/doc/Documentation/devicetree/bindings/video/exynos_dsim.txt -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] regulator: s2mps11: Merge S2MPA01 driver
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Add S2MPA01 support to the s2mps11 regulator driver. This obsoletes the
s2mpa01 regulator driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
@@ -216,30 +250,20 @@ static int s2mps11_set_ramp_delay(struct regulator_dev
*rdev, int ramp_delay)
ramp_delay = s2mps11-ramp_delay16;
break;
case S2MPX_BUCK2:
- if (!ramp_delay) {
- ramp_enable = 0;
- break;
- }
-
What if we want to disable ramp_delay from DT ?
- s2mps11-ramp_delay2 = ramp_delay;
+ if (s2mps11-dev_type == S2MPS11X ||
+ ramp_delay s2mps11-ramp_delay2)
+ s2mps11-ramp_delay2 = ramp_delay;
+ else /* S2MPA01 ramp_delay = s2mpa01-ramp_delay24 */
+ ramp_delay = s2mps11-ramp_delay2;
Here ramp_delay = 0(ramp_disable case) is also getting over written,
if required to take care of it later.
break;
case S2MPX_BUCK3:
- if (!ramp_delay) {
- ramp_enable = 0;
- break;
- }
[snip]
- if (!ramp_enable)
- goto ramp_disable;
-
- /* Ramp delay can be enabled/disabled only for buck[2346] */
if (ramp_reg-enable_supported) {
+ if (ramp_disable)
typo ?if (!ramp_enable) / if (!ramp_delay) ?
+ goto ramp_disable;
+
Also TBH, I can't get rationale behind this merge, As i can't see
considerable reduction in no of C code lines in comp of added
complexity.
Is there considerable advantage in binary stats of single driver as
compare to independent drivers?
Regards,
Yadwinder
--
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] regulator: s2mps11: Refactor setting ramp delay
On wto, 2014-05-27 at 11:56 +0530, Yadwinder Singh Brar wrote:
Hi Krzysztof,
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Prepare for merging the s2mpa01 regulator driver into s2mps11 by:
1. Adding common id for buck regulators.
2. Splitting shared ramp delay settings to match S2MPA01.
3. Adding a configuration of registers for setting ramp delay for each
buck regulator.
The functionality of the driver should not change as this patch only
prepares for supporting S2MPA01 device.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/regulator/s2mps11.c | 210
++--
1 file changed, 144 insertions(+), 66 deletions(-)
[snip]
- if (ramp_delay s2mps11-ramp_delay34)
- s2mps11-ramp_delay34 = ramp_delay;
+ if (ramp_delay s2mps11-ramp_delay3)
+ s2mps11-ramp_delay3 = ramp_delay;
else
- ramp_delay = s2mps11-ramp_delay34;
-
- ramp_shift = S2MPS11_BUCK34_RAMP_SHIFT;
- ramp_reg = S2MPS11_REG_RAMP;
+ ramp_delay = s2mps11-ramp_delay3;
break;
case S2MPS11_BUCK4:
- enable_shift = S2MPS11_BUCK4_RAMP_EN_SHIFT;
if (!ramp_delay) {
ramp_enable = 0;
break;
}
- if (ramp_delay s2mps11-ramp_delay34)
- s2mps11-ramp_delay34 = ramp_delay;
+ if (ramp_delay s2mps11-ramp_delay4)
+ s2mps11-ramp_delay4 = ramp_delay;
else
- ramp_delay = s2mps11-ramp_delay34;
-
- ramp_shift = S2MPS11_BUCK34_RAMP_SHIFT;
- ramp_reg = S2MPS11_REG_RAMP;
+ ramp_delay = s2mps11-ramp_delay4;
Main rationale behind shared value is completely omitted here, in
other cases also,
after just giving a NOTE in documentation asking user to make sure to
pass same value.
It doesn't seem safe, simply leaving a scope of stability issue (in
case ramp_delay3 ramp_delay4).
The documentation already states that these bucks (e.g. 3 and 4) share
the ramp delay setting and 'regulator-ramp-delay' should be the same.
However you're right that patch is not safe against changing shared ramp
delays to different values. Previously the code was safe so this is not
entirely non-functional change. I'll fix it to retain the same
behavior.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/18] ARM: dts: s6e3fa0: add DT bindings
On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote: Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Then the command mode timings aren't a property of the panel at all. They describe what DSIM expects, so that's where they should be defined. Thierry pgp7wxhxIWi2B.pgp Description: PGP signature
Re: [PATCH 2/3] regulator: s2mps11: Merge S2MPA01 driver
On wto, 2014-05-27 at 12:00 +0530, Yadwinder Singh Brar wrote:
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Add S2MPA01 support to the s2mps11 regulator driver. This obsoletes the
s2mpa01 regulator driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
@@ -216,30 +250,20 @@ static int s2mps11_set_ramp_delay(struct
regulator_dev *rdev, int ramp_delay)
ramp_delay = s2mps11-ramp_delay16;
break;
case S2MPX_BUCK2:
- if (!ramp_delay) {
- ramp_enable = 0;
- break;
- }
-
What if we want to disable ramp_delay from DT ?
It will work OK because at the beginning of s2mps11_set_ramp_delay():
unsigned int ramp_disable = !ramp_delay;
This 'ramp_disable' is later used if enable/disable is supported.
- s2mps11-ramp_delay2 = ramp_delay;
+ if (s2mps11-dev_type == S2MPS11X ||
+ ramp_delay s2mps11-ramp_delay2)
+ s2mps11-ramp_delay2 = ramp_delay;
+ else /* S2MPA01 ramp_delay = s2mpa01-ramp_delay24 */
+ ramp_delay = s2mps11-ramp_delay2;
Here ramp_delay = 0(ramp_disable case) is also getting over written,
if required to take care of it later.
The same, it is already stored as 'ramp_disable' local variable.
break;
case S2MPX_BUCK3:
- if (!ramp_delay) {
- ramp_enable = 0;
- break;
- }
[snip]
- if (!ramp_enable)
- goto ramp_disable;
-
- /* Ramp delay can be enabled/disabled only for buck[2346] */
if (ramp_reg-enable_supported) {
+ if (ramp_disable)
typo ?if (!ramp_enable) / if (!ramp_delay) ?
I think it is good. I changed the 'ramp_enable' into 'ramp_disable'.
Anyway while reviewing the code I found that I didn't updated the case
statements with new BUCKX enum values and the register for
enable/disable is hard-coded. I'll fix it.
+ goto ramp_disable;
+
Also TBH, I can't get rationale behind this merge, As i can't see
considerable reduction in no of C code lines in comp of added
complexity.
Is there considerable advantage in binary stats of single driver as
compare to independent drivers?
Overall more code is removed than added:
6 files changed, 454 insertions(+), 719 deletions(-)
but you are right that the code for ramp delay is now more complex. What
is worth noting now most of ramp delay settings are moved to an array:
static const struct s2mpx_ramp_reg s2mps11_ramp_regs[] = {
[S2MPX_BUCK1] = s2mps11_ramp_reg(BUCK16),
[S2MPX_BUCK2] = s2mps11_buck2346_ramp_reg(BUCK2, RAMP, BUCK2),
[S2MPX_BUCK3] = s2mps11_buck2346_ramp_reg(BUCK34, RAMP, BUCK3)
instead of being hard-coded into the big switch statement like it was
before.
Alternative solution to complex ramp delay setting is to just use
original functions: s2mps11_set_ramp_delay and s2mpa01_set_ramp_delay.
These chips are really similar so having two drivers seems like doubling
the effort for maintaining them.
Thanks for comments.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: exynos4: Add PPMU IP block source clocks.
Exynos4 has saveral PPMUs and each of them has operation clock which
can be gated through CMU's SFR control.
New clocks are listed below. All clocks are added as a gate-typed clock.
CLK_PPMULEFT, CLK_PPMURIGHT, CLK_PPMUG3D, CLK_PPMUCAMIF, CLK_PPMUTV,
CLK_PPMUMFC_L, CLK_PPMUMFC_R, CLK_PPMUIMAGE, CLK_PPMULCD0, CLK_PPMULCD1,
CLK_PPMUFILE, CLK_PPMUGPS, CLK_PPMUCPU, CLK_PPMUACP, CLK_PPMUDMC0,
CLK_PPMUDMC1
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/clk/samsung/clk-exynos4.c | 20
include/dt-bindings/clock/exynos4.h | 18 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..5648437 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -852,6 +852,22 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
0, 0),
GATE(CLK_AC97, ac97, aclk100, GATE_IP_PERIL, 27,
0, 0),
+ GATE(CLK_PPMULEFT, ppmuleft, aclk200, GATE_IP_LEFTBUS, 1, 0, 0),
+ GATE(CLK_PPMURIGHT, ppmuright, aclk200, GATE_IP_RIGHTBUS,
+ 1, 0, 0),
+ GATE(CLK_PPMUG3D, ppmug3d, aclk200, GATE_IP_G3D,
+ 1, 0, 0),
+ GATE(CLK_PPMUCAMIF, ppmucamif, aclk160, GATE_IP_CAM, 16, 0, 0),
+ GATE(CLK_PPMUTV, ppmutv, aclk160, GATE_IP_TV, 5, 0, 0),
+ GATE(CLK_PPMUMFC_L, ppmumfc_l, aclk100, GATE_IP_MFC, 3, 0, 0),
+ GATE(CLK_PPMUMFC_R, ppmumfc_r, aclk100, GATE_IP_MFC, 4, 0, 0),
+ GATE(CLK_PPMULCD0, ppmulcd0, aclk160, GATE_IP_LCD0, 5, 0, 0),
+ GATE(CLK_PPMUFILE, ppmufile, aclk133, GATE_IP_FSYS, 17, 0, 0),
+ GATE(CLK_PPMUGPS, ppmugps, aclk200, GATE_IP_GPS, 2, 0, 0),
+ GATE(CLK_PPMUCPU, ppmucpu, aclk133, GATE_IP_DMC, 10, 0, 0),
+ GATE(CLK_PPMUACP, ppmuacp, aclk133, GATE_IP_DMC, 16, 0, 0),
+ GATE(CLK_PPMUDMC0, ppmudmc0, aclk133, GATE_IP_DMC, 8, 0, 0),
+ GATE(CLK_PPMUDMC1, ppmudmc1, aclk133, GATE_IP_DMC, 9, 0, 0),
};
/* list of gate clocks supported in exynos4210 soc */
@@ -896,6 +912,9 @@ static struct samsung_gate_clock exynos4210_gate_clks[]
__initdata = {
CLK_SET_RATE_PARENT, 0),
GATE(CLK_TMU_APBIF, tmu_apbif, aclk100, E4210_GATE_IP_PERIR, 17, 0,
0),
+ GATE(CLK_PPMUIMAGE, ppmuimage, aclk200, E4210_GATE_IP_IMAGE, 9,
+ 0, 0),
+ GATE(CLK_PPMULCD1, ppmulcd1, aclk160, E4210_GATE_IP_LCD1, 5, 0, 0),
};
/* list of gate clocks supported in exynos4x12 soc */
@@ -1001,6 +1020,7 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
GATE(CLK_G2D, g2d, aclk200, GATE_IP_DMC, 23, 0, 0),
GATE(CLK_TMU_APBIF, tmu_apbif, aclk100, E4X12_GATE_IP_PERIR, 17, 0,
0),
+ GATE(CLK_PPMUIMAGE, ppmuimage, aclk200, E4X12_GATE_IP_IMAGE, 9, 0,
0),
};
static struct samsung_clock_alias exynos4_aliases[] __initdata = {
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index 75aff33..9f331f1 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -230,6 +230,24 @@
#define CLK_MOUT_G3D 394
#define CLK_ACLK400_MCUISP 395 /* Exynos4x12 only */
+/* gate clocks - ppmu */
+#define CLK_PPMULEFT 400
+#define CLK_PPMURIGHT 401
+#define CLK_PPMUG3D402
+#define CLK_PPMUCAMIF 403
+#define CLK_PPMUTV 404
+#define CLK_PPMUMFC_L 405
+#define CLK_PPMUMFC_R 406
+#define CLK_PPMUIMAGE 407
+#define CLK_PPMULCD0 408
+#define CLK_PPMULCD1 409
+#define CLK_PPMUFILE 410
+#define CLK_PPMUGPS411
+#define CLK_PPMUCPU412
+#define CLK_PPMUACP413
+#define CLK_PPMUDMC0 414
+#define CLK_PPMUDMC1 415
+
/* div clocks */
#define CLK_DIV_ISP0 450 /* Exynos4x12 only */
#define CLK_DIV_ISP1 451 /* Exynos4x12 only */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] regulator: s2mps11: Merge S2MPA01 driver
On Tue, May 27, 2014 at 1:26 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
On wto, 2014-05-27 at 12:00 +0530, Yadwinder Singh Brar wrote:
On Mon, May 26, 2014 at 6:50 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Add S2MPA01 support to the s2mps11 regulator driver. This obsoletes the
s2mpa01 regulator driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
@@ -216,30 +250,20 @@ static int s2mps11_set_ramp_delay(struct
regulator_dev *rdev, int ramp_delay)
ramp_delay = s2mps11-ramp_delay16;
break;
case S2MPX_BUCK2:
- if (!ramp_delay) {
- ramp_enable = 0;
- break;
- }
-
What if we want to disable ramp_delay from DT ?
It will work OK because at the beginning of s2mps11_set_ramp_delay():
unsigned int ramp_disable = !ramp_delay;
This 'ramp_disable' is later used if enable/disable is supported.
Oh! I missed you defined a new variable ramp_disable,
since ramp_disable is already a label defined in same function.
It should be different, i think.
- s2mps11-ramp_delay2 = ramp_delay;
+ if (s2mps11-dev_type == S2MPS11X ||
+ ramp_delay s2mps11-ramp_delay2)
+ s2mps11-ramp_delay2 = ramp_delay;
+ else /* S2MPA01 ramp_delay = s2mpa01-ramp_delay24 */
+ ramp_delay = s2mps11-ramp_delay2;
Here ramp_delay = 0(ramp_disable case) is also getting over written,
if required to take care of it later.
The same, it is already stored as 'ramp_disable' local variable.
break;
case S2MPX_BUCK3:
- if (!ramp_delay) {
- ramp_enable = 0;
- break;
- }
[snip]
- if (!ramp_enable)
- goto ramp_disable;
-
- /* Ramp delay can be enabled/disabled only for buck[2346] */
if (ramp_reg-enable_supported) {
+ if (ramp_disable)
typo ?if (!ramp_enable) / if (!ramp_delay) ?
I think it is good. I changed the 'ramp_enable' into 'ramp_disable'.
ok, but very next statement is
goto ramp_disable;
which seems odd and obfuscated me.
Anyway while reviewing the code I found that I didn't updated the case
statements with new BUCKX enum values and the register for
enable/disable is hard-coded. I'll fix it.
+ goto ramp_disable;
+
Also TBH, I can't get rationale behind this merge, As i can't see
considerable reduction in no of C code lines in comp of added
complexity.
Is there considerable advantage in binary stats of single driver as
compare to independent drivers?
Overall more code is removed than added:
6 files changed, 454 insertions(+), 719 deletions(-)
but you are right that the code for ramp delay is now more complex. What
is worth noting now most of ramp delay settings are moved to an array:
static const struct s2mpx_ramp_reg s2mps11_ramp_regs[] = {
[S2MPX_BUCK1] = s2mps11_ramp_reg(BUCK16),
[S2MPX_BUCK2] = s2mps11_buck2346_ramp_reg(BUCK2, RAMP, BUCK2),
[S2MPX_BUCK3] = s2mps11_buck2346_ramp_reg(BUCK34, RAMP, BUCK3)
instead of being hard-coded into the big switch statement like it was
before.
Alternative solution to complex ramp delay setting is to just use
original functions: s2mps11_set_ramp_delay and s2mpa01_set_ramp_delay.
These chips are really similar so having two drivers seems like doubling
the effort for maintaining them.
I think maintaining a complex or a big file(in case we keep original
functions), itself will be an effort consuming thing and moreover
binary size of a single driver will also increase considerable as
compare to independent drivers (if its not case of multiplatform
kernel).
Anyways, i think its matter of preference of all, It will be OK, if
for others( especially maintainers, Mark ?), its OK.
Best Regards,
Yadwinder
Thanks for comments.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 1/3] mmc: host: add slot argument to mmc_of_parse
On Mon, May 26, 2014, Jaehoon Chung wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
Some hosts manage several slots. In these case information such as the
bus width, chip detect and others are into the slot node. So we have to
parse child node. If not NULL, slot node will be used instead of the
device node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Acked-by: Seungwon Jeon tgih@samsung.com
Thanks,
Seungwon Jeon
---
Changelog V2:
- Fix the typo.
drivers/mmc/core/host.c | 13 +
include/linux/mmc/host.h | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 95cceae..0f677b3 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -298,15 +298,17 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
#endif
/**
- * mmc_of_parse() - parse host's device-tree node
+ * __mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot : some device provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
- np = host-parent-of_node;
+ if (slot)
+ np = slot;
+ else
+ np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
@@ -459,7 +464,7 @@ out:
return ret;
}
-EXPORT_SYMBOL(mmc_of_parse);
+EXPORT_SYMBOL(__mmc_of_parse);
/**
* mmc_alloc_host - initialise the per-host structure.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7960424..c62af91 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -372,7 +372,15 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
-int mmc_of_parse(struct mmc_host *host);
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot);
+/*
+ * mmc_of_parse - parse host's device-tree node
+ * @host: host whose node should be parsed.
+ */
+static inline int mmc_of_parse(struct mmc_host *host)
+{
+ return __mmc_of_parse(host, NULL);
+}
static inline void *mmc_priv(struct mmc_host *host)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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: [PATCHv2 2/3] mmc: dw_mmc: use the __mmc_of_parse to parse the slot node
Hi Jaehoon,
On Mon, May 26, 2014, Jaehoon Chung wrote:
dw-mmc controller have the multiple slot.
Have - has?
Then it needs to parse the property for each slot.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changelog V2:
- None
drivers/mmc/host/dw_mmc.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..d4800f8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1015,12 +1015,11 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
{
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
- struct dw_mci_board *brd = slot-host-pdata;
struct dw_mci *host = slot-host;
int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
- if (brd-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ if (slot-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
present = 1;
else if (!IS_ERR_VALUE(gpio_cd))
present = gpio_cd;
@@ -2010,6 +2009,9 @@ static struct dw_mci_of_slot_quirks {
{
.quirk = disable-wp,
.id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ }, {
+ .quirk = broken-cd,
+ .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
},
};
@@ -2088,7 +2090,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
if (host-pdata-caps2)
mmc-caps2 = host-pdata-caps2;
- mmc_of_parse(mmc);
+ __mmc_of_parse(mmc, dw_mci_of_find_slot_node(host-dev, slot-id));
if (host-pdata-blk_settings) {
mmc-max_segs = host-pdata-blk_settings-max_segs;
@@ -2231,23 +2233,13 @@ static inline bool dw_mci_ctrl_all_reset(struct
dw_mci *host)
}
#ifdef CONFIG_OF
-static struct dw_mci_of_quirks {
- char *quirk;
- int id;
-} of_quirks[] = {
- {
- .quirk = broken-cd,
- .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
- },
-};
-
Moving broken-cd to slot_quirks is reasonable.
But I think of_quirks should be kept and we can add right quirks.
In cae of DW_MCI_QUIRK_IDMAC_DTO and DW_MCI_QUIRK_RETRY_DELAY,
we can handle those with dw_mci_of_quirks although we didn't add.
static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
{
struct dw_mci_board *pdata;
struct device *dev = host-dev;
struct device_node *np = dev-of_node;
const struct dw_mci_drv_data *drv_data = host-drv_data;
- int idx, ret;
+ int ret;
u32 clock_frequency;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
@@ -2264,11 +2256,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
dw_mci *host)
pdata-num_slots = 1;
}
- /* get quirks */
- for (idx = 0; idx ARRAY_SIZE(of_quirks); idx++)
- if (of_get_property(np, of_quirks[idx].quirk, NULL))
- pdata-quirks |= of_quirks[idx].id;
-
Same as above.
Thanks,
Seungwon Jeon
if (of_property_read_u32(np, fifo-depth, pdata-fifo_depth))
dev_info(dev, fifo-depth property not found, using
value of FIFOTH register as default\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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: [PATCHv2 3/3] ARM: dts: replace the broken-cd property into slot node for dwmmc.
Can this be merged with your another patch, [PATCH 2/5] mmc: dw_mmc: remove
the supports-highspeed property.?
On Mon, May 26, 2014, Jaehoon Chung wrote:
dw-mmc controller can be support the multiple slot.
can support, it would be better to correct the above message.
Thanks,
Seungwon Jeon
So each slot's property can be difference.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changelog V2:
- None
arch/arm/boot/dts/exynos4412-odroidx.dts |2 +-
arch/arm/boot/dts/exynos4412-origen.dts |2 +-
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
arch/arm/boot/dts/exynos5250-arndale.dts |2 +-
arch/arm/boot/dts/exynos5250-cros-common.dtsi |4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts |2 +-
arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 +-
arch/arm/boot/dts/rk3066a-bqcurie2.dts|2 +-
arch/arm/boot/dts/socfpga_arria5.dtsi |2 +-
arch/arm/boot/dts/socfpga_cyclone5.dtsi |2 +-
arch/arm/boot/dts/socfpga_vt.dts |2 +-
11 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..24ec351 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -46,7 +46,6 @@
num-slots = 1;
supports-highspeed;
- broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -55,6 +54,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e2c0dca..ed712a6 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -129,7 +129,6 @@
num-slots = 1;
supports-highspeed;
- broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -138,6 +137,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 73be464..37c3cb3 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -460,8 +460,6 @@
mmc@1255 {
num-slots = 1;
supports-highspeed;
- broken-cd;
- non-removable;
card-detect-delay = 200;
vmmc-supply = vemmc_reg;
clock-frequency = 4;
@@ -475,6 +473,8 @@
slot@0 {
reg = 0;
bus-width = 8;
+ non-removable;
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 090f983..0c9a7da 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -400,7 +400,6 @@
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;
@@ -412,6 +411,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-
common.dtsi
index 2c1560d..7ab3b94 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -249,7 +249,6 @@
mmc@1220 {
num-slots = 1;
supports-highspeed;
- broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -260,6 +259,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+ broken-cd;
};
};
@@ -283,7 +283,6 @@
mmc@1223 {
num-slots = 1;
supports-highspeed;
- broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -293,6 +292,7 @@
slot@0 {
reg = 0;
bus-width = 4;
+ broken-cd;
};
};
diff --git
Re: [PATCH v5] drm/exynos: enable fimd clocks in probe before accessing fimd registers
Gentle Reminder
On 26 May 2014 14:21, Rahul Sharma rahul.sha...@samsung.com wrote:
Hi Daniel,
On 26 May 2014 13:11, Daniel Kurtz djku...@chromium.org wrote:
On Mon, May 26, 2014 at 2:59 PM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Hi Inki,
Please review this patch.
[snip]
+
+ ret = clk_prepare_enable(ctx-lcd_clk);
Hi Rahul,
Can you explain why exactly we are clearing windows here in probe(),
anyway?
I am not sure why it was added there but it is present since the first
version of this
file. Probably Inki can explain about this :). I can see the change
coming from his
first patch for adding drm fimd driver.
IIUC, bus_clk is the clock that enables FIMD register access, and
lcd_clk clocks the scan out engine.
Therefore, if we only need to read/write some registers, we only need
the bus_clk, not lcd_clk, right?
Correct, bus_clk should be sufficient to access the registers. But unless we
are confident about all implicit clock requirements in all SoCs, it is
safer to follow
the power_on/off sequence. This implementation is as good as DPMS on -
perform
reg operation - DPMS Off. It was same in the original version but
later clock enables
were moved out of the probe.
However, fimd_clear_win() actually clears per-window registers.
Writes to per-window registers typically do not take effect until the
next vblank.
Therefore we do would need to enable lcd_clk to ensure that these
changes take effect.
Furthermore, to ensure the window clear completes during probe(), we
would also need to synchronously wait for the next vblank here - but
only if FIMD scanout is actually enabled already, otherwise there will
never be a next scanout, so we must check for that first.
Lastly, waiting around for a vblank could take a while. Doing so in
probe() is not very friendly to boot up time, so the waiting should
probably be moved out of the main probe() thread into some sort of
asynchronous handler, which could then signal back when the clear is
complete.
Do you agree, or am I missing something?
I agree. There seems a room for improvement. But at present we have two
options,
either fix the current implementation and try to improve it as you mentioned
above. OR remove fimd_clear_win from probe if it is just a legacy code which
is no more required.
@Inki, need your inputs here.
Regards,
Rahul Sharma.
Thanks,
-djk
+ if (ret) {
[snip]
+pm_put_err:
+ return ret;
}
static void fimd_unbind(struct device *dev, struct device *master,
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/3] mmc: dw_mmc: use the __mmc_of_parse to parse the slot node
Hi, Seungwon
On 05/27/2014 06:49 PM, Seungwon Jeon wrote:
Hi Jaehoon,
On Mon, May 26, 2014, Jaehoon Chung wrote:
dw-mmc controller have the multiple slot.
Have - has?
Fix it.
Then it needs to parse the property for each slot.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changelog V2:
- None
drivers/mmc/host/dw_mmc.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..d4800f8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1015,12 +1015,11 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
{
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
-struct dw_mci_board *brd = slot-host-pdata;
struct dw_mci *host = slot-host;
int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
-if (brd-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+if (slot-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
present = 1;
else if (!IS_ERR_VALUE(gpio_cd))
present = gpio_cd;
@@ -2010,6 +2009,9 @@ static struct dw_mci_of_slot_quirks {
{
.quirk = disable-wp,
.id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+}, {
+.quirk = broken-cd,
+.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
},
};
@@ -2088,7 +2090,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
if (host-pdata-caps2)
mmc-caps2 = host-pdata-caps2;
-mmc_of_parse(mmc);
+__mmc_of_parse(mmc, dw_mci_of_find_slot_node(host-dev, slot-id));
if (host-pdata-blk_settings) {
mmc-max_segs = host-pdata-blk_settings-max_segs;
@@ -2231,23 +2233,13 @@ static inline bool dw_mci_ctrl_all_reset(struct
dw_mci *host)
}
#ifdef CONFIG_OF
-static struct dw_mci_of_quirks {
-char *quirk;
-int id;
-} of_quirks[] = {
-{
-.quirk = broken-cd,
-.id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
-},
-};
-
Moving broken-cd to slot_quirks is reasonable.
But I think of_quirks should be kept and we can add right quirks.
In cae of DW_MCI_QUIRK_IDMAC_DTO and DW_MCI_QUIRK_RETRY_DELAY,
we can handle those with dw_mci_of_quirks although we didn't add.
Ok.
Best Regards,
Jaehoon Chung
static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
{
struct dw_mci_board *pdata;
struct device *dev = host-dev;
struct device_node *np = dev-of_node;
const struct dw_mci_drv_data *drv_data = host-drv_data;
-int idx, ret;
+int ret;
u32 clock_frequency;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
@@ -2264,11 +2256,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
dw_mci *host)
pdata-num_slots = 1;
}
-/* get quirks */
-for (idx = 0; idx ARRAY_SIZE(of_quirks); idx++)
-if (of_get_property(np, of_quirks[idx].quirk, NULL))
-pdata-quirks |= of_quirks[idx].id;
-
Same as above.
Thanks,
Seungwon Jeon
if (of_property_read_u32(np, fifo-depth, pdata-fifo_depth))
dev_info(dev, fifo-depth property not found, using
value of FIFOTH register as default\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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-mmc 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: [PATCHv2 3/3] ARM: dts: replace the broken-cd property into slot node for dwmmc.
On 05/27/2014 06:49 PM, Seungwon Jeon wrote:
Can this be merged with your another patch, [PATCH 2/5] mmc: dw_mmc: remove
the supports-highspeed property.?
Sure..
On Mon, May 26, 2014, Jaehoon Chung wrote:
dw-mmc controller can be support the multiple slot.
can support, it would be better to correct the above message.
Fix it.
Best Regards,
Jaehoon Chung
Thanks,
Seungwon Jeon
So each slot's property can be difference.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changelog V2:
- None
arch/arm/boot/dts/exynos4412-odroidx.dts |2 +-
arch/arm/boot/dts/exynos4412-origen.dts |2 +-
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
arch/arm/boot/dts/exynos5250-arndale.dts |2 +-
arch/arm/boot/dts/exynos5250-cros-common.dtsi |4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts |2 +-
arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 +-
arch/arm/boot/dts/rk3066a-bqcurie2.dts|2 +-
arch/arm/boot/dts/socfpga_arria5.dtsi |2 +-
arch/arm/boot/dts/socfpga_cyclone5.dtsi |2 +-
arch/arm/boot/dts/socfpga_vt.dts |2 +-
11 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..24ec351 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -46,7 +46,6 @@
num-slots = 1;
supports-highspeed;
-broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -55,6 +54,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e2c0dca..ed712a6 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -129,7 +129,6 @@
num-slots = 1;
supports-highspeed;
-broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -138,6 +137,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 73be464..37c3cb3 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -460,8 +460,6 @@
mmc@1255 {
num-slots = 1;
supports-highspeed;
-broken-cd;
-non-removable;
card-detect-delay = 200;
vmmc-supply = vemmc_reg;
clock-frequency = 4;
@@ -475,6 +473,8 @@
slot@0 {
reg = 0;
bus-width = 8;
+non-removable;
+broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 090f983..0c9a7da 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -400,7 +400,6 @@
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;
@@ -412,6 +411,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+broken-cd;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-
common.dtsi
index 2c1560d..7ab3b94 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -249,7 +249,6 @@
mmc@1220 {
num-slots = 1;
supports-highspeed;
-broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -260,6 +259,7 @@
slot@0 {
reg = 0;
bus-width = 8;
+broken-cd;
};
};
@@ -283,7 +283,6 @@
mmc@1223 {
num-slots = 1;
supports-highspeed;
-broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
@@ -293,6 +292,7 @@
slot@0 {
reg = 0;
bus-width = 4;
+broken-cd;
};
};
diff --git
Re: [PATCHv2 3/3] ARM: dts: replace the broken-cd property into slot node for dwmmc.
On 27 May 2014 11:49, Seungwon Jeon tgih@samsung.com wrote: Can this be merged with your another patch, [PATCH 2/5] mmc: dw_mmc: remove the supports-highspeed property.? Normally devicetree people don't like us to remove DT bindings. In principle you need to support them forever once added. Still you should update the DTS files to use the new bindings and mark the old ones as deprecated in the documentation. I am not sure if this approach has changed though!? Kind regards Ulf Hansson -- 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] clk: exynos4: Add PPMU IP block source clocks.
Hi Jonghwa,
On 27.05.2014 10:35, Jonghwa Lee wrote:
Exynos4 has saveral PPMUs and each of them has operation clock which
can be gated through CMU's SFR control.
New clocks are listed below. All clocks are added as a gate-typed clock.
CLK_PPMULEFT, CLK_PPMURIGHT, CLK_PPMUG3D, CLK_PPMUCAMIF, CLK_PPMUTV,
CLK_PPMUMFC_L, CLK_PPMUMFC_R, CLK_PPMUIMAGE, CLK_PPMULCD0, CLK_PPMULCD1,
CLK_PPMUFILE, CLK_PPMUGPS, CLK_PPMUCPU, CLK_PPMUACP, CLK_PPMUDMC0,
CLK_PPMUDMC1
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/clk/samsung/clk-exynos4.c | 20
include/dt-bindings/clock/exynos4.h | 18 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..5648437 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -852,6 +852,22 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
0, 0),
GATE(CLK_AC97, ac97, aclk100, GATE_IP_PERIL, 27,
0, 0),
+ GATE(CLK_PPMULEFT, ppmuleft, aclk200, GATE_IP_LEFTBUS, 1, 0, 0),
+ GATE(CLK_PPMURIGHT, ppmuright, aclk200, GATE_IP_RIGHTBUS,
+ 1, 0, 0),
+ GATE(CLK_PPMUG3D, ppmug3d, aclk200, GATE_IP_G3D,
+ 1, 0, 0),
+ GATE(CLK_PPMUCAMIF, ppmucamif, aclk160, GATE_IP_CAM, 16, 0, 0),
+ GATE(CLK_PPMUTV, ppmutv, aclk160, GATE_IP_TV, 5, 0, 0),
+ GATE(CLK_PPMUMFC_L, ppmumfc_l, aclk100, GATE_IP_MFC, 3, 0, 0),
+ GATE(CLK_PPMUMFC_R, ppmumfc_r, aclk100, GATE_IP_MFC, 4, 0, 0),
+ GATE(CLK_PPMULCD0, ppmulcd0, aclk160, GATE_IP_LCD0, 5, 0, 0),
+ GATE(CLK_PPMUFILE, ppmufile, aclk133, GATE_IP_FSYS, 17, 0, 0),
+ GATE(CLK_PPMUGPS, ppmugps, aclk200, GATE_IP_GPS, 2, 0, 0),
+ GATE(CLK_PPMUCPU, ppmucpu, aclk133, GATE_IP_DMC, 10, 0, 0),
+ GATE(CLK_PPMUACP, ppmuacp, aclk133, GATE_IP_DMC, 16, 0, 0),
+ GATE(CLK_PPMUDMC0, ppmudmc0, aclk133, GATE_IP_DMC, 8, 0, 0),
+ GATE(CLK_PPMUDMC1, ppmudmc1, aclk133, GATE_IP_DMC, 9, 0, 0),
Please keep the clocks sorted. It should be by register address
ascending and then by bit field position ascending. I know that it went
a bit out of control and there are unsorted entries, but we should try
to keep it clean when adding new ones.
};
/* list of gate clocks supported in exynos4210 soc */
@@ -896,6 +912,9 @@ static struct samsung_gate_clock exynos4210_gate_clks[]
__initdata = {
CLK_SET_RATE_PARENT, 0),
GATE(CLK_TMU_APBIF, tmu_apbif, aclk100, E4210_GATE_IP_PERIR, 17, 0,
0),
+ GATE(CLK_PPMUIMAGE, ppmuimage, aclk200, E4210_GATE_IP_IMAGE, 9,
+ 0, 0),
+ GATE(CLK_PPMULCD1, ppmulcd1, aclk160, E4210_GATE_IP_LCD1, 5, 0, 0),
Ditto.
};
/* list of gate clocks supported in exynos4x12 soc */
@@ -1001,6 +1020,7 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
GATE(CLK_G2D, g2d, aclk200, GATE_IP_DMC, 23, 0, 0),
GATE(CLK_TMU_APBIF, tmu_apbif, aclk100, E4X12_GATE_IP_PERIR, 17, 0,
0),
+ GATE(CLK_PPMUIMAGE, ppmuimage, aclk200, E4X12_GATE_IP_IMAGE, 9, 0,
0),
Ditto.
};
static struct samsung_clock_alias exynos4_aliases[] __initdata = {
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index 75aff33..9f331f1 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -230,6 +230,24 @@
#define CLK_MOUT_G3D 394
#define CLK_ACLK400_MCUISP 395 /* Exynos4x12 only */
+/* gate clocks - ppmu */
+#define CLK_PPMULEFT 400
+#define CLK_PPMURIGHT401
+#define CLK_PPMUG3D 402
+#define CLK_PPMUCAMIF403
+#define CLK_PPMUTV 404
+#define CLK_PPMUMFC_L405
+#define CLK_PPMUMFC_R406
+#define CLK_PPMUIMAGE407
+#define CLK_PPMULCD0 408
+#define CLK_PPMULCD1 409
A comment saying that this clock is only for Exynos4210 might be nice,
as several Exynos4x12-specific clocks already have.
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 v5 5/5] arm: exynos: Add MCPM call-back functions
On Monday 05 May 2014, Abhilash Kesavan wrote:
+static const struct mcpm_platform_ops exynos_power_ops = {
+ .power_up = exynos_power_up,
+ .power_down = exynos_power_down,
+ .power_down_finish = exynos_power_down_finish,
+};
I'm getting a build error in linux-next because there is no .power_down_finish
member in mcpm_platform_ops here.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/11] ARM: Exynos: PMU cleanup and refactoring for using DT
Hi, Any comments on this series? On Sat, May 10, 2014 at 12:26 PM, Pankaj Dubey pankaj.du...@samsung.com wrote: This patch series, does some minor cleanup of exynos machine files. It also modifies Exynos Power Management Unit (PMU) related code for converting it into a platform_driver. This is also preparation for moving PMU related code out of machine folder into a either drivers/mfd, or drivers/power or some other suitable place so that ARM64 based SoC can utilize common piece of code. These patches require change in Exynos4 SoC dtsi files, which has been posted as separate patch series. These patches are created on top of Kukjin Kim's for-next (v3.15-rc1 tag) branch and on top of Daniel Lezcano's Exynos cpuidle refactor patches [2]. These patches depends on following three patch series: [1] mfd: syscon: Support early initialization https://lkml.org/lkml/2014/4/8/239 [2] Daniel Lezcano's Exynos cpuidle refactor patches http://thread.gmane.org/gmane.linux.kernel.samsung-soc/29085 [3] Allow NULL property in syscon_early_regmap_lookup_by_phandle https://lkml.org/lkml/2014/5/10/10 and https://lkml.org/lkml/2014/4/29/661 We have tested these patches on SMDK5250 board for System boot and Arndale (Exynos5250) board for System boot and PMU initialization and S2R. For testing on Arndale (Exynos5250) board: Tested-by: Pankaj Dubey pankaj.du...@samsung.com Changes Since v3: - Addressed build fail issue in exynos.c as reported by Sachin Kamat. - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init as suggested by Vikas Sajjan. - Rebased on top of Sysram patches by Sachin Kamat. - Modified syscon_early_regmap_lookup_by_phandle and syscon_regmap_lookup_by_phandle function call to pass property as NULL. Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed exynos_cpuidle_init and exynos_cpufreq_init code as suggested by Tomasz Figa. - Removed early mapping of PMU base address from exynos.c and removed get_exynos_pmuaddr function. Instead of this added code in platsmp.c to get PMU base address using of_iomap as suggested by Tomasz Figa. - Converted PMU implementation into platform_driver by using static platform_device method. Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Added patch: Make exynos machine_ops as static. For making more cleanup in mach-exynos/common.h as suggested by Tomasz Figa. - Addressed comments of Tomasz Figa for cleaning mach-exynos/common.h. - Updated patch: Remove file path from comment section As suggested by Michel Simek, instead of updating file path lets remove them from each file under mach-exynos. Even though Kukjin pointed out that there is similar patch pending from Sachin/Tushar but since I could not find I have included this here. If I have missed something please point to any existing such patch. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of exynos_pmu_base, as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that early_syscon_init requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as smp_secondary_init will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Added patch: Remove linux/bug.h from pmu.c. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Move mach/map.h inclusion from regs-pmu.h to platsmp.c - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to drivers/mfd folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as samsung, exynosxxx-pmu, syscon, once we enable MFD_SYSCON config option, current syscon driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using syscon_early_regmap_lookup_by_phandle. If there is any better solution please suggest. Pankaj Dubey (7): ARM: EXYNOS: Make exynos machine_ops as static ARM: EXYNOS: Move cpufreq
[PATCH v2] clk: exynos4: Add PPMU IP block source clocks.
Exynos4 has saveral PPMUs and each of them has operation clock which
can be gated through CMU's SFR control.
New clocks are listed below. All clocks are added as a gate-typed clock.
CLK_PPMULEFT, CLK_PPMURIGHT, CLK_PPMUCAMIF, CLK_PPMUTV, CLK_PPMUMFC_L,
CLK_PPMUMFC_R, CLK_G3D, CLK_PPMUIMAGE, CLK_PPMULCD0, CLK_PPMULCD1,
CLK_PPMUFILE, CLK_PPMUGPS, CLK_PPMUDMC0, CLK_PPMUDMC1, CLK_PPMUCPU,
CLK_PPMUACP,
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
V2 :
- Change clock definition order.
drivers/clk/samsung/clk-exynos4.c | 19 +++
include/dt-bindings/clock/exynos4.h | 18 ++
2 files changed, 37 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..bed19b9 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -680,6 +680,8 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
* the device name and clock alias names specified below for some
* of the clocks can be removed.
*/
+ GATE(CLK_PPMULEFT, ppmuleft, aclk200, GATE_IP_LEFTBUS, 1, 0, 0),
+ GATE(CLK_PPMURIGHT, ppmuright, aclk200, GATE_IP_RIGHTBUS, 1, 0, 0),
GATE(CLK_SCLK_HDMI, sclk_hdmi, mout_hdmi, SRC_MASK_TV, 0, 0, 0),
GATE(CLK_SCLK_SPDIF, sclk_spdif, mout_spdif, SRC_MASK_PERIL1, 8, 0,
0),
@@ -695,11 +697,13 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
GATE(CLK_SROMC, sromc, aclk133, GATE_IP_FSYS, 11, 0, 0),
GATE(CLK_SCLK_G3D, sclk_g3d, div_g3d, GATE_IP_G3D, 0,
CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PPMUG3D, ppmug3d, aclk200, GATE_IP_G3D, 1, 0, 0),
GATE(CLK_USB_DEVICE, usb_device, aclk133, GATE_IP_FSYS, 13, 0, 0),
GATE(CLK_ONENAND, onenand, aclk133, GATE_IP_FSYS, 15, 0, 0),
GATE(CLK_NFCON, nfcon, aclk133, GATE_IP_FSYS, 16, 0, 0),
GATE(CLK_GPS, gps, aclk133, GATE_IP_GPS, 0, 0, 0),
GATE(CLK_SMMU_GPS, smmu_gps, aclk133, GATE_IP_GPS, 1, 0, 0),
+ GATE(CLK_PPMUGPS, ppmugps, aclk200, GATE_IP_GPS, 2, 0, 0),
GATE(CLK_SLIMBUS, slimbus, aclk100, GATE_IP_PERIL, 25, 0, 0),
GATE(CLK_SCLK_CAM0, sclk_cam0, div_cam0, GATE_SCLK_CAM, 4,
CLK_SET_RATE_PARENT, 0),
@@ -781,19 +785,24 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
0, 0),
GATE(CLK_SMMU_JPEG, smmu_jpeg, aclk160, GATE_IP_CAM, 11,
0, 0),
+ GATE(CLK_PPMUCAMIF, ppmucamif, aclk160, GATE_IP_CAM, 16, 0, 0),
GATE(CLK_PIXELASYNCM0, pxl_async0, aclk160, GATE_IP_CAM, 17, 0, 0),
GATE(CLK_PIXELASYNCM1, pxl_async1, aclk160, GATE_IP_CAM, 18, 0, 0),
GATE(CLK_SMMU_TV, smmu_tv, aclk160, GATE_IP_TV, 4,
0, 0),
+ GATE(CLK_PPMUTV, ppmutv, aclk160, GATE_IP_TV, 5, 0, 0),
GATE(CLK_MFC, mfc, aclk100, GATE_IP_MFC, 0, 0, 0),
GATE(CLK_SMMU_MFCL, smmu_mfcl, aclk100, GATE_IP_MFC, 1,
0, 0),
GATE(CLK_SMMU_MFCR, smmu_mfcr, aclk100, GATE_IP_MFC, 2,
0, 0),
+ GATE(CLK_PPMUMFC_L, ppmumfc_l, aclk100, GATE_IP_MFC, 3, 0, 0),
+ GATE(CLK_PPMUMFC_R, ppmumfc_r, aclk100, GATE_IP_MFC, 4, 0, 0),
GATE(CLK_FIMD0, fimd0, aclk160, GATE_IP_LCD0, 0,
0, 0),
GATE(CLK_SMMU_FIMD0, smmu_fimd0, aclk160, GATE_IP_LCD0, 4,
0, 0),
+ GATE(CLK_PPMULCD0, ppmulcd0, aclk160, GATE_IP_LCD0, 5, 0, 0),
GATE(CLK_PDMA0, pdma0, aclk133, GATE_IP_FSYS, 0,
0, 0),
GATE(CLK_PDMA1, pdma1, aclk133, GATE_IP_FSYS, 1,
@@ -806,6 +815,7 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
0, 0),
GATE(CLK_SDMMC3, sdmmc3, aclk133, GATE_IP_FSYS, 8,
0, 0),
+ GATE(CLK_PPMUFILE, ppmufile, aclk133, GATE_IP_FSYS, 17, 0, 0),
GATE(CLK_UART0, uart0, aclk100, GATE_IP_PERIL, 0,
0, 0),
GATE(CLK_UART1, uart1, aclk100, GATE_IP_PERIL, 1,
@@ -852,6 +862,10 @@ static struct samsung_gate_clock exynos4_gate_clks[]
__initdata = {
0, 0),
GATE(CLK_AC97, ac97, aclk100, GATE_IP_PERIL, 27,
0, 0),
+ GATE(CLK_PPMUDMC0, ppmudmc0, aclk133, GATE_IP_DMC, 8, 0, 0),
+ GATE(CLK_PPMUDMC1, ppmudmc1, aclk133, GATE_IP_DMC, 9, 0, 0),
+ GATE(CLK_PPMUCPU, ppmucpu, aclk133, GATE_IP_DMC, 10, 0, 0),
+ GATE(CLK_PPMUACP, ppmuacp, aclk133, GATE_IP_DMC, 16, 0, 0),
};
/* list of gate clocks supported in exynos4210 soc */
@@ -863,6 +877,9 @@ static struct samsung_gate_clock exynos4210_gate_clks[]
__initdata = {
GATE(CLK_SMMU_G2D, smmu_g2d, aclk200, E4210_GATE_IP_IMAGE, 3, 0, 0),
GATE(CLK_SMMU_MDMA, smmu_mdma, aclk200,
[PATCH 0/2] drm/exynos: consider deferred probe case
This patch series includes the following two patches. One makes sure that exynos drm framework handles deferred probe case of sub drivers, and other makes sure that mipi dsi driver considers deferred probe incurred by panel driver. Inki Dae (2): drm/exynos: consider deferred probe feature drm/exynos: mipi-dsi: consider panel driver-deferred probe drivers/gpu/drm/exynos/exynos_dp_core.c | 16 ++- drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69 +++--- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49 +++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 62 +++ drivers/gpu/drm/exynos/exynos_mixer.c| 16 ++- 7 files changed, 170 insertions(+), 77 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: mipi-dsi: consider panel driver-deferred probe
This patch makes sure that mipi dsi driver makes it re-probe
in case that panel driver isn't probed yet.
For this, it checks if panel driver is probed or not before
component_add() is called.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 38 +++
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 1421d9b..22503f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1166,11 +1166,8 @@ exynos_dsi_detect(struct drm_connector *connector, bool
force)
{
struct exynos_dsi *dsi = connector_to_dsi(connector);
- if (!dsi-panel) {
- dsi-panel = of_drm_find_panel(dsi-panel_node);
- if (dsi-panel)
- drm_panel_attach(dsi-panel, dsi-connector);
- } else if (!dsi-panel_node) {
+/* Power off if panel driver is removed. */
+ if (!dsi-panel_node) {
struct exynos_drm_display *display;
display = platform_get_drvdata(to_platform_device(dsi-dev));
@@ -1383,19 +1380,8 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
void *data)
{
struct drm_device *drm_dev = data;
- struct exynos_dsi *dsi;
- int ret;
- ret = exynos_drm_create_enc_conn(drm_dev, exynos_dsi_display);
- if (ret) {
- DRM_ERROR(Encoder create [%d] failed with %d\n,
- exynos_dsi_display.type, ret);
- return ret;
- }
-
- dsi = exynos_dsi_display.ctx;
-
- return mipi_dsi_host_register(dsi-dsi_host);
+ return exynos_drm_create_enc_conn(drm_dev, exynos_dsi_display);
}
static void exynos_dsi_unbind(struct device *dev, struct device *master,
@@ -1406,8 +1392,6 @@ static void exynos_dsi_unbind(struct device *dev, struct
device *master,
exynos_dsi_dpms(exynos_dsi_display, DRM_MODE_DPMS_OFF);
- mipi_dsi_host_unregister(dsi-dsi_host);
-
encoder-funcs-destroy(encoder);
drm_connector_cleanup(dsi-connector);
}
@@ -1502,6 +1486,18 @@ static int exynos_dsi_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, exynos_dsi_display);
+ ret = mipi_dsi_host_register(dsi-dsi_host);
+ if (ret)
+ goto err_del_component;
+
+ dsi-panel = of_drm_find_panel(dsi-panel_node);
+ if (!dsi-panel) {
+ mipi_dsi_host_unregister(dsi-dsi_host);
+ return -EPROBE_DEFER;
+ }
+
+ drm_panel_attach(dsi-panel, dsi-connector);
+
ret = component_add(pdev-dev, exynos_dsi_component_ops);
if (ret)
goto err_del_component;
@@ -1515,6 +1511,10 @@ err_del_component:
static int exynos_dsi_remove(struct platform_device *pdev)
{
+ struct exynos_dsi *dsi = exynos_dsi_display.ctx;
+
+ mipi_dsi_host_unregister(dsi-dsi_host);
+
component_del(pdev-dev, exynos_dsi_component_ops);
exynos_drm_component_del(pdev-dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm/exynos: consider deferred probe case
This patch makes sure that exynos drm framework handles deferred
probe case correctly.
Sub drivers could be probed before resources, clock, regulator,
phy or panel, are ready for them so we should make sure that exynos
drm core waits until all resources are ready and sub drivers are
probed correctly.
Signed-off-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 16 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h |7 +---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 31 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 62 ++
drivers/gpu/drm/exynos/exynos_mixer.c| 16 +++-
7 files changed, 151 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index ff63901..7526f36 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1328,12 +1328,24 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
- return exynos_drm_component_add(pdev-dev, exynos_dp_ops);
+ int ret;
+
+ ret = exynos_drm_component_add(pdev-dev);
+ if (ret)
+ return ret;
+
+ ret = component_add(pdev-dev, exynos_dp_ops);
+ if (ret)
+ exynos_drm_component_del(pdev-dev);
+
+ return ret;
}
static int exynos_dp_remove(struct platform_device *pdev)
{
- exynos_drm_component_del(pdev-dev, exynos_dp_ops);
+ component_del(pdev-dev, exynos_dp_ops);
+ exynos_drm_component_del(pdev-dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index c5a401ae..f611f5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -381,22 +381,25 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
};
-int exynos_drm_component_add(struct device *dev,
- const struct component_ops *ops)
+int exynos_drm_component_add(struct device *dev)
{
struct component_dev *cdev;
- int ret;
+
+ mutex_lock(drm_component_lock);
+
+ list_for_each_entry(cdev, drm_component_list, list) {
+ if (cdev-dev == dev) {
+ mutex_unlock(drm_component_lock);
+ return 0;
+ }
+ }
+
+ mutex_unlock(drm_component_lock);
cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
if (!cdev)
return -ENOMEM;
- ret = component_add(dev, ops);
- if (ret) {
- kfree(cdev);
- return ret;
- }
-
cdev-dev = dev;
mutex_lock(drm_component_lock);
@@ -406,8 +409,7 @@ int exynos_drm_component_add(struct device *dev,
return 0;
}
-void exynos_drm_component_del(struct device *dev,
- const struct component_ops *ops)
+void exynos_drm_component_del(struct device *dev)
{
struct component_dev *cdev, *next;
@@ -422,8 +424,6 @@ void exynos_drm_component_del(struct device *dev,
}
mutex_unlock(drm_component_lock);
-
- component_del(dev, ops);
}
static int compare_of(struct device *dev, void *data)
@@ -446,6 +446,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
ret = component_master_add_child(m, compare_of, cdev-dev);
if (!ret)
attached_cnt++;
+ else
+ return ret;
mutex_lock(drm_component_lock);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e82e620..13480b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -354,12 +354,9 @@ void exynos_drm_remove_vidi(void);
int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
-struct component_ops;
-int exynos_drm_component_add(struct device *dev,
- const struct component_ops *ops);
+int exynos_drm_component_add(struct device *dev);
-void exynos_drm_component_del(struct device *dev,
- const struct component_ops *ops);
+void exynos_drm_component_del(struct device *dev);
extern struct platform_driver fimd_driver;
extern struct platform_driver dp_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 84661fe..1421d9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@
Re: [PATCH v5] drm/exynos: enable fimd clocks in probe before accessing fimd registers
On 2014년 05월 27일 18:55, Rahul Sharma wrote:
Gentle Reminder
On 26 May 2014 14:21, Rahul Sharma rahul.sha...@samsung.com wrote:
Hi Daniel,
On 26 May 2014 13:11, Daniel Kurtz djku...@chromium.org wrote:
On Mon, May 26, 2014 at 2:59 PM, Rahul Sharma rahul.sha...@samsung.com
wrote:
Hi Inki,
Please review this patch.
[snip]
+
+ ret = clk_prepare_enable(ctx-lcd_clk);
Hi Rahul,
Can you explain why exactly we are clearing windows here in probe(),
anyway?
I am not sure why it was added there but it is present since the first
version of this
file. Probably Inki can explain about this :). I can see the change
coming from his
first patch for adding drm fimd driver.
IIUC, bus_clk is the clock that enables FIMD register access, and
lcd_clk clocks the scan out engine.
Therefore, if we only need to read/write some registers, we only need
the bus_clk, not lcd_clk, right?
Correct, bus_clk should be sufficient to access the registers. But unless we
are confident about all implicit clock requirements in all SoCs, it is
safer to follow
the power_on/off sequence. This implementation is as good as DPMS on -
perform
reg operation - DPMS Off. It was same in the original version but
later clock enables
were moved out of the probe.
However, fimd_clear_win() actually clears per-window registers.
Writes to per-window registers typically do not take effect until the
next vblank.
Therefore we do would need to enable lcd_clk to ensure that these
changes take effect.
Furthermore, to ensure the window clear completes during probe(), we
would also need to synchronously wait for the next vblank here - but
only if FIMD scanout is actually enabled already, otherwise there will
never be a next scanout, so we must check for that first.
Lastly, waiting around for a vblank could take a while. Doing so in
probe() is not very friendly to boot up time, so the waiting should
probably be moved out of the main probe() thread into some sort of
asynchronous handler, which could then signal back when the clear is
complete.
Do you agree, or am I missing something?
I agree. There seems a room for improvement. But at present we have two
options,
either fix the current implementation and try to improve it as you mentioned
above. OR remove fimd_clear_win from probe if it is just a legacy code which
Just let's remove fimd_clear_win. it wouldn't need to disable all
hardware overlays at probe.
Thanks,
Inki Dae
is no more required.
@Inki, need your inputs here.
Regards,
Rahul Sharma.
Thanks,
-djk
+ if (ret) {
[snip]
+pm_put_err:
+ return ret;
}
static void fimd_unbind(struct device *dev, struct device *master,
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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] drm/exynos: Make exynos_drm_init() call late during the bootup
On 2014년 05월 26일 14:39, Naveen Krishna Ch wrote: Hello Everyone, On 21 May 2014 21:16, Thierry Reding thierry.red...@gmail.com wrote: On Wed, May 14, 2014 at 05:09:45PM +0530, Naveen Krishna Chatradhi wrote: exynos_drm_init() does probing of various drivers like dp_panel, hdmi, fimd, mixer, etc in an order and finally binds them together. Some of the drm devices (Eg: dp_panel) try to do regulator_get() and enable few supplies during their probe. Chances are that, these devices may get probed before the respective supply/PMIC is hooked. In such cases, dp_panel would continue with dummy regulator. Which is not what the system wants. Lets give the core connectivity and regulators modules some time to hookup the supplies before Exynos DRM devices comes into picture. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- This change is proposed after 1. Discussing with I2C/SPI DMA subsystem maintainers and Others @ https://lkml.org/lkml/2014/5/9/333 Trying to change the I2C, SPI and DMA drivers as subsys_initcall() Which was strictly opposed, as a flaw was found in DRM subsystem. 2. -EPROBE_DEFER won't work well with the current sequency of platform_driver_register()s in exynos_drm_init() Then this is the problem that you need to fix. If the driver doesn't handle -EPROBE_DEFER properly then that means the driver is broken. No amount of initcall ordering can fix this for you. We seem to have a problem with the probe sequencing and usage of _EPROBE_DEFER in DRM. Component way of registration doesnt seem to fix everything. Inki Dae, Is there any discussion or approach underway. Anyone working on this. Hi, I have just posted a patch series, [PATCH 0/2] drm/exynos: consider deferred probe case, to resolve that issue. With this, it wouldn't need your patch anymore. Thanks, Inki Dae Thierry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/7] arm64: KVM: Set physical address size related factors in runtime
On Mon, May 12, 2014 at 06:40:54PM +0900, Jungseok Lee wrote:
This patch sets TCR_EL2.PS, VTCR_EL2.T0SZ and vttbr_baddr_mask in runtime,
not compile time.
In ARMv8, EL2 physical address size (TCR_EL2.PS) and stage2 input address
size (VTCR_EL2.T0SZE) cannot be determined in compile time since they
depends on hardware capability.
s/depends/depend/
According to Table D4-23 and Table D4-25 in ARM DDI 0487A.b document,
vttbr_x is calculated using different hard-coded values with consideration
super nit: I guess this is fixed values, and not hard-coded values
of T0SZ, granule size and the level of translation tables. Therefore,
vttbr_baddr_mask should be determined dynamically.
so I think there's a deeper issue here, which is that we're not
currently considering that for a given supported physical address size
(run-time) and given page granularity (compile-time), we may have some
flexibility in choosing the VTCR_EL2.SL0 field, and thereby the size of
the initial stage2 pgd, by concatinating the initial level page tables.
Additionally, the combinations of the givens may also force us to choose
a specific SL0 value.
Policy-wise, I would say we should concatenate as many initial level page
tables as possible when using 4K pages, iow. always set VTCR_EL2.SL0 to
the lowest possible value given the PARange and page size config we have
at hand. That should always provide increased performance for VMs at
the cost of maximum 16 concatenated tables, which is a 64K contiguous
allocation and alignment, for 4K pages.
For 64K pages, it becomes a 256K alignment and contiguous allocation
requirement. One could argue that if this is not possible on your
system, then you have no business runninng VMs on there, but I want to
leave this open for comments...
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
arch/arm/kvm/arm.c | 82
+-
arch/arm64/include/asm/kvm_arm.h | 17 ++--
arch/arm64/kvm/hyp-init.S| 20 +++---
3 files changed, 98 insertions(+), 21 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f0e50a0..9f19f2c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -37,6 +37,7 @@
#include asm/mman.h
#include asm/tlbflush.h
#include asm/cacheflush.h
+#include asm/cputype.h
#include asm/virt.h
#include asm/kvm_arm.h
#include asm/kvm_asm.h
@@ -61,6 +62,9 @@ static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
static u8 kvm_next_vmid;
static DEFINE_SPINLOCK(kvm_vmid_lock);
+/* VTTBR mask cannot be determined in complie time under ARMv8 */
+static u64 vttbr_baddr_mask;
+
static bool vgic_present;
static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
@@ -412,6 +416,75 @@ static bool need_new_vmid_gen(struct kvm *kvm)
}
/**
+ * set_vttbr_baddr_mask - set mask value for vttbr base address
+ *
+ * In ARMv8, vttbr_baddr_mask cannot be determined in compile time since
stage2
the stage2 input address size
+ * input address size depends on hardware capability. Thus, it is needed to
read
Thus, we first need to read... considering both the translation granule
and the level...
+ * ID_AA64MMFR0_EL1.PARange first and then set vttbr_baddr_mask with
consideration
+ * of both granule size and the level of translation tables.
+ */
+static int set_vttbr_baddr_mask(void)
+{
+#ifndef CONFIG_ARM64
We have completely avoided this kind of ifdef's so far.
The end calculation of the alignment requirements for the VTTBR.BADDR
field is the same for arm and arm64, so either providing a lookup table or
static inlines in kvm_arm.h for the two archs should work.
+ vttbr_baddr_mask = VTTBR_BADDR_MASK;
+#else
+ int pa_range, t0sz, vttbr_x;
+
+ pa_range = read_cpuid(ID_AA64MMFR0_EL1) 0xf;
+
+ switch (pa_range) {
+ case 0:
+ t0sz = VTCR_EL2_T0SZ(32);
+ break;
+ case 1:
+ t0sz = VTCR_EL2_T0SZ(36);
+ break;
+ case 2:
+ t0sz = VTCR_EL2_T0SZ(40);
+ break;
+ case 3:
+ t0sz = VTCR_EL2_T0SZ(42);
+ break;
+ case 4:
+ t0sz = VTCR_EL2_T0SZ(44);
+ break;
+ default:
+ t0sz = VTCR_EL2_T0SZ(48);
why default? this would be 'case 5', and then
default:
kvm_err(Unknown PARange: %d, hardware is weird\n, pa_range);
return -EFAULT;
+ }
+
+ /*
+ * See Table D4-23 and Table D4-25 in ARM DDI 0487A.b to figure out
+ * the origin of the hardcoded values, 38 and 37.
+ */
+#ifdef CONFIG_ARM64_64K_PAGES
+ /*
+ * 16 = T0SZ = 21 is valid under 3 level of translation tables
+ * 18 = T0SZ = 34 is valid under 2 level of translation tables
+ * 31 = T0SZ = 39 is valid under 1 level of
Re: [PATCH 0/8] i.MX6 PCIe binding change and MSI support
Hi Bjorn, On Mon, May 12, 2014 at 5:59 AM, Lucas Stach l.st...@pengutronix.de wrote: Hi Bjorn, just a friendly reminder. It would be nice if you could pull those in. Shawn already pulled the DT change and as it is a binding change this means PCIe on i.MX6 is broken in -next, as long as the remaining patches are missing. We still have imx6q pcie broken in linux-next: imx6q-pcie 1ffc000.pcie: lvds_gate clock select missing or invalid imx6q-pcie: probe of 1ffc000.pcie failed with error -2 Could you please apply Lucas' series? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/7] arm64: KVM: Set physical address size related factors in runtime
On Tue, May 27, 2014 at 03:53:49PM +0200, Christoffer Dall wrote: On Mon, May 12, 2014 at 06:40:54PM +0900, Jungseok Lee wrote: This patch sets TCR_EL2.PS, VTCR_EL2.T0SZ and vttbr_baddr_mask in runtime, not compile time. In ARMv8, EL2 physical address size (TCR_EL2.PS) and stage2 input address size (VTCR_EL2.T0SZE) cannot be determined in compile time since they depends on hardware capability. s/depends/depend/ According to Table D4-23 and Table D4-25 in ARM DDI 0487A.b document, vttbr_x is calculated using different hard-coded values with consideration super nit: I guess this is fixed values, and not hard-coded values of T0SZ, granule size and the level of translation tables. Therefore, vttbr_baddr_mask should be determined dynamically. so I think there's a deeper issue here, which is that we're not currently considering that for a given supported physical address size (run-time) and given page granularity (compile-time), we may have some flexibility in choosing the VTCR_EL2.SL0 field, and thereby the size of the initial stage2 pgd, by concatinating the initial level page tables. Additionally, the combinations of the givens may also force us to choose a specific SL0 value. Policy-wise, I would say we should concatenate as many initial level page tables as possible when using 4K pages, iow. always set VTCR_EL2.SL0 to the lowest possible value given the PARange and page size config we have at hand. That should always provide increased performance for VMs at the cost of maximum 16 concatenated tables, which is a 64K contiguous allocation and alignment, for 4K pages. For 64K pages, it becomes a 256K alignment and contiguous allocation requirement. One could argue that if this is not possible on your system, then you have no business runninng VMs on there, but I want to leave this open for comments... Just had a brief chat with Marc, and he made me think of the fact that we cannot decide this freely, because the code in kvm_mmu.c assumes that the stage-2 page tables have the same number of levels etc. as the host kernel (we re-use functions like pud_offset, pud_addr_end, etc. etc.). I'm not sure this can always be aligned, so we may have to write our own kvm_... versions of these to accomodate the best policy for KVM. -Christoffer -- 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 v6 7/7] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2
On Mon, May 12, 2014 at 06:56:00PM +0900, Jungseok Lee wrote: This patch adds 4 levels of translation tables implementation for both HYP and stage2. Both symmetric and asymmetric configurations for page size and translation levels are are validated on Fast Models: 1) 4KB + 3 levels guest on 4KB + 4 levels host 2) 4KB + 4 levels guest on 4KB + 4 levels host 3) 64KB + 2 levels guest on 4KB + 4 levels host 4) 4KB + 3 levels guest on 64KB + 2 levels host 5) 4KB + 4 levels guest on 64KB + 2 levels host 6) 64KB + 2 levels guest on 64KB + 2 levels host Cc: Marc Zyngier marc.zyng...@arm.com Cc: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com Acked-by: Kukjin Kim kgene@samsung.com I'm going to hold off giving this a final review until we have that previous VTTBR_X patch sorted out. Given the number of open questions in that one, I recommend you factor that patch out of this patch set, get that sorted out first, and then send a new version of this patch set once we have an agreement on the other patch. -Christoffer -- 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 13/18] ARM: dts: s6e3fa0: add DT bindings
2014-05-27 16:53 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote: Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Then the command mode timings aren't a property of the panel at all. Then the video mode timings aren't also a property of the panel. Which interface mipi and display controller should use would be decided by lcd panel type: display controller can use i80 interface based lcd panel, and also mipi controller can use i80 interface based lcd panel. In here, the only difference is that lcd panel receives packets, which includes video data or command data, packed with mipi protocol via lane lines or receives video data or command data via parallel lines. And the below is LCD types, RGB interface panel. i80 interface panel. MIPI based RGB interface panel. MIPI based i80 interface panel. RGB interface also is called video mode, and i80 interface also is called cpu mode. In case of omap SoC, it is also called Smart panel. i80 interface is just one of LCD types. So I think this interface timings should be handled by frameworks related to mode in same way as RGB interface. Thanks, Inki Dae They describe what DSIM expects, so that's where they should be defined. 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
[PATCH] ARM: multi_v7_defconfig: Enable Exynos platform
From: Sachin Kamat sachin.ka...@linaro.org Enable Exynos platform and its related IPs for multi_v7_defconfig. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/configs/multi_v7_defconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index d4e8a47..1996463 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -47,6 +47,7 @@ CONFIG_ARCH_SPEAR13XX=y CONFIG_MACH_SPEAR1310=y CONFIG_MACH_SPEAR1340=y CONFIG_ARCH_STI=y +CONFIG_ARCH_EXYNOS=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_SIRF=y CONFIG_ARCH_TEGRA=y @@ -71,6 +72,7 @@ CONFIG_PCI_MSI=y CONFIG_PCI_MVEBU=y CONFIG_PCI_TEGRA=y CONFIG_SMP=y +CONFIG_NR_CPUS=8 CONFIG_HIGHPTE=y CONFIG_CMA=y CONFIG_ARM_APPENDED_DTB=y @@ -153,6 +155,8 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_SERIAL_SAMSUNG=y +CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_SIRFSOC=y CONFIG_SERIAL_SIRFSOC_CONSOLE=y CONFIG_SERIAL_TEGRA=y @@ -176,6 +180,7 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y CONFIG_I2C_MUX_PINCTRL=y CONFIG_I2C_DESIGNWARE_PLATFORM=y +CONFIG_I2C_EXYNOS5=y CONFIG_I2C_MV64XXX=y CONFIG_I2C_SIRF=y CONFIG_I2C_TEGRA=y @@ -210,6 +215,7 @@ CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_SPI=y CONFIG_MFD_MAX8907=y +CONFIG_MFD_SEC_CORE=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y @@ -220,6 +226,8 @@ CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_PALMAS=y +CONFIG_REGULATOR_S2MPS11=y +CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65090=y @@ -274,12 +282,16 @@ CONFIG_MMC_ARMMMCI=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ESDHC_IMX=y CONFIG_MMC_SDHCI_TEGRA=y +CONFIG_MMC_SDHCI_S3C=y CONFIG_MMC_SDHCI_DOVE=y CONFIG_MMC_SDHCI_SPEAR=y +CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_SDHCI_BCM_KONA=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y CONFIG_MMC_MVSDIO=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_EXYNOS=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_HIGHBANK_MC=y -- 1.8.2.1.339.g52a3e01 -- 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 v5 5/5] arm: exynos: Add MCPM call-back functions
On 05/27/14 20:39, Kukjin Kim wrote:
Arnd Bergmann wrote:
On Monday 05 May 2014, Abhilash Kesavan wrote:
+static const struct mcpm_platform_ops exynos_power_ops = {
+ .power_up = exynos_power_up,
+ .power_down = exynos_power_down,
+ .power_down_finish = exynos_power_down_finish,
+};
I'm getting a build error in linux-next because there is
no .power_down_finish
member in mcpm_platform_ops here.
Yeah, commit 166aaf39 (ARM: 8029/1: mcpm: Rename the power_down_finish()
functions to be less confusing) changed the name to
wait_for_cpu_powerdown...
So need to change it accordingly...
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 1ac618c..34c4e6f 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -235,7 +235,7 @@ static void exynos_power_down(void)
/* Not dead at this point? Let our caller cope. */
}
-static int exynos_power_down_finish(unsigned int cpu, unsigned int cluster)
+static int exynos_wait_for_powerdown(unsigned int cpu, unsigned int
cluster)
{
unsigned int tries = 100;
unsigned int cpunr = cpu + (cluster * EXYNOS5420_CPUS_PER_CLUSTER);
@@ -261,7 +261,7 @@ static int exynos_power_down_finish(unsigned int cpu,
unsigned int cluster)
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
- .power_down_finish = exynos_power_down_finish,
+ .wait_for_powerdown = exynos_wait_for_powerdown,
};
static void __init exynos_mcpm_usage_count_init(void)
Arnd,
Fixed with above patch.
So I hope it should be fine with tomorrow -next tree.
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] ARM: EXYNOS: Use wfi macro in platform_do_lowpower
On 05/23/14 15:13, Leela Krishna Amudala wrote: Hi Kgene, Hi, On Fri, May 23, 2014 at 12:31 AM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 05/22/2014 09:57 AM, Leela Krishna Amudala wrote: This patch is originally based on commit b3377d186572 (ARM: 7064/1: vexpress: Use wfi macro in platform_do_lowpower.) Current Exynos CPU hotplug code includes a hardcoded WFI instruction, in ARM encoding. When the kernel is compiled in Thumb-2 mode, this is invalid and causes the machine to hang hard when a CPU is offlined. Use wfi macro instead of the hardcoded WFI instruction. Signed-off-by: Leela Krishna Amudalaleela.kris...@linaro.org Acked-by: Daniel Lezcanodaniel.lezc...@linaro.org Can you please take action on this patch. 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 1/5] ARM: dts: Enable RTC node on Origen boards
On 05/26/14 12:29, Sachin Kamat wrote:
On 23 May 2014 11:38, Sachin Kamatsachin.ka...@linaro.org wrote:
Enabled RTC node on Origen 4210 and 4412 boards.
Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts |4
arch/arm/boot/dts/exynos4412-origen.dts |4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f7ea21..95efb1189cf0 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = okay;
+ };
+
tmu@100C {
status = okay;
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e2c0dcab4d81..934fe7ecca7e 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = okay;
+ };
+
pinctrl@1100 {
keypad_rows: keypad-rows {
samsung,pins = gpx2-0, gpx2-1, gpx2-2;
--
1.7.9.5
Kukjin,
The patches in this series are really simple and do not want them to
wait for another
cycle. Please review and send them with your next pull request for
3.16. Also please
look at the 2 patches related to secondary cpu boot sent by Tushar.
Applied, but I'm not sure this can be sent to upstream in this time, I
will try to do it though ;-) Because already queued a bunch of exynos
stuff for arm-soc and this is not really critical at this moment?...
Anyway 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: exynos4412: powerdomain issues with HDMI PHY and VP
Tomasz Figa tomasz.f...@gmail.com writes: Hi Tobias, First of all, big thanks for investigating this issue. Hopefully we can have it fixed in upstream soon. I've added Tomasz Stanislawski to CC list, as he's been doing some work to enable HDMI support on Exynos4 using Exynos DRM. On 24.05.2014 22:45, Tobias Jakobi wrote: Hello, I'm still working on getting HDMI output on my ODROID-X2 board (based on Exynos4412 Prime) working. My tree is a 3.15-rc6 with some patches on top to get it boot on the board. You can find the tree here: https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.15.y Here is the DTS: https://github.com/tobiasjakobi/linux-odroid/blob/odroid-3.15.y/arch/arm/boot/dts/exynos4412-odroidx2.dts I encountered two issues with powerdomains. On related to HDMI PHY and the other one related to the VP (video processor). The pd the mixer is in, is currently set to pd_tv. I can't seem to specify multiple powerdomains for one device. However the PHY seems to need both TV and LCD0 pd to function properly. We've discovered this issue too. Unfortunately the Linux implementation of generic power domain core (genpd) doesn't support multiple power domains per device, so we ended up with a hack in our internal tree. Generic power domain bindings aren't going to help too much, because even though they account for this, the implementation will use only the first domain. I have CC'ed Rafael, Kevin and Ulf, as they might have some ideas how to solve this. Hmm, this seems a bit strange. How is this implemented in hardware? It seems rather unlikely that the same IP block is getting power from two different power rails. So I don't think what you really want is to have the device modeled in 2 power domains. Rather, I suspect there's some functional dependency going on that's not directly a function of the power domain itself. Taking a wild shot in the dark, it wouldn't be too surprising if the IP block in question depends on a clock coming from a device in another power domain? Since this sounds display related, is the pixel clock required coming from an IP block in the other power domain? If it's something like a clock dependency, then that needs to be modeled so what when the clock is enabled, the power domain containg the device providing that clock cannot be shut down. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exynos4412: powerdomain issues with HDMI PHY and VP
On 27.05.2014 18:49, Kevin Hilman wrote: Tomasz Figa tomasz.f...@gmail.com writes: Hi Tobias, First of all, big thanks for investigating this issue. Hopefully we can have it fixed in upstream soon. I've added Tomasz Stanislawski to CC list, as he's been doing some work to enable HDMI support on Exynos4 using Exynos DRM. On 24.05.2014 22:45, Tobias Jakobi wrote: Hello, I'm still working on getting HDMI output on my ODROID-X2 board (based on Exynos4412 Prime) working. My tree is a 3.15-rc6 with some patches on top to get it boot on the board. You can find the tree here: https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.15.y Here is the DTS: https://github.com/tobiasjakobi/linux-odroid/blob/odroid-3.15.y/arch/arm/boot/dts/exynos4412-odroidx2.dts I encountered two issues with powerdomains. On related to HDMI PHY and the other one related to the VP (video processor). The pd the mixer is in, is currently set to pd_tv. I can't seem to specify multiple powerdomains for one device. However the PHY seems to need both TV and LCD0 pd to function properly. We've discovered this issue too. Unfortunately the Linux implementation of generic power domain core (genpd) doesn't support multiple power domains per device, so we ended up with a hack in our internal tree. Generic power domain bindings aren't going to help too much, because even though they account for this, the implementation will use only the first domain. I have CC'ed Rafael, Kevin and Ulf, as they might have some ideas how to solve this. Hmm, this seems a bit strange. How is this implemented in hardware? It seems rather unlikely that the same IP block is getting power from two different power rails. So I don't think what you really want is to have the device modeled in 2 power domains. Rather, I suspect there's some functional dependency going on that's not directly a function of the power domain itself. Taking a wild shot in the dark, it wouldn't be too surprising if the IP block in question depends on a clock coming from a device in another power domain? Since this sounds display related, is the pixel clock required coming from an IP block in the other power domain? If it's something like a clock dependency, then that needs to be modeled so what when the clock is enabled, the power domain containg the device providing that clock cannot be shut down. Unfortunately we don't have any more detailed information about this right now. This dependency is not described in documentation and was discovered experimentally. Right now I'm on holidays, so I won't be able to get any details about this, but Marek and Tomasz S. might be able to come up with something. 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 v11 0/3] Exynos 5410 support
Tarek Dakhran t.dakh...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Samsung Linux Kernel (branch: for-next, commit: 97eae6c Merge branch 'v3.16-next/multiplatform' into for-next) Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) 2) Exynos 5410 reference board (multi_v7_defconfig) 3) Odroid-XU board (exynos_defconfig) 4) Odroid-XU board (multi_v7_defconfig) Tested-by: Kevin Hilman khil...@linaro.org FYI, I boot tested this on an odroid-xu (exynos_defconfig and multi_v7_defconfig.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/3] Exynos 5410 support
Kevin Hilman khil...@linaro.org writes: Tarek Dakhran t.dakh...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Samsung Linux Kernel (branch: for-next, commit: 97eae6c Merge branch 'v3.16-next/multiplatform' into for-next) Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) 2) Exynos 5410 reference board (multi_v7_defconfig) 3) Odroid-XU board (exynos_defconfig) 4) Odroid-XU board (multi_v7_defconfig) Tested-by: Kevin Hilman khil...@linaro.org FYI, I boot tested this on an odroid-xu (exynos_defconfig and multi_v7_defconfig.) Oops, I may have spoke to soon. There seem to be some problems with multi_v7_defconfig. Applying this series directly on the commit mentioned above and testing, it works just fine using multi_v7_defconfig. However, if I directly test the current contents of the samsung for-next branch (where this series has been merged) it no longer boots on the odroid-xu. A quick diff shows that there are some other changes to multi_v7_defconfig in the samsung/for-next branch that may be causing problems here. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/3] Exynos 5410 support
Hi, On Tue, May 27, 2014 at 9:44 PM, Kevin Hilman khil...@linaro.org wrote: Kevin Hilman khil...@linaro.org writes: Tarek Dakhran t.dakh...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Samsung Linux Kernel (branch: for-next, commit: 97eae6c Merge branch 'v3.16-next/multiplatform' into for-next) Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) 2) Exynos 5410 reference board (multi_v7_defconfig) 3) Odroid-XU board (exynos_defconfig) 4) Odroid-XU board (multi_v7_defconfig) Tested-by: Kevin Hilman khil...@linaro.org FYI, I boot tested this on an odroid-xu (exynos_defconfig and multi_v7_defconfig.) Oops, I may have spoke to soon. There seem to be some problems with multi_v7_defconfig. Applying this series directly on the commit mentioned above and testing, it works just fine using multi_v7_defconfig. Thank you for testing. However, if I directly test the current contents of the samsung for-next branch (where this series has been merged) it no longer boots on the odroid-xu. A quick diff shows that there are some other changes to multi_v7_defconfig in the samsung/for-next branch that may be causing problems here. Yes. Right you are. There is no ARCH_EXYNOS defined in multi_v7_defconfig at current state (branch: for-next commit: ca610da Merge branch 'v3.16-next/dt-samsung-3' into for-next). So booting kernel on 5410 SoC is not possible with multi_v7_defconfig. Please use exynos_defconfig. Kevin Best regards, Tarek -- 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 13/18] ARM: dts: s6e3fa0: add DT bindings
On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote: 2014-05-27 16:53 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote: Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Then the command mode timings aren't a property of the panel at all. Then the video mode timings aren't also a property of the panel. Which interface mipi and display controller should use would be decided by lcd panel type: display controller can use i80 interface based lcd panel, and also mipi controller can use i80 interface based lcd panel. In here, the only difference is that lcd panel receives packets, which includes video data or command data, packed with mipi protocol via lane lines or receives video data or command data via parallel lines. And the below is LCD types, RGB interface panel. i80 interface panel. MIPI based RGB interface panel. MIPI based i80 interface panel. RGB interface also is called video mode, and i80 interface also is called cpu mode. In case of omap SoC, it is also called Smart panel. i80 interface is just one of LCD types. So I think this interface timings should be handled by frameworks related to mode in same way as RGB interface. LCD is a display technology, it has nothing to do with the interface. My point is that from Andrzej's description, and in fact from this patch series in general, the S6E3FA0 panel is a DSI panel. Associating timings that are i80 specific to it is therefore wrong. Consider for instance what would happen if somebody were to use the same panel on some other device (connected to a DSI controller). If you specify i80 timings for the panel then the new device won't know what to do with them because it expects DSI-related timings. Let me try to summarize the above to make sure we're all on the same page: - FIMD is a display controller that can be configured to either send RGB data or i80 data - DSIM takes either RGB as input and outputs DSI (video mode) or i80 as input and outputs DSI (command mode) In both cases the panel is connected to DSIM and it takes DSI as input, because it is a DSI panel (it doesn't understand RGB or i80). The panel needs to describe the properties of the DSI interface so that DSIM can be configured appropriately. DSIM in turn works as a bridge or encoder that converts RGB or i80 to DSI (video or command mode). So it makes no sense to describe the i80 timings for the panel because it has nothing to do with i80. Instead the DSIM is the hardware that needs to specify the i80 timings, so that FIMD can be configured to generate the timings that DSIM needs. Thierry pgpKJfcfCUIIW.pgp Description: PGP signature
Re: [PATCH v6 3/7] arm64: Add a description on 48-bit address space with 4KB pages
On Mon, May 12, 2014 at 06:40:44PM +0900, Jungseok Lee wrote: This patch adds memory layout and translation lookup information about 48-bit address space with 4K pages. The description is based on 4 levels of translation tables. Cc: Catalin Marinas catalin.mari...@arm.com Cc: Steve Capper steve.cap...@linaro.org Signed-off-by: Jungseok Lee jays@samsung.com Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com Acked-by: Kukjin Kim kgene@samsung.com --- Looks reasonable to me: Acked-by: Christoffer Dall christoffer.d...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/3] Exynos 5410 support
On 27.05.2014 22:17, Tarek Dakhran wrote: Hi, On Tue, May 27, 2014 at 9:44 PM, Kevin Hilman khil...@linaro.org wrote: Kevin Hilman khil...@linaro.org writes: Tarek Dakhran t.dakh...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Samsung Linux Kernel (branch: for-next, commit: 97eae6c Merge branch 'v3.16-next/multiplatform' into for-next) Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig) 2) Exynos 5410 reference board (multi_v7_defconfig) 3) Odroid-XU board (exynos_defconfig) 4) Odroid-XU board (multi_v7_defconfig) Tested-by: Kevin Hilman khil...@linaro.org FYI, I boot tested this on an odroid-xu (exynos_defconfig and multi_v7_defconfig.) Oops, I may have spoke to soon. There seem to be some problems with multi_v7_defconfig. Applying this series directly on the commit mentioned above and testing, it works just fine using multi_v7_defconfig. Thank you for testing. However, if I directly test the current contents of the samsung for-next branch (where this series has been merged) it no longer boots on the odroid-xu. A quick diff shows that there are some other changes to multi_v7_defconfig in the samsung/for-next branch that may be causing problems here. Yes. Right you are. There is no ARCH_EXYNOS defined in multi_v7_defconfig at current state (branch: for-next commit: ca610da Merge branch 'v3.16-next/dt-samsung-3' into for-next). So booting kernel on 5410 SoC is not possible with multi_v7_defconfig. Please use exynos_defconfig. I wonder if this patch isn't maybe the missing part: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/32414 Olof asked Kukjin to separate it from his pull requests, so it can be applied directly to ARM SoC tree to avoid conflicts. 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
[GIT PULL 4th 1/2 v2] Samsung Exynos multiplatform for 3.16
Hi, I sorted out the branch as per Olof's suggestion and sending v2 pull-request for that (4th pull-request). Also sent multi_v7_defconfig update patch to a...@kernel.org. Please pull this for 3.16. If any problems, please kindly let me know. Thanks, Kukjin The following changes since commit dfacdfef06090ca0c131f45dfd3f3ca3452a8ed3: Merge branch 'v3.16-next/dt-samsung' into v3.16-next/multiplatform (2014-05-26 06:19:01 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/exynos-multiplatform-v2 for you to fetch changes up to f7b163d16d412e14be49f47240ffaba328aaab6c: cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORM (2014-05-27 23:52:50 +0900) Exynos mutiplatform support for 3.16 Here is enabling the exynos platform as part of a multiplatform kernel. This is including ARCH_EXYNOS related Kconfig entries consolidation. And fixes exynos-cpufreq driver compilation with ARCH_MULTIPLATFORM. Note that this is based on tags/exynos-soc. And tags/samsung-dt, tags/samsung-clk are merged on top of that. Arnd Bergmann (1): ARM: EXYNOS: Enable multi-platform build support Sachin Kamat (1): ARM: EXYNOS: Consolidate Kconfig entries Tomasz Figa (1): cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORM arch/arm/Kconfig | 20 - arch/arm/mach-exynos/Kconfig | 81 arch/arm/mach-exynos/Makefile| 2 + arch/arm/plat-samsung/Makefile | 3 ++ drivers/cpufreq/Kconfig.arm | 6 +-- drivers/cpufreq/exynos-cpufreq.c | 2 - drivers/cpufreq/exynos-cpufreq.h | 30 +++-- drivers/cpufreq/exynos4210-cpufreq.c | 39 ++--- drivers/cpufreq/exynos4x12-cpufreq.c | 40 +++--- drivers/cpufreq/exynos5250-cpufreq.c | 43 +++ 10 files changed, 151 insertions(+), 115 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 2/3] clk: exynos5410: register clocks using common clock framework
Quoting Tarek Dakhran (2014-05-25 20:23:32)
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 45 +
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos5410.c | 209
include/dt-bindings/clock/exynos5410.h | 33
4 files changed, 288 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/exynos5410-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..aeab635
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,45 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be samsung,exynos5410-clock
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+
+There is clock that is generated outside the SoC. It
+is expected that it is defined using standard clock bindings
+with following clock-output-name:
+
+ - fin_pll - PLL input clock from XXTI
Does fin_pll feed into the exynos5410-clock controller? If so, should
the example clock-controller node below have a clocks and clock-names
property?
Otherwise patch looks good.
Regards,
Mike
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x1001 {
+ compatible = samsung,exynos5410-clock;
+ reg = 0x1001 0x3;
+ #clock-cells = 1;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the
clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@12C2 {
+ compatible = samsung,exynos4210-uart;
+ reg = 0x12C0 0x100;
+ interrupts = 0 51 0;
+ clocks = clock CLK_UART0, clock CLK_SCLK_UART0;
+ clock-names = uart, clk_uart_baud0;
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 25646c6..69e8177 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_EXYNOS3250)+= clk-exynos3250.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o
+obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c
new file mode 100644
index 000..c9505ab
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran t.dakh...@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.
+ *
+ * Common Clock Framework support for Exynos5410 SoC.
+*/
+
+#include dt-bindings/clock/exynos5410.h
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+
+#include clk.h
+
+#define APLL_LOCK 0x0
+#define APLL_CON0 0x100
+#define CPLL_LOCK 0x10020
+#define CPLL_CON0 0x10120
+#define MPLL_LOCK 0x4000
+#define MPLL_CON0 0x4100
+#define BPLL_LOCK 0x20010
+#define BPLL_CON0 0x20110
+#define KPLL_LOCK 0x28000
+#define KPLL_CON0 0x28100
+
+#define SRC_CPU0x200
+#define DIV_CPU0 0x500
+#define SRC_CPERI1 0x4204
+#define DIV_TOP0 0x10510
+#define DIV_TOP1 0x10514
+#define DIV_FSYS1 0x1054c
+#define DIV_FSYS2 0x10550
+#define DIV_PERIC0 0x10558
+#define SRC_TOP0 0x10210
+#define
Re: [PATCH v11 2/3] clk: exynos5410: register clocks using common clock framework
Hi Mike,
On Wed, May 28, 2014 at 4:41 AM, Mike Turquette mturque...@linaro.org wrote:
Quoting Tarek Dakhran (2014-05-25 20:23:32)
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 45 +
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos5410.c | 209
include/dt-bindings/clock/exynos5410.h | 33
4 files changed, 288 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/exynos5410-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..aeab635
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,45 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be samsung,exynos5410-clock
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+
+There is clock that is generated outside the SoC. It
+is expected that it is defined using standard clock bindings
+with following clock-output-name:
+
+ - fin_pll - PLL input clock from XXTI
Does fin_pll feed into the exynos5410-clock controller? If so, should
the example clock-controller node below have a clocks and clock-names
property?
fin_pll does not feed into exynos5410-clock controller, but into mct do.
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..3839c26
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,206 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * 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 skeleton.dtsi
+#include dt-bindings/clock/exynos5410.h
+
+/ {
+ compatible = samsung,exynos5410, samsung,exynos5;
+ interrupt-parent = gic;
[snip]
+ mct: mct@101C {
+ compatible = samsung,exynos4210-mct;
+ reg = 0x101C 0xB00;
+ interrupt-parent = interrupt_map;
+ interrupts = 0, 1, 2, 3,
+ 4, 5, 6, 7,
+ 8, 9, 10, 11;
+ clocks = fin_pll, clock CLK_MCT;
+ clock-names = fin_pll, mct;
+
+ interrupt_map: interrupt-map {
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 combiner 23 3,
+ 1 combiner 23 4,
+ 2 combiner 25 2,
+ 3 combiner 25 3,
+ 4 gic 0 120 0,
+ 5 gic 0 121 0,
+ 6 gic 0 122 0,
+ 7 gic 0 123 0,
+ 8 gic 0 128 0,
+ 9 gic 0 129 0,
+ 10 gic 0 130 0,
+ 11 gic 0 131 0;
+ };
+ };
+
That's why I documented fin_pll. Should I add mct binding example to
documentation too?
Best regards,
Tarek
--
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/5] ARM: dts: Enable RTC node on Origen boards
Hi Kukjin,
On 27 May 2014 21:09, Kukjin Kim kgene@samsung.com wrote:
On 05/26/14 12:29, Sachin Kamat wrote:
On 23 May 2014 11:38, Sachin Kamatsachin.ka...@linaro.org wrote:
Enabled RTC node on Origen 4210 and 4412 boards.
Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts |4
arch/arm/boot/dts/exynos4412-origen.dts |4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f7ea21..95efb1189cf0 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = okay;
+ };
+
tmu@100C {
status = okay;
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e2c0dcab4d81..934fe7ecca7e 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = okay;
+ };
+
pinctrl@1100 {
keypad_rows: keypad-rows {
samsung,pins = gpx2-0, gpx2-1, gpx2-2;
--
1.7.9.5
Kukjin,
The patches in this series are really simple and do not want them to
wait for another
cycle. Please review and send them with your next pull request for
3.16. Also please
look at the 2 patches related to secondary cpu boot sent by Tushar.
Applied, but I'm not sure this can be sent to upstream in this time, I will
try to do it though ;-) Because already queued a bunch of exynos stuff for
arm-soc and this is not really critical at this moment?...
Thanks for applying. These patches are not critical. However there are 2 more
patches posted by Tushar which are critical (have already sent pings for that,
will send once again separately for your reference). You may send these patches
along with those.
[PATCH V2 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
http://www.spinics.net/lists/linux-samsung-soc/msg31258.html
[PATCH RESEND 2/2] ARM: dts: Add secure firmware support for Arndale-octa
http://www.spinics.net/lists/linux-samsung-soc/msg31259.html
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
Almost all Exynos-series of SoCs that run in secure mode don't need additional offset for every CPU, with Exynos4412 being the only exception. Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). While at it, fix the coding style (space around *). Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- arch/arm/mach-exynos/firmware.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c index eb91d2350f8c..e8797bb78871 100644 --- a/arch/arm/mach-exynos/firmware.c +++ b/arch/arm/mach-exynos/firmware.c @@ -57,8 +57,13 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr) boot_reg = sysram_ns_base_addr + 0x1c; - if (!soc_is_exynos4212() !soc_is_exynos3250()) - boot_reg += 4*cpu; + /* +* Almost all Exynos-series of SoCs that run in secure mode don't need +* additional offset for every CPU, with Exynos4412 being the only +* exception. +*/ + if (soc_is_exynos4412()) + boot_reg += 4 * cpu; __raw_writel(boot_addr, boot_reg); return 0; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 Resend 2/2] ARM: dts: Add secure firmware support for Arndale-octa
From: Tushar Behera tushar.beh...@linaro.org
Arndale-Octa board is always configured to work with trustzone
firmware binary. Added DTS node entry to enable this support.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 6ee8149fd5c4..434fd9d3e09d 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -26,6 +26,11 @@
bootargs = console=ttySAC3,115200;
};
+ firmware@02073000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x02073000 0x1000;
+ };
+
fixed-rate-clocks {
oscclk {
compatible = samsung,exynos5420-oscclk;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: dts: Enable RTC node on Origen boards
On 28 May 2014 09:23, Sachin Kamat sachin.ka...@linaro.org wrote:
Hi Kukjin,
On 27 May 2014 21:09, Kukjin Kim kgene@samsung.com wrote:
On 05/26/14 12:29, Sachin Kamat wrote:
On 23 May 2014 11:38, Sachin Kamatsachin.ka...@linaro.org wrote:
Enabled RTC node on Origen 4210 and 4412 boards.
Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts |4
arch/arm/boot/dts/exynos4412-origen.dts |4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f7ea21..95efb1189cf0 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = okay;
+ };
+
tmu@100C {
status = okay;
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e2c0dcab4d81..934fe7ecca7e 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = okay;
+ };
+
pinctrl@1100 {
keypad_rows: keypad-rows {
samsung,pins = gpx2-0, gpx2-1, gpx2-2;
--
1.7.9.5
Kukjin,
The patches in this series are really simple and do not want them to
wait for another
cycle. Please review and send them with your next pull request for
3.16. Also please
look at the 2 patches related to secondary cpu boot sent by Tushar.
Applied, but I'm not sure this can be sent to upstream in this time, I will
try to do it though ;-) Because already queued a bunch of exynos stuff for
arm-soc and this is not really critical at this moment?...
Thanks for applying. These patches are not critical. However there are 2 more
patches posted by Tushar which are critical (have already sent pings for that,
will send once again separately for your reference). You may send these
patches
along with those.
[PATCH V2 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
http://www.spinics.net/lists/linux-samsung-soc/msg31258.html
[PATCH RESEND 2/2] ARM: dts: Add secure firmware support for Arndale-octa
http://www.spinics.net/lists/linux-samsung-soc/msg31259.html
Re-sent both the above patches once again after rebasing on your
latest for-next branch.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/6] add cpuidle support for Exynos5420
On 26 May 2014 15:59, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Chander, On 16.05.2014 10:03, Chander Kashyap wrote: Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg331100.html Changelog is in respective patches. Chander Kashyap (5): driver: cpuidle-big-little: add of_device_id structure arm: exynos: add generic function to calculate cpu number cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/exynos.c|4 +++- arch/arm/mach-exynos/mcpm-exynos.c | 36 ++ arch/arm/mach-exynos/regs-pmu.h |9 + drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c | 12 +++- 5 files changed, 60 insertions(+), 3 deletions(-) For the whole series, Reviewed-by: Tomasz Figa t.f...@samsung.com Thanks Tomasz. Dear Kukjin, Can you take these patches. Best regards, Tomasz -- with warm regards, Chander Kashyap -- 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/6] add cpuidle support for Exynos5420
Chander Kashyap wrote: On 26 May 2014 15:59, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Chander, On 16.05.2014 10:03, Chander Kashyap wrote: Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg331100.html Changelog is in respective patches. Chander Kashyap (5): driver: cpuidle-big-little: add of_device_id structure arm: exynos: add generic function to calculate cpu number cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/exynos.c|4 +++- arch/arm/mach-exynos/mcpm-exynos.c | 36 ++ arch/arm/mach-exynos/regs-pmu.h |9 + drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c | 12 +++- 5 files changed, 60 insertions(+), 3 deletions(-) For the whole series, Reviewed-by: Tomasz Figa t.f...@samsung.com Thanks Tomasz. Dear Kukjin, Can you take these patches. When I looked at this series quickly, looks good to me but I need to get ack from cpuidle maintainer Rafael or Daniel. 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 v11 2/3] clk: exynos5410: register clocks using common clock framework
Mike Turquette wrote: Quoting Tarek Dakhran (2014-05-25 20:23:32) The EXYNOS5410 clocks are statically listed and registered using the Samsung specific common clock helper functions. Signed-off-by: Tarek Dakhran t.dakh...@samsung.com Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com --- .../devicetree/bindings/clock/exynos5410-clock.txt | 45 + drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos5410.c | 209 include/dt-bindings/clock/exynos5410.h | 33 4 files changed, 288 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5410- clock.txt create mode 100644 drivers/clk/samsung/clk-exynos5410.c create mode 100644 include/dt-bindings/clock/exynos5410.h diff --git a/Documentation/devicetree/bindings/clock/exynos5410- clock.txt b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt new file mode 100644 index 000..aeab635 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt @@ -0,0 +1,45 @@ +* Samsung Exynos5410 Clock Controller + +The Exynos5410 clock controller generates and supplies clock to various +controllers within the Exynos5410 SoC. + +Required Properties: + +- compatible: should be samsung,exynos5410-clock + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5410.h header and can be used in device +tree sources. + +External clock: + +There is clock that is generated outside the SoC. It +is expected that it is defined using standard clock bindings +with following clock-output-name: + + - fin_pll - PLL input clock from XXTI Does fin_pll feed into the exynos5410-clock controller? If so, should the example clock-controller node below have a clocks and clock-names property? Well, it is fixed clocks and generated outside of the SoC...so maybe the properties are not required? BTW, I've applied this series with Tomasz Figa's reviewed tag and sent out to arm-soc today so if any concerns on this, please let me know immediately. Otherwise patch looks good. 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 13/18] ARM: dts: s6e3fa0: add DT bindings
On 2014년 05월 28일 05:21, Thierry Reding wrote: On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote: 2014-05-27 16:53 GMT+09:00 Thierry Reding thierry.red...@gmail.com: On Tue, May 27, 2014 at 08:28:52AM +0200, Andrzej Hajda wrote: Hi Thierry, On 05/26/2014 03:41 PM, Thierry Reding wrote: On Wed, May 21, 2014 at 01:43:05PM +0900, YoungJun Cho wrote: This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt You're totally confusing me here. Half of this patch series is about adding i80 support to Exynos FIMD, and then you go and add what is apparently a DSI peripheral driver here that's supposed to be used by this new i80 support. Nothing I've been able to dig up indicates that i80 or DSI are in anyway related. FIMD can produce parallel RGB output or command mode in i80 style output via parallel lines. DSIM can accept parallel RGB stream in this case it produces MIPI DSI video mode signal or it can accept i80 and in this case it translates it to MIPI DSI command mode. Then the command mode timings aren't a property of the panel at all. Then the video mode timings aren't also a property of the panel. Which interface mipi and display controller should use would be decided by lcd panel type: display controller can use i80 interface based lcd panel, and also mipi controller can use i80 interface based lcd panel. In here, the only difference is that lcd panel receives packets, which includes video data or command data, packed with mipi protocol via lane lines or receives video data or command data via parallel lines. And the below is LCD types, RGB interface panel. i80 interface panel. MIPI based RGB interface panel. MIPI based i80 interface panel. RGB interface also is called video mode, and i80 interface also is called cpu mode. In case of omap SoC, it is also called Smart panel. i80 interface is just one of LCD types. So I think this interface timings should be handled by frameworks related to mode in same way as RGB interface. LCD is a display technology, it has nothing to do with the interface. My point is that from Andrzej's description, and in fact from this patch series in general, the S6E3FA0 panel is a DSI panel. Associating timings that are i80 specific to it is therefore wrong. Consider for instance what would happen if somebody were to use the same panel on some other device (connected to a DSI controller). If you specify i80 timings for the panel then the new device won't know what to do with them because it expects DSI-related timings. Let me try to summarize the above to make sure we're all on the same page: - FIMD is a display controller that can be configured to either send RGB data or i80 data - DSIM takes either RGB as input and outputs DSI (video mode) or i80 as input and outputs DSI (command mode) In both cases the panel is connected to DSIM and it takes DSI as input, because it is a DSI panel (it doesn't understand RGB or i80). The panel needs to describe the properties of the DSI interface so that DSIM can be configured appropriately. DSIM in turn works as a bridge or encoder that converts RGB or i80 to DSI (video or command mode). So it makes no sense to describe the i80 timings for the panel because it has nothing to do with i80. Instead the DSIM is the hardware that needs to specify the i80 timings, so that FIMD can be configured to generate the timings that DSIM needs. CPU interface MIPI lane FIMD --- DSIM - LCD Panel Hmm... reasonable. So your point is that command mode timing should be placed in fimd device node, not panel device node? And panel device node should provide only a property that DSIM driver can set LCD mode properly to i80 or rgb interface mode, and also FIMD driver can set LCD mode to i80 or rgb interface mode. Is there my missing point? And in case of Exynos, now video timing property is also placed in panel device node so it needs to move to fimd device node. Andrzej, do you have other opinion? I have looked into dts files for other SoC and In most SoC, it seems that display controller node has video timing property, not panel node. Thierry's pointing seems reasonable to me. Thanks, Inki Dae Thierry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/4] mmc: host: add slot argument to mmc_of_parse
From: Ludovic Desroches ludovic.desroc...@atmel.com
Some hosts manage several slots. In these case information such as the
bus width, chip detect and others are into the slot node. So we have to
parse child node. If not NULL, slot node will be used instead of the
device node.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Acked-by: Seungwon Jeon tgih@samsung.com
---
Changelog V3:
- None.
Changelog V2:
- Fix the typo.
drivers/mmc/core/host.c | 13 +
include/linux/mmc/host.h | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 95cceae..0f677b3 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -298,15 +298,17 @@ static inline void mmc_host_clk_sysfs_init(struct
mmc_host *host)
#endif
/**
- * mmc_of_parse() - parse host's device-tree node
+ * __mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
+ * @slot : some device provide several slots so the node to parse
+ * is not the host one.
*
* To keep the rest of the MMC subsystem unaware of whether DT has been
* used to to instantiate and configure this host instance or not, we
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-int mmc_of_parse(struct mmc_host *host)
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot)
{
struct device_node *np;
u32 bus_width;
@@ -317,7 +319,10 @@ int mmc_of_parse(struct mmc_host *host)
if (!host-parent || !host-parent-of_node)
return 0;
- np = host-parent-of_node;
+ if (slot)
+ np = slot;
+ else
+ np = host-parent-of_node;
/* bus-width is translated to MMC_CAP_*_BIT_DATA flags */
if (of_property_read_u32(np, bus-width, bus_width) 0) {
@@ -459,7 +464,7 @@ out:
return ret;
}
-EXPORT_SYMBOL(mmc_of_parse);
+EXPORT_SYMBOL(__mmc_of_parse);
/**
* mmc_alloc_host - initialise the per-host structure.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7960424..c62af91 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -372,7 +372,15 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
-int mmc_of_parse(struct mmc_host *host);
+int __mmc_of_parse(struct mmc_host *host, struct device_node *slot);
+/*
+ * mmc_of_parse - parse host's device-tree node
+ * @host: host whose node should be parsed.
+ */
+static inline int mmc_of_parse(struct mmc_host *host)
+{
+ return __mmc_of_parse(host, NULL);
+}
static inline void *mmc_priv(struct mmc_host *host)
{
--
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
[PATCHv3 2/4] mmc: dw_mmc: use the __mmc_of_parse to parse the slot node
dw-mmc controller has the multiple slot.
Then it needs to parse the property for each slot.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changelog V3:
- Fix typo.
- Maintained the dw_mci_of_quirks().
Changelog V2:
- None
drivers/mmc/host/dw_mmc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..3285bdd 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1015,12 +1015,11 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
{
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
- struct dw_mci_board *brd = slot-host-pdata;
struct dw_mci *host = slot-host;
int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
- if (brd-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ if (slot-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
present = 1;
else if (!IS_ERR_VALUE(gpio_cd))
present = gpio_cd;
@@ -2010,6 +2009,9 @@ static struct dw_mci_of_slot_quirks {
{
.quirk = disable-wp,
.id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ }, {
+ .quirk = broken-cd,
+ .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
},
};
@@ -2088,7 +2090,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
if (host-pdata-caps2)
mmc-caps2 = host-pdata-caps2;
- mmc_of_parse(mmc);
+ __mmc_of_parse(mmc, dw_mci_of_find_slot_node(host-dev, slot-id));
if (host-pdata-blk_settings) {
mmc-max_segs = host-pdata-blk_settings-max_segs;
@@ -2234,12 +2236,7 @@ static inline bool dw_mci_ctrl_all_reset(struct dw_mci
*host)
static struct dw_mci_of_quirks {
char *quirk;
int id;
-} of_quirks[] = {
- {
- .quirk = broken-cd,
- .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
- },
-};
+} of_quirks[] = {};
static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
{
--
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
[PATCHv3 4/4] ARM: dts: replace the slot property into slot sub-node for dwmmc.
dw-mmc controller can support the multiple slot.
So each slot's property can be difference.
And support-highspeed property in dw-mmc is deprecated.
support-highspeed property can be replaced to cap-sd/mmc-highspeed.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changelog V3:
- Merge [PATCH 2/5] mmc: dw_mmc: rmove the supports-highspeed
property
Changelog V2:
- None
.../devicetree/bindings/mmc/exynos-dw-mshc.txt |5 +++--
.../devicetree/bindings/mmc/k3-dw-mshc.txt |3 ++-
.../devicetree/bindings/mmc/synopsys-dw-mshc.txt |6 --
arch/arm/boot/dts/exynos4412-odroidx.dts |4 ++--
arch/arm/boot/dts/exynos4412-origen.dts|4 ++--
arch/arm/boot/dts/exynos4412-trats2.dts|6 +++---
arch/arm/boot/dts/exynos5250-arndale.dts |6 +++---
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 10 +-
arch/arm/boot/dts/exynos5250-smdk5250.dts |6 +++---
arch/arm/boot/dts/exynos5420-arndale-octa.dts |6 +++---
arch/arm/boot/dts/exynos5420-smdk5420.dts |4 ++--
arch/arm/boot/dts/rk3066a-bqcurie2.dts |2 +-
arch/arm/boot/dts/socfpga_arria5.dtsi |5 +++--
arch/arm/boot/dts/socfpga_cyclone5.dtsi|5 +++--
arch/arm/boot/dts/socfpga_vt.dts |5 +++--
15 files changed, 42 insertions(+), 35 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index 532b1d4..41cc703 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -69,8 +69,6 @@ Example:
dwmmc0@1220 {
num-slots = 1;
- supports-highspeed;
- broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
@@ -85,5 +83,8 @@ Example:
gpc1 2 2 3 3, gpc1 3 2 3 3,
gpc0 3 2 3 3, gpc0 4 2 3 3,
gpc0 5 2 3 3, gpc0 6 2 3 3;
+ broken-cd;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
};
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index b8653ea..b1844c5 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -34,7 +34,6 @@ Example:
num-slots = 1;
vmmc-supply = ldo12;
fifo-depth = 0x100;
- supports-highspeed;
pinctrl-names = default;
pinctrl-0 = sd_pmx_pins sd_cfg_func1 sd_cfg_func2;
slot@0 {
@@ -42,5 +41,7 @@ Example:
bus-width = 4;
disable-wp;
cd-gpios = gpio10 3 0;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
};
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 2d4a725..ff393ab 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -67,7 +67,8 @@ Optional properties:
* card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.
-* supports-highspeed: Enables support for high speed cards (up to 50MHz)
+* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to
50MHz)
+ (use cap-mmc-highspeed or cap-sd-highspeed
instead)
* broken-cd: as documented in mmc core bindings.
@@ -98,7 +99,6 @@ board specific portions as listed below.
clock-frequency = 4;
clock-freq-min-max = 40 2;
num-slots = 1;
- supports-highspeed;
broken-cd;
fifo-depth = 0x80;
card-detect-delay = 200;
@@ -107,5 +107,7 @@ board specific portions as listed below.
slot@0 {
reg = 0;
bus-width = 8;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 31db28a..fb2cd8d 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -45,8 +45,6 @@
status = okay;
num-slots = 1;
- supports-highspeed;
- broken-cd;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
[PATCHv3 3/4] mmc: dw_mmc: remove the supports-highspeed property.
Removed the parser for supports-highspeed. It can be parsed with cap-mmc-highsped or cap-sd-highspeed at mmc_of_parse(). Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/host/dw_mmc.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 3285bdd..34b5210 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -2281,9 +2281,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host) return ERR_PTR(ret); } - if (of_find_property(np, supports-highspeed, NULL)) - pdata-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - return pdata; } -- 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
