Re: [PATCH 1/3] clk: samsung: exynos4: Add SSS gate clock

[Stephen Boyd]

On 10/19, Krzysztof Kozlowski wrote:
> Add a gate clock for controlling all clocks of Security Sub System
> (SSS).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> ---

The To: list is huge, so I have no idea if you want me to apply
this patch or not, and given that it's part of a series that has
dts changes I guess that means it should go through arm-soc:

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks

[Stephen Boyd]

On 10/16, Michael Turquette wrote:
> Quoting Krzysztof Kozlowski (2015-10-15 16:46:27)
> > On 15.10.2015 19:31, Tomeu Vizoso wrote:
> > > When the DISP1 power domain is powered off, there's two clocks that need
> > > to be temporarily reparented to OSC, and back to their original parents
> > > when the domain is powered on again.
> > > 
> > > We expose these two clocks in the DT bindings so that the DT node of the
> > > power domain can reference them.
> > > 
> > > Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> > > Acked-by: Stephen Boyd <sb...@codeaurora.org>
> > > ---
> > > 
> > > Changes in v2:
> > > - Reuse mout_aclk200_p
> > > - Rename div_aclk300 as div_aclk300_disp
> > > 
> > >  drivers/clk/samsung/clk-exynos5250.c   | 14 +-
> > >  include/dt-bindings/clock/exynos5250.h |  4 +++-
> > >  2 files changed, 16 insertions(+), 2 deletions(-)
> > > 
> > 
> > Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> Applied to clk-next.
> 

I think Tomeu wanted to take this through arm-soc? Otherwise
we'll need to provide a stable branch for the dt header.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v1 1/2] clk: samsung: exynos5250: Add DISP1 clocks

[Stephen Boyd]

On 10/14, Tomeu Vizoso wrote:
> When the DISP1 power domain is powered off, there's two clocks that need
> to be temporarily reparented to OSC, and back to their original parents
> when the domain is powered on again.
> 
> We expose these two clocks in the DT bindings so that the DT node of the
> power domain can reference them.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
> ---

Acked-by: Stephen Boyd <sb...@codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: [GIT PULL] clk/samsung updates for v4.4

[Stephen Boyd]

On 10/02, Sylwester Nawrocki wrote:
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/snawrocki/samsung.git tags/clk-samsung-4.4
> 
> for you to fetch changes up to 7993b3ebec979b23c2d7425959c9d232c452498b:
> 
>   clk: samsung: exynos7: Add required clock tree for UFS (2015-09-15 11:18:15 
> +0200)
> 

Thanks, pulled. I put this patch on top though.

-8<-
From: Stephen Boyd <sb...@codeaurora.org>
Subject: [PATCH] clk: samsung: exynos7: Staticize file scope symbols

drivers/clk/samsung/clk-exynos7.c:896:33:
warning: symbol 'fixed_rate_clks_fsys0' was not declared. Should
it be static?
drivers/clk/samsung/clk-exynos7.c:1010:33:
warning: symbol 'fixed_rate_clks_fsys1' was not declared. Should
it be static?

Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
---
 drivers/clk/samsung/clk-exynos7.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index 924215b219da..55f8e2e24ab8 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -893,7 +893,7 @@ PNAME(mout_phyclk_usbdrd300_udrd30_pipe_pclk_user_p)
= { "fin_pll",
"phyclk_usbdrd300_udrd30_pipe_pclk" };
 
 /* fixed rate clocks used in the FSYS0 block */
