Re: Issues with HW RNG / SSS on Exynos 5422
Hi
On 2015년 08월 16일 20:21, Heiner Kallweit wrote:
> Am 16.08.2015 um 13:18 schrieb Heiner Kallweit:
>> Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:
>>> I'm having issues making the hardware RNG work on a Samsung Exynos 5422
>>> (Odroid XU4) with kernel 4.2rc6.
>>> No random number generation is started if I write the appropriate value
>>> (0x18) to the hash control register.
>>>
>>> What I did so far:
>>> Splitted the sss DT node in exynos5420.dtsi into one for the s5p-sss driver
>>> and one for the exynos-rng driver.
>>> (s5p-sss doesn't seem to need the hash registers from offset 0x400)
>>>
>>> sss: sss@1083 {
>>> icompatible = "samsung,exynos4210-secss";
>>> reg = <0x1083 0x400>;
>>> interrupts = <0 112 0>;
>>> clocks = <&clock CLK_SSS>;
>>> clock-names = "secss";
>>> };
>>>
>>> rng: rng@10830400 {
>>> compatible = "samsung,exynosrng-secss";
>>> reg = <0x10830400 0x300>;
>>> clocks = <&clock CLK_SSS>;
>>> clock-names = "secss";
>>> };
>>>
>>> The DT binding is just for testing and after adding some DT glue logic
>>> (of_device_id table) to the exynos-rng driver
>>> it binds to the rng platform device.
>>> The clock also seems to be ok with a rate of 266 MHz.
>>> As is the driver hangs in a loop because the PRNG_DONE in the status
>>> register bit never gets set.
>>>
>>> I traced it back to the hash control register not accepting value 0x8 (or
>>> 0x18 incl. the start bit) for the PRNG.
>>> Writing a value and reading it back works for values from 0 to 5 only.
>>> As I have no SSS datasheet my only other reference is
>>> drivers/crypto/ace_sha.h in the uboot source code
>>> which also uses the HW RNG.
>>>
>>> Any hint would be appreciated.
>>>
>> After some more testing it seems like SSS in general has problems on Exynos
>> 5422.
>> Also the AES implementation in s5p-sss doesn't work. dmesg output:
>>
>> [7.116739] alg: skcipher: encryption failed on chunk test 1 for
>> ecb-aes-s5p: ret=22
>> [7.123673] s5p-sss driver registered
>>
> Sorry, there was a typo in the mail agent cc line.
>
I suspect Trustzone would prohibit to access SSS IP. I never tested it Exynos
hwrng under Trustzone enabled,
however some said it cannot be used manually after being protected by Secure OS.
And I don't know neither how to check whether Trustzone is enabled.
Can you access all other registers in SSS IP? If not, it might be related with
it.
Thanks.
Jonghwa
--
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] soc: samsung: pmu: split up SoC specific PMU data
On 2014년 12월 01일 01:16, Pankaj Dubey wrote: > This patch splits up exynos-pmu.c file, and moves PMU configuration data > and functions handing those data into SoC specific PMU files, keeping > driver structure and common functionality into exynos-pmu.c. > > At the same time it also separates compilation of these different SoC PMU > files > based on CONFIG_ARM64 and CONFIG_ARM. This way we can reduce overhead of ARM64 > SoC's PMU getting compiled when kernel is built for ARM and vice-versa. > > This patch also removes .owner field from exynos-pmu.c as it's redundant for > drivers calling platform_driver_register to register platform_driver. > > Signed-off-by: Pankaj Dubey > --- > This patch is prepared on top of kgene/for-next and following patch [1] from > Amit Daniel. > > [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39797.html > > This patch tries to address some of concerns raised for using exynos-pmu.c for > ARM and ARM64 based SoC at these threads [2], [3]. > > [2]: http://www.spinics.net/lists/linux-samsung-soc/msg39809.html > [3]: https://lkml.org/lkml/2014/11/24/322 > > Since Exynos SoC's has similar PMU IP, and already existing bindings can be > used, it makes sense to keep single driver for both ARM and ARM64 based SoCs. > All common functionalties are in exynos-pmu.c whereas SoC specific data and > handling are moved into SoC specific exynos-pmu files. > > All changes are compiled tested only. Any improvements/suggestions are most > welcome. > > drivers/soc/samsung/Makefile |9 +- > drivers/soc/samsung/exynos-pmu.c | 1293 > +- > drivers/soc/samsung/exynos-pmu.h | 63 ++ > drivers/soc/samsung/exynos3250-pmu.c | 176 + > drivers/soc/samsung/exynos4-pmu.c| 223 ++ > drivers/soc/samsung/exynos5250-pmu.c | 196 ++ > drivers/soc/samsung/exynos5420-pmu.c | 298 > drivers/soc/samsung/exynos7-pmu.c| 441 > 8 files changed, 1412 insertions(+), 1287 deletions(-) > create mode 100644 drivers/soc/samsung/exynos-pmu.h > create mode 100644 drivers/soc/samsung/exynos3250-pmu.c > create mode 100644 drivers/soc/samsung/exynos4-pmu.c > create mode 100644 drivers/soc/samsung/exynos5250-pmu.c > create mode 100644 drivers/soc/samsung/exynos5420-pmu.c > create mode 100644 drivers/soc/samsung/exynos7-pmu.c > ... > diff --git a/drivers/soc/samsung/exynos-pmu.h > b/drivers/soc/samsung/exynos-pmu.h > new file mode 100644 > index 000..4adc5a3 > --- /dev/null > +++ b/drivers/soc/samsung/exynos-pmu.h > @@ -0,0 +1,63 @@ > +/* > + * Copyright (c) 2014 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * Header for EXYNOS PMU Driver 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. > + */ > + > +#ifndef __EXYNOSPMU_H > +#define __EXYNOSPMU_H > + > +#include > + > +#define PMU_TABLE_END(-1U) > + > +static void __iomem *pmu_base_addr; > + AFAIK, static variable in header file can't be used globally. It would be placed in exynos-pmu.c or elsewhere and then only extern declaration is allowed here. If I'm wrong, please let me know. Thanks. Jonghwa -- 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: [RESEND PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.
On 2014년 09월 17일 17:53, Vikas Sajjan wrote:
> Hi,
>
> On Wed, Sep 17, 2014 at 8:52 AM, Jonghwa Lee wrote:
>> Add rtc alarm and tick irq to wakeup sources in exynos3250.
>>
>> Signed-off-by: Jonghwa Lee
>> Acked-by : Chanwoo choi
>> ---
>> arch/arm/mach-exynos/pm.c |9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
>> index fa7218a..d78dcf9 100644
>> --- a/arch/arm/mach-exynos/pm.c
>> +++ b/arch/arm/mach-exynos/pm.c
>> @@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {
>>
>> static u32 exynos_irqwake_intmask = 0x;
>>
>> +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
>> + { 105, BIT(1) }, /* RTC alarm */
>> + { 106, BIT(2) }, /* RTC tick */
>> + { /* sentinel */ },
>> +};
>> +
>> static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
>> { 76, BIT(1) }, /* RTC alarm */
>> { 77, BIT(2) }, /* RTC tick */
>> @@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[]
>> = {
>> static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
>> {
>> const struct exynos_wkup_irq *wkup_irq;
>> -
>> if (soc_is_exynos5250())
>> wkup_irq = exynos5250_wkup_irq;
>> + else if (soc_is_exynos3250())
>> + wkup_irq = exynos3250_wkup_irq;
>
>
> Don't add anymore soc_is_exynosxxx() checks, please rebase on [1],
> which refactors the pm.c to use DT based lookup.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg355266.html
>
Okay, I'll wait those patches are merged, then I'll rebase and repost it.
Thanks,
Jonghwa.
--
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 00/30] thermal: exynos: Add thermal driver for exynos5440
On 2013년 06월 11일 21:53, Amit Daniel Kachhap wrote: > Most of the changes in this version is as per suggestion from Jonghwa Lee. I > have retained one to one mapping of platform data with TMU instances as the > TMU's are different devices. In exynos5440 soc there is some register > sharing across multiple TMU's but in exynos5420 there is no register between > multiple TMU's, so the current implementation is useful to support both of the > above. > > This patch uses localized ARCH_HAS_TMU Kconfig option and is a temporary > solution > until a more generic macro ARCH_HAS_BANDGAP is introduced as per discussion in > the link https://patchwork.kernel.org/patch/2659001/. > > Changes in V5: > * trip type is passed as platform data. > * HW trip is allowed only for maximum level. > * Platform data structure is now abstracted inside 1 more structure to support > strong multiple sensor TMU data. > > Changes in V4: > Almost all the changes in this version is as per suggestion from Eduardo.The > major ones are listed below, > * Added kconfig symbol ARCH_HAS_TMU which needs to be enabled by platform. > With > this change existing symbol EXYNOS_TMU_DATA is not needed. > * Movement of freq_clip_table from exynos_tmu.h to exynos_thermal_common.h is > explained in the commit logs. > * Wrote all register description documentation. > * Split 5440 TMU support patch into controller change, configuration data and > feature addition patches. > * Remove all *LINUX_* in the header files. > * Still regulator enable is kept optional but a TODO: comment is added to fix > it later. > > Changes in V3: > * Added proper dependency of different exynos thermal Kconfig symbols. > Basically 3 > Kconfig can be enabled now and corresponds to tmu driver. exynos common part > and exynos configuration data. This issue was raised by Rui Zhang. > > Changes in V2: > * Separated SOC data from TMU driver. This is as per suggestion from Eduardo. > * Merged the new file created for exynos5440 TMU controller with the existing > TMU controller code. > * Removed the DT parsing code as now the SOC specific data are cleanly put > inside the data specific file. > * Even the register definations/bitfields are treated as data as there is > some variation across SOC's. > > This patchset adds TMU(Thermal management Unit) driver support for > exynos5440 platform. There are 3 instances of the TMU controllers so > necessary cleanup/re-structure is done to handle multiple thermal zone. > > Patch (exynos4: Add documentation for Exynos SoC thermal bindings) from > Lukasz Majewski is already posted to mainline. Adding it here for > completeness. > (http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg17817.html) > > Patch (thermal: exynos: Support thermal tripping ) from Jonghwan Choi is > added here with some changes. > (https://patchwork.kernel.org/patch/1668371/) > > Patch (thermal: exynos: Support for TMU regulator defined at device tree) > is a repost of my earlier > patch(https://patchwork-mail1.kernel.org/patch/2510771/) > and adds regulator support. > > Patch (ARM: dts: Add device tree node for exynos5440 TMU controller) and > patch (arm: exynos: enable ARCH_HAS_TMU) can be merged through exynos platform > maintainer as this can cause merge conflict. > > All these patches are based on thermal maintainers git tree, > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next. > > Amit Daniel Kachhap (29): > thermal: exynos: Moving exynos thermal files into samsung directory > thermal: exynos: Add ARCH_HAS_TMU config to know the supported soc's > thermal: exynos: Remove CPU_THERMAL dependency for using TMU driver > thermal: exynos: Bifurcate exynos thermal common and tmu controller > code > thermal: exynos: Rename exynos_thermal.c to exynos_tmu.c > thermal: exynos: Move exynos_thermal.h from include/* to driver/* > folder > thermal: exynos: Bifurcate exynos tmu driver and configuration data > thermal: exynos: Add missing definations and code cleanup > thermal: exynos: Add extra entries in the tmu platform data > thermal: exynos: Move register definitions from driver to data file > thermal: exynos: Support thermal tripping > thermal: exynos: Fix to clear only the generated interrupts > thermal: exynos: Add support for instance based register/unregister > thermal: exynos: Modify private_data to appropriate name driver_data > thermal: exynos: Return success even if no cooling data supplied > thermal: exynos: Make the zone handling use trip information > thermal: exynos: Remove non DT based support > thermal: exynos: Add support to handle many instances of TMU > thermal: exynos: Add TMU features to check instead of using SOC type > thermal: exynos: use device resource management infrastructure > thermal: exynos: Add support to access common register for > multistance > thermal: exynos: Add driver support for exynos5440 TMU sensor > thermal: exynos: Add th
Re: [PATCH V4 22/30] thermal: exynos: Add support for exynos5440 TMU sensor.
On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:
> This patch modifies TMU controller to add changes needed to work with
> exynos5440 platform. This sensor registers 3 instance of the tmu controller
> with the thermal zone and hence reports 3 temperature output. This controller
> supports upto five trip points. For critical threshold the driver uses the
> core driver thermal framework for shutdown.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
> ---
> .../devicetree/bindings/thermal/exynos-thermal.txt | 28 -
> drivers/thermal/samsung/exynos_tmu.c | 43 +--
> drivers/thermal/samsung/exynos_tmu.h |6 +++
> drivers/thermal/samsung/exynos_tmu_data.h |2 +
> 4 files changed, 72 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 535fd0e..970eeba 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -6,13 +6,16 @@
> "samsung,exynos4412-tmu"
> "samsung,exynos4210-tmu"
> "samsung,exynos5250-tmu"
> +"samsung,exynos5440-tmu"
> - interrupt-parent : The phandle for the interrupt controller
> -- reg : Address range of the thermal registers
> +- reg : Address range of the thermal registers. For exynos5440-tmu which has
> 3
> + instances of TMU, 2 set of register has to supplied. First set belongs
> + to each instance of TMU and second set belongs to common TMU registers.
> - interrupts : Should contain interrupt for thermal system
> - clocks : The main clock for TMU device
> - clock-names : Thermal system clock name
>
> -Example:
> +Example 1):
>
> tmu@100C {
> compatible = "samsung,exynos4412-tmu";
> @@ -23,3 +26,24 @@ Example:
> clock-names = "tmu_apbif";
> status = "disabled";
> };
> +
> +Example 2):
> +
> + tmuctrl_0: tmuctrl@160118 {
> + compatible = "samsung,exynos5440-tmu";
> + reg = <0x160118 0x230>, <0x160368 0x10>;
> + interrupts = <0 58 0>;
> + clocks = <&clock 21>;
> + clock-names = "tmu_apbif";
> + };
> +
> +Note: For multi-instance tmu each instance should have an alias correctly
> +numbered in "aliases" node.
> +
> +Example:
> +
> +aliases {
> + tmuctrl0 = &tmuctrl_0;
> + tmuctrl1 = &tmuctrl_1;
> + tmuctrl2 = &tmuctrl_2;
> +};
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 7f7b1cf..7ca9c4d 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -185,9 +185,11 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> reg->threshold_th0 + i * sizeof(reg->threshold_th0));
>
> writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
> - } else if (data->soc == SOC_ARCH_EXYNOS) {
> + } else if (data->soc == SOC_ARCH_EXYNOS ||
> + data->soc == SOC_ARCH_EXYNOS5440) {
> /* Write temperature code for rising and falling threshold */
> - for (i = 0; i < trigger_levs; i++) {
> + for (i = 0;
> + i < trigger_levs && i < EXYNOS_MAX_TRIGGER_PER_REG; i++) {
> threshold_code = temp_to_code(data,
> pdata->trigger_levels[i]);
> if (threshold_code < 0) {
> @@ -218,7 +220,30 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> writel((reg->inten_rise_mask << reg->inten_rise_shift) |
> (reg->inten_fall_mask << reg->inten_fall_shift),
> data->base + reg->tmu_intclear);
> +
> + /* if 5th threshold limit is also present, use TH2 register */
> + i = EXYNOS_MAX_TRIGGER_PER_REG;
> + if (pdata->trigger_levels[i]) {
> + threshold_code = temp_to_code(data,
> + pdata->trigger_levels[i]);
> + if (threshold_code < 0) {
> + ret = threshold_code;
> + goto out;
> + }
> + rising_threshold =
> + threshold_code << reg->threshold_th3_l0_shift;
> + writel(rising_threshold,
> + data->base + reg->threshold_th2);
> + if (pdata->trigger_type[i] == HW_TRIP) {
> + con = readl(data->base + reg->tmu_ctrl);
> + con |= (1 << reg->therm_trip_en_shift);
> + writel(con, data->base + reg->tmu_ctrl);
> + }
> + }
>
Re: [PATCH V4 16/30] thermal: exynos: Make the zone handling dependent on trip count
On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:
> This code simplifies the zone handling to use the trip count passed
> by the TMU driver. This also helps in adding more zone support.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/exynos_thermal_common.c | 55
> ---
> drivers/thermal/samsung/exynos_thermal_common.h |2 -
> 2 files changed, 29 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
> b/drivers/thermal/samsung/exynos_thermal_common.c
> index 86d39aa..2369417 100644
> --- a/drivers/thermal/samsung/exynos_thermal_common.c
> +++ b/drivers/thermal/samsung/exynos_thermal_common.c
> @@ -78,17 +78,16 @@ static int exynos_set_mode(struct thermal_zone_device
> *thermal,
> static int exynos_get_trip_type(struct thermal_zone_device *thermal, int
> trip,
>enum thermal_trip_type *type)
> {
> - switch (GET_ZONE(trip)) {
> - case MONITOR_ZONE:
> - case WARN_ZONE:
> - *type = THERMAL_TRIP_ACTIVE;
> - break;
> - case PANIC_ZONE:
> - *type = THERMAL_TRIP_CRITICAL;
> - break;
> - default:
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
> + int max_trip = th_zone->sensor_conf->trip_data.trip_count;
> +
> + if (trip < 0 || trip >= max_trip)
> return -EINVAL;
> - }
> + else if (trip == (max_trip - 1))
> + *type = THERMAL_TRIP_CRITICAL;
> + else
> + *type = THERMAL_TRIP_ACTIVE;
> +
In current exynos_thermal driver, it is hard to set various trip type for each
trip, especially passive type. (not impossible, but complicated)
What do you think we just keep trip information with trip temperature in private
data? I mean if we just make trip level information to driver's private data
(like exynos_thermal_zone), it might be helpful to control trip type and trip
temperature. Like this,
struct exynos_thermal_trip_info {
int trip_temp;
enum thermal_trip_type type;
};
struct exynos_thermal_device {
.
struct exynos_thermal_trip_info *trips;
int num_trips;
};
Thanks,
Jonghwa
> return 0;
> }
>
> @@ -97,8 +96,9 @@ static int exynos_get_trip_temp(struct thermal_zone_device
> *thermal, int trip,
> unsigned long *temp)
> {
> struct exynos_thermal_zone *th_zone = thermal->devdata;
> + int max_trip = th_zone->sensor_conf->trip_data.trip_count;
>
> - if (trip < GET_TRIP(MONITOR_ZONE) || trip > GET_TRIP(PANIC_ZONE))
> + if (trip < 0 || trip >= max_trip)
> return -EINVAL;
>
> *temp = th_zone->sensor_conf->trip_data.trip_val[trip];
> @@ -112,10 +112,10 @@ static int exynos_get_trip_temp(struct
> thermal_zone_device *thermal, int trip,
> static int exynos_get_crit_temp(struct thermal_zone_device *thermal,
> unsigned long *temp)
> {
> - int ret;
> - /* Panic zone */
> - ret = exynos_get_trip_temp(thermal, GET_TRIP(PANIC_ZONE), temp);
> - return ret;
> + struct exynos_thermal_zone *th_zone = thermal->devdata;
> + int max_trip = th_zone->sensor_conf->trip_data.trip_count;
> + /* Get the temp of highest trip*/
> + return exynos_get_trip_temp(thermal, max_trip - 1, temp);
> }
>
> /* Bind callback functions for thermal zone */
> @@ -340,19 +340,22 @@ int exynos_register_thermal(struct thermal_sensor_conf
> *sensor_conf)
> return -ENOMEM;
>
> th_zone->sensor_conf = sensor_conf;
> - cpumask_set_cpu(0, &mask_val);
> - th_zone->cool_dev[0] = cpufreq_cooling_register(&mask_val);
> - if (IS_ERR(th_zone->cool_dev[0])) {
> - pr_err("Failed to register cpufreq cooling device\n");
> - ret = -EINVAL;
> - goto err_unregister;
> + if (sensor_conf->cooling_data.freq_clip_count > 0) {
> + cpumask_set_cpu(0, &mask_val);
> + th_zone->cool_dev[0] = cpufreq_cooling_register(&mask_val);
> + if (IS_ERR(th_zone->cool_dev[0])) {
> + pr_err("Failed to register cpufreq cooling device\n");
> + ret = -EINVAL;
> + goto err_unregister;
> + }
> + th_zone->cool_dev_size++;
> }
> - th_zone->cool_dev_size++;
>
> - th_zone->therm_dev = thermal_zone_device_register(sensor_conf->name,
> - EXYNOS_ZONE_COUNT, 0, th_zone, &exynos_dev_ops, NULL, 0,
> - sensor_conf->trip_data.trigger_falling ?
> - 0 : IDLE_INTERVAL);
> + th_zone->therm_dev = thermal_zone_device_register(
> + sensor_conf->name, sensor_conf->trip_data.trip_count,
> + 0, th_zone, &exynos_dev_ops, NULL, 0,
> + sensor_conf->trip_data.trigger_falling ? 0 :
> + IDLE_INTERVAL);
>
>
Re: [PATCH V4 10/30] thermal: exynos: Support thermal tripping
Hi, Amit
On 2013년 05월 14일 18:58, Amit Daniel Kachhap wrote:
> TMU urgently sends active-high signal (thermal trip) to PMU, and thermal
> tripping by hardware logic. Thermal tripping means that PMU cuts off the
> whole power of SoC by controlling external voltage regulator.
>
> Acked-by: Kukjin Kim
> Signed-off-by: Jonghwan Choi
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/exynos_tmu.c |8 +++-
> drivers/thermal/samsung/exynos_tmu_data.c |2 ++
> 2 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 5f8f189..479d61e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -84,6 +84,7 @@
> #define EXYNOS_TMU_CLEAR_FALL_INT(0x111 << 12)
> #define EXYNOS_TMU_TRIP_MODE_SHIFT 13
> #define EXYNOS_TMU_TRIP_MODE_MASK0x7
> +#define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
>
> #define EXYNOS_TMU_INTEN_RISE0_SHIFT 0
> #define EXYNOS_TMU_INTEN_RISE1_SHIFT 4
> @@ -186,7 +187,7 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> {
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> struct exynos_tmu_platform_data *pdata = data->pdata;
> - unsigned int status, trim_info;
> + unsigned int status, trim_info, con;
> unsigned int rising_threshold = 0, falling_threshold = 0;
> int ret = 0, threshold_code, i, trigger_levs = 0;
>
> @@ -251,6 +252,11 @@ static int exynos_tmu_initialize(struct platform_device
> *pdev)
> falling_threshold |=
> threshold_code << 8 * i;
> }
> + if (pdata->trigger_type[i] != HW_TRIP)
> + continue;
As you know, HW trip can be used when only the most last level of threshold
temperature is set. (exynos4412 : 4th, exynos 5440 : 5th threshold level). So it
wouldn't work properly, even if we enable HW trip according to pre-defined
trigger type not to HW trip threshold temperature. To enable HW trip, we just
need to check whether if HW trip threshold temperature level is defined.
if (trigger_level[HW_TRIP_LEVEL])
enable HW trip
Thanks,
Jonghwa
> + con = readl(data->base + EXYNOS_TMU_REG_CONTROL);
> + con |= (1 << EXYNOS_TMU_THERM_TRIP_EN_SHIFT);
> + writel(con, data->base + EXYNOS_TMU_REG_CONTROL);
> }
>
> writel(rising_threshold,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index ee6a3c9..6b937f5 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -64,6 +64,7 @@ struct exynos_tmu_platform_data const
> exynos5250_default_tmu_data = {
> .trigger_levels[0] = 85,
> .trigger_levels[1] = 103,
> .trigger_levels[2] = 110,
> + .trigger_levels[3] = 120,
> .trigger_enable[0] = 1,
> .trigger_enable[1] = 1,
> .trigger_enable[2] = 1,
> @@ -71,6 +72,7 @@ struct exynos_tmu_platform_data const
> exynos5250_default_tmu_data = {
> .trigger_type[0] = 0,
> .trigger_type[1] = 0,
> .trigger_type[2] = 1,
> + .trigger_type[3] = 2,
> .gain = 8,
> .reference_voltage = 16,
> .noise_cancel_mode = 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 v6 1/6] thermal: add generic cpufreq cooling implementation
Hi, Amit,
On 2012년 08월 16일 20:41, Amit Daniel Kachhap wrote:
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> new file mode 100644
> index 000..66cbd52
> --- /dev/null
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -0,0 +1,586 @@
> +/**
> + * cpufreq_cooling_register - function to create cpufreq cooling device.
> + * @clip_cpus: cpumask of cpus where the frequency constraints will happen.
> + */
> +struct thermal_cooling_device *cpufreq_cooling_register(
> + struct cpumask *clip_cpus)
> +{
> + struct thermal_cooling_device *cool_dev;
> + struct cpufreq_cooling_device *cpufreq_dev = NULL;
> + unsigned int cpufreq_dev_count = 0, min = 0, max = 0;
> + char dev_name[THERMAL_NAME_LENGTH];
> + int ret = 0, id = 0, i;
> + struct cpufreq_policy policy;
> + ret = get_idr(&cpufreq_idr,&cpufreq_dev->id);
> + if (ret) {
> + kfree(cpufreq_dev);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + sprintf(dev_name, "thermal-cpufreq-%d", cpufreq_dev->id);
> +
> + cool_dev = thermal_cooling_device_register(dev_name, cpufreq_dev,
> +&cpufreq_cooling_ops);
> + if (!cool_dev) {
> + release_idr(&cpufreq_idr, cpufreq_dev->id);
> + kfree(cpufreq_dev);
> + return ERR_PTR(-EINVAL);
> + }
> + cpufreq_dev->id = id;
Why is this needed? Should every cpufreq_dev instance's id be same for
zero? It looks odd. And it also has problem which can be occurred when
it release id during unregistering cpufreq_dev. I think it should keep
the idr value taken before.
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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 5/5] ARM: exynos: add thermal sensor driver platform data support
Hi, Amit,
On 2012년 07월 14일 16:30, amit kachhap wrote:
> On Sat, Jul 14, 2012 at 7:03 AM, Kyungmin Park wrote:
>> On Fri, Jul 13, 2012 at 8:10 PM, Amit Daniel Kachhap
>> wrote:
>>> Add necessary default platform data support needed for TMU driver. This
>>> dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
>>> platforms.
>> Looks good to me.
> Thanks.
>
>> just nitpicks below.
>>
>> Thank you,
>> Kyungmin Park
>>> Signed-off-by: Amit Daniel Kachhap
>>> Cc: Donggeun Kim
>>> Acked-by: Guenter Roeck
>>> Cc: SangWook Ju
>>> Cc: Durgadoss
>>> Cc: Len Brown
>>> Cc: Jean Delvare
>>> Signed-off-by: Andrew Morton
>>> ---
>>> drivers/thermal/exynos_thermal.c | 111
>>> +-
>>> 1 files changed, 110 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/thermal/exynos_thermal.c
>>> b/drivers/thermal/exynos_thermal.c
>>> index 9ef8c37..07736ea 100644
>>> --- a/drivers/thermal/exynos_thermal.c
>>> +++ b/drivers/thermal/exynos_thermal.c
>>> @@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>>> static struct thermal_sensor_conf exynos_sensor_conf = {
>>> .name = "exynos-therm",
>>> .read_temperature = (int (*)(void *))exynos_tmu_read,
>>> +};
>>> +
>>> +#if defined(CONFIG_CPU_EXYNOS4210)
>> BTW, doesn't it same as exynos4412? does it different from exynos4412?
> Currently I only tested this only for origen and exynos5250 board.
> Maybe somebody can add 4412 support also.
Recently, I applied this patchset with exynos4412 and found it uses same
register map with exynos5250.
So, I think it should rename the any type of name containing exynos4 and
exynos5 (e.g. SOC_ARCH_EXYNOS4)
In my local, i renamed SOC_ARCH_EXYNOS4 to SOC_ARCH_EXYNOS4210 and
SOC_ARCH_EXYNOS5 to SOC_ARCH_EXYNOS and
other related name also. I recommend you to change all of name
>> If it's same, it's better to use CONFIG_SOC_EXYNOS4?
>>> +static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
>>> + .threshold = 80,
>>> + .trigger_levels[0] = 5,
>>> + .trigger_levels[1] = 20,
>>> + .trigger_levels[2] = 30,
>>> + .trigger_level0_en = 1,
>>> + .trigger_level1_en = 1,
>>> + .trigger_level2_en = 1,
>>> + .trigger_level3_en = 0,
>>> + .gain = 15,
>>> + .reference_voltage = 7,
>>> + .cal_type = TYPE_ONE_POINT_TRIMMING,
>>> + .freq_tab[0] = {
>>> + .freq_clip_max = 800 * 1000,
>>> + .temp_level = 85,
>>> + },
>>> + .freq_tab[1] = {
>>> + .freq_clip_max = 200 * 1000,
>>> + .temp_level = 100,
>>> + },
>>> + .freq_tab_count = 2,
>>> + .type = SOC_ARCH_EXYNOS4,
>>> +};
>>> +#define EXYNOS4_TMU_DRV_DATA (&exynos4_default_tmu_data)
>>> +#else
>>> +#define EXYNOS4_TMU_DRV_DATA (NULL)
>>> +#endif
>>> +
>>> +#if defined(CONFIG_SOC_EXYNOS5250)
>> similar.
>>> +static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
>>> + .trigger_levels[0] = 85,
>>> + .trigger_levels[1] = 103,
>>> + .trigger_levels[2] = 110,
>>> + .trigger_level0_en = 1,
>>> + .trigger_level1_en = 1,
>>> + .trigger_level2_en = 1,
>>> + .trigger_level3_en = 0,
>>> + .gain = 8,
>>> + .reference_voltage = 16,
>>> + .noise_cancel_mode = 4,
>>> + .cal_type = TYPE_ONE_POINT_TRIMMING,
>>> + .efuse_value = 55,
>>> + .freq_tab[0] = {
>>> + .freq_clip_max = 800 * 1000,
>>> + .temp_level = 85,
>>> + },
>>> + .freq_tab[1] = {
>>> + .freq_clip_max = 200 * 1000,
>>> + .temp_level = 103,
>>> + },
>>> + .freq_tab_count = 2,
>>> + .type = SOC_ARCH_EXYNOS5,
>>> +};
>>> +#define EXYNOS5_TMU_DRV_DATA (&exynos5_default_tmu_data)
>>> +#else
>>> +#define EXYNOS5_TMU_DRV_DATA (NULL)
>>> +#endif
>>> +
>>> +#ifdef CONFIG_OF
>>> +static const struct of_device_id exynos_tmu_match[] = {
>>> + {
>>> + .compatible = "samsung,exynos4-tmu",
>>> + .data = (void *)EXYNOS4_TMU_DRV_DATA,
>>> + },
>>> + {
>>> + .compatible = "samsung,exynos5-tmu",
>>> + .data = (void *)EXYNOS5_TMU_DRV_DATA,
>>> + },
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>>> +#else
>>> +#define exynos_tmu_match NULL
>>> +#endif
>>> +
>>> +static struct platform_device_id exynos_tmu_driver_ids[] = {
>>> + {
>>> + .name = "exynos4-tmu",
>>> + .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
>>> + },
>>> + {
>>> + .name = "exynos5-tmu",
>>> + .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
>>> + },
>>> + { },
>>> +};
>>> +MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
>>> +
>>> +static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
>>> +
Re: [PATCH v3 2/2] regulator: Add support for MAX77686.
On 2012년 05월 23일 14:23, Yadwinder Singh Brar wrote: > On Wed, May 23, 2012 at 10:10 AM, wrote: >> On 2012년 05월 23일 13:16, Yadwinder Singh Brar wrote: >> > + max77686_update_reg(i2c, MAX77686_REG_BUCK2CTRL1, > + max77686->ramp_delay << 6, RAMP_MASK); > + max77686_update_reg(i2c, MAX77686_REG_BUCK3CTRL1, > + max77686->ramp_delay << 6, RAMP_MASK); > + max77686_update_reg(i2c, MAX77686_REG_BUCK4CTRL1, > + max77686->ramp_delay << 6, RAMP_MASK); > + Why do you use i2c client still? If you registered regmap you can use its API. I recommend you to use regmap_update_bits() directly. >>> >>> Yes, we are using regmap_update_bits(). max77686_update_reg() is just >>> a wrapper over it. >>> >> >> >> Yes, i know what you mean. However it doesn't need max77686_update_reg() >> any more since it uses regmap API. Why don't you just pass iodev->regmap >> to regmap_update_bits(). It is clear that there is no reason for using >> i2c client as a medium. Please check regulator and mfd driver of my >> previous patch. >> > > I agree with you we can use directly regmap API. But I preferred > max77686_update_reg() because its a common practice to use > common read/write API which we define in mfd driver to access > that particular mfd device from other drivers. > > Regards, > Yadwinder. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > I inform you my mfd driver has been confirmed by Samuel Oritz and there is no mfd private API. This situation looks unusual that we registers mfd driver and regulator driver separately. But how should we do? For corporation , i'm asking you to consider my suggestion. Thanks. 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 v3 2/2] regulator: Add support for MAX77686.
On 2012년 05월 23일 13:16, Yadwinder Singh Brar wrote: >>> + max77686_update_reg(i2c, MAX77686_REG_BUCK2CTRL1, >>> + max77686->ramp_delay << 6, RAMP_MASK); >>> + max77686_update_reg(i2c, MAX77686_REG_BUCK3CTRL1, >>> + max77686->ramp_delay << 6, RAMP_MASK); >>> + max77686_update_reg(i2c, MAX77686_REG_BUCK4CTRL1, >>> + max77686->ramp_delay << 6, RAMP_MASK); >>> + >> >> >> Why do you use i2c client still? If you registered regmap you can use >> its API. I recommend you to use regmap_update_bits() directly. >> >> > > Yes, we are using regmap_update_bits(). max77686_update_reg() is just > a wrapper over it. > Yes, i know what you mean. However it doesn't need max77686_update_reg() any more since it uses regmap API. Why don't you just pass iodev->regmap to regmap_update_bits(). It is clear that there is no reason for using i2c client as a medium. Please check regulator and mfd driver of my previous patch. 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 v3 2/2] regulator: Add support for MAX77686.
Hi, again.
On 2012년 05월 22일 14:57, yadi.bra...@gmail.com wrote:
> +static __devinit int max77686_pmic_probe(struct platform_device *pdev)
> +{
> +
> + for (i = 0; i < pdata->num_regulators; i++) {
> + config.dev = max77686->dev;
> + config.init_data = pdata->regulators[i].init_data;
> + config.driver_data = max77686;
> + config.regmap = iodev->regmap;
> +
> + rdev[i] = regulator_register(®ulators[i], &config);
I'm sorry that i missed one. You have to register all regulators
unconditionally. Mark brown commented about this to my former patch.
'No, you should unconditionally register all regulators the device
physically has. This is useful for debug and simplifies the code.'
- from Mark Brown
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 v3 2/2] regulator: Add support for MAX77686.
Hi, Yadwinder,
As you know, both of us, recently, had competition for one driver
whether you intend or not. And now, i think it is time to stop this and
to find appropriate goal. From now on, i won't update this driver no
more. I recommend you to review my patch and apply feature that you can
apply. And also check comments that i wrote below.
On 2012년 05월 22일 14:57, yadi.bra...@gmail.com wrote:
> From: Yadwinder Singh Brar
>
> Add support for PMIC/regulator portion of MAX77686 multifunction device.
> MAX77686 provides LDOs[1-26] and BUCKs[1-9]. This is initial release of driv
> which supports setting and getting the voltage of a regulator with I2C
> interface.
>
> Signed-off-by: Yadwinder Singh Brar
> ---
> drivers/regulator/Kconfig|9 +
> drivers/regulator/Makefile |1 +
> drivers/regulator/max77686.c | 387
> ++
> 3 files changed, 397 insertions(+), 0 deletions(-)
> create mode 100644 drivers/regulator/max77686.c
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index c86b886..e8f9417 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -195,6 +195,15 @@ config REGULATOR_MAX8998
> via I2C bus. The provided regulator is suitable for S3C6410
> and S5PC1XX chips to control VCC_CORE and VCC_USIM voltages.
>
> +config REGULATOR_MAX77686
> + tristate "Maxim 77686 regulator"
> + depends on MFD_MAX77686
> + help
> + This driver controls a Maxim 77686 voltage regulator via I2C
> + bus. The provided regulator is suitable for Exynos5 chips to
> + control VDD_ARM and VDD_INT voltages.It supports LDOs[1-26]
> + and BUCKs[1-9].
> +
> config REGULATOR_PCAP
> tristate "Motorola PCAP2 regulator driver"
> depends on EZX_PCAP
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 977fd46..d854453 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_REGULATOR_MAX8925) += max8925-regulator.o
> obj-$(CONFIG_REGULATOR_MAX8952) += max8952.o
> obj-$(CONFIG_REGULATOR_MAX8997) += max8997.o
> obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
> +obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
> obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
> obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
> obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
> diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
> new file mode 100644
> index 000..98dbd50
> --- /dev/null
> +++ b/drivers/regulator/max77686.c
> @@ -0,0 +1,387 @@
> +/*
> + * max77686.c - Regulator driver for the Maxim 77686
> + *
> + * Copyright (C) 2012 Samsung Electronics Co. Ltd.
> + * Chiwoong Byun
> + * Yadwinder Singh Brar
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + * This driver is based on max8997.c
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct max77686_data {
> + struct device *dev;
> + struct max77686_dev *iodev;
> + int num_regulators;
> + struct regulator_dev **rdev;
> + int ramp_delay; /* index of ramp_delay */
> +
> + /*GPIO-DVS feature is not enabled with the
> + *current version of MAX77686 driver.*/
> +};
> +
> +static int max77686_voltage_dvs_buck_time_sel(struct regulator_dev *rdev,
> + unsigned int old_sel,
> + unsigned int new_sel)
> +{
> + struct max77686_data *max77686 = rdev_get_drvdata(rdev);
> + int ramp[] = {13, 27, 55, 100}; /* ramp_rate in mV/uS */
> +
> + return DIV_ROUND_UP(rdev->desc->uV_step *
> + abs(new_sel - old_sel),
> + ramp[max77686->ramp_delay]);
> +}
> +
> +static int max77686_voltage_time_sel(struct regulator_dev *rdev,
> + unsigned int old_sel,
> + unsigned int new_sel)
> +{
> + return DIV_ROUND_UP(rdev->desc->uV_step *
> + abs(new_sel - old_sel),
> + 100);
> +}
> +
Does LDO also need waiting for vo
