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 pankaj.du...@samsung.com --- 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 linux/io.h + +#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: [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 thermal configuration data for exynos5440 TMU sensor thermal: exynos: Fix to set the second
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 kgene@samsung.com
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
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 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 kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
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);
if (IS_ERR(th_zone-therm_dev)) {
pr_err(Failed to register thermal zone device\n);
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 kgene@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com
---
.../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);
+ }
+ }
}
+ /*Clear the PMIN in the common TMU register*/
+ if (reg-tmu_pmin !data-id)
+ writel(0, data-base_common +
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 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 yadi.b...@samsung.com
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 yadi.b...@samsung.com
---
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 woong.b...@samsung.com
+ * Yadwinder Singh Brar yadi.b...@samsung.com
+ *
+ * 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 linux/module.h
+#include linux/bug.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
+#include linux/mfd/max77686.h
+#include linux/mfd/max77686-private.h
+
+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)
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(regulators[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.
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.
On 2012년 05월 23일 14:23, Yadwinder Singh Brar wrote: On Wed, May 23, 2012 at 10:10 AM, jonghwa3@samsung.com 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