-struct samsung_fixed_rate_clock fixed_rate_clks_fsys0[] __initdata = {
+static struct samsung_fixed_rate_clock fixed_rate_clks_fsys0[] __initdata = {
FRATE(0, "phyclk_usbdrd300_udrd30_phyclock", NULL,
CLK_IS_ROOT, 6000),
FRATE(0, "phyclk_usbdrd300_udrd30_pipe_pclk", NULL,
@@ -1007,7 +1007,7 @@ PNAME(mout_phyclk_ufs20_rx0_user_p) = { "fin_pll", 
"phyclk_ufs20_rx0_symbol" };
 PNAME(mout_phyclk_ufs20_rx1_user_p) = { "fin_pll", "phyclk_ufs20_rx1_symbol" };
 
 /* fixed rate clocks used in the FSYS1 block */
-struct samsung_fixed_rate_clock fixed_rate_clks_fsys1[] __initdata = {
+static struct samsung_fixed_rate_clock fixed_rate_clks_fsys1[] __initdata = {
FRATE(PHYCLK_UFS20_TX0_SYMBOL, "phyclk_ufs20_tx0_symbol", NULL,
CLK_IS_ROOT, 3),
FRATE(PHYCLK_UFS20_RX0_SYMBOL, "phyclk_ufs20_rx0_symbol", NULL,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] clk: samsung: fix cpu clock's flags checking

[Stephen Boyd]

On 08/28, 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: 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 
> ---

Applied to clk-fixes

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] cpufreq-dt: add suspend frequency support

[Stephen Boyd]

On 09/02/2015 09:47 AM, Bartlomiej Zolnierkiewicz wrote:
> Add suspend frequency support and set it to the boot frequency,
> this matches what the old exynos-cpufreq driver has been doing.
>
> This patch fixes suspend/resume support on Exynos4412 based
> Trats2 board and reboot hang on Exynos4412 based Odroid U3
> board.
>
> Cc: Viresh Kumar 
> Cc: Thomas Abraham 
> Cc: Javier Martinez Canillas 
> Cc: Krzysztof Kozlowski 
> Cc: Marek Szyprowski 
> Cc: Tobias Jakobi 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
> This patch supersedes "[PATCH] ARM: dts: exynos4412-odroid-*: add
> workaround for CPUfreq/reboot issue" one from yesterday.

What do we do about cpufreq-dt users that don't want to change frequency
during suspend?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

[Stephen Boyd]

Use the provider based method to get a clock's name so that we
can get rid of the clk member in struct clk_hw one day. Mostly
converted with the following coccinelle script.

@@
struct clk_hw *E;
@@

-__clk_get_name(E-clk)
+clk_hw_get_name(E)

Cc: Heiko Stuebner he...@sntech.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Peter De Schrijver pdeschrij...@nvidia.com
Cc: Prashant Gaikwad pgaik...@nvidia.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Ulf Hansson ulf.hans...@linaro.org
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Andrew Bresticker abres...@chromium.org
Cc: Ezequiel Garcia ezequiel.gar...@imgtec.com
Cc: Ralf Baechle r...@linux-mips.org
Cc: Kevin Cernekee cerne...@chromium.org
Cc: Geert Uytterhoeven geert+rene...@glider.be
Cc: Ulrich Hecht ulrich.hecht+rene...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
 drivers/clk/berlin/berlin2-pll.c |  4 ++--
 drivers/clk/clk-xgene.c  | 22 +++---
 drivers/clk/pistachio/clk-pll.c  |  4 ++--
 drivers/clk/qcom/clk-branch.c|  2 +-
 drivers/clk/rockchip/clk-inverter.c  |  2 +-
 drivers/clk/rockchip/clk-mmc-phase.c |  2 +-
 drivers/clk/samsung/clk-pll.c| 18 +-
 drivers/clk/shmobile/clk-div6.c  |  2 +-
 drivers/clk/st/clk-flexgen.c |  4 ++--
 drivers/clk/st/clkgen-fsyn.c | 18 +-
 drivers/clk/st/clkgen-mux.c  |  2 +-
 drivers/clk/st/clkgen-pll.c  |  8 
 drivers/clk/tegra/clk-pll.c  |  8 
 drivers/clk/ti/apll.c|  4 ++--
 drivers/clk/ti/clkt_dflt.c   |  8 
 drivers/clk/ti/clockdomain.c | 14 +++---
 drivers/clk/ux500/clk-prcmu.c| 16 
 drivers/clk/ux500/clk-sysctrl.c  |  2 +-
 18 files changed, 70 insertions(+), 70 deletions(-)

diff --git a/drivers/clk/berlin/berlin2-pll.c b/drivers/clk/berlin/berlin2-pll.c
index f4b8d324b083..1c2294d3ba85 100644
--- a/drivers/clk/berlin/berlin2-pll.c
+++ b/drivers/clk/berlin/berlin2-pll.c
@@ -61,7 +61,7 @@ berlin2_pll_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
fbdiv = (val  map-fbdiv_shift)  FBDIV_MASK;
rfdiv = (val  map-rfdiv_shift)  RFDIV_MASK;
if (rfdiv == 0) {
-   pr_warn(%s has zero rfdiv\n, __clk_get_name(hw-clk));
+   pr_warn(%s has zero rfdiv\n, clk_hw_get_name(hw));
rfdiv = 1;
}
 
@@ -70,7 +70,7 @@ berlin2_pll_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
vcodiv = map-vcodiv[vcodivsel];
if (vcodiv == 0) {
pr_warn(%s has zero vcodiv (index %d)\n,
-   __clk_get_name(hw-clk), vcodivsel);
+   clk_hw_get_name(hw), vcodivsel);
vcodiv = 1;
}
 
diff --git a/drivers/clk/clk-xgene.c b/drivers/clk/clk-xgene.c
index 4caee9356407..96a6190acac2 100644
--- a/drivers/clk/clk-xgene.c
+++ b/drivers/clk/clk-xgene.c
@@ -74,7 +74,7 @@ static int xgene_clk_pll_is_enabled(struct clk_hw *hw)
u32 data;
 
data = xgene_clk_read(pllclk-reg + pllclk-pll_offset);
-   pr_debug(%s pll %s\n, __clk_get_name(hw-clk),
+   pr_debug(%s pll %s\n, clk_hw_get_name(hw),
data  REGSPEC_RESET_F1_MASK ? disabled : enabled);
 
return data  REGSPEC_RESET_F1_MASK ? 0 : 1;
@@ -112,7 +112,7 @@ static unsigned long xgene_clk_pll_recalc_rate(struct 
clk_hw *hw,
fref = parent_rate / nref;
fvco = fref * nfb;
}
-   pr_debug(%s pll recalc rate %ld parent %ld\n, __clk_get_name(hw-clk),
+   pr_debug(%s pll recalc rate %ld parent %ld\n, clk_hw_get_name(hw),
fvco / nout, parent_rate);
 
return fvco / nout;
@@ -225,7 +225,7 @@ static int xgene_clk_enable(struct clk_hw *hw)
spin_lock_irqsave(pclk-lock, flags);
 
if (pclk-param.csr_reg != NULL) {
-   pr_debug(%s clock enabled\n, __clk_get_name(hw-clk));
+   pr_debug(%s clock enabled\n, clk_hw_get_name(hw));
reg = __pa(pclk-param.csr_reg);
/* First enable the clock */
data = xgene_clk_read(pclk-param.csr_reg +
@@ -234,7 +234,7 @@ static int xgene_clk_enable(struct clk_hw *hw)
xgene_clk_write(data, pclk-param.csr_reg +
pclk-param.reg_clk_offset);
pr_debug(%s clock PADDR base %pa clk offset 0x%08X mask 0x%08X 
value 0x%08X\n,
-   __clk_get_name(hw-clk), reg,
+   clk_hw_get_name(hw), reg,
pclk-param.reg_clk_offset

Re: [PATCH v2] clk: exynos4: Fix wrong clock for Exynos4x12 ADC

[Stephen Boyd]

On 07/26, Sylwester Nawrocki wrote:
 On 07/22/2015 08:41 AM, Krzysztof Kozlowski wrote:
 On 22.07.2015 07:42, Stephen Boyd wrote:
 On 06/12, Krzysztof Kozlowski wrote:
 [...]
 Signed-off-by: Krzysztof Kozlowskik.kozlow...@samsung.com
 Cc:sta...@vger.kernel.org
 Fixes: c63c57433003 (ARM: dts: Add ADC's dt data to read raw data for 
 exynos4x12)
 Link:https://lkml.org/lkml/2015/6/11/85
 
 Did you want clk maintainers to apply this? The To: list is not
 helping so I'm not sure what's going on and it seems to have
 slipped through the cracks.
 
 Thank you for being proactive! I appreciate this.
 Some time ago Sylwester replied that he took care about this patch so I
 think this will go through Samsung clock tree.
 
 Sylwester, are you planning to send this as fix for 4.2-rc?
 
 I think it qualifies for 4.3, it's not a new regression and will be
 backported to -stable anyway.
 I would prefer clk maintainers have applied this, otherwise I would
 need to make a (questionable) pull request with only one patch, since
 all patches except this one after the last merge window were part
 of bigger series touching multiple subsystems and applied through
 the samsung soc tree.
 

Ok. Applied to clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: s2mps11: Use kcalloc instead of kzalloc for array allocation

[Stephen Boyd]

On 07/22, Vaibhav Hiremath wrote:
 This patch cleans up the driver for,
 
   - Use devm_kcalloc varient instead of devm_kzalloc for array
 allocation.
   - clk_prepare/unprepare, remove ret variable as it is not required
   - use __exit for cleanup function
 
 As I am referring this driver as a reference for my 88pm800 clk driver,
 applying same changes here as well.
 
 Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
 ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] clk: exynos4: Fix wrong clock for Exynos4x12 ADC

[Stephen Boyd]

On 06/12, Krzysztof Kozlowski wrote:
 The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
 However TSADC is present only on Exynos4210 so on Trats2 board (with
 Exynos4412 SoC) the exynos-adc driver could not be probed:
ERROR: could not get clock /adc@126C:adc(0)
exynos-adc 126c.adc: failed getting clock, err = -2
exynos-adc: probe of 126c.adc failed with error -2
 
 Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
 Converter is located in different register and it is named in datasheet
 as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
 is the same as purpose of TSADC from Exynos4210.
 
 The patch adds gate clock for Exynos4x12 using the proper register so
 backward compatibility is preserved. This fixes the probe of exynos-adc
 driver on Exynos4x12 boards and allows accessing sensors connected to it
 on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: sta...@vger.kernel.org
 Fixes: c63c57433003 (ARM: dts: Add ADC's dt data to read raw data for 
 exynos4x12)
 Link: https://lkml.org/lkml/2015/6/11/85
 

Did you want clk maintainers to apply this? The To: list is not
helping so I'm not sure what's going on and it seems to have
slipped through the cracks.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 1/3] clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock

[Stephen Boyd]

On 07/01/2015 06:21 AM, Chanwoo Choi wrote:
 This patch add CPU clock configuration data and instantiate the CPU clock type
 for Exynos3250 to support Samsung specific cpu-clock type.

 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---


Looks ok.

Acked-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: [question] [PATCH RFC] clocksource: exynos_mct: remove unneeded container_of()

[Stephen Boyd]

On 06/15, Alexey Klimov wrote:
 
 Patch removes unneeded container_of() macro
 in exynos4_local_timer_setup(). Instead let's pass mevt pointer
 to setup and stop functions from exynos4_mct_cpu_notify() 
 and let them get evt pointer.
 
 Signed-off-by: Alexey Klimov klimov.li...@gmail.com
 ---

Acked-by: Stephen Boyd sb...@codeaurora.org

It was done this way to minimize the diff. I don't see any
problem changing it as you propose.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: make several parent names const

[Stephen Boyd]

On 05/28, Uwe Kleine-König wrote:
 Since commit 2893c379461a (clk: make strings in parent name arrays
 const) the name of parent clocks can be const. So add more const in
 several clock drivers.
 
 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
 ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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:clk - Fix typo in panic log.

[Stephen Boyd]

On 05/21, Shailendra Verma wrote:
 
 Signed-off-by: Shailendra Verma shailendra.capric...@gmail.com
 ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/8] clk: tegra: Fix inconsistent indenting

[Stephen Boyd]

On 04/28, Krzysztof Kozlowski wrote:
 Fix the indentation - spaces used instead of tabs and actually wrong
 number of spaces.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/clk/tegra/clk-emc.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

What branch is this against? I don't see this in linux-next or
clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 4/8] clk: tegra: Fix duplicate const for parent names

[Stephen Boyd]

On 04/09, Thierry Reding wrote:
 On Thu, Apr 09, 2015 at 12:07:59PM +0200, Krzysztof Kozlowski wrote:
  2015-04-09 12:00 GMT+02:00 Thierry Reding thierry.red...@gmail.com:
   On Wed, Apr 08, 2015 at 03:22:15PM +0200, Krzysztof Kozlowski wrote:
   Replace duplicated const keyword for 'emc_parent_clk_names' with proper
   array of const pointers to const strings.
  
   Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
   ---
drivers/clk/tegra/clk-emc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
  
   This would probably better go in via the Tegra tree since the patch that
   contains this has only made it to linux-next.
  
   Stephen, Mike, any objections to me taking this?
  
  Applying this without the change for const-ness of parent_names (patch
  by Sascha Hauer sent before mine [1]) would introduce a warning -
  assign of const to non-const. Any idea to solve it? Immutable branch?
 
 Right, I had missed that. Immutable branch would work, though perhaps
 it'd be easier to just defer this until after v4.1-rc1. The warning
 shouldn't happen if we leave out this single patch and apply it later
 on, right?
 
 Alternatively the whole series could be deferred until after v4.1-rc1.
 

Yeah I don't really care to make an immutable branch for this
cleanup series. If everyone is ok with waiting until after -rc1
we can apply the Tegra patch then (or you can and we'll get it
through a pull later). We should be able to apply the parts that
go through clk tree though.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 3/8] clk: Constify pointers to parent names in init data

[Stephen Boyd]

On 04/08/15 06:22, Krzysztof Kozlowski wrote:
 The 'parent_names' member of 'clk_init_data' is not modified so it can
 be made as an array of const pointers to constant strings.

 Some drivers (e.g. arch/mips/alchemy/common/clock.c) already pass such
 data.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---

Sascha sent a similar patch a few days ago.

http://lkml.kernel.org/r/1427825817-26773-2-git-send-email-s.ha...@pengutronix.de


  drivers/clk/clk-composite.c  |  2 +-
  drivers/clk/clk-mux.c|  8 
  include/linux/clk-provider.h | 12 ++--
  3 files changed, 11 insertions(+), 11 deletions(-)

 diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
 index 956b7e54fa1c..077f4c7148f1 100644
 --- a/drivers/clk/clk-composite.c
 +++ b/drivers/clk/clk-composite.c
 @@ -188,7 +188,7 @@ static void clk_composite_disable(struct clk_hw *hw)
  }
  
  struct clk *clk_register_composite(struct device *dev, const char *name,
 - const char **parent_names, int num_parents,
 + const char * const *parent_names, int num_parents,
   struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
   struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
   struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
 index 69a094c3783d..962e2a056381 100644
 --- a/drivers/clk/clk-mux.c
 +++ b/drivers/clk/clk-mux.c
 @@ -114,8 +114,8 @@ const struct clk_ops clk_mux_ro_ops = {
  EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
  
  struct clk *clk_register_mux_table(struct device *dev, const char *name,
 - const char **parent_names, u8 num_parents, unsigned long flags,
 - void __iomem *reg, u8 shift, u32 mask,
 + const char * const *parent_names, u8 num_parents,
 + unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
   u8 clk_mux_flags, u32 *table, spinlock_t *lock)
  {
   struct clk_mux *mux;
 @@ -166,8 +166,8 @@ struct clk *clk_register_mux_table(struct device *dev, 
 const char *name,
  EXPORT_SYMBOL_GPL(clk_register_mux_table);
  
  struct clk *clk_register_mux(struct device *dev, const char *name,
 - const char **parent_names, u8 num_parents, unsigned long flags,
 - void __iomem *reg, u8 shift, u8 width,
 + const char * const *parent_names, u8 num_parents,
 + unsigned long flags, void __iomem *reg, u8 shift, u8 width,
   u8 clk_mux_flags, spinlock_t *lock)
  {
   u32 mask = BIT(width) - 1;
 diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
 index 28abf1badb40..0bf0308963da 100644
 --- a/include/linux/clk-provider.h
 +++ b/include/linux/clk-provider.h
 @@ -209,7 +209,7 @@ struct clk_ops {
  struct clk_init_data {
   const char  *name;
   const struct clk_ops*ops;
 - const char  **parent_names;
 + const char * const  *parent_names;
   u8  num_parents;
   unsigned long   flags;
  };
 @@ -426,13 +426,13 @@ extern const struct clk_ops clk_mux_ops;
  extern const struct clk_ops clk_mux_ro_ops;
  
  struct clk *clk_register_mux(struct device *dev, const char *name,
 - const char **parent_names, u8 num_parents, unsigned long flags,
 - void __iomem *reg, u8 shift, u8 width,
 + const char * const *parent_names, u8 num_parents,
 + unsigned long flags, void __iomem *reg, u8 shift, u8 width,
   u8 clk_mux_flags, spinlock_t *lock);
  
  struct clk *clk_register_mux_table(struct device *dev, const char *name,
 - const char **parent_names, u8 num_parents, unsigned long flags,
 - void __iomem *reg, u8 shift, u32 mask,
 + const char * const *parent_names, u8 num_parents,
 + unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
   u8 clk_mux_flags, u32 *table, spinlock_t *lock);
  
  void clk_unregister_mux(struct clk *clk);
 @@ -518,7 +518,7 @@ struct clk_composite {
  };
  
  struct clk *clk_register_composite(struct device *dev, const char *name,
 - const char **parent_names, int num_parents,
 + const char * const *parent_names, int num_parents,
   struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
   struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
   struct clk_hw *gate_hw, const struct clk_ops *gate_ops,


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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] clk: samsung: Add CLKOUT driver support for Exynos3250 SoC.

[Stephen Boyd]

On 03/01/15 18:15, Inha Song wrote:
 This patch add CLKOUT driver support for Exynos3250 SoC.

 Exynos3250 SoC PMU_DEBUG is the same with Exynos4's PMU_DEBUG
 including CLKOUT mux. So, We can use the exynos4's clkout init
 function for Exynos3250 without the need to add new function.

 Signed-off-by: Inha Song ideal.s...@samsung.com

Do you want to take this through some SoC tree? If so:

Acked-by: Stephen Boyd sb...@codeaurora.org

 ---
  drivers/clk/samsung/clk-exynos-clkout.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/clk/samsung/clk-exynos-clkout.c 
 b/drivers/clk/samsung/clk-exynos-clkout.c
 index 3a7cb25..1c02e73 100644
 --- a/drivers/clk/samsung/clk-exynos-clkout.c
 +++ b/drivers/clk/samsung/clk-exynos-clkout.c
 @@ -142,6 +142,8 @@ CLK_OF_DECLARE(exynos4212_clkout, 
 samsung,exynos4212-pmu,
   exynos4_clkout_init);
  CLK_OF_DECLARE(exynos4412_clkout, samsung,exynos4412-pmu,
   exynos4_clkout_init);
 +CLK_OF_DECLARE(exynos3250_clkout, samsung,exynos3250-pmu,
 + exynos4_clkout_init);
  
  static void __init exynos5_clkout_init(struct device_node *node)
  {


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: Don't use LDREX and STREX after disabling cache coherency

[Stephen Boyd]

On 02/16/15 05:36, Krzysztof Kozlowski wrote:
 During CPU shutdown the exynos_cpu_power_down() is called after
 disabling cache coherency and it uses LDREX and STREX instructions (by
 calling of_machine_is_compatible() - kobject_get() - kref_get()).

 The LDREX and STREX should not be used after disabling the cache
 coherency so just use soc_is_exynos().

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Fixes: adc548d77c22 (ARM: EXYNOS: Use MCPM call-backs to support S2R on 
 exynos5420)
 Cc: sta...@vger.kernel.org
 Reported-by: Stephen Boyd sb...@codeaurora.org
 ---

Looks good to me.

Reviewed-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] clk: Don't dereference parent clock if is NULL

[Stephen Boyd]

On 02/12/15 05:58, Javier Martinez Canillas wrote:
 The clock passed as an argument to clk_mux_determine_rate_flags()
 has the CLK_SET_RATE_PARENT flag set but it has no parent, then a
 NULL pointer will tried to be dereferenced.

 This shouldn't happen since setting that flag for a clock with no
 parent is a bug but the core should be robust to handle that case.

 Fixes: 035a61c314eb3 (clk: Make clk API return per-user struct clk 
 instances)
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Reviewed-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] clk: Replace explicit clk assignment with __clk_hw_set_clk

[Stephen Boyd]

 [c0008944] (do_one_initcall+0x80/0x1d0)
 [c0008944] (do_one_initcall) from [c066bd44] 
 (kernel_init_freeable+0x10c/0x1d8)
 [c066bd44] (kernel_init_freeable) from [c0481940] (kernel_init+0x8/0xe4)
 [c0481940] (kernel_init) from [c000e680] (ret_from_fork+0x14/0x34)
 Code: e24dd00c e5907000 e1a08001 e88d000c (e5970034)

 The changes were made using the following cocinelle semantic patch:

 @i@
 @@

 @depends on i@
 identifier dst;
 @@

 - dst-clk = hw-clk;
 + __clk_hw_set_clk(dst, hw);

 @depends on i@
 identifier dst;
 @@

 - dst-hw.clk = hw-clk;
 + __clk_hw_set_clk(dst-hw, hw);

 Fixes: 035a61c314eb3 (clk: Make clk API return per-user struct clk 
 instances)
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Reviewed-by: Stephen Boyd sb...@codeaurora.org

Did you run this on all files that include clk-provider.h? I hope there
aren't similar situations in arch/arm/ for example.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] clk: Add __clk_hw_set_clk helper function

[Stephen Boyd]

On 02/12/15 05:58, Javier Martinez Canillas wrote:
 After the clk API change to return a per-user clock instance, both the
 struct clk_core and struct clk pointers from the hw clock needs to be
 assigned to clock that share the same state.

 In the future the struct clk_core will be removed and this is going to

s/clk_core/clk/?

 change again so to avoid having to change the assignments twice in all
 the drivers, add a helper function to have an indirection level.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

Reviewed-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] clk: composite: Set clk_core to composite rate and mux components

[Stephen Boyd]

On 02/11, Javier Martinez Canillas wrote:
 Commit 035a61c314eb3 (clk: Make clk API return per-user struct clk 
 instances)
 moved the clock state to struct clk_core to allow the clk API returning per
 user clk instances so now the struct clk_hw .core field is used instead of 
 .clk
 for most operations.
 
 But in case of composite clocks, the rate and mux components didn't have a 
 .core
 set which leads to a NULL pointer dereference in 
 clk_mux_determine_rate_flags():
 
 Unable to handle kernel NULL pointer dereference at virtual address 0034
 pgd = c0004000
 [0034] *pgd=
 Internal error: Oops: 5 [#1] PREEMPT SMP ARM
 Modules linked in:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
 3.19.0-next-20150211-2-g1fb7f0e1150d #423
 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 task: ee48 ti: ee488000 task.ti: ee488000
 PC is at clk_mux_determine_rate_flags+0x14/0x19c
 LR is at __clk_mux_determine_rate+0x24/0x2c
 pc : [c03a355c]lr : [c03a3734]psr: a113
 sp : ee489ce8  ip : ee489d84  fp : ee489d84
 r10: 005c  r9 : 0001  r8 : 016e3600
 r7 :   r6 :   r5 : ee442200  r4 : ee440c98
 r3 :   r2 :   r1 : 016e3600  r0 : ee440c98
 Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
 Control: 10c5387d  Table: 4000406a  DAC: 0015
 Process swapper/0 (pid: 1, stack limit = 0xee488210)
 Stack: (0xee489ce8 to 0xee48a000)
 9ce0:     6113 ee440c98 ee442200 
 9d00: 016e3600  0001 005c ee489d84 c03a3734 ee489d80 ee489d84
 9d20:  c048b130 0400 c03a5798 ee489d80 ee489d84 c0607f60 ffea
 9d40: 0001 0001 ee489d5c c003f844 c06e3340 ee402680 ee440d0c ed935000
 9d60: 016e3600 0003 0001 005c eded3700 c03a11a0 ee489d80 ee489d84
 9d80: 016e3600 ee402680 c05b413a eddc9900 016e3600 c03a1228  
 9da0:  eddc9900 016e3600 c03a1c1c  016e3600 ed8c6710 c03d6ce4
 9dc0: eded3400   c03c797c 0001 005c eded3700 eded3700
 9de0: 05e0 0001 005c c03db8ac c06e7e54 c03c8f08  c06e7e64
 9e00: c06b6e74 c06e7f64 05e0 c06e7df8 c06e5100  c06e7e6c c06e7f54
 9e20:   eebd9550  c06e7da0 c06e7e54 ee7b5010 c06e7da0
 9e40: eddc9690 c06e7db4 c06b6e74 0097  c03d4398  ee7b5010
 9e60: eebd9550 c06e7da0  c03db824 ee7b5010 fffe c06e7db4 c0299c7c
 9e80: ee7b5010 c072a05c  c0298858 ee7b5010 c06e7db4 ee7b5044 
 9ea0: eddc9580 c0298a04 c06e7db4  c0298978 c02971d4 ee405c78 ee732b40
 9ec0: c06e7db4 eded3800 c06d6738 c0298044 c0608300 c06e7db4  c06e7db4
 9ee0:  c06beb58 c06beb58 c0299024  c068dd00  c0008944
 9f00: 0038 c049013c ee462200 c0711920 ee48 6113 c06c2cb0 
 9f20:  c06c2cb0 6113  ef7fcafc  c0640194 c00389ec
 9f40: c05ec3a8 c063f824 0006 0006 c06c2c50 c0696444 0006 c0696424
 9f60: c06ee1c0 c066b588 c06b6e74 0097  c066bd44 0006 0006
 9f80: c066b588 c003d684  c0481938    
 9fa0:  c0481940  c000e680    
 9fc0:        
 9fe0:     0013   
 [c03a355c] (clk_mux_determine_rate_flags) from [c03a3734] 
 (__clk_mux_determine_rate+0x24/0x2c)
 [c03a3734] (__clk_mux_determine_rate) from [c03a5798] 
 (clk_composite_determine_rate+0xbc/0x238)
 [c03a5798] (clk_composite_determine_rate) from [c03a11a0] 
 (clk_core_round_rate_nolock+0x5c/0x9c)
 [c03a11a0] (clk_core_round_rate_nolock) from [c03a1228] 
 (__clk_round_rate+0x38/0x40)
 [c03a1228] (__clk_round_rate) from [c03a1c1c] (clk_round_rate+0x20/0x38)
 [c03a1c1c] (clk_round_rate) from [c03d6ce4] 
 (max98090_dai_set_sysclk+0x34/0x118)
 [c03d6ce4] (max98090_dai_set_sysclk) from [c03c797c] 
 (snd_soc_dai_set_sysclk+0x38/0x80)
 [c03c797c] (snd_soc_dai_set_sysclk) from [c03db8ac] 
 (snow_late_probe+0x24/0x48)
 [c03db8ac] (snow_late_probe) from [c03c8f08] 
 (snd_soc_register_card+0xf04/0x1070)
 [c03c8f08] (snd_soc_register_card) from [c03d4398] 
 (devm_snd_soc_register_card+0x30/0x64)
 [c03d4398] (devm_snd_soc_register_card) from [c03db824] 
 (snow_probe+0x68/0xcc)
 [c03db824] (snow_probe) from [c0299c7c] (platform_drv_probe+0x48/0x98)
 [c0299c7c] (platform_drv_probe) from [c0298858] 
 (driver_probe_device+0x114/0x234)
 [c0298858] (driver_probe_device) from [c0298a04] 
 (__driver_attach+0x8c/0x90)
 [c0298a04] (__driver_attach) from [c02971d4] (bus_for_each_dev+0x54/0x88)
 [c02971d4] (bus_for_each_dev) from [c0298044] (bus_add_driver+0xd8/0x1cc)
 [c0298044] (bus_add_driver) from [c0299024] (driver_register+0x78/0xf4)
 [c0299024] (driver_register) from [c0008944] (do_one_initcall+0x80/0x1d0)
 [c0008944] (do_one_initcall) from [c066bd44] 
 (kernel_init_freeable+0x10c/0x1d8)
 

Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

[Stephen Boyd]

Kept meaning to get back to this thread. Have you resolved it?

On 10/29/14 03:38, Marcin Jabrzyk wrote:
 So I've tried this patch, it resolves one problem but introduces also
 new ones. As expected the BUG warning is not showing after applying
 this patch but there are some interesting side effects.

Well that's half good news.

 I was looking on /proc/interrupts output. IRQ for CPU0 have MCT name
 and IRQ for CPU1 has unexpectedly no name at all.

This is pretty confusing. I don't see how the patch could cause this to
happen.

 After making hotplug cycle of CPU1 I've observed that IRQs attached
 originally for that CPU are generating on really low count and not in
 order with IRQ for CPU0.
 What's more the interrupt for CPU1 is showing to me as being counted
 for both CPUs, so it's probably not being attached to CPU1.


yeah. Can you give the output of /proc/timer_list in addition to
/proc/interrupts? It may give some hints on what's going on. It may also
be interesting to see if irq_force_affinity() is failing. Please check
the return value and print an error


diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 1800053b4644..3c4538e26731 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -450,6 +450,7 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
 {
struct mct_clock_event_device *mevt;
unsigned int cpu = smp_processor_id();
+   int ret;
 
mevt = container_of(evt, struct mct_clock_event_device, evt);
 
@@ -468,7 +469,9 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
enable_irq(evt-irq);
-   irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+   ret = irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], 
cpumask_of(cpu));
+   if (ret)
+   pr_err(force failed %d\n, ret);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] clk: exynos-audss: Fix memory leak on driver unbind or probe failure

[Stephen Boyd]

On 01/05/2015 01:52 AM, Krzysztof Kozlowski wrote:
 The memory allocated by basic clock divider/gate/mux (struct clk_gate,
 clk_divider and clk_mux) was leaking. During driver unbind or probe
 failure the driver only unregistered the clocks.

 Use clk_unregister_{gate,divider,mux} to release all resources.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com


Reviewed-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

[Stephen Boyd]

On 10/24/2014 06:22 AM, Marcin Jabrzyk wrote:


 On 23/10/14 20:41, Stephen Boyd wrote:
 On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
 The CPU notifier is called via notify_cpu_starting(), which is called
 with interrupts disabled, and a reason code of CPU_STARTING. 
 Interrupts
 at this point /must/ remain disabled.

 The Exynos code then goes on to call exynos4_local_timer_setup() which
 tries to reverse the free_irq() in exynos4_local_timer_stop() by
 calling
 request_irq().  Calling request_irq() with interrupts off has never
 been
 permissible.

 So, this code is wrong today, and it was also wrong when it was
 written.
 It /couldn't/ have been tested.  It looks like this commit added this
 buggy code:

 commit ee98d27df6827b5ba4bd99cb7d5cb1239b6a1a31
 Author: Stephen Boyd sb...@codeaurora.org
 Date:   Fri Feb 15 16:40:51 2013 -0800

  ARM: EXYNOS4: Divorce mct from local timer API

  Separate the mct local timers from the local timer API. This will
  allow us to remove ARM local timer support in the near future and
  gets us closer to moving this driver to drivers/clocksource.

  Acked-by: Kukjin Kim kgene@samsung.com
  Acked-by: Marc Zyngier marc.zyng...@arm.com
  Cc: Thomas Abraham thomas.abra...@linaro.org
  Signed-off-by: Stephen Boyd sb...@codeaurora.org

 I'm not so sure. It looks like in that patch I didn't change anything
 with respect to when things are called. In fact, it looks like we were
 calling setup_irq() there, but another patch around the same time
 changed that to request_irq()

 commit 7114cd749a12ff9fd64a2f6f04919760f45ab183
 Author: Chander Kashyap chander.kash...@linaro.org
 Date:   Wed Jun 19 00:29:35 2013 +0900

  clocksource: exynos_mct: use (request/free)_irq calls for local
 timer registration

  Replace the (setup/remove)_irq calls for local timer
 registration with
  (request/free)_irq calls. This generalizes the local timer
 registration API.
  Suggested by Mark Rutland.

  Signed-off-by: Chander Kashyap chander.kash...@linaro.org
  Acked-by: Mark Rutland mark.rutl...@arm.com
  Reviewed-by: Tomasz Figa t.f...@samsung.com
  Signed-off-by: Kukjin Kim kgene@samsung.com

 I don't believe setup_irq() allocates anything so we should probably go
 back to using that over request_irq() or explore requesting the irqs
 once and then enabling/disabling instead.


 So what would be a better way to handle this? Going back to setup_irq
 or trying to enable/disable irqs on CPU hotplug? As this touched low
 level things and it's rare case for setting/enabling irqs just after
 CPU is coming back to life again.


The safest thing is setup_irq(), but do you care to try this patch?
Doing the enable/disable is not as robust because request_irq() returns
with the irq enabled and then we have to disable the irq to make things
symmetric. This whole driver doesn't look like it's prepared for such a
situation where the interrupt triggers before the clockevent is
registered so this doesn't look like a problem in practice. Doing the
disable right after request is typically bad though, and may not pass
review.

8-

From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] clocksource: exynos_mct: Avoid scheduling while atomic

If we call request_irq() during the CPU_STARTING notifier we'll
try to allocate an irq descriptor with GFP_KERNEL while we're
running with irqs disabled. Just request the irqs at boot time
and enable/disable them when a CPU comes up or goes down to avoid
such problems.

Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
 drivers/clocksource/exynos_mct.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 9403061a2acc..1800053b4644 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -467,13 +467,7 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
 
if (mct_int_type == MCT_INT_SPI) {
evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
-   if (request_irq(evt-irq, exynos4_mct_tick_isr,
-   IRQF_TIMER | IRQF_NOBALANCING,
-   evt-name, mevt)) {
-   pr_err(exynos-mct: cannot register IRQ %d\n,
-   evt-irq);
-   return -EIO;
-   }
+   enable_irq(evt-irq);
irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
@@ -488,7 +482,7 @@ static void exynos4_local_timer_stop(struct 
clock_event_device *evt)
 {
evt-set_mode(CLOCK_EVT_MODE_UNUSED, evt);
if (mct_int_type == MCT_INT_SPI)
-   free_irq(evt-irq, this_cpu_ptr(percpu_mct_tick));
+   disable_irq(evt-irq);
else
disable_percpu_irq(mct_irqs

Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

[Stephen Boyd]

On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
 On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
 [1.] One line summary of the problem: BUG: sleeping function called from
 invalid context at mm/slub.c:1250 after CPU hotplug
 I'm really not surprised.

 When SoC have MCT_INT_SPI interrupt it is being allocated after hotplugging
 of the CPU, secondary_start_kernel() is sending CPU boot notifications which
 are send when preemption and interrupts are disabled. Exynos_mct
 notification handler tries to set up and allocate IRQ for SPI type interrupt
 for started CPU and then BUG appears.
 There might be similar problem on qcom-timer I think just after looking on
 the code.

There's no problem for qcom-timer because there are only PPIs on SMP
platforms.

 The CPU notifier is called via notify_cpu_starting(), which is called
 with interrupts disabled, and a reason code of CPU_STARTING.  Interrupts
 at this point /must/ remain disabled.

 The Exynos code then goes on to call exynos4_local_timer_setup() which
 tries to reverse the free_irq() in exynos4_local_timer_stop() by calling
 request_irq().  Calling request_irq() with interrupts off has never been
 permissible.

 So, this code is wrong today, and it was also wrong when it was written.
 It /couldn't/ have been tested.  It looks like this commit added this
 buggy code:

 commit ee98d27df6827b5ba4bd99cb7d5cb1239b6a1a31
 Author: Stephen Boyd sb...@codeaurora.org
 Date:   Fri Feb 15 16:40:51 2013 -0800

 ARM: EXYNOS4: Divorce mct from local timer API

 Separate the mct local timers from the local timer API. This will
 allow us to remove ARM local timer support in the near future and
 gets us closer to moving this driver to drivers/clocksource.

 Acked-by: Kukjin Kim kgene@samsung.com
 Acked-by: Marc Zyngier marc.zyng...@arm.com
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Signed-off-by: Stephen Boyd sb...@codeaurora.org

I'm not so sure. It looks like in that patch I didn't change anything
with respect to when things are called. In fact, it looks like we were
calling setup_irq() there, but another patch around the same time
changed that to request_irq()

commit 7114cd749a12ff9fd64a2f6f04919760f45ab183
Author: Chander Kashyap chander.kash...@linaro.org
Date:   Wed Jun 19 00:29:35 2013 +0900

clocksource: exynos_mct: use (request/free)_irq calls for local timer 
registration

Replace the (setup/remove)_irq calls for local timer registration with
(request/free)_irq calls. This generalizes the local timer registration API.
Suggested by Mark Rutland.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com

I don't believe setup_irq() allocates anything so we should probably go
back to using that over request_irq() or explore requesting the irqs
once and then enabling/disabling instead.

 A good question would be: why doesn't this happen at boot time when CPU1
 is first brought up?  The conditions here are no different from hotplugging
 CPU1 back in.  Do you see a similar warning on boot too?


Probably because such checks are completely avoided until the system
state is switched to SYSTEM_RUNNING (see the first if statement in
__might_sleep()). It would be nice if we could remove that.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up

[Stephen Boyd]

On 01/11, Tomasz Figa wrote:
 +
 +/**
 + * of_genpd_lock() - Lock access to of_genpd_providers list
 + */
 +static void of_genpd_lock(void)
 +{
 + mutex_lock(of_genpd_mutex);
 +}
 +
 +/**
 + * of_genpd_unlock() - Unlock access to of_genpd_providers list
 + */
 +static void of_genpd_unlock(void)
 +{
 + mutex_unlock(of_genpd_mutex);
 +}

Why do we need these functions? Can't we just call
mutex_lock/unlock directly?

 +
 +/**
 + * of_genpd_add_provider() - Register a domain provider for a node
 + * @np: Device node pointer associated with domain provider
 + * @genpd_src_get: callback for decoding domain
 + * @data: context pointer for @genpd_src_get callback.

These look a little outdated.

 + */
 +int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
 +   void *data)
 +{
 + struct of_genpd_provider *cp;
 +
 + cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);

Please use sizeof(*cp) instead.

 + if (!cp)
 + return -ENOMEM;
 +
 + cp-node = of_node_get(np);
 + cp-data = data;
 + cp-xlate = xlate;
 +
 + of_genpd_lock();
 + list_add(cp-link, of_genpd_providers);
 + of_genpd_unlock();
 + pr_debug(Added domain provider from %s\n, np-full_name);
 +
 + return 0;
 +}
 +EXPORT_SYMBOL_GPL(of_genpd_add_provider);
 +
[...]
 +
 +/* See of_genpd_get_from_provider(). */
 +static struct generic_pm_domain *__of_genpd_get_from_provider(
 + struct of_phandle_args *genpdspec)
 +{
 + struct of_genpd_provider *provider;
 + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);

Can this be -EPROBE_DEFER so that we can defer probe until a
later time if the power domain provider hasn't registered yet?

 +
 + /* Check if we have such a provider in our array */
 + list_for_each_entry(provider, of_genpd_providers, link) {
 + if (provider-node == genpdspec-np)
 + genpd = provider-xlate(genpdspec, provider-data);
 + if (!IS_ERR(genpd))
 + break;
 + }
 +
 + return genpd;
 +}
 +
[...]
 +static int of_genpd_notifier_call(struct notifier_block *nb,
 +   unsigned long event, void *data)
 +{
 + struct device *dev = data;
 + int ret;
 +
 + if (!dev-of_node)
 + return NOTIFY_DONE;
 +
 + switch (event) {
 + case BUS_NOTIFY_BIND_DRIVER:
 + ret = of_genpd_add_to_domain(dev);
 + break;
 +
 + case BUS_NOTIFY_UNBOUND_DRIVER:
 + ret = of_genpd_del_from_domain(dev);
 + break;
 +
 + default:
 + return NOTIFY_DONE;
 + }
 +
 + return notifier_from_errno(ret);
 +}
 +
 +static struct notifier_block of_genpd_notifier_block = {
 + .notifier_call = of_genpd_notifier_call,
 +};
 +
 +static int of_genpd_init(void)
 +{
 + return bus_register_notifier(platform_bus_type,
 + of_genpd_notifier_block);
 +}
 +core_initcall(of_genpd_init);

Would it be possible to call the of_genpd_add_to_domain() and
of_genpd_del_from_domain() functions directly in the driver core,
similar to how the pinctrl framework has a hook in there? That
way we're not relying on any initcall ordering for this.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up

[Stephen Boyd]

On 01/20, Tomasz Figa wrote:
 Hi Kevin,
 
 On 14.01.2014 16:42, Kevin Hilman wrote:
 Tomasz Figa tomasz.f...@gmail.com writes:
 
 This patch introduces generic code to perform power domain look-up using
 device tree and automatically bind devices to their power domains.
 Generic device tree binding is introduced to specify power domains of
 devices in their device tree nodes.
 
 Backwards compatibility with legacy Samsung-specific power domain
 bindings is provided, but for now the new code is not compiled when
 CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
 will change as soon as Exynos power domain code gets converted to use
 the generic framework in further patch.
 
 Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
 
 I haven't read through this in detail yet, but wanted to make sure that
 the DT representation can handle nested power domains.  At least
 SH-mobile has a hierarchy of power domains and the genpd code can handle
 that, so wanted to make sure that the DT representation can handle it as
 well.
 
 The representation of power domains themselves as implied by this
 patch is fully platform-specific. The only generic part is the
 #power-domain-cells property, which defines the number of cells
 needed to identify the power domain of given provider. You are free
 to have any platform-specific properties (or even generic ones,
 added on top of this patch) to let you specify the hierarchy in DT.
 

(Semi-related to this thread, but not really the patchset)

I'd like to have a way to say that this power domain is a
subdomain of another domain provided by a different power domain
provider driver. From what I can tell, the only way to reparent
domains as of today is by name or reference and you have to make
a function call to do it (pm_genpd_add_subdomain_names() or
pm_genpd_add_subdomain()). This is annoying in the case where all
the power domains are not regsitered within the same driver
because we don't know which driver comes first.

It would be great if there was a way to specify this relationship
explicitly when initializing a power domain so that the
reparenting is done automatically without requiring any explicit
function call. Perhaps DT could specify this? Or we could add
another field to the generic_power_domain struct like parent_name?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clocksource: exynos_mct: Set IRQ affinity when the CPU goes online

[Stephen Boyd]

On 08/26, Tomasz Figa wrote:
 Some variants of Exynos MCT, namely exynos4210-mct at the moment, use
 normal, shared interrupts for local timers. This means that each
 interrupt must have correct affinity set to fire only on CPU
 corresponding to given local timer.
 
 However after recent conversion of clocksource drivers to not use the
 local timer API for local timer initialization any more, the point of
 time when local timers get initialized changed and irq_set_affinity()
 fails because the CPU is not marked as online yet.
 
 This patch fixes this by moving the call to irq_set_affinity() to
 CPU_ONLINE notification, so the affinity is being set when the CPU goes
 online.
 
 This fixes a problem with Exynos4210 failing to boot, present since commit
   ee98d27df6 ARM: EXYNOS4: Divorce mct from local timer API
 due to failing irq_set_affinity().
 
 Signed-off-by: Tomasz Figa t.f...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---

Looks good to me if you want to go this route.

Acked-by: Stephen Boyd sb...@codeaurora.org

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] irqchip: gic: Allow setting affinity to offline CPUs

[Stephen Boyd]

On 08/20/13 09:11, Tomasz Figa wrote:
 Sometimes it is necessary to fix interrupt affinity to an offline CPU,
 for example in initialization of local timers. This patch modifies
 .set_affinity() operation of irq-gic driver to fall back to any possible
 CPU if no online CPU can be found in requested CPU mask.

 This fixes broken Exynos4210 support since commit
   ee98d27df6 ARM: EXYNOS4: Divorce mct from local timer API
 caused by timer initialization code unable to set affinity for local
 timer interrupts.

Care to elaborate further? I don't see how the interrupt affinity is set
for a CPU that isn't online because the mct code runs on the CPU that
the affinity is being set to.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] irqchip: gic: Allow setting affinity to offline CPUs

[Stephen Boyd]

On 08/20/13 09:41, Tomasz Figa wrote:
 On Tuesday 20 of August 2013 09:33:31 Stephen Boyd wrote:
 On 08/20/13 09:11, Tomasz Figa wrote:
 Sometimes it is necessary to fix interrupt affinity to an offline CPU,
 for example in initialization of local timers. This patch modifies
 .set_affinity() operation of irq-gic driver to fall back to any
 possible
 CPU if no online CPU can be found in requested CPU mask.

 This fixes broken Exynos4210 support since commit

 ee98d27df6 ARM: EXYNOS4: Divorce mct from local timer API

 caused by timer initialization code unable to set affinity for local
 timer interrupts.
 Care to elaborate further? I don't see how the interrupt affinity is set
 for a CPU that isn't online because the mct code runs on the CPU that
 the affinity is being set to.
 Well, please look at secondary_start_kernel() in arch/arm/kernel/smp.c [1]. 
 You can see that notify_cpu_starting() (line 348) that fires the notifier 
 registered in MCT driver is called before set_cpu_online() (line 359) that 
 marks the CPU as online. Also notice that, originally, local timer 
 initialization was happening after set_cpu_online() - see line 365.



Great, thank you. Please put this information in the commit text next time.

I wonder if we shouldn't make the cpumask_any_and() work on the present
mask instead? If we ever support physical hotplug on ARM I think we
wouldn't want to allow interrupts to go to CPUs that aren't even present
(but still possible).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] irqchip: gic: Allow setting affinity to offline CPUs

[Stephen Boyd]

On 08/21, Tomasz Figa wrote:
 On Tuesday 20 of August 2013 22:14:42 Russell King - ARM Linux wrote:
  On Tue, Aug 20, 2013 at 06:11:10PM +0200, Tomasz Figa wrote:
   Sometimes it is necessary to fix interrupt affinity to an offline CPU,
   for example in initialization of local timers. This patch modifies
   .set_affinity() operation of irq-gic driver to fall back to any
   possible CPU if no online CPU can be found in requested CPU mask.
  
  Err, this is a bad idea.  If a CPU is offline, then it must not respond
  to interrupts.  If you bind an interrupt to an offline CPU, and that
  device asserts its interrupt, what happens?  It doesn't get serviced
  until that CPU comes back online, which may be a very long time.
  
  If, for example, that is your network device, it would mean your
  network stops operating.  Worse, the network layer will time out and
  reset the ethernet device, trying to get things working (which it
  won't.)
  
  I think how I used to handle this case prior to genirq is that I fell
  back to any online CPU if the interrupt ended up only routed to offline
  CPUs, but when an offline CPU comes back, it could then be re-routed
  back to that CPU.  In other words, the mask change was non-destructive.
  
  I think with genirq, such mask changes are destructive.
 
 Yes, that's correct. Although if you _explicitly_ request the interrupt to 
 be routed to an offline CPU (i.e. only offline CPUs have bits set in 
 passed cpumask), is it an error?
 
 There is at least one irqchip that does not check received cpumask for 
 this (metag) and I don't see any documentation saying what should happen 
 in this case in .set_affinity operation.
 
 Still, if you have any better solution for the original problem (broken 
 Exynos4210 local timers, due to failing irq_set_affinity()), then I'd 
 appreciate it, as I don't like the one from this patch too much either.
 

One solution might be to change the irq affinity after the CPU
is marked online via the hotplug notifier chain. For a short
period of time the timer interrupt will go to a different CPU but
I don't see how that is a problem.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: timer: Shutdown clock event device when stopping local timer

[Stephen Boyd]

On 03/29/13 02:24, ning.n.ji...@gmail.com wrote:
 From: Ning Jiang ning.n.ji...@gmail.com

 Currently there are two problems when we try to stop local timer.
 First, it calls set_mode function directly so mode state is not
 updated for the clock event device. Second, it makes the device
 unused instead of shutdown.

What device is this a problem on? I believe this only matters to drivers
which enable their timer in their set_next_event() callback? But even
then, does anything actually happen because the interrupt should have
been disabled in the local timer stop callback.


 A subtle error will happen because of it. When a cpu is plugged out
 it will stop the local timer. It will call tick_nohz_idle_enter()
 in idle thread afterwards. It will cancel the sched timer and try
 to reprogram the next event. This is wrong since the local timer
 is supposed to be stopped.

 The right way to stop the local timer is to shutdown it by calling
 clockevents_set_mode(). Thus when we try to reprogram the clock
 event device, it will return directly without doing anything since
 the clock mode is CLOCK_EVT_MODE_SHUTDOWN.

While this prevents the set_next_event() callback from being called on a
dying CPU, wouldn't it be better to fix this problem in the core code
once instead of fixing it many times in each local timer driver? It
doesn't seem to make much sense to program an event on a CPU that is
about to die, so why do we do that?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412

[Stephen Boyd]

On 8/28/2012 4:13 AM, Tomasz Figa wrote:
 diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
 index 36c3984..1114ced 100644
 --- a/arch/arm/mach-exynos/platsmp.c
 +++ b/arch/arm/mach-exynos/platsmp.c
 @@ -34,8 +34,19 @@
  
  extern void exynos4_secondary_startup(void);
  
 -#define CPU1_BOOT_REG(samsung_rev() == EXYNOS4210_REV_1_1 ? \
 - S5P_INFORM5 : S5P_VA_SYSRAM)
 +static inline volatile void *cpu_boot_reg_base(void)

__iomem?

 +{
 + if (soc_is_exynos4210()  samsung_rev() == EXYNOS4210_REV_1_1)
 + return S5P_INFORM5;
 + return S5P_VA_SYSRAM;
 +}
 +
 +static inline volatile void *cpu_boot_reg(int cpu)

__iomem? And why volatile?

 +{
 + if (soc_is_exynos4412())
 + return cpu_boot_reg_base() + 4*cpu;
 + return cpu_boot_reg_base();
 +}
  
  /*
   * control for which core is the next to come out of the secondary
 @@ -195,6 +208,8 @@ void __init platform_smp_prepare_cpus(unsigned int 
 max_cpus)
* until it receives a soft interrupt, and then the
* secondary CPU branches to this address.
*/
 - __raw_writel(virt_to_phys(exynos4_secondary_startup),
 - CPU1_BOOT_REG);
 + for (i = 1; i  max_cpus; ++i) {
 + __raw_writel(virt_to_phys(exynos4_secondary_startup),
 + cpu_boot_reg(i));

Do you need to use cpu_logical_map()?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] i2c: s3c2410: Keep a copy of platform data and use it

[Stephen Boyd]

On 9/12/2011 9:16 PM, Thomas Abraham wrote:
 @@ -809,6 +810,15 @@ static int s3c24xx_i2c_probe(struct platform_device 
 *pdev)
   return -ENOMEM;
   }
  
 + i2c-pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
 + if (!i2c-pdata) {
 + ret = -ENOMEM;
 + goto err_noclk;
 + }
 +
 + if (pdata)
 + memcpy(i2c-pdata, pdata, sizeof(*pdata));
 +

