Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Wed, 12 Dec 2012, Will Deacon wrote: On Wed, Dec 12, 2012 at 10:33:38AM +, Lorenzo Pieralisi wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. At some point we probably want to describe the level of flushing required in the device tree as a property of the CPU node (or something similar). That would allow us to have *one* function for flushing, e.g. cpu_suspend_flush_cache which flushes to the appropriate level. Then we could remove the louis flush from the CPU suspend code and instead make it the finisher's responsibility to call our flushing function when it's done, which helps to avoid over/under-flushing the cache. In the meantime, fixing louis as we've suggested should work. Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] regulator: core: if voltage scaling fails, restore original
On Thu, Dec 13, 2012 at 05:15:33AM +, Mark Brown wrote: On Wed, Dec 12, 2012 at 12:45:52PM +0100, Paolo Pisati wrote: And after a second look it's clear what's going on: After a second look at what? You've not provided any context, I've no idea what you're talking about here. forgot the --in-reply-to=..., i'll resend as a new thread. -- bye, p. -- 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] [resend] regulator: core: if voltage scaling fails, restore original values
[resent with cc: stable and a bit more context]
I've been experiencing solid hangs on my beaglexm with v3.7 after
kexec:
here is my .config (omap2plus + EHCI/OHCI + CPUFREQ + DEVTMP):
http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/config
here is the diff i added to get some debugging:
http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/dpll-debug.diff
here is a trace of the kexeced kernel:
http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/kexec-boot.txt
And after a second look it's clear what's going on:
[...]
[5.575744] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV
[5.582946] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[5.590332] cpu cpu0: omap_target: unable to scale voltage up.
[1]
[5.596649] notification 1 of frequency transition to 30 kHz
[5.603179] FREQ: 30 - CPU: 0
[5.606597] governor: change or update limits
[5.611572] __cpufreq_governor for CPU 0, event 3
[5.616699] setting to 80 kHz because of event 3
[5.622039] target for CPU 0: 80 kHz, relation 1
[5.627441] request for target 80 kHz (relation: 1) for cpu 0
[5.634063] target is 2 (80 kHz, 2)
[5.638183] notification 0 of frequency transition to 80 kHz
[5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV -- 800 MHz, 1325 mV
[2]
[hangs here]
first time[1] it tries to ramp up frequency (and thus voltage),
regulator_set_voltage() returns an error and we exit:
omap-cpufreq.c::omap_target():
...
dev_dbg(mpu_dev, cpufreq-omap: %u MHz, %ld mV -- %u MHz, %ld mV\n,
freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
freqs.new / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
if (mpu_reg (freqs.new freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r 0) {
dev_warn(mpu_dev, %s: unable to scale voltage up.\n,
__func__);
freqs.new = freqs.old;
goto done;
}
}
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
...
but inside regulator_set_voltage(), we save the new regulator voltage before
actually ramping up:
core.c::regulator_set_voltage():
...
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); -- ERROR!!!
if (ret 0)
goto out2;
...
and by the time we try to change frequency again[2], regulator_set_voltage()
is a noop because it thinks we are already at the desired voltage:
core.c::regulator_set_voltage():
...
/* If we're setting the same range as last time the change
* should be a noop (some cpufreq implementations use the same
* voltage for multiple
[PATCH] regulator: core: if voltage scaling fails, restore original voltage values
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
Tested-by: Robert Nelson robertcnel...@gmail.com
---
drivers/regulator/core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
{
struct regulator_dev *rdev = regulator-rdev;
int ret = 0;
+ int old_min_uV, old_max_uV;
mutex_lock(rdev-mutex);
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, min_uV, max_uV);
if (ret 0)
goto out;
+
+ /* restore original values in case of error */
+ old_min_uV = regulator-min_uV;
+ old_max_uV = regulator-max_uV;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
ret = regulator_check_consumers(rdev, min_uV, max_uV);
if (ret 0)
- goto out;
+ goto out2;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+ if (ret 0)
+ goto out2;
+
out:
mutex_unlock(rdev-mutex);
return ret;
+out2:
+ regulator-min_uV = old_min_uV;
+ regulator-max_uV = old_max_uV;
+ mutex_unlock(rdev-mutex);
+ return ret;
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
--
1.7.10.4
--
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 01/10] ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
On Thu, Dec 13, 2012 at 12:59:49, Paul Walmsley wrote: On Thu, 13 Dec 2012, Hiremath, Vaibhav wrote: On Thu, Dec 13, 2012 at 11:11:49, Paul Walmsley wrote: The branch name to use is: TEST_pwrdm_post_fpwrst_devel_a_3.9 If I am correct, it only includes one additional patch (merge commit), right??? commit d94831e0005fee743cefd28f4c20b7c435c71236 Merge: 3e885c6 80ab3b2 Author: Paul Walmsley p...@pwsan.com Date: Sun Dec 9 13:06:51 2012 -0700 build fixes Does this also fix sparse warnings? Just ran a quick sparse check on mach-omap2 at 3e885c6 and d94831e with 'make -j4 C=2 arch/arm/mach-omap2', and no warnings showed up. There were some sparse issues that got fixed at an earlier point, though, so perhaps you have an older copy of the branches somehow? Ignore my earlier comment on sparse warning, it was my wrong sparse tool which was culprit here. I am working on remote server, which has sparse present inside /usr/bin, and somehow my default config using that one instead of what I was building. I fixed this by changing the PATH, and now I do not see any issues/warnings. Thanks, Vaibhav -- 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] regulator: core: if voltage scaling fails, restore original voltage values
On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: Signed-off-by: Paolo Pisati paolo.pis...@canonical.com Tested-by: Robert Nelson robertcnel...@gmail.com please read Documentation/stable_kernel_rules.txt, you'll see this is wrong. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 00/23] OMAP USB Host cleanup
Hi Samuel Felipe, How can we proceed with this patchset? You can use the below pull request. The following changes since commit 47f46768d3a3866bff7164649dab499bf5d8ed81: Merge branch 'next/soc' into for-next (2012-12-07 16:35:14 -0800) are available in the git repository at: g...@github.com:rogerq/linux.git arm-for-next-usbhost6 It is known to fix the following warnings on arm-soc/for-next [1.608428] WARNING: at drivers/clk/clk.c:512 __clk_enable+0x94/0xa0() [0.608428] Modules linked in: [0.608459] [c001b254] (unwind_backtrace+0x0/0xf0) from [c003fdd4] (warn_slowpath_common+0x4c/0x64) [0.608459] [c003fdd4] (warn_slowpath_common+0x4c/0x64) from [c003fe08] (warn_slowpath_null+0x1c/0x24) [0.608489] [c003fe08] (warn_slowpath_null+0x1c/0x24) from [c03f05d8] (__clk_enable+0x94/0xa0) [0.608489] [c03f05d8] (__clk_enable+0x94/0xa0) from [c03f0604] (clk_enable+0x20/0x3c) [0.608520] [c03f0604] (clk_enable+0x20/0x3c) from [c031f480] (usbhs_runtime_resume+0x68/0xa4) [0.608520] [c031f480] (usbhs_runtime_resume+0x68/0xa4) from [c030c9a0] (pm_generic_runtime_resume+0x2c/0x38) [0.608551] [c030c9a0] (pm_generic_runtime_resume+0x2c/0x38) from [c0310134] (__rpm_callback+0x2c/0x60) [0.608581] [c0310134] (__rpm_callback+0x2c/0x60) from [c0311060] (rpm_resume+0x39c/0x60c) [0.608581] [c0311060] (rpm_resume+0x39c/0x60c) from [c0311538] (__pm_runtime_resume+0x48/0x60) [0.608612] [c0311538] (__pm_runtime_resume+0x48/0x60) from [c04b8260] (usbhs_omap_probe+0x3a8/0x858) [0.608612] [c04b8260] (usbhs_omap_probe+0x3a8/0x858) from [c0309c70] (platform_drv_probe+0x18/0x1c) [0.608642] [c0309c70] (platform_drv_probe+0x18/0x1c) from [c03089f4] (driver_probe_device+0x74/0x218) [0.608642] [c03089f4] (driver_probe_device+0x74/0x218) from [c0308c2c] (__driver_attach+0x94/0x98) [0.608673] [c0308c2c] (__driver_attach+0x94/0x98) from [c0307188] (bus_for_each_dev+0x4c/0x80) [0.608673] [c0307188] (bus_for_each_dev+0x4c/0x80) from [c0308224] (bus_add_driver+0x174/0x240) [0.608703] [c0308224] (bus_add_driver+0x174/0x240) from [c03090f8] (driver_register+0x78/0x14c) [0.608703] [c03090f8] (driver_register+0x78/0x14c) from [c0309e5c] (platform_driver_probe+0x18/0x9c) [0.608734] [c0309e5c] (platform_driver_probe+0x18/0x9c) from [c0008774] (do_one_initcall+0xfc/0x168) [0.608734] [c0008774] (do_one_initcall+0xfc/0x168) from [c04b2014] (kernel_init+0x120/0x2cc) [0.608764] [c04b2014] (kernel_init+0x120/0x2cc) from [c00137f0] (ret_from_fork+0x14/0x24) [0.608764] ---[ end trace f627315b3f056ecc ]--- [0.608795] [ cut here ] [0.608795] WARNING: at drivers/clk/clk.c:471 clk_disable+0x20/0x34() [0.608825] Modules linked in: [0.608825] [c001b254] (unwind_backtrace+0x0/0xf0) from [c003fdd4] (warn_slowpath_common+0x4c/0x64) [0.608856] [c003fdd4] (warn_slowpath_common+0x4c/0x64) from [c003fe08] (warn_slowpath_null+0x1c/0x24) [0.608856] [c003fe08] (warn_slowpath_null+0x1c/0x24) from [c03f0530] (clk_disable+0x20/0x34) [0.608886] [c03f0530] (clk_disable+0x20/0x34) from [c031f500] (usbhs_runtime_suspend+0x44/0xa4) [0.608917] [c031f500] (usbhs_runtime_suspend+0x44/0xa4) from [c030c968] (pm_generic_runtime_suspend+0x2c/0x38) [0.608917] [c030c968] (pm_generic_runtime_suspend+0x2c/0x38) from [c002b120] (_od_runtime_suspend+0xc/0x24) [0.608947] [c002b120] (_od_runtime_suspend+0xc/0x24) from [c0310134] (__rpm_callback+0x2c/0x60) [0.608947] [c0310134] (__rpm_callback+0x2c/0x60) from [c03104a4] (rpm_suspend+0xf4/0x59c) [0.608978] [c03104a4] (rpm_suspend+0xf4/0x59c) from [c03118f8] (__pm_runtime_suspend+0x5c/0x80) [0.609008] [c03118f8] (__pm_runtime_suspend+0x5c/0x80) from [c030cde0] (pm_generic_runtime_idle+0x44/0x50) [0.609008] [c030cde0] (pm_generic_runtime_idle+0x44/0x50) from [c0310134] (__rpm_callback+0x2c/0x60) [0.609039] [c0310134] (__rpm_callback+0x2c/0x60) from [c0310aa8] (rpm_idle+0xf0/0x21c) [0.609039] [c0310aa8] (rpm_idle+0xf0/0x21c) from [c0310ca0] (__pm_runtime_idle+0x5c/0x80) [0.609069] [c0310ca0] (__pm_runtime_idle+0x5c/0x80) from [c04b83c0] (usbhs_omap_probe+0x508/0x858) [0.609069] [c04b83c0] (usbhs_omap_probe+0x508/0x858) from [c0309c70] (platform_drv_probe+0x18/0x1c) [0.609100] [c0309c70] (platform_drv_probe+0x18/0x1c) from [c03089f4] (driver_probe_device+0x74/0x218) [0.609100] [c03089f4] (driver_probe_device+0x74/0x218) from [c0308c2c] (__driver_attach+0x94/0x98) [0.609130] [c0308c2c] (__driver_attach+0x94/0x98) from [c0307188] (bus_for_each_dev+0x4c/0x80) [0.609130] [c0307188] (bus_for_each_dev+0x4c/0x80) from [c0308224] (bus_add_driver+0x174/0x240) [0.609161] [c0308224] (bus_add_driver+0x174/0x240) from [c03090f8] (driver_register+0x78/0x14c) [0.609161] [c03090f8] (driver_register+0x78/0x14c) from [c0309e5c] (platform_driver_probe+0x18/0x9c) [0.609191] [c0309e5c] (platform_driver_probe+0x18/0x9c) from [c0008774]
Re: [PATCH v4 00/23] OMAP USB Host cleanup
Hi, On Thu, Dec 13, 2012 at 12:44:22PM +0200, Roger Quadros wrote: Hi Samuel Felipe, How can we proceed with this patchset? You can use the below pull request. there are patches under arch/arm/ which need Tony's Acked-by, if we get those, then sure, go ahead ;-) -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote: On Wed, 12 Dec 2012, Will Deacon wrote: Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Cheers, Will -- 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 v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On Wed, Dec 05, 2012 at 04:13:46PM +0200, Roger Quadros wrote:
On 12/05/2012 03:42 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..e5257dc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
-/* for OMAP3 , the clk set paretn fails */
+/* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap-utmi_clk[0],
omap-xclk60mhsp1_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp1_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp1_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[0])) {
ret = clk_set_parent(omap-utmi_clk[0],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp2_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp2_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ret);
Hm, you sometimes put a space before colon in the error message and
sometimes not. Inconsistent. :-)
That was because it fit in 80 characters without the space. I'm not sure
what is more important, fitting in 80 or consistency in the print
message. Maybe i should have removed the spaces everywhere so that it is
consistent as well. :)
I'd say it's the consistency :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On 5 December 2012 19:43, Roger Quadros rog...@ti.com wrote:
On 12/05/2012 03:42 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..e5257dc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
-/* for OMAP3 , the clk set paretn fails */
+/* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap-utmi_clk[0],
omap-xclk60mhsp1_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp1_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp1_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[0])) {
ret = clk_set_parent(omap-utmi_clk[0],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp2_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp2_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ret);
Hm, you sometimes put a space before colon in the error message and
sometimes not. Inconsistent. :-)
That was because it fit in 80 characters without the space. I'm not sure
what is more important, fitting in 80 or consistency in the print
message. Maybe i should have removed the spaces everywhere so that it is
consistent as well. :)
prints are one thing where breaking the 80 column rule is acceptable.
Otherwise it fails grep'ing
--
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/1] net: cpts: fix for build break after ARM SoC integration
Hi, On 2012-11-27 12:27, Mugunthan V N wrote: CC drivers/net/ethernet/ti/cpts.o drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory compilation terminated. make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1 make[3]: *** [drivers/net/ethernet/ti] Error 2 make[2]: *** [drivers/net/ethernet] Error 2 make[1]: *** [drivers/net] Error 2 fix for build break as the header file is removed from plat-omap as part of the below patch linux-next still has this build problem, I guess this patch is lingering somewhere. Somewhat annoying, as the driver is enabled by default. (btw, why is it default y?) Tomi -- 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 2/5] OMAPFB: simplify locking
On 2012-12-07 13:55, Tomi Valkeinen wrote: Kernel lock verification code has lately detected possible circular locking in omapfb. The exact problem is unclear, but omapfb's current locking seems to be overly complex. This patch simplifies the locking in the following ways: - Remove explicit omapfb mem region locking. I couldn't figure out the need for this, as long as we take care to take omapfb lock. - Get omapfb lock always, even if the operation is possibly only related to one fb_info. Better safe than sorry, and normally there's only one user for the fb so this shouldn't matter. - Make sure fb_info lock is taken first, then omapfb lock. With this patch the warnings about possible circular locking does not happen anymore. I'm dropping this patch, for some reason it causes huge latencies with two processes using separate fbs. I guess there's need for the more precise locking, after all. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
On Thu, Dec 13, 2012 at 01:07:37PM +0200, Tomi Valkeinen wrote: Hi, On 2012-11-27 12:27, Mugunthan V N wrote: CC drivers/net/ethernet/ti/cpts.o drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory compilation terminated. make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1 make[3]: *** [drivers/net/ethernet/ti] Error 2 make[2]: *** [drivers/net/ethernet] Error 2 make[1]: *** [drivers/net] Error 2 fix for build break as the header file is removed from plat-omap as part of the below patch linux-next still has this build problem, I guess this patch is lingering somewhere. Somewhat annoying, as the driver is enabled by default. (btw, why is it default y?) Um, in Linus' master, net, and net-next, neither TI_CPSW nor TI_CPTS are default y, so I don't know where you are coming from on that. Sorry, Richard -- 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 PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, 13 Dec 2012, Will Deacon wrote: On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote: On Wed, 12 Dec 2012, Will Deacon wrote: Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Well, the fix is yours, so, it should be From: you. I can certainly send it just copying your description above, but I'd also need your Sob. Something like the below (feel free to improve the subject line and the description): From: Will Deacon will.dea...@arm.com Subject: [PATCH] ARM: sh7372: fix cache clean / invalidate order According to the Cortex A8 TRM the L2 cache should be first cleaned and then disabled. Fix the swapped order on sh7372. Signed-off-by: you Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de (or even just) Tested-by: Guennadi Liakhovetski g.liakhovet...@gmx.de diff --git a/arch/arm/mach-shmobile/sleep-sh7372.S b/arch/arm/mach-shmobile/sleep-sh7372.S index 1d56467..df15d8a 100644 --- a/arch/arm/mach-shmobile/sleep-sh7372.S +++ b/arch/arm/mach-shmobile/sleep-sh7372.S @@ -59,16 +59,16 @@ sh7372_do_idle_sysc: mcr p15, 0, r0, c1, c0, 0 isb - /* disable L2 cache in the aux control register */ - mrc p15, 0, r10, c1, c0, 1 - bic r10, r10, #2 - mcr p15, 0, r10, c1, c0, 1 - /* * Invalidate data cache again. */ ldr r1, kernel_flush blx r1 + + /* disable L2 cache in the aux control register */ + mrc p15, 0, r10, c1, c0, 1 + bic r10, r10, #2 + mcr p15, 0, r10, c1, c0, 1 /* * The kernel doesn't interwork: v7_flush_dcache_all in particluar will * always return in Thumb state when CONFIG_THUMB2_KERNEL is 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thursday 13 December 2012 03:32 PM, Guennadi Liakhovetski wrote: On Thu, 13 Dec 2012, Will Deacon wrote: On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote: On Wed, 12 Dec 2012, Will Deacon wrote: Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Well, the fix is yours, so, it should be From: you. I can certainly send it just copying your description above, but I'd also need your Sob. Something like the below (feel free to improve the subject line and the description): From: Will Deacon will.dea...@arm.com Subject: [PATCH] ARM: sh7372: fix cache clean / invalidate order According to the Cortex A8 TRM the L2 cache should be first cleaned and then disabled. Fix the swapped order on sh7372. Signed-off-by: you Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de (or even just) Tested-by: Guennadi Liakhovetski g.liakhovet...@gmx.de diff --git a/arch/arm/mach-shmobile/sleep-sh7372.S b/arch/arm/mach-shmobile/sleep-sh7372.S index 1d56467..df15d8a 100644 --- a/arch/arm/mach-shmobile/sleep-sh7372.S +++ b/arch/arm/mach-shmobile/sleep-sh7372.S @@ -59,16 +59,16 @@ sh7372_do_idle_sysc: mcr p15, 0, r0, c1, c0, 0 isb - /* disable L2 cache in the aux control register */ - mrc p15, 0, r10, c1, c0, 1 - bic r10, r10, #2 - mcr p15, 0, r10, c1, c0, 1 - /* * Invalidate data cache again. */ kernel_flush does Clean and Invalidate ldr r1, kernel_flush blx r1 + + /* disable L2 cache in the aux control register */ + mrc p15, 0, r10, c1, c0, 1 + bic r10, r10, #2 + mcr p15, 0, r10, c1, c0, 1 An isb will be make it safe. Otherwise patch looks good to me. Feel free to add my review-by tag if you need one. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Dec 13, 2012 at 02:32:46PM +, Guennadi Liakhovetski wrote: On Thu, 13 Dec 2012, Will Deacon wrote: On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote: On Wed, 12 Dec 2012, Will Deacon wrote: Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Well, the fix is yours, so, it should be From: you. I can certainly send it just copying your description above, but I'd also need your Sob. Something like the below (feel free to improve the subject line and the description): No, I didn't send any code for this so you should be the author. I can review/possibly ack it if you like (please send a v2 addressing Santosh's comments). Will -- 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/5] ARM: CORESIGHT: Add generic lock/unlock helpers
Hi Jon,
On Wed, Dec 12, 2012 at 09:43:04PM +, Jon Hunter wrote:
The Cross Trigger Interface (CTI) helpers in cti.h include definitions
for the Coresight Lock Access Register (LAR) and Lock Status Register
(LSR). These registers are already defined in coresight.h and so rather
than having multiple definitions, just use the definitions from
coresight.h.
Add the following coresight macros ...
- coresight_unlock() -- Unlocks coresight module
- coresight_lock() -- Locks coresight module
Use the above macros for ETB, ETM and CTI. The do-while(0) statement
has been removed from the macro as it is not a multi-line macro.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/cti.h| 16 +++-
arch/arm/include/asm/hardware/coresight.h | 16
2 files changed, 11 insertions(+), 21 deletions(-)
[...]
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
index 7ecd793..dcd0e66 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -141,17 +141,17 @@
#define ETBFF_TRIGEVTBIT(9)
#define ETBFF_TRIGFL BIT(10)
-#define etb_writel(t, v, x) \
- (__raw_writel((v), (t)-etb_regs + (x)))
+#define etb_writel(t, v, x) (__raw_writel((v), (t)-etb_regs + (x)))
#define etb_readl(t, x) (__raw_readl((t)-etb_regs + (x)))
-#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etm_unlock(t) \
- do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define etb_lock(t) coresight_lock((t)-etb_regs)
+#define etb_unlock(t) coresight_unlock((t)-etb_regs)
+#define etm_lock(t) coresight_lock((t)-etm_regs)
+#define etm_unlock(t) coresight_unlock((t)-etm_regs)
-#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etb_unlock(t) \
- do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
+#define coresight_unlock(base) \
+ (__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
#endif /* __ASM_HARDWARE_CORESIGHT_H */
How about we take this opportunity to divorce the more general coresight
bits from the etb specific parts, like you've done for the cti. We could
move the ETB stuff out into asm/etb.h (although it might be nice to keep all
the coresight device headers in one place... answers on a postcard) and just
have the architected coresight functionality in this header.
Will
--
1.7.10.4
--
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 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver
On Wed, Dec 12, 2012 at 09:43:06PM +, Jon Hunter wrote:
Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
AMBA bus driver so that we can use device-tree to look-up the hardware
specific information such as base address and interrupt number during
the device probe. This also add APIs to request, cti_get() and release,
cti_put(), a CTI module so that drivers can allocate a module at
runtime.
Currently, the driver only supports looking-up the CTI hardware
information via device-tree, however, the driver could be extended to
support non-device-tree configurations if needed for a particular
architecture.
The CTI driver only currently supports CTI modules that have a single
CPU interrupt, however, could be extended in the future to support more
interrupts if a device requires this.
Aha, so elaborating on my earlier comments, we basically want to do the same
thing for ETB I reckon. This does raise the question about namespaces
though...
+/**
+ * struct cti - Cross Trigger Interface (CTI) struct
+ *
+ * @node: Connects CTI instance to list of CTI instances
+ * @dev: Pointer to device structure
+ * @base: Mapped virtual address of the CTI module
+ * @name: Name associated with CTI instance
+ * @irq: Interrupt associated with CTI instance
+ * @trig_out: Trigger output associated with interrupt (@irq)
+ * @reserved: Used to indicate if CTI instance has been allocated
+ * @enabled: Used to indicate if CTI instance has been enabled
+ */
+struct cti {
+ struct list_head node;
+ struct device *dev;
+ void __iomem *base;
+ const char *name;
+ int irq;
+ int trig_out;
+ bool reserved;
+ bool enabled;
+};
+
+#ifdef CONFIG_ARM_AMBA_CTI
+
+int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan);
+int cti_enable(struct cti *cti);
+int cti_disable(struct cti *cti);
+int cti_irq_ack(struct cti *cti);
+struct cti *cti_get(const char *name);
+void cti_put(struct cti *cti);
I wonder whether we should stick these all into a struct and have a general
way to see which coresight devices we have and then retrieve their ops
structures (so things like perf can walk a virtual coresight bus containing
initialised devices). It might also help if we decide to describe the
plumbing in the device tree, like Rob suggested.
What do you reckon?
Will
--
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] OMAP: add pwm driver using dmtimers.
On 12/12/2012 09:06 PM, NeilBrown wrote:
[Thierry: question for you near the end - thanks]
On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter jon-hun...@ti.com wrote:
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
This patch is based on an earlier patch by Grant Erickson
which provided pwm devices using the 'legacy' interface.
This driver instead uses the new framework interface.
Cc: Grant Erickson maratho...@gmail.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..7df573a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -85,6 +85,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP
+ tristate OMAP pwm support
+ depends on ARCH_OMAP
We should probably have depends on or selects OMAP_DM_TIMER here too.
Sounds sensible - fixed.
+ help
+ Generic PWM framework driver for OMAP
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap
+
config PWM_PUV3
tristate PKUnity NetBook-0916 PWM support
depends on ARCH_PUV3
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..f5d200d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
new file mode 100644
index 000..e3dbce3
--- /dev/null
+++ b/drivers/pwm/pwm-omap.c
@@ -0,0 +1,318 @@
+/*
+ *Copyright (c) 2012 NeilBrown ne...@suse.de
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.com
+ *
+ *Also based on pwm-samsung.c
+ *
+ *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.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
I would drop the OMAP2/3 and just say OMAP here. Potentially this should
work for OMAP1-5.
Done.
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ *The 'id' number for the device encodes the number of the dm timer
+ *to use, and the polarity of the output.
+ *lsb is '1' of active-high, and '0' for active low
+ *remaining bit a timer number and need to be shifted down before use.
+ */
+
+#define pr_fmt(fmt) pwm-omap: fmt
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/pwm.h
+#include linux/module.h
+
+#include plat/dmtimer.h
This is going to be a problem for the single zImage work, because we
cannot include any plat headers in driver code any more. Therefore,
although it is not ideal, one way to handle this is pass function
pointers to the various dmtimer APIs that are needed via the platform
data. Painful I know ...
But that doesn't work with devicetree does it?
Ugh, you are right! This is becoming an increasing problem.
Can't we move the dmtimer.h file to include/linux/omap-dmtimer.h or something?
I can ask Tony if he thinks we could do that.
It only included other things from include/linux, so it should be safe.
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct omap_chip {
+ struct platform_device *pdev;
+
+ struct omap_dm_timer*dm_timer;
+ unsigned intpolarity;
+ const char *label;
+
+ unsigned intduty_ns, period_ns;
+ struct pwm_chip chip;
+};
+
+#define to_omap_chip(chip) container_of(chip, struct omap_chip, chip)
+
+#definepwm_dbg(_pwm, msg...) dev_dbg((_pwm)-pdev-dev, msg)
+
+/**
+ * pwm_calc_value - determines the counter value for a clock rate and
period.
+ * @clk_rate: The clock rate, in Hz, of the PWM's clock source to compute
the
+ *counter value for.
+ * @ns: The period, in nanoseconds, to computer the counter value for.
+ *
+ * Returns the PWM counter value for the specified clock rate and period.
+ */
+static inline int pwm_calc_value(unsigned long clk_rate, int ns)
+{
+ const unsigned long nanoseconds_per_second = 10;
+ int cycles;
+ __u64 c;
+
+ c = (__u64)clk_rate * ns;
+ do_div(c, nanoseconds_per_second);
+ cycles = c;
+
+ return DM_TIMER_LOAD_MIN - cycles;
+}
+
+static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device
Re: [PATCH] OMAP: add pwm driver using dmtimers.
* Jon Hunter jon-hun...@ti.com [121213 09:11]: On 12/12/2012 09:06 PM, NeilBrown wrote: On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter jon-hun...@ti.com wrote: On 12/12/2012 02:24 AM, NeilBrown wrote: + +#include plat/dmtimer.h This is going to be a problem for the single zImage work, because we cannot include any plat headers in driver code any more. Therefore, although it is not ideal, one way to handle this is pass function pointers to the various dmtimer APIs that are needed via the platform data. Painful I know ... But that doesn't work with devicetree does it? Ugh, you are right! This is becoming an increasing problem. Can't we move the dmtimer.h file to include/linux/omap-dmtimer.h or something? I can ask Tony if he thinks we could do that. Yeah we need to fix this somehow. First we need to limit that header to the minimum and have most of it in a local header file for the clocksource and clockevent. Then let's move the minimal header to include/linux/omap-dmtimer.h until we have something Linux generic available for doing things like this. Regards, Tony -- 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] OMAP: add pwm driver using dmtimers.
* NeilBrown ne...@suse.de [121212 19:09]: On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter jon-hun...@ti.com wrote: On 12/12/2012 02:24 AM, NeilBrown wrote: + + /* Request the OMAP dual-mode timer that will be bound to and + * associated with this generic PWM. + */ + + omap-dm_timer = omap_dm_timer_request_specific(timer); I would recommend that you use omap_dm_timer_request_by_cap() (new for v3.8 so you should be able to use once v3.8-rc1 is out) here to request a timer that supports the PWM output. The above function will not be supported when booting with device-tree. I wasn't planning on rushing into working on 3.8-rcX so I'd rather not do this now. Would you object to the patch being submitted with the current call, then an update when I do move on to 3.8? However I may be misunderstanding something, but I want a timer to drive a particular output pin - GPIO-57. And I thought that it could only be driver by GPT11. So I need to explicitly request number 11 don't I? Yes I believe it needs to tied to a specific GPT instance to have access to the pin. We should not export omap_dm_timer_request_specific(), that information should become from platform_data and device tree. Regards, Tony -- 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 2/5] ARM: dts: Add Cross Trigger Interface binding
On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote: Adds a device-tree binding for the ARM Cross Trigger Interface (CTI). The ARM Cross Trigger Interface provides a way to route events between processor modules. For example, on OMAP4430 we use the CTI module to route PMU events to the GIC interrupt module. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Documentation/devicetree/bindings/arm/cti.txt | 32 + 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cti.txt diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt new file mode 100644 index 000..4a0e2d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cti.txt @@ -0,0 +1,32 @@ +* ARM Cross Trigger Interface (CTI) + +The ARM Cross Trigger Interface provides a way to route events between +processor modules. For example, debug events from one processor can be +broadcasted to other processors. The events that can be routed between +processors are specific to the device. + +Required properties: + +- compatible:Should be arm,primecell. +- interrupts:Interrupt associated with CTI module. +- reg: Contains timer register address range (base + address and length). +- arm,cti-name: A unique name for the CTI module, that will be + used when requesting the CTI module instance. + + +Optional properties: + +- arm-primecell-periphid:Primecell peripheral ID associated with CTI + module. For multi-cluster systems, I wouldn't be surprised to see multiple CTI instances, each with different CPU affinities. Can we include an affinity property following Mark's proposed binding? http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html Will -- 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] OMAP: add pwm driver using dmtimers.
On 12/12/2012 10:33 PM, NeilBrown wrote: On Thu, 13 Dec 2012 14:06:35 +1100 NeilBrown ne...@suse.de wrote: + omap_dm_timer_enable(omap-dm_timer); Do you need to call omap_dm_timer_enable here? _set_load and _set_match will enable the timer. So this should not be necessary. True. That is what you get for copying someone else's code and not understanding it fully. However omap_dm_timer_write_counter *doesn't* enable the timer, and explicitly checks that it is already runtime-enabled. Does that mean I don't need to call omap_dm_timer_write_counter here? Or does it mean that I do need the enable/disable pair? Typically, omap_dm_timer_write_counter() is used to update the counter value while the counter is running and hence is enabled. Looking at the code, some more I now see what they are trying to do. It seems that they are trying to force an overflow to occur as soon as they enable the timer. This will cause the timer to load the count value from the timer load register into the timer counter register. So that does make sense to me. However, this should not be necessary as omap_dm_timer_set_load should do this for you. Therefore, I think that you could accomplish the same thing by doing ... omap_pwm_config -- omap_dm_timer_set_load() -- omap_dm_timer_set_match() -- omap_dm_timer_set_pwm() omap_pwm_enable -- omap_dm_timer_start() If we call _set_load in config then we don't need to call _load_start in the enable, we can just call _start. Can you try this and see if this is working ok? Cheers Jon -- 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/5] ARM: CORESIGHT: Add generic lock/unlock helpers
On 12/13/2012 08:58 AM, Will Deacon wrote:
Hi Jon,
On Wed, Dec 12, 2012 at 09:43:04PM +, Jon Hunter wrote:
The Cross Trigger Interface (CTI) helpers in cti.h include definitions
for the Coresight Lock Access Register (LAR) and Lock Status Register
(LSR). These registers are already defined in coresight.h and so rather
than having multiple definitions, just use the definitions from
coresight.h.
Add the following coresight macros ...
- coresight_unlock() -- Unlocks coresight module
- coresight_lock() -- Locks coresight module
Use the above macros for ETB, ETM and CTI. The do-while(0) statement
has been removed from the macro as it is not a multi-line macro.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/cti.h| 16 +++-
arch/arm/include/asm/hardware/coresight.h | 16
2 files changed, 11 insertions(+), 21 deletions(-)
[...]
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
index 7ecd793..dcd0e66 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -141,17 +141,17 @@
#define ETBFF_TRIGEVT BIT(9)
#define ETBFF_TRIGFLBIT(10)
-#define etb_writel(t, v, x) \
-(__raw_writel((v), (t)-etb_regs + (x)))
+#define etb_writel(t, v, x) (__raw_writel((v), (t)-etb_regs + (x)))
#define etb_readl(t, x) (__raw_readl((t)-etb_regs + (x)))
-#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etm_unlock(t) \
-do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define etb_lock(t) coresight_lock((t)-etb_regs)
+#define etb_unlock(t) coresight_unlock((t)-etb_regs)
+#define etm_lock(t) coresight_lock((t)-etm_regs)
+#define etm_unlock(t) coresight_unlock((t)-etm_regs)
-#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etb_unlock(t) \
-do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
+#define coresight_unlock(base) \
+(__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
#endif /* __ASM_HARDWARE_CORESIGHT_H */
How about we take this opportunity to divorce the more general coresight
bits from the etb specific parts, like you've done for the cti. We could
move the ETB stuff out into asm/etb.h (although it might be nice to keep all
the coresight device headers in one place... answers on a postcard) and just
have the architected coresight functionality in this header.
Yes I have been wondering about that too. Long term it would be good to
find a home in the drivers directory for all these coresight devices
too. For now, we could extract the etb/etm parts from coresight.h into
etb.h and etm.h, respectively.
Cheers
Jon
--
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 2/5] ARM: dts: Add Cross Trigger Interface binding
On 12/13/2012 11:41 AM, Will Deacon wrote: On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote: Adds a device-tree binding for the ARM Cross Trigger Interface (CTI). The ARM Cross Trigger Interface provides a way to route events between processor modules. For example, on OMAP4430 we use the CTI module to route PMU events to the GIC interrupt module. Signed-off-by: Jon Hunter jon-hun...@ti.com --- Documentation/devicetree/bindings/arm/cti.txt | 32 + 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cti.txt diff --git a/Documentation/devicetree/bindings/arm/cti.txt b/Documentation/devicetree/bindings/arm/cti.txt new file mode 100644 index 000..4a0e2d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cti.txt @@ -0,0 +1,32 @@ +* ARM Cross Trigger Interface (CTI) + +The ARM Cross Trigger Interface provides a way to route events between +processor modules. For example, debug events from one processor can be +broadcasted to other processors. The events that can be routed between +processors are specific to the device. + +Required properties: + +- compatible: Should be arm,primecell. +- interrupts: Interrupt associated with CTI module. +- reg: Contains timer register address range (base +address and length). +- arm,cti-name: A unique name for the CTI module, that will be +used when requesting the CTI module instance. + + +Optional properties: + +- arm-primecell-periphid: Primecell peripheral ID associated with CTI +module. For multi-cluster systems, I wouldn't be surprised to see multiple CTI instances, each with different CPU affinities. Can we include an affinity property following Mark's proposed binding? http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html Yes I can take a look. Would something like that be applicable to pmu as well or is that unlikely to have different affinities? I am just wondering if there is something that we should implement in general for the various primecell components. Cheers Jon -- 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 3/5] ARM: CTI: Convert CTI helpers to AMBA bus driver
On 12/13/2012 09:08 AM, Will Deacon wrote:
On Wed, Dec 12, 2012 at 09:43:06PM +, Jon Hunter wrote:
Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
AMBA bus driver so that we can use device-tree to look-up the hardware
specific information such as base address and interrupt number during
the device probe. This also add APIs to request, cti_get() and release,
cti_put(), a CTI module so that drivers can allocate a module at
runtime.
Currently, the driver only supports looking-up the CTI hardware
information via device-tree, however, the driver could be extended to
support non-device-tree configurations if needed for a particular
architecture.
The CTI driver only currently supports CTI modules that have a single
CPU interrupt, however, could be extended in the future to support more
interrupts if a device requires this.
Aha, so elaborating on my earlier comments, we basically want to do the same
thing for ETB I reckon. This does raise the question about namespaces
though...
+/**
+ * struct cti - Cross Trigger Interface (CTI) struct
+ *
+ * @node: Connects CTI instance to list of CTI instances
+ * @dev: Pointer to device structure
+ * @base: Mapped virtual address of the CTI module
+ * @name: Name associated with CTI instance
+ * @irq: Interrupt associated with CTI instance
+ * @trig_out: Trigger output associated with interrupt (@irq)
+ * @reserved: Used to indicate if CTI instance has been allocated
+ * @enabled: Used to indicate if CTI instance has been enabled
+ */
+struct cti {
+ struct list_head node;
+ struct device *dev;
+ void __iomem *base;
+ const char *name;
+ int irq;
+ int trig_out;
+ bool reserved;
+ bool enabled;
+};
+
+#ifdef CONFIG_ARM_AMBA_CTI
+
+int cti_map_trigger(struct cti *cti, int trig_in, int trig_out, int chan);
+int cti_enable(struct cti *cti);
+int cti_disable(struct cti *cti);
+int cti_irq_ack(struct cti *cti);
+struct cti *cti_get(const char *name);
+void cti_put(struct cti *cti);
I wonder whether we should stick these all into a struct and have a general
way to see which coresight devices we have and then retrieve their ops
structures (so things like perf can walk a virtual coresight bus containing
initialised devices).
Yes we could use a struct here. Hopefully, the enable/disable/get/put
could be used across coresight devices. I would need to think more about
the custom functions such as map_trigger which are specific to CTI.
It might also help if we decide to describe the
plumbing in the device tree, like Rob suggested.
Yes, I did propose adding more information to the binding for CTI to
describe trigger-ins/outs for a device. However, we could go a step
further and try and come up with a way to link the devices. Though I am
not sure if there are any other possible use-cases for CTI where that
may not be suitable and we just want to be able to configure it to map
trigger input to trigger output. Anyway, open to any ideas to improve this.
Cheers
Jon
--
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/5] ARM: CORESIGHT: Add generic lock/unlock helpers
Hi Jon, Will,
On Thu, Dec 13, 2012 at 8:18 PM, Jon Hunter jon-hun...@ti.com wrote:
On 12/13/2012 08:58 AM, Will Deacon wrote:
Hi Jon,
On Wed, Dec 12, 2012 at 09:43:04PM +, Jon Hunter wrote:
The Cross Trigger Interface (CTI) helpers in cti.h include definitions
for the Coresight Lock Access Register (LAR) and Lock Status Register
(LSR). These registers are already defined in coresight.h and so rather
than having multiple definitions, just use the definitions from
coresight.h.
Add the following coresight macros ...
- coresight_unlock() -- Unlocks coresight module
- coresight_lock() -- Locks coresight module
Use the above macros for ETB, ETM and CTI. The do-while(0) statement
has been removed from the macro as it is not a multi-line macro.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/include/asm/cti.h| 16 +++-
arch/arm/include/asm/hardware/coresight.h | 16
2 files changed, 11 insertions(+), 21 deletions(-)
[...]
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
index 7ecd793..dcd0e66 100644
--- a/arch/arm/include/asm/hardware/coresight.h
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -141,17 +141,17 @@
#define ETBFF_TRIGEVT BIT(9)
#define ETBFF_TRIGFLBIT(10)
-#define etb_writel(t, v, x) \
-(__raw_writel((v), (t)-etb_regs + (x)))
+#define etb_writel(t, v, x) (__raw_writel((v), (t)-etb_regs + (x)))
#define etb_readl(t, x) (__raw_readl((t)-etb_regs + (x)))
-#define etm_lock(t) do { etm_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etm_unlock(t) \
-do { etm_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define etb_lock(t) coresight_lock((t)-etb_regs)
+#define etb_unlock(t) coresight_unlock((t)-etb_regs)
+#define etm_lock(t) coresight_lock((t)-etm_regs)
+#define etm_unlock(t) coresight_unlock((t)-etm_regs)
-#define etb_lock(t) do { etb_writel((t), 0, CSMR_LOCKACCESS); } while (0)
-#define etb_unlock(t) \
-do { etb_writel((t), UNLOCK_MAGIC, CSMR_LOCKACCESS); } while (0)
+#define coresight_lock(base) (__raw_writel(0, base + CSMR_LOCKACCESS))
+#define coresight_unlock(base) \
+(__raw_writel(UNLOCK_MAGIC, base + CSMR_LOCKACCESS))
#endif /* __ASM_HARDWARE_CORESIGHT_H */
How about we take this opportunity to divorce the more general coresight
bits from the etb specific parts, like you've done for the cti. We could
move the ETB stuff out into asm/etb.h (although it might be nice to keep all
the coresight device headers in one place... answers on a postcard) and just
have the architected coresight functionality in this header.
Yes I have been wondering about that too. Long term it would be good to
find a home in the drivers directory for all these coresight devices
too. For now, we could extract the etb/etm parts from coresight.h into
etb.h and etm.h, respectively.
I am now writing a HW trace driver that extracts traces from the CMI
and PMI IP blocks (and later L2CC). It is still in early development
status.
The idea I have in mind is to have the implementation in
drivers/power/hw_trace. Eventually this directory would contain the
drivers for ETM/ETB, CMI, PMI and also the coresight support. It would
be architected so that the lower level drivers export the necessary
functions for the higher level code to use the resource. Example: the
PMI driver would use the ETB and coresight drivers.
What do you think?
Regards,
Jean
Cheers
Jon
--
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
--
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
cpts: Fix build error caused by include of plat/clock.h
Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Otherwise we get the following error with at least omap2plus_defconfig: drivers/net/ethernet/ti/cpts.c:30:24: error: plat/clock.h: No such file or directory Signed-off-by: Tony Lindgren t...@atomide.com --- a/drivers/net/ethernet/ti/cpts.c +++ b/drivers/net/ethernet/ti/cpts.c @@ -27,8 +27,6 @@ #include linux/uaccess.h #include linux/workqueue.h -#include plat/clock.h - #include cpts.h #ifdef CONFIG_TI_CPTS -- 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 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Hi Samuel,
* Roger Quadros rog...@ti.com [121210 02:23]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h
for omaps by -rc1 before more drivers start using it again.
That is assuming nobody else is planning on merging this series for
v3.8 presumably. Want to ack this one?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-host.c |4
drivers/mfd/omap-usb-host.c|2 +-
include/linux/platform_data/usb-omap.h |3 +++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..2e44e8a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -508,6 +508,10 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
+
+ if (omap_rev() = OMAP3430_REV_ES2_1)
+ usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index cebfe0a..fe7906b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -384,7 +384,7 @@ static void omap_usbhs_init(struct device *dev)
reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
- if (cpu_is_omap3430() (omap_rev() = OMAP3430_REV_ES2_1)) {
+ if (pdata-single_ulpi_bypass) {
dev_dbg(dev, OMAP3 ES version = ES2.1\n);
if (is_ehci_phy_mode(pdata-port_mode[0]) ||
is_ehci_phy_mode(pdata-port_mode[1]) ||
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..ef65b67 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -59,6 +59,9 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
+
+ /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
+ unsignedsingle_ulpi_bypass:1;
};
/*-*/
--
1.7.4.1
--
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/1] ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio
On Tue, Nov 27, 2012 at 10:58 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 11/27/2012 02:21 AM, Javier Martinez Canillas wrote: Many TI OMAP SoC based boards that uses twl4030 as codec have been updated to use the unified audio driver (omap-twl4030) since they have similar audio setup. So, is good to have it built to add audio support to these boards. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I also agree that it is a good practice to enable this in the defconfig. Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Hi Tony, Any comments on this patch? Best regards, Javier -- 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/1] ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio
* Javier Martinez Canillas martinez.jav...@gmail.com [121213 16:01]: On Tue, Nov 27, 2012 at 10:58 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 11/27/2012 02:21 AM, Javier Martinez Canillas wrote: Many TI OMAP SoC based boards that uses twl4030 as codec have been updated to use the unified audio driver (omap-twl4030) since they have similar audio setup. So, is good to have it built to add audio support to these boards. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I also agree that it is a good practice to enable this in the defconfig. Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Hi Tony, Any comments on this patch? No looks just fine to me. Let's see if we can get it merged after the merge window related issues are dealt with. Regards, Tony -- 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] drm/lcdc: add TI LCD Controller DRM driver
A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
CMA helpers. Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape). There are also various LCD
displays, for which support can be added (as I get hw to test on),
and an external i2c HDMI encoder found on some boards.
The display controller supports a single CRTC. And the encoder+
connector are split out into sub-devices. Depending on which LCD
or external encoder is actually present, the appropriate output
module(s) will be loaded.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/lcdc/Kconfig | 11 +
drivers/gpu/drm/lcdc/Makefile | 8 +
drivers/gpu/drm/lcdc/lcdc_crtc.c | 544 +
drivers/gpu/drm/lcdc/lcdc_drv.c| 604 +
drivers/gpu/drm/lcdc/lcdc_drv.h| 162 ++
drivers/gpu/drm/lcdc/lcdc_regs.h | 154 ++
drivers/gpu/drm/lcdc/lcdc_tfp410.c | 424 ++
drivers/gpu/drm/lcdc/lcdc_tfp410.h | 26 ++
10 files changed, 1936 insertions(+)
create mode 100644 drivers/gpu/drm/lcdc/Kconfig
create mode 100644 drivers/gpu/drm/lcdc/Makefile
create mode 100644 drivers/gpu/drm/lcdc/lcdc_crtc.c
create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.c
create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.h
create mode 100644 drivers/gpu/drm/lcdc/lcdc_regs.h
create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.c
create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 983201b..255efcb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -212,3 +212,5 @@ source drivers/gpu/drm/cirrus/Kconfig
source drivers/gpu/drm/shmobile/Kconfig
source drivers/gpu/drm/tegra/Kconfig
+
+source drivers/gpu/drm/lcdc/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6f58c81..8e0a19a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -50,4 +50,5 @@ obj-$(CONFIG_DRM_UDL) += udl/
obj-$(CONFIG_DRM_AST) += ast/
obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
obj-$(CONFIG_DRM_TEGRA) += tegra/
+obj-$(CONFIG_DRM_LCDC) += lcdc/
obj-y += i2c/
diff --git a/drivers/gpu/drm/lcdc/Kconfig b/drivers/gpu/drm/lcdc/Kconfig
new file mode 100644
index 000..084b0a0
--- /dev/null
+++ b/drivers/gpu/drm/lcdc/Kconfig
@@ -0,0 +1,11 @@
+config DRM_LCDC
+ tristate DRM Support for TI LCDC Display Controller
+ depends on DRM OF
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_GEM_CMA_HELPER
+ help
+ Choose this option if you have an TI SoC with LCDC display
+ controller, for example AM33xx in beagle-bone, DA8xx, or
+ OMAP-L1xx. This driver replaces the FB_DA8XX fbdev driver.
+
diff --git a/drivers/gpu/drm/lcdc/Makefile b/drivers/gpu/drm/lcdc/Makefile
new file mode 100644
index 000..db32161
--- /dev/null
+++ b/drivers/gpu/drm/lcdc/Makefile
@@ -0,0 +1,8 @@
+ccflags-y := -Iinclude/drm -Werror
+
+lcdc-y := \
+ lcdc_crtc.o \
+ lcdc_tfp410.o \
+ lcdc_drv.o
+
+obj-$(CONFIG_DRM_LCDC) += lcdc.o
diff --git a/drivers/gpu/drm/lcdc/lcdc_crtc.c b/drivers/gpu/drm/lcdc/lcdc_crtc.c
new file mode 100644
index 000..052c2c1
--- /dev/null
+++ b/drivers/gpu/drm/lcdc/lcdc_crtc.c
@@ -0,0 +1,544 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark robdcl...@gmail.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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include lcdc_drv.h
+#include lcdc_regs.h
+
+struct lcdc_crtc {
+ struct drm_crtc base;
+
+ const struct lcdc_panel_info *info;
+ uint32_t dirty;
+ dma_addr_t start, end;
+ struct drm_pending_vblank_event *event;
+ int dpms;
+ wait_queue_head_t frame_done_wq;
+ bool frame_done;
+};
+#define to_lcdc_crtc(x) container_of(x, struct lcdc_crtc, base)
+
+static void set_scanout(struct drm_crtc *crtc, uint32_t stat)
+{
+ struct lcdc_crtc *lcdc_crtc = to_lcdc_crtc(crtc);
+ struct drm_device *dev = crtc-dev;
+
+ pm_runtime_get_sync(dev-dev);
+ if (stat LCDC_END_OF_FRAME0) {
+ lcdc_write(dev, LCDC_DMA_FRM_BUF_BASE_ADDR_0_REG,
+ lcdc_crtc-start);
+ lcdc_write(dev,
Re: [PATCH v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Hi Tony, On Thu, Dec 13, 2012 at 01:49:49PM -0800, Tony Lindgren wrote: Hi Samuel, * Roger Quadros rog...@ti.com [121210 02:23]: Instead of using cpu_is_omap..() macros in the device driver we rely on information provided in the platform data. The only information we need is whether the USB Host module has a single ULPI bypass control bit for all ports or individual bypass control bits for each port. OMAP3 REV2.1 and earlier have the former. I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h for omaps by -rc1 before more drivers start using it again. That is assuming nobody else is planning on merging this series for v3.8 presumably. This should go into 3.9, yes. Want to ack this one? Looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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: [RESEND PATCH v3 1/6] watchdog: omap_wdt: convert to new watchdog core
* Sebastian Reichel s...@debian.org [121213 17:26]: On Mon, Nov 12, 2012 at 02:47:03PM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [121112 10:49]: Convert omap_wdt to new watchdog core. On OMAP boards, there are usually multiple watchdogs. Since the new watchdog core supports multiple watchdogs, all watchdog drivers used on OMAP should be converted. The legacy watchdog device node is still created, so this should not break existing users. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Tested-by: Jarkko Nikula jarkko.nik...@jollamobile.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Wim Van Sebroeck w...@iguana.be Wim, looks like these will cause merge conflicts with what we have already queued in omap-for-v3.8/cleanup-prcm as patch watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr along with other ARM multiplatform related clean up. If these look ackable to you, I can queue these that's OK to you. What's the status of this patchset? If I'm not mistaken it is neither included in linux-omap, nor in linux-watchdog-next. It should be all linux-watchdog-next with what got merged into the mainline kernel today. No more arch/arm/*omap*/ dependencies AFAIK. Regards, Tony -- 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: [RESEND PATCH v3 1/6] watchdog: omap_wdt: convert to new watchdog core
On Mon, Nov 12, 2012 at 02:47:03PM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [121112 10:49]: Convert omap_wdt to new watchdog core. On OMAP boards, there are usually multiple watchdogs. Since the new watchdog core supports multiple watchdogs, all watchdog drivers used on OMAP should be converted. The legacy watchdog device node is still created, so this should not break existing users. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Tested-by: Jarkko Nikula jarkko.nik...@jollamobile.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Wim Van Sebroeck w...@iguana.be Wim, looks like these will cause merge conflicts with what we have already queued in omap-for-v3.8/cleanup-prcm as patch watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr along with other ARM multiplatform related clean up. If these look ackable to you, I can queue these that's OK to you. What's the status of this patchset? If I'm not mistaken it is neither included in linux-omap, nor in linux-watchdog-next. -- Sebastian signature.asc Description: Digital signature
Re: [RESEND PATCH v3 1/6] watchdog: omap_wdt: convert to new watchdog core
Hi Tony, On Thu, Dec 13, 2012 at 05:32:57PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [121213 17:26]: What's the status of this patchset? If I'm not mistaken it is neither included in linux-omap, nor in linux-watchdog-next. It should be all linux-watchdog-next with what got merged into the mainline kernel today. No more arch/arm/*omap*/ dependencies AFAIK. I can see the dependency fixes, but the driver itself is still using miscdevice instead of the new watchdog core: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/watchdog/omap_wdt.c;b=master This patch is not needed for using the watchdog on a multiplatform kernel, but using multiple watchdogs (i.e. twl4030_wdt and omap_wdt) at the same time. It also simplifies the driver. -- Sebastian signature.asc Description: Digital signature
Re: [RESEND PATCH v3 1/6] watchdog: omap_wdt: convert to new watchdog core
Hi, On Fri, Dec 14, 2012 at 02:23:36AM +0100, Sebastian Reichel wrote: On Mon, Nov 12, 2012 at 02:47:03PM -0800, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [121112 10:49]: Convert omap_wdt to new watchdog core. On OMAP boards, there are usually multiple watchdogs. Since the new watchdog core supports multiple watchdogs, all watchdog drivers used on OMAP should be converted. The legacy watchdog device node is still created, so this should not break existing users. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Tested-by: Jarkko Nikula jarkko.nik...@jollamobile.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Cc: Wim Van Sebroeck w...@iguana.be Wim, looks like these will cause merge conflicts with what we have already queued in omap-for-v3.8/cleanup-prcm as patch watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr along with other ARM multiplatform related clean up. If these look ackable to you, I can queue these that's OK to you. What's the status of this patchset? If I'm not mistaken it is neither included in linux-omap, nor in linux-watchdog-next. Since it's not in -next, then I guess it won't appear in 3.8. Once the 3.8-rc1 is out, I will continue rebasing/retesting/resending the patch set... A. -- 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] watchdog: Convert twl4030_wdt to watchdog core
Hi, On Thu, Sep 27, 2012 at 11:23:12PM +0200, Wim Van Sebroeck wrote: On 09/11/2012 09:01 AM, Jarkko Nikula wrote: Convert the twl4030_wdt watchdog driver to watchdog core. While at there use devm_kzalloc and set the default timeout in order to be able test this driver with a simple shell script. Signed-off-by: Jarkko Nikulajarkko.nik...@jollamobile.com Tested-by: Aaro Koskinenaaro.koski...@iki.fi on my todo list. Will this patch get into 3.8? I did not yet see it in linux-watchdog-next.git. -- Sebastian signature.asc Description: Digital signature
[PATCH v2 2/8] ARM: OMAP2+: omap2plus_defconfig: Enable tps65910 PMIC
AM335X-EVM and AM335X-EVMSK devices have tps65910 PMIC regulator, one has to manually enable this support to use regulators. So this patch enables tps65910 mfd and regulator driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 19b7311..27bf465 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -133,10 +133,12 @@ CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65910=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 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
[PATCH v2 5/8] ARM: OMAP2+: omap2plus_defconfig: Enable matrix keypad driver
AM335X-EVM device have 3x2 matrix keypad, one has to manually enable this support to use matrix keypad. So this patch enables matrix keypad driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index f0d6afb..c004d9b 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -109,6 +109,7 @@ CONFIG_USB_KC2190=y CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y +CONFIG_KEYBOARD_MATRIX=y CONFIG_KEYBOARD_TWL4030=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y -- 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
[PATCH v2 0/8] ARM: OMAP2+: AM33XX: Enable few drivers in omap2plus_defconfig
This patch series enable tps65910, lis3lv02d accelerometer, tsl2550 ambient light sensor, matrix keypad, tmp275 temperature sensor, gpio leds and D_CAN drivers in omap2plus_defconfig. These are the peripherals present in AM33XX family of devices. Changes from v1: - Incorporated martinez javier's comments on v1 * Enabled few more triggers in omap2plus_defconfig - Included Igor's patch, which modifies the omap2plus defconfig for AM33XX devices. AnilKumar Ch (7): ARM: OMAP2+: omap2plus_defconfig: Enable tps65910 PMIC ARM: OMAP2+: omap2plus_defconfig: Enable lis3lv02d accelerometer ARM: OMAP2+: omap2plus_defconfig: Enable tsl2550 ambient light sensor ARM: OMAP2+: omap2plus_defconfig: Enable matrix keypad driver ARM: OMAP2+: omap2plus_defconfig: Enable tmp275 sensor ARM: OMAP2+: omap2plus_defconfig: Enable leds-gpio driver ARM: OMAP2+: omap2plus_defconfig: Enable DCAN controller Igor Mazanov (1): ARM: OMAP2+: omap2plus_defconfig: Enable tps65217 PMIC arch/arm/configs/omap2plus_defconfig | 24 1 file changed, 24 insertions(+) -- 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
[PATCH v2 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable DCAN controller
AM335X-EVM has BOSCH DCAN controller, one has to manually enable this support to use of DCAN controller. So this patch enables DCAN driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b0ad0b0..0ce6771 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -52,6 +52,11 @@ CONFIG_IP_PNP_RARP=y # CONFIG_INET_LRO is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y +CONFIG_CAN=y +CONFIG_CAN_RAW=y +CONFIG_CAN_BCM=y +CONFIG_CAN_C_CAN=y +CONFIG_CAN_C_CAN_PLATFORM=y CONFIG_BT=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y -- 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
[PATCH v2 6/8] ARM: OMAP2+: omap2plus_defconfig: Enable tmp275 sensor
AM335x-evm device have temperature sensor, one has to manually enable this support to use of temperature sensor. So this patch enables tmp275 driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c004d9b..e1d2385 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -133,6 +133,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_GPIO_TWL4030=y CONFIG_W1=y CONFIG_POWER_SUPPLY=y +CONFIG_SENSORS_LM75=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -- 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
[PATCH v2 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable leds-gpio driver
AM335X-EVMSK and AM335X-BONE devices have gpio controlled user leds, one has to manually enable this support to use user leds. So this patch enables gpio-leds driver in omap2plus_defconfig. Also enables different TRIGGERS like TRIGGER_TIMER, TRIGGER_HEARTBEAT and etc. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index e1d2385..b0ad0b0 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -200,6 +200,16 @@ CONFIG_MMC_UNSAFE_RESUME=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_TIMER=y +CONFIG_LEDS_TRIGGER_ONESHOT=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_BACKLIGHT=y +CONFIG_LEDS_TRIGGER_CPU=y +CONFIG_LEDS_TRIGGER_GPIO=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y -- 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
[PATCH v2 3/8] ARM: OMAP2+: omap2plus_defconfig: Enable lis3lv02d accelerometer
AM335X-EVM and AM335X-EVMSK devices have lis331dlh accelerometer, one has to manually enable this support to use accelerometer. So this patch enables lis3lv02d driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 27bf465..417a320 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -81,6 +81,8 @@ CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 +CONFIG_SENSORS_LIS3LV02D=y +CONFIG_SENSORS_LIS3_I2C=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_MULTI_LUN=y -- 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
[PATCH v2 1/8] ARM: OMAP2+: omap2plus_defconfig: Enable tps65217 PMIC
From: Igor Mazanov i.maza...@gmail.com The BeagleBone platform uses TPS65217 PMIC to control voltages on the board. This patch enables TPS65217 MFD and regulator drivers in omap2plus_defconfig. Signed-off-by: Igor Mazanov i.maza...@gmail.com Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a1dc5c0..19b7311 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -132,9 +132,11 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_TPS65217=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TPS65217=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 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
[PATCH v2 4/8] ARM: OMAP2+: omap2plus_defconfig: Enable tsl2550 ambient light sensor
AM335x-evm device have tsl2550 ambient light sensor, one has to manually enable this support to use light sensor. So this patch enables tsl2550 driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 417a320..f0d6afb 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -82,6 +82,7 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SENSORS_LIS3LV02D=y +CONFIG_SENSORS_TSL2550=y CONFIG_SENSORS_LIS3_I2C=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -- 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
[PATCH v4 2/4] ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone
Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5302f79..e7dff9d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -88,6 +88,8 @@
/include/ tps65217.dtsi
tps {
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-always-on;
--
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
[PATCH v4 0/4] pm: Add power off control
Add PM power_off control to rtc driver and PMIC status is set to STATUS_OFF to shutdown PMIC if PWR_EN is toggled by RTC module. System power off sequence:- * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low * Enable PMIC_POWER_EN in rtc module * Set rtc ALARM2 time * Enable ALARM2 interrupt These patches were tested on am335x-bone (BeagleBone). These patchs are based on linux-next. Changes from v3: - TPS65217 mfd driver changes are accepted so dropped from this series. - With recent changes in the kernel, reboot_mutex held BUG() is not seen so removed while(1); from rtc_power_off. - Removed spinlock before while(1); which is not necessary. Changes from v2: - Incorporated Kevin's comment on v2 * Enabled RTC in ompa2plus_defconfig Changes from v1: - Incorporated Vaibhav's comments on v1 * Changed the time rollover logic with the help of rtc-lib APIs AnilKumar Ch (3): ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone ARM: dts: AM33XX: Enable system power off control in am335x-bone ARM: OMAP2+: omap2plus_defconfig: Enable RTC support Colin Foe-Parker (1): rtc: OMAP: Add system pm_power_off to rtc driver Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++ arch/arm/boot/dts/am335x-bone.dts |6 ++ arch/arm/configs/omap2plus_defconfig |1 + drivers/rtc/rtc-omap.c | 74 +++- 4 files changed, 85 insertions(+), 1 deletion(-) -- 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
[PATCH v4 3/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index e7dff9d..febbe2f 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -52,6 +52,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
leds {
--
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
[PATCH v4 4/4] ARM: OMAP2+: omap2plus_defconfig: Enable RTC support
AM33XX family of devices use RTC module, one has to manually enable this support to use RTC features. So this patch enable RTC driver in omap2plus_defconfig. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 0ce6771..e58afc5 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -216,6 +216,7 @@ CONFIG_LEDS_TRIGGER_CPU=y CONFIG_LEDS_TRIGGER_GPIO=y CONFIG_LEDS_TRIGGER_DEFAULT_ON=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_OMAP=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y CONFIG_DMADEVICES=y -- 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
[PATCH v4 1/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 74 +++-
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..e6d4878 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,56 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ unsigned long time;
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+* pmic_pwr_enable is controlled by means of ALARM2 event. So here
+* programming alarm2 expiry time and enabling alarm2 interrupt
+*/
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
+ val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
+ writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+ rtc_base + OMAP_RTC_INTERRUPTS_REG);
+}
+
static struct rtc_class_ops omap_rtc_ops = {
.read_time = omap_rtc_read_time,
.set_time = omap_rtc_set_time,
@@ -327,12 +391,16 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
struct resource *res, *mem;
struct rtc_device
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman khil...@deeprootsystems.com
wrote:
OK thanks, I'll queue this up for v3.6-rc as this should qualify as a
regression.
I don't think this did actually get queued. At least I'm still seeing the
bug in 3.7 and I cannot see a patch in the git history that looks right.
But then I don't remember what we ended up with - it was 3 months ago!!!
This is the last thing I can find in my email history - it still seems to
apply and still seems to work.
NeilBrown
From: NeilBrown ne...@suse.de
Date: Mon, 10 Sep 2012 14:09:06 +1000
Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Current kernel will wake from suspend on an event an any active
GPIO event if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4fbc208..79e1340 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -57,6 +57,7 @@ struct gpio_bank {
u16 irq;
int irq_base;
struct irq_domain *domain;
+ u32 suspend_wakeup;
u32 non_wakeup_gpios;
u32 enabled_non_wakeup_gpios;
struct gpio_regs context;
@@ -522,11 +523,9 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
spin_lock_irqsave(bank-lock, flags);
if (enable)
- bank-context.wake_en |= gpio_bit;
+ bank-suspend_wakeup |= gpio_bit;
else
- bank-context.wake_en = ~gpio_bit;
-
- __raw_writel(bank-context.wake_en, bank-base + bank-regs-wkup_en);
+ bank-suspend_wakeup = ~gpio_bit;
spin_unlock_irqrestore(bank-lock, flags);
return 0;
@@ -1157,6 +1156,49 @@ static int __devinit omap_gpio_probe(struct
platform_device *pdev)
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM_RUNTIME)
+
+#if defined(CONFIG_PM_SLEEP)
+static int omap_gpio_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned long flags;
+
+ if (!bank-mod_usage ||
+ !bank-regs-wkup_en ||
+ !bank-context.wake_en)
+ return 0;
+
+ spin_lock_irqsave(bank-lock, flags);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-suspend_wakeup, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ return 0;
+}
+
+static int omap_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+ void __iomem *base = bank-base;
+ unsigned long flags;
+
+ if (!bank-mod_usage ||
+ !bank-regs-wkup_en ||
+ !bank-context.wake_en)
+ return 0;
+
+ spin_lock_irqsave(bank-lock, flags);
+ _gpio_rmw(base, bank-regs-wkup_en, 0x, 0);
+ _gpio_rmw(base, bank-regs-wkup_en, bank-context.wake_en, 1);
+ spin_unlock_irqrestore(bank-lock, flags);
+
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
static void omap_gpio_restore_context(struct gpio_bank *bank);
static int omap_gpio_runtime_suspend(struct device *dev)
@@ -1386,11 +1428,14 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
}
#endif /* CONFIG_PM_RUNTIME */
#else
+#define omap_gpio_suspend NULL
+#define omap_gpio_resume NULL
#define omap_gpio_runtime_suspend NULL
#define omap_gpio_runtime_resume NULL
#endif
static const struct dev_pm_ops gpio_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(omap_gpio_suspend, omap_gpio_resume)
SET_RUNTIME_PM_OPS(omap_gpio_runtime_suspend,
Re: cpts: Fix build error caused by include of plat/clock.h
On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote: Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock) mistakenly included plat/clock.h that should not be included by drivers even if it exists. Hasn't this already been fixed? https://patchwork.kernel.org/patch/1810481/ http://www.spinics.net/lists/linux-omap/msg83132.html Thanks, Richard -- 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 0/2] ARM: OMAP4: clock data fixes for early 3.8-rc
A few bugs in the OMAP4 common clock framework data caused boot-time warnings on OMAP4460 PandaBoard-ES; these patches fix those. They apply after the arm-soc merge during pre-3.8-rc1. Also needed are Jon Hunter's clock fixes series; the pull request will combine his patches and this series. - Paul --- Paul Walmsley (2): ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent lists arch/arm/mach-omap2/cclock44xx_data.c | 37 + 1 file changed, 28 insertions(+), 9 deletions(-) -- 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 2/2] ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent lists
Booting OMAP4460 Pandaboard ES with a recent u-boot results in this
warning:
WARNING: at arch/arm/mach-omap2/dpll3xxx.c:427
omap3_noncore_dpll_enable+0xf4/0x110()
The OMAP4 DPLL parent clock name arrays only listed the reference
clocks, not the bypass clocks. Fix by adding the bypass clocks to the
DPLL parent lists.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mike Turquette mturque...@linaro.org
---
arch/arm/mach-omap2/cclock44xx_data.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index a3c54b2..4536bae 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -233,7 +233,7 @@ static struct dpll_data dpll_core_dd = {
static const char *dpll_core_ck_parents[] = {
- sys_clkin_ck,
+ sys_clkin_ck, core_hsd_byp_clk_mux_ck
};
static struct clk dpll_core_ck;
@@ -363,6 +363,10 @@ static struct dpll_data dpll_iva_dd = {
.min_divider= 1,
};
+static const char *dpll_iva_ck_parents[] = {
+ sys_clkin_ck, iva_hsd_byp_clk_mux_ck
+};
+
static struct clk dpll_iva_ck;
static struct clk_hw_omap dpll_iva_ck_hw = {
@@ -373,7 +377,7 @@ static struct clk_hw_omap dpll_iva_ck_hw = {
.ops= clkhwops_omap3_dpll,
};
-DEFINE_STRUCT_CLK(dpll_iva_ck, dpll_core_ck_parents, dpll_abe_ck_ops);
+DEFINE_STRUCT_CLK(dpll_iva_ck, dpll_iva_ck_parents, dpll_abe_ck_ops);
static const char *dpll_iva_x2_ck_parents[] = {
dpll_iva_ck,
@@ -416,6 +420,10 @@ static struct dpll_data dpll_mpu_dd = {
.min_divider= 1,
};
+static const char *dpll_mpu_ck_parents[] = {
+ sys_clkin_ck, div_mpu_hs_clk
+};
+
static struct clk dpll_mpu_ck;
static struct clk_hw_omap dpll_mpu_ck_hw = {
@@ -426,7 +434,7 @@ static struct clk_hw_omap dpll_mpu_ck_hw = {
.ops= clkhwops_omap3_dpll,
};
-DEFINE_STRUCT_CLK(dpll_mpu_ck, dpll_core_ck_parents, dpll_abe_ck_ops);
+DEFINE_STRUCT_CLK(dpll_mpu_ck, dpll_mpu_ck_parents, dpll_abe_ck_ops);
DEFINE_CLK_FIXED_FACTOR(mpu_periphclk, dpll_mpu_ck, dpll_mpu_ck, 0x0, 1, 2);
@@ -464,6 +472,9 @@ static struct dpll_data dpll_per_dd = {
.min_divider= 1,
};
+static const char *dpll_per_ck_parents[] = {
+ sys_clkin_ck, per_hsd_byp_clk_mux_ck
+};
static struct clk dpll_per_ck;
@@ -475,7 +486,7 @@ static struct clk_hw_omap dpll_per_ck_hw = {
.ops= clkhwops_omap3_dpll,
};
-DEFINE_STRUCT_CLK(dpll_per_ck, dpll_core_ck_parents, dpll_abe_ck_ops);
+DEFINE_STRUCT_CLK(dpll_per_ck, dpll_per_ck_parents, dpll_abe_ck_ops);
DEFINE_CLK_DIVIDER(dpll_per_m2_ck, dpll_per_ck, dpll_per_ck, 0x0,
OMAP4430_CM_DIV_M2_DPLL_PER, OMAP4430_DPLL_CLKOUT_DIV_SHIFT,
@@ -559,6 +570,10 @@ static struct dpll_data dpll_usb_dd = {
.min_divider= 1,
};
+static const char *dpll_usb_ck_parents[] = {
+ sys_clkin_ck, usb_hs_clk_div_ck
+};
+
static struct clk dpll_usb_ck;
static struct clk_hw_omap dpll_usb_ck_hw = {
@@ -569,7 +584,7 @@ static struct clk_hw_omap dpll_usb_ck_hw = {
.ops= clkhwops_omap3_dpll,
};
-DEFINE_STRUCT_CLK(dpll_usb_ck, dpll_core_ck_parents, dpll_abe_ck_ops);
+DEFINE_STRUCT_CLK(dpll_usb_ck, dpll_usb_ck_parents, dpll_abe_ck_ops);
static const char *dpll_usb_clkdcoldo_ck_parents[] = {
dpll_usb_ck,
@@ -696,9 +711,13 @@ DEFINE_CLK_DIVIDER(syc_clk_div_ck, sys_clkin_ck,
sys_clkin_ck, 0x0,
OMAP4430_CM_ABE_DSS_SYS_CLKSEL, OMAP4430_CLKSEL_0_0_SHIFT,
OMAP4430_CLKSEL_0_0_WIDTH, 0x0, NULL);
+static const char *dbgclk_mux_ck_parents[] = {
+ sys_clkin_ck
+};
+
static struct clk dbgclk_mux_ck;
DEFINE_STRUCT_CLK_HW_OMAP(dbgclk_mux_ck, NULL);
-DEFINE_STRUCT_CLK(dbgclk_mux_ck, dpll_core_ck_parents,
+DEFINE_STRUCT_CLK(dbgclk_mux_ck, dbgclk_mux_ck_parents,
dpll_usb_clkdcoldo_ck_ops);
/* Leaf clocks controlled by modules */
--
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 1/2] ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider
The OMAP4 clock divider div_iva_hs_clk is listed in the clock data as an OMAP HSDIVIDER, but it's actually a power-of-two divider. This causes a warning during boot on an OMAP4460 Pandaboard-ES with a recent u-boot: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:143 omap2_clksel_recalc+0xf4/0x12c() clock: div_iva_hs_clk: could not find fieldval 0 for parent dpll_core_m5x2_ck Fix by converting the data for this clock to a power-of-two divider. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@linaro.org --- arch/arm/mach-omap2/cclock44xx_data.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c index aa56c3e..a3c54b2 100644 --- a/arch/arm/mach-omap2/cclock44xx_data.c +++ b/arch/arm/mach-omap2/cclock44xx_data.c @@ -286,9 +286,9 @@ DEFINE_CLK_DIVIDER(div_core_ck, dpll_core_m5x2_ck, dpll_core_m5x2_ck, 0x0, OMAP4430_CM_CLKSEL_CORE, OMAP4430_CLKSEL_CORE_SHIFT, OMAP4430_CLKSEL_CORE_WIDTH, 0x0, NULL); -DEFINE_CLK_OMAP_HSDIVIDER(div_iva_hs_clk, dpll_core_m5x2_ck, - dpll_core_m5x2_ck, 0x0, OMAP4430_CM_BYPCLK_DPLL_IVA, - OMAP4430_CLKSEL_0_1_MASK); +DEFINE_CLK_DIVIDER(div_iva_hs_clk, dpll_core_m5x2_ck, dpll_core_m5x2_ck, + 0x0, OMAP4430_CM_BYPCLK_DPLL_IVA, OMAP4430_CLKSEL_0_1_SHIFT, + OMAP4430_CLKSEL_0_1_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL); DEFINE_CLK_DIVIDER(div_mpu_hs_clk, dpll_core_m5x2_ck, dpll_core_m5x2_ck, 0x0, OMAP4430_CM_BYPCLK_DPLL_MPU, OMAP4430_CLKSEL_0_1_SHIFT, -- 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] watchdog: Convert twl4030_wdt to watchdog core
Hi On 12/14/2012 03:28 AM, Sebastian Reichel wrote: Hi, On Thu, Sep 27, 2012 at 11:23:12PM +0200, Wim Van Sebroeck wrote: On 09/11/2012 09:01 AM, Jarkko Nikula wrote: Convert the twl4030_wdt watchdog driver to watchdog core. While at there use devm_kzalloc and set the default timeout in order to be able test this driver with a simple shell script. Signed-off-by: Jarkko Nikulajarkko.nik...@jollamobile.com Tested-by: Aaro Koskinenaaro.koski...@iki.fi on my todo list. Will this patch get into 3.8? I did not yet see it in linux-watchdog-next.git. I've been wondering the same. How to get forward with this patch? -- Jarkko -- 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
