Re: FIX ME in omap-cpufreq.c
On 12/04/2014 10:30 PM, Viresh Kumar wrote: On 4 December 2014 at 23:13, nick xerofo...@gmail.com wrote: Greetings Kevin and the other maintainers of this file, Hi, I am wondering why the below code still has a fix me? It seems rather trivial to fix, as all we need is the transition time of the CPU. Due to this and I don't have the hardware do any of you have the hardware, can any of you tell me the correct value for this if you have this hardware. Further more I will paste the code below. Not every FIXME wants to get fixed. Believe me. Don't just grep for FIXME's in kernel and send patches for that. It isn't working anymore Nick. I understand that you want to get some name for yourself in the kernel community (and for sure there is nothing wrong in that), but the way you have chosen isn't taking you there. People aren't really happy with the way things are proceeding. If you really want to help kernel (and yourself), start getting deeper knowledge of frameworks you have any idea of. And they try to solve some real problems. I don't want to discourage you here, but trying to show the right path. Rest is upon you :) by the way, the file is redundant once we get omap3 platforms to be DT only and will be deleted. It is meant only for legacy boot for OMAP3 at the moment. -- Regards, Nishanth Menon -- 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] tty: serial: serial-omap: depend on !8250_omap
On Mon, 1 Dec 2014 19:51:18 -0600 Felipe Balbi ba...@ti.com wrote: On Tue, Dec 02, 2014 at 01:13:38AM +0200, Aaro Koskinen wrote: Hi, On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote: Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make serial-omap.c transparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of my serial port stopped working questions again. Thata a udev problem not a kernel one surely. People also use serial console to observe the early kernel boot before the userspace is started. right, we need a way to tell the kernel that ttyO%d and ttyS%d are the exact same device so that console=ttyO0 and console=ttyS0 mean the same thing. That maintains backwards compatibility and lets people move on Yes.. and that possibly also means a temporary char driver that claims ttyO* and simply redirects the calls into the tty. -- 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
regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
next-20141204 fails to boot, but next-20141203 boots fine with omap2plus_defconfig. Panda-ES(4460): https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt Panda(4430): https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt at the point of hang (JTAG): pandaboard-es: cpu0: http://slexy.org/view/s2eIFqkRd5 cpu1: http://slexy.org/view/s2Tysb6gpL Case #1: Disabling CPUIDLE allows boot to proceed. there does not seem to have been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this. Case #2: Reverting the following allows boot. From next-20141204 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings revert this - boot still fails d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL revert this - boot still fails 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C revert this - boot still fails c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like revert this - boot passed (first bad commit). -- Regards, Nishanth Menon -- 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: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On 12/05/2014 10:10 AM, Nishanth Menon wrote: next-20141204 fails to boot, but next-20141203 boots fine with omap2plus_defconfig. Panda-ES(4460): https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt Panda(4430): https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt at the point of hang (JTAG): pandaboard-es: cpu0: http://slexy.org/view/s2eIFqkRd5 cpu1: http://slexy.org/view/s2Tysb6gpL Case #1: Disabling CPUIDLE allows boot to proceed. there does not seem to have been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this. Case #2: Reverting the following allows boot. From next-20141204 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings revert this - boot still fails d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL revert this - boot still fails 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C revert this - boot still fails c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like revert this - boot passed (first bad commit). + linux-samsung soc and updated Thomaz's mail ID (gmail now). -- Regards, Nishanth Menon -- 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: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On Fri, Dec 05, 2014 at 10:13:51AM -0600, Nishanth Menon wrote: On 12/05/2014 10:10 AM, Nishanth Menon wrote: Case #2: Reverting the following allows boot. From next-20141204 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings revert this - boot still fails d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL revert this - boot still fails 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C revert this - boot still fails c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like revert this - boot passed (first bad commit). + linux-samsung soc and updated Thomaz's mail ID (gmail now). Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have to wait another cycle until this patch set (hopefully in a revised form) can be merged. I think we need 8208/1 split up into smaller changes so that the cause of this regression can be found. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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
regression: Clock changes in next-20141205 break at least omap4
Hi, Looks like commit 646cafc6aa4d (clk: Change clk_ops-determine_rate to return a clk_hw as the best parent) breaks booting at least for omap4. Below is the output from omap4-sdp with DEBUG_LL and earlyprintk enabled. Regards, Tony [1.670806] clock: dpll_abe_ck failed transition to 'locked' [2.966735] clock: dpll_abe_ck failed transition to 'locked' [4.262634] clock: dpll_abe_ck failed transition to 'locked' [4.268554] [ cut here ] [4.273406] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:846 clk_disable+0x24/0x30() [4.281341] Modules linked in: [4.284576] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141205-4-g24aaa63b #141 [4.293945] Hardware name: Generic OMAP4 (Flattened Device Tree) [4.300231] [c0015614] (unwind_backtrace) from [c0011cdc] (show_stack+0x10/0x14) [4.308288] [c0011cdc] (show_stack) from [c05b7fb8] (dump_stack+0x80/0x9c) [4.315795] [c05b7fb8] (dump_stack) from [c003e4e8] (warn_slowpath_common+0x78/0xb4) [4.324188] [c003e4e8] (warn_slowpath_common) from [c003e540] (warn_slowpath_null+0x1c/0x24) [4.333282] [c003e540] (warn_slowpath_null) from [c04c386c] (clk_disable+0x24/0x30) [4.341583] [c04c386c] (clk_disable) from [c00252a0] (_disable_clocks+0x18/0x68) [4.349609] [c00252a0] (_disable_clocks) from [c0026810] (_idle+0x15c/0x240) [4.357299] [c0026810] (_idle) from [c0844cb8] (_setup+0x174/0x22c) [4.364166] [c0844cb8] (_setup) from [c0026c4c] (omap_hwmod_for_each+0x30/0x5c) [4.372131] [c0026c4c] (omap_hwmod_for_each) from [c08450c4] (__omap_hwmod_setup_all+0x30/0x40) [4.381500] [c08450c4] (__omap_hwmod_setup_all) from [c0008b44] (do_one_initcall+0x80/0x1d4) [4.390594] [c0008b44] (do_one_initcall) from [c0837e9c] (kernel_init_freeable+0x1f4/0x2cc) [4.399627] [c0837e9c] (kernel_init_freeable) from [c05b211c] (kernel_init+0x8/0xe4) [4.408020] [c05b211c] (kernel_init) from [c000ea48] (ret_from_fork+0x14/0x2c) [4.415954] ---[ end trace f968bc068c5b0ccc ]--- [5.710815] clock: dpll_abe_ck failed transition to 'locked' [7.006744] clock: dpll_abe_ck failed transition to 'locked' -- 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: [RFC 1/2] i2c: omap: fix buffer overruns during RX/TX data processing
Hello, Tony! The issue I'm seeing on 2430sdp is some earlier regression that has started happening over the past year or so. I don't have 2430sdp. And I couldn't find 2430sdp schematics. Looks, like this is NDA stuff. Of course the issue I'm seeing could be caused by hung twl4030 PMIC too. This could be switching twl4030 into inappropriate for 2430sdp mode. For example, SMARTREFLEX_ENABLE bit is dangerous, because it switch twl-pads from VMODE to i2c. And when you set SMARTREFLEX_ENABLE, twl automatically drop VDD1 and VDD2 to 1.2V (if VDD1_SR_CONTROL was not initialized through BYPASS register early in the boot loader). What mode is used in the 2430sdp? VMODE or Smartreflex? And, that is my assumption, may be it wrong again. I'd added trace in the twl_i2c_read_u8/twl_i2c_write_u8 functions to easy find concrete line of code, what cause problem (by register address). Hang happens on access to 0x004b address group. That could be: BACKUP_REG, INT, PM_MASTER, PM_RECEIVER, RTC or SECURED_REG. It hard to tell which one cause hang without trace. Hope this helps. Regards, Alexander. -- 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] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node
From: Menon, Nishanth n...@ti.com
TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on the following:
https://patchwork.kernel.org/patch/5439201/
https://patchwork.kernel.org/patch/5439191/
enable and disable can be controlled by
echo '1' /sys/class/hwmon/hwmon0/fan1_target
and
echo '0' /sys/class/hwmon/hwmon0/fan1_target
requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
Applies on
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2
arch/arm/boot/dts/am57xx-beagle-x15.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..7fe82ef 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,15 @@
default-state = off;
};
};
+
+ gpio_fan {
+ /* Based on 5v 500mA AFB02505HHB */
+ compatible = gpio-fan;
+ pinctrl-names = default;
+ gpios = tps659038_gpio 1 GPIO_ACTIVE_HIGH;
+ gpio-fan,speed-map = 00
+ 13000 1;
+ };
};
dra7_pmx_core {
@@ -314,6 +323,12 @@
wakeup-source;
ti,palmas-long-press-seconds = 12;
};
+
+ tps659038_gpio: tps659038_gpio {
+ compatible = ti,palmas-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
};
tmp102: tmp102@48 {
--
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] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node
On Fri, Dec 05, 2014 at 11:32:18AM -0600, Nishanth Menon wrote:
From: Menon, Nishanth n...@ti.com
do you want to sanitize your name ?
TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on the following:
https://patchwork.kernel.org/patch/5439201/
https://patchwork.kernel.org/patch/5439191/
enable and disable can be controlled by
echo '1' /sys/class/hwmon/hwmon0/fan1_target
and
echo '0' /sys/class/hwmon/hwmon0/fan1_target
requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
Applies on
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2
arch/arm/boot/dts/am57xx-beagle-x15.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..7fe82ef 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,15 @@
default-state = off;
};
};
+
+ gpio_fan {
+ /* Based on 5v 500mA AFB02505HHB */
+ compatible = gpio-fan;
+ pinctrl-names = default;
not needed.
+ gpios = tps659038_gpio 1 GPIO_ACTIVE_HIGH;
+ gpio-fan,speed-map = 00
+ 13000 1;
+ };
};
dra7_pmx_core {
@@ -314,6 +323,12 @@
wakeup-source;
ti,palmas-long-press-seconds = 12;
};
+
+ tps659038_gpio: tps659038_gpio {
+ compatible = ti,palmas-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
};
tmp102: tmp102@48 {
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
[PATCH V2] ARM: dts: am57xx-beagle-x15: Add GPIO controlled fan node
TPS gpio now controls a 5v 500mA TL5209 regulator which may be supply
a fan (such as AFB02505HHB) over J1 connector for various purposes.
Provide device tree node to enable the same.
Signed-off-by: Nishanth Menon n...@ti.com
---
V2: review comment updates
review comments update
- Sanitized outlook-ified name back to normal ;)
- removed unnecessary pinctrl-names property.
V1: https://patchwork.kernel.org/patch/5444911/
Depends on the following:
https://patchwork.kernel.org/patch/5439201/
https://patchwork.kernel.org/patch/5439191/
enable and disable can be controlled by (post the RPM, it finds
closest match - even a 1 will do)
echo '13000' /sys/class/hwmon/hwmon0/fan1_target
and
echo '0' /sys/class/hwmon/hwmon0/fan1_target
Test log: http://slexy.org/view/s2T0ajh46z
requires CONFIG_GPIO_PALMAS and CONFIG_SENSORS_GPIO_FAN to be operational
Applies on
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2
arch/arm/boot/dts/am57xx-beagle-x15.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..4e55e94 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -80,6 +80,14 @@
default-state = off;
};
};
+
+ gpio_fan {
+ /* Based on 5v 500mA AFB02505HHB */
+ compatible = gpio-fan;
+ gpios = tps659038_gpio 1 GPIO_ACTIVE_HIGH;
+ gpio-fan,speed-map = 00
+ 13000 1;
+ };
};
dra7_pmx_core {
@@ -314,6 +322,12 @@
wakeup-source;
ti,palmas-long-press-seconds = 12;
};
+
+ tps659038_gpio: tps659038_gpio {
+ compatible = ti,palmas-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
};
tmp102: tmp102@48 {
--
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: regression: Clock changes in next-20141205 break at least omap4
On 12/05/2014 08:55 AM, Tony Lindgren wrote:
Hi,
Looks like commit 646cafc6aa4d (clk: Change clk_ops-determine_rate
to return a clk_hw as the best parent) breaks booting at least for
omap4.
Do you get a compilation warning in arch/arm/mach-omap2/dpll3xxx.c ?
From what I can tell omap3_noncore_dpll_determine_rate() hasn't been
updated to take a clk_hw pointer instead of clk pointer. It was there in
the original patch and I'm not sure why Mike dropped that part while
applying.
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 20e120d..c2da2a0 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -474,7 +474,7 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
*/
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk)
+ struct clk_hw **best_parent_clk)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
@@ -488,10 +488,10 @@ long omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
unsigned long rate,
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = dd-clk_bypass;
+ *best_parent_clk = __clk_get_hw(dd-clk_bypass);
} else {
rate = omap2_dpll_round_rate(hw, rate, best_parent_rate);
- *best_parent_clk = dd-clk_ref;
+ *best_parent_clk = __clk_get_hw(dd-clk_ref);
}
*best_parent_rate = rate;
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 535822f..0e58e5a 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -223,7 +223,7 @@ out:
*/
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk)
+ struct clk_hw **best_parent_clk)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
@@ -237,11 +237,11 @@ long omap4_dpll_regm4xen_determine_rate(struct clk_hw
*hw, unsigned long rate,
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = dd-clk_bypass;
+ *best_parent_clk = __clk_get_hw(dd-clk_bypass);
} else {
rate = omap4_dpll_regm4xen_round_rate(hw, rate,
best_parent_rate);
- *best_parent_clk = dd-clk_ref;
+ *best_parent_clk = __clk_get_hw(dd-clk_ref);
}
*best_parent_rate = rate;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: regression: Clock changes in next-20141205 break at least omap4
* Stephen Boyd sb...@codeaurora.org [141205 10:23]:
On 12/05/2014 08:55 AM, Tony Lindgren wrote:
Hi,
Looks like commit 646cafc6aa4d (clk: Change clk_ops-determine_rate
to return a clk_hw as the best parent) breaks booting at least for
omap4.
Do you get a compilation warning in arch/arm/mach-omap2/dpll3xxx.c ?
Yes so it seems.
From what I can tell omap3_noncore_dpll_determine_rate() hasn't been
updated to take a clk_hw pointer instead of clk pointer. It was there in
the original patch and I'm not sure why Mike dropped that part while
applying.
OK that makes sense, Mike should apply that part too. Note that also
include/linux/clk/ti.h needs changed accordingly for struct clk_hw,
which you probably had in your orignal patch too. Assuming that's there,
please feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 20e120d..c2da2a0 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -474,7 +474,7 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
*/
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
-struct clk **best_parent_clk)
+struct clk_hw **best_parent_clk)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
@@ -488,10 +488,10 @@ long omap3_noncore_dpll_determine_rate(struct clk_hw
*hw, unsigned long rate,
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = dd-clk_bypass;
+ *best_parent_clk = __clk_get_hw(dd-clk_bypass);
} else {
rate = omap2_dpll_round_rate(hw, rate, best_parent_rate);
- *best_parent_clk = dd-clk_ref;
+ *best_parent_clk = __clk_get_hw(dd-clk_ref);
}
*best_parent_rate = rate;
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 535822f..0e58e5a 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -223,7 +223,7 @@ out:
*/
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long
rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_clk)
+ struct clk_hw **best_parent_clk)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
struct dpll_data *dd;
@@ -237,11 +237,11 @@ long omap4_dpll_regm4xen_determine_rate(struct clk_hw
*hw, unsigned long rate,
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
- *best_parent_clk = dd-clk_bypass;
+ *best_parent_clk = __clk_get_hw(dd-clk_bypass);
} else {
rate = omap4_dpll_regm4xen_round_rate(hw, rate,
best_parent_rate);
- *best_parent_clk = dd-clk_ref;
+ *best_parent_clk = __clk_get_hw(dd-clk_ref);
}
*best_parent_rate = rate;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] arm: omap: hwmod: add debugfs interface
By exposing the details of hwmod structures
to debugfs we can much more easily verify
that changes to hwmod data is correct and won't
cause regressions.
The idea is that this can be used to check the
state of one hwmod, verify hwmod sysc fields, etc.
For example, this will be used to move some of
the sysc fields to DT and later verify that they
are correct pre- and post-patch.
Signed-off-by: Felipe Balbi ba...@ti.com
---
The idea behind this is that I'll be moving some more of hwmod
data to DT and this will help diff pre- and post-patch boots
to see if data remained the same.
Tested with AM437x SK, logs here:
http://hastebin.com/ukahuvipiz
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/omap_hwmod.c | 1 +
arch/arm/mach-omap2/omap_hwmod.h | 6 +
arch/arm/mach-omap2/omap_hwmod_debugfs.c | 280 +++
4 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_debugfs.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d27dfd..68c9ae5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -11,7 +11,7 @@ obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o
timer.o pm.o \
omap_device.o sram.o drm.o
hwmod-common = omap_hwmod.o omap_hwmod_reset.o \
- omap_hwmod_common_data.o
+ omap_hwmod_common_data.o
omap_hwmod_debugfs.o
clock-common = clock.o clock_common_data.o \
clkt_dpll.o clkt_clksel.o
secure-common = omap-smc.o omap-secure.o
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908d..a01caa4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3314,6 +3314,7 @@ static int __init omap_hwmod_setup_all(void)
omap_hwmod_for_each(_init, NULL);
omap_hwmod_for_each(_setup, NULL);
+ omap_hwmod_debug_init();
return 0;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 35ca6ef..49f1d82 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -768,4 +768,10 @@ int am43xx_hwmod_init(void);
extern int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois);
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+extern int __init omap_hwmod_debug_init(void);
+#else
+static inline int __int omap_hwmod_debug_init(void) { return 0; }
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_debugfs.c
b/arch/arm/mach-omap2/omap_hwmod_debugfs.c
new file mode 100644
index 000..eb120a4
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_debugfs.c
@@ -0,0 +1,280 @@
+/*
+ * omap_hwmod debugfs view
+ *
+ * Copyright (C) 2014 Texas Instruments, Incorporated - http://www.ti.com
+ * Author: Felipe Balbi ba...@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.
+ */
+#undef DEBUG
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/io.h
+#include linux/err.h
+#include linux/fs.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/spinlock.h
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+#include clock.h
+#include omap_hwmod.h
+
+#include soc.h
+#include common.h
+#include clockdomain.h
+#include powerdomain.h
+#include cm2xxx.h
+#include cm3xxx.h
+#include cm33xx.h
+#include prm.h
+#include prm3xxx.h
+#include prm44xx.h
+#include prm33xx.h
+#include prminst44xx.h
+#include mux.h
+#include pm.h
+
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static int __init omap_hwmod_create_files(struct omap_hwmod *oh,
+ struct dentry *dir)
+{
+ struct dentry *file;
+
+ file = debugfs_create_u16(flags, S_IRUGO, dir, oh-flags);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(mpu_rt_idx, S_IRUGO, dir, oh-mpu_rt_idx);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(response_lat, S_IRUGO, dir,
+ oh-response_lat);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(rst_lines_cnt, S_IRUGO, dir,
+ oh-rst_lines_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(opt_clks_cnt, S_IRUGO, dir,
+ oh-opt_clks_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(masters_cnt, S_IRUGO, dir, oh-masters_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(slaves_cnt, S_IRUGO, dir, oh-slaves_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(hwmods_cnt, S_IRUGO, dir, oh-hwmods_cnt);
+
[PATCH] ARM / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under
arch/arm/ (the defconfig files will be modified later).
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) which is only in linux-next at the moment (via the
linux-pm tree).
Please let me know if it is OK to take this one into linux-pm.
---
arch/arm/kernel/perf_event.c |2 +-
arch/arm/mach-davinci/pm_domain.c |2 +-
arch/arm/mach-keystone/pm_domain.c |2 +-
arch/arm/mach-omap1/pm_bus.c |4 ++--
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/omap_device.c |2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-pm/arch/arm/kernel/perf_event.c
===
--- linux-pm.orig/arch/arm/kernel/perf_event.c
+++ linux-pm/arch/arm/kernel/perf_event.c
@@ -481,7 +481,7 @@ static void armpmu_disable(struct pmu *p
armpmu-stop(armpmu);
}
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int armpmu_runtime_resume(struct device *dev)
{
struct arm_pmu_platdata *plat = dev_get_platdata(dev);
Index: linux-pm/arch/arm/mach-davinci/pm_domain.c
===
--- linux-pm.orig/arch/arm/mach-davinci/pm_domain.c
+++ linux-pm/arch/arm/mach-davinci/pm_domain.c
@@ -14,7 +14,7 @@
#include linux/pm_clock.h
#include linux/platform_device.h
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int davinci_pm_runtime_suspend(struct device *dev)
{
int ret;
Index: linux-pm/arch/arm/mach-keystone/pm_domain.c
===
--- linux-pm.orig/arch/arm/mach-keystone/pm_domain.c
+++ linux-pm/arch/arm/mach-keystone/pm_domain.c
@@ -19,7 +19,7 @@
#include linux/clk-provider.h
#include linux/of.h
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int keystone_pm_runtime_suspend(struct device *dev)
{
int ret;
Index: linux-pm/arch/arm/mach-omap1/pm_bus.c
===
--- linux-pm.orig/arch/arm/mach-omap1/pm_bus.c
+++ linux-pm/arch/arm/mach-omap1/pm_bus.c
@@ -21,7 +21,7 @@
#include soc.h
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int omap1_pm_runtime_suspend(struct device *dev)
{
int ret;
@@ -59,7 +59,7 @@ static struct dev_pm_domain default_pm_d
#define OMAP1_PM_DOMAIN (default_pm_domain)
#else
#define OMAP1_PM_DOMAIN NULL
-#endif /* CONFIG_PM_RUNTIME */
+#endif /* CONFIG_PM */
static struct pm_clk_notifier_block platform_bus_notifier = {
.pm_domain = OMAP1_PM_DOMAIN,
Index: linux-pm/arch/arm/mach-omap2/io.c
===
--- linux-pm.orig/arch/arm/mach-omap2/io.c
+++ linux-pm/arch/arm/mach-omap2/io.c
@@ -359,7 +359,7 @@ static void __init omap_hwmod_init_posts
u8 postsetup_state;
/* Set the default postsetup state for all hwmods */
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
postsetup_state = _HWMOD_STATE_IDLE;
#else
postsetup_state = _HWMOD_STATE_ENABLED;
Index: linux-pm/arch/arm/mach-omap2/omap_device.c
===
--- linux-pm.orig/arch/arm/mach-omap2/omap_device.c
+++ linux-pm/arch/arm/mach-omap2/omap_device.c
@@ -588,7 +588,7 @@ odbs_exit:
return ERR_PTR(ret);
}
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int _od_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
--
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
