Re: [PATCH v4 02/10] ARM: dts: list the CPU nodes for Exynos5250
On 2 September 2013 12:07, Chander Kashyap wrote: > I tested on 3.11-rc7. > Both the cpu's are booting. I didnet see any issue. Oops!! I copied dtb to wrong location.. stupid mistake.. sorry. -- 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 02/10] ARM: dts: list the CPU nodes for Exynos5250
On 2 September 2013 12:07, Chander Kashyap wrote: > I tested on 3.11-rc7. > Both the cpu's are booting. I didnet see any issue. Strange.. I am sure about the problem I reported.. Please share your .config and I will give it a try.. -- 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 02/10] ARM: dts: list the CPU nodes for Exynos5250
On Tue, Jun 18, 2013 at 11:59 AM, Chander Kashyap
wrote:
> Instead of having to specify the number for CPUs in Exynos5250 in platsmp.c
> file, let the number of CPUs be determined by having this information listed
> in Exynos5250 device tree file.
>
> Signed-off-by: Chander Kashyap
> Reviewed-by: Tomasz Figa
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 16
> arch/arm/mach-exynos/platsmp.c| 10 +++---
> 2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 63ca03d..1aeef98 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -50,6 +50,22 @@
> pinctrl3 = &pinctrl_3;
> };
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0>;
> + };
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <1>;
> + };
> + };
> +
> pd_gsc: gsc-power-domain@0x10044000 {
> compatible = "samsung,exynos4210-pd";
> reg = <0x10044000 0x20>;
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index 1a4e4e5..85ea4ca 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -180,10 +180,14 @@ static void __init exynos_smp_init_cpus(void)
> void __iomem *scu_base = scu_base_addr();
> unsigned int i, ncores;
>
> - if (soc_is_exynos5250())
> - ncores = 2;
> - else
> + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
> ncores = scu_base ? scu_get_core_count(scu_base) : 1;
> + else
> + /*
> +* CPU Nodes are passed thru DT and set_cpu_possible
> +* is set by "arm_dt_init_cpu_maps".
> +*/
> + return;
>
> /* sanity check */
> if (ncores > nr_cpu_ids) {
After this patch only one cpu is coming up for me on my Arndale board..
Revert of this one fixes the issue though (Tested over v3.11-rc7)
--
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: fix EXYNOS drivers selection
On 9 August 2013 21:20, Tomasz Figa wrote: > On Friday 09 of August 2013 14:04:55 Bartlomiej Zolnierkiewicz wrote: >> * remove superfluous pr_debug() call from exynos_cpufreq_init() >> (init errors are always logged anyway) >> * add dummy per-SoC type init functions to exynos-cpufreq.h >> * make per-SoC type cpufreq config options selectable >> * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and >> automatically enable it when needed >> >> This patch fixes following issues: >> * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being >> always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), >> even if common EXYNOS cpufreq support was disabled >> * inability to select cpufreq for each SoC type separately (it could >> be only enabled/disabled for all SoCs for which support was enabled) >> * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 >> support was enabled and couldn't be disabled >> >> Signed-off-by: Bartlomiej Zolnierkiewicz >> Signed-off-by: Kyungmin Park >> --- >> drivers/cpufreq/Kconfig.arm | 36 >> drivers/cpufreq/exynos-cpufreq.c | >> 1 - >> drivers/cpufreq/exynos-cpufreq.h | 21 + >> 3 files changed, 45 insertions(+), 13 deletions(-) > Reviewed-by: Tomasz Figa Applied. Thanks!! -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos5440: Fix to skip when new frequency same as current
On 8 August 2013 04:55, Rafael J. Wysocki wrote: > It looks like it would require us to redefine .target() to take next_state > instead of target_freq (at least in the acpi-cpufreq case), wouldn't it? If we don't do it, then atleast for few drivers, like acpi-cpufreq, which use index more than just for frequency, we may end up calling cpufreq_frequency_table_target() twice. Once in the core and then in driver. I believe this is doable and will post a patch soon. -- 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: Fix to skip when new frequency same as current
On 7 August 2013 17:00, Sudeep KarkadaNagesha wrote: > Any particular reason we need this check in all drivers after your > commit: 5a1c0228 "cpufreq: Avoid calling cpufreq driver's target() > routine if target_freq == policy->cur" > > I think it can removed from all drivers, am I missing something ? Yeah.. Just a bit though :) So, cpufreq core checks this when we call target for any frequency. Now, cpufreq driver actually does a cpufreq_frequency_table_target() and so the frequency may vary than what is requested, in case requested frequency isn't picked from the table. In such cases we check it again to be sure that we aren't at this frequency already.. Earlier I thought of calling cpufreq_frequency_table_target() in the core before calling target but dropped the idea as I wasn't sure of the side effects. @Rafael: Do you see why we shouldn't/can't call cpufreq_frequency_table_target() from the core itself and so drivers never need to do it? -- 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: Fix to skip when new frequency same as current
On 7 August 2013 16:46, Amit Daniel Kachhap wrote: > This patch fixes the issue of un-necessary setting the clock controller > when the new target frequency is same as the current one. This case usually > occurs with governors like ondemand which passes the target frequency as the > percentage of average frequency. This check is present in most of the cpufreq > driver. > > Cc: Viresh Kumar > Cc: Rafael J. Wysocki > Cc: Kukjin Kim > Signed-off-by: Amit Daniel Kachhap > --- > drivers/cpufreq/exynos5440-cpufreq.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) Applied. -- 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: s3c24xx: fix typo "ARM_S3C24XX"
On 14 July 2013 17:32, Paul Bolle wrote:
> Kconfig symbol S3C24XX_PLL depends on ARM_S3C24XX. But that symbol
> doesn't exist. Commit f023f8dd59bf ("cpufreq: s3c24xx: move cpufreq
> driver to drivers/cpufreq"), which added this typo, makes clear that
> ARM_S3C24XX_CPUFREQ was intended here.
>
> Signed-off-by: Paul Bolle
> ---
> Untested!
>
> arch/arm/mach-s3c24xx/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 6d9252e..7791ac7 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -208,7 +208,7 @@ config S3C24XX_GPIO_EXTRA128
>
> config S3C24XX_PLL
> bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
> - depends on ARM_S3C24XX
> + depends on ARM_S3C24XX_CPUFREQ
> help
> Compile in support for changing the PLL frequency from the
> S3C24XX series CPUfreq driver. The PLL takes time to settle
Acked-by: Viresh Kumar
@Rafael: I saw you taking other s3c patch directly. Mind taking this
one too?
--
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 31/38] cpufreq: exynos4x12: Remove check for SOC_EXYNOS4412
On 17 June 2013 22:04, Tomasz Figa wrote: > Since SOC_EXYNOS4412 Kconfig symbol has been removed, it is enough to > check for SOC_EXYNOS4212 for both SoCs from Exynos4x12 series. > > Cc: linux...@vger.kernel.org > Cc: Viresh Kumar > Signed-off-by: Tomasz Figa > Signed-off-by: Kyungmin Park > --- > drivers/cpufreq/Kconfig.arm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Looks good. You want it to get via samsung tree or cpufreq? I think all cpufreq related patches should go through cpufreq unless there is a real dependency on samsung tree. -- 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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 14 May 2013 18:30, Rafael J. Wysocki wrote: > On Tuesday, May 14, 2013 09:36:42 PM Kukjin Kim wrote: >> Viresh Kumar wrote: >> > >> > On 13 May 2013 16:21, Rafael J. Wysocki wrote: >> > > That doesn't matter I suppose. I can take it, but please rebase it on >> > top >> > > of current linux-next. >> > >> > I have already done that (attached). But i wasn't sure what Kukjin wants >> > as >> > he may report conflicts again and i will ask the same question for 3.12 :) >> > >> Since this missed last time, this would be sent to upstream via samsung tree >> again. It means the conflicts should be handled by myself. >> >> Rafael, if you don't mind, let me take this into Samsung tree for v3.11. > > Sure, please go ahead. Kukjin, I hope you have already applied this for linux-next? -- 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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 13 May 2013 16:21, Rafael J. Wysocki wrote: > That doesn't matter I suppose. I can take it, but please rebase it on top > of current linux-next. I have already done that (attached). But i wasn't sure what Kukjin wants as he may report conflicts again and i will ask the same question for 3.12 :) -- viresh 0001-cpufreq-s3c24xx-move-cpufreq-driver-to-drivers-cpufr.patch Description: Binary data
Re: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 23 April 2013 20:55, Kukjin Kim wrote: > On 04/05/13 20:36, Rafael J. Wysocki wrote: >> >> On Friday, April 05, 2013 12:36:34 PM Viresh Kumar wrote: >>> >>> On 5 April 2013 12:18, Kukjin Kim wrote: >>>> >>>> Basically, this moving looks good to me, but should be re-worked based >>>> on >>>> for-next of samsung tree because this touches too many samsung stuff so >>>> this >>>> should be sent to upstream via samsung tree. >>> >>> >>> Hmm... Its already applied in Rafael's tree. But it doesn't mean that >>> it can't be >>> moved to your tree if there is a issue. >> >> >> Well, I'm dropping it. Please merge via the Samsung tree. >> > > Oops, I missed, maybe I have no more chance to send this to upstream for > upcoming merge window :-( > > Rafael, please take this patch with my ack in your tree, sorry for noise. > > Acked-by: Kukjin Kim > > If any problems, please kindly let me know. Who is going to pick this patch now for next merge window? -- 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] ARM: S5pv210: compiling issue, ARM_S5PV210_CPUFREQ need CONFIG_CPU_FREQ_TABLE=y
On Wed, Apr 24, 2013 at 4:34 PM, Chen Gang wrote: > > For arm S5pv210 with allmodconfig, ARM_S5PV210_CPUFREQ need > CONFIG_CPU_FREQ_TABLE=y, or will cause compiling issue. > > The related operation: > + arm-linux-gnu-ld -EL -p --no-undefined -X --build-id -X -o .tmp_vmlinux1 -T > /root/linux-next/arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o > init/built-in.o --start-group usr/built-in.o arch/arm/nwfpe/built-in.o > arch/arm/vfp/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o > arch/arm/common/built-in.o arch/arm/net/built-in.o arch/arm/crypto/built-in.o > arch/arm/mach-s5pv210/built-in.o arch/arm/plat-samsung/built-in.o > kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o > security/built-in.o crypto/built-in.o block/built-in.o arch/arm/lib/lib.a > lib/lib.a arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o > sound/built-in.o firmware/built-in.o net/built-in.o --end-group > > The related errors: > drivers/built-in.o: In function `s5pv210_target': > drivers/cpufreq/s5pv210-cpufreq.c:225: undefined reference to > `cpufreq_frequency_table_target' > drivers/cpufreq/s5pv210-cpufreq.c:237: undefined reference to > `cpufreq_frequency_table_target' > drivers/built-in.o: In function `s5pv210_verify_speed': > drivers/cpufreq/s5pv210-cpufreq.c:182: undefined reference to > `cpufreq_frequency_table_verify' > drivers/built-in.o: In function `s5pv210_cpu_init': > drivers/cpufreq/s5pv210-cpufreq.c:556: undefined reference to > `cpufreq_frequency_table_get_attr' > drivers/cpufreq/s5pv210-cpufreq.c:560: undefined reference to > `cpufreq_frequency_table_cpuinfo' > make: *** [vmlinux] Error 1 > > Signed-off-by: Chen Gang > --- > drivers/cpufreq/Kconfig.arm |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index bce2195..bbcd719 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -187,6 +187,7 @@ config ARM_S3C64XX_CPUFREQ > config ARM_S5PV210_CPUFREQ > bool "Samsung S5PV210 and S5PC110" > depends on CPU_S5PV210 > + select CPU_FREQ_TABLE Acked-by: Viresh Kumar -- 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 22 April 2013 15:26, Tomasz Figa wrote: > Can you assure that in future SoCs, on which this driver will be used, this > assumption will still hold true or even that in current Exynos driver this > behavior won't be changed? Probably yes.. Registers for enabling/disabling these clocks should always be on AMBA bus and not on SPI/I2C, i.e. on-soc... and so this will hold true. -- 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 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
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
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.
> 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;
> + }
> +
> 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...
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 0/4] cpufreq: exynos5440: support for cpufreq driver
On 8 April 2013 13:47, Amit Daniel Kachhap wrote: > Submitting the V6 version of exynos5440 cpufreq driver. This patchset > addresses > all the coding and design concerns raised especially by Viresh. > > Changes in V6: > * Used cpufreq post-change notifier call back in case of failure as pointed by > Viresh. > * Called cpufreq_frequency_table_cpuinfo before calling > cpufreq_frequency_table_get_attr as pointed by Viresh. > * Used modified API cpufreq_notify_transition. > > Changes in V5: > * Removed the unnecessary DT look up entry from mach-exynos5-dt.c. > * Fixed all coding and comments issue raised by Viresh. > > Changes in V4: > * Added dev_err logs instead of pr_err. > * Used the devm_ioremap_resource API. > * Implemented several coding guidelines and minor error comments from > Sylwester, > Russell and Viresh. > > Changes in V3: > * Converted the driver to probe based as suggested by Viresh. This is also > beneficial for multiplatform kernel. > * Other coding guidelines related changes. > * Moved the DT node outside cpu0 node as the driver is now a platform > driver. > > Changes in V2: > * Added OPP library support to parse DT parameters. > * Removed a hack to handle interrupts in bootup. > * Implemented other review comments from Viresh and Inder. > > All these patches are dependent on Thomas Abraham common clock patches. > (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html) > This whole patch series is based on Rafael tree. > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > bleeding-edge > > Amit Daniel Kachhap (4): > cpufreq: exynos: Add cpufreq driver for exynos5440 > cpufreq: exynos: Remove error return even if no soc is found > arm: exynos: Enable OPP library support for exynos5440 > arm: dts: Add cpufreq controller node for Exynos5440 SoC > > .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 ++ > arch/arm/boot/dts/exynos5440.dtsi | 12 + > arch/arm/mach-exynos/Kconfig |2 + > drivers/cpufreq/Kconfig.arm|9 + > drivers/cpufreq/Makefile |1 + > drivers/cpufreq/exynos-cpufreq.c |2 +- > drivers/cpufreq/exynos5440-cpufreq.c | 479 > > 7 files changed, 532 insertions(+), 1 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt > create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c With the resent of 1/4, Acked-by: Viresh Kumar -- 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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 8 April 2013 14:45, Kukjin Kim wrote: > Rafael J. Wysocki wrote: >> Well, I'm dropping it. Please merge via the Samsung tree. >> > OK, I will. > > I got patch file from Viresh, and there is a sign from Rafael, but it should > be ack. So Rafael, let me use your ack on this patch when I apply. If any > problems, please let me know. Ahh.. I forgot to remove it. I picked the initial patch from Rafael's tree. But yes, you need it anyway :) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On 8 April 2013 14:17, Viresh Kumar wrote: > On 8 April 2013 13:47, Amit Daniel Kachhap wrote: > >> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm >> index f3f3b14..bce2195 100644 >> --- a/drivers/cpufreq/Kconfig.arm >> +++ b/drivers/cpufreq/Kconfig.arm >> @@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ >> This adds the CPUFreq driver for Samsung EXYNOS5250 >> SoC. >> >> +config ARM_EXYNOS5440_CPUFREQ >> + def_bool SOC_EXYNOS5440 >> + depends on HAVE_CLK && PM_OPP && OF > > Don't you need a depend on your Soc or mach or arch? Don't send another > version for this now.. Just send a new patch over this patchset. Sorry, i overlooked def_bool... This comments stands invalid. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 1/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On 8 April 2013 13:47, Amit Daniel Kachhap wrote:
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index f3f3b14..bce2195 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -42,6 +42,15 @@ config ARM_EXYNOS5250_CPUFREQ
> This adds the CPUFreq driver for Samsung EXYNOS5250
> SoC.
>
> +config ARM_EXYNOS5440_CPUFREQ
> + def_bool SOC_EXYNOS5440
> + depends on HAVE_CLK && PM_OPP && OF
Don't you need a depend on your Soc or mach or arch? Don't send another
version for this now.. Just send a new patch over this patchset.
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> +static int exynos_target(struct cpufreq_policy *policy,
> + unsigned int target_freq,
> + unsigned int relation)
> +{
> + unsigned int index, tmp;
> + int ret = 0, i;
> + struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
> +
> + mutex_lock(&cpufreq_lock);
> + freqs.old = dvfs_info->cur_frequency;
> +
> + ret = cpufreq_frequency_table_target(policy, freq_table,
> + target_freq, relation, &index);
> + if (ret)
> + goto out;
> +
Move freqs.old = *** here.
> + freqs.new = freq_table[index].frequency;
> + freqs.cpu = policy->cpu;
You don't need this. Below call takes care of it.
Rest is fine.. Just resend this patch with all above issues fixed and i will Ack
it without any further reviews :)
Don't wait for few days for doing this, send it right now. :)
--
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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 5 April 2013 12:36, Viresh Kumar wrote: > On 5 April 2013 12:18, Kukjin Kim wrote: >> Basically, this moving looks good to me, but should be re-worked based on >> for-next of samsung tree because this touches too many samsung stuff so this >> should be sent to upstream via samsung tree. > > Hmm... Its already applied in Rafael's tree. But it doesn't mean that > it can't be > moved to your tree if there is a issue. > > What tree/branch? I used: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next > >> Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq >> error: patch failed: arch/arm/Kconfig:2166 >> error: arch/arm/Kconfig: patch does not apply > > above two are obvious as you haven't applied other patches in this series. > >> error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28 >> error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply >> error: patch failed: arch/arm/mach-s3c24xx/Makefile:17 >> error: arch/arm/mach-s3c24xx/Makefile: patch does not apply >> error: patch failed: drivers/cpufreq/Makefile:63 >> error: drivers/cpufreq/Makefile: patch does not apply > > Same here. > >> error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index > > I can still see it in for-next. > > Attached is my patch based of your for-next Kukjin, As Rafael has already dropped it, can you apply it at your end and make sure it doesn't miss the merge cycle? -- 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 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 5 April 2013 12:18, Kukjin Kim wrote: > Basically, this moving looks good to me, but should be re-worked based on > for-next of samsung tree because this touches too many samsung stuff so this > should be sent to upstream via samsung tree. Hmm... Its already applied in Rafael's tree. But it doesn't mean that it can't be moved to your tree if there is a issue. What tree/branch? I used: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next > Applying: cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq > error: patch failed: arch/arm/Kconfig:2166 > error: arch/arm/Kconfig: patch does not apply above two are obvious as you haven't applied other patches in this series. > error: patch failed: arch/arm/mach-s3c24xx/Kconfig:28 > error: arch/arm/mach-s3c24xx/Kconfig: patch does not apply > error: patch failed: arch/arm/mach-s3c24xx/Makefile:17 > error: arch/arm/mach-s3c24xx/Makefile: patch does not apply > error: patch failed: drivers/cpufreq/Makefile:63 > error: drivers/cpufreq/Makefile: patch does not apply Same here. > error: drivers/cpufreq/s3c2412-cpufreq.c: does not exist in index I can still see it in for-next. Attached is my patch based of your for-next 0001-cpufreq-s3c24xx-move-cpufreq-driver-to-drivers-cpufr.patch Description: Binary data
[PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Viresh Kumar
Acked-by: Arnd Bergmann
---
arch/arm/Kconfig | 46 ---
arch/arm/mach-s3c24xx/Kconfig | 66 +-
arch/arm/mach-s3c24xx/Makefile | 6 --
arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h | 0
arch/arm/mach-s3c24xx/iotiming-s3c2412.c | 2 +-
arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
arch/arm/plat-samsung/include/plat/cpu-freq.h | 6 +-
drivers/cpufreq/Kconfig.arm| 58 +++
drivers/cpufreq/Makefile | 5 ++
.../cpufreq/s3c2410-cpufreq.c | 0
.../cpufreq/s3c2412-cpufreq.c | 3 +-
.../cpufreq/s3c2440-cpufreq.c | 0
.../cpufreq/s3c24xx-cpufreq-debugfs.c | 0
.../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c | 0
14 files changed, 100 insertions(+), 102 deletions(-)
rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c =>
drivers/cpufreq/s3c2410-cpufreq.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c =>
drivers/cpufreq/s3c2412-cpufreq.c (99%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c =>
drivers/cpufreq/s3c2440-cpufreq.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c =>
drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c
(100%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c3563f6..70366b7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2166,52 +2166,6 @@ config CPU_FREQ_SA1100
config CPU_FREQ_SA1110
bool
-config CPU_FREQ_S3C
- bool
- help
- Internal configuration node for common cpufreq on Samsung SoC
-
-config CPU_FREQ_S3C24XX
- bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
- depends on ARCH_S3C24XX && CPU_FREQ
- select CPU_FREQ_S3C
- help
- This enables the CPUfreq driver for the Samsung S3C24XX family
- of CPUs.
-
- For details, take a look at .
-
- If in doubt, say N.
-
-config CPU_FREQ_S3C24XX_PLL
- bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
- depends on CPU_FREQ_S3C24XX
- help
- Compile in support for changing the PLL frequency from the
- S3C24XX series CPUfreq driver. The PLL takes time to settle
- after a frequency change, so by default it is not enabled.
-
- This also means that the PLL tables for the selected CPU(s) will
- be built which may increase the size of the kernel image.
-
-config CPU_FREQ_S3C24XX_DEBUG
- bool "Debug CPUfreq Samsung driver core"
- depends on CPU_FREQ_S3C24XX
- help
- Enable s3c_freq_dbg for the Samsung S3C CPUfreq core
-
-config CPU_FREQ_S3C24XX_IODEBUG
- bool "Debug CPUfreq Samsung driver IO timing"
- depends on CPU_FREQ_S3C24XX
- help
- Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
-
-config CPU_FREQ_S3C24XX_DEBUGFS
- bool "Export debugfs for CPUFreq"
- depends on CPU_FREQ_S3C24XX && DEBUG_FS
- help
- Export status information via debugfs.
-
endif
source "drivers/cpuidle/Kconfig"
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 37f513d..81d2f3c 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -28,7 +28,7 @@ config CPU_S3C2410
select CPU_ARM920T
select CPU_LLSERIAL_S3C2410
select S3C2410_CLOCK
- select S3C2410_CPUFREQ if CPU_FREQ_S3C24XX
+ select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
help
Support for S3C2410 and S3C2410A family from the S3C24XX line
@@ -202,27 +202,38 @@ config S3C24XX_GPIO_EXTRA128
Add an extra 128 gpio numbers to the available GPIO pool. This is
available for boards that need extra gpios for external devices.
+config S3C24XX_PLL
+ bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
+ depends on ARM_S3C24XX
+ help
+ Compile in support for changing the PLL frequency from the
+ S3C24XX series CPUfreq driver. The PLL takes time to settle
+ after a frequency change, so by default it is not enabled.
+
+ This also means that the PLL tables for the selected CPU(s) will
+ be built which may increase the size of the kernel image.
+
# cpu frequency items common between s3c2410 and s3c2440/s3c2442
config S3C2410_IOTIMING
bool
-
Re: [PATCH 8/9] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 31 March 2013 09:23, Viresh Kumar wrote:
> On 25 March 2013 15:41, Viresh Kumar wrote:
>> This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
>> drivers/cpufreq.
>>
>> Cc: Ben Dooks
>> Cc: Kukjin Kim
>> Cc: linux-samsung-soc@vger.kernel.org
>> Signed-off-by: Viresh Kumar
>> ---
>> arch/arm/Kconfig | 46 ---
>> arch/arm/mach-s3c24xx/Kconfig | 66
>> +-
>> arch/arm/mach-s3c24xx/Makefile | 6 --
>> arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h | 0
>> arch/arm/mach-s3c24xx/iotiming-s3c2412.c | 2 +-
>> arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
>> arch/arm/plat-samsung/include/plat/cpu-freq.h | 6 +-
>> drivers/cpufreq/Kconfig.arm| 58 +++
>> drivers/cpufreq/Makefile | 5 ++
>> .../cpufreq/s3c2410-cpufreq.c | 0
>> .../cpufreq/s3c2412-cpufreq.c | 3 +-
>> .../cpufreq/s3c2440-cpufreq.c | 0
>> .../cpufreq/s3c24xx-cpufreq-debugfs.c | 0
>> .../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c | 0
>> 14 files changed, 100 insertions(+), 102 deletions(-)
>> rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
>> rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c =>
>> drivers/cpufreq/s3c2410-cpufreq.c (100%)
>> rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c =>
>> drivers/cpufreq/s3c2412-cpufreq.c (99%)
>> rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c =>
>> drivers/cpufreq/s3c2440-cpufreq.c (100%)
>> rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c =>
>> drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
>> rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c
>> (100%)
>
> Ben/Kukjin,
>
> Can i have your View or Ack for this patch?
Ping!!
--
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
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);
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 8/9] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
On 25 March 2013 15:41, Viresh Kumar wrote:
> This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
> drivers/cpufreq.
>
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Viresh Kumar
> ---
> arch/arm/Kconfig | 46 ---
> arch/arm/mach-s3c24xx/Kconfig | 66
> +-
> arch/arm/mach-s3c24xx/Makefile | 6 --
> arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h | 0
> arch/arm/mach-s3c24xx/iotiming-s3c2412.c | 2 +-
> arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
> arch/arm/plat-samsung/include/plat/cpu-freq.h | 6 +-
> drivers/cpufreq/Kconfig.arm| 58 +++
> drivers/cpufreq/Makefile | 5 ++
> .../cpufreq/s3c2410-cpufreq.c | 0
> .../cpufreq/s3c2412-cpufreq.c | 3 +-
> .../cpufreq/s3c2440-cpufreq.c | 0
> .../cpufreq/s3c24xx-cpufreq-debugfs.c | 0
> .../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c | 0
> 14 files changed, 100 insertions(+), 102 deletions(-)
> rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
> rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c =>
> drivers/cpufreq/s3c2410-cpufreq.c (100%)
> rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c =>
> drivers/cpufreq/s3c2412-cpufreq.c (99%)
> rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c =>
> drivers/cpufreq/s3c2440-cpufreq.c (100%)
> rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c =>
> drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
> rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c
> (100%)
Ben/Kukjin,
Can i have your View or Ack for this patch?
--
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/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On 28 March 2013 13:35, Amit Daniel Kachhap wrote:
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> +static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> + policy->cur = dvfs_info->cur_frequency;
> + cpufreq_frequency_table_get_attr(dvfs_info->freq_table, policy->cpu);
> +
> + /* set the transition latency value */
> + policy->cpuinfo.transition_latency = dvfs_info->latency;
> +
> + cpumask_setall(policy->cpus);
> +
> + return cpufreq_frequency_table_cpuinfo(policy, dvfs_info->freq_table);
I missed this earlier and saw this mistake in yet another driver.
You need to call cpufreq_frequency_table_get_attr() only when
cpufreq_frequency_table_cpuinfo() has passed.
> +}
--
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/4] cpufreq: exynos: Add cpufreq driver for exynos5440
On 28 March 2013 13:35, Amit Daniel Kachhap wrote:
> This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
> they scale at same frequency. The nature of exynos5440 clock controller is
> different from previous exynos controllers so not using the common exynos
> cpufreq framework. The major difference being interrupt notification for
> frequency change. Also, OPP library is used for device tree parsing to get
> different parameters like frequency, voltage etc. Since the opp library sorts
> the frequency table in ascending order so they are again re-arranged in
> descending order. This will have one-to-one mapping with the clock controller
> state management logic.
>
> Signed-off-by: Amit Daniel Kachhap
Mostly okay now, just minor comments:
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> +static void exynos_cpufreq_work(struct work_struct *work)
> +{
> + if (likely(index < dvfs_info->freq_count)) {
> + freqs.new = freq_table[index].frequency;
> + for_each_cpu(freqs.cpu, policy->cpus)
> + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> + dvfs_info->cur_frequency = freqs.new;
> + } else {
> + dev_crit(dvfs_info->dev, "New frequency out of range\n");
> + }
I believe there is something wrong here. For failure cases too
we need to issue cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
with the old frequency.
> +static int exynos_cpufreq_probe(struct platform_device *pdev)
> +{
> + ret = cpufreq_register_driver(&exynos_driver);
> + if (ret) {
> + dev_err(dvfs_info->dev,
> + "%s: failed to register cpufreq driver\n", __func__);
> + goto err_free_table;
> + }
> +
> + of_node_put(np);
Don't we need to put node everytime?
> + dvfs_info->dvfs_enabled = true;
> + return 0;
> +
> +err_free_table:
> + opp_free_cpufreq_table(dvfs_info->dev, &dvfs_info->freq_table);
> +err_put_node:
> + of_node_put(np);
> + dev_err(dvfs_info->dev, "%s: failed initialization\n", __func__);
> + return ret;
> +}
--
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 V5 0/4] cpufreq: exynos5440: support for cpufreq driver
On 28 March 2013 13:35, Amit Daniel Kachhap wrote: > Submitting the V5 version of exynos5440 cpufreq driver. This patchset > addresses > all the coding and design concerns raised especially by Viresh. > > Changes in V5: > * Removed the unnecessary DT look up entry from mach-exynos5-dt.c. > * Fixed all coding and comments issue raised by Viresh. People normally forget what they commented on earlier and that's why this change log phenomenon was introduced. Some more details would be better here for next time. -- 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 8/9] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Viresh Kumar
---
arch/arm/Kconfig | 46 ---
arch/arm/mach-s3c24xx/Kconfig | 66 +-
arch/arm/mach-s3c24xx/Makefile | 6 --
arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h | 0
arch/arm/mach-s3c24xx/iotiming-s3c2412.c | 2 +-
arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 10 ++--
arch/arm/plat-samsung/include/plat/cpu-freq.h | 6 +-
drivers/cpufreq/Kconfig.arm| 58 +++
drivers/cpufreq/Makefile | 5 ++
.../cpufreq/s3c2410-cpufreq.c | 0
.../cpufreq/s3c2412-cpufreq.c | 3 +-
.../cpufreq/s3c2440-cpufreq.c | 0
.../cpufreq/s3c24xx-cpufreq-debugfs.c | 0
.../cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c | 0
14 files changed, 100 insertions(+), 102 deletions(-)
rename arch/arm/mach-s3c24xx/{ => include/mach}/s3c2412.h (100%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2410.c =>
drivers/cpufreq/s3c2410-cpufreq.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2412.c =>
drivers/cpufreq/s3c2412-cpufreq.c (99%)
rename arch/arm/mach-s3c24xx/cpufreq-s3c2440.c =>
drivers/cpufreq/s3c2440-cpufreq.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq-debugfs.c =>
drivers/cpufreq/s3c24xx-cpufreq-debugfs.c (100%)
rename arch/arm/mach-s3c24xx/cpufreq.c => drivers/cpufreq/s3c24xx-cpufreq.c
(100%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 39c8a3b..cdbe688 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2162,52 +2162,6 @@ config CPU_FREQ_SA1100
config CPU_FREQ_SA1110
bool
-config CPU_FREQ_S3C
- bool
- help
- Internal configuration node for common cpufreq on Samsung SoC
-
-config CPU_FREQ_S3C24XX
- bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
- depends on ARCH_S3C24XX && CPU_FREQ
- select CPU_FREQ_S3C
- help
- This enables the CPUfreq driver for the Samsung S3C24XX family
- of CPUs.
-
- For details, take a look at .
-
- If in doubt, say N.
-
-config CPU_FREQ_S3C24XX_PLL
- bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
- depends on CPU_FREQ_S3C24XX
- help
- Compile in support for changing the PLL frequency from the
- S3C24XX series CPUfreq driver. The PLL takes time to settle
- after a frequency change, so by default it is not enabled.
-
- This also means that the PLL tables for the selected CPU(s) will
- be built which may increase the size of the kernel image.
-
-config CPU_FREQ_S3C24XX_DEBUG
- bool "Debug CPUfreq Samsung driver core"
- depends on CPU_FREQ_S3C24XX
- help
- Enable s3c_freq_dbg for the Samsung S3C CPUfreq core
-
-config CPU_FREQ_S3C24XX_IODEBUG
- bool "Debug CPUfreq Samsung driver IO timing"
- depends on CPU_FREQ_S3C24XX
- help
- Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
-
-config CPU_FREQ_S3C24XX_DEBUGFS
- bool "Export debugfs for CPUFreq"
- depends on CPU_FREQ_S3C24XX && DEBUG_FS
- help
- Export status information via debugfs.
-
endif
source "drivers/cpuidle/Kconfig"
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 37f513d..81d2f3c 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -28,7 +28,7 @@ config CPU_S3C2410
select CPU_ARM920T
select CPU_LLSERIAL_S3C2410
select S3C2410_CLOCK
- select S3C2410_CPUFREQ if CPU_FREQ_S3C24XX
+ select ARM_S3C2410_CPUFREQ if ARM_S3C24XX_CPUFREQ
select S3C2410_PM if PM
help
Support for S3C2410 and S3C2410A family from the S3C24XX line
@@ -202,27 +202,38 @@ config S3C24XX_GPIO_EXTRA128
Add an extra 128 gpio numbers to the available GPIO pool. This is
available for boards that need extra gpios for external devices.
+config S3C24XX_PLL
+ bool "Support CPUfreq changing of PLL frequency (EXPERIMENTAL)"
+ depends on ARM_S3C24XX
+ help
+ Compile in support for changing the PLL frequency from the
+ S3C24XX series CPUfreq driver. The PLL takes time to settle
+ after a frequency change, so by default it is not enabled.
+
+ This also means that the PLL tables for the selected CPU(s) will
+ be built which may increase the size of the kernel image.
+
# cpu frequency items common between s3c2410 and s3c2440/s3c2442
config S3C2410_IOTIMING
bool
- depends on CPU_FREQ_S3C24XX
+ depends on ARM_S3C24XX_CPUFRE
Re: [PATCH] drm/exynos: enable FIMD clocks
On 19 March 2013 15:29, Vikas Sajjan wrote: > While migrating to common clock framework (CCF), 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. > > By calling clk_prepare_enable() for FIMD clocks fixes the issue. > > Signed-off-by: Vikas Sajjan > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index 9537761..d93dd8a 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -934,6 +934,9 @@ static int fimd_probe(struct platform_device *pdev) > return ret; > } > > + clk_prepare_enable(ctx->lcd_clk); > + clk_prepare_enable(ctx->bus_clk); > + Ideally you should check return values here. -- 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 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
This is what Russell told me a long time back:
"Don't use Adding, Fixing, etc words as this work is not something, which is
already done."
So your subject should have been: "cpufreq: exynos: Add cpufreq driver
for exynos5440"
Fix it if you need another version, which i believe you do :)
On Tue, Mar 12, 2013 at 5:58 PM, Amit Daniel Kachhap
wrote:
> This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
> they scale at same frequency. The nature of exynos5440 clock controller is
> different from previous exynos controllers so not using the common exynos
> cpufreq framework. The major difference being interrupt notfication for
s/notfication/notification
> frequency change. Also, OPP library is used for device tree parsing to get
> different parameters like frequency, voltage etc. Since the opp library sorts
> the frequency table in ascending order so they are again re-arranged in
> descending order. This will have one-to-one mapping with the clock controller
> state management logic.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> .../bindings/cpufreq/cpufreq-exynos5440.txt| 29 ++
> drivers/cpufreq/Kconfig.arm|9 +
> drivers/cpufreq/Makefile |1 +
> drivers/cpufreq/exynos5440-cpufreq.c | 466
>
> 4 files changed, 505 insertions(+), 0 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> new file mode 100644
> index 000..a0dbe0b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> @@ -0,0 +1,29 @@
> +
> +Exynos5440 cpufreq driver
> +---
> +
> +Exynos5440 SoC cpufreq driver for CPU frequency scaling.
> +
> +Required properties:
> +- interrupts: Interrupt to know the completion of cpu frequency change.
> +- operating-points: Table of frequencies and voltage CPU could be
> transitioned into,
> + in the decreasing order. Frequency should be in KHZ units and voltage
s/KHZ/KHz
> + should be in microvolts.
probably s/microvolts/micro-volts ??
> +
> +Optional properties:
> +- clock-latency: Clock monitor latency in microsecond.
> +
> +All the required listed above must be defined under node cpufreq.
> +
> +Example:
> +
> + cpufreq@16 {
> + compatible = "samsung,exynos5440-cpufreq";
> + reg = <0x16 0x1000>;
> + interrupts = <0 57 0>;
> + operating-points = <
> + 100 975000
> + 80 925000>;
> + clock-latency = <10>;
> + };
> +
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> +static void exynos_enable_dvfs(void)
> +{
> + /* Set initial performance index */
> + for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
> + if (freq_table[i].frequency == dvfs_info->cur_frequency)
> + break;
> +
> + if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
> + dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
> + /* Assign the highest frequency */
> + i = 0;
> + dvfs_info->cur_frequency = freq_table[i].frequency;
What about:
dvfs_info->cur_frequency = freq_table[0].frequency;
as i don't see i being used again?
> + }
> +}
> +static int exynos_target(struct cpufreq_policy *policy,
> + unsigned int target_freq,
> + unsigned int relation)
> +{
> + if (cpufreq_frequency_table_target(policy, freq_table,
> + target_freq, relation, &index)) {
> + ret = -EINVAL;
Use the error value returned by called functions, probably i gave this
comment last time too?
> + goto out;
> + }
> +}
> +static void exynos_sort_descend_freq_table(void)
> +{
> + struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
> + int i = 0, index;
> + unsigned int tmp_freq;
> +
> + /*
> +* Freq table is already in ascending order as it is created from
> +* OPP library, so just swap the elements to make it descending.
why??
> +*/
> + for (i = 0; i < dvfs_info->freq_count / 2; i++) {
> + index = dvfs_info->freq_count - i - 1;
> + tmp_freq = freq_tbl[i].frequency;
> + freq_tbl[i].frequency = freq_tbl[index].frequency;
> + freq_tbl[index].frequency = tmp_freq;
> + }
> +}
> +
> +static int exynos_cpufreq_probe(struct platform_device *pdev)
> +{
> + int ret = -EINVAL;
> + struct device_node *np;
Re: [PATCH V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
On 7 March 2013 12:13, Amit Daniel Kachhap wrote:
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> +struct exynos_dvfs_data {
> + void __iomem *base;
> + struct resource *mem;
> + int irq;
> + struct clk *cpu_clk;
> + unsigned int cur_frequency;
> + unsigned int latency;
> + struct cpufreq_frequency_table *freq_table;
> + unsigned int freq_count;
> + struct device *dev;
> + bool dvfs_enable;
s/enable/enabled?
> +static int exynos_cpufreq_probe(struct platform_device *pdev)
> + dvfs_info->cpu_clk = devm_clk_get(dvfs_info->dev, "armclk");
> + if (IS_ERR_OR_NULL(dvfs_info->cpu_clk)) {
s/IS_ERR_OR_NULL/IS_ERR
> + if (devm_request_irq(dvfs_info->dev, dvfs_info->irq,
> exynos_cpufreq_irq,
> + IRQF_TRIGGER_NONE, CPUFREQ_NAME, dvfs_info)) {
> + pr_err("Failed to register IRQ\n");
> + ret = -ENODEV;
use the value returned from this function rather than creating your
own.. true for all
other calls too, unless they return NULL on error.
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
On 6 March 2013 13:35, amit kachhap wrote:
> On Tue, Mar 5, 2013 at 6:48 AM, Viresh Kumar wrote:
>>> +static void exynos_cpufreq_work(struct work_struct *work)
>>> +{
>>> + unsigned int cur_pstate, index;
>>> + struct cpufreq_policy *policy = cpufreq_cpu_get(0); /* boot CPU */
>>> + struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
>>> +
>>> + if (policy == NULL)
>>> + goto skip_work;
>>
>> How can that be true? And if it can be, you will miss POSTCHANGE
>> notifications
>> too.
> This skip of POSTCHANGE notifications is needed in one case where
> bootup frequency does not match with any elements of cpufreq table and
> hence I simply assign the highest frequency. Also cpufreq driver is
> not registered at this point.
I will keep a variable for that then, otherwise its misleading... So keep a
variable like cpufreq_enabled for it and set it to 1 as soon as this first
interrupt is gone... keep it in unlikely() too.
>>> + dvfs_info = kzalloc(sizeof(struct exynos_dvfs_data), GFP_KERNEL);
>>
>> sizeof(*dvfs_info) ??
> Isn't both same?
You need to read Documentation/CodingStyle.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
On 2 March 2013 15:04, Amit Daniel Kachhap wrote:
> This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
> they run at same frequency. The nature of exynos5440 clock controller is
> different from previous exynos controllers so not using the common exynos
> cpufreq framework. The major difference being interrupt notfication for
> frequency change. Also, OPP library is used for device tree parsing to get
> different parameters like frequency, voltage etc. Since the opp library sorts
> the frequency table in ascending order so they are again re-arranged in
> descending order. This will have one-to-one mapping with the clock controller
> state management logic.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> Changes in V2:
> * Added OPP library support to parse DT parameters.
> * Removed a hack to handle interrupts in bootup.
> * Added many review comments from Viresh and Inder.
Added? Thanks :)
>
> All these patches are dependent on Thomas Abraham common clock patches.
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html
>
> .../bindings/cpufreq/cpufreq-exynos5440.txt| 32 ++
> drivers/cpufreq/Kconfig.arm|9 +
> drivers/cpufreq/Makefile |1 +
> drivers/cpufreq/exynos5440-cpufreq.c | 450
>
> 4 files changed, 492 insertions(+), 0 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> new file mode 100644
> index 000..caa3f8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> @@ -0,0 +1,32 @@
> +
> +Exynos5440 cpufreq driver
> +---
> +
> +Exynos5440 SoC cpufreq driver for CPU frequency scaling.
> +
> +Required properties:
> +- interrupts: Interrupt to know the completion of cpu frequency change.
> +- operating-points: Table of frequencies and voltage CPU could be
> transitioned into,
> + in the decreasing order. Frequency should be in KHZ units and voltage
> + should be in microvolts.
> +- clocks: phandle of the clock from common clock binding. More description
> can
> + be found in
> Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> +Optional properties:
> +- clock-latency: Clock transition latency in microsecond.
> +
> +All the required listed above must be defined under node cpufreq.
> +
> +Example:
> +
> + cpufreq@16 {
> + compatible = "samsung,exynos5440-cpufreq";
> + reg = <0x16 0x1000>;
> + interrupts = <0 57 0>;
> + operating-points = <
> + 100 975000
> + 80 925000>;
> + clocks = <&clock 2>;
> + clock-latency = <10>;
> + };
> +
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 030ddf6..7ed9c4a 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
> This adds the CPUFreq driver for Samsung EXYNOS5250
> SoC.
>
> +config ARM_EXYNOS5440_CPUFREQ
> + def_bool SOC_EXYNOS5440
> + depends on HAVE_CLK && PM_OPP && OF
> + help
> + This adds the CPUFreq driver for Samsung EXYNOS5440
> + SoC. The nature of exynos5440 clock controller is
> + different than previous exynos controllers so not using
> + the common exynos framework.
> +
> config ARM_KIRKWOOD_CPUFREQ
> def_bool ARCH_KIRKWOOD && OF
> help
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 863fd18..c841438 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
> +obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
> obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> new file mode 100644
> index 000..2dc43b1
> --- /dev/null
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> @@ -0,0 +1,450 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Amit Daniel Kachhap
> + *
> + * EXYNOS5440 - CPU frequency scaling support
> + *
> + * This program is free software; you can
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
On 8 February 2013 08:56, amit kachhap wrote: > + dvfs_info->dvfs_init = true; why do you need this ? >>> This is added to synchronize the interrupts. >> >> How? You are setting it once in init() and not touching it afterwards. :) > > Yes but during init also if interrupts starts arriving before complete > initialization so to protect that case it is there. I suppose there > are other ways. Will check them Then clear any pending interrupts from init () -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
On 8 February 2013 00:38, amit kachhap wrote:
> Hi Viresh,
>
> Thanks for the detailed review. Will try to handle them in the next version,
np. I haven't seen reply to few questions, you missed them or accept them.
General tip: Leave a blank line before and after your comment, it makes it more
readable. :)
> On Thu, Feb 7, 2013 at 3:17 AM, Viresh Kumar wrote:
>> On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
>>> +Required properties:
>>> +- interrupts: Interrupt to know the completion of cpu frequency change.
>>> +- cpufreq_tbl: Table of frequencies and voltage CPU could be transitioned
>>> into,
>>
>> This has to be "operating-points" as in cpufreq-cpu0 driver.
> Yes I will check if opp table is beneficial. In my case it is just one
> time parsing of cpufreq table and those values(freq, volt) are not
> used later so did not use opp libraries.
Its one time parsing for everybody, nobody do it twice :)
>>> + for (old_index = 0;
>>> + freq_table[old_index].frequency != CPUFREQ_TABLE_END;
>>> + old_index++)
>>> + if (freq_table[old_index].frequency == freqs.old)
>>> + break;
>>> +
>>> + if (freq_table[old_index].frequency == CPUFREQ_TABLE_END) {
>>
>> How can this be true?
> This is error scenario
We have given cpufreq core a valid table and it has to set frequency from
this table only. How can cpu have any other freq here ? And you have done
something similar in your init() too, where you check if cpu has freq from the
table or not.
>>> + dvfs_info = kzalloc(sizeof(struct exynos_dvfs_data), GFP_KERNEL);
>>
>> sizeof(*dvfs_info) ?? why don't make it static too, as you have other
>> stuff too.. ?
>> The better option for single image solution to allocate everything
>> dynamically, so that
>> unused drivers don't occupy any space.
?
>>> + if ((len == 0) || (len / 2 > CPUFREQ_LEVEL_END)) {
>>
>> I really didn't like this limit you have put at the number of dvfs
>> points. Better
>> would be to use:
>>> + dvfs_info->dvfs_init = true;
>>
>> why do you need this ?
> This is added to synchronize the interrupts.
How? You are setting it once in init() and not touching it afterwards. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] cpufreq: exynos: Remove error return even if no soc found
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap wrote: > This change is needed for adding different type of cpufreq driver > and support single binary image. That's not sufficient, we need more description of the problem you faced. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
On Thu, Feb 7, 2013 at 10:39 AM, Inderpal Singh
wrote:
>> +#define DRIVER_NAME"exynos5440_dvfs"
>> +static struct cpufreq_driver exynos_driver = {
>> + .name = DRIVER_NAME,
>> +};
>> +
>
> Since this driver is only for exynos5440, having the same names as
> common exynos-cpufreq is misleading.
Where is it same?
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] cpufreq: exynos: Adding cpufreq driver for exynos5440
On Thu, Feb 7, 2013 at 1:09 AM, Amit Daniel Kachhap
wrote:
> This patch adds dvfs support for exynos5440 SOC. The nature of exynos5440
> clock controller is different from previous exynos controllers so not using
> the common exynos cpufreq framework. Also, the device tree parsing is added
> to get different parameters like frequency, voltage etc.
Some information about platform cpu configuration would be helpful.. cpus, type,
clock lines for cpus - shared/separate?
> Signed-off-by: Amit Daniel Kachhap
> ---
> .../bindings/cpufreq/cpufreq-exynos5440.txt| 24 ++
> drivers/cpufreq/Kconfig.arm|8 +
> drivers/cpufreq/Makefile |1 +
> drivers/cpufreq/exynos5440-cpufreq.c | 448
>
> 4 files changed, 481 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> new file mode 100644
> index 000..96cb0ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
> @@ -0,0 +1,24 @@
> +
> +Exynos5440 cpufreq driver
> +---
> +
> +Exynos5440 SoC cpufreq driver for CPU frequency scaling.
> +
> +Required properties:
> +- interrupts: Interrupt to know the completion of cpu frequency change.
> +- cpufreq_tbl: Table of frequencies and voltage CPU could be transitioned
> into,
This has to be "operating-points" as in cpufreq-cpu0 driver.
> + in the decreasing order. Frequency should be in KHZ units and voltage
> + should be in microvolts.
> +
> +All the required listed above must be defined under node cpufreq.
> +
> +Example:
> +
> + cpufreq@16 {
> + compatible = "samsung,exynos5440-cpufreq";
> + reg = <0x16 0x1000>;
> + interrupts = <0 57 0>;
> + cpufreq_tbl = < 120 1025000
> + 100 975000
> + 80 925000 >;
> + };
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> new file mode 100644
> index 000..41d39e2
> --- /dev/null
> +++ b/drivers/cpufreq/exynos5440-cpufreq.c
> @@ -0,0 +1,448 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Amit Daniel Kachhap
> + *
> + * EXYNOS5440 - CPU frequency scaling support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*Register definations*/
> +#define XMU_DVFS_CTRL 0x0060
> +#define XMU_PMU_P0_7 0x0064
> +#define XMU_C0_3_PSTATE0x0090
> +#define XMU_P_LIMIT0x00A0
> +#define XMU_P_STATUS 0x00A4
> +#define XMU_PMUEVTEN 0x00D0
> +#define XMU_PMUIRQEN 0x00D4
> +#define XMU_PMUIRQ 0x00D8
> +
> +/*PMU mask and shift definations*/
> +#define P_VALUE_MASK 0x7
> +
> +#define XMU_DVFS_CTRL_EN_SHIFT 0
> +
> +#define P0_7_CPUCLKDEV_SHIFT 21
> +#define P0_7_CPUCLKDEV_MASK0x7
> +#define P0_7_ATBCLKDEV_SHIFT 18
> +#define P0_7_ATBCLKDEV_MASK0x7
> +#define P0_7_CSCLKDEV_SHIFT15
> +#define P0_7_CSCLKDEV_MASK 0x7
> +#define P0_7_CPUEMA_SHIFT 28
> +#define P0_7_CPUEMA_MASK 0xf
> +#define P0_7_L2EMA_SHIFT 24
> +#define P0_7_L2EMA_MASK0xf
> +#define P0_7_VDD_SHIFT 8
> +#define P0_7_VDD_MASK 0x7f
> +#define P0_7_FREQ_SHIFT0
> +#define P0_7_FREQ_MASK 0xff
> +
> +#define C0_3_PSTATE_VALID_SHIFT8
> +#define C0_3_PSTATE_CURR_SHIFT 4
> +#define C0_3_PSTATE_NEW_SHIFT 0
> +
> +#define PSTATE_CHANGED_EVTEN_SHIFT 0
> +
> +#define PSTATE_CHANGED_IRQEN_SHIFT 0
> +
> +#define PSTATE_CHANGED_SHIFT 0
> +
> +/*some constant values for clock divider calculation*/
> +#define CPU_DIV_FREQ_MAX 500
> +#define CPU_DBG_FREQ_MAX 375
> +#define CPU_ATB_FREQ_MAX 500
> +
> +#define PMIC_LOW_VOLT 0x30
> +#define PMIC_HIGH_VOLT 0x28
> +
> +#define CPUEMA_HIGH0x2
> +#define CPUEMA_MID 0x4
> +#define CPUEMA_LOW 0x7
> +
> +#define L2EMA_HIGH 0x1
> +#define L2EMA_MID 0x3
> +#define L2EMA_LOW 0x4
> +
> +#define DIV_TAB_MAX2
> +/*frequency unit is 20MHZ*/
> +#define FREQ_UNIT 20
> +#define MAX_VOLTAGE155 /*In micro volt*/
> +#define VOLTAGE_STEP 12500 /*In micro volt*/
> +
> +#define DRIVER_NAME"exynos5440_dvfs"
> +#define DEF_TRANS_LATENCY
Re: [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
On 31 January 2013 21:42, Viresh Kumar wrote: > On 31 January 2013 21:37, Tomasz Figa wrote: >> Hmm. Now as I think of it, there might be another confusing aspect: >> >> Could you explain what "sw coordination" and "any coordination" mean? >> I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus >> masks. > > Check this out: > > https://lkml.org/lkml/2013/1/30/587 You would really like to look and ack this one too: https://lkml.org/lkml/2013/1/30/592 -- 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: exynos: Broadcast frequency change notifications for all cores
On 31 January 2013 21:37, Tomasz Figa wrote: > Hmm. Now as I think of it, there might be another confusing aspect: > > Could you explain what "sw coordination" and "any coordination" mean? > I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus > masks. Check this out: https://lkml.org/lkml/2013/1/30/587 -- 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: exynos: Broadcast frequency change notifications for all cores
On 31 January 2013 20:34, Tomasz Figa wrote: > Well, the fact that it isn't used at the moment doesn't mean that it > shouldn't be set correctly. The field is present in the structure and has > a set of defined values - one of which should be selected. For example, > I can imagine some governor taking this information into account. Governors already take this information but from a different variable: policy->cpus. Look at the patch which added it: commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36 Author: Venkatesh Pallipadi Date: Wed Dec 14 15:05:00 2005 -0500 P-state software coordination for ACPI core http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown --- drivers/acpi/processor_perflib.c | 228 + include/acpi/processor.h | 27 - include/linux/cpufreq.h | 4 ++ 3 files changed, 258 insertions(+), 1 deletion(-) It was clearly for ACPI, but was probably named badly and we people got confused that it is for our use. -- 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] cpufreq: exynos: Broadcast frequency change notifications for all cores
On 31 January 2013 20:15, Tomasz Figa wrote:
> On Thursday 31 of January 2013 09:50:37 Viresh Kumar wrote:
>> > + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
>> I couldn't understand the use of this change. Can you please explain ?
>
> All cores on Exynos SoCs share the same clock source, which means that
> they all always run at the same frequency. So setting frequency on one
> core sets the frequency on all cores and so it doesn't matter on which
> core the frequency setting operation is done.
Great, that's like most other platforms and for this you just need to set mask
of all the possible cpus (online or offline) into policy->cpus
> As you can see in include/linux/cpufreq.h:
>
> #define CPUFREQ_SHARED_TYPE_ANY (3) /* Freq can be set from any dependent
> CPU*/
>
> which basically tells (together with rest of the patch) the cpufreq
> subsystem about what I wrote earlier.
I don't think so. Because i wasn't using it on my system and it was
working well.
Then i grepped it in kernel source
viresh@blr-linut-001:$ git grep shared_type drivers/cpufreq/
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
CPUFREQ_SHARED_TYPE_ALL ||
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type ==
CPUFREQ_SHARED_TYPE_ANY) {
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_HW;
drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/db8500-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/omap-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
I couldn't see any core file using this stuff other than acpi-cpufreq.c,
which is for x86 only systems if i am not wrong.
@Rafael: You view on this.. ? Actually i believe it was just used by many
ARM drivers without knowing the real use of it and new drivers have just
followed it.
I can get a patch to fix it at all places if you agree.
BTW, grep in full kernel source gave, which is again acpi only:
viresh@blr-linut-001:$ git grep shared_type
arch/arm/mach-tegra/cpu-tegra.c:policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_HW;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/acpi/processor_perflib.c:
match_pr->performance->shared_type =
drivers/acpi/processor_perflib.c:
pr->performance->shared_type;
drivers/acpi/processor_perflib.c:
pr->performance->shared_type = CPUFREQ_SHARED_TYPE_ALL;
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/acpi/processor_throttling.c:pthrottling->shared_type =
pdomain->coord_type;
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/acpi/processor_throttling.c:if (p_throttling->shared_type
== DOMAIN_COORD_TYPE_SW_ANY) {
drivers/acpi/processor_throttling.c:
pthrottling->shared_type = DOMAIN_COORD_TYPE_SW_ALL;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type = perf->shared_type;
drivers/cpufreq/acpi-cpufreq.c: if (policy->shared_type ==
CPUFREQ_SHARED_TYPE_ALL ||
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type ==
CPUFREQ_SHARED_TYPE_ANY) {
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/acpi-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_HW;
drivers/cpufreq/cpufreq-cpu0.c: policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/db8500-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ALL;
drivers/cpufreq/omap-cpufreq.c: policy->shared_type =
CPUFREQ_SHARED_TYPE_ANY;
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/cpufreq/speedstep-centrino.c: if
(policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:
rtlpcipriv->bt_coexist.bt_radio_shared_type =
drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
pcipriv->bt_coexist.bt_radio_shared_type =
drivers/net/wireless/rtlwifi/rtl8723ae/hw.c:
pcipriv->bt_coexist.bt_radio_shared_type);
drivers/net/
Re: [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
On Tue, Nov 13, 2012 at 2:56 PM, Tomasz Figa wrote:
> On Exynos SoCs all cores share the same frequency setting, so changing
> frequency of one core will affect rest of cores.
>
> This patch modifies the exynos-cpufreq driver to inform cpufreq core
> about this behavior and broadcast frequency change notifications for all
> cores.
> /* When the new frequency is lower than current frequency */
> if ((freqs.new < freqs.old) ||
> @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> cpumask_copy(policy->related_cpus, cpu_possible_mask);
> cpumask_copy(policy->cpus, cpu_online_mask);
> } else {
> + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> cpumask_setall(policy->cpus);
I couldn't understand the use of this change. Can you please explain ?
--
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] drivers: cpufreq: exynos: update related_cpus mask to fix hotplug dump
On 28 January 2013 17:56, Rafael J. Wysocki wrote: > So here's a deal: I'll drop "cpufreq: Simplify cpufreq_add_dev()" for now and > you'll generate a new patch that won't cause the WARN_ON() to trigger. OK? :( Or what about set all cpus from policy->cpus into related_cpus in our core code? So, if platform sets any additional cpus, they would be retained? -- 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] drivers: cpufreq: exynos: update related_cpus mask to fix hotplug dump
On Thu, Jan 24, 2013 at 9:40 AM, Inderpal Singh
wrote:
> commit "7e6087e595d3...cpufreq: Simplify cpufreq_add_dev()" started using
> related_cpus mask to check if the current cpu is already managed.
>
> With above commit hotplug in exynos gives following dump.
>
> / $ echo 1 > /sys/devices/system/cpu/cpu1/online
> CPU1: Booted secondary processor
> [ cut here ]
> WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0x88/0xbc()
> sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0/cpufreq'
> Modules linked in:
> [] (unwind_backtrace+0x0/0xf8) from []
> (warn_slowpath_common+0x4c/0x64)
> [] (warn_slowpath_common+0x4c/0x64) from []
> (warn_slowpath_fmt+0x30/0x40)
> [] (warn_slowpath_fmt+0x30/0x40) from []
> (sysfs_add_one+0x88/0xbc)
> [] (sysfs_add_one+0x88/0xbc) from []
> (sysfs_do_create_link+0x110/0x208)
> [] (sysfs_do_create_link+0x110/0x208) from []
> (cpufreq_add_dev_interface+0x218/0x2b0)
> [] (cpufreq_add_dev_interface+0x218/0x2b0) from []
> (cpufreq_add_dev+0x30c/0x448)
> [] (cpufreq_add_dev+0x30c/0x448) from []
> (cpufreq_cpu_callback+0x94/0x9c)
> [] (cpufreq_cpu_callback+0x94/0x9c) from []
> (notifier_call_chain+0x44/0x84)
> [] (notifier_call_chain+0x44/0x84) from []
> (__cpu_notify+0x28/0x44)
> [] (__cpu_notify+0x28/0x44) from [] (_cpu_up+0x104/0x154)
> [] (_cpu_up+0x104/0x154) from [] (cpu_up+0x64/0x84)
> [] (cpu_up+0x64/0x84) from [] (store_online+0x50/0x78)
> [] (store_online+0x50/0x78) from []
> (dev_attr_store+0x18/0x24)
> [] (dev_attr_store+0x18/0x24) from []
> (sysfs_write_file+0x168/0x198)
> [] (sysfs_write_file+0x168/0x198) from []
> (vfs_write+0x9c/0x140)
> [] (vfs_write+0x9c/0x140) from [] (sys_write+0x3c/0x70)
> [] (sys_write+0x3c/0x70) from []
> (ret_fast_syscall+0x0/0x30)
> ---[ end trace 3d002b0ded69f43b ]---
>
> This patch fixes it by updating the related_cpus mask.
>
> Tested on Rafael's linux-next.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/cpufreq/exynos-cpufreq.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 7012ea8..8ba4cdb 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -238,6 +238,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> cpumask_copy(policy->cpus, cpu_online_mask);
> } else {
> policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> + cpumask_setall(policy->related_cpus);
> cpumask_setall(policy->cpus);
This is required for all SMP systems.
Acked-by: Viresh Kumar
--
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 6/6] mmc: sdhci-s3c: Add device tree support
On 3/27/2012 9:49 PM, Arnd Bergmann wrote: > These bindings came up in a discussion IRC today. I think it's rather bad that > we can't agree on a common way to name the properties for mmc. We have > bindings being proposed or already included from Anton, Stephen, Shawn, > Rajendra, Viresh, Lee and Thomas. Almost all of them define GPIO pins > for card detect and write protect, as well properties to define the bus > width and high-speed modes, but we seem to have almost as many different > definitions of these as we have drivers. > > Can we please come up with a common binding for these? Is there any progress on this? Sorry i wasn't following all mails. How should i progress for sdhci-spear? -- 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 30/31] ARM: amba: spear: use common amba device initializers
On 1/20/2012 3:02 PM, Russell King - ARM Linux wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-spear3xx/spear300.c | 14 ++
> arch/arm/mach-spear3xx/spear3xx.c | 27 ---
> 2 files changed, 6 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm/mach-spear3xx/spear300.c
> b/arch/arm/mach-spear3xx/spear300.c
> index 6fdeec9..9da50e281 100644
> --- a/arch/arm/mach-spear3xx/spear300.c
> +++ b/arch/arm/mach-spear3xx/spear300.c
> @@ -430,18 +430,8 @@ static struct pl061_platform_data gpio1_plat_data = {
> .irq_base = SPEAR300_GPIO1_INT_BASE,
> };
>
> -struct amba_device spear300_gpio1_device = {
> - .dev = {
> - .init_name = "gpio1",
> - .platform_data = &gpio1_plat_data,
> - },
> - .res = {
> - .start = SPEAR300_GPIO_BASE,
> - .end = SPEAR300_GPIO_BASE + SZ_4K - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - .irq = {SPEAR300_VIRQ_GPIO1},
> -};
> +AMBA_APB_DEVICE(spear300_gpio1, "gpio1", 0, SPEAR300_GPIO_BASE,
> + {SPEAR300_VIRQ_GPIO1}, &gpio1_plat_data);
>
> /* spear300 routines */
> void __init spear300_init(struct pmx_mode *pmx_mode, struct pmx_dev
> **pmx_devs,
> diff --git a/arch/arm/mach-spear3xx/spear3xx.c
> b/arch/arm/mach-spear3xx/spear3xx.c
> index bc4f1c6..b1733c3 100644
> --- a/arch/arm/mach-spear3xx/spear3xx.c
> +++ b/arch/arm/mach-spear3xx/spear3xx.c
> @@ -28,31 +28,12 @@ static struct pl061_platform_data gpio_plat_data = {
> .irq_base = SPEAR3XX_GPIO_INT_BASE,
> };
>
> -struct amba_device spear3xx_gpio_device = {
> - .dev = {
> - .init_name = "gpio",
> - .platform_data = &gpio_plat_data,
> - },
> - .res = {
> - .start = SPEAR3XX_ICM3_GPIO_BASE,
> - .end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
> -};
> +AMBA_APB_DEVICE(spear3xx_gpio, "gpio", 0, SPEAR3XX_ICM3_GPIO_BASE,
> + {SPEAR3XX_IRQ_BASIC_GPIO}, &gpio_plat_data);
>
> /* uart device registration */
> -struct amba_device spear3xx_uart_device = {
> - .dev = {
> - .init_name = "uart",
> - },
> - .res = {
> - .start = SPEAR3XX_ICM1_UART_BASE,
> - .end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - .irq = {SPEAR3XX_IRQ_UART},
> -};
> +AMBA_APB_DEVICE(spear3xx_uart, "uart", 0, SPEAR3XX_ICM1_UART_BASE,
> + {SPEAR3XX_IRQ_UART}, NULL);
>
> /* Do spear3xx familiy common initialization part here */
> void __init spear3xx_init(void)
Acked-by: Viresh Kumar
--
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 15/31] ARM: amba: spear: get rid of NO_IRQ initializers
On 1/20/2012 2:57 PM, Russell King - ARM Linux wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/mach-spear3xx/spear300.c |2 +-
> arch/arm/mach-spear3xx/spear3xx.c |4 ++--
> arch/arm/mach-spear6xx/spear6xx.c | 10 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-spear3xx/spear300.c
> b/arch/arm/mach-spear3xx/spear300.c
> index a5e46b4..6fdeec9 100644
> --- a/arch/arm/mach-spear3xx/spear300.c
> +++ b/arch/arm/mach-spear3xx/spear300.c
> @@ -440,7 +440,7 @@ struct amba_device spear300_gpio1_device = {
> .end = SPEAR300_GPIO_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {SPEAR300_VIRQ_GPIO1, NO_IRQ},
> + .irq = {SPEAR300_VIRQ_GPIO1},
> };
>
> /* spear300 routines */
> diff --git a/arch/arm/mach-spear3xx/spear3xx.c
> b/arch/arm/mach-spear3xx/spear3xx.c
> index 10af45d..bc4f1c6 100644
> --- a/arch/arm/mach-spear3xx/spear3xx.c
> +++ b/arch/arm/mach-spear3xx/spear3xx.c
> @@ -38,7 +38,7 @@ struct amba_device spear3xx_gpio_device = {
> .end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {SPEAR3XX_IRQ_BASIC_GPIO, NO_IRQ},
> + .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
> };
>
> /* uart device registration */
> @@ -51,7 +51,7 @@ struct amba_device spear3xx_uart_device = {
> .end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {SPEAR3XX_IRQ_UART, NO_IRQ},
> + .irq = {SPEAR3XX_IRQ_UART},
> };
>
> /* Do spear3xx familiy common initialization part here */
> diff --git a/arch/arm/mach-spear6xx/spear6xx.c
> b/arch/arm/mach-spear6xx/spear6xx.c
> index e0f6628..b997b1b 100644
> --- a/arch/arm/mach-spear6xx/spear6xx.c
> +++ b/arch/arm/mach-spear6xx/spear6xx.c
> @@ -34,7 +34,7 @@ struct amba_device uart_device[] = {
> .end = SPEAR6XX_ICM1_UART0_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {IRQ_UART_0, NO_IRQ},
> + .irq = {IRQ_UART_0},
> }, {
> .dev = {
> .init_name = "uart1",
> @@ -44,7 +44,7 @@ struct amba_device uart_device[] = {
> .end = SPEAR6XX_ICM1_UART1_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {IRQ_UART_1, NO_IRQ},
> + .irq = {IRQ_UART_1},
> }
> };
>
> @@ -73,7 +73,7 @@ struct amba_device gpio_device[] = {
> .end = SPEAR6XX_CPU_GPIO_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {IRQ_LOCAL_GPIO, NO_IRQ},
> + .irq = {IRQ_LOCAL_GPIO},
> }, {
> .dev = {
> .init_name = "gpio1",
> @@ -84,7 +84,7 @@ struct amba_device gpio_device[] = {
> .end = SPEAR6XX_ICM3_GPIO_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {IRQ_BASIC_GPIO, NO_IRQ},
> + .irq = {IRQ_BASIC_GPIO},
> }, {
> .dev = {
> .init_name = "gpio2",
> @@ -95,7 +95,7 @@ struct amba_device gpio_device[] = {
> .end = SPEAR6XX_ICM2_GPIO_BASE + SZ_4K - 1,
> .flags = IORESOURCE_MEM,
> },
> - .irq = {IRQ_APPL_GPIO, NO_IRQ},
> + .irq = {IRQ_APPL_GPIO},
> }
> };
>
Acked-by: Viresh Kumar
--
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 V2 1/1] dmaengine/amba-pl08x: Add support for s3c64xx DMAC
On 9/28/2011 5:24 PM, Alim Akhtar wrote: > I did Modified pl08x_cctl_bits(), but for some reason i reverted it back. > what i was doing something like returning just __retbits__ instead of > retbits |= tsize << PL080_CONTROL_TRANSFER_SIZE_SHIFT; > and doing the below for the __non-s3c__ controllers in the > pl08x_fill_lli_for_desc(). > cctl |= 1 << PL080_CONTROL_TRANSFER_SIZE_SHIFT; > pl08x_fill_lli_for_desc(&bd, num_llis++, 1, cctl); > One way out would be: Don't do retbits |= tsize << PL080_CONTROL_TRANSFER_SIZE_SHIFT in pl08x_cctl_bits() and do this conditionally in pl08x_fill_lli_for_desc(). This needs adding tsize argument in fill_lli_**() routine and removing it from cctl_bits(). Probably this is what you were mentioning. -- 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 V2 1/1] dmaengine/amba-pl08x: Add support for s3c64xx DMAC
On 9/28/2011 2:20 PM, Alim Akhtar wrote: > The main difference between Primecell PL080 and samsung variant is in > LLI control register bit [0:11] is reserved in case of samsung pl080 > and one extra register is add to hold the transfer size at offset > 0x10. The purpose of cctl1 is store the transfer_size. So, actually you need to modify pl08x_fill_lli_for_desc() and pl08x_cctl_bits() routines. Updating cctl1 on the last lli will not solve your purpose, and transfers needing more than one lli will fail. BTW, did you try testing your patch for more than one LLI. -- 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 V2 1/1] dmaengine/amba-pl08x: Add support for s3c64xx DMAC
On 9/28/2011 11:20 AM, Alim Akhtar wrote:
> Signed-off-by: Alim Akhtar
> ---
> drivers/dma/amba-pl08x.c | 135
> ++
> 1 files changed, 112 insertions(+), 23 deletions(-)
>
It would be good if you can add pick some part from cover-letter and put it in
commit log too.
> diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
> index cd8df7f..501540f 100644
> --- a/drivers/dma/amba-pl08x.c
> +++ b/drivers/dma/amba-pl08x.c
> @@ -110,6 +129,11 @@ struct pl08x_lli {
> u32 dst;
> u32 lli;
> u32 cctl;
> + /*
> + * Samsung pl080 DMAC has one exrta control register
> + * which is used to hold the transfer_size
> + */
> + u32 cctl1;
Will you write transfer_size in cctl also? What is the purpose of cctl1?
> @@ -215,11 +255,23 @@ static void pl08x_start_txd(struct pl08x_dma_chan
> *plchan,
> cpu_relax();
>
> /* Do not access config register until channel shows as inactive */
> - val = readl(phychan->base + PL080_CH_CONFIG);
> - while ((val & PL080_CONFIG_ACTIVE) || (val & PL080_CONFIG_ENABLE))
> + if (pl08x->vd->is_pl080_s3c) {
> + val = readl(phychan->base + PL080S_CH_CONFIG);
> + while ((val & PL080_CONFIG_ACTIVE) ||
> + (val & PL080_CONFIG_ENABLE))
> + val = readl(phychan->base + PL080S_CH_CONFIG);
> +
> + writel(val | PL080_CONFIG_ENABLE,
> + phychan->base + PL080S_CH_CONFIG);
> + } else {
> val = readl(phychan->base + PL080_CH_CONFIG);
> + while ((val & PL080_CONFIG_ACTIVE) ||
> + (val & PL080_CONFIG_ENABLE))
> + val = readl(phychan->base + PL080_CH_CONFIG);
>
> - writel(val | PL080_CONFIG_ENABLE, phychan->base + PL080_CH_CONFIG);
> + writel(val | PL080_CONFIG_ENABLE,
> + phychan->base + PL080_CH_CONFIG);
> + }
You have similar stuff in most the the changes in this patch, because offset of
config register changes for s3c, you placed in if,else block.
If you check these changes again, there is a lot of code duplication in this
if,else
blocks. The only different thing in if,else is the offset of CH_CONFIG register.
It would be much better if you can do following:
u32 ch_cfg_off;
if (pl08x->vd->is_pl080_s3c)
ch_cfg_off = PL080S_CH_CONFIG;
else
ch_cfg_off = PL080_CH_CONFIG;
Now, this offset can be used in existing code, without much code duplication.
> @@ -569,6 +641,7 @@ static int pl08x_fill_llis_for_desc(struct
> pl08x_driver_data *pl08x,
> u32 cctl, early_bytes = 0;
> size_t max_bytes_per_lli, total_bytes = 0;
> struct pl08x_lli *llis_va;
> + size_t lli_len = 0, target_len, tsize, odd_bytes;
>
> txd->llis_va = dma_pool_alloc(pl08x->pool, GFP_NOWAIT, &txd->llis_bus);
> if (!txd->llis_va) {
> @@ -700,7 +773,7 @@ static int pl08x_fill_llis_for_desc(struct
> pl08x_driver_data *pl08x,
>* width left
>*/
> while (bd.remainder > (mbus->buswidth - 1)) {
> - size_t lli_len, tsize, width;
> + size_t width;
>
why do we need above two changes. odd_bytes and target_len are still unused.
> /*
>* If enough left try to send max possible,
> @@ -759,6 +832,9 @@ static int pl08x_fill_llis_for_desc(struct
> pl08x_driver_data *pl08x,
> llis_va[num_llis - 1].lli = 0;
> /* The final LLI element shall also fire an interrupt. */
> llis_va[num_llis - 1].cctl |= PL080_CONTROL_TC_IRQ_EN;
> + /* Keep the TransferSize seperate to fill samsung specific register */
> + if (pl08x->vd->is_pl080_s3c)
> + llis_va[num_llis - 1].cctl1 |= lli_len;
I couldn't get this completely. Why do you keep only length of
last lli in cctl1. what about all other llis. Also why |=
and not directly cctl1 = lli_len
--
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
