Re: [PATCH] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
Hello,
Krzysztof Kozlowski wrote:
> On 28.08.2015 10:48, Jaehoon Chung wrote:
>> On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
>>> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
Currently vmmc's property is wrong.
If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
(Card supply power and I/O Line supply Power.)
Signed-off-by: Jaehoon Chung
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ca7d168..4ddabfd 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -461,10 +461,10 @@
&mshc_0 {
pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
pinctrl-names = "default";
- vmmc-supply = <&ldo20_reg &buck8_reg>;
+ vmmc-supply = <&ldo20_reg>;
+ vqmmc-supply = <&buck8_reg>;
>>>
>>> Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
>>> so it should be VQMMC?
>>
>> If my schematics is right thing, buck8 is used LAN card power.
>> I will send after removing buck8_reg. how about?
>> Anyway, Thanks for pointing out. :)
>
> Removing this regulator from this node would effectively disable it.
> That could affect other components like LAN.
>
> Anyway before fixing the order I would prefer to find the right
> regulators used by MSHC node.
Please see this commit:
https://github.com/tobiasjakobi/linux-odroid/commit/113ffb92e0c7f58f15fe60b47d13eb2d65956d10
This was derived from private communication with Hardkernel.
I can't vouch for correctness though.
With best wishes,
Tobias
> Best regards,
> Krzysztof
>
>>
>> I don't know who this regulator applied. I have guessed that it used for
>> eMMC.
>> Sorry for guessing.
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> In the same time I can't find on schematics where BUCK8 goes...
>>>
>>> The SDHCI_2 node below looks good.
>>>
>>> Best regards,
>>> Krzysztof
>>>
mmc-pwrseq = <&emmc_pwrseq>;
status = "okay";
-
num-slots = <1>;
broken-cd;
card-detect-delay = <200>;
@@ -485,7 +485,8 @@
bus-width = <4>;
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
pinctrl-names = "default";
- vmmc-supply = <&ldo4_reg &ldo21_reg>;
+ vmmc-supply = <&ldo21_reg>;
+ vqmmc-supply = <&ldo4_reg>;
cd-gpios = <&gpk2 2 0>;
cd-inverted;
status = "okay";
>>>
>>>
>>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/44] [media] media: rename the function that create pad links
Em Wed, 26 Aug 2015 11:54:03 -0300 Mauro Carvalho Chehab escreveu: > Em Tue, 25 Aug 2015 12:55:41 -0600 > Shuah Khan escreveu: > > > On 08/23/2015 02:17 PM, Mauro Carvalho Chehab wrote: > > > Now that a link can be either between two different graph > > > objects, we'll need to add more functions to create links. > > > > Is this an incomplete sentence. Should it read: "either between > > two different graph objects or two pads" ? > > That would be redundant, as pad is a graph object ;) Renamed the patch description to: With the new API, a link can be either between two PADs or between an interface and an entity. So, we need to use a better name for the function that create links between two pads. So, rename the such function to media_create_pad_link(). No functional changes. This patch was created via this shell script: for i in $(find drivers/media -name '*.[ch]' -type f) $(find drivers/staging/media -name '*.[ch]' -type f) $(find include/ -name '*.h' -type f) ; do sed s,media_entity_create_link,media_create_pad_link,g <$i >a && mv a $i; done Signed-off-by: Mauro Carvalho Chehab Acked-by: Hans Verkuil Regards, Mauro > > > > > > So, rename the existing one that create links only between > > > two pads as media_create_pad_link(). > > > > > > > > No functional changes. > > > > > > This patch was created via this shell script: > > > for i in $(find drivers/media -name '*.[ch]' -type f) $(find > > > drivers/staging/media -name '*.[ch]' -type f) $(find include/ -name '*.h' > > > -type f) ; do sed s,media_entity_create_link,media_create_pad_link,g <$i > > > >a && mv a $i; done > > > > > > > Didn't want to experiment with Coccinelle?? :) > > I use Coccinelle, but only when I need more complex changes, as > Coccinelle may mangle with comments. > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > Acked-by: Hans Verkuil > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > Changes look good to me. After fixing the commit log: > > > > Acked-by: Shuah Khan > > > > thanks, > > -- Shuah > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" 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: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hi, On Friday, August 28, 2015 09:42:35 PM Krzysztof Kozlowski wrote: > W dniu 28.08.2015 o 17:35, Javier Martinez Canillas pisze: > > Hello Bartlomiej and Lorenzo, > > > > Thanks a lot for your explanations. > > > > On 08/27/2015 06:58 PM, Bartlomiej Zolnierkiewicz wrote: > > > >> If somebody wants to implement a separate Exynos542x/Exynos5800 > >> big.LITTLE cpuidle driver for them I see no problem with it and I'm > >> willing to help in maintaining it. > >> > > > > Ok, I'll see if I can take a look what is needed to implement a Exynos542x > > CPUidle > > driver. I'm quite busy with other stuff right now but I should be less busy > > in a > > couple of weeks. > > The only useful users of Exynos542x cpuidle would be Chromebooks. > Probably the same goes with suspend to RAM. Non-mobile devices could > leave without it. > > In the same time cpuidle and S2R would require a significant amount of > work. Testing would have to be performed on Chromebooks. I have doubts > it would work on Odroid XU3. > > I dug into S2R issues on Odroid XU3 and after fixing trivial imprecise > abort I don't have clue. It just dies somewhere in firmware/bootloader. > Vendor code has a lot more stuff related to suspend and testing it > one-by-one whether it fixes the issue is frustrating. > > Do we really need cpuidle or S2R on Exynos542x/5800? > > > > > Maybe is a little bit out of topic but since Anand also asked about CPUFreq > > support, > > are you planning on re-posting your "cpufreq: add generic cpufreq driver > > support > > for Exynos5250/5800 platforms" [0] series? > > That would be useful. Bartlomiej, do you have plans for continuing the work? Yes. It is still on my TODO but may take a while (1-2 weeks) before I find some time to actually do it. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-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: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
W dniu 28.08.2015 o 17:35, Javier Martinez Canillas pisze: > Hello Bartlomiej and Lorenzo, > > Thanks a lot for your explanations. > > On 08/27/2015 06:58 PM, Bartlomiej Zolnierkiewicz wrote: > >> If somebody wants to implement a separate Exynos542x/Exynos5800 >> big.LITTLE cpuidle driver for them I see no problem with it and I'm >> willing to help in maintaining it. >> > > Ok, I'll see if I can take a look what is needed to implement a Exynos542x > CPUidle > driver. I'm quite busy with other stuff right now but I should be less busy > in a > couple of weeks. The only useful users of Exynos542x cpuidle would be Chromebooks. Probably the same goes with suspend to RAM. Non-mobile devices could leave without it. In the same time cpuidle and S2R would require a significant amount of work. Testing would have to be performed on Chromebooks. I have doubts it would work on Odroid XU3. I dug into S2R issues on Odroid XU3 and after fixing trivial imprecise abort I don't have clue. It just dies somewhere in firmware/bootloader. Vendor code has a lot more stuff related to suspend and testing it one-by-one whether it fixes the issue is frustrating. Do we really need cpuidle or S2R on Exynos542x/5800? > > Maybe is a little bit out of topic but since Anand also asked about CPUFreq > support, > are you planning on re-posting your "cpufreq: add generic cpufreq driver > support > for Exynos5250/5800 platforms" [0] series? That would be useful. Bartlomiej, do you have plans for continuing the work? 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] clk: samsung: exynos7: Add required clock tree for UFS
Hi, On 08/28/2015 03:36 PM, Krzysztof Kozlowski wrote: 2015-08-28 18:28 GMT+09:00 Alim Akhtar : Adding required mux/div/gate clocks for UFS controller present on Exynos7. Signed-off-by: Alim Akhtar --- This patch has a dependency on [1] [1]-> https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg46122.html Hi, I just noticed that you did not send this and previous patches to proper mailing list and to all of maintainers. You missed linux-...@vger.kernel.org and Stephen Boyd. Please use script/get_maintainers. It will print all necessary addresses. Thanks for pointing this out, I will add them. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] clk: samsung: fix cpu clock's flags checking
CLK_CPU_HAS_DIV1 and CLK_CPU_NEEDS_DEBUG_ALT_DIV masks were
incorrectly used as a bit numbers. Fix it.
Tested on Exynos4210 based Origen board and on Exynos5250 based
Arndale board.
Cc: Tomasz Figa
Cc: Michael Turquette
Cc: Thomas Abraham
Fixes: ddeac8d96 ("clk: samsung: add infrastructure to register cpu clocks")
Reported-by: Dan Carpenter
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
Acked-by: Sylwester Nawrocki
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- added Reviewed-by, Acked-by and Fixes tags (no code changes)
Michael, please apply. Thank you.
drivers/clk/samsung/clk-cpu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index 7c1e1f5..2fe37f7 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -164,7 +164,7 @@ static int exynos_cpuclk_pre_rate_change(struct
clk_notifier_data *ndata,
* the values for DIV_COPY and DIV_HPM dividers need not be set.
*/
div0 = cfg_data->div0;
- if (test_bit(CLK_CPU_HAS_DIV1, &cpuclk->flags)) {
+ if (cpuclk->flags & CLK_CPU_HAS_DIV1) {
div1 = cfg_data->div1;
if (readl(base + E4210_SRC_CPU) & E4210_MUX_HPM_MASK)
div1 = readl(base + E4210_DIV_CPU1) &
@@ -185,7 +185,7 @@ static int exynos_cpuclk_pre_rate_change(struct
clk_notifier_data *ndata,
alt_div = DIV_ROUND_UP(alt_prate, tmp_rate) - 1;
WARN_ON(alt_div >= MAX_DIV);
- if (test_bit(CLK_CPU_NEEDS_DEBUG_ALT_DIV, &cpuclk->flags)) {
+ if (cpuclk->flags & CLK_CPU_NEEDS_DEBUG_ALT_DIV) {
/*
* In Exynos4210, ATB clock parent is also mout_core. So
* ATB clock also needs to be mantained at safe speed.
@@ -206,7 +206,7 @@ static int exynos_cpuclk_pre_rate_change(struct
clk_notifier_data *ndata,
writel(div0, base + E4210_DIV_CPU0);
wait_until_divider_stable(base + E4210_DIV_STAT_CPU0, DIV_MASK_ALL);
- if (test_bit(CLK_CPU_HAS_DIV1, &cpuclk->flags)) {
+ if (cpuclk->flags & CLK_CPU_HAS_DIV1) {
writel(div1, base + E4210_DIV_CPU1);
wait_until_divider_stable(base + E4210_DIV_STAT_CPU1,
DIV_MASK_ALL);
@@ -225,7 +225,7 @@ static int exynos_cpuclk_post_rate_change(struct
clk_notifier_data *ndata,
unsigned long mux_reg;
/* find out the divider values to use for clock data */
- if (test_bit(CLK_CPU_NEEDS_DEBUG_ALT_DIV, &cpuclk->flags)) {
+ if (cpuclk->flags & CLK_CPU_NEEDS_DEBUG_ALT_DIV) {
while ((cfg_data->prate * 1000) != ndata->new_rate) {
if (cfg_data->prate == 0)
return -EINVAL;
@@ -240,7 +240,7 @@ static int exynos_cpuclk_post_rate_change(struct
clk_notifier_data *ndata,
writel(mux_reg & ~(1 << 16), base + E4210_SRC_CPU);
wait_until_mux_stable(base + E4210_STAT_CPU, 16, 1);
- if (test_bit(CLK_CPU_NEEDS_DEBUG_ALT_DIV, &cpuclk->flags)) {
+ if (cpuclk->flags & CLK_CPU_NEEDS_DEBUG_ALT_DIV) {
div |= (cfg_data->div0 & E4210_DIV0_ATB_MASK);
div_mask |= E4210_DIV0_ATB_MASK;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm64: dts: Add BUS1 instance pinctrl support
This adds BUS1 instance pinctrl for exynos7 soc.
Signed-off-by: Alim Akhtar
---
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 111 +++
arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
2 files changed, 118 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 2eef4a2..96be6e3 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -586,3 +586,114 @@
samsung,pin-drv = <2>;
};
};
+
+&pinctrl_bus1 {
+ etc1: etc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf2: gpf2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf3: gpf3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf4: gpf4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpf5: gpf5 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpg1: gpg1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpg2: gpg2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gph1: gph1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpv6: gpv6 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ spi5_bus: spi5-bus {
+ samsung,pins = "gpf2-0", "gpf2-1", "gpf2-2", "gpf2-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ ufs_refclk_out: ufs-refclk-out {
+ samsung,pins = "gpg2-4";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <2>;
+ };
+
+ ufs_rst_n: ufs-rst-n {
+ samsung,pins = "gph1-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index d7a37c3..f9c5a54 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -26,6 +26,7 @@
pinctrl5 = &pinctrl_ese;
pinctrl6 = &pinctrl_fsys0;
pinctrl7 = &pinctrl_fsys1;
+ pinctrl8 = &pinctrl_bus1;
};
cpus {
@@ -278,6 +279,12 @@
interrupts = <0 203 0>;
};
+ pinctrl_bus1: pinctrl@1487 {
+ compatible = "samsung,exynos7-pinctrl";
+ reg = <0x1487 0x1000>;
+ interrupts = <0 384 0>;
+ };
+
hsi2c_0: hsi2c@1364 {
compatible = "samsung,exynos7-hsi2c";
reg = <0x1364 0x1000>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: samsung: fix cpu clock's flags checking
On 29/06/15 19:29, Bartlomiej Zolnierkiewicz wrote: > CLK_CPU_HAS_DIV1 and CLK_CPU_NEEDS_DEBUG_ALT_DIV masks were > incorrectly used as a bit numbers. Fix it. > > Tested on Exynos4210 based Origen board and on Exynos5250 based > Arndale board. > > Cc: Tomasz Figa > Cc: Michael Turquette > Cc: Javier Martinez Canillas > Cc: Thomas Abraham > Reported-by: Dan Carpenter > Signed-off-by: Bartlomiej Zolnierkiewicz Acked-by: Sylwester Nawrocki -- To unsubscribe from this list: send the line "unsubscribe linux-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: samsung: fix cpu clock's flags checking
Michael/Sylwester, could you please merge this patch?
It is a bugfix for ddeac8d968d41d13a52582d6e80395a329e9b1ff ("clk:
samsung: add infrastructure to register cpu clocks") which got
merged in v4.2-rc1.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
On Tuesday, June 30, 2015 08:27:36 AM Javier Martinez Canillas wrote:
> On Tue, Jun 30, 2015 at 2:06 AM, Krzysztof Kozlowski
> wrote:
> > On 30.06.2015 02:29, Bartlomiej Zolnierkiewicz wrote:
> >> CLK_CPU_HAS_DIV1 and CLK_CPU_NEEDS_DEBUG_ALT_DIV masks were
> >> incorrectly used as a bit numbers. Fix it.
> >>
> >> Tested on Exynos4210 based Origen board and on Exynos5250 based
> >> Arndale board.
> >>
> >> Cc: Tomasz Figa
> >> Cc: Michael Turquette
> >> Cc: Javier Martinez Canillas
> >> Cc: Thomas Abraham
> >> Reported-by: Dan Carpenter
> >> Signed-off-by: Bartlomiej Zolnierkiewicz
> >> ---
> >> drivers/clk/samsung/clk-cpu.c | 10 +-
> >> 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > Reviewed-by: Krzysztof Kozlowski
> >
>
> Looks good to me as well.
>
> Reviewed-by: Javier Martinez Canillas
>
> > Best regards,
> > Krzysztof
> >
>
> Best regards,
> Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: samsung: exynos7: Add required clock tree for UFS
2015-08-28 18:28 GMT+09:00 Alim Akhtar : > Adding required mux/div/gate clocks for UFS controller > present on Exynos7. > > Signed-off-by: Alim Akhtar > --- > This patch has a dependency on [1] > [1]-> > https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg46122.html Hi, I just noticed that you did not send this and previous patches to proper mailing list and to all of maintainers. You missed linux-...@vger.kernel.org and Stephen Boyd. Please use script/get_maintainers. It will print all necessary addresses. 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: samsung: exynos7: Add required clock tree for UFS
Adding required mux/div/gate clocks for UFS controller
present on Exynos7.
Signed-off-by: Alim Akhtar
---
This patch has a dependency on [1]
[1]->
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg46122.html
drivers/clk/samsung/clk-exynos7.c | 117 +++
include/dt-bindings/clock/exynos7-clk.h | 34 +++--
2 files changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos7.c
b/drivers/clk/samsung/clk-exynos7.c
index 380608b..069af8c 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -35,6 +35,7 @@
#define DIV_TOPC1 0x0604
#define DIV_TOPC3 0x060C
#define ENABLE_ACLK_TOPC1 0x0804
+#define ENABLE_SCLK_TOPC1 0x0A04
static struct samsung_fixed_factor_clock topc_fixed_factor_clks[] __initdata =
{
FFACTOR(0, "ffac_topc_bus0_pll_div2", "mout_bus0_pll_ctrl", 1, 2, 0),
@@ -143,6 +144,15 @@ static struct samsung_pll_rate_table pll1460x_24mhz_tbl[]
__initdata = {
static struct samsung_gate_clock topc_gate_clks[] __initdata = {
GATE(ACLK_MSCL_532, "aclk_mscl_532", "dout_aclk_mscl_532",
ENABLE_ACLK_TOPC1, 20, 0, 0),
+
+ GATE(SCLK_MFC_PLL_B, "dout_sclk_mfc_pll_b", "dout_sclk_mfc_pll",
+ ENABLE_SCLK_TOPC1, 17, 0, 0),
+ GATE(SCLK_MFC_PLL_A, "dout_sclk_mfc_pll_a", "dout_sclk_mfc_pll",
+ ENABLE_SCLK_TOPC1, 16, 0, 0),
+ GATE(SCLK_BUS1_PLL_B, "dout_sclk_bus1_pll_b", "dout_sclk_bus1_pll",
+ ENABLE_SCLK_TOPC1, 13, 0, 0),
+ GATE(SCLK_BUS1_PLL_B, "dout_sclk_bus1_pll_a", "dout_sclk_bus1_pll",
+ ENABLE_SCLK_TOPC1, 12, 0, 0),
};
static struct samsung_pll_clock topc_pll_clks[] __initdata = {
@@ -433,12 +443,21 @@ static struct samsung_mux_clock top1_mux_clks[]
__initdata = {
MUX(0, "mout_aclk_fsys1_200", mout_top1_group1, MUX_SEL_TOP13, 24, 2),
MUX(0, "mout_aclk_fsys0_200", mout_top1_group1, MUX_SEL_TOP13, 28, 2),
+ MUX(0, "mout_sclk_phy_fsys0_26m", mout_top1_group1,
+ MUX_SEL_TOP1_FSYS0, 0, 2),
MUX(0, "mout_sclk_mmc2", mout_top1_group1, MUX_SEL_TOP1_FSYS0, 16, 2),
MUX(0, "mout_sclk_usbdrd300", mout_top1_group1,
MUX_SEL_TOP1_FSYS0, 28, 2),
+ MUX(0, "mout_sclk_phy_fsys1", mout_top1_group1,
+ MUX_SEL_TOP1_FSYS1, 0, 2),
+ MUX(0, "mout_sclk_ufsunipro20", mout_top1_group1,
+ MUX_SEL_TOP1_FSYS1, 16, 2),
+
MUX(0, "mout_sclk_mmc1", mout_top1_group1, MUX_SEL_TOP1_FSYS11, 0, 2),
MUX(0, "mout_sclk_mmc0", mout_top1_group1, MUX_SEL_TOP1_FSYS11, 12, 2),
+ MUX(0, "mout_sclk_phy_fsys1_26m", mout_top1_group1,
+ MUX_SEL_TOP1_FSYS11, 24, 2),
};
static struct samsung_div_clock top1_div_clks[] __initdata = {
@@ -447,6 +466,13 @@ static struct samsung_div_clock top1_div_clks[] __initdata
= {
DIV(DOUT_ACLK_FSYS0_200, "dout_aclk_fsys0_200", "mout_aclk_fsys0_200",
DIV_TOP13, 28, 4),
+ DIV(DOUT_SCLK_PHY_FSYS1, "dout_sclk_phy_fsys1",
+ "mout_sclk_phy_fsys1", DIV_TOP1_FSYS1, 0, 6),
+
+ DIV(DOUT_SCLK_UFSUNIPRO20, "dout_sclk_ufsunipro20",
+ "mout_sclk_ufsunipro20",
+ DIV_TOP1_FSYS1, 16, 6),
+
DIV(DOUT_SCLK_MMC2, "dout_sclk_mmc2", "mout_sclk_mmc2",
DIV_TOP1_FSYS0, 16, 10),
DIV(0, "dout_sclk_usbdrd300", "mout_sclk_usbdrd300",
@@ -456,6 +482,9 @@ static struct samsung_div_clock top1_div_clks[] __initdata
= {
DIV_TOP1_FSYS11, 0, 10),
DIV(DOUT_SCLK_MMC0, "dout_sclk_mmc0", "mout_sclk_mmc0",
DIV_TOP1_FSYS11, 12, 10),
+
+ DIV(DOUT_SCLK_PHY_FSYS1_26M, "dout_sclk_phy_fsys1_26m",
+ "mout_sclk_phy_fsys1_26m", DIV_TOP1_FSYS11, 24, 6),
};
static struct samsung_gate_clock top1_gate_clks[] __initdata = {
@@ -464,10 +493,20 @@ static struct samsung_gate_clock top1_gate_clks[]
__initdata = {
GATE(0, "sclk_usbdrd300", "dout_sclk_usbdrd300",
ENABLE_SCLK_TOP1_FSYS0, 28, 0, 0),
+ GATE(CLK_SCLK_PHY_FSYS1, "sclk_phy_fsys1", "dout_sclk_phy_fsys1",
+ ENABLE_SCLK_TOP1_FSYS1, 0, CLK_SET_RATE_PARENT, 0),
+
+ GATE(CLK_SCLK_UFSUNIPRO20, "sclk_ufsunipro20", "dout_sclk_ufsunipro20",
+ ENABLE_SCLK_TOP1_FSYS1, 16, CLK_SET_RATE_PARENT, 0),
+
GATE(CLK_SCLK_MMC1, "sclk_mmc1", "dout_sclk_mmc1",
ENABLE_SCLK_TOP1_FSYS11, 0, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_MMC0, "sclk_mmc0", "dout_sclk_mmc0",
ENABLE_SCLK_TOP1_FSYS11, 12, CLK_SET_RATE_PARENT, 0),
+
+ GATE(CLK_SCLK_PHY_FSYS1_26M, "sclk_phy_fsys1_26m",
+ "dout_sclk_phy_fsys1_26m", ENABLE_SCLK_TOP1_FSYS11,
+ 24, CLK_SET_RATE_PARENT, 0),
};
static struct samsung_fixed_factor_clock top1_fixed_factor_clks[] __initdata =
{
@@ -902,39 +941,117 @@ CLK_OF_DECLARE(exynos7_clk_fsys0,
"samsung,exynos7
Re: [PATCH] ARM: exynos_defconfig: Enable big.LITTLE CPUidle support
Hello Sjoerd,
On 08/28/2015 10:51 AM, Sjoerd Simons wrote:
> On Fri, 2015-08-28 at 10:16 +0200, Javier Martinez Canillas wrote:
>> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
>> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
>> driver to work correctly, so enable support for this.
>>
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>> Kukjin and Krzysztof,
>>
>> As you know there are other boards like the Exynos5422 based Odroid
>> XU{3,4}
>> whose firmware is broken due leaving CCI in secure mode which means
>> that the
>> kernel MCPM support can't properly manage CCI.
>>
>> So if you pick this patch, it should be tested in kernelci before
>> appearing
>> in linux-next to prevent any boot issues.
>
> I've pushed this patch into Collabora's for-next branch, which should
> get picked up by kernelci soonish.
>
Awesome, thanks a lot for your help!
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: Enable big.LITTLE CPUidle support
On Fri, 2015-08-28 at 10:16 +0200, Javier Martinez Canillas wrote:
> Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
> Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
> driver to work correctly, so enable support for this.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
> Kukjin and Krzysztof,
>
> As you know there are other boards like the Exynos5422 based Odroid
> XU{3,4}
> whose firmware is broken due leaving CCI in secure mode which means
> that the
> kernel MCPM support can't properly manage CCI.
>
> So if you pick this patch, it should be tested in kernelci before
> appearing
> in linux-next to prevent any boot issues.
I've pushed this patch into Collabora's for-next branch, which should
get picked up by kernelci soonish.
--
Sjoerd Simons
Collabora Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-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: CPUIdle for Exynos5422 Odroid-XU3/XU4 boards.
Hello Bartlomiej and Lorenzo, Thanks a lot for your explanations. On 08/27/2015 06:58 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Tuesday, August 25, 2015 05:09:32 PM Lorenzo Pieralisi wrote: >> On Tue, Aug 25, 2015 at 03:35:29PM +0100, Bartlomiej Zolnierkiewicz wrote: >>> >>> [ added Lorenzo and linux-pm to Cc: ] >>> >>> Hi, >>> >>> On Tuesday, August 25, 2015 11:43:38 AM Javier Martinez Canillas wrote: [adding Kevin Hilman as cc who was also interested in CPUidle for Exynos] Hello Krzysztof, On 08/23/2015 03:26 AM, Krzysztof Kozlowski wrote: [snip] > 2015-08-21 16:21 GMT+09:00 Javier Martinez Canillas > : > > The big.LITTLE cpuidle driver is not a typical Exynos cpuidle driver. > It only executes CPU suspend on a cluster which essentially is a power > down operation. > You are correct, looking at the the big.LITTLE CPUidle driver I see that it only has two C-states: C0 (normal WFI) and C1 (single CPU power-down) which as you said, places the CPU into power-down mode by using the MCPM infrastructure so it's basically a CPU suspend AFAIU. So what you are saying is that there are deeper C-states supported by the Exynos 542x SoC family but these are not handled by the b.L CPUidle driver. > When we talk about cpuidle on Exynos, we have in mind one of sleep > modes: AFTR or LPA (sometimes instead of LPA there is LPD or W-AFTR). > Actually this is more like a system idle mode, not CPU idle. The power > savings are much bigger than disabling only one cluster. > Interesting, I was not aware of AFTR and LPA but I looked in the manual now. Thanks a lot for the information. I see that the Exynos CPUidle driver (drivers/cpuidle/cpuidle-exynos.c) also has only two C-states (WFI and C1) but C1 makes the system to enter in AFTR (system-level power gating). This is similar to what the downstream ChromiumOS 3.8 kernel CPUidle driver does IIUC [0]. >>> >>> Yes but upstream does it in a clean way, has support for platforms >>> requiring secure firmware operations and also implements coupled >>> AFTR mode on a few platforms. >>> > So the question is still valid - whether someone wants or plans to > implement cpuidle for Exynos 542x family. Odroid XU3 is not a priority > here because energy consumption is not an issue there. This is not a > mobile device. > That's true but it will be interesting for the 5420 and 5800 based Chromebooks since optimizing power consumption would be useful there. >>> >>> I would be happy to help with reviewing patches etc. but personally >>> I don't have any plans for doing this work. I may look into adding >>> support for newer ARM64 SoCs (Exynos5433) if I find some extra time >>> (quite unlikely currently). >>> I thought that big.LITTLE platforms were encouraged to use the generic b.L CPUidle driver just like DT platforms should use the generic CPUFreq DT driver but I guess I misunderstood. So the b.L CPUidle driver is only to have minimum CPUidle support but a SoC specific driver is needed to fine tune and get most out of the platform? Or should the b.L CPUidle driver be extended to add per platform C-states? >>> >>> This is a good question. Daniel/Lorenzo? >> >> To move the b.L driver to multiple C-states we should first convert it to >> the generic CPUidle driver (by defining an MCPM enable-method): >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/cpuidle-arm.c?id=refs/tags/v4.2-rc8 >> >> Then we have to figure out how to determine how many CPUidle drivers we >> have to create (since idle states are different on different CPUs), since >> using the MIDR does not really scale. >> >> For certain I won't support coupled C-states in the DT idle states code, >> and every platform requiring them is considered buggy and not worth >> merging in the mainline kernel from now onwards, HW should be fixed, >> eventually, I am not willing to see code like >> drivers/cpuidle/cpuidle-exynos.c in the mainline kernel anymore, >> I am sorry. > > For Exynos chipsets coupled C-states are not strictly required for > having cpuidle support but make it more useful. On Exynos chipsets > secondary CPUs must be disabled to allow system to go into deeper > idle modes and this is assured by using coupled C-states. Original > Android drivers don't use coupled C-states and depend on the rest > of the system to offline secondary CPUs when not needed. > > I would of course prefer not to have handle this in software and > be automatically handled by hardware/firmware but that doesn't mean > that we should be declining mainline support for "ugly" hardware > (this has never been "the Linux way" of doing things). > > Coming back to the platforms in question (ARM32 big.LITTLE based > Odroid XU3 boards etc
[PATCH] ARM: exynos_defconfig: Enable big.LITTLE CPUidle support
Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
driver to work correctly, so enable support for this.
Signed-off-by: Javier Martinez Canillas
---
Kukjin and Krzysztof,
As you know there are other boards like the Exynos5422 based Odroid XU{3,4}
whose firmware is broken due leaving CCI in secure mode which means that the
kernel MCPM support can't properly manage CCI.
So if you pick this patch, it should be tested in kernelci before appearing
in linux-next to prevent any boot issues.
But if that happens, I believe that is better to do a fix / workaround in
those broken platforms since nothing prevents users to enable this option
anyways. For example the CCI device node could be disabled in the DTS.
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index 729e2fae3e58..228ee945b8ed 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -30,6 +30,7 @@ CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPUFREQ_DT=y
CONFIG_CPU_IDLE=y
+CONFIG_ARM_BIG_LITTLE_CPUIDLE=y
CONFIG_ARM_EXYNOS_CPUIDLE=y
CONFIG_VFP=y
CONFIG_NEON=y
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
