Re: [PATCH 07/10] spi: s3c64xx: Remove the 'set_level' callback from controller data
On Wed, May 9, 2012 at 3:34 AM, Thomas Abraham thomas.abra...@linaro.org wrote: The set_level callback in the controller data, which is used to configure the slave select line, cannot be supported when migrating the driver to device tree based discovery. Since all the platforms currently use gpio as the slave select line, this callback can be removed from the controller data and replaced with call to gpio_set_value in the driver. This patch is ok. Separately, you might also want to see if we really need the air-tight protection of spin_lock_irqsave around enable_cs - IIRC someone had a CS coming out of an gpio extender connected over I2C -- 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 00/10] spi: s3c64xx: add support for device tree
On Wed, May 9, 2012 at 3:34 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
This patch series adds device tree based discovery support for Samsung's
s3c64xx compatible spi controller. This is mainly tested for Exynos4210
and Exynos5250 with onboard spi nor flash device.
This patch series is based on Linux 3.4-rc5 with the following two
patch series applied.
[1]
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg10494.html
[PATCH 00/20] ARM: Samsung: Add support for Exynos5250 Rev1.0
[2]
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg09640.html
[PATCH 0/6] S3C24XX: Add support for HSSPI on S3C2416/S3C2443
Thomas Abraham (10):
spi: s3c64xx: remove unused S3C64XX_SPI_ST_TRLCNTZ macro
spi: s3c64xx: move controller information into driver data
ARM: Samsung: Remove spi hardware controller information from platform data
ARM: Samsung: Remove pdev pointer paremeter from spi gpio setup functions
ARM: Samsung: Update the device names for spi clock lookup
ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
spi: s3c64xx: Remove the 'set_level' callback from controller data
ARM: Exynos4: Fix the incorrect hierarchy of spi controller bus clock
ARM: Exynos5: Add spi clock support
spi: s3c64xx: add device tree support
Look ok to me. FWIW, Acked-by: Jassi Brar jassisinghb...@gmail.com
--
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/6] thermal: Add generic cpufreq cooling implementation
On 9 May 2012 01:46, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 8 May 2012 21:48:14 +0530
Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This patch adds support for generic cpu thermal cooling low level
implementations using frequency scaling up/down based on the registration
parameters. Different cpu related cooling devices can be registered by the
user and the binding of these cooling devices to the corresponding
trip points can be easily done as the registration APIs return the
cooling device pointer. The user of these APIs are responsible for
passing clipping frequency . The drivers can also register to recieve
notification about any cooling action called. Even the driver can effect
the cooling action by modifying the default data such as freq_clip_max if
needed.
...
+struct cpufreq_cooling_device {
+ int id;
+ struct thermal_cooling_device *cool_dev;
+ struct freq_clip_table *tab_ptr;
+ unsigned int tab_size;
+ unsigned int cpufreq_state;
+ const struct cpumask *allowed_cpus;
+ struct list_head node;
+};
It would be nice to document the fields. Especially id, tab_size,
cpufreq_state and node. For `node' we should describe the locking for
the list, and describe which list_head anchors this list.
Thanks Andrew for the detailed review. I will add more documentation
and post the next version shortly.
+static LIST_HEAD(cooling_cpufreq_list);
+static DEFINE_MUTEX(cooling_cpufreq_lock);
+static DEFINE_IDR(cpufreq_idr);
+static DEFINE_PER_CPU(unsigned int, max_policy_freq);
+static struct freq_clip_table *notify_table;
+static int notify_state;
+static BLOCKING_NOTIFIER_HEAD(cputherm_state_notifier_list);
+
+static int get_idr(struct idr *idr, struct mutex *lock, int *id)
+{
+ int err;
+again:
+ if (unlikely(idr_pre_get(idr, GFP_KERNEL) == 0))
+ return -ENOMEM;
+
+ if (lock)
+ mutex_lock(lock);
The test for NULL `lock' is unneeded. In fact the `lock' argument
could be removed altogether - just use cooling_cpufreq_lock directly.
Agreed
+ err = idr_get_new(idr, NULL, id);
+ if (lock)
+ mutex_unlock(lock);
+ if (unlikely(err == -EAGAIN))
+ goto again;
+ else if (unlikely(err))
+ return err;
+
+ *id = *id MAX_ID_MASK;
+ return 0;
+}
+
+static void release_idr(struct idr *idr, struct mutex *lock, int id)
+{
+ if (lock)
+ mutex_lock(lock);
Ditto.
+ idr_remove(idr, id);
+ if (lock)
+ mutex_unlock(lock);
+}
+
...
+
+/*Below codes defines functions to be used for cpufreq as cooling device*/
+static bool is_cpufreq_valid(int cpu)
+{
+ struct cpufreq_policy policy;
+ return !cpufreq_get_policy(policy, cpu) ? true : false;
Can use
Ok
return !cpufreq_get_policy(policy, cpu);
+}
+
+static int cpufreq_apply_cooling(struct cpufreq_cooling_device
*cpufreq_device,
+ unsigned long cooling_state)
+{
+ unsigned int event, cpuid;
+ struct freq_clip_table *th_table;
+
+ if (cooling_state cpufreq_device-tab_size)
+ return -EINVAL;
+
+ cpufreq_device-cpufreq_state = cooling_state;
+
+ /*cpufreq thermal notifier uses this cpufreq device pointer*/
This code looks like it was written by two people.
/* One who does this */
/*And one who does this*/
The first one was right. Please go through all the comments in all the
patches and get the layout consistent?
Sure will add more details.
+ notify_state = cooling_state;
+
+ if (notify_state 0) {
+ th_table = (cpufreq_device-tab_ptr[cooling_state - 1]);
+ memcpy(notify_table, th_table, sizeof(struct freq_clip_table));
+ event = CPUFREQ_COOLING_TYPE;
+ blocking_notifier_call_chain(cputherm_state_notifier_list,
+ event, notify_table);
+ }
+
+ for_each_cpu(cpuid, cpufreq_device-allowed_cpus) {
+ if (is_cpufreq_valid(cpuid))
+ cpufreq_update_policy(cpuid);
+ }
+
+ notify_state = -1;
+
+ return 0;
+}
+
+static int cpufreq_thermal_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct cpufreq_policy *policy = data;
+ unsigned long max_freq = 0;
+
+ if ((event != CPUFREQ_ADJUST) || (notify_state == -1))
Please document `notify_state', at its definition site. This reader
doesn't know what notify_state == -1 *means*.
+ return 0;
+
+ if (notify_state 0) {
+ max_freq = notify_table-freq_clip_max;
+
+ if (per_cpu(max_policy_freq, policy-cpu) == 0)
+ per_cpu(max_policy_freq, policy-cpu) = policy-max;
+ } else {
+ if (per_cpu(max_policy_freq, policy-cpu) != 0) {
+
Re: [PATCH 05/10] ARM: Samsung: Update the device names for spi clock lookup
On Wed, May 09, 2012 at 03:34:49AM +0530, Thomas Abraham wrote: With the addition of platform specific driver data in the spi-s3c64xx driver, the device name of spi controllers are changed. Accordingly, update the device name of spi clocks instances. This should've been squashed into the patch that updated to use driver data in order to avoid breaking bisection. -- 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 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
On Wed, May 09, 2012 at 03:34:50AM +0530, Thomas Abraham wrote: + s3c64xx_spi0_set_platdata(s3c6410-spi, NULL, 0, 1); Shouldn't we just set the name in the struct platform_device rather than requiring the machine to pass it through by hand? -- 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 10/10] spi: s3c64xx: add device tree support
On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as +the slave select line by the spi controller. The format of the gpio +specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. -- 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 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
Am Mittwoch, 9. Mai 2012, 10:56:17 schrieb Mark Brown: On Wed, May 09, 2012 at 03:34:50AM +0530, Thomas Abraham wrote: + s3c64xx_spi0_set_platdata(s3c6410-spi, NULL, 0, 1); Shouldn't we just set the name in the struct platform_device rather than requiring the machine to pass it through by hand? Similar to the adc and rtc driver, all Samsung platforms reuse a common platform-device definition for the s3c64xx-spi and simply will set the correct name when the machine type is determined during boot. I.e. I will also have to change my out-of-tree machine stuff to set the s3c2443-spi name using this method. The alternative is creating a mulitude of platform devices for each possible machine type using this driver. Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] spi: s3c64xx: Remove the 'set_level' callback from controller data
Am Mittwoch, 9. Mai 2012, 00:04:51 schrieb Thomas Abraham:
The set_level callback in the controller data, which is used to configure
the slave select line, cannot be supported when migrating the driver to
device tree based discovery. Since all the platforms currently use gpio
as the slave select line, this callback can be removed from the
controller data and replaced with call to gpio_set_value in the driver.
I was quite fond of the set_level callback. On one of the machines I'm working
on there is some sort of multiplexer (TI-sn74cbtlv3257) sitting between the
controller and spi devices to provide support for more than one device.
So I was doing the switch to the correct device in the set_level callback,
which worked quite well.
In the end, I'm still ok with this consolidation, as the device line has
reached it's end of life and the second device (an epaper controller)
provides another form of access to it through the display controller of the
s3c2416.
Heiko
[1]
https://github.com/mmind/linux-es600/blob/topic/es600-devel/arch/arm/mach-s3c24xx/common-es600.c#L1155
Cc: Jaswinder Singh jaswinder.si...@linaro.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h |2 --
drivers/spi/spi-s3c64xx.c|8
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h index a733ce9..48a6495
100644
--- a/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
+++ b/arch/arm/plat-samsung/include/plat/s3c64xx-spi.h
@@ -18,7 +18,6 @@ struct platform_device;
* @fb_delay: Slave specific feedback delay.
*Refer to FB_CLK_SEL register definition in SPI chapter.
* @line: Custom 'identity' of the CS line.
- * @set_level: CS line control.
*
* This is per SPI-Slave Chipselect information.
* Allocate and initialize one in machine init code and make the
@@ -27,7 +26,6 @@ struct platform_device;
struct s3c64xx_spi_csinfo {
u8 fb_delay;
unsigned line;
- void (*set_level)(unsigned line_id, int lvl);
};
/**
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f6bc0e3..d84ce7f 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -406,14 +406,14 @@ static inline void enable_cs(struct
s3c64xx_spi_driver_data *sdd, if (sdd-tgl_spi != spi) { /* if last mssg
on diff device */
/* Deselect the last toggled device */
cs = sdd-tgl_spi-controller_data;
- cs-set_level(cs-line,
- spi-mode SPI_CS_HIGH ? 0 : 1);
+ gpio_set_value(cs-line,
+ spi-mode SPI_CS_HIGH ? 0 : 1);
}
sdd-tgl_spi = NULL;
}
cs = spi-controller_data;
- cs-set_level(cs-line, spi-mode SPI_CS_HIGH ? 1 : 0);
+ gpio_set_value(cs-line, spi-mode SPI_CS_HIGH ? 1 : 0);
}
static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -499,7 +499,7 @@ static inline void disable_cs(struct
s3c64xx_spi_driver_data *sdd, if (sdd-tgl_spi == spi)
sdd-tgl_spi = NULL;
- cs-set_level(cs-line, spi-mode SPI_CS_HIGH ? 0 : 1);
+ gpio_set_value(cs-line, spi-mode SPI_CS_HIGH ? 0 : 1);
}
static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
--
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 5/6] thermal: exynos: Register the tmu sensor with the kernel thermal layer
On 9 May 2012 01:46, Andrew Morton a...@linux-foundation.org wrote:
On Tue, 8 May 2012 21:48:17 +0530
Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This code added creates a link between temperature sensors, linux thermal
framework and cooling devices for samsung exynos platform. This layer
monitors the temperature from the sensor and informs the generic thermal
layer to take the necessary cooling action.
...
+static void exynos_report_trigger(void)
+{
+ unsigned int i;
+ char data[2];
+ char *envp[] = { data, NULL };
+
+ if (!th_zone || !th_zone-therm_dev)
+ return;
+
+ thermal_zone_device_update(th_zone-therm_dev);
+
+ mutex_lock(th_zone-therm_dev-lock);
+ /* Find the level for which trip happened */
+ for (i = 0; i th_zone-sensor_conf-trip_data.trip_count; i++) {
+ if (th_zone-therm_dev-last_temperature
+ th_zone-sensor_conf-trip_data.trip_val[i] * 1000)
+ break;
+ }
+
+ if (th_zone-mode == THERMAL_DEVICE_ENABLED) {
+ if (i 0)
+ th_zone-therm_dev-polling_delay = ACTIVE_INTERVAL;
+ else
+ th_zone-therm_dev-polling_delay = IDLE_INTERVAL;
+ }
+
+ sprintf(data, %u, i);
yikes, if `i' exceeds 9, we have a stack scribble. Please review this
and at least use snprintf(... sizeof(data)) to prevent accidents.
Ok
+ kobject_uevent_env(th_zone-therm_dev-device.kobj, KOBJ_CHANGE,
envp);
+ mutex_unlock(th_zone-therm_dev-lock);
+}
+
...
+/* Get trip temperature callback functions for thermal zone */
+static int exynos_get_trip_temp(struct thermal_zone_device *thermal, int
trip,
+ unsigned long *temp)
+{
+ if (trip 0 || trip 2)
I don't know what `trip' does and I don't know the meaning of the
values 0, 1 and 2. Documentation, please.
Agreed will put their description.
+ return -EINVAL;
+
+ *temp = th_zone-sensor_conf-trip_data.trip_val[trip];
+ /* convert the temperature into millicelsius */
+ *temp = *temp * 1000;
+
+ return 0;
+}
+
...
+/* Bind callback functions for thermal zone */
+static int exynos_bind(struct thermal_zone_device *thermal,
+ struct thermal_cooling_device *cdev)
+{
+ int ret = 0;
+
+ /* if the cooling device is the one from exynos4 bind it */
+ if (cdev != th_zone-cool_dev[0])
+ return 0;
+
+ if (thermal_zone_bind_cooling_device(thermal, 0, cdev)) {
+ pr_err(error binding cooling dev inst 0\n);
+ return -EINVAL;
+ }
+ if (thermal_zone_bind_cooling_device(thermal, 1, cdev)) {
+ pr_err(error binding cooling dev inst 1\n);
+ ret = -EINVAL;
+ goto error_bind1;
+ }
There can never be more than two instances?
As of now it is fixed as we register only 2 zones
+ return ret;
+error_bind1:
+ thermal_zone_unbind_cooling_device(thermal, 0, cdev);
+ return ret;
+}
+
...
+/* Get temperature callback functions for thermal zone */
+static int exynos_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ void *data;
+
+ if (!th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+ data = th_zone-sensor_conf-private_data;
+ *temp = th_zone-sensor_conf-read_temperature(data);
+ /* convert the temperature into millicelsius */
+ *temp = *temp * 1000;
+ return 0;
+}
+
+/* Operation callback functions for thermal zone */
+static struct thermal_zone_device_ops exynos_dev_ops = {
Can it be const? That sometimes saves space, as the table doesn't need
to be moved into writeable storage at runtime.
Yes it can be made const
+ .bind = exynos_bind,
+ .unbind = exynos_unbind,
+ .get_temp = exynos_get_temp,
+ .get_mode = exynos_get_mode,
+ .set_mode = exynos_set_mode,
+ .get_trip_type = exynos_get_trip_type,
+ .get_trip_temp = exynos_get_trip_temp,
+ .get_crit_temp = exynos_get_crit_temp,
+};
+
+/* Register with the in-kernel thermal management */
+static int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf)
+{
+ int ret, count, tab_size;
+ struct freq_clip_table *tab_ptr;
+
+ if (!sensor_conf || !sensor_conf-read_temperature) {
+ pr_err(Temperature sensor not initialised\n);
+ return -EINVAL;
+ }
+
+ th_zone = kzalloc(sizeof(struct exynos_thermal_zone), GFP_KERNEL);
+ if (!th_zone) {
+ ret = -ENOMEM;
+ goto err_unregister;
This seems wrong? If we need to call exynos_unregister_thermal() on
this error path then we needed to call it on the predecing one?
Perhaps?
ok my fault.
+ }
+
+ th_zone-sensor_conf = sensor_conf;
+
+
Re: [PATCH 07/10] spi: s3c64xx: Remove the 'set_level' callback from controller data
On 9 May 2012 14:50, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 9. Mai 2012, 00:04:51 schrieb Thomas Abraham: The set_level callback in the controller data, which is used to configure the slave select line, cannot be supported when migrating the driver to device tree based discovery. Since all the platforms currently use gpio as the slave select line, this callback can be removed from the controller data and replaced with call to gpio_set_value in the driver. I was quite fond of the set_level callback. On one of the machines I'm working on there is some sort of multiplexer (TI-sn74cbtlv3257) sitting between the controller and spi devices to provide support for more than one device. So I was doing the switch to the correct device in the set_level callback, which worked quite well. I suppose you should still be able to do that defining virtual gpios backed by appropriate physical mux'ing of lines ? -jassi -- 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 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
On Wed, May 09, 2012 at 11:10:14AM +0200, Heiko Stübner wrote: Similar to the adc and rtc driver, all Samsung platforms reuse a common platform-device definition for the s3c64xx-spi and simply will set the correct name when the machine type is determined during boot. Right, that doesn't mean this is a great way of doing things, though - it's been a frequent source of errors in the past and is painful to debug as the data structures get rewritten during boot which is a bit of a surprise. The alternative is creating a mulitude of platform devices for each possible machine type using this driver. Yes, that's the normal way of handling this and is actually what the code was originally doing - there's a bunch of ifdefed devices in plat-samsung/devs.c. You usually have to do this anyway as the IPs move about so the resources need changing. signature.asc Description: Digital signature
[PATCH] ARM: SAMSUNG: Fix the value of tcnt and tcmp for PWM
According to PWM hardware spec, the actual period which
has been calculated by period and input clock is same
with (tcnt + 1), so need to down count for tcnt register.
And current PWM HW checks the compare register after
tcmp++ internally in hardware.
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/plat-samsung/pwm.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-samsung/pwm.c b/arch/arm/plat-samsung/pwm.c
index c559d84..88fdb1c 100644
--- a/arch/arm/plat-samsung/pwm.c
+++ b/arch/arm/plat-samsung/pwm.c
@@ -22,6 +22,7 @@
#include mach/map.h
+#include plat/cpu.h
#include plat/regs-timer.h
struct pwm_device {
@@ -215,10 +216,24 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int
period_ns)
tcmp = duty_ns / tin_ns;
tcmp = tcnt - tcmp;
- /* the pwm hw only checks the compare register after a decrement,
- so the pin never toggles if tcmp = tcnt */
- if (tcmp == tcnt)
- tcmp--;
+
+ if (soc_is_s3c24xx()) {
+ /*
+* The S3C24XX PWM HW only checks the compare register after
+* a decrement, so the pin never toggles if tcmp = tcnt.
+*/
+ if (tcmp == tcnt)
+ tcmp--;
+ } else {
+ /*
+* The other PWM HW checks the compare register after tcmp++
+* internally, so needs -2 for tcmp, and the actual period
+* which has been calculated by period_ns and tin_ns is same
+* with (tcnt + 1), so need to down count for tcnt register.
+*/
+ tcmp = tcmp - 2;
+ tcnt--;
+ }
pwm_dbg(pwm, tin_ns=%lu, tcmp=%ld/%lu\n, tin_ns, tcmp, tcnt);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 07/20] ARM: EXYNOS: Add pre-divider and fout mux clocks for bpll and mpll
Thomas Abraham wrote:
From: Kisoo Yu ksoo...@samsung.com
The fout clock of BPLL and MPLL have a selectable source in rev1 of
EXYNOS5. The clock options are a fixed divided by 2 clock and the
output of the PLL itself. Add support for these new clock instances.
Signed-off-by: Kisoo Yu ksoo...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
[kgene@samsung.com: temporary apply this because I
don't want to add pll stuff in each clock not commonly]
As I commented, I won't apply this because pll stuff should be added in
common file such as plat-s5p/clock.c even though the plat-s5p files moved
into plat-samsung.
Temporary-Signed-off-by: Kukjin Kim kgene@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
No. I didn't sign on this in my topic branch.
---
arch/arm/mach-exynos/clock-exynos5.c | 73
+++-
arch/arm/mach-exynos/include/mach/regs-clock.h |2 +
arch/arm/plat-s5p/clock.c | 11
3 files changed, 74 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-
exynos/clock-exynos5.c
index 846741e..7c0f810 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -145,6 +145,39 @@ static struct clksrc_clk exynos5_clk_sclk_apll = {
.reg_div = { .reg = EXYNOS5_CLKDIV_CPU0, .shift = 24, .size = 3 },
};
+static struct clk clk_fout_bpll_div2 = {
+ .name = fout_bpll_div2,
+};
+
+static struct clk *exynos5_clkset_mout_bpll_fout_list[] = {
+ [0] = clk_fout_bpll_div2,
+ [1] = clk_fout_bpll,
+};
+
+static struct clksrc_sources exynos5_clkset_mout_bpll_fout = {
+ .sources= exynos5_clkset_mout_bpll_fout_list,
+ .nr_sources = ARRAY_SIZE(exynos5_clkset_mout_bpll_fout_list),
+};
+
+static struct clksrc_clk exynos5_clk_mout_bpll_fout = {
+ .clk= {
+ .name = mout_bpll_fout,
+ },
+ .sources = exynos5_clkset_mout_bpll_fout,
+ .reg_src = { .reg = EXYNOS5_PLL_DIV2_SEL, .shift = 0, .size = 1 },
+};
+
+/* Possible clock sources for BPLL Mux */
+static struct clk *clk_src_bpll_list[] = {
+ [0] = clk_fin_bpll,
+ [1] = exynos5_clk_mout_bpll_fout.clk,
+};
+
+struct clksrc_sources clk_src_bpll = {
+ .sources= clk_src_bpll_list,
+ .nr_sources = ARRAY_SIZE(clk_src_bpll_list),
+};
+
static struct clksrc_clk exynos5_clk_mout_bpll = {
.clk= {
.name = mout_bpll,
@@ -187,11 +220,43 @@ static struct clksrc_clk exynos5_clk_mout_epll = {
.reg_src = { .reg = EXYNOS5_CLKSRC_TOP2, .shift = 12, .size = 1 },
};
+static struct clk clk_fout_mpll_div2 = {
+ .name = fout_mpll_div2,
+};
+
+static struct clk *exynos5_clkset_mout_mpll_fout_list[] = {
+ [0] = clk_fout_mpll_div2,
+ [1] = clk_fout_mpll,
+};
+
+static struct clksrc_sources exynos5_clkset_mout_mpll_fout = {
+ .sources= exynos5_clkset_mout_mpll_fout_list,
+ .nr_sources = ARRAY_SIZE(exynos5_clkset_mout_mpll_fout_list),
+};
+
+static struct clksrc_clk exynos5_clk_mout_mpll_fout = {
+ .clk= {
+ .name = mout_mpll_fout,
+ },
+ .sources = exynos5_clkset_mout_mpll_fout,
+ .reg_src = { .reg = EXYNOS5_PLL_DIV2_SEL, .shift = 4, .size = 1 },
+};
+
+static struct clk *exynos5_clk_src_mpll_list[] = {
+ [0] = clk_fin_mpll,
+ [1] = exynos5_clk_mout_mpll_fout.clk,
+};
+
+struct clksrc_sources exynos5_clk_src_mpll = {
+ .sources= exynos5_clk_src_mpll_list,
+ .nr_sources = ARRAY_SIZE(exynos5_clk_src_mpll_list),
+};
+
struct clksrc_clk exynos5_clk_mout_mpll = {
.clk = {
.name = mout_mpll,
},
- .sources = clk_src_mpll,
+ .sources = exynos5_clk_src_mpll,
.reg_src = { .reg = EXYNOS5_CLKSRC_CORE1, .shift = 8, .size = 1 },
};
@@ -946,10 +1011,12 @@ static struct clksrc_clk *exynos5_sysclks[] = {
exynos5_clk_mout_apll,
exynos5_clk_sclk_apll,
exynos5_clk_mout_bpll,
+ exynos5_clk_mout_bpll_fout,
exynos5_clk_mout_bpll_user,
exynos5_clk_mout_cpll,
exynos5_clk_mout_epll,
exynos5_clk_mout_mpll,
+ exynos5_clk_mout_mpll_fout,
exynos5_clk_mout_mpll_user,
exynos5_clk_vpllsrc,
exynos5_clk_sclk_vpll,
@@ -1013,6 +1080,8 @@ static struct clk *exynos5_clks[] __initdata = {
exynos5_clk_sclk_hdmi27m,
exynos5_clk_sclk_hdmiphy,
clk_fout_bpll,
+ clk_fout_bpll_div2,
+ clk_fout_mpll_div2,
clk_fout_cpll,
exynos5_clk_armclk,
};
@@ -1178,8 +1247,10 @@ void __init_or_cpufreq exynos5_setup_clocks(void)
clk_fout_apll.ops = exynos5_fout_apll_ops;
clk_fout_bpll.rate = bpll;
+ clk_fout_bpll_div2.rate = bpll 1;
clk_fout_cpll.rate = cpll;
clk_fout_mpll.rate = mpll;
+ clk_fout_mpll_div2.rate =
RE: [PATCH 00/20] ARM: Samsung: Add support for Exynos5250 Rev1.0
Thomas Abraham wrote: This patch series adds support for Samsung's Exynos5250 Rev1.0. It includes fixes for device tree support, updates for rev1.0 silicon and device tree discovery for combiner and wakeup interrupt controller. This patch series depricates the existing support for Exynos5250 Rev0.0. This patchset is based and tested on top of v3.4-rc5. Boojin Kim (1): ARM: EXYNOS: Support DMA for EXYNOS5250 SoC Changhwan Youn (2): ARM: EXYNOS: Modify the GIC physical address for static io-mapping ARM: EXYNOS: Redefine IRQ_MCT_L0,1 definition Kisoo Yu (1): ARM: EXYNOS: Add pre-divider and fout mux clocks for bpll and mpll Kukjin Kim (2): ARM: EXYNOS: fix ctrlbit for exynos5_clk_pdma1 ARM: EXYNOS: update irqs for EXYNOS5250 evt1 Sangsu Park (1): ARM: EXYNOS: add GPC4 bank instance Thomas Abraham (13): ARM: EXYNOS: Add watchdog timer clock instance ARM: Exynos: Remove a new bus_type instance for Exynos5 of/irq: fix interrupt parent lookup procedure of/irq: add retry support for interrupt controller tree initialization ARM: Exynos: Add irq_domain support for interrupt combiner ARM: Exynos: Add device tree support for interrupt combiner ARM: Exynos: Simplify the wakeup interrupt setup code ARM: Exynos: Add irq_domain support for gpio wakeup interrupts ARM: Exynos: Remove arch_initcall for wakeup interrupt initialization ARM: Exynos: Add device tree support for gpio wakeup interrupt controller ARM: dts: Update device tree source files for EXYNOS5250 ARM: Exynos5: Add combiner, wakeup interrupt controller and ethernet nodes ARM: Exynos5: Add AUXDATA for i2c controllers .../bindings/arm/samsung/interrupt-combiner.txt| 52 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 63 arch/arm/boot/dts/exynos5250.dtsi | 99 -- arch/arm/mach-exynos/Kconfig |7 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos5.c | 80 +- arch/arm/mach-exynos/common.c | 338 ++-- arch/arm/mach-exynos/dma.c | 129 +++-- arch/arm/mach-exynos/include/mach/gpio.h |9 +- arch/arm/mach-exynos/include/mach/irqs.h | 40 ++- arch/arm/mach-exynos/include/mach/map.h|4 +- arch/arm/mach-exynos/include/mach/regs-clock.h |2 + arch/arm/mach-exynos/include/mach/regs-gpio.h |4 +- arch/arm/mach-exynos/mach-exynos5-dt.c |4 + arch/arm/mach-exynos/mct.c | 17 +- arch/arm/mach-exynos/pm.c |2 +- arch/arm/plat-s5p/clock.c | 11 - arch/arm/plat-samsung/Kconfig |2 +- arch/arm/plat-samsung/include/plat/cpu.h |2 +- arch/arm/plat-samsung/include/plat/dma-pl330.h |1 + drivers/gpio/gpio-samsung.c| 11 +- drivers/of/irq.c | 29 ++- 22 files changed, 698 insertions(+), 210 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt -- 1.7.5.4 Hi, Basically, it's ok to me on 1st~9th patches except #7 as I commented. Will apply them but need to update #7. And I will look at the others again. If any comments, let you know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
amit kachhap wrote:
Hi Mr Kukjin,
Any comment or update about this patch?
I'm not sure we don't need to check the idle_time?
Others, looks ok to me.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Regards,
Amit Daniel
On Mon, Apr 30, 2012 at 10:13 PM, Rob Lee rob@linaro.org wrote:
On Wed, Apr 25, 2012 at 9:44 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 04/25/2012 02:11 PM, Amit Daniel Kachhap wrote:
This patch enables core cpuidle timekeeping and irq enabling and
remove those redundant parts from the exynos cpuidle drivers
CC: Daniel Lezcanodaniel.lezc...@linaro.org
CC: Robert Leerob@linaro.org
Signed-off-by: Amit Danielamit.kach...@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 53
---
1 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c
b/arch/arm/mach-exynos/cpuidle.c
index 33ab4e7..26dac28 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -20,6 +20,7 @@
#includeasm/smp_scu.h
#includeasm/suspend.h
#includeasm/unified.h
+#includeasm/cpuidle.h
#includemach/regs-pmu.h
#includemach/pmu.h
@@ -34,22 +35,12 @@
#define S5P_CHECK_AFTR0xFCBA0D10
-static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index);
static int exynos4_enter_lowpower(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
static struct cpuidle_state exynos4_cpuidle_set[] __initdata = {
- [0] = {
- .enter = exynos4_enter_idle,
- .exit_latency = 1,
- .target_residency = 10,
- .flags = CPUIDLE_FLAG_TIME_VALID,
- .name = C0,
- .desc = ARM clock gating(WFI),
- },
+ [0] = ARM_CPUIDLE_WFI_STATE,
[1] = {
.enter = exynos4_enter_lowpower,
.exit_latency = 300,
@@ -63,8 +54,9 @@ static struct cpuidle_state exynos4_cpuidle_set[]
__initdata = {
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
static struct cpuidle_driver exynos4_idle_driver = {
- .name = exynos4_idle,
- .owner = THIS_MODULE,
+ .name = exynos4_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
};
/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
@@ -103,13 +95,8 @@ static int exynos4_enter_core0_aftr(struct
cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct timeval before, after;
- int idle_time;
unsigned long tmp;
- local_irq_disable();
- do_gettimeofday(before);
-
exynos4_set_wakeupmask();
/* Set value of power down register for aftr mode */
@@ -150,34 +137,6 @@ static int exynos4_enter_core0_aftr(struct
cpuidle_device *dev,
/* Clear wakeup state register */
__raw_writel(0x0, S5P_WAKEUP_STAT);
- do_gettimeofday(after);
-
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
- return index;
-}
-
-static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- cpu_do_idle();
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
return index;
}
@@ -192,7 +151,7 @@ static int exynos4_enter_lowpower(struct
cpuidle_device *dev,
new_index = drv-safe_state_index;
if (new_index == 0)
- return exynos4_enter_idle(dev, drv, new_index);
+ return arm_cpuidle_simple_enter(dev, drv, new_index);
else
return exynos4_enter_core0_aftr(dev, drv, new_index);
}
Acked-by: Robert Lee rob@linaro.org
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM
SoCs
Follow Linaro:
Re: [PATCH] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
On 05/09/2012 01:53 PM, Kukjin Kim wrote: amit kachhap wrote: Hi Mr Kukjin, Any comment or update about this patch? I'm not sure we don't need to check the idle_time? Others, looks ok to me. Hi, may be I misunderstood your question but the behavior is not changed here, just the code is refactored and using a common routine where the time is computed. The idle_time computation is done by the cpuidle core now if the en_core_tk_irqen flag is enabled. That allows to remove a lot of duplicated code across the cpuidle drivers. Thanks -- Daniel -- 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] ARM: exynos: Adapt to cpuidle core time keeping and irq enable
Daniel Lezcano wrote: On 05/09/2012 01:53 PM, Kukjin Kim wrote: amit kachhap wrote: Hi Mr Kukjin, Any comment or update about this patch? I'm not sure we don't need to check the idle_time? Others, looks ok to me. Hi, may be I misunderstood your question but the behavior is not changed here, just the code is refactored and using a common routine where the time is computed. The idle_time computation is done by the cpuidle core now if the en_core_tk_irqen flag is enabled. That allows to remove a lot of duplicated code across the cpuidle drivers. OK, I see and checked. Daniel, thanks. Amit, this looks ok to me, will apply. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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] ARM: EXYNOS: fix the hotplug for Cortex-A15
From: Changhwan Youn chaos.y...@samsung.com
The sequence of cpu_enter_lowpower() for Cortex-A15
is different from the sequence for Cortex-A9.
This patch implements cpu_enter_lowpower() for EXYNOS5
SoC which has Cortex-A15 cores.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Note, I didn't see common code for fix of hotplug for Cortex-A15.
If any regarding patch, please kindly let me know, thanks.
arch/arm/mach-exynos/hotplug.c | 39 +--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 9c17a0a..2a444b1 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -21,9 +21,11 @@
#include mach/regs-pmu.h
+#include plat/cpu.h
+
extern volatile int pen_release;
-static inline void cpu_enter_lowpower(void)
+static inline void cpu_enter_lowpower_a9(void)
{
unsigned int v;
@@ -45,6 +47,35 @@ static inline void cpu_enter_lowpower(void)
: cc);
}
+static inline void cpu_enter_lowpower_a15(void)
+{
+ unsigned int v;
+
+ asm volatile(
+ mrc p15, 0, %0, c1, c0, 0\n
+ bic %0, %0, %1\n
+ mcr p15, 0, %0, c1, c0, 0\n
+ : =r (v)
+ : Ir (CR_C)
+ : cc);
+
+ flush_cache_all();
+
+ asm volatile(
+ /*
+ * Turn off coherency
+ */
+ mrc p15, 0, %0, c1, c0, 1\n
+ bic %0, %0, %1\n
+ mcr p15, 0, %0, c1, c0, 1\n
+ : =r (v)
+ : Ir (0x40)
+ : cc);
+
+ isb();
+ dsb();
+}
+
static inline void cpu_leave_lowpower(void)
{
unsigned int v;
@@ -112,7 +143,11 @@ void platform_cpu_die(unsigned int cpu)
/*
* we're ready for shutdown now, so do it
*/
- cpu_enter_lowpower();
+ if (soc_is_exynos5250())
+ cpu_enter_lowpower_a15();
+ else
+ cpu_enter_lowpower_a9();
+
platform_do_lowpower(cpu, spurious);
/*
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/4] ARM: S3C24XX: move some code from plat to mach directory
Heiko Stübner wrote:
Again the series of small moves of common code from the plat-s3c24xx to
the
mach-s3c24xx directory.
This time without the wrong handled irq.c . Hopefully I'll get time to do
it
properly later.
As the dev-uart.c move breaks the resource patch by Tushar Behera, I
updated
the patch to fix the correct code and will submit it as a v2 to the
resource
series.
Heiko Stuebner (4):
ARM: S3C24XX: move plat-s3c24xx/cpu.c
ARM: S3C24XX: move plat-s3c24xx/dev-uart.c into common.c
ARM: S3C24XX: move common power-management code to mach-s3c24xx
ARM: S3C24XX: move common clock init into common.c
arch/arm/mach-s3c24xx/Makefile |6 +
.../{plat-s3c24xx/cpu.c = mach-s3c24xx/common.c} | 93
++-
arch/arm/{plat-s3c24xx = mach-s3c24xx}/irq-pm.c |0
arch/arm/{plat-s3c24xx = mach-s3c24xx}/pm.c |0
arch/arm/{plat-s3c24xx = mach-s3c24xx}/sleep.S|0
arch/arm/plat-s3c24xx/Makefile |6 -
arch/arm/plat-s3c24xx/clock.c | 59
arch/arm/plat-s3c24xx/dev-uart.c | 100
8 files changed, 98 insertions(+), 166 deletions(-)
rename arch/arm/{plat-s3c24xx/cpu.c = mach-s3c24xx/common.c} (75%)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/irq-pm.c (100%)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/pm.c (100%)
rename arch/arm/{plat-s3c24xx = mach-s3c24xx}/sleep.S (100%)
delete mode 100644 arch/arm/plat-s3c24xx/clock.c
delete mode 100644 arch/arm/plat-s3c24xx/dev-uart.c
--
1.7.5.4
Thanks for your re-posting.
Looks better. Will apply this series instead.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 06/33] ARM: S3C24XX: dev-uart: Use common macro to define resources
Heiko Stübner wrote:
From: Tushar Behera tushar.beh...@linaro.org
CC: Ben Dooks ben-li...@fluff.org
CC: Kukjin Kim kgene@samsung.com
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
Signed-off-by: Heiko Stuebner he...@sntech.de
---
changes since v1: update the patch to apply against the moved dev-uart
devices
As this patch does not touch anything else apart from the uart devices it
could
also be applied on top of the movement patches directly
arch/arm/mach-s3c24xx/common.c | 56
+++-
---
1 files changed, 16 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-
s3c24xx/common.c
index d42423a..56cdd34 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -241,55 +241,31 @@ void __init s3c24xx_init_io(struct map_desc
*mach_desc, int size)
/* Serial port registrations */
static struct resource s3c2410_uart0_resource[] = {
- [0] = {
- .start = S3C2410_PA_UART0,
- .end = S3C2410_PA_UART0 + 0x3fff,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_S3CUART_RX0,
- .end = IRQ_S3CUART_ERR0,
- .flags = IORESOURCE_IRQ,
- }
+ [0] = DEFINE_RES_MEM(S3C2410_PA_UART0, SZ_16K),
+ [1] = DEFINE_RES_NAMED(IRQ_S3CUART_RX0, \
+ IRQ_S3CUART_ERR0 - IRQ_S3CUART_RX0 + 1, \
+ NULL, IORESOURCE_IRQ)
};
static struct resource s3c2410_uart1_resource[] = {
- [0] = {
- .start = S3C2410_PA_UART1,
- .end = S3C2410_PA_UART1 + 0x3fff,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_S3CUART_RX1,
- .end = IRQ_S3CUART_ERR1,
- .flags = IORESOURCE_IRQ,
- }
+ [0] = DEFINE_RES_MEM(S3C2410_PA_UART1, SZ_16K),
+ [1] = DEFINE_RES_NAMED(IRQ_S3CUART_RX1, \
+ IRQ_S3CUART_ERR1 - IRQ_S3CUART_RX1 + 1, \
+ NULL, IORESOURCE_IRQ)
};
static struct resource s3c2410_uart2_resource[] = {
- [0] = {
- .start = S3C2410_PA_UART2,
- .end = S3C2410_PA_UART2 + 0x3fff,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_S3CUART_RX2,
- .end = IRQ_S3CUART_ERR2,
- .flags = IORESOURCE_IRQ,
- }
+ [0] = DEFINE_RES_MEM(S3C2410_PA_UART2, SZ_16K),
+ [1] = DEFINE_RES_NAMED(IRQ_S3CUART_RX2, \
+ IRQ_S3CUART_ERR2 - IRQ_S3CUART_RX2 + 1, \
+ NULL, IORESOURCE_IRQ)
};
static struct resource s3c2410_uart3_resource[] = {
- [0] = {
- .start = S3C2443_PA_UART3,
- .end = S3C2443_PA_UART3 + 0x3fff,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = IRQ_S3CUART_RX3,
- .end = IRQ_S3CUART_ERR3,
- .flags = IORESOURCE_IRQ,
- },
+ [0] = DEFINE_RES_MEM(S3C2443_PA_UART3, SZ_16K),
+ [1] = DEFINE_RES_NAMED(IRQ_S3CUART_RX3, \
+ IRQ_S3CUART_ERR3 - IRQ_S3CUART_RX3 + 1, \
+ NULL, IORESOURCE_IRQ)
};
struct s3c24xx_uart_resources s3c2410_uart_resources[] __initdata = {
--
1.7.5.4
OK, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 9 May 2012 01:36, Zhang, Rui rui.zh...@intel.com wrote:
Hi, Amit,
Sorry for the late response as I'm in a travel recently.
I think the generic cpufreq cooling patches are good.
But about the THERMAL_TRIP_STATE_INSTANCE patch, what I'd like to see is that
1. from thermal zone point of view, when the temperature is higher than a
trip point, either ACTIVE or PASSIVE, what we should do is to set device
cooling state to cur_state+1, right?
The only difference is that if we should take passive cooling actions or
active cooling actions based on the policy.
So my question would be if it is possible to combine these two kind of trip
points together. Maybe something like this:
In thermal_zone_device_update(),
...
case THERMAL_TRIP_PASSIVE:
if (passive cooling not allowed)
continue;
if (tc1)
thermal_zone_device_passive();
else
thermal_set_cooling_state();
break;
case THERMAL_TRIP_ACTIVE:
if (active cooling not allowed)
continue;
thermal_set_cooling_state();
break;
...
and thermal_set_cooling_state() {
list_for_each_entry(instance, tz-cooling_devices, node) {
if (instance-trip != count)
continue;
cdev = instance-cdev;
if (temp = trip_temp)
cdev-ops-set_cur_state(cdev, 1);
else
cdev-ops-set_cur_state(cdev, 0);
}
}
2. use only one cooling_device instance for a thermal_zone, and introduce
cdev-trips which shows the trip points this cooling device is bind to.
And we may use multiple cooling devices states for one active trip point.
Then, thermal_set_cooling_state() would be look like
list_for_each_entry(instance, tz-cooling_devices, node) {
cdev = instance-cdev;
/* check whether this cooling device is bind to the trip point */
if (!(cdev-trips 1count))
continue;
cdev-ops-get_max_state(cdev, max_state);
cdev-ops-get_cur_state(cdev, cur_state);
if (temp = trip_temp) {
if (cur_state++ = max_state))
cdev-ops-set_cur_state(cdev, cur_state);
} else if ((temp trip_temp) (cur_state-- = 0))
cdev-ops-set_cur_state(cdev, cur_state);
}
}
Hi Rui,
The above implementation also cools instance based cooling devices
like passive trip type. I need some changes on top of your
implementation such as,
thermal_set_cooling_state() {
list_for_each_entry(instance, tz-cooling_devices,
node) {
cdev = instance-cdev;
if (!cdev-trips 1count)
continue;
inst_id = 0;
for_each_bit_set(i, cdev-trips, count)
inst_id++;
cdev-ops-get_max_state(cdev, max_state);
if ((temp = trip_temp) (inst_id = max_state))
cdev-ops-set_cur_state(cdev, inst_id);
else if ((temp trip_temp) (--inst_id = 0))
cdev-ops-set_cur_state(cdev, inst_id);
}
}
I agree with you that the instance based trip types violates the
concept like reading the cur_state and do cur_state++/cur_state--
depending upon threshold increase or decrease because it needs the
state_id/inst_id.
I am actually thinking of dropping this new trip type and use the
existing THERMAL_TRIP_ACTIVE because there is so much logic in
calculating the state_id. The only flip side of using TRIP_ACTIVE is
that I need to create so many cooling devices.
Thanks,
Amit D
With these two things, I think the WARN_ZONE AND MONITOR_ZONE can be
registered as two PASSIVE trip points in the generic thermal layer, right?
Actually, this is one thing in my TODO list. And I'd glad to make it high
priority if this solves the problem you have.
Thanks,
rui
-Original Message-
From: linux-acpi-ow...@vger.kernel.org
[mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap
Sent: Tuesday, May 08, 2012 9:18 AM
To: a...@linux-foundation.org; linux...@lists.linux-foundation.org
Cc: R, Durgadoss; linux-a...@vger.kernel.org; l...@kernel.org; Zhang, Rui;
amit.kach...@linaro.org; linaro-...@lists.linaro.org;
linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org; patc...@linaro.org
Subject: [PATCH v3 0/6] thermal: exynos: Add kernel thermal support for
exynos platform
Importance: High
Hi Andrew,
This patchset introduces a new generic cooling device based on cpufreq that
can be used on non-ACPI platforms. As a proof of concept, we have drivers for
the following platforms using this mechanism now:
* TI OMAP (git://git.linaro.org/people/amitdanielk/linux.git
omap4460_thermal)
* Samsung Exynos (Exynos4 and Exynos5) in the current patchset.
* Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git
imx6q_thermal)
These patches have been reviewed by Rui Zhang
(https://lkml.org/lkml/2012/4/9/448)
who seems to agree with them in principle, but I haven't had any luck getting
them merged, perhaps
[PATCH] ARM: EXYNOS: PD: Fix duplicate variable
struct generic_pm_domain already has a field for name. Use that field
instead of creating another field in struct exynos_pm_domain
Signed-off-by: Sangwook Lee sangwook@linaro.org
---
arch/arm/mach-exynos/pm_domains.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 13b3068..4d2563c 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -28,7 +28,6 @@
*/
struct exynos_pm_domain {
void __iomem *base;
- char const *name;
bool is_off;
struct generic_pm_domain pd;
};
@@ -75,10 +74,10 @@ static int exynos_pd_power_off(struct generic_pm_domain
*domain)
#define EXYNOS_GPD(PD, BASE, NAME) \
static struct exynos_pm_domain PD = { \
.base = (void __iomem *)BASE, \
- .name = NAME, \
.pd = { \
.power_off = exynos_pd_power_off, \
.power_on = exynos_pd_power_on, \
+ .name = NAME, \
}, \
}
@@ -99,7 +98,7 @@ static __init int exynos_pm_dt_parse_domains(void)
if (of_get_property(np, samsung,exynos4210-pd-off, NULL))
pd-is_off = true;
- pd-name = np-name;
+ pd-pd.name = (char *)np-name;
pd-base = of_iomap(np, 0);
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
@@ -122,7 +121,7 @@ static __init void exynos_pm_add_dev_to_genpd(struct
platform_device *pdev,
if (pm_genpd_add_device(pd-pd, pdev-dev))
pr_info(%s: error in adding %s device to %s power
domain\n, __func__, dev_name(pdev-dev),
- pd-name);
+ pd-pd.name);
}
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/33] Use common macro to define resources
Russell King - ARM Linux wrote: On Wed, Apr 25, 2012 at 11:21:47AM +, Arnd Bergmann wrote: Note that the point of the DEFINE_RES_*() macros is really to prevent people from coming up with new silly macros to do the same thing, as we've had in the past. One of the other reaons was to stop the stream of resources with wrong endings (because people kept thinking it was exclusive rather than inclusive) - and the resulting stream of additional patches to fix those errors. The legacy platforms do have those kinds of errors - when I converted SA11x0 as part of a previous patch set, I found a number suffering from this error. (Were any found in this patch set? I've not read through it.) I think if this becomes a small %age of the change to Samsung stuff, and Kukjin is happy with it, it should go in. Yes, agree. I will apply this whole series. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 05/10] ARM: Samsung: Update the device names for spi clock lookup
On 9 May 2012 16:52, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:49AM +0530, Thomas Abraham wrote: With the addition of platform specific driver data in the spi-s3c64xx driver, the device name of spi controllers are changed. Accordingly, update the device name of spi clocks instances. This should've been squashed into the patch that updated to use driver data in order to avoid breaking bisection. This patch updates clock devname in the platform code and the modifications to use driver data is in the driver file. So these two changes are kept separate to allow them to be applied to their respective trees. Thanks, Thomas. -- 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 10/10] spi: s3c64xx: add device tree support
On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as + the slave select line by the spi controller. The format of the gpio + specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Thanks, Thomas. -- 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 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
On 9 May 2012 18:55, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 11:10:14AM +0200, Heiko Stübner wrote: Similar to the adc and rtc driver, all Samsung platforms reuse a common platform-device definition for the s3c64xx-spi and simply will set the correct name when the machine type is determined during boot. Right, that doesn't mean this is a great way of doing things, though - it's been a frequent source of errors in the past and is painful to debug as the data structures get rewritten during boot which is a bit of a surprise. The alternative is creating a mulitude of platform devices for each possible machine type using this driver. Yes, that's the normal way of handling this and is actually what the code was originally doing - there's a bunch of ifdefed devices in plat-samsung/devs.c. You usually have to do this anyway as the IPs move about so the resources need changing. In addition to the setting the name, the platform data is also assigned at runtime. Adding multiple platform devices means that we add lot more code in setting up the platform data. And since we are moving towards adopting dt, these would anyway go away when we have all the platforms migrated to dt. Thanks, Thomas. -- 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 05/10] ARM: Samsung: Update the device names for spi clock lookup
On Wed, May 09, 2012 at 09:40:26PM +0800, Thomas Abraham wrote: On 9 May 2012 16:52, Mark Brown broo...@opensource.wolfsonmicro.com wrote: This should've been squashed into the patch that updated to use driver data in order to avoid breaking bisection. This patch updates clock devname in the platform code and the modifications to use driver data is in the driver file. So these two changes are kept separate to allow them to be applied to their respective trees. This means that bisection will be broken - anything with only one tree won't be able to load the SPI driver successfully until it's merged with the other which isn't ideal. signature.asc Description: Digital signature
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote: On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. I'd suggest just specifying the order - someone might want to use it later for some reason and it's not really a hardship for someone to use it. Avoids any how does that work? questions like I had. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as + the slave select line by the spi controller. The format of the gpio + specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. signature.asc Description: Digital signature
Re: [PATCH 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
On Wed, May 09, 2012 at 10:22:26PM +0800, Thomas Abraham wrote: On 9 May 2012 18:55, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Yes, that's the normal way of handling this and is actually what the code was originally doing - there's a bunch of ifdefed devices in plat-samsung/devs.c. You usually have to do this anyway as the IPs move about so the resources need changing. In addition to the setting the name, the platform data is also assigned at runtime. Adding multiple platform devices means that we add lot more code in setting up the platform data. And since we are moving towards adopting dt, these would anyway go away when we have all the platforms migrated to dt. With your refactoring the only platform data that's left is the /CS? signature.asc Description: Digital signature
Re: [PATCH 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function
On 9 May 2012 22:33, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 10:22:26PM +0800, Thomas Abraham wrote: On 9 May 2012 18:55, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Yes, that's the normal way of handling this and is actually what the code was originally doing - there's a bunch of ifdefed devices in plat-samsung/devs.c. You usually have to do this anyway as the IPs move about so the resources need changing. In addition to the setting the name, the platform data is also assigned at runtime. Adding multiple platform devices means that we add lot more code in setting up the platform data. And since we are moving towards adopting dt, these would anyway go away when we have all the platforms migrated to dt. With your refactoring the only platform data that's left is the /CS? The nCS line is not part of the platform data. It is part of the spi board info. There are three elements in the platform data after the re-factoring which is used on only non-dt platforms - (a) the clock source number to be selected as the bus clock in the spi controller's clock mux, (b) the number of nCS lines emulated by the controller and (c) the gpio setup callback function. With device tree, all this information is obtained from the device tree. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] regulator: add initial suport for max77686
This patch series adds support for max77686 which is a multifunction device which includes regulator (pmic), rtc and charger sub-blocks within it. The support for mfd driver and regulator driver are added by this patch series. This patch series also includes device tree and irqdomain support for mfd and regulator portions. Thanks, Yadwinder Singh -- 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/2] mfd: Add support for MAX77686.
From: Yadwinder Singh Brar yadi.b...@samsung.com
MAX77686 is a mulitifunction device with PMIC, RTC and Charger on chip. This
driver provides common support for accessing the device. This is initial
version of this driver that supports to enable the chip with its primary I2C
bus.It also includes IRQ and device tree support for MAX77686 chip.
Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
drivers/mfd/Kconfig | 19 ++
drivers/mfd/Makefile |1 +
drivers/mfd/max77686-irq.c | 258 +
drivers/mfd/max77686.c | 299 ++
include/linux/mfd/max77686-private.h | 279 +++
include/linux/mfd/max77686.h | 104
6 files changed, 960 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/max77686-irq.c
create mode 100644 drivers/mfd/max77686.c
create mode 100644 include/linux/mfd/max77686-private.h
create mode 100644 include/linux/mfd/max77686.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 11e4438..618bc42 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -441,6 +441,25 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MAX77686
+ bool Maxim Semiconductor MAX77686 PMIC Support
+ depends on I2C=y GENERIC_HARDIRQS
+ select MFD_CORE
+ help
+ Say yes here to support for Maxim Semiconductor MAX77686.
+ This is a Power Management IC with RTC on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
+config DEBUG_MAX77686
+ bool MAX77686 PMIC debugging
+ depends on MFD_MAX77686
+ help
+ Say yes, if you need enable debug messages in MFD_MAX77686 driver.
+ Further for enabling/disabling particular type of debug messages set
+ max77686_debug_mask accordingly.
+
config MFD_S5M_CORE
bool SAMSUNG S5M Series Support
depends on I2C=y GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 05fa538..19ecca9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -79,6 +79,7 @@ max8925-objs := max8925-core.o max8925-i2c.o
obj-$(CONFIG_MFD_MAX8925) += max8925.o
obj-$(CONFIG_MFD_MAX8997) += max8997.o max8997-irq.o
obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o
+obj-$(CONFIG_MFD_MAX77686) += max77686.o max77686-irq.o
pcf50633-objs := pcf50633-core.o pcf50633-irq.o
obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
diff --git a/drivers/mfd/max77686-irq.c b/drivers/mfd/max77686-irq.c
new file mode 100644
index 000..b40a46d
--- /dev/null
+++ b/drivers/mfd/max77686-irq.c
@@ -0,0 +1,258 @@
+/*
+ * max77686-irq.c - Interrupt controller support for MAX77686
+ *
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * Chiwoong Byun woong.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-irq.c
+ */
+
+#include linux/err.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/mfd/max77686.h
+#include linux/mfd/max77686-private.h
+#include linux/irqdomain.h
+
+#define IRQ_GRP (data-hwirq 3)
+#define IRQ_MASK (1 (data-hwirq 7))
+
+int max77686_debug_mask = MAX77686_DEBUG_INFO; /* enable debug prints */
+
+static const u8 max77686_mask_reg[] = {
+ [PMIC_INT1] = MAX77686_REG_INT1MSK,
+ [PMIC_INT2] = MAX77686_REG_INT2MSK,
+ [RTC_INT] = MAX77686_RTC_INTM,
+};
+
+static struct i2c_client *max77686_get_i2c(struct max77686_dev *max77686,
+ enum max77686_irq_source src)
+{
+ switch (src) {
+ case PMIC_INT1...PMIC_INT2:
+ return max77686-i2c;
+ case RTC_INT:
+ return max77686-rtc;
+ default:
+ return ERR_PTR(-EINVAL);
+ }
+}
+
+static void max77686_irq_lock(struct irq_data *data)
+{
+ struct max77686_dev *max77686 = irq_get_chip_data(data-irq);
+
+ mutex_lock(max77686-irqlock);
+}
+
+static void max77686_irq_sync_unlock(struct irq_data *data)
[PATCH 2/2] regulator: Add support for MAX77686.
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 driver
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 | 660 ++
3 files changed, 670 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/max77686.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 36db5a4..67162cc 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 94b5274..008931b 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..4aa9722
--- /dev/null
+++ b/drivers/regulator/max77686.c
@@ -0,0 +1,660 @@
+/*
+ * max77686.c - Regulator driver for the Maxim 77686
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * Chiwoong Byun woong.b...@smasung.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.*/
+};
+
+struct voltage_map_desc {
+ int min;
+ int max;
+ int step;
+ unsigned int n_bits;
+};
+
+/* Voltage maps in mV */
+static const struct voltage_map_desc ldo_voltage_map_desc = {
+ .min = 800, .max = 3950,.step = 50, .n_bits = 6,
+}; /* LDO3 ~ 5, 9 ~ 14, 16 ~ 26 */
+
+static const struct voltage_map_desc ldo_low_voltage_map_desc = {
+ .min = 800, .max = 2375,.step = 25, .n_bits = 6,
+}; /* LDO1 ~ 2, 6 ~ 8, 15 */
+
+static const struct voltage_map_desc buck_dvs_voltage_map_desc = {
+ .min = 60, .max = 3787500, .step = 12500, .n_bits = 8,
+}; /* Buck2, 3, 4 (uV) */
+
+static const struct voltage_map_desc buck_voltage_map_desc = {
+ .min = 750, .max = 3900,.step = 50, .n_bits = 6,
+}; /* Buck1, 5 ~ 9 */
+
+static const struct voltage_map_desc *reg_voltage_map[] = {
+ [MAX77686_LDO1] = ldo_low_voltage_map_desc,
+ [MAX77686_LDO2] = ldo_low_voltage_map_desc,
+ [MAX77686_LDO3] = ldo_voltage_map_desc,
+ [MAX77686_LDO4] = ldo_voltage_map_desc,
+ [MAX77686_LDO5] =
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote: On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. I'd suggest just specifying the order - someone might want to use it later for some reason and it's not really a hardship for someone to use it. Avoids any how does that work? questions like I had. Ok. I will add the order of the gpios as you have suggested. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as + the slave select line by the spi controller. The format of the gpio + specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. Ok. For this patch series, I will continue with the samsung specific binding for the nCS line. Thanks, Thomas. -- 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 10/10] spi: s3c64xx: add device tree support
On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote: On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. Ok. For this patch series, I will continue with the samsung specific binding for the nCS line. How about just renaming your binding to a generic one and documenting it separately? It looks like a sensible binding which other people should be able to use so may as well have something there already. signature.asc Description: Digital signature
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On 10 May 2012 00:47, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote: On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. Ok. For this patch series, I will continue with the samsung specific binding for the nCS line. How about just renaming your binding to a generic one and documenting it separately? It looks like a sensible binding which other people should be able to use so may as well have something there already. Ok. I will replace the samsung specific binding with a generic binding in the next version of this patch series. Thanks, Thomas. -- 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 05/10] ARM: Samsung: Update the device names for spi clock lookup
On 9 May 2012 22:28, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 09:40:26PM +0800, Thomas Abraham wrote: On 9 May 2012 16:52, Mark Brown broo...@opensource.wolfsonmicro.com wrote: This should've been squashed into the patch that updated to use driver data in order to avoid breaking bisection. This patch updates clock devname in the platform code and the modifications to use driver data is in the driver file. So these two changes are kept separate to allow them to be applied to their respective trees. This means that bisection will be broken - anything with only one tree won't be able to load the SPI driver successfully until it's merged with the other which isn't ideal. Yes, we would have that problem until the two trees are merged. But I still prefer not to squash the two patches which already contain huge diff. Thanks, Thomas. -- 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 0/2] regulator: add initial suport for max77686
On Wed, May 09, 2012 at 09:54:53PM +0530, Yadwinder Singh wrote: This patch series adds support for max77686 which is a multifunction device which includes regulator (pmic), rtc and charger sub-blocks within it. The support for mfd driver and regulator driver are added by this patch series. This patch series also includes device tree and irqdomain support for mfd and regulator portions. Always CC maintainers on patches, please see SubmittingPatches. -- 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/2] mfd: Add support for MAX77686.
On Wed, May 09, 2012 at 09:54:54PM +0530, Yadwinder Singh wrote:
+int max77686_read_reg(struct i2c_client *i2c, u8 reg, u8 *dest)
+{
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(i2c, reg);
+ if (ret 0)
It would really be better if this used the regmap API - the regulator
API is starting to build out functionality on top of regmap which this
won't be able to take advantage of if it doesn't use regmap.
+ if (of_get_property(dev-of_node, max77686,wakeup, NULL))
+ pd-wakeup = true;
You haven't included any binding documentatiojn for the device tree
bindings - you should do this.
+ max77686 = kzalloc(sizeof(struct max77686_dev), GFP_KERNEL);
+ if (max77686 == NULL) {
+ dev_err(max77686-dev, could not allocate memory\n);
+ return -ENOMEM;
+ }
devm_kzalloc().
+ device_init_wakeup(max77686-dev, max77686-wakeup);
Why is this not just done unconditionally? There's sysfs files to allow
userspace control.
+ if (max77686_read_reg(i2c, MAX77686_REG_DEVICE_ID, data) 0) {
+ ret = -EIO;
+ dbg_info(%s : device not found on this channel\n, __func__);
+ goto err_mfd;
+ } else
+ dev_info(max77686-dev, device found\n);
You should verify that the device ID you read back is the expected one.
+ dev_err(max77686-dev, device probe failed : %d\n, ret);
Driver core should do this for you.
--
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/2] regulator: Add support for MAX77686.
On Wed, May 09, 2012 at 09:54:55PM +0530, Yadwinder Singh wrote:
+/* Voltage maps in mV */
+static const struct voltage_map_desc ldo_voltage_map_desc = {
+ .min = 800, .max = 3950,.step = 50, .n_bits = 6,
+}; /* LDO3 ~ 5, 9 ~ 14, 16 ~ 26 */
Hrm, funnily enough I was just thinking about factoring this stuff out
into the core after a conversation with Graeme Gregory the other week.
Let's do that...
+ [MAX77686_EN32KHZ_AP] = NULL,
+ [MAX77686_EN32KHZ_CP] = NULL,
Now that the generic clock API is in mainline these should be moved over
to use it.
+static int max77686_get_voltage_unit(int rid)
+{
+ int unit = 0;
+
+ switch (rid) {
+ case MAX77686_BUCK2...MAX77686_BUCK4:
+ unit = 1; /* BUCK2,3,4 is uV */
+ break;
+ default:
+ unit = 1000;
Why not just list everything in uV?
+static int max77686_get_voltage(struct regulator_dev *rdev)
+{
Implement get_voltage_sel().
+static inline int max77686_get_voltage_proper_val(const struct
voltage_map_desc
+ *desc, int min_vol,
+ int max_vol)
+{
+ int i = 0;
+
+ if (desc == NULL)
+ return -EINVAL;
+
+ if (max_vol desc-min || min_vol desc-max)
+ return -EINVAL;
+
+ while (desc-min + desc-step * i min_vol
+desc-min + desc-step * i desc-max)
+ i++;
Why are you iterating here? Calculate! Though like I say let's factor
this out anyway.
+ if (rid == MAX77686_BUCK2 || rid == MAX77686_BUCK3 ||
+ rid == MAX77686_BUCK4) {
+ /* If the voltage is increasing */
+ if (org i)
+ udelay(DIV_ROUND_UP(desc-step * (i - org),
+ ramp[max77686-ramp_delay]));
+ }
Don't do this, implement set_voltage_time_sel().
+ .enable = max77686_reg_enable,
+ .disable = max77686_reg_disable,
+ .set_suspend_enable = max77686_reg_enable,
+ .set_suspend_disable = max77686_reg_disable,
You've got the same ops for suspend and non-suspend cases here, this is
clearly buggy.
+/* count the number of regulators to be supported in pmic */
+ pdata-num_regulators = 0;
Coding style.
+ if (iodev-dev-of_node) {
+ ret = max77686_pmic_dt_parse_pdata(iodev, pdata);
+ if (ret)
+ return ret;
This ought to use of_regulator_match().
+ }
+
+ if (!pdata) {
+ dev_err(pdev-dev, platform data not found\n);
+ return -ENODEV;
+ }
This should be totally fine.
+ max77686 = kzalloc(sizeof(struct max77686_data), GFP_KERNEL);
+ if (!max77686)
+ return -ENOMEM;
devm_kzalloc().
+ if (pdata-ramp_delay) {
+ max77686-ramp_delay = pdata-ramp_delay;
+ max77686_update_reg(i2c, MAX77686_REG_BUCK2CTRL1,
+ RAMP_VALUE, RAMP_MASK);
This appears not to actually use the value passed in as platform_data.
+
+ for (i = 0; i pdata-num_regulators; i++) {
+ const struct voltage_map_desc *desc;
+ int id = pdata-regulators[i].id;
+
+ desc = reg_voltage_map[id];
+ if (desc)
+ regulators[id].n_voltages =
+ (desc-max - desc-min) / desc-step + 1;
+
+ rdev[i] = regulator_register(regulators[id], max77686-dev,
+ pdata-regulators[i].initdata,
+ max77686, NULL);
No, you should unconditionally register all regulators the device
physically has. This is useful for debug and simplifies the code.
--
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/2] mfd: Add support for MAX77686.
Hi Mark,
We have posted following patch on the last week and received
your comment. So, We are implementing that use regmap API for I2C
and modify MFD driver of MAX77686 according to your comment.
[PATCH] MFD : add MAX77686 mfd driver
- https://lkml.org/lkml/2012/4/30/96
Additionally, We are intergrating support irq_domain for MAX77686 irq.
We will post new patch to support MFD driver of MAX77686 including
modification by your comment within this week.
Best Regards,
Chanwoo Choi
On 05/10/2012 03:27 AM, Mark Brown wrote:
On Wed, May 09, 2012 at 09:54:54PM +0530, Yadwinder Singh wrote:
+int max77686_read_reg(struct i2c_client *i2c, u8 reg, u8 *dest)
+{
+int ret;
+
+ret = i2c_smbus_read_byte_data(i2c, reg);
+if (ret 0)
It would really be better if this used the regmap API - the regulator
API is starting to build out functionality on top of regmap which this
won't be able to take advantage of if it doesn't use regmap.
+if (of_get_property(dev-of_node, max77686,wakeup, NULL))
+pd-wakeup = true;
You haven't included any binding documentatiojn for the device tree
bindings - you should do this.
+max77686 = kzalloc(sizeof(struct max77686_dev), GFP_KERNEL);
+if (max77686 == NULL) {
+dev_err(max77686-dev, could not allocate memory\n);
+return -ENOMEM;
+}
devm_kzalloc().
+device_init_wakeup(max77686-dev, max77686-wakeup);
Why is this not just done unconditionally? There's sysfs files to allow
userspace control.
+if (max77686_read_reg(i2c, MAX77686_REG_DEVICE_ID, data) 0) {
+ret = -EIO;
+dbg_info(%s : device not found on this channel\n, __func__);
+goto err_mfd;
+} else
+dev_info(max77686-dev, device found\n);
You should verify that the device ID you read back is the expected one.
+dev_err(max77686-dev, device probe failed : %d\n, ret);
Driver core should do this for you.
--
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
[PATCH] ARM: SAMSUNG: Fix for S3C2412 EBI memory mapping.
While upgrading the kernel on a S3C2412 based board I've noted that it was impossible to boot the board with a 2.6.32 or upper kernel. I've tracked down the problem to the EBI virtual memory mapping that is in conflict with the IO mapping definition in arch/arm/mach-s3c24xx/s3c2412.c. Signed-off-by: José Miguel Gonçalves jose.goncal...@inov.pt --- arch/arm/plat-samsung/include/plat/map-s3c.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-samsung/include/plat/map-s3c.h b/arch/arm/plat-samsung/include/plat/map-s3c.h index 7d04875..c0c70a8 100644 --- a/arch/arm/plat-samsung/include/plat/map-s3c.h +++ b/arch/arm/plat-samsung/include/plat/map-s3c.h @@ -22,7 +22,7 @@ #define S3C24XX_VA_WATCHDOGS3C_VA_WATCHDOG #define S3C2412_VA_SSMCS3C_ADDR_CPU(0x) -#define S3C2412_VA_EBI S3C_ADDR_CPU(0x0001) +#define S3C2412_VA_EBI S3C_ADDR_CPU(0x0010) #define S3C2410_PA_UART(0x5000) #define S3C24XX_PA_UARTS3C2410_PA_UART -- 1.7.5.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
