Re: Re: [PATCH V12 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files
Hi Wim, I rebased this patch series on Kukjin's for-next branch. That is the reason for missing this context code in the patch. As this is a dts file change and if Kukjin accepts to merge this patch into your "linux-watchdog-next" tree you can rebase and apply it. Best Wishes, Leela Krishna. --- Original Message --- Sender : Wim Van Sebroeck Date : Jan 10, 2014 13:11 (GMT+05:30) Title : Re: [PATCH V12 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files Hi Leela, > This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to > handle PMU register accesses in a centralized way using syscon driver > > Signed-off-by: Leela Krishna Amudala > Reviewed-by: Tomasz Figa > Reviewed-by: Doug Anderson > Tested-by: Doug Anderson > --- ... > diff --git a/arch/arm/boot/dts/exynos5420.dtsi > b/arch/arm/boot/dts/exynos5420.dtsi > index b1fa334..cd47db0 100644 > --- a/arch/arm/boot/dts/exynos5420.dtsi > +++ b/arch/arm/boot/dts/exynos5420.dtsi > @@ -402,4 +402,9 @@ > clock-names = "gscl"; > samsung,power-domain = <&gsc_pd>; > }; I can't add this patch since there is no "gscl" in the current linux-tree. Is this depending on another patch or are we going to fix this in another way? Kind regards, Wim. Best Wishes, Leela Krishna.
Re: [PATCH V12 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files
Hi Leela, > This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to > handle PMU register accesses in a centralized way using syscon driver > > Signed-off-by: Leela Krishna Amudala > Reviewed-by: Tomasz Figa > Reviewed-by: Doug Anderson > Tested-by: Doug Anderson > --- ... > diff --git a/arch/arm/boot/dts/exynos5420.dtsi > b/arch/arm/boot/dts/exynos5420.dtsi > index b1fa334..cd47db0 100644 > --- a/arch/arm/boot/dts/exynos5420.dtsi > +++ b/arch/arm/boot/dts/exynos5420.dtsi > @@ -402,4 +402,9 @@ > clock-names = "gscl"; > samsung,power-domain = <&gsc_pd>; > }; I can't add this patch since there is no "gscl" in the current linux-tree. Is this depending on another patch or are we going to fix this in another way? Kind regards, Wim. -- 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 V12 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register
Hi Leela > Add device tree support for exynos5250 and 5420 SoCs and use syscon regmap > interface > to configure AUTOMATIC_WDT_RESET_DISABLE and MASK_WDT_RESET_REQUEST registers > of PMU > to mask/unmask enable/disable of watchdog in probe and s2r scenarios. > > Signed-off-by: Leela Krishna Amudala > Signed-off-by: Doug Anderson This patch has been added to linux-watchdog-next. Kind regards, Wim. -- 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 v12 7/7] thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412)
On Fri, 2013-12-20 at 15:24 +0100, Lukasz Majewski wrote:
> This patch provides auto disable/enable operation for boost. It uses already
> present thermal infrastructure to provide BOOST hysteresis.
> The TMU data has been modified to work properly with or without BOOST.
> Hence, the two first trip points with corresponding clip frequencies were
> adjusted.
>
> The first one was reduced from 85 to 70 degrees and clip frequency was
> increased to 1.4 GHz from 800 MHz. This trip point is in fact responsible
> for providing BOOST hysteresis. When temperature exceeds 70 deg, the maximal
> non BOOST frequency for Exynos4412 is imposed.
>
> Since the first trigger level has been "stolen" for BOOST, the second one
> needs to be a compromise for the previously used two for non BOOST
> configuration. The 95 deg with modified clip freq (to 400 MHz) shall provide
> a good balance between cooling down the overheated device and throughput on
> an acceptable level.
>
> Two last trigger levels were not modified since, they cause platform shutdown
> on emergency overheat situation.
> Third trip point passage results in SW managed shut down of the system.
> If the last trip point is crossed, the PMU HW generates the power off
> signal.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Myungjoo Ham
> Acked-by: Eduardo Valentin
Reviewed-by: Zhang Rui
thanks,
rui
>
> ---
> Changes for v12:
> - More verbose patch description to explain new TMU temperature assignment
> for Exynos4412
>
> Changes for v11:
> - Use only one thermal data set
> - Adjust Exynos4412 thermal data to work with or without BOOST
>
> Changes for v10:
> - Remove boost related code from thermal_core.c
> - Use already present thermal infrastructure to provide thermal hysteresis
> - Introduce special set of TMU data for BOOST
>
> Changes for v9:
> - None
>
> Changes for v8:
> - Move cpufreq_boost_* stub functions definition (needed when cpufreq
> is not compiled in) to cpufreq.h at cpufreq core support commit
>
> Changes for v7:
> - None
>
> Changes for v6:
> - Disable boost only when supported and enabled
> - Protect boost related thermal_zone_device struct fields with mutex
> - Evaluate temperature trend during boost enable decision
> - Create separate methods to handle boost enable/disable
> (thermal_boost_{enable|disable}) operations
> - Boost is disabled at any trip point passage (not only the non critical
> one)
> - Add stub definitions for cpufreq boost functions used when
> CONFIG_CPU_FREQ is NOT defined.
>
> Changes for v5:
> - Move boost disable code from cpu_cooling.c to thermal_core.c
> (to handle_non_critical_trips)
> - Extent struct thermal_zone_device by adding overheated bool flag
> - Implement auto enable of boost after device cools down
> - Introduce boost_polling flag, which indicates if thermal uses it's
> predefined
> pool delay or has woken up thermal workqueue only to wait until device
> cools down.
>
> Changes for v4:
> - New patch
>
> drivers/thermal/samsung/exynos_tmu_data.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index 073c292..476b768 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -131,8 +131,8 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
>
> #define EXYNOS4412_TMU_DATA \
> .threshold_falling = 10, \
> - .trigger_levels[0] = 85, \
> - .trigger_levels[1] = 103, \
> + .trigger_levels[0] = 70, \
> + .trigger_levels[1] = 95, \
> .trigger_levels[2] = 110, \
> .trigger_levels[3] = 120, \
> .trigger_enable[0] = true, \
> @@ -155,12 +155,12 @@ static const struct exynos_tmu_registers
> exynos4412_tmu_registers = {
> .second_point_trim = 85, \
> .default_temp_offset = 50, \
> .freq_tab[0] = { \
> - .freq_clip_max = 800 * 1000, \
> - .temp_level = 85, \
> + .freq_clip_max = 1400 * 1000, \
> + .temp_level = 70, \
> }, \
> .freq_tab[1] = { \
> - .freq_clip_max = 200 * 1000, \
> - .temp_level = 103, \
> + .freq_clip_max = 400 * 1000, \
> + .temp_level = 95, \
> }, \
> .freq_tab_count = 2, \
> .registers = &exynos4412_tmu_registers, \
--
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 v12 0/7] cpufreq:boost: CPU Boost mode support
On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote: > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > Hi Rafael, > > Hi, > > > > This patch series introduces support for CPU overclocking technique > > > called Boost. > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > component: > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > software oriented one (like the one done at Exynos). > > > For this reason cpufreq/freq_table code has been reorganized to > > > include common code. > > > > > > Important design decisions: > > > - Boost related code is compiled-in unconditionally to cpufreq core > > > and disabled by default. The cpufreq_driver is responsibile for > > > setting boost_supported flag and providing set_boost callback(if HW > > > support is needed). For software managed boost, special Kconfig flag - > > > CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be selected only > > > when a target platform has thermal framework properly configured. > > > > > > - struct cpufreq_driver has been extended with boost related fields: > > > -- boost_supported - when driver supports boosting > > > -- boost_enabled - boost state > > > -- set_boost - callback to function, which is necessary to > > >enable/disable boost > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > > > visible _only_ when cpufreq driver supports Boost. > > > > > > - No special spin_lock for Boost was created. The one from cpufreq > > > core was reused. > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > changed, then the policy list is iterated and proper adjustements are > > > done. > > > > > > - To improve safety level, the thermal framework is also extended to > > > disable software boosting, when thermal trip point is reached. After > > > cooling down the boost can be enabled again. This emulates behaviour > > > similar to HW managed boost (like x86) > > > > > > Tested at HW: > > >Exynos 4412 3.13-rc4 Linux > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > Lukasz Majewski (7): > > > cpufreq: Add boost frequency support in core > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with common > > > boost solution > > > cpufreq:boost:Kconfig: Provide support for software managed BOOST > > > cpufreq:exynos:Extend Exynos cpufreq driver to support boost > > > framework > > > Documentation:cpufreq:boost: Update BOOST documentation > > > cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > > > thermal:exynos:boost: Automatic enable/disable of BOOST feature (at > > > Exynos4412) > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > drivers/cpufreq/Kconfig |4 + > > > drivers/cpufreq/Kconfig.arm | 15 > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > +++-- drivers/cpufreq/cpufreq.c | > > > 118 - > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > drivers/cpufreq/freq_table.c | 56 -- > > > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > > > include/linux/cpufreq.h | 24 ++ 10 files > > > changed, 261 insertions(+), 85 deletions(-) > > > > > > > A gentle ping about BOOST patches. > > > > Its been already acked by Viresh and Eduardo. > > > > It applies on kernel_pm/bleeding_edge SHA1: > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > It looks like Rui is still looking into this. > > Rui, are you fine with this series? > Yes, I'm okay with the thermal related parts of this patch set. thanks, rui > Rafael > -- 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/6 v2] crypto:s5p-sss: Add device tree support
Hi Naveen,
On 10 January 2014 11:37, Naveen Krishna Ch wrote:
> Hello Tomasz,
>
[snip]
>>> *pdev)
>>> static struct platform_driver s5p_aes_crypto = {
>>> .probe = s5p_aes_probe,
>>> .remove = s5p_aes_remove,
>>> + .id_table = s5p_sss_ids,
>>> .driver = {
>>> .owner = THIS_MODULE,
>>> .name = "s5p-secss",
>>> + .of_match_table = s5p_sss_dt_match,
>>
>>
>> .of_match_table = of_match_ptr(s5p_sss_dt_match),
> I dint use it, Some time back there was a patchset from Sachin
> https://lkml.org/lkml/2013/9/28/61
> Please suggest me on this.
In those cases the structure was always compiled in. i.e., it was not protected
by #ifdef CONFIG_OF. Hence use of of_match_ptr was not required. of_match_ptr
abstracts this check depending on OF is enabled or not. In the case of
this (sss) driver,
since you are using CONFIG_OF to selectively compile out the code (and esp.
s5p_sss_dt_match structure), use of of_match_ptr will make the code
simpler as it
avoids the use of a dummy structure definition (the #else part of the
struct definition) when OF is
disabled. Hope this clarifies.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6 v2] crypto:s5p-sss: Add device tree support
Hello Tomasz,
Thanks for time and review comments they are really helping me a lot
in getting the patches merged.
Secondly, accept my apologies for not giving proper writeup of why i
din't address
few of your comments on v1 of this patchset.
On 9 January 2014 19:44, Tomasz Figa wrote:
> Hi Naveen,
>
>
> On 09.01.2014 05:59, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds device tree support to the s5p-sss.c crypto driver.
>> Implements a varient struct to address the changes in SSS hardware
>> on various SoCs from Samsung.
>>
>> Also, Documentation under devicetree/bindings added.
>>
>> Signed-off-by: Naveen Krishna Ch
>> CC: Herbert Xu
>> CC: David S. Miller
>> CC: Vladimir Zapolskiy
>> TO:
>> CC:
>> ---
>> Changes since v1:
>> 1. Added description of the SSS module in Documentation
>> 2. Corrected the interrupts description
>> 3. Added varient struct instead of the version variable
>>
>> .../devicetree/bindings/crypto/samsung-sss.txt | 20 +
>> drivers/crypto/s5p-sss.c | 81
>> ++--
>> 2 files changed, 95 insertions(+), 6 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> new file mode 100644
>> index 000..0e45b0d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> @@ -0,0 +1,20 @@
>> +Samsung SoC SSS (Security SubSystem) module
>> +
>> +The SSS module in S5PV210 SoC supports the following:
>> +-- Feeder (FeedCtrl)
>> +-- Advanced Encryption Standard (AES)
>> +-- Data Encryption Standard (DES)/3DES
>> +-- Public Key Accelerator (PKA)
>> +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
>> +-- PRNG: Pseudo Random Number Generator
>> +
>> +Required properties:
>> +
>> +- compatible : Should contain entries for this and backward compatible
>> + SSS versions:
>> + - "samsung,s5p-secss" for S5PV210 SoC.
>
>
> As I wrote in my previous reply, please use specific compatible string
> containing name of SoC on which the block described by it appeared first.
> Let me say it again, for security block that showed up first on S5PV210 the
> string will be "samsung,s5pv210-secss".
1. .name = "s5p-secss", is the name used in the present driver.
So, i dint modify that.
2. I'm not sure which one is the first soc to have the new varient.
May be Exynos4210. Will modify in the next version.
>
>
>> +- reg : Offset and length of the register set for the module
>> +- interrupts : the interrupt-specifier for the SSS module.
>> + Two interrupts "feed control and hash" in case of S5PV210
>> +- clocks : the required gating clock for the SSS module.
>> +- clock-names : the gating clock name to be requested in the SSS driver.
>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>> index 93cddeb..78e0c37 100644
>> --- a/drivers/crypto/s5p-sss.c
>> +++ b/drivers/crypto/s5p-sss.c
>> @@ -22,6 +22,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -145,6 +146,20 @@
>> #define AES_KEY_LEN 16
>> #define CRYPTO_QUEUE_LEN1
>>
>> +/**
>> + * struct samsung_aes_varient - platform specific SSS driver data
>
>
> typo: s/varient/variant/g
>
> Anyway, I think this should be moved to the patch adding support for
> Exynos5, as before it there is no use for this struct and it's not directly
> related to DT support.
>
>
>> + * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
>> + * @aes_offset: AES register offset from SSS module's base.
>> + *
>> + * Specifies platform specific configuration of SSS module.
>> + * Note: A structure for driver specific platform data is used for future
>> + * expansion of its usage.
>> + */
>> +struct samsung_aes_varient {
>> + boolhas_hash_irq;
>> + unsigned intaes_offset;
>> +};
>> +
>> struct s5p_aes_reqctx {
>> unsigned long mode;
>> };
>> @@ -173,10 +188,56 @@ struct s5p_aes_dev {
>> struct crypto_queue queue;
>> boolbusy;
>> spinlock_t lock;
>> +
>> + struct samsung_aes_varient *varient;
>> };
>>
>> static struct s5p_aes_dev *s5p_dev;
>>
>> +static struct samsung_aes_varient s5p_aes_data = {
>
>
> Remember to mark constant data as const.
>
>
>> + .has_hash_irq = true,
>> + .aes_offset = 0x4000,
>> +};
>> +
>> +static const struct platform_device_id s5p_sss_ids[] = {
>> + {
>> + .name = "s5p-secss",
>> + .driver_data= (kernel_ulong_t)&s5p_aes_data,
>> + },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
>> +
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id s5p_sss_dt_match[] = {
>> + {
>> + .compatible = "samsung,s5p-
[PATCH 1/1] drivers: net: silence compiler warning in smc91x.c
If used 64 bit compiler GCC warns that:
drivers/net/ethernet/smsc/smc91x.c:1897:7:
warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
This patch fixes this by changing typecase from "unsigned int" to "unsigned
long"
CC: "David S. Miller"
CC: Jingoo Han
CC: net...@vger.kernel.org
Signed-off-by: Pankaj Dubey
---
drivers/net/ethernet/smsc/smc91x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c
b/drivers/net/ethernet/smsc/smc91x.c
index 0c9b5d9..42e79b4 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -1894,7 +1894,7 @@ static int smc_probe(struct net_device *dev, void __iomem
*ioaddr,
SMC_SELECT_BANK(lp, 1);
val = SMC_GET_BASE(lp);
val = ((val & 0x1F00) >> 3) << SMC_IO_SHIFT;
- if (((unsigned int)ioaddr & (0x3e0 << SMC_IO_SHIFT)) != val) {
+ if (((unsigned long)ioaddr & (0x3e0 << SMC_IO_SHIFT)) != val) {
netdev_warn(dev, "%s: IOADDR %p doesn't match configuration
(%x).\n",
CARDNAME, ioaddr, val);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] drivers: i2c: silence a compile warning in i2c-s3c2410.c
If used 64 bit compiler GCC warns that:
drivers/i2c/busses/i2c-s3c2410.c: In function ‘s3c24xx_get_device_quirks’:
drivers/i2c/busses/i2c-s3c2410.c:168:10: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
This patch fixes this by converting "unsigned int" to "unsigned long".
CC: Kukjin Kim
CC: Wolfram Sang
CC: linux-...@vger.kernel.org
Signed-off-by: Pankaj Dubey
---
drivers/i2c/busses/i2c-s3c2410.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bf8fb94..447dd98 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -101,7 +101,7 @@ enum s3c24xx_i2c_state {
struct s3c24xx_i2c {
wait_queue_head_t wait;
- unsigned intquirks;
+ unsigned longquirks;
unsigned intsuspended:1;
struct i2c_msg *msg;
@@ -160,12 +160,13 @@ MODULE_DEVICE_TABLE(of, s3c24xx_i2c_match);
* Get controller type either from device tree or platform device variant.
*/
-static inline unsigned int s3c24xx_get_device_quirks(struct platform_device
*pdev)
+static inline unsigned long
+ s3c24xx_get_device_quirks(struct platform_device *pdev)
{
if (pdev->dev.of_node) {
const struct of_device_id *match;
match = of_match_node(s3c24xx_i2c_match, pdev->dev.of_node);
- return (unsigned int)match->data;
+ return (unsigned long)match->data;
}
return platform_get_device_id(pdev)->driver_data;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] irqchip: exynos-combiner: call handle_bad_irq directly
On 01/10/2014 11:32 AM, Pankaj Dubey wrote: This patch is inspired from following commit aec0095653: (irqchip: gic: Call handle_bad_irq() directly) Also this will help in removing unwanted inclusion of header file "asm/mach/irq.h" Signed-off-by: Pankaj Dubey This is single patch only. By mistake sent as Patch[1/3]. --- drivers/irqchip/exynos-combiner.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c index 40e6440..f8636a6 100644 --- a/drivers/irqchip/exynos-combiner.c +++ b/drivers/irqchip/exynos-combiner.c @@ -17,7 +17,6 @@ #include #include #include -#include #include "irqchip.h" @@ -81,7 +80,7 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) cascade_irq = irq_find_mapping(combiner_irq_domain, combiner_irq); if (unlikely(!cascade_irq)) - do_bad_IRQ(irq, desc); + handle_bad_irq(irq, desc); else generic_handle_irq(cascade_irq); -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] irqchip: exynos-combiner: call handle_bad_irq directly
This patch is inspired from following commit aec0095653: (irqchip: gic: Call handle_bad_irq() directly) Also this will help in removing unwanted inclusion of header file "asm/mach/irq.h" Signed-off-by: Pankaj Dubey --- drivers/irqchip/exynos-combiner.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/irqchip/exynos-combiner.c b/drivers/irqchip/exynos-combiner.c index 40e6440..f8636a6 100644 --- a/drivers/irqchip/exynos-combiner.c +++ b/drivers/irqchip/exynos-combiner.c @@ -17,7 +17,6 @@ #include #include #include -#include #include "irqchip.h" @@ -81,7 +80,7 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) cascade_irq = irq_find_mapping(combiner_irq_domain, combiner_irq); if (unlikely(!cascade_irq)) - do_bad_IRQ(irq, desc); + handle_bad_irq(irq, desc); else generic_handle_irq(cascade_irq); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clocksource: exynos_mct: remove unwanted header file inclusion
remove unwanted header file inclusion "asm/mach/time.h" from exynos_mct.c Signed-off-by: Pankaj Dubey --- drivers/clocksource/exynos_mct.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c index 48f76bc..ed49b25 100644 --- a/drivers/clocksource/exynos_mct.c +++ b/drivers/clocksource/exynos_mct.c @@ -25,8 +25,6 @@ #include #include -#include - #define EXYNOS4_MCTREG(x) (x) #define EXYNOS4_MCT_G_CNT_LEXYNOS4_MCTREG(0x100) #define EXYNOS4_MCT_G_CNT_UEXYNOS4_MCTREG(0x104) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung Clock changes for v3.14
On Wednesday 08 of January 2014 16:49:56 Mike Turquette wrote: > Quoting Mike Turquette (2014-01-08 14:59:43) > > Quoting Tomasz Figa (2014-01-08 14:43:24) > > > On Wednesday 08 of January 2014 14:07:49 Mike Turquette wrote: > > > > Quoting Tomasz Figa (2014-01-08 11:13:38) > > > > > Hi Mike, > > > > > > > > > > Please consider pulling following Samsung Clock changes for v3.14. > > > > > > > > > > The following changes since commit > > > > > 2bb00c68e094271b79deac993893461cc051b721: > > > > > > > > Hi Tomasz, > > > > > > > > Commit 2bb00c68 is the tip of the Samsung clk fixes that I'm about to > > > > send out. Can you rebase this request onto the tip of clk-next? > > > > > > I guess I can do it, but wouldn't this introduce merge conflicts, since > > > some of the fixes are changing the same parts of the code? > > > > Yes it will cause conflicts, but that is sometimes OK. > > > > > > > > I based my samsung-next branch on top of your clk-next with my fixes > > > branch merged, since that's what will end up in Linus' tree anyway. Was it > > > not the right thing to do? > > > > Well maybe I am missing something, but I think it is not the best thing. > > The problem is that those patches will sort of be merged twice. Again > > maybe I am missing something. The same commit IDs will be used so > > perhaps it is OK... > > > > Part of this trouble is caused by the simple way that I fork clk-next > > from v3.xx-rc1. Since I never rebase that branch to a more recent -rc > > then there is a delta between the fixes that go in the queue of patches > > for the next merge window. > > > > I guess one way that other subsystems handle this is by having something > > like clk-next-late which is a new branch based on a later -rc. > > > > How awful is the merge conflict resolution? > > Thanks for working this out on IRC. I've taken this pull request into > clk-next for 3.14. Great, thanks. One more thing. Could you update your public tree to let patches get some wider testing in linux-next before the merge window? Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
The Exynos4210 specific cpufreq driver performs read/write operations
of clock controller registers bypassing the Exynos common clock
framework driver. This could lead to potential issues if CCF and
cpufreq driver modify the clock registers independently of each other.
In addition to this, the generic cpufreq-cpu0 driver is sufficient
for Exynos4210 based platforms since this SoC uses a single clock
and voltage line for both the ARM cores. So remove the support for
Exynos4210 specific cpufreq driver and use cpufreq-cpu0 driver
for Exynos4210 platforms
Signed-off-by: Thomas Abraham
---
drivers/cpufreq/Kconfig.arm | 11 ---
drivers/cpufreq/Makefile |1 -
drivers/cpufreq/exynos-cpufreq.c |4 +-
drivers/cpufreq/exynos-cpufreq.h |8 --
drivers/cpufreq/exynos4210-cpufreq.c | 157 --
5 files changed, 1 insertions(+), 180 deletions(-)
delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0468ad1..0a2a589 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -19,17 +19,6 @@ config ARM_DT_BL_CPUFREQ
config ARM_EXYNOS_CPUFREQ
bool
-config ARM_EXYNOS4210_CPUFREQ
- bool "SAMSUNG EXYNOS4210"
- depends on CPU_EXYNOS4210
- default y
- select ARM_EXYNOS_CPUFREQ
- help
- This adds the CPUFreq driver for Samsung EXYNOS4210
- SoC (S5PV310 or S5PC210).
-
- If in doubt, say N.
-
config ARM_EXYNOS4X12_CPUFREQ
bool "SAMSUNG EXYNOS4x12"
depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412)
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 7494565..ce2abf9 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) +=
arm_big_little_dt.o
obj-$(CONFIG_ARCH_DAVINCI_DA850) += davinci-cpufreq.o
obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
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
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 4ee3804..eacc7eb 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -237,9 +237,7 @@ static int exynos_cpufreq_probe(struct platform_device
*pdev)
if (!exynos_info)
return -ENOMEM;
- if (soc_is_exynos4210())
- ret = exynos4210_cpufreq_init(exynos_info);
- else if (soc_is_exynos4212() || soc_is_exynos4412())
+ if (soc_is_exynos4212() || soc_is_exynos4412())
ret = exynos4x12_cpufreq_init(exynos_info);
else if (soc_is_exynos5250())
ret = exynos5250_cpufreq_init(exynos_info);
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 3ddade8..1e0afbe 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -43,14 +43,6 @@ struct exynos_dvfs_info {
bool (*need_apll_change)(unsigned int, unsigned int);
};
-#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
-extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
-#else
-static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
-{
- return -EOPNOTSUPP;
-}
-#endif
#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
#else
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
deleted file mode 100644
index 40d84c4..000
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ /dev/null
@@ -1,157 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4210 - 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 "exynos-cpufreq.h"
-
-static struct clk *cpu_clk;
-static struct clk *moutcore;
-static struct clk *mout_mpll;
-static struct clk *mout_apll;
-
-static unsigned int exynos4210_volt_table[] = {
- 125, 115, 105, 975000, 95,
-};
-
-static struct cpufreq_frequency_table exynos4210_freq_table[] = {
- {L0, 1200 * 1000},
- {L1, 1000 * 1000},
- {L2, 800 * 1000},
- {L3, 500 * 1000},
- {L4, 200 * 1000},
- {0, CPUFREQ_TABLE_END},
-};
-
-static struct apll_freq apll_freq_4210[] = {
- /*
-* values:
-* freq
-* clock divider for CORE, COREM0, COREM1, PERIPH, ATB, PCLK_DBG, APLL,
RESERVED
-
[PATCH 5/6] arm: exynos4-dt: statically add platform device for cpufreq-cpu0 platform driver
In order to use the cpufreq-cpu0 driver on Exynos4 based platforms,
statically add the platform device for cpufreq-cpu0 platform driver.
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/mach-exynos4-dt.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index d3e54b7..8b8ad41 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -19,11 +19,17 @@
#include "common.h"
+static struct platform_device cpufreq_device = {
+ .name = "cpufreq-cpu0",
+ .id = -1,
+};
+
static void __init exynos4_dt_machine_init(void)
{
exynos_cpuidle_init();
exynos_cpufreq_init();
+ platform_device_register(&cpufreq_device);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.6.6.rc2
--
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 6/6] arm: dts: add cpu nodes for Exynos4210 SoC
Add CPU nodes for Exynos4210 SoC and also properties required by the
cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham
---
arch/arm/boot/dts/exynos4210-origen.dts |6 ++
arch/arm/boot/dts/exynos4210-trats.dts |6 ++
arch/arm/boot/dts/exynos4210-universal_c210.dts |6 ++
arch/arm/boot/dts/exynos4210.dtsi | 22 ++
4 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 2aa13cb..afecd8f 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -32,6 +32,12 @@
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&buck1_reg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63cc571..25487d7 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,6 +30,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&varm_breg>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d2e3f5f..74d5a70 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,12 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1";
};
+ cpus {
+ cpu: cpu@0 {
+ cpu0-supply = <&vdd_arm_reg>;
+ };
+ };
+
mct@1005 {
compatible = "none";
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 48ecd7a..3db2da8 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -36,6 +36,28 @@
reg = <0x10023CA0 0x20>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ clocks = <&clock 12>;
+ clock-names = "cpu";
+
+ operating-points = <
+ 20 95
+ 40 975000
+ 50 975000
+ 80 1075000
+ 100 115
+ 120 125
+ >;
+ safe-opp-index = <3>;
+ };
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = <0x8000>;
};
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
On some platforms such as the Samsung Exynos, changing the frequency
of the CPU clock requires changing the frequency of the PLL that is
supplying the CPU clock. To change the frequency of the PLL, the CPU
clock is temporarily reparented to another parent clock.
The clock frequency of this temporary parent clock could be much higher
than the clock frequency of the PLL at the time of reparenting. Due
to the temporary increase in the CPU clock speed, the CPU (and any other
components in the CPU clock domain such as dividers, mux, etc.) have to
to be operated at a higher voltage level, called the safe voltage level.
This patch adds optional support to temporarily switch to a safe voltage
level during CPU frequency transitions.
Cc: Shawn Guo
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |5 ++
drivers/cpufreq/cpufreq-cpu0.c | 49 +++-
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f055515..020d859 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -19,6 +19,10 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
+- safe-opp-index: Certain platforms require that during a opp transition,
+ a system should not go below a particular opp level. For such systems,
+ this property specifies the minimum opp to be maintained during the
+ opp transitions.
Examples:
@@ -36,6 +40,7 @@ cpus {
396000 95
198000 85
>;
+ safe-opp-index = <1>;
clock-latency = <61036>; /* two CLK32 periods */
#cooling-cells = <2>;
cooling-min-level = <0>;
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 0c12ffc..dda4b7b 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -27,6 +27,8 @@
static unsigned int transition_latency;
static unsigned int voltage_tolerance; /* in percentage */
+static unsigned long safe_frequency;
+static unsigned long safe_voltage;
static struct device *cpu_dev;
static struct clk *cpu_clk;
@@ -69,12 +71,26 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
unsigned int index)
new_freq / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
- if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
+ if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
+ new_freq >= safe_frequency) {
ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
if (ret) {
pr_err("failed to scale voltage up: %d\n", ret);
return ret;
}
+ } else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
+ /*
+* the scaled up voltage level for the new_freq is lower
+* than the safe voltage level. so set safe_voltage
+* as the intermediate voltage level and revert it
+* back after the frequency has been changed.
+*/
+ ret = regulator_set_voltage(cpu_reg, safe_voltage,
+ safe_voltage);
+ if (ret) {
+ pr_err("failed to set safe voltage: %d\n", ret);
+ return ret;
+ }
}
ret = clk_set_rate(cpu_clk, freq_exact);
@@ -94,6 +110,19 @@ static int cpu0_set_target(struct cpufreq_policy *policy,
unsigned int index)
}
}
+ /*
+* if safe voltage was applied during voltage scale up, then set
+* the correct target voltage now.
+*/
+ if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
+ new_freq < safe_frequency) {
+ ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
+ if (ret) {
+ pr_err("failed to scale voltage up: %d\n", ret);
+ return ret;
+ }
+ }
+
return ret;
}
@@ -116,7 +145,9 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
+ struct dev_pm_opp *opp;
struct device_node *np;
+ unsigned int safe_opp_index;
int ret;
cpu_dev = get_cpu_device(0);
@@ -165,13 +196,27 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
goto out_put_node;
}
+ if (!of_property_read_u32(np, "safe-opp-index", &safe_opp_index)) {
+ rcu_read_lock();
+ opp = dev_pm_opp_find_freq_
[PATCH 2/6] clk: samsung: add infrastructure to register CPU clocks
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds infrastructure to register the CPU clock providers for Samsung
platforms.
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk.c | 71 +
drivers/clk/samsung/clk.h | 37 +++-
2 files changed, 107 insertions(+), 1 deletions(-)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index f503f32..9ac9056 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -316,3 +316,74 @@ unsigned long _get_rate(const char *clk_name)
return clk_get_rate(clk);
}
+
+/*
+ * On most platform, the core clock rate is equal to the clock rate of
+ * parent pll. This is a simple helper function to support recalc_rate
+ * callback for such platforms.
+ */
+unsigned long samsung_core_clock_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ /*
+* Assuming that the output of the parent pll is the output clock
+* frequency of the core clock.
+*/
+ return parent_rate;
+}
+
+/* This is a helper function to perform clock rounding for core clocks. */
+long samsung_core_clk_round_rate(struct clk_hw *hw,
+ unsigned long drate, unsigned long *prate)
+{
+ struct samsung_core_clock *core_clk;
+ const struct samsung_core_clock_freq_table *freq_tbl;
+ int i;
+
+ core_clk = container_of(hw, struct samsung_core_clock, hw);
+ freq_tbl = core_clk->freq_table;
+ drate /= 1000;
+
+ for (i = 0; i < freq_tbl->freq_count; i++) {
+ if (drate >= freq_tbl->freq[i])
+ return freq_tbl->freq[i] * 1000;
+ }
+ return freq_tbl->freq[i - 1] * 1000;
+}
+
+/* helper function to register a core clock */
+void __init samsung_coreclk_register(const char *name, const char **parents,
+ unsigned int num_parents, const char *pllclk,
+ const struct clk_ops *clk_ops, unsigned int lookup_id,
+ const struct samsung_core_clock_freq_table *freq_tbl)
+{
+ struct samsung_core_clock *coreclk;
+ struct clk_init_data init;
+ struct clk *clk;
+
+ coreclk = kzalloc(sizeof(*coreclk), GFP_KERNEL);
+ if (!coreclk) {
+ pr_err("%s: could not allocate memory for coreclk %s\n",
+ __func__, name);
+ return;
+ }
+
+ init.name = name;
+ init.flags = CLK_GET_RATE_NOCACHE;
+ init.parent_names = parents;
+ init.num_parents = num_parents;
+ init.ops = clk_ops;
+
+ coreclk->hw.init = &init;
+ coreclk->ctrl_base = reg_base;
+ coreclk->fout_pll = __clk_lookup(pllclk);
+ coreclk->freq_table = freq_tbl;
+
+ clk = clk_register(NULL, &coreclk->hw);
+ if (IS_ERR(clk)) {
+ pr_err("%s: could not register coreclk %s\n", __func__, name);
+ kfree(coreclk);
+ return;
+ }
+ samsung_clk_add_lookup(clk, lookup_id);
+}
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 31b4174..0e43023 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -312,6 +312,37 @@ struct samsung_pll_clock {
__PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
_lock, _con, _rtable, _alias)
+/**
+ * struct samsung_core_clock_freq_table: table of frequency supported by
+ * a core clock and associated data if any.
+ * @freq: points to a table of supported frequencies (in KHz)
+ * @freq_count: number of entries in the frequency table
+ * @data: core clock specific data, if any
+ */
+struct samsung_core_clock_freq_table {
+ const unsigned long *freq; /* in KHz */
+ unsigned long freq_count;
+ const void *data;
+};
+
+/**
+ * struct samsung_core_clock: information about clock supplied to a CPU core.
+ * @hw: handle between ccf and core clock.
+ * @ctrl_base: base address of the clock controller.
+ * @fout_pll: clock handle representing the clock output of the associated PLL.
+ */
+struct samsung_core_clock {
+ struct clk_hw hw;
+ void __iomem*ctrl_base;
+ struct clk *fout_pll;
+ const struct samsung_core_clock_freq_table *freq_table;
+};
+
+extern unsigned long samsung_core_clock_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate);
+extern long samsung_core_clk_round_rate(struct clk_hw *hw,
+ unsigned long drate, unsigned long *prate);
+
extern void __init samsung_clk_init(struct device_node *np, void __iomem *base,
[PATCH 3/6] clk: samsung: register cpu clock provider for exynos4210 SoC
Add a new clock provider for ARM clock domain. This clock provider
is composed of multiple components which include mux_core, div_core,
div_core2, div_corem0, div_corem1, div_periph, div_atb, div_pclk_dbg,
div_copy and div_hpm. This composition of mutiple components into
a single clock provider helps with faster completion of CPU clock
speed switching during DVFS operations.
Signed-off-by: Thomas Abraham
---
drivers/clk/samsung/clk-exynos4.c | 96 -
1 files changed, 95 insertions(+), 1 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index d967571..4bf2f93 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -108,8 +108,11 @@
#define APLL_CON0 0x14100
#define E4210_MPLL_CON00x14108
#define SRC_CPU0x14200
+#define STAT_CPU 0x14400
#define DIV_CPU0 0x14500
#define DIV_CPU1 0x14504
+#define DIV_STAT_CPU0 0x14600
+#define DIV_STAT_CPU1 0x14604
#define GATE_SCLK_CPU 0x14800
#define GATE_IP_CPU0x14900
#define E4X12_DIV_ISP0 0x18300
@@ -289,7 +292,7 @@ static unsigned long exynos4_clk_regs[] __initdata = {
};
/* list of all parent clock list */
-PNAME(mout_apll_p) = { "fin_pll", "fout_apll", };
+PNAME(mout_apll_p) = { "fin_pll", "fout_apll1", };
PNAME(mout_mpll_p) = { "fin_pll", "fout_mpll", };
PNAME(mout_epll_p) = { "fin_pll", "fout_epll", };
PNAME(mout_vpllsrc_p) = { "fin_pll", "sclk_hdmi24m", };
@@ -306,6 +309,7 @@ PNAME(mout_onenand_p) = {"aclk133", "aclk160", };
PNAME(mout_onenand1_p) = {"mout_onenand", "sclk_vpll", };
/* Exynos 4210-specific parent groups */
+PNAME(armclk_p) = { "fout_apll", };
PNAME(sclk_vpll_p4210) = { "mout_vpllsrc", "fout_vpll", };
PNAME(mout_core_p4210) = { "mout_apll", "sclk_mpll", };
PNAME(sclk_ampll_p4210)= { "sclk_mpll", "sclk_apll", };
@@ -1089,6 +1093,92 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+#define EXYNOS4210_DIV_CPU0(apll, pclk_dbg, atb, periph, corem1, corem0) \
+ ((apll << 24) | (pclk_dbg << 20) | (atb << 16) | \
+ (periph << 12) | (corem1 << 8) | (corem0 << 4))
+#define EXYNOS4210_DIV_CPU1(hpm, copy) \
+ ((hpm << 4) | (copy << 0))
+static const unsigned long exynos4210_armclk_data[][2] = {
+ { EXYNOS4210_DIV_CPU0(7, 1, 4, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 5), },
+ { EXYNOS4210_DIV_CPU0(7, 1, 4, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 4), },
+ { EXYNOS4210_DIV_CPU0(7, 1, 3, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 3), },
+ { EXYNOS4210_DIV_CPU0(7, 1, 3, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 3), },
+ { EXYNOS4210_DIV_CPU0(7, 1, 3, 3, 7, 3), EXYNOS4210_DIV_CPU1(0, 3), },
+ { EXYNOS4210_DIV_CPU0(0, 1, 3, 1, 3, 1), EXYNOS4210_DIV_CPU1(0, 3), },
+};
+
+static const unsigned long exynos4210_armclk_freqs[] = {
+ 120 , 100, 80, 50, 40, 20,
+};
+
+static const struct samsung_core_clock_freq_table exyno4210_armclk_table = {
+ .freq = exynos4210_armclk_freqs,
+ .freq_count = ARRAY_SIZE(exynos4210_armclk_freqs),
+ .data = (void *)exynos4210_armclk_data,
+};
+
+static int exynos4210_armclk_set_rate(struct clk_hw *hw, unsigned long drate,
+ unsigned long prate)
+{
+ struct samsung_core_clock *armclk;
+ const struct samsung_core_clock_freq_table *freq_tbl;
+ unsigned long *freq_data;
+ unsigned long mux_reg, idx;
+ void __iomem *base;
+
+ if (drate == prate)
+ return 0;
+
+ armclk = container_of(hw, struct samsung_core_clock, hw);
+ freq_tbl = armclk->freq_table;
+ freq_data = (unsigned long *)freq_tbl->data;
+ base = armclk->ctrl_base;
+
+ for (idx = 0; idx < freq_tbl->freq_count; idx++, freq_data += 2)
+ if ((freq_tbl->freq[idx] * 1000) == drate)
+ break;
+
+ if (!armclk->fout_pll)
+ armclk->fout_pll = __clk_lookup("fout_apll");
+
+ if (drate < prate) {
+ mux_reg = readl(base + SRC_CPU);
+ writel(mux_reg | (1 << 16), base + SRC_CPU);
+ while (((readl(base + STAT_CPU) >> 16) & 0x7) != 2)
+ ;
+
+ clk_set_rate(armclk->fout_pll, drate);
+ }
+
+ writel(freq_data[0], base + DIV_CPU0);
+ while (readl(base + DIV_STAT_CPU0) != 0)
+ ;
+ writel(freq_data[1], base + DIV_CPU1);
+ while (readl(base + DIV_STAT_CPU1) != 0)
+ ;
+
+ if (drate > prate) {
+ mux_reg = readl(base + SRC_CPU);
+ writel(mux_reg | (1 << 16), base + SRC_CPU);
+ while (((readl(base + STAT_CPU) >> 16) & 0x7) != 2)
+ ;
+
+
[PATCH 0/6] cpufreq: use cpufreq-cpu0 driver for exynos4210 based platforms
The patch series removes the use of Exynos4210 specific cpufreq driver and enables to use the cpufreq-cpu0 driver for Exynos4210 based platforms. This is being done for few reasons. (a) The Exynos4210 cpufreq driver reads/writes clock controller registers bypassing the Exynos4 CCF driver which is sort of problematic. (b) Removes the need for having clock controller register definitions in the cpufreq driver and also removes the need for statically io-remapping clock controller address space (helps in moving towards multiplatform kernel). In order to use cpufreq-cpu0 driver and provide fast cpu clock switching during dvfs operations, the following apporach has been used. (a) A new CPU clock provider type has been introduced in Samsung's CCF support. This clock provider type can be a compostion of multiple clock blocks such as mux, dividers and gates. Typically, in Exynos platforms, there are multiple clock blocks in between the output of the APLL and the CPU clock domain output. Representing these mutiple clock blocks within a opaque CPU clock provider type helps in reducing the time taken to perform a CPU clock frequency change operation, which is generally required during DVFS operations. This approach was suggested by Arnd Bergmann during LCE-2013. (b) A new optional safe operating point property has been introduced in the cpufreq-cpu0 driver binding. On some platforms such as the Samsung Exynos, a change in CPU frequency requires a change in the PLL output that drives the CPU clock. A change in PLL output requires the PLL output be turned off, which implies that the CPU (and other components in the CPU clock domain) be supplied with an alternate clock source during the time the PLL output is changed. The clock speed of this alternate clock source could be higher than the clock speed of the PLL at the time of switching over to the alternate clock source. This temporary increase in clock speed of the CPU clock domain implies that the blocks within the CPU clock domain should also be supplied with an appropriate voltage supply level as required to drive the CPU clock domain components at the speed of the alternative clock source. This temporary voltage level required during switching of CPU clock speed is called safe voltage level. And the cpufreq-cpu0 driver has been modified to setup the safe voltage levels during the changes in CPU clock speed. (c) The CPU clock supply as been restructured as [ Output of APLL -> Opaque CPU clock provider -> CPU clock output ] And with the changes in (a) and (b) above, the cpufreq-cpu0 driver can now be used and can remove the use of Exynos4210 specific cpufreq driver. This approach is currently tried on Exynos4210 only. The same approach can be adopted for other Exynos SoCs as well. This patch series is based on linux-next master branch. Thomas Abraham (6): cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions clk: samsung: add infrastructure to register CPU clocks clk: samsung: register cpu clock provider for exynos4210 SoC cpufreq: exynos: remove Exynos4210 specific cpufreq driver support arm: exynos4-dt: statically add platform device for cpufreq-cpu0 platform driver arm: dts: add cpu nodes for Exynos4210 SoC .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |5 + arch/arm/boot/dts/exynos4210-origen.dts|6 + arch/arm/boot/dts/exynos4210-trats.dts |6 + arch/arm/boot/dts/exynos4210-universal_c210.dts|6 + arch/arm/boot/dts/exynos4210.dtsi | 22 +++ arch/arm/mach-exynos/mach-exynos4-dt.c |6 + drivers/clk/samsung/clk-exynos4.c | 96 - drivers/clk/samsung/clk.c | 71 + drivers/clk/samsung/clk.h | 37 +- drivers/cpufreq/Kconfig.arm| 11 -- drivers/cpufreq/Makefile |1 - drivers/cpufreq/cpufreq-cpu0.c | 49 ++- drivers/cpufreq/exynos-cpufreq.c |4 +- drivers/cpufreq/exynos-cpufreq.h |8 - drivers/cpufreq/exynos4210-cpufreq.c | 157 15 files changed, 301 insertions(+), 184 deletions(-) delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c -- 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/6 v2] crypto:s5p-sss: Add device tree support
Hi Naveen,
On 09.01.2014 05:59, Naveen Krishna Chatradhi wrote:
This patch adds device tree support to the s5p-sss.c crypto driver.
Implements a varient struct to address the changes in SSS hardware
on various SoCs from Samsung.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v1:
1. Added description of the SSS module in Documentation
2. Corrected the interrupts description
3. Added varient struct instead of the version variable
.../devicetree/bindings/crypto/samsung-sss.txt | 20 +
drivers/crypto/s5p-sss.c | 81 ++--
2 files changed, 95 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..0e45b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - "samsung,s5p-secss" for S5PV210 SoC.
As I wrote in my previous reply, please use specific compatible string
containing name of SoC on which the block described by it appeared
first. Let me say it again, for security block that showed up first on
S5PV210 the string will be "samsung,s5pv210-secss".
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts "feed control and hash" in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..78e0c37 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -145,6 +146,20 @@
#define AES_KEY_LEN 16
#define CRYPTO_QUEUE_LEN1
+/**
+ * struct samsung_aes_varient - platform specific SSS driver data
typo: s/varient/variant/g
Anyway, I think this should be moved to the patch adding support for
Exynos5, as before it there is no use for this struct and it's not
directly related to DT support.
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct samsung_aes_varient {
+ boolhas_hash_irq;
+ unsigned intaes_offset;
+};
+
struct s5p_aes_reqctx {
unsigned long mode;
};
@@ -173,10 +188,56 @@ struct s5p_aes_dev {
struct crypto_queue queue;
boolbusy;
spinlock_t lock;
+
+ struct samsung_aes_varient *varient;
};
static struct s5p_aes_dev *s5p_dev;
+static struct samsung_aes_varient s5p_aes_data = {
Remember to mark constant data as const.
+ .has_hash_irq = true,
+ .aes_offset = 0x4000,
+};
+
+static const struct platform_device_id s5p_sss_ids[] = {
+ {
+ .name = "s5p-secss",
+ .driver_data= (kernel_ulong_t)&s5p_aes_data,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
+
+#ifdef CONFIG_OF
+static const struct of_device_id s5p_sss_dt_match[] = {
+ {
+ .compatible = "samsung,s5p-secss",
+ .data = (void *)&s5p_aes_data,
No need to cast pointers to (void *) explicitly.
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+#else
+static struct of_device_id s5p_sss_dt_match[] = {
+ { },
+};
Hmm, I don't think there is any need for this.
+#endif
+
+static inline struct samsung_aes_varient *find_s5p_sss_version
+ (struct platform_device *pdev)
+{
+ if (IS_ENABLED(CONFIG_OF)) {
+ if (pdev->dev.of_node) {
What about using a single if, as follows:
if (IS_ENABLED(CONFIG_IF) && pdev->dev.of_node)
+ const struct of_device_id *match;
+ match = of_match_node(s5p_sss_dt_match,
You can use of_match_ptr(s5p_sss_dt_match) instead of referring to the
table directly to eliminate the need for empty table.
+
Re: Arndale Timer Interrupt Question
added linux-samsung-soc to cc:, it is a better suited list for this question On Thursday, January 09, 2014 10:30:56 AM Mj Embd wrote: > I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can > you please help here. > > As per the exynos5 public manual > What is the difference between CPU_nCNTHPIRQ[0] and CNTHPIRQ. > > While the later has an interrupt ID 26, the former is part of a group > with combined interrupt id as 33 for core 0 and 54 for core 1. > > For a timer interrupt which goes to PL2, which id should be used 26 or > 33 for core 0 ? > > Please clear this confusion. > > Many 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 3/6 v2] crypto:s5p-sss: Add support for SSS module on Exynos
Hi Naveen, On 9 January 2014 10:29, Naveen Krishna Chatradhi wrote: > This patch adds new compatible and varient to support the SSS module > on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250) for which > 1. AES register are at an offset of 0x200 and > 2. hash interrupt is not available > > Signed-off-by: Naveen Krishna Ch > CC: Herbert Xu > CC: David S. Miller > CC: Vladimir Zapolskiy > TO: > CC: > --- > Changes since v1: > 1. Used varient struct > 2. Added description in Documentation > > .../devicetree/bindings/crypto/samsung-sss.txt | 20 + > drivers/crypto/s5p-sss.c | 43 > ++-- > 2 files changed, 51 insertions(+), 12 deletions(-) > > diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt > b/Documentation/devicetree/bindings/crypto/samsung-sss.txt > index 0e45b0d..4531da2 100644 > --- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt > +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt > @@ -8,13 +8,33 @@ The SSS module in S5PV210 SoC supports the following: > -- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG > -- PRNG: Pseudo Random Number Generator > > +The SSS module in Exynos4 (Exynos4210) and > +Exynos5 (Exynos5420 and Exynos5250) SoCs > +supports the following also: > +-- ARCFOUR (ARC4) > +-- True Random Number Generator (TRNG) > +-- Secure Key Manager > + > Required properties: > > - compatible : Should contain entries for this and backward compatible >SSS versions: >- "samsung,s5p-secss" for S5PV210 SoC. > + - "samsung,exynos-secss" for Exynos4210, Exynos5250 and Exynos5420 SoCs. Shouldn't the compatible string be more specific with the name of the first SoC that had this IP? -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6 v2] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
Hi Naveen, On 9 January 2014 10:29, Naveen Krishna Chatradhi wrote: > From: Naveen Krishna Ch > > This patch modifies Kconfig such that ARCH_EXYNOS SoCs > which includes (Exynos4210, Exynos5250 and Exynos5420) > can also select Samsung SSS(Security SubSystem) driver. What about Exynos4x12 and 5440 as they too come under ARCH_EXYNOS? -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver
Hi,
On Thursday, January 09, 2014 08:58:14 AM Shaik Ameer Basha wrote:
> This patch adds the DT binding documentation for the
> Exynos5420/5410 based SCALER device driver.
>
> Signed-off-by: Shaik Ameer Basha
> Reviewed-by: Sylwester Nawrocki
> ---
> .../devicetree/bindings/media/exynos5-scaler.txt | 22
>
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
>
> diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> new file mode 100644
> index 000..9328e7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> @@ -0,0 +1,22 @@
> +* Samsung Exynos5 SCALER device
> +
> +SCALER is used for scaling, blending, color fill and color space
> +conversion on EXYNOS[5420/5410] SoCs.
> +
> +Required properties:
> +- compatible: should be "samsung,exynos5420-scaler" or
> + "samsung,exynos5410-scaler"
> +- reg: should contain SCALER physical address location and length
> +- interrupts: should contain SCALER interrupt number
> +- clocks: should contain the SCALER clock specifier, from the
> + common clock bindings
> +- clock-names: should be "scaler"
> +
> +Example:
> + scaler_0: scaler@1280 {
> + compatible = "samsung,exynos5420-scaler";
> + reg = <0x1280 0x1000>;
> + interrupts = <0 220 0>;
> + clocks = <&clock 381>;
> + clock-names = "scaler";
> + };
Your patchset adds support for EXYNOS5 SCALER but doesn't add any real
users of it yet. Could you please explain why?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver
Hi,
On Thursday, January 09, 2014 08:58:12 AM Shaik Ameer Basha wrote:
> This patch adds the core functionality for the SCALER driver.
>
> Signed-off-by: Shaik Ameer Basha
> Reviewed-by: Sylwester Nawrocki
> ---
> drivers/media/platform/exynos-scaler/scaler.c | 1231
> +
> drivers/media/platform/exynos-scaler/scaler.h | 376
> 2 files changed, 1607 insertions(+)
> create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
> create mode 100644 drivers/media/platform/exynos-scaler/scaler.h
[...]
> +static int scaler_probe(struct platform_device *pdev)
> +{
> + struct scaler_dev *scaler;
> + struct resource *res;
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + if (!dev->of_node)
> + return -ENODEV;
> +
> + scaler = devm_kzalloc(dev, sizeof(*scaler), GFP_KERNEL);
> + if (!scaler)
> + return -ENOMEM;
> +
> + scaler->pdev = pdev;
> + scaler->variant = scaler_get_variant_data(pdev);
> +
> + init_waitqueue_head(&scaler->irq_queue);
> + spin_lock_init(&scaler->slock);
> + mutex_init(&scaler->lock);
> + scaler->clock = ERR_PTR(-EINVAL);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + scaler->regs = devm_request_and_ioremap(dev, res);
> + if (!scaler->regs)
> + return -ENODEV;
> +
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + if (!res) {
> + dev_err(dev, "failed to get IRQ resource\n");
> + return -ENXIO;
> + }
> +
> + ret = scaler_clk_get(scaler);
> + if (ret < 0)
> + return ret;
> +
> + ret = devm_request_irq(dev, res->start, scaler_irq_handler,
> + 0, pdev->name, scaler);
> + if (ret < 0) {
> + dev_err(dev, "failed to install irq (%d)\n", ret);
> + goto err_clk;
> + }
> +
> + platform_set_drvdata(pdev, scaler);
> + pm_runtime_enable(dev);
> +
> + /* Initialize the continious memory allocator */
> + scaler->alloc_ctx = vb2_dma_contig_init_ctx(dev);
> + if (IS_ERR(scaler->alloc_ctx)) {
> + ret = PTR_ERR(scaler->alloc_ctx);
> + goto err_clk;
> + }
> +
> + ret = v4l2_device_register(dev, &scaler->v4l2_dev);
> + if (ret < 0)
> + goto err_clk;
> +
> + ret = scaler_register_m2m_device(scaler);
> + if (ret < 0)
> + goto err_v4l2;
> +
> + dev_info(dev, "registered successfully\n");
> + return 0;
> +
> +err_v4l2:
> + v4l2_device_unregister(&scaler->v4l2_dev);
> +err_clk:
> + scaler_clk_put(scaler);
vb2_dma_contig_cleanup_ctx() and pm_runtime_disable() calls on
failure are missing
> + return ret;
> +}
> +
> +static int scaler_remove(struct platform_device *pdev)
> +{
> + struct scaler_dev *scaler = platform_get_drvdata(pdev);
> +
> + scaler_unregister_m2m_device(scaler);
> + v4l2_device_unregister(&scaler->v4l2_dev);
> +
> + vb2_dma_contig_cleanup_ctx(scaler->alloc_ctx);
> + pm_runtime_disable(&pdev->dev);
> + scaler_clk_put(scaler);
> +
> + scaler_dbg(scaler, "%s driver unloaded\n", pdev->name);
> + return 0;
> +}
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver
Hi, On Thursday, January 09, 2014 08:58:13 AM Shaik Ameer Basha wrote: > This patch adds the Makefile and memory to memory (m2m) interface > functionality for the SCALER driver. > > [arun...@samsung.com: fix compilation issues] > > Signed-off-by: Shaik Ameer Basha > Signed-off-by: Arun Kumar K > Reviewed-by: Sylwester Nawrocki > --- > drivers/media/platform/Kconfig|8 + > drivers/media/platform/Makefile |1 + > drivers/media/platform/exynos-scaler/Makefile |3 + > drivers/media/platform/exynos-scaler/scaler-m2m.c | 788 > + It would be cleaner to add Kconfig + Makefiles in the same patch that adds core functionality (patch #2) and then switch the order of patch #2 and patch #3. > 4 files changed, 800 insertions(+) > create mode 100644 drivers/media/platform/exynos-scaler/Makefile > create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index b2a4403..aec5b80 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -196,6 +196,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC > help > This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler. > > +config VIDEO_SAMSUNG_EXYNOS_SCALER > + tristate "Samsung Exynos SCALER driver" > + depends on OF && VIDEO_DEV && VIDEO_V4L2 && ARCH_EXYNOS5 Please check for EXYNOS5410 and EXYNOS5420 explicitly instead of checking just for ARCH_EXYNOS5. Also this config option doesn't need to depend on OF since the whole EXYNOS support is OF only now. > + select VIDEOBUF2_DMA_CONTIG > + select V4L2_MEM2MEM_DEV > + help > + This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER. > + > config VIDEO_SH_VEU > tristate "SuperH VEU mem2mem video processing driver" > depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
