Re: [GIT PULL] omap fixes against v3.14-rc1
Hi, On Fri, Feb 14, 2014 at 08:44:31AM -0800, Tony Lindgren wrote: > The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: > > Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.14/fixes-against-rc1 Pulled. Looks like the following two snuck in that should maybe have been cleanups instead, but it's not worth respinning over: > Paul Bolle (2): > ARM: OMAP2+: Remove MACH_NOKIA_N800 > ARM: OMAP2+: Remove legacy macros for zoom platforms -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] devicetree: bindings: voltagedomain: add bindings for OMAP compatible SoCs
Add documentation for device tree description for basic voltage domain for Texas Instruments OMAP compatible SoC family of processors which controls both bias and supply voltage planes. Signed-off-by: Nishanth Menon --- .../bindings/power/voltdm/voltdm_omap.txt | 24 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt diff --git a/Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt b/Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt new file mode 100644 index 000..30cd3d2 --- /dev/null +++ b/Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt @@ -0,0 +1,24 @@ +Texas Instruments OMAP compatible voltage domain description + +This binding uses [1] and describes the voltage domain devices +typically used on Texas Instruments OMAP compatible SoC family of +processors. + +[1] Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt + +Required Properties: +- compatible: Should be one of: + "ti,omap-voltdm" - basic voltage domain controlling VDD and VBB +- vdd-supply: phandle to regulator controlling VDD supply +- vbb-supply: phandle to regulator controlling Body Bias supply + (Usually Adaptive Body Bias regulator) +- #voltdm-cells: shall be <0> + +Example: +voltage_domain_mpu: voltdm@1 { + compatible = "ti,omap-voltdm"; + #voltdm-cells = <0>; + + vdd-supply = <&vcc>; + vbb-supply = <&abb_mpu>; +}; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
From: Mike Turquette This patch provides helper functions for drivers that wish to scale voltage through the clock rate-change notifiers. The approach taken is that the user-driver(cpufreq/devfreq) do not care about the details of the OPP table, nor does it care about handling the voltage regulator directly. By using the clk notifier flags, we are able to sequence the operations in the right order. The current logic is heavily influenced by implementation done in cpufreq-cpu0. [n...@ti.com: Fixes in logic, and broken out from clk to allow building a generic voltagedomain solution independent of cpufreq] Signed-off-by: Nishanth Menon Signed-off-by: Mike Turquette --- drivers/power/Kconfig |1 + drivers/power/Makefile|1 + drivers/power/voltdm/Kconfig |7 ++ drivers/power/voltdm/Makefile |2 + drivers/power/voltdm/core.c | 195 + include/linux/pm_voltage_domain.h | 47 + 6 files changed, 253 insertions(+) create mode 100644 drivers/power/voltdm/Kconfig create mode 100644 drivers/power/voltdm/Makefile create mode 100644 drivers/power/voltdm/core.c create mode 100644 include/linux/pm_voltage_domain.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index ba69751..5c4fe16 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -394,3 +394,4 @@ source "drivers/power/reset/Kconfig" endif # POWER_SUPPLY source "drivers/power/avs/Kconfig" +source "drivers/power/voltdm/Kconfig" diff --git a/drivers/power/Makefile b/drivers/power/Makefile index ee54a3e..3d47072 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -58,3 +58,4 @@ obj-$(CONFIG_POWER_AVS) += avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o obj-$(CONFIG_POWER_RESET) += reset/ +obj-$(CONFIG_VOLTAGE_DOMAIN) += voltdm/ diff --git a/drivers/power/voltdm/Kconfig b/drivers/power/voltdm/Kconfig new file mode 100644 index 000..c5353bd --- /dev/null +++ b/drivers/power/voltdm/Kconfig @@ -0,0 +1,7 @@ +config VOLTAGE_DOMAIN + bool + depends on COMMON_CLK && OF && PM_OPP + default y if COMMON_CLK + ---help--- + Core voltage domain framework using common clock framework's + notifier mechanism. diff --git a/drivers/power/voltdm/Makefile b/drivers/power/voltdm/Makefile new file mode 100644 index 000..3fa4408 --- /dev/null +++ b/drivers/power/voltdm/Makefile @@ -0,0 +1,2 @@ +# Generic voltage domain +obj-$(CONFIG_VOLTAGE_DOMAIN) += core.o diff --git a/drivers/power/voltdm/core.c b/drivers/power/voltdm/core.c new file mode 100644 index 000..d0ed27e --- /dev/null +++ b/drivers/power/voltdm/core.c @@ -0,0 +1,195 @@ +/* + * Copyright (C) 2013 Linaro Ltd + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/ + * + * 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. + * + * Helper functions for registering clock rate-change notifier handlers + * that scale voltage when a clock changes its output frequency. + */ +#include +#include +#include +#include +#include +#include + +/** + * struct volt_scale_data - Internal structure to maintain notifier information + * @dev: device on behalf of which we register the notifier + * @clk: clk on which we registered the notifier + * @reg: regulator if any which is used for scaling voltage + * @tol: voltage tolerance in % + * @nb:notifier block pointer + */ +struct volt_scale_data { + struct device *dev; + struct clk *clk; + struct regulator *reg; + int tol; + struct notifier_block nb; +}; + +#define to_volt_scale_data(_nb) container_of(_nb, \ + struct volt_scale_data, nb) + +static int clk_volt_notifier_handler(struct notifier_block *nb, +unsigned long flags, void *data) +{ + struct clk_notifier_data *cnd = data; + struct volt_scale_data *vsd = to_volt_scale_data(nb); + int ret, volt, tol; + struct dev_pm_opp *opp; + unsigned long old_rate = cnd->old_rate; + unsigned long new_rate = cnd->new_rate; + + if ((new_rate < old_rate && flags == PRE_RATE_CHANGE) || + (new_rate > old_rate && flags == POST_RATE_CHANGE)) + return NOTIFY_OK; + + rcu_read_lock(); + if (flags != ABORT_RATE_CHANGE) + opp = dev_pm_opp_find_freq_ceil(vsd->dev, &new_rate); + else + opp = dev_pm_opp_find_freq_ceil(vsd->dev, &old_rate); + if (IS_ERR(opp)) { + rcu_read_unlock(); + dev_err(vsd->dev, "%s: Failed to find OPP for %lu\n", + __func__, new_rate); + return notifier_from_errno(PTR_ERR(opp)); + } + + volt = dev_pm_opp
[RFC PATCH 0/6] PM: introduce voltage domain abstraction
Hi, On many SoCs such as OMAP, hardware blocks are isolated into voltage domains allowing for individual tweaks for optimal power-performance tradeoffs. Frameworks such as cpufreq, devfreq provide a top level control of these hardware blocks. Most SoCs have different knobs to fine tune the voltages. They may supply multiple supplies to various voltage planes on the same voltage domains. Regulator framework provides us a with an appropriate representation of consumer model, however, we lack the abstraction necessary to isolate the necessary sequencing for a specific voltage domain. There has been few attempts previously taken such as [3] [4], this series is a further development of of Mike's series[1] where cpufreq-cpu0 driver was first targetted with clk notifiers. While I do understand the concerns Mike has in [2], this could be a base on which further work may be done. In a nutshell, this (for cpufreq-cpu0 as an example): maintains the legacy definitions used by cpufreq/devfreq such as: &cpu0 { cpu0-supply = <®ulator_x>; }; on other SoCs where this might turn out to be a more detailed implementation, &cpu0 { cpu0-voltdm = <&voltdm_x>; }; To enure this is split off from clk framework, I chose drivers/power/voltdm as the location for the new files, I'd love to hear opinions and suggestions on the approach. The series is based on 3.14-rc3 and is available here: https://github.com/nmenon/linux-2.6-playground/commits/push/voltdm-notifier-rfc A testing branch for Beagle-XM (OMAP3630 as testbed): https://github.com/nmenon/linux-2.6-playground/commits/testing/beagle-xm-voltdm-notifier-rfc Log: http://slexy.org/view/s20TgkN7kf NOTE: TI platforms potentially need further development, however, this forms the basis of the development. Mike Turquette (2): PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling cpufreq: cpufreq-cpu0: use clk rate-change notifiers Nishanth Menon (4): PM / Voltagedomain: introduce voltage domain driver support devicetree: bindings: add documentation for voltagedomain PM / Voltagedomain: introduce basic voltage domain support for OMAP devicetree: bindings: voltagedomain: add bindings for OMAP compatible SoCs .../bindings/power/voltdm/voltage_domain.txt | 65 +++ .../bindings/power/voltdm/voltdm_omap.txt | 24 + drivers/cpufreq/Kconfig|1 + drivers/cpufreq/cpufreq-cpu0.c | 140 ++ drivers/power/Kconfig |1 + drivers/power/Makefile |1 + drivers/power/voltdm/Kconfig | 19 + drivers/power/voltdm/Makefile |6 + drivers/power/voltdm/core.c| 508 drivers/power/voltdm/voltage_domain_private.h | 86 drivers/power/voltdm/voltdm_omap.c | 287 +++ include/linux/pm_voltage_domain.h | 47 ++ 12 files changed, 1086 insertions(+), 99 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt create mode 100644 Documentation/devicetree/bindings/power/voltdm/voltdm_omap.txt create mode 100644 drivers/power/voltdm/Kconfig create mode 100644 drivers/power/voltdm/Makefile create mode 100644 drivers/power/voltdm/core.c create mode 100644 drivers/power/voltdm/voltage_domain_private.h create mode 100644 drivers/power/voltdm/voltdm_omap.c create mode 100644 include/linux/pm_voltage_domain.h [1] https://lkml.org/lkml/2013/7/7/110 (original RFC) [2] http://marc.info/?l=linux-arm-kernel&m=137947787621572&w=2 (runtime pm should enable regulator) [3] http://marc.info/?t=13660311176&r=1&w=2 [4] http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/dvfs.c;hb=p-linux-omap-3.4 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/6] devicetree: bindings: add documentation for voltagedomain
Add documentation for voltage domain binding format. Specific voltage domains will have bindings corresponding to them. Signed-off-by: Nishanth Menon --- .../bindings/power/voltdm/voltage_domain.txt | 65 1 file changed, 65 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt diff --git a/Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt b/Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt new file mode 100644 index 000..da48a19 --- /dev/null +++ b/Documentation/devicetree/bindings/power/voltdm/voltage_domain.txt @@ -0,0 +1,65 @@ +Specifying Voltage Domain information for devices += + +1. Specifying a voltage domain. + +SoCs may have multiple voltage domains under which various clocks operate. + +Mandatory Properties: +- #voltdm-cells - indicates if there are specifiers needed to reference the + voltage domain + +Optional Properties: +- voltage-tolerance: Specify the voltage tolerance in percentage + +2. Voltage domain consumer +consumer nodes can be reference using the below binding: +- -voltdm: phandle to the voltage domain node. + +Examples: + +A. Voltage Domain controlling multiple regulator +voltage_domain_mpu: voltdm@1 { + compatible = "xyz"; + #voltdm-cells = <0>; + vdd-supply = <&vcc>; + vbb-supply = <&abb_mpu>; + ... +}; + +voltage_domain_gpu: voltdm@2 { + compatible = "xyz"; + #voltdm-cells = <0>; + vdd-supply = <&dcdc2>; + vbb-supply = <&abb_gpu>; + ... +}; +... +&cpu0 { + cpu0-voltdm = <&voltage_domain_mpu>; + voltage-tolerance = <1>; +}; + +&gpu { + gpu-voltdm = <&voltage_domain_gpu>; +}; + +B. Indexed voltage domain device + +#define SOC_XYZ_VOLTAGE_DOMAIN_MPU 0 +#define SOC_XYZ_VOLTAGE_DOMAIN_GFX 1 + +voltage_domain_socx: voltdm@1 { + compatible = "abc"; + #voltdm-cells = <1>; + ... +}; +... +&cpu0 { + cpu0-voltdm = <&voltage_domain_socx SOC_XYZ_VOLTAGE_DOMAIN_MPU>; + voltage-tolerance = <1>; +}; + +&gpu { + gpu-voltdm = <&voltage_domain_socx SOC_XYZ_VOLTAGE_DOMAIN_GFX>; +}; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
Many SoCs have basic concepts of voltage rails supplying a specific SoC device. These voltage rails may be as simple as a single regulator or complex to be three or more regulators that are transitioned in tandem with respect to clock changes. In some cases, they may tend to use custom frameworks to do the actual voltage transition OR use hardware modules that takes hints about the required configuration and does optimized voltage transitions. The current regulator model provides the basic building blocks for the transitions, however SoC drivers specific to each of these devices, be it cpufreq/devfreq have to replicate the logic for functionality. To simply the logic, we can hence introduce a layer that takes care of the mundane transition logic, registration mechanisms to provide the "user drivers" such as cpufreq/devfreq a generic interface, whose details are abstracted by the device tree description for the SoC on which the driver operates on. This allows us opportunity to make generic cpufreq / devfreq drivers which may deal with a single clock, however the actual voltage change mechanism can be customized specific to SoC without impact to the generic driver. Signed-off-by: Nishanth Menon --- drivers/power/voltdm/Kconfig |5 + drivers/power/voltdm/Makefile |3 + drivers/power/voltdm/core.c | 347 +++-- drivers/power/voltdm/voltage_domain_private.h | 86 ++ 4 files changed, 424 insertions(+), 17 deletions(-) create mode 100644 drivers/power/voltdm/voltage_domain_private.h diff --git a/drivers/power/voltdm/Kconfig b/drivers/power/voltdm/Kconfig index c5353bd..270fdab 100644 --- a/drivers/power/voltdm/Kconfig +++ b/drivers/power/voltdm/Kconfig @@ -5,3 +5,8 @@ config VOLTAGE_DOMAIN ---help--- Core voltage domain framework using common clock framework's notifier mechanism. + +menu "Voltage Domain Framework Drivers" + depends on VOLTAGE_DOMAIN + +endmenu diff --git a/drivers/power/voltdm/Makefile b/drivers/power/voltdm/Makefile index 3fa4408..fd32040 100644 --- a/drivers/power/voltdm/Makefile +++ b/drivers/power/voltdm/Makefile @@ -1,2 +1,5 @@ # Generic voltage domain obj-$(CONFIG_VOLTAGE_DOMAIN) += core.o + +# Hardware specific voltage domain +# please keep this section sorted lexicographically by file/directory path name diff --git a/drivers/power/voltdm/core.c b/drivers/power/voltdm/core.c index d0ed27e..69f6e81 100644 --- a/drivers/power/voltdm/core.c +++ b/drivers/power/voltdm/core.c @@ -10,12 +10,32 @@ * that scale voltage when a clock changes its output frequency. */ #include +#include #include #include #include #include #include +#include "voltage_domain_private.h" + +/** + * struct pm_voltdm_dev - internal representation of voltage domain devices + * @desc: voltage domain description + * @dev: voltage domain device + * @list: list to remaining voltage domain devices + * @lock: mutex to control data structure modifications and serialize ops + * @notifier_list: list of notifiers registered for this device + */ +struct pm_voltdm_dev { + const struct pm_voltdm_desc *desc; + struct device *dev; + struct list_head list; + /* list lock */ + struct mutex lock; + struct list_head notifier_list; +}; + /** * struct volt_scale_data - Internal structure to maintain notifier information * @dev: device on behalf of which we register the notifier @@ -23,6 +43,9 @@ * @reg: regulator if any which is used for scaling voltage * @tol: voltage tolerance in % * @nb:notifier block pointer + * @list: list head for the notifier + * @vdev: pointer to voltage domain device for this notifier + * @voltdm_data: voltdm driver specific data */ struct volt_scale_data { struct device *dev; @@ -30,23 +53,208 @@ struct volt_scale_data { struct regulator *reg; int tol; struct notifier_block nb; + struct list_head list; + + struct pm_voltdm_dev *vdev; + void *voltdm_data; }; #define to_volt_scale_data(_nb) container_of(_nb, \ struct volt_scale_data, nb) +static DEFINE_MUTEX(pm_voltdm_list_lock); +static LIST_HEAD(pm_voltdm_list); + +static inline bool voltmd_skip_check(struct pm_voltdm_dev *vdev) +{ + bool ret = false; + + if (vdev) { + const struct pm_voltdm_desc *desc; + + if (IS_ERR(vdev)) + return false; + + mutex_lock(&vdev->lock); + desc = vdev->desc; + + if (desc->flags & VOLTAGE_DOMAIN_FLAG_NOTIFY_ALL) + ret = true; + mutex_unlock(&vdev->lock); + } + + return ret; +} + +static inline int voltmd_scale_voltage(struct volt_scale_data *vsd, + unsigned long flags, int volt, int tol) +{ + int ret; + str
[RFC PATCH 2/6] cpufreq: cpufreq-cpu0: use clk rate-change notifiers
From: Mike Turquette Removes directly handling of OPP tables and voltage regulators by calling of_clk_cpufreq_notifier_handler, introduced by commit "clk: cpufreq helper for voltage scaling". In the future this can help consolidate code found across similar CPUfreq drivers. [n...@ti.com: updates to keep the OPP logic still in cpufreq-cpu0 - optimization to generalize that for cpufreq is to be done in a later series] Signed-off-by: Nishanth Menon Signed-off-by: Mike Turquette --- drivers/cpufreq/Kconfig|1 + drivers/cpufreq/cpufreq-cpu0.c | 140 2 files changed, 42 insertions(+), 99 deletions(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 4b029c0..70b07ab 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -187,6 +187,7 @@ config GENERIC_CPUFREQ_CPU0 tristate "Generic CPU0 cpufreq driver" depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL select PM_OPP + select VOLTAGE_DOMAIN help This adds a generic cpufreq driver for CPU0 frequency management. It supports both uniprocessor (UP) and symmetric multiprocessor (SMP) diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index 0c12ffc..32719d3 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -21,23 +21,20 @@ #include #include #include -#include +#include #include #include static unsigned int transition_latency; -static unsigned int voltage_tolerance; /* in percentage */ static struct device *cpu_dev; static struct clk *cpu_clk; -static struct regulator *cpu_reg; static struct cpufreq_frequency_table *freq_table; static struct thermal_cooling_device *cdev; +static struct notifier_block *clk_nb; static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index) { - struct dev_pm_opp *opp; - unsigned long volt = 0, volt_old = 0, tol = 0; unsigned int old_freq, new_freq; long freq_Hz, freq_exact; int ret; @@ -50,50 +47,14 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index) new_freq = freq_Hz / 1000; old_freq = clk_get_rate(cpu_clk) / 1000; - if (!IS_ERR(cpu_reg)) { - rcu_read_lock(); - opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_Hz); - if (IS_ERR(opp)) { - rcu_read_unlock(); - pr_err("failed to find OPP for %ld\n", freq_Hz); - return PTR_ERR(opp); - } - volt = dev_pm_opp_get_voltage(opp); - rcu_read_unlock(); - tol = volt * voltage_tolerance / 100; - volt_old = regulator_get_voltage(cpu_reg); - } - - pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n", -old_freq / 1000, volt_old ? volt_old / 1000 : -1, -new_freq / 1000, volt ? volt / 1000 : -1); - - /* scaling up? scale voltage before frequency */ - if (!IS_ERR(cpu_reg) && new_freq > old_freq) { - ret = regulator_set_voltage_tol(cpu_reg, volt, tol); - if (ret) { - pr_err("failed to scale voltage up: %d\n", ret); - return ret; - } - } + pr_debug("%u MHz --> %u MHz\n", old_freq / 1000, new_freq / 1000); ret = clk_set_rate(cpu_clk, freq_exact); if (ret) { pr_err("failed to set clock rate: %d\n", ret); - if (!IS_ERR(cpu_reg)) - regulator_set_voltage_tol(cpu_reg, volt_old, tol); return ret; } - /* scaling down? scale voltage after frequency */ - if (!IS_ERR(cpu_reg) && new_freq < old_freq) { - ret = regulator_set_voltage_tol(cpu_reg, volt, tol); - if (ret) { - pr_err("failed to scale voltage down: %d\n", ret); - clk_set_rate(cpu_clk, old_freq * 1000); - } - } - return ret; } @@ -117,33 +78,24 @@ static struct cpufreq_driver cpu0_cpufreq_driver = { static int cpu0_cpufreq_probe(struct platform_device *pdev) { struct device_node *np; + unsigned int voltage_latency; int ret; - cpu_dev = get_cpu_device(0); if (!cpu_dev) { - pr_err("failed to get cpu0 device\n"); - return -ENODEV; - } - - np = of_node_get(cpu_dev->of_node); - if (!np) { - pr_err("failed to find cpu0 node\n"); - return -ENOENT; - } + cpu_dev = get_cpu_device(0); + if (!cpu_dev) { + pr_err("failed to get cpu0 device\n"); + return -ENODEV; + } - cpu_reg = devm_regulator_get_optional(cpu_dev, "cpu0"); - if (IS_ERR(cpu_reg)) { - /* -
[RFC PATCH 5/6] PM / Voltagedomain: introduce basic voltage domain support for OMAP
OMAP platforms have multiple voltage domains, but each with consistent behavior of controlling the VDD (supply) and VBB(ABB/Bias voltage). These need to be sequenced in a specific order for functionality. Further optimization such as AVS(Adaptive Voltage Scaling), optimized voltages from efuse(Class0) can also be introduced based on this basic framework. This now allows reuse by voltage domain devices which may share the same voltage domain by allowing the regulator framework to maintain per consumer usage information. Signed-off-by: Nishanth Menon --- drivers/power/voltdm/Kconfig |7 + drivers/power/voltdm/Makefile |1 + drivers/power/voltdm/voltdm_omap.c | 287 3 files changed, 295 insertions(+) create mode 100644 drivers/power/voltdm/voltdm_omap.c diff --git a/drivers/power/voltdm/Kconfig b/drivers/power/voltdm/Kconfig index 270fdab..41bfbc3 100644 --- a/drivers/power/voltdm/Kconfig +++ b/drivers/power/voltdm/Kconfig @@ -9,4 +9,11 @@ config VOLTAGE_DOMAIN menu "Voltage Domain Framework Drivers" depends on VOLTAGE_DOMAIN +config VOLTAGE_DOMAIN_OMAP + tristate "TI OMAP Voltage domain driver" + ---help--- + Voltage domain support for OMAP platforms which need + vdd regulator and Adaptive Body Bias(ABB) regulator + support + endmenu diff --git a/drivers/power/voltdm/Makefile b/drivers/power/voltdm/Makefile index fd32040..e1cb50d 100644 --- a/drivers/power/voltdm/Makefile +++ b/drivers/power/voltdm/Makefile @@ -3,3 +3,4 @@ obj-$(CONFIG_VOLTAGE_DOMAIN)+= core.o # Hardware specific voltage domain # please keep this section sorted lexicographically by file/directory path name +obj-$(CONFIG_VOLTAGE_DOMAIN_OMAP) += voltdm_omap.o diff --git a/drivers/power/voltdm/voltdm_omap.c b/drivers/power/voltdm/voltdm_omap.c new file mode 100644 index 000..aacbdde --- /dev/null +++ b/drivers/power/voltdm/voltdm_omap.c @@ -0,0 +1,287 @@ +/* + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/ + * + * 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. + * + * Helper functions for registering clock rate-change notifier handlers + * that scale voltage when a clock changes its output frequency. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "voltage_domain_private.h" + +/** + * struct omap_voltdm_data - OMAP specific voltage domain data + * @vdd_reg: VDD regulator + * @vbb_reg: Body Bias regulator + */ +struct omap_voltdm_data { + struct regulator *vdd_reg; + struct regulator *vbb_reg; +}; + +/** + * omap_voltdm_do_transition() - do the voltage domain transition + * @dev: voltage domain device for which we are doing the transition + * @voltdm_data: data specific to the device + * @clk_notifier_flags:clk notifier flags for direction of transition + * @uv:what voltage to transition to + * @tol_uv:voltage tolerance to use + */ +static int omap_voltdm_do_transition(struct device *dev, +void *voltdm_data, +unsigned long clk_notifier_flags, int uv, +int tol_uv) +{ + struct omap_voltdm_data *data = (struct omap_voltdm_data *)voltdm_data; + int ret; + bool do_abb_first; + + /* We dont expect voltdm layer to make mistakes.. but still */ + BUG_ON(!data); + + do_abb_first = clk_notifier_flags == ABORT_RATE_CHANGE || + clk_notifier_flags == POST_RATE_CHANGE; + + if (do_abb_first) { + dev_dbg(dev, "vbb pre %duV[tol %duV]\n", uv, tol_uv); + ret = regulator_set_voltage_tol(data->vbb_reg, uv, tol_uv); + if (ret) { + dev_err(dev, + "vbb failed for voltage %duV[tol %duV]:%d\n", + uv, tol_uv, ret); + return ret; + } + } + + dev_dbg(dev, "vdd for voltage %duV[tol %duV]\n", uv, tol_uv); + ret = regulator_set_voltage_tol(data->vdd_reg, uv, tol_uv); + if (ret) { + dev_err(dev, + "vdd failed for voltage %duV[tol %duV]:%d\n", + uv, tol_uv, ret); + return ret; + } + + if (!do_abb_first) { + dev_dbg(dev, "vbb post %duV[tol %duV]\n", uv, tol_uv); + ret = regulator_set_voltage_tol(data->vbb_reg, uv, tol_uv); + if (ret) { + dev_err(dev, + "vbb failed for voltage %duV[tol %duV]:%d\n", + uv, tol_uv, ret); + return ret; + } + } + + return 0; +} + +/**
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
Hi, On Tue, Feb 18, 2014 at 09:30:21AM -0800, Greg KH wrote: > > > > > +static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue > > > > > *glue) > > > > > +{ > > > > > + struct dentry *root; > > > > > + struct dentry *file; > > > > > + char buf[128]; > > > > > + > > > > > + sprintf(buf, "%s.dsps", dev_name(musb->controller)); > > > > > + root = debugfs_create_dir(buf, NULL); > > > > > + if (!root) > > > > > > > > wrong, you should be using IS_ERR() > > > > > > !root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled. > > > > in that case, files will be created on parent directory right ? > > If, for some reason, creating a directory fails and then creating a file > would succeed, yes, that will happen. > > > If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in > > __create_file(). > > No, because -ENODEV will only happen if debugfs is not enabled, so no > dereference will ever happen. > > Don't worry about checking return values from debugfs, it shouldn't be > needed. aha, now I see. I missed the: 348 if (error) { 349 dentry = NULL; 350 simple_release_fs(&debugfs_mount, &debugfs_mount_count); 351 } in fs/debugfs/inode.c::__create_file(). I'll apply this patch in a few hours (randconfig running). cheers -- balbi signature.asc Description: Digital signature
OMAP baseline test results for v3.14-rc3
Here are some basic OMAP test results for Linux v3.14-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.14-rc3/20140217214814/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass ( 9/ 9): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som Build: zImage: Pass (13/13): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Boot to userspace: FAIL ( 1/12): 2430sdp skip ( 2/12): 5912osk, cmt3517 Pass ( 9/12): 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, 4460varsomom PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip retention via dynamic idle: FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off via dynamic idle: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom vmlinux object size (delta in bytes from test_v3.14-rc2 (b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed)): text data bsstotal kernel +9089 +2560+9345 omap1_defconfig +5085 +2880+5373 omap1_defconfig_1510innovator_only +4993 +2640+5257 omap1_defconfig_5912osk_only +8797439 +826332 +291072 +9914843 multi_v7_defconfig +5340 +3040+5644 omap2plus_defconfig +9164 +2880+9452 omap2plus_defconfig_2430sdp_only +4996 +2720+5268 omap2plus_defconfig_am33xx_only +5068 +3040+5372 omap2plus_defconfig_am43xx_only +9372 +2640+9636 omap2plus_defconfig_cpupm +5148 +2640+5412 omap2plus_defconfig_dra7xx_only +58100 +581 omap2plus_defconfig_n800_multi_omap2xxx +54900 +549 omap2plus_defconfig_n800_only_a +9372 +2560+9628 omap2plus_defconfig_no_pm +5276 +2560+5532 omap2plus_defconfig_omap2_4_only +5276 +2720+5548 omap2plus_defconfig_omap3_4_only +11048 +8960 +11944 omap2plus_defconfig_omap5_only +3880 -88 +300 rmk_omap3430_ldp_allnoconfig +44900 +449 rmk_omap3430_ldp_oldconfig +3880 -88 +300 rmk_omap4430_sdp_allnoconfig +3170 -64 +253 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.14-rc2 (b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed)) avail rsrvd high freed board kconfig -8k 8k . . 2430sdpomap2plus_defconfig -8k 8k . . 3517evmomap2plus_defconfig -8k 8k . . 3530es3beagle omap2plus_defconfig -8k 8k . . 3730beaglexm omap2plus_defconfig -8k 8k . . 37xxevmomap2plus_defconfig -8k 8k . . 4430es2panda omap2plus_defconfig -8k 8k . . 4460pandaesomap2plus_defconfig -8k 8k . . 4460varsomom omap2plus_defconfig -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only Have added a build config for multi_v7_defconfig. Not booting it yet on any boards. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 11:03:35AM -0600, Felipe Balbi wrote: > On Tue, Feb 18, 2014 at 08:59:11AM -0800, Greg KH wrote: > > On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote: > > > On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote: > > > > debugfs files to show the contents of important dsps registers. > > > > > > > > Signed-off-by: Markus Pargmann > > > > --- > > > > drivers/usb/musb/musb_dsps.c | 54 > > > > > > > > 1 file changed, 54 insertions(+) > > > > > > > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > > > > index 593d3c9..d0a97d6 100644 > > > > --- a/drivers/usb/musb/musb_dsps.c > > > > +++ b/drivers/usb/musb/musb_dsps.c > > > > @@ -46,6 +46,8 @@ > > > > #include > > > > #include > > > > > > > > +#include > > > > + > > > > #include "musb_core.h" > > > > > > > > static const struct of_device_id musb_dsps_of_match[]; > > > > @@ -137,6 +139,26 @@ struct dsps_glue { > > > > unsigned long last_timer;/* last timer data for each > > > > instance */ > > > > > > > > struct dsps_context context; > > > > + struct debugfs_regset32 regset; > > > > + struct dentry *dbgfs_root; > > > > +}; > > > > + > > > > +static const struct debugfs_reg32 dsps_musb_regs[] = { > > > > + { "revision", 0x00 }, > > > > + { "control",0x14 }, > > > > + { "status", 0x18 }, > > > > + { "eoi",0x24 }, > > > > + { "intr0_stat", 0x30 }, > > > > + { "intr1_stat", 0x34 }, > > > > + { "intr0_set", 0x38 }, > > > > + { "intr1_set", 0x3c }, > > > > + { "txmode", 0x70 }, > > > > + { "rxmode", 0x74 }, > > > > + { "autoreq",0xd0 }, > > > > + { "srpfixtime", 0xd4 }, > > > > + { "tdown", 0xd8 }, > > > > + { "phy_utmi", 0xe0 }, > > > > + { "mode", 0xe8 }, > > > > }; > > > > > > > > static void dsps_musb_try_idle(struct musb *musb, unsigned long > > > > timeout) > > > > @@ -369,6 +391,30 @@ out: > > > > return ret; > > > > } > > > > > > > > +static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue > > > > *glue) > > > > +{ > > > > + struct dentry *root; > > > > + struct dentry *file; > > > > + char buf[128]; > > > > + > > > > + sprintf(buf, "%s.dsps", dev_name(musb->controller)); > > > > + root = debugfs_create_dir(buf, NULL); > > > > + if (!root) > > > > > > wrong, you should be using IS_ERR() > > > > !root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled. > > in that case, files will be created on parent directory right ? If, for some reason, creating a directory fails and then creating a file would succeed, yes, that will happen. > If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in > __create_file(). No, because -ENODEV will only happen if debugfs is not enabled, so no dereference will ever happen. Don't worry about checking return values from debugfs, it shouldn't be needed. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 08:59:11AM -0800, Greg KH wrote: > On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote: > > On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote: > > > debugfs files to show the contents of important dsps registers. > > > > > > Signed-off-by: Markus Pargmann > > > --- > > > drivers/usb/musb/musb_dsps.c | 54 > > > > > > 1 file changed, 54 insertions(+) > > > > > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > > > index 593d3c9..d0a97d6 100644 > > > --- a/drivers/usb/musb/musb_dsps.c > > > +++ b/drivers/usb/musb/musb_dsps.c > > > @@ -46,6 +46,8 @@ > > > #include > > > #include > > > > > > +#include > > > + > > > #include "musb_core.h" > > > > > > static const struct of_device_id musb_dsps_of_match[]; > > > @@ -137,6 +139,26 @@ struct dsps_glue { > > > unsigned long last_timer;/* last timer data for each instance */ > > > > > > struct dsps_context context; > > > + struct debugfs_regset32 regset; > > > + struct dentry *dbgfs_root; > > > +}; > > > + > > > +static const struct debugfs_reg32 dsps_musb_regs[] = { > > > + { "revision", 0x00 }, > > > + { "control",0x14 }, > > > + { "status", 0x18 }, > > > + { "eoi",0x24 }, > > > + { "intr0_stat", 0x30 }, > > > + { "intr1_stat", 0x34 }, > > > + { "intr0_set", 0x38 }, > > > + { "intr1_set", 0x3c }, > > > + { "txmode", 0x70 }, > > > + { "rxmode", 0x74 }, > > > + { "autoreq",0xd0 }, > > > + { "srpfixtime", 0xd4 }, > > > + { "tdown", 0xd8 }, > > > + { "phy_utmi", 0xe0 }, > > > + { "mode", 0xe8 }, > > > }; > > > > > > static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout) > > > @@ -369,6 +391,30 @@ out: > > > return ret; > > > } > > > > > > +static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue) > > > +{ > > > + struct dentry *root; > > > + struct dentry *file; > > > + char buf[128]; > > > + > > > + sprintf(buf, "%s.dsps", dev_name(musb->controller)); > > > + root = debugfs_create_dir(buf, NULL); > > > + if (!root) > > > > wrong, you should be using IS_ERR() > > !root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled. in that case, files will be created on parent directory right ? If we pass a ERR_PTR(-ENODEV), otoh, we will try to dereference it in __create_file(). -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Tue, Feb 18, 2014 at 10:20:54AM -0600, Felipe Balbi wrote: > On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote: > > debugfs files to show the contents of important dsps registers. > > > > Signed-off-by: Markus Pargmann > > --- > > drivers/usb/musb/musb_dsps.c | 54 > > > > 1 file changed, 54 insertions(+) > > > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > > index 593d3c9..d0a97d6 100644 > > --- a/drivers/usb/musb/musb_dsps.c > > +++ b/drivers/usb/musb/musb_dsps.c > > @@ -46,6 +46,8 @@ > > #include > > #include > > > > +#include > > + > > #include "musb_core.h" > > > > static const struct of_device_id musb_dsps_of_match[]; > > @@ -137,6 +139,26 @@ struct dsps_glue { > > unsigned long last_timer;/* last timer data for each instance */ > > > > struct dsps_context context; > > + struct debugfs_regset32 regset; > > + struct dentry *dbgfs_root; > > +}; > > + > > +static const struct debugfs_reg32 dsps_musb_regs[] = { > > + { "revision", 0x00 }, > > + { "control",0x14 }, > > + { "status", 0x18 }, > > + { "eoi",0x24 }, > > + { "intr0_stat", 0x30 }, > > + { "intr1_stat", 0x34 }, > > + { "intr0_set", 0x38 }, > > + { "intr1_set", 0x3c }, > > + { "txmode", 0x70 }, > > + { "rxmode", 0x74 }, > > + { "autoreq",0xd0 }, > > + { "srpfixtime", 0xd4 }, > > + { "tdown", 0xd8 }, > > + { "phy_utmi", 0xe0 }, > > + { "mode", 0xe8 }, > > }; > > > > static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout) > > @@ -369,6 +391,30 @@ out: > > return ret; > > } > > > > +static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue) > > +{ > > + struct dentry *root; > > + struct dentry *file; > > + char buf[128]; > > + > > + sprintf(buf, "%s.dsps", dev_name(musb->controller)); > > + root = debugfs_create_dir(buf, NULL); > > + if (!root) > > wrong, you should be using IS_ERR() !root is fine, IS_ERR() will fail if CONFIG_DEBUGFS is not enabled. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usb: musb: dsps, debugfs files
On Fri, Jan 17, 2014 at 10:22:35AM +0100, Markus Pargmann wrote: > debugfs files to show the contents of important dsps registers. > > Signed-off-by: Markus Pargmann > --- > drivers/usb/musb/musb_dsps.c | 54 > > 1 file changed, 54 insertions(+) > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > index 593d3c9..d0a97d6 100644 > --- a/drivers/usb/musb/musb_dsps.c > +++ b/drivers/usb/musb/musb_dsps.c > @@ -46,6 +46,8 @@ > #include > #include > > +#include > + > #include "musb_core.h" > > static const struct of_device_id musb_dsps_of_match[]; > @@ -137,6 +139,26 @@ struct dsps_glue { > unsigned long last_timer;/* last timer data for each instance */ > > struct dsps_context context; > + struct debugfs_regset32 regset; > + struct dentry *dbgfs_root; > +}; > + > +static const struct debugfs_reg32 dsps_musb_regs[] = { > + { "revision", 0x00 }, > + { "control",0x14 }, > + { "status", 0x18 }, > + { "eoi",0x24 }, > + { "intr0_stat", 0x30 }, > + { "intr1_stat", 0x34 }, > + { "intr0_set", 0x38 }, > + { "intr1_set", 0x3c }, > + { "txmode", 0x70 }, > + { "rxmode", 0x74 }, > + { "autoreq",0xd0 }, > + { "srpfixtime", 0xd4 }, > + { "tdown", 0xd8 }, > + { "phy_utmi", 0xe0 }, > + { "mode", 0xe8 }, > }; > > static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout) > @@ -369,6 +391,30 @@ out: > return ret; > } > > +static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue) > +{ > + struct dentry *root; > + struct dentry *file; > + char buf[128]; > + > + sprintf(buf, "%s.dsps", dev_name(musb->controller)); > + root = debugfs_create_dir(buf, NULL); > + if (!root) wrong, you should be using IS_ERR() -- balbi signature.asc Description: Digital signature
Re: [PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
> Use a meaningful name for the reference clocks so that it indicates the > function. > > CC: Lee Jones > CC: Samuel Ortiz > Signed-off-by: Roger Quadros > --- > drivers/mfd/omap-usb-host.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c > index 60a3bed..ce620a8 100644 > --- a/drivers/mfd/omap-usb-host.c > +++ b/drivers/mfd/omap-usb-host.c > @@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device > *pdev) > goto err_mem; > } > > -omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck"); > +omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1"); > >>> > >>> You can't do that. These changes will have to be in the same patch as > >>> the core change i.e. where they are initialised. > >> > >> I'm not touching them anywhere in this series. When core changes are you > >> referring to? > > > > The ones in: > > arch/arm/mach-omap2/cclock3xxx_data.c > > OK, right. They are now no longer needed so I'll get rid of them. > In fact that change should either be in a separate patch or combined with > PATCH 2 > in this series. What do you suggest? A separate patch will do fine. > if (IS_ERR(omap->xclk60mhsp1_ck)) { > ret = PTR_ERR(omap->xclk60mhsp1_ck); > dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret); > goto err_mem; > } > > -omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck"); > +omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2"); > if (IS_ERR(omap->xclk60mhsp2_ck)) { > ret = PTR_ERR(omap->xclk60mhsp2_ck); > dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret); > goto err_mem; > } > > -omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk"); > +omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int"); > if (IS_ERR(omap->init_60m_fclk)) { > ret = PTR_ERR(omap->init_60m_fclk); > dev_err(dev, "init_60m_fclk failed error:%d\n", ret); > >>> > >> > > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
On 02/14/2014 03:33 PM, Lee Jones wrote: Use a meaningful name for the reference clocks so that it indicates the function. CC: Lee Jones CC: Samuel Ortiz Signed-off-by: Roger Quadros --- drivers/mfd/omap-usb-host.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 60a3bed..ce620a8 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev) goto err_mem; } - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck"); + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1"); >>> >>> You can't do that. These changes will have to be in the same patch as >>> the core change i.e. where they are initialised. >> >> I'm not touching them anywhere in this series. When core changes are you >> referring to? > > The ones in: > arch/arm/mach-omap2/cclock3xxx_data.c OK, right. They are now no longer needed so I'll get rid of them. In fact that change should either be in a separate patch or combined with PATCH 2 in this series. What do you suggest? cheers, -roger > if (IS_ERR(omap->xclk60mhsp1_ck)) { ret = PTR_ERR(omap->xclk60mhsp1_ck); dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret); goto err_mem; } - omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck"); + omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2"); if (IS_ERR(omap->xclk60mhsp2_ck)) { ret = PTR_ERR(omap->xclk60mhsp2_ck); dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret); goto err_mem; } - omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk"); + omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int"); if (IS_ERR(omap->init_60m_fclk)) { ret = PTR_ERR(omap->init_60m_fclk); dev_err(dev, "init_60m_fclk failed error:%d\n", ret); >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Hi Igor, On Tuesday 18 February 2014 16:03:44 Igor Grinberg wrote: > On 02/18/14 14:47, Laurent Pinchart wrote: > > On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote: > >> The camera sensor will soon require regulators and clocks. Register > >> fixed regulators for its VAA and VDD power supplies and a fixed rate > >> clock for its master clock. > > > > This patch is a prerequisite for a set of 4 patches that need to go > > through the linux-media tree. It would simpler if it could go through the > > same tree as well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen > > very little activity recently I believe the risk of conflict is pretty > > low. > > Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped > updating the board-cm-t35.c file. DT support for the OMAP3 ISP is coming. Too slowly, but it's coming :-) > > Tony, would > > that be fine with you ? > > > >> Signed-off-by: Laurent Pinchart > > Acked-by: Igor Grinberg Thank you. Tony, could I get your ack as well to push this through Mauro's tree ? > >> --- > >> > >> arch/arm/mach-omap2/board-cm-t35.c | 16 > >> 1 file changed, 16 insertions(+) > >> > >> diff --git a/arch/arm/mach-omap2/board-cm-t35.c > >> b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644 > >> --- a/arch/arm/mach-omap2/board-cm-t35.c > >> +++ b/arch/arm/mach-omap2/board-cm-t35.c > >> @@ -16,6 +16,8 @@ > >> > >> * > >> */ > >> > >> +#include > >> +#include > >> > >> #include > >> #include > >> #include > >> > >> @@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = { > >> > >>.subdevs = cm_t35_isp_subdevs, > >> > >> }; > >> > >> +static struct regulator_consumer_supply cm_t35_camera_supplies[] = { > >> + REGULATOR_SUPPLY("vaa", "3-005d"), > >> + REGULATOR_SUPPLY("vdd", "3-005d"), > >> +}; > >> + > >> > >> static void __init cm_t35_init_camera(void) > >> { > >> > >> + struct clk *clk; > >> + > >> + clk = clk_register_fixed_rate(NULL, "mt9t001-clkin", NULL, CLK_IS_ROOT, > >> +4800); > >> + clk_register_clkdev(clk, NULL, "3-005d"); > >> + > >> + regulator_register_fixed(2, cm_t35_camera_supplies, > >> + ARRAY_SIZE(cm_t35_camera_supplies)); > >> + > >> > >>if (omap3_init_camera(&cm_t35_isp_pdata) < 0) > >> > >>pr_warn("CM-T3x: Failed registering camera device!\n"); > >> > >> } -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller
On Friday 14 February 2014 11:15 AM, Nishanth Menon wrote: When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers. Platforms such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by this. Provide a new compatible property "ti,omap3-pre-es3-hsmmc" to allow driver to determine if driver needs to implement quirks associated with the specific module version (primarily because the IP revision information is not sufficient for the same). Signed-off-by: Nishanth Menon looks good to me Acked-by: Balaji T K --- Changes since v1: - new compatible flag as suggested by Tony which contains the relevant controller flag to work around the erratum V1: https://patchwork.kernel.org/patch/3514851/ .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 + drivers/mmc/host/omap_hsmmc.c | 26 +--- 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ce80561 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -10,6 +10,7 @@ Required properties: - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers + Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers - ti,hwmods: Must be "mmc", n is controller instance starting 1 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 575f9cc..390f421 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -192,6 +192,11 @@ struct omap_hsmmc_host { struct omap_mmc_platform_data *pdata; }; +struct omap_mmc_of_data { + u32 reg_offset; + u8 controller_flags; +}; + static int omap_hsmmc_card_detect(struct device *dev, int slot) { struct omap_hsmmc_host *host = dev_get_drvdata(dev); @@ -1678,18 +1683,29 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc) #endif #ifdef CONFIG_OF -static u16 omap4_reg_offset = 0x100; +static const struct omap_mmc_of_data omap3_pre_es3_mmc_of_data = { + /* See 35xx errata 2.1.1.128 in SPRZ278F */ + .controller_flags = OMAP_HSMMC_BROKEN_MULTIBLOCK_READ, +}; + +static const struct omap_mmc_of_data omap4_mmc_of_data = { + .reg_offset = 0x100, +}; static const struct of_device_id omap_mmc_of_match[] = { { .compatible = "ti,omap2-hsmmc", }, { + .compatible = "ti,omap3-pre-es3-hsmmc", + .data = &omap3_pre_es3_mmc_of_data, + }, + { .compatible = "ti,omap3-hsmmc", }, { .compatible = "ti,omap4-hsmmc", - .data = &omap4_reg_offset, + .data = &omap4_mmc_of_data, }, {}, }; @@ -1759,6 +1775,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev) dma_cap_mask_t mask; unsigned tx_req, rx_req; struct pinctrl *pinctrl; + const struct omap_mmc_of_data *data; match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev); if (match) { @@ -1768,8 +1785,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev) return PTR_ERR(pdata); if (match->data) { - const u16 *offsetp = match->data; - pdata->reg_offset = *offsetp; + data = match->data; + pdata->reg_offset = data->reg_offset; + pdata->controller_flags |= data->controller_flags; } } -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: support more DT properties
On Monday 17 February 2014 05:06 PM, Daniel Mack wrote: This should probably be done implicitly through mmc_of_parse(), but that doesn't play well along with the multi-slot model the hsmmc driver features. Hence, for now, do it manually. The properties are already documented in Documentation/devicetree/bindings/mmc/mmc.txt. Signed-off-by: Daniel Mack looks good to me Acked-by: Balaji T K --- drivers/mmc/host/omap_hsmmc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2815de6..a5a38cc 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev) if (of_find_property(np, "ti,needs-special-hs-handling", NULL)) pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT; + if (of_find_property(np, "keep-power-in-suspend", NULL)) + pdata->slots[0].pm_caps |= MMC_PM_KEEP_POWER; + + if (of_find_property(np, "enable-sdio-wakeup", NULL)) + pdata->slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ; + return pdata; } #else -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Hi Laurent, On 02/18/14 14:47, Laurent Pinchart wrote: > Mauro, Tony, > > On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote: >> The camera sensor will soon require regulators and clocks. Register >> fixed regulators for its VAA and VDD power supplies and a fixed rate >> clock for its master clock. > > This patch is a prerequisite for a set of 4 patches that need to go through > the linux-media tree. It would simpler if it could go through the same tree > as > well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen very little > activity recently I believe the risk of conflict is pretty low. Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped updating the board-cm-t35.c file. > Tony, would > that be fine with you ? > >> Signed-off-by: Laurent Pinchart Acked-by: Igor Grinberg >> --- >> arch/arm/mach-omap2/board-cm-t35.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/arch/arm/mach-omap2/board-cm-t35.c >> b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644 >> --- a/arch/arm/mach-omap2/board-cm-t35.c >> +++ b/arch/arm/mach-omap2/board-cm-t35.c >> @@ -16,6 +16,8 @@ >> * >> */ >> >> +#include >> +#include >> #include >> #include >> #include >> @@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = { >> .subdevs = cm_t35_isp_subdevs, >> }; >> >> +static struct regulator_consumer_supply cm_t35_camera_supplies[] = { >> +REGULATOR_SUPPLY("vaa", "3-005d"), >> +REGULATOR_SUPPLY("vdd", "3-005d"), >> +}; >> + >> static void __init cm_t35_init_camera(void) >> { >> +struct clk *clk; >> + >> +clk = clk_register_fixed_rate(NULL, "mt9t001-clkin", NULL, CLK_IS_ROOT, >> + 4800); >> +clk_register_clkdev(clk, NULL, "3-005d"); >> + >> +regulator_register_fixed(2, cm_t35_camera_supplies, >> + ARRAY_SIZE(cm_t35_camera_supplies)); >> + >> if (omap3_init_camera(&cm_t35_isp_pdata) < 0) >> pr_warn("CM-T3x: Failed registering camera device!\n"); >> } > -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Mauro, Tony, On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote: > The camera sensor will soon require regulators and clocks. Register > fixed regulators for its VAA and VDD power supplies and a fixed rate > clock for its master clock. This patch is a prerequisite for a set of 4 patches that need to go through the linux-media tree. It would simpler if it could go through the same tree as well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen very little activity recently I believe the risk of conflict is pretty low. Tony, would that be fine with you ? > Signed-off-by: Laurent Pinchart > --- > arch/arm/mach-omap2/board-cm-t35.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/arm/mach-omap2/board-cm-t35.c > b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644 > --- a/arch/arm/mach-omap2/board-cm-t35.c > +++ b/arch/arm/mach-omap2/board-cm-t35.c > @@ -16,6 +16,8 @@ > * > */ > > +#include > +#include > #include > #include > #include > @@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = { > .subdevs = cm_t35_isp_subdevs, > }; > > +static struct regulator_consumer_supply cm_t35_camera_supplies[] = { > + REGULATOR_SUPPLY("vaa", "3-005d"), > + REGULATOR_SUPPLY("vdd", "3-005d"), > +}; > + > static void __init cm_t35_init_camera(void) > { > + struct clk *clk; > + > + clk = clk_register_fixed_rate(NULL, "mt9t001-clkin", NULL, CLK_IS_ROOT, > + 4800); > + clk_register_clkdev(clk, NULL, "3-005d"); > + > + regulator_register_fixed(2, cm_t35_camera_supplies, > + ARRAY_SIZE(cm_t35_camera_supplies)); > + > if (omap3_init_camera(&cm_t35_isp_pdata) < 0) > pr_warn("CM-T3x: Failed registering camera device!\n"); > } -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] OMAPDSS: use DISPC register to detect context loss
On Friday 14 February 2014 01:59 PM, Tomi Valkeinen wrote: Instead of relying on the OMAP specific omap_pm_get_dev_context_loss_count() to detect register context loss, we can achieve the same in a much simpler way by just observing the DISPC registers. We always set DISPC's load mode to LOAD_FRAME_ONLY, which is not the reset value. Thus we can just observe the load mode to see if we have lost register context. Nice trick :p Reviewed-by: Archit Taneja Archit Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/dispc.c | 24 +++- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index bbeb8dd7f108..1659aa912d2b 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -100,8 +100,6 @@ static struct { struct platform_device *pdev; void __iomem*base; - int ctx_loss_cnt; - int irq; unsigned long core_clk_rate; @@ -357,29 +355,20 @@ static void dispc_save_context(void) if (dss_has_feature(FEAT_CORE_CLK_DIV)) SR(DIVISOR); - dispc.ctx_loss_cnt = dss_get_ctx_loss_count(); dispc.ctx_valid = true; - DSSDBG("context saved, ctx_loss_count %d\n", dispc.ctx_loss_cnt); + DSSDBG("context saved\n"); } static void dispc_restore_context(void) { - int i, j, ctx; + int i, j; DSSDBG("dispc_restore_context\n"); if (!dispc.ctx_valid) return; - ctx = dss_get_ctx_loss_count(); - - if (ctx >= 0 && ctx == dispc.ctx_loss_cnt) - return; - - DSSDBG("ctx_loss_count: saved %d, current %d\n", - dispc.ctx_loss_cnt, ctx); - /*RR(IRQENABLE);*/ /*RR(CONTROL);*/ RR(CONFIG); @@ -3768,6 +3757,15 @@ static int dispc_runtime_suspend(struct device *dev) static int dispc_runtime_resume(struct device *dev) { + /* +* The reset value for load mode is 0 (OMAP_DSS_LOAD_CLUT_AND_FRAME) +* but we always initialize it to 2 (OMAP_DSS_LOAD_FRAME_ONLY) in +* _omap_dispc_initial_config(). We can thus use it to detect if +* we have lost register context. +*/ + if (REG_GET(DISPC_CONFIG, 2, 1) == OMAP_DSS_LOAD_FRAME_ONLY) + return 0; + _omap_dispc_initial_config(); dispc_restore_context(); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM/dts: hdmi-codec: panda/es dt entries
HDMI codec dummy entries for Panda/ES. Signed-off-by: Paolo Pisati --- Depends on "0f7f3d1 ASoC: hdmi-codec: Add devicetree binding with documentation", eligible for a 3.14-rcX fix. arch/arm/boot/dts/omap4-panda-common.dtsi |9 - arch/arm/boot/dts/omap4-panda-es.dts |3 ++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..f4aeaa1 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -36,9 +36,15 @@ }; }; + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; + sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; + ti,audio-codec = <&hdmi_audio>; ti,mclk-freq = <3840>; @@ -57,7 +63,8 @@ "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* HS USB Port 1 Power */ diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 816d1c9..70152d6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -23,7 +23,8 @@ "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* PandaboardES has external pullups on SCL & SDA */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
On Saturday 15 February 2014 01:51 AM, Mark Brown wrote: On Thu, Feb 06, 2014 at 11:20:13AM +0530, Keerthy wrote: This patch adds support for TPS65218 PMIC regulators. The regulators set consists of 6 DCDCs and 1 LDO. The output voltages are configurable and are meant to supply power to the main processor and other components. Applied, thanks. Please use subject lines consistent with the subsystem. Sure. Thanks a lot Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP capabilities, resizer
Hello, > > * I have a test program, http://pmeerw.net/scaler.c, which exercises the > > OMAP3 ISP resizer standalone with the pipeline given below; it crashes the > > system quite reliably on 3.7 and recent kernels :( > > > > the reason for the crash is that the ISP resizer can still be busy and > > doesn't like to be turned off then; a little sleep before > > omap3isp_sbl_disable() helps (or waiting for the ISP resize to become > > idle, see the patch below) > > > > I'm not sure what omap3isp_module_sync_idle() is supposed to do, it > > immediately returns since we are in SINGLESHOT mode and > > isp_pipeline_ready() is false > > The function is supposed to wait until the module becomes idle. I'm not sure > why we don't call it for memory-to-memory pipelines, I need to investigate > that. Sakari, do you remember what we've done there ? > > > with below patch I am happily resizing... > > > > // snip, RFC > > From: Peter Meerwald > > Date: Wed, 12 Feb 2014 15:59:20 +0100 > > Subject: [PATCH] omap3isp: Wait for resizer to become idle before > > disabling > > > > --- > > drivers/media/platform/omap3isp/ispresizer.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/media/platform/omap3isp/ispresizer.c > > b/drivers/media/platform/omap3isp/ispresizer.c > > index d11fb26..fea98f7 100644 > > --- a/drivers/media/platform/omap3isp/ispresizer.c > > +++ b/drivers/media/platform/omap3isp/ispresizer.c > > @@ -1145,6 +1145,7 @@ static int resizer_set_stream(struct v4l2_subdev *sd, > > int enable) struct isp_video *video_out = &res->video_out; > > struct isp_device *isp = to_isp_device(res); > > struct device *dev = to_device(res); > > + unsigned long timeout = 0; > > > > if (res->state == ISP_PIPELINE_STREAM_STOPPED) { > > if (enable == ISP_PIPELINE_STREAM_STOPPED) > > @@ -1176,6 +1177,15 @@ static int resizer_set_stream(struct v4l2_subdev *sd, > > int enable) if (omap3isp_module_sync_idle(&sd->entity, &res->wait, > > &res->stopping)) > > dev_dbg(dev, "%s: module stop timeout.\n", > > sd->name); > > + > > + while (omap3isp_resizer_busy(res)) { > > + if (timeout++ > 1000) { > > + dev_alert(isp->dev, "ISP resizer does not > > become idle\n"); > > + return -ETIMEDOUT; > > + } > > + udelay(100); > > + } > > + > > Let's try to avoid busy loops if possible. Does it help if you comment out > the > condition at the top of omap3isp_module_sync_idle() ? > > > omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_RESIZER_READ | > > OMAP3_ISP_SBL_RESIZER_WRITE); > > omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_RESIZER); tried without the check at the top of omap3isp_module_sync_idle() I am not sure yet when and how many interrupts occur in memory-to-memory (singleshot) mode... and the code might be racy: if the resizer is done, we don't want to wait for another interrupt which might never happen; if the resizer is not done (how do we know?), we need to test that and set the stopping flag so that omap3isp_module_sync_is_stopping() wakes us when done omap3isp_module_sync_idle(): if (pipe->stream_state == ISP_PIPELINE_STREAM_STOPPED || (0 && pipe->stream_state == ISP_PIPELINE_STREAM_SINGLESHOT && !isp_pipeline_ready(pipe))) return 0; isp_pipeline_ready() seems to be the wrong check for resizer done; the final interrupt could occur here, before setting 'stopping' /* * atomic_set() doesn't include memory barrier on ARM platform for SMP * scenario. We'll call it here to avoid race conditions. */ atomic_set(stopping, 1); regards, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html