Is there a devm_kmemdup()? If not, maybe it would be a good idea to add it.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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: platsmp: Allow secondary cpu hotplug with maxcpus=1

[Stephen Boyd]

On 6/30/2011 6:11 AM, Russell King - ARM Linux wrote:
 On Wed, Jun 29, 2011 at 11:31:39AM -0700, Stephen Boyd wrote:
  void __init platform_smp_prepare_cpus(unsigned int max_cpus)
  {
 -int i;
 -
  /*
   * Initialise the present map, which describes the set of CPUs
   * actually populated at the present time.
   */
 -for (i = 0; i  max_cpus; i++)
 -set_cpu_present(i, true);
 +init_cpu_present(cpu_possible_map);
 Ok, if we're now doing this in every platform, it might as well go into
 arch/arm/kernel/smp.c - platforms can re-initialize the present map
 in this callback if they need to do something different.

That sounds better. V2 coming soon.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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: platsmp: Allow secondary cpu hotplug with maxcpus=1

[Stephen Boyd]

If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Fix this by always calling platform_smp_prepare_cpus() as long as
max_cpus is non-zero (0 means no SMP) to allow platform code to
decide if any non-boot cpus are present in the system. Since
all current platform code doesn't support physical hotplug we
have a situation where possible == present and thus we can
simply copy the possible map to the present map.

With this patch it's possible to boot an ARM system with
maxcpus=1 on the command line and then hotplug in secondary cpus
via sysfs. This is more in line with how x86 works with maxcpus=1
on the command line.

Signed-off-by: Stephen Boyd sb...@codeaurora.org
---

This patch was tested along with an MSM patch:

  https://lkml.org/lkml/2011/4/7/354

I don't have any non-MSM hardware to test on so Acks and
tested-bys are welcome.

 arch/arm/kernel/smp.c |3 +--
 arch/arm/mach-exynos4/platsmp.c   |5 +
 arch/arm/mach-msm/platsmp.c   |5 +
 arch/arm/mach-omap2/omap-smp.c|5 +
 arch/arm/mach-realview/platsmp.c  |5 +
 arch/arm/mach-shmobile/platsmp.c  |5 +
 arch/arm/mach-tegra/platsmp.c |5 +
 arch/arm/mach-ux500/platsmp.c |5 +
 arch/arm/mach-vexpress/ct-ca9x4.c |5 +
 9 files changed, 9 insertions(+), 34 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index e7f92a4..fbaa24a 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -365,8 +365,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 */
if (max_cpus  ncores)
max_cpus = ncores;
-
-   if (max_cpus  1) {
+   if (ncores  1  max_cpus) {
/*
 * Enable the local timer or broadcast device for the
 * boot CPU, but only if we have more than one CPU.
diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
index c5e65a0..3f870d2 100644
--- a/arch/arm/mach-exynos4/platsmp.c
+++ b/arch/arm/mach-exynos4/platsmp.c
@@ -154,14 +154,11 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
scu_enable(scu_base_addr());
 
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 2034098..84e293f 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -157,12 +157,9 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 }
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index ecfe93c..5895d19 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -125,14 +125,11 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
/*
 * Initialise the SCU and wake up the secondary core using
diff --git a/arch/arm/mach-realview/platsmp.c b/arch/arm/mach-realview/platsmp.c
index 963bf0d..00666be 100644
--- a/arch/arm/mach-realview/platsmp.c
+++ b/arch/arm/mach-realview/platsmp.c
@@ -68,14 +68,11 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
/*
 * Initialise the present map, which describes the set of CPUs
 * actually populated at the present time.
 */
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
scu_enable(scu_base_addr());
 
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index f3888fe..ca5b523 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -64,10 +64,7 @@ void __init smp_init_cpus(void)
 
 void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 {
-   int i;
-
-   for (i = 0; i  max_cpus; i++)
-   set_cpu_present(i, true);
+   init_cpu_present(cpu_possible_map);
 
shmobile_smp_prepare_cpus();
 }
diff --git

Re: [PATCH] TWD: enable one-shot mode

[Stephen Boyd]

On 01/11/2011 03:52 AM, Russell King - ARM Linux wrote:
 On Mon, Jan 10, 2011 at 09:12:36PM -0800, Stephen Boyd wrote:

 I see this patch was already tested and merged but can you elaborate on
 why this was done? From what I understand, NOHZ selects one-shot (like
 is done in this patch), so why don't the machines with a TWD choose NOHZ
 or high res timers?

 You're right - so it's not actually required.  It should probably be
 reverted, though it does no damage...

Now I'm wondering why there are other 'select TICK_ONESHOT' lines in
arch/arm/Kconfig. Can we just remove them all? Otherwise it feels like
we're making it confusing for others later on.

-8---[cut here]8-
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e2f8011..7750a78 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -532,7 +532,6 @@ config ARCH_MMP
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
-   select TICK_ONESHOT
select PLAT_PXA
select SPARSE_IRQ
help
@@ -613,7 +612,6 @@ config ARCH_PXA
select ARCH_REQUIRE_GPIOLIB
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
-   select TICK_ONESHOT
select PLAT_PXA
select SPARSE_IRQ
help
@@ -668,7 +666,6 @@ config ARCH_SA1100
select GENERIC_CLOCKEVENTS
select HAVE_CLK
select HAVE_SCHED_CLOCK
-   select TICK_ONESHOT
select ARCH_REQUIRE_GPIOLIB
help
  Support for StrongARM 11x0 based boards.
@@ -1300,7 +1297,6 @@ config HAVE_ARM_SCU
 config HAVE_ARM_TWD
bool
depends on SMP
-   select TICK_ONESHOT
help
  This options enables support for the ARM timer and watchdog unit

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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] TWD: enable one-shot mode

[Stephen Boyd]

On 12/24/2010 11:18 AM, Russell King - ARM Linux wrote:
 Allow one shot timer mode to be used with the TWD.  This allows
 NOHZ mode to be used on SMP systems using the TWD localtimer.

 Tested on Versatile Express.

 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 ---
 Acks/Tested-by's would be appreciated, thanks.


I see this patch was already tested and merged but can you elaborate on
why this was done? From what I understand, NOHZ selects one-shot (like
is done in this patch), so why don't the machines with a TWD choose NOHZ
or high res timers?

Putting it another way, if my machine supports a oneshot capable
clockevent device should I be selecting oneshot regardless of the NOHZ
and high res config option being chosen?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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