Re: [PATCH 5/6] thermal:exynos4: Enable support for Exynos4412 SoCs
On 22 April 2013 11:55, amit kachhap wrote:
> Hi,
>
> I have one suggestion,
>
> On Fri, Apr 19, 2013 at 10:08 PM, Lukasz Majewski
> wrote:
>> Enable TMU support for Exynos4412 based target with device tree.
>>
>> Signed-off-by: Lukasz Majewski
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/thermal/exynos_thermal.c |4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> index e922fa4..f54066d 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -819,6 +819,10 @@ static const struct of_device_id exynos_tmu_match[] = {
>> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
>> },
>> {
>> + .compatible = "samsung,exynos4412-tmu",
>> + .data = (void *)EXYNOS_TMU_DRV_DATA,
>> + },
> Instead of adding a new compatible string, "exynos5250-tmu" name can
> be re-used in the 4412 DT node file as 4412 and 5250 TMU controller
> are same.
In cases where they are the same, it was generally the previous
version of SoC that was added to the compatible list and re-used in
the higher ones. IIRC, in cases where exynos5 based string was already
defined a separate compatible string was added for exynos4 too (even
if they used same driver data).
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] thermal:exynos4: Enable support for Exynos4412 SoCs
Hi amit,
> Hi,
>
> I have one suggestion,
>
> On Fri, Apr 19, 2013 at 10:08 PM, Lukasz Majewski
> wrote:
> > Enable TMU support for Exynos4412 based target with device tree.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/thermal/exynos_thermal.c |4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/thermal/exynos_thermal.c
> > b/drivers/thermal/exynos_thermal.c index e922fa4..f54066d 100644
> > --- a/drivers/thermal/exynos_thermal.c
> > +++ b/drivers/thermal/exynos_thermal.c
> > @@ -819,6 +819,10 @@ static const struct of_device_id
> > exynos_tmu_match[] = { .data = (void *)EXYNOS4210_TMU_DRV_DATA,
> > },
> > {
> > + .compatible = "samsung,exynos4412-tmu",
> > + .data = (void *)EXYNOS_TMU_DRV_DATA,
> > + },
> Instead of adding a new compatible string, "exynos5250-tmu" name can
> be re-used in the 4412 DT node file as 4412 and 5250 TMU controller
> are same.
Good point.
>
> Thanks,
> Amit Daniel
> > + {
> > .compatible = "samsung,exynos5250-tmu",
> > .data = (void *)EXYNOS_TMU_DRV_DATA,
> > },
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-samsung-soc" in the body of a message to
> > majord...@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
--
Best regards,
Lukasz Majewski
Samsung R&D Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] thermal:exynos4: Enable support for Exynos4412 SoCs
Hi,
I have one suggestion,
On Fri, Apr 19, 2013 at 10:08 PM, Lukasz Majewski
wrote:
> Enable TMU support for Exynos4412 based target with device tree.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> ---
> drivers/thermal/exynos_thermal.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index e922fa4..f54066d 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -819,6 +819,10 @@ static const struct of_device_id exynos_tmu_match[] = {
> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
> },
> {
> + .compatible = "samsung,exynos4412-tmu",
> + .data = (void *)EXYNOS_TMU_DRV_DATA,
> + },
Instead of adding a new compatible string, "exynos5250-tmu" name can
be re-used in the 4412 DT node file as 4412 and 5250 TMU controller
are same.
Thanks,
Amit Daniel
> + {
> .compatible = "samsung,exynos5250-tmu",
> .data = (void *)EXYNOS_TMU_DRV_DATA,
> },
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [Suggestion] ARM:S5pv210: compiling issue for s5pv210 by using randconfig
On 2013年04月17日 18:02, Russell King - ARM Linux wrote: > On Wed, Apr 17, 2013 at 05:25:34PM +0800, Chen Gang wrote: >> CONFIG_CPU_ARM7TDMI=y >> CONFIG_CPU_ARM9TDMI=y >> CONFIG_CPU_V7=y >> CONFIG_CPU_32v4T=y >> CONFIG_CPU_32v6K=y >> CONFIG_CPU_32v7=y > > This is an invalid configuration. A single kernel can not support ARMv7 > and ARMv4T simultaneously. > > The problem is caused by MMU=n, which exposes the CPU_ARM7TDMI and > CPU_ARM9TDMI options, which in turn select 32v4T. This is in turn > caused by the incomplete integration of uclinux. > > I think the only thing which can be done is to remove the ARM9TDMI > support code, which doesn't seem to be used by anything, and adjust > ARM7TDMI so that it isn't visible, but is selected by ARCH_AT91X40 > (which seems to be its only user.) > > Here's the slightly smaller version of that: > I apply your patch below. and also let CONFIG_MMU=y in menuconfig (just Arnd suggested). it passes compilation. I prefer to let the patch below to integrate into next-tree. if I should do it (e.g. need send the patch again in normal way), I should try. thanks. gchen. > diff --git a/arch/arm/mach-at91/Kconfig.non_dt > b/arch/arm/mach-at91/Kconfig.non_dt > index 6c24985..dc972e1 100644 > --- a/arch/arm/mach-at91/Kconfig.non_dt > +++ b/arch/arm/mach-at91/Kconfig.non_dt > @@ -47,6 +47,7 @@ config ARCH_AT91X40 > select ARCH_USES_GETTIMEOFFSET > select MULTI_IRQ_HANDLER > select SPARSE_IRQ > + select CPU_ARM7TDMI > > endchoice > > diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig > index cb812a1..deb6c6a 100644 > --- a/arch/arm/mm/Kconfig > +++ b/arch/arm/mm/Kconfig > @@ -6,7 +6,7 @@ comment "Processor Type" > > # ARM7TDMI > config CPU_ARM7TDMI > - bool "Support ARM7TDMI processor" > + bool > depends on !MMU > select CPU_32v4T > select CPU_ABRT_LV4T > @@ -56,7 +56,7 @@ config CPU_ARM740T > > # ARM9TDMI > config CPU_ARM9TDMI > - bool "Support ARM9TDMI processor" > + bool > depends on !MMU > select CPU_32v4T > select CPU_ABRT_NOMMU > > > -- Chen Gang Asianux Corporation -- 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] drm/exynos: enable FIMD clocks
Hi, Mr. Vikas
Please fix the below typos Viresh pointed out and my comments.
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Monday, April 01, 2013 5:51 PM
> To: Vikas Sajjan
> Cc: dri-de...@lists.freedesktop.org; linux-samsung-soc@vger.kernel.org;
> jy0922.s...@samsung.com; inki@samsung.com; kgene@samsung.com;
> linaro-ker...@lists.linaro.org; linux-me...@vger.kernel.org
> Subject: Re: [PATCH v3] drm/exynos: enable FIMD clocks
>
> On 1 April 2013 14:13, Vikas Sajjan wrote:
> > While migrating to common clock framework (CCF), found that the FIMD
> clocks
>
> s/found/we found/
>
> > were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > drivers, then such clock(s) are PULLed low by CCF.
> >
> > By calling clk_prepare_enable() for FIMD clocks fixes the issue.
>
> s/By calling/Calling/
>
> and
>
> s/the/this
>
> > this patch also replaces clk_disable() with clk_disable_unprepare()
>
> s/this/This
>
> > during exit.
>
> Sorry but your log doesn't say what you are doing. You are just adding
> relevant calls to clk_prepare/unprepare() before calling
> clk_enable/disable.
>
> > Signed-off-by: Vikas Sajjan
> > ---
> > Changes since v2:
> > - moved clk_prepare_enable() and clk_disable_unprepare() from
> > fimd_probe() to fimd_clock() as suggested by Inki Dae
>
> > Changes since v1:
> > - added error checking for clk_prepare_enable() and also
replaced
> > clk_disable() with clk_disable_unprepare() during exit.
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 9537761..f2400c8 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -799,18 +799,18 @@ static int fimd_clock(struct fimd_context *ctx,
> bool enable)
> > if (enable) {
> > int ret;
> >
> > - ret = clk_enable(ctx->bus_clk);
> > + ret = clk_prepare_enable(ctx->bus_clk);
> > if (ret < 0)
> > return ret;
> >
> > - ret = clk_enable(ctx->lcd_clk);
> > + ret = clk_prepare_enable(ctx->lcd_clk);
> > if (ret < 0) {
> > - clk_disable(ctx->bus_clk);
> > + clk_disable_unprepare(ctx->bus_clk);
> > return ret;
> > }
> > } else {
> > - clk_disable(ctx->lcd_clk);
> > - clk_disable(ctx->bus_clk);
> > + clk_disable_unprepare(ctx->lcd_clk);
> > + clk_disable_unprepare(ctx->bus_clk);
> > }
> >
> > return 0;
> > @@ -981,8 +981,8 @@ static int fimd_remove(struct platform_device *pdev)
> > if (ctx->suspended)
> > goto out;
> >
> > - clk_disable(ctx->lcd_clk);
> > - clk_disable(ctx->bus_clk);
> > + clk_disable_unprepare(ctx->lcd_clk);
> > + clk_disable_unprepare(ctx->bus_clk);
Just remove the above codes. It seems that clk_disable(also
clk_disable_unprepare) isn't needed because it will be done by
pm_runtime_put_sync and please re-post it(probably patch v5??)
Thanks,
Inki Dae
>
> You are doing things at the right place but i have a suggestion. Are you
> doing
> anything in your clk_prepare() atleast for this device? Probably not.
>
> If not, then its better to call clk_prepare/unprepare only once at
> probe/remove
> and keep clk_enable/disable calls as is.
>
> --
> viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On 21 April 2013 20:13, Tomasz Figa wrote:
> 3) after those two changes, all that remains is to fix compliance with
> Common Clock Framework, in other words:
>
> s/clk_enable/clk_prepare_enable/
>
> and
>
> s/clk_disable/clk_disable_unprepare/
We don't have to call clk_{un}prepare() everytime for your platform as
you aren't doing anything in it. So just call them once at probe/remove and
call clk_enable/disable everywhere else.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] thermal:exynos4: Add documentation for Exynos SoC thermal bindings
Hi Lukasz, Thanks for adding this. Some comments inline. On 19 April 2013 22:08, Lukasz Majewski wrote: > Proper description for Exynos4 bindings added to Documentation/devicetree/ > bindings > > Signed-off-by: Lukasz Majewski > Signed-off-by: Kyungmin Park > --- > .../devicetree/bindings/thermal/exynos-thermal.txt | 22 > > 1 file changed, 22 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > new file mode 100644 > index 000..e994e1e > --- /dev/null > +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > @@ -0,0 +1,22 @@ > +* Exynos Thermal How about "Exynos Thermal Management Unit (TMU)"? > + > +Required properties: > +- compatible : "samsung,exynos4412-tmu" Should be one of the following: "samsung,exynos4210-tmu" "samsung,exynos4412-tmu" "samsung,exynos5250-tmu" > +- interrupts-parent : The phandle for the interrupt controller s/interrupts-parent /interrupt-parent > +- reg : Address range of the thermal registers > +- interrupts : Should contain interrupt for thermal system > +- clocks : The main clock for TMU device > +- clocks-names : Thermal system clock name s/clocks-names /clock-names You may also choose to add "from common clock binding" for clocks and clock-names properties above. > +- status : Initial state of the device You may remove this as it is quite obvious now. Even if you want to retain this, it should be under 'Optional properties:' -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: Enable TMU on SMDK4412 board
Enables TMU on SMDK4412 board.
Signed-off-by: Sachin Kamat
---
Dependent on:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17630.html
---
arch/arm/boot/dts/exynos4412-smdk4412.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts
b/arch/arm/boot/dts/exynos4412-smdk4412.dts
index a8ba195..d0b80f2 100644
--- a/arch/arm/boot/dts/exynos4412-smdk4412.dts
+++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
@@ -27,6 +27,10 @@
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC1,115200 init=/linuxrc";
};
+ tmu@100C {
+ status = "okay";
+ };
+
g2d@1080 {
status = "okay";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: Enable TMU on Origen4412 board
Enables TMU on Origen4412 board.
Signed-off-by: Sachin Kamat
---
Dependent on:
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17630.html
---
arch/arm/boot/dts/exynos4412-origen.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index ca73c42..00104ea 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -98,6 +98,10 @@
};
};
+ tmu@100C {
+ status = "okay";
+ };
+
g2d@1080 {
status = "okay";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: Enable TMU on Origen4210 board
Enables TMU on Origen4210 board.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210-origen.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 524b908..8b0a781 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -41,6 +41,10 @@
enable-active-high;
};
+ tmu@100C {
+ status = "okay";
+ };
+
sdhci@1253 {
bus-width = <4>;
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sd2_cd>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: Add TMU clock entries to exynos4210.dtsi
Adds TMU clock entries to exynos4210.dtsi file.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210.dtsi |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 50ab9d4..53654c4 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -111,6 +111,9 @@
interrupt-parent = <&combiner>;
reg = <0x100C 0x100>;
interrupts = <2 4>;
+ clocks = <&clock 383>;
+ clock-names = "tmu_apbif";
+ status = "disabled";
};
g2d@1280 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] thermal:exynos4: TMU device tree support for Exynos4412 targets
Hi Lukasz,
On 19 April 2013 22:08, Lukasz Majewski wrote:
> Device tree support for TMU at Exynos4x12 targets.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
nit: Subject for these kind of patches should start with "ARM: dts: ..."
Otherwise looks good to me.
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index e3380a7..ee920b3 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -79,4 +79,14 @@
> interrupts = <0 89 0>;
> status = "disabled";
> };
> +
> + tmu@100C {
> + compatible = "samsung,exynos4412-tmu";
> + interrupt-parent = <&combiner>;
> + reg = <0x100C 0x100>;
> + interrupts = <2 4>;
> + clocks = <&clock 383>;
> + clock-names = "tmu_apbif";
> + status = "disabled";
> + };
> };
> --
> 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
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] clk: exynos4: Add clock entries for TMU
Added clock entries for thermal management unit (TMU) for
Exynos4 SoCs.
Signed-off-by: Sachin Kamat
Cc: Thomas Abraham
Cc: Mike Turquette
---
Should be applied on top of the below patches:
https://patchwork.kernel.org/patch/2448711/
https://patchwork.kernel.org/patch/2459831/
Changes since v1:
Changed clock name 'tmu' to 'tmu_apbif' as per the SoC user manual.
---
.../devicetree/bindings/clock/exynos4-clock.txt|1 +
drivers/clk/samsung/clk-exynos4.c |4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index 14d5c2a..8fc1151 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
spi0_isp_sclk 380 Exynos4x12
spi1_isp_sclk 381 Exynos4x12
uart_isp_sclk 382 Exynos4x12
+ tmu_apbif 383
[Mux Clocks]
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 09cf161..0be7d05 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -170,7 +170,7 @@ enum exynos4_clks {
gicisp, smmu_isp, smmu_drc, smmu_fd, smmu_lite0, smmu_lite1, mcuctl_isp,
mpwm_isp, i2c0_isp, i2c1_isp, mtcadc_isp, pwm_isp, wdt_isp, uart_isp,
asyncaxim, smmu_ispcx, spi0_isp, spi1_isp, pwm_isp_sclk, spi0_isp_sclk,
- spi1_isp_sclk, uart_isp_sclk,
+ spi1_isp_sclk, uart_isp_sclk, tmu_apbif,
/* mux clocks */
mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
@@ -815,6 +815,7 @@ static struct samsung_gate_clock exynos4210_gate_clks[]
__initdata = {
GATE_A(keyif, "keyif", "aclk100", E4210_GATE_IP_PERIR, 16, 0, 0,
"keypad"),
GATE_DA(sclk_fimd1, "exynos4-fb.1", "sclk_fimd1", "div_fimd1",
E4210_SRC_MASK_LCD1, 0, CLK_SET_RATE_PARENT, 0,
"sclk_fimd"),
+ GATE(tmu_apbif, "tmu_apbif", "aclk100", E4210_GATE_IP_PERIR, 17, 0, 0),
};
/* list of gate clocks supported in exynos4x12 soc */
@@ -915,6 +916,7 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
GATE(spi1_isp, "spi1_isp", "aclk200", E4X12_GATE_ISP1, 13,
CLK_IGNORE_UNUSED, 0),
GATE(g2d, "g2d", "aclk200", GATE_IP_DMC, 23, 0, 0),
+ GATE(tmu_apbif, "tmu_apbif", "aclk100", E4X12_GATE_IP_PERIR, 17, 0, 0),
};
#ifdef CONFIG_OF
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos5440: Protect opp search calls with rcu lock
On Monday, April 15, 2013 11:54:47 AM Amit Daniel Kachhap wrote:
> As per the OPP library documentation(Documentation/power/opp.txt) all
> opp find/get calls should be protected by rcu locks.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
>
> This patch is created against linux-next tree and is suggested by
> Nishanth Menon. (https://lkml.org/lkml/2013/4/12/119)
Applied.
Thanks,
Rafael
> drivers/cpufreq/exynos5440-cpufreq.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> index ead7ed4..0c74018 100644
> --- a/drivers/cpufreq/exynos5440-cpufreq.c
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> @@ -120,11 +120,13 @@ static int init_div_table(void)
> int i = 0;
> struct opp *opp;
>
> + rcu_read_lock();
> for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
>
> opp = opp_find_freq_exact(dvfs_info->dev,
> freq_tbl[i].frequency * 1000, true);
> if (IS_ERR(opp)) {
> + rcu_read_unlock();
> dev_err(dvfs_info->dev,
> "failed to find valid OPP for %u KHZ\n",
> freq_tbl[i].frequency);
> @@ -159,6 +161,7 @@ static int init_div_table(void)
> __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
> }
>
> + rcu_read_unlock();
> return 0;
> }
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] MAINTAINERS: Add linux-samsung-soc list to all related entries
Several entries in MAINTAINERS file related to Samsung SoCs do not point to linux-samsung-soc mailing list, which is supposed to collect all Samsung SoC-related threads, to ease following of Samsung SoC-related work. This leads to a problem with people skipping this mailing list in their posts, even though they are related to Samsung SoCs. This patch adds pointers to linux-samsung-soc mailing list to affected entries of MAINTAINERS file. Signed-off-by: Tomasz Figa --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6c0d68b..07cb8da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1139,6 +1139,7 @@ F:arch/arm/mach-exynos*/ ARM/SAMSUNG MOBILE MACHINE SUPPORT M: Kyungmin Park L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-s5pv210/mach-aquila.c F: arch/arm/mach-s5pv210/mach-goni.c @@ -1150,6 +1151,7 @@ M:Kyungmin Park M: Kamil Debski L: linux-arm-ker...@lists.infradead.org L: linux-me...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/media/platform/s5p-g2d/ @@ -1158,6 +1160,7 @@ M:Kyungmin Park M: Sylwester Nawrocki L: linux-arm-ker...@lists.infradead.org L: linux-me...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/plat-samsung/include/plat/*fimc* F: drivers/media/platform/s5p-fimc/ @@ -1168,6 +1171,7 @@ M:Kamil Debski M: Jeongtae Park L: linux-arm-ker...@lists.infradead.org L: linux-me...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/plat-samsung/s5p-dev-mfc.c F: drivers/media/platform/s5p-mfc/ @@ -1177,6 +1181,7 @@ M:Kyungmin Park M: Tomasz Stanislawski L: linux-arm-ker...@lists.infradead.org L: linux-me...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/media/platform/s5p-tv/ @@ -2679,6 +2684,7 @@ M:Joonyoung Shim M: Seung-Woo Kim M: Kyungmin Park L: dri-de...@lists.freedesktop.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git S: Supported F: drivers/gpu/drm/exynos @@ -3142,6 +3148,7 @@ F:Documentation/extcon/ EXYNOS DP DRIVER M: Jingoo Han L: linux-fb...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/exynos/exynos_dp* F: include/video/exynos_dp* @@ -3151,6 +3158,7 @@ M:Inki Dae M: Donghwa Lee M: Kyungmin Park L: linux-fb...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/exynos/exynos_mipi* F: include/video/exynos_mipi* @@ -6892,12 +6900,14 @@ F: drivers/platform/x86/samsung-laptop.c SAMSUNG AUDIO (ASoC) DRIVERS M: Sangbeom Kim L: alsa-de...@alsa-project.org (moderated for non-subscribers) +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Supported F: sound/soc/samsung SAMSUNG FRAMEBUFFER DRIVER M: Jingoo Han L: linux-fb...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/s3c-fb.c @@ -7087,6 +7097,7 @@ F:drivers/mmc/host/sdhci-pltfm.[ch] SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER M: Ben Dooks L: linux-...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/mmc/host/sdhci-s3c.c -- 1.8.2.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 3/3] ARM: S3C24XX: remove obsolete s3c2412 specific dma settings
The s3c2412 dma init contained code to handle dma-direction specific
settings. As now all s3c2412-dma-channels are direction-independent this
is not needed anymore.
As the s3c2412 also was the only user of this, it can go away completely.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/dma-s3c2412.c | 42 ++
arch/arm/mach-s3c24xx/dma.c |3 --
arch/arm/plat-samsung/include/plat/dma-s3c24xx.h |5 ---
3 files changed, 3 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c
b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index 8d8a679..9950400 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -37,131 +37,95 @@ static struct s3c24xx_dma_map __initdata
s3c2412_dma_mappings[] = {
[DMACH_XD0] = {
.name = "xdreq0",
.channels = MAP(S3C2412_DMAREQSEL_XDREQ0),
- .channels_rx= MAP(S3C2412_DMAREQSEL_XDREQ0),
},
[DMACH_XD1] = {
.name = "xdreq1",
.channels = MAP(S3C2412_DMAREQSEL_XDREQ1),
- .channels_rx= MAP(S3C2412_DMAREQSEL_XDREQ1),
},
[DMACH_SDI] = {
.name = "sdi",
.channels = MAP(S3C2412_DMAREQSEL_SDI),
- .channels_rx= MAP(S3C2412_DMAREQSEL_SDI),
},
[DMACH_SPI0_RX] = {
.name = "spi0-rx",
.channels = MAP(S3C2412_DMAREQSEL_SPI0RX),
- .channels_rx= MAP(S3C2412_DMAREQSEL_SPI0RX),
},
[DMACH_SPI0_TX] = {
.name = "spi0-tx",
.channels = MAP(S3C2412_DMAREQSEL_SPI0TX),
- .channels_rx= MAP(S3C2412_DMAREQSEL_SPI0TX),
},
[DMACH_SPI1_RX] = {
.name = "spi1-rx",
.channels = MAP(S3C2412_DMAREQSEL_SPI1RX),
- .channels_rx= MAP(S3C2412_DMAREQSEL_SPI1RX),
},
[DMACH_SPI1_TX] = {
.name = "spi1-tx",
.channels = MAP(S3C2412_DMAREQSEL_SPI1TX),
- .channels_rx= MAP(S3C2412_DMAREQSEL_SPI1TX),
},
[DMACH_UART0] = {
.name = "uart0",
.channels = MAP(S3C2412_DMAREQSEL_UART0_0),
- .channels_rx= MAP(S3C2412_DMAREQSEL_UART0_0),
},
[DMACH_UART1] = {
.name = "uart1",
.channels = MAP(S3C2412_DMAREQSEL_UART1_0),
- .channels_rx= MAP(S3C2412_DMAREQSEL_UART1_0),
},
[DMACH_UART2] = {
.name = "uart2",
.channels = MAP(S3C2412_DMAREQSEL_UART2_0),
- .channels_rx= MAP(S3C2412_DMAREQSEL_UART2_0),
},
[DMACH_UART0_SRC2] = {
.name = "uart0",
.channels = MAP(S3C2412_DMAREQSEL_UART0_1),
- .channels_rx= MAP(S3C2412_DMAREQSEL_UART0_1),
},
[DMACH_UART1_SRC2] = {
.name = "uart1",
.channels = MAP(S3C2412_DMAREQSEL_UART1_1),
- .channels_rx= MAP(S3C2412_DMAREQSEL_UART1_1),
},
[DMACH_UART2_SRC2] = {
.name = "uart2",
.channels = MAP(S3C2412_DMAREQSEL_UART2_1),
- .channels_rx= MAP(S3C2412_DMAREQSEL_UART2_1),
},
[DMACH_TIMER] = {
.name = "timer",
.channels = MAP(S3C2412_DMAREQSEL_TIMER),
- .channels_rx= MAP(S3C2412_DMAREQSEL_TIMER),
},
[DMACH_I2S_IN] = {
.name = "i2s-sdi",
.channels = MAP(S3C2412_DMAREQSEL_I2SRX),
- .channels_rx= MAP(S3C2412_DMAREQSEL_I2SRX),
},
[DMACH_I2S_OUT] = {
.name = "i2s-sdo",
.channels = MAP(S3C2412_DMAREQSEL_I2STX),
- .channels_rx= MAP(S3C2412_DMAREQSEL_I2STX),
},
[DMACH_USB_EP1] = {
.name = "usb-ep1",
.channels = MAP(S3C2412_DMAREQSEL_USBEP1),
- .channels_rx= MAP(S3C2412_DMAREQSEL_USBEP1),
},
[DMACH_USB_EP2] = {
.name = "usb-ep2",
.channels = MAP(S3C2412_DMAREQSEL_USBEP2),
- .channels_rx= MAP(S3C2412_DMAREQSEL_USBEP2),
},
[DMACH_USB_EP3] = {
.name = "usb-ep3",
.channels = MAP(S3C2412_DMAREQSEL_USBEP3),
- .channels_rx= MAP(S3C2412_DMAREQSEL_USBEP3),
},
[DMACH_USB_EP4] = {
.name = "usb-ep4",
.channels = MAP(S3C2412_DMAREQSEL_USBEP4),
-
[PATCH 2/3] ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits
The values read from the channel map always also contain the
DMA_CH_VALID (= 1<<31) setting, which should not get written
into the register, even if this bit is unused.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/dma-s3c2443.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c
b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 000e4c6..e992a7c 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -130,7 +130,8 @@ static struct s3c24xx_dma_map __initdata
s3c2443_dma_mappings[] = {
static void s3c2443_dma_select(struct s3c2410_dma_chan *chan,
struct s3c24xx_dma_map *map)
{
- writel(map->channels[0] | S3C2443_DMAREQSEL_HW,
+ unsigned long chsel = map->channels[0] & (~DMA_CH_VALID);
+ writel(chsel | S3C2443_DMAREQSEL_HW,
chan->regs + S3C2443_DMA_DMAREQSEL);
}
--
1.7.2.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
[PATCH 1/3] ARM: S3C24XX: split s3c2412 spi dma channels
While s3c24xx before s3c2412 (2410, 2440, 2442) use one dma channel
for both sending and receiving spi data, all later s3c24xx socs use
separate channels.
To keep with the structure of "one spi channel" s3c2412 introduced
a channel_rx attribute to the map and selects the correct request
channel depending on the dma direction, hiding the underlying
separation from view.
The s3c24xx-spi driver, which would need this, currently does not
use dma at all, but as s3c2443 has both highspeed (spi0) and regular
(spi1) controllers and also uses the split scheme a future dma support
for s3c24xx-spi would in any case need to differentiate between
old-style and new-style spi channel structure.
Thus we can swtch to the split channel structure like in later socs.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/dma-s3c2412.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c
b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index c0e8c3f..8d8a679 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -49,16 +49,26 @@ static struct s3c24xx_dma_map __initdata
s3c2412_dma_mappings[] = {
.channels = MAP(S3C2412_DMAREQSEL_SDI),
.channels_rx= MAP(S3C2412_DMAREQSEL_SDI),
},
- [DMACH_SPI0] = {
- .name = "spi0",
- .channels = MAP(S3C2412_DMAREQSEL_SPI0TX),
+ [DMACH_SPI0_RX] = {
+ .name = "spi0-rx",
+ .channels = MAP(S3C2412_DMAREQSEL_SPI0RX),
.channels_rx= MAP(S3C2412_DMAREQSEL_SPI0RX),
},
- [DMACH_SPI1] = {
- .name = "spi1",
- .channels = MAP(S3C2412_DMAREQSEL_SPI1TX),
+ [DMACH_SPI0_TX] = {
+ .name = "spi0-tx",
+ .channels = MAP(S3C2412_DMAREQSEL_SPI0TX),
+ .channels_rx= MAP(S3C2412_DMAREQSEL_SPI0TX),
+ },
+ [DMACH_SPI1_RX] = {
+ .name = "spi1-rx",
+ .channels = MAP(S3C2412_DMAREQSEL_SPI1RX),
.channels_rx= MAP(S3C2412_DMAREQSEL_SPI1RX),
},
+ [DMACH_SPI1_TX] = {
+ .name = "spi1-tx",
+ .channels = MAP(S3C2412_DMAREQSEL_SPI1TX),
+ .channels_rx= MAP(S3C2412_DMAREQSEL_SPI1TX),
+ },
[DMACH_UART0] = {
.name = "uart0",
.channels = MAP(S3C2412_DMAREQSEL_UART0_0),
--
1.7.2.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
[PATCH 0/3] ARM: S3C24XX: dma cleanups for s3c2412 and s3c2443
The s3c2412 uses the same dma channel selection-type as the s3c2443 and later but introduced the notion of a receive channel to keep the spi channels, together that are separate in hardware. This series split the spi channels like later socs do (the s3c24xx-spi driver does not use dma at all) and removes this type of special handling. Heiko Stuebner (3): ARM: S3C24XX: split s3c2412 spi dma channels ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits ARM: S3C24XX: remove obsolete s3c2412 specific dma settings arch/arm/mach-s3c24xx/dma-s3c2412.c | 56 ++ arch/arm/mach-s3c24xx/dma-s3c2443.c |3 +- arch/arm/mach-s3c24xx/dma.c |3 - arch/arm/plat-samsung/include/plat/dma-s3c24xx.h |5 -- 4 files changed, 17 insertions(+), 50 deletions(-) -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > Hi,
> >
> > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > While migrating to common clock framework (CCF), I found that the
> > > > FIMD
> > > > clocks were pulled down by the CCF.
> > > > If CCF finds any clock(s) which has NOT been claimed by any of the
> > > > drivers, then such clock(s) are PULLed low by CCF.
> > > >
> > > > Calling clk_prepare() for FIMD clocks fixes the issue.
> > > >
> > > > This patch also replaces clk_disable() with clk_unprepare() during
> > > > exit, since clk_prepare() is called in fimd_probe().
> > >
> > > I asked you about fixing your commit log too.. It still looks
> > > incorrect
> > > to me.
> > >
> > > This patch doesn't have anything to do with CCF pulling clocks down,
> > > but calling clk_prepare() before clk_enable() is must now.. that's
> > > it.. nothing more.
> >
> > I fully agree.
> >
> > The message should be something like:
> >
> > Common Clock Framework introduced the need to prepare clocks before
> > enabling them, otherwise clk_enable() fails. This patch adds
> > clk_prepare calls to the driver.
> >
> > and that's all.
> >
> > What you are observing as "CCF pulling clocks down" is the fact that
> > clk_enable() fails if the clock is not prepared and so the clock is
> > not
> > enabled in result.
> >
> > Another thing is that CCF is not pulling anything down. GPIO pins can
> > be pulled down (or up or not pulled), but clocks can be masked, gated
> > or simply disabled - this does not imply their signal level.
> >
> > > > Signed-off-by: Vikas Sajjan
> > > > ---
> > > >
> > > > Changes since v3:
> > > > - added clk_prepare() in fimd_probe() and clk_unprepare()
> > > > in
> > > > fimd_remove()>
> > > >
> > > > as suggested by Viresh Kumar
> > > >
> > > > Changes since v2:
> > > > - moved clk_prepare_enable() and clk_disable_unprepare()
> > > > from
> > > > fimd_probe() to fimd_clock() as suggested by Inki Dae
> > > > >
> > > >
> > > > Changes since v1:
> > > > - added error checking for clk_prepare_enable() and also
> > > > replaced
> > > > clk_disable() with clk_disable_unprepare() during exit.
> > > >
> > > > ---
> > > >
> > > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
> > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
> > > > 100644
> > > > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
> > > > *pdev)>
> > > >
> > > > return ret;
> > > >
> > > > }
> > > >
> > > > + ret = clk_prepare(ctx->bus_clk);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + ret = clk_prepare(ctx->lcd_clk);
> > > > + if (ret < 0) {
> > > > + clk_unprepare(ctx->bus_clk);
> > > > + return ret;
> > > > + }
> > > > +
> >
> > Why not just simply use clk_prepare_enable() instead of all calls to
> > clk_enable() in the driver?
> >
> > Same goes for s/clk_disable/clk_disable_unprepare/ .
>
> I agree with you. Using clk_prepare_enable() is more clear. Actually I
> had already commented on this. Please see the patch v2. But this way
> also looks good to me.
Well, both versions are technically correct and will have the same effect
for Exynos SoC clocks, since only enable/disable ops change hardware
state.
However if we look at general meaning of those generic ops, the clock will
remain prepared for all the time the driver is loaded, even if the device
is runtime suspended. Again on Exynos SoCs this won't have any effect, but
I think we should respect general Common Clock Framework semantics anyway.
> > > > ctx->vidcon0 = pdata->vidcon0;
> > > > ctx->vidcon1 = pdata->vidcon1;
> > > > ctx->default_win = pdata->default_win;
> > > >
> > > > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
> > > > *pdev)>
> > > >
> > > > if (ctx->suspended)
> > > >
> > > > goto out;
> > > >
> > > > - clk_disable(ctx->lcd_clk);
> > > > - clk_disable(ctx->bus_clk);
> > > > + clk_unprepare(ctx->lcd_clk);
> > > > + clk_unprepare(ctx->bus_clk);
> > >
> > > This looks wrong again.. You still need to call clk_disable() to
> > > make
> > > clk enabled
> > > count zero...
> >
> > Viresh is right again here.
>
> Ok, you two guys say together this looks wrong so I'd like to take more
> checking. I thought that clk->clk_enable is 1 at here and it would be 0
> by pm_runtimg_put_sync(). Is there any my missing point?
You're reas
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
Hi Inki, On Sunday 21 of April 2013 23:05:45 Inki Dae wrote: > 2013/4/21 Tomasz Figa > > > On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote: > > > On 20 April 2013 20:56, Inki Dae wrote: > > > > Sorry for being late. I think clk_prepare/unprepare are nothing to > > > > do > > > > yet in case of Exynos but those might be used for in the future so > > > > your patch looks good to me as is. > > > > > > > > Applied. :) > > > > Hmm. Now, after searching for this thread in dri-devel archives, I'm > > wondering why I haven't received some of messages from this thread > > through linux-samsung-soc mailing list... > > > > I believe linux-samsung-soc list exists to collect all threads related > > to Samsung SoCs for people that don't want to subscribe to lists like > > dri- devel, on which there is a lot of threads irrelevant to them, > > with the risk of missing the important ones. > > > > Please always make sure that any discussion about Samsung SoCs > > (patches in particular) is going through linux-samsung-soc as well. > > Thanks for your advice. As you said, some people might not want to > subscribe to some mainling lists they don't want. And I think that the > main mailing list on this patch is dri-devel so you must receive this > email thread if you subscribed to the dri-devel. I agree that dri-devel is the target mailing list for DRM patches, but AFAIK all threads related to Samsung SoCs should be sent to linux-samsung- soc as well. For example, I don't subscribe dri-devel, but I do linux-samsung-soc, because all I want to follow is all the works related to Samsung SoCs. Remaining threads on dri-devel are outside of my competencies. > Anyway it would be > best to share this all mailing lists included in this email thread but > if so, I have no doubt to receive email bumb. :( Hmm, you don't have to subscribe to a mailing list to post to it. Actually I'm wondering if the fact that your previous messages did not get to the linux-samsung-soc list was not caused by presence of HTML part in your messages, which is strongly discouraged on all mailing lists and actually blocked on vger.kernel.org where linux-samsung-soc is hosted. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On Sunday 21 of April 2013 13:23:10 Viresh Kumar wrote: > On 20 April 2013 20:56, Inki Dae wrote: > > Sorry for being late. I think clk_prepare/unprepare are nothing to do > > yet in case of Exynos but those might be used for in the future so > > your patch looks good to me as is. > > > > Applied. :) > Hmm. Now, after searching for this thread in dri-devel archives, I'm wondering why I haven't received some of messages from this thread through linux-samsung-soc mailing list... I believe linux-samsung-soc list exists to collect all threads related to Samsung SoCs for people that don't want to subscribe to lists like dri- devel, on which there is a lot of threads irrelevant to them, with the risk of missing the important ones. Please always make sure that any discussion about Samsung SoCs (patches in particular) is going through linux-samsung-soc as well. Thanks in advance. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan wrote:
> > While migrating to common clock framework (CCF), I found that the FIMD
> > clocks were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > drivers, then such clock(s) are PULLed low by CCF.
> >
> > Calling clk_prepare() for FIMD clocks fixes the issue.
> >
> > This patch also replaces clk_disable() with clk_unprepare() during
> > exit, since clk_prepare() is called in fimd_probe().
>
> I asked you about fixing your commit log too.. It still looks incorrect
> to me.
>
> This patch doesn't have anything to do with CCF pulling clocks down, but
> calling clk_prepare() before clk_enable() is must now.. that's it..
> nothing more.
>
I fully agree.
The message should be something like:
Common Clock Framework introduced the need to prepare clocks before
enabling them, otherwise clk_enable() fails. This patch adds clk_prepare
calls to the driver.
and that's all.
What you are observing as "CCF pulling clocks down" is the fact that
clk_enable() fails if the clock is not prepared and so the clock is not
enabled in result.
Another thing is that CCF is not pulling anything down. GPIO pins can be
pulled down (or up or not pulled), but clocks can be masked, gated or
simply disabled - this does not imply their signal level.
> > Signed-off-by: Vikas Sajjan
> > ---
> >
> > Changes since v3:
> > - added clk_prepare() in fimd_probe() and clk_unprepare() in
> > fimd_remove()>
> > as suggested by Viresh Kumar
> >
> > Changes since v2:
> > - moved clk_prepare_enable() and clk_disable_unprepare() from
> > fimd_probe() to fimd_clock() as suggested by Inki Dae
> > >
> > Changes since v1:
> > - added error checking for clk_prepare_enable() and also
> > replaced
> > clk_disable() with clk_disable_unprepare() during exit.
> >
> > ---
> >
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
> > 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
> > *pdev)>
> > return ret;
> >
> > }
> >
> > + ret = clk_prepare(ctx->bus_clk);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = clk_prepare(ctx->lcd_clk);
> > + if (ret < 0) {
> > + clk_unprepare(ctx->bus_clk);
> > + return ret;
> > + }
> > +
Why not just simply use clk_prepare_enable() instead of all calls to
clk_enable() in the driver?
Same goes for s/clk_disable/clk_disable_unprepare/ .
> >
> > ctx->vidcon0 = pdata->vidcon0;
> > ctx->vidcon1 = pdata->vidcon1;
> > ctx->default_win = pdata->default_win;
> >
> > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
> > *pdev)>
> > if (ctx->suspended)
> >
> > goto out;
> >
> > - clk_disable(ctx->lcd_clk);
> > - clk_disable(ctx->bus_clk);
> > + clk_unprepare(ctx->lcd_clk);
> > + clk_unprepare(ctx->bus_clk);
>
> This looks wrong again.. You still need to call clk_disable() to make
> clk enabled
> count zero...
Viresh is right again here.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On 20 April 2013 20:56, Inki Dae wrote: > Sorry for being late. I think clk_prepare/unprepare are nothing to do yet in > case of Exynos but those might be used for in the future so your patch looks > good to me as is. > > Applied. :) And you think the comments i gave were incorrect then? Why? -- 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
