Re: ARM errata 430973 on multi platform kernels
On 23 April 2015 at 12:25, Russell King - ARM Linux li...@arm.linux.org.uk wrote: And you can't detect whether you're running in secure mode or not. If not, you get an undefined instruction exception, which you could trap. This may not be convenient, but can't detect is an overstatement. Matthijs -- 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 0/5] PM / clock_ops: provide default runtime ops and cleanup users
On 23 April 2015 at 10:33, Rajendra Nayak rna...@codeaurora.org wrote: Most users of PM clocks do the exact same thing in runtime callbacks. Provide default callbacks and cleanup the existing users (keystone/davinci /omap1/sh) Rajendra Nayak (5): PM / clock_ops: Provide default runtime ops to users arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arch/arm/mach-davinci/pm_domain.c | 32 +- arch/arm/mach-keystone/pm_domain.c | 33 +- arch/arm/mach-omap1/pm_bus.c | 37 ++ drivers/base/power/clock_ops.c | 38 ++ drivers/sh/pm_runtime.c| 47 ++ include/linux/pm_clock.h | 10 6 files changed, 54 insertions(+), 143 deletions(-) I guess you don't need more acks/reviewed by for this patchset. Still, and also for my own reference. Acked-by: Ulf Hansson ulf.hans...@linaro.org Kind regards Uffe -- 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 22/04/2015 at 19:04:52 -0500, Nishanth Menon wrote : I fully agree that your patch doesn't change the behaviour for the other cases you presented and further clean up is to be done in a separate set of patches. Sure, Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: [PATCH] mmc: core: add missing pm event in mmc_pm_notify to fix hib restore
On 04/23/2015 04:19 PM, Ulf Hansson wrote: On 23 April 2015 at 12:43, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Huh, that was an old bug you found. :-) oh yes. it's happened thanks to HW issue on my board which generates a flood of SDCD IRQs :) It's the worst case ever to track wrong/missed PM notifiers ( I have applied it for fixes and added the below fixes tag. Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume) Thanks. -- regards, -grygorii -- 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 0/5] PM / clock_ops: provide default runtime ops and cleanup users
On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote: Most users of PM clocks do the exact same thing in runtime callbacks. Provide default callbacks and cleanup the existing users (keystone/davinci /omap1/sh) Rajendra Nayak (5): PM / clock_ops: Provide default runtime ops to users arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arch/arm/mach-davinci/pm_domain.c | 32 +- arch/arm/mach-keystone/pm_domain.c | 33 +- arch/arm/mach-omap1/pm_bus.c | 37 ++ drivers/base/power/clock_ops.c | 38 ++ drivers/sh/pm_runtime.c| 47 ++ include/linux/pm_clock.h | 10 6 files changed, 54 insertions(+), 143 deletions(-) It is not particularly clear to me who is supposed to apply this series, but I can do that if people don't have problems with that. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 12:54 PM, Suman Anna wrote: The L3 Error handling on OMAP5 for the most part is very similar to that of OMAP4, and had leveraged common data structures and register layout definitions so far. Upon closer inspection, there are a few minor differences causing an incorrect decoding and reporting of the master NIU upon an error: 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies 11 bits on OMAP5 as against 8 bits on OMAP4, with the master NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR field. 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3 input sources on OMAP5. The common DEBUGSS source is at a different input on each SoC. Fix the above issues by using a OMAP5-specific compatible property and using SoC-specific data where there are differences. Cc: Nishanth Menon n...@ti.com Signed-off-by: Suman Anna s-a...@ti.com --- Some validation traces by adding couple of traces and intentionally creating L3 errors from DSP IPU by accessing invalid Timers Before Patch: OMAP4 [Correct] IPU accessing Timer4 [ 46.548095] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 46.553344] mstaddr = 0x44 mask = 0xfc masterid = 0x11 [ 46.553955] [ cut here ] [ 46.563171] WARNING: CPU: 0 PID: 4 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 46.564941] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 114.018524] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 114.023498] mstaddr = 0x20 mask = 0xfc masterid = 0x8 [ 114.028564] [ cut here ] [ 114.033233] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 114.042572] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access OMAP5 [Incorrect] IPU accessing Timer4: [ 29.579306] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 29.584550] mstaddr = 0x220 mask = 0xfc masterid = 0x8 [ 29.589705] [ cut here ] [ 29.594345] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 29.603774] 4400.ocp:L3 Custom Error: MASTER DSP TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 21.347105] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 21.352091] mstaddr = 0x100 mask = 0xfc masterid = 0x0 [ 21.357250] [ cut here ] [ 21.361896] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 21.371242] 4400.ocp:L3 Custom Error: MASTER MPU TARGET ABE (Idle): Data Access in Supervisor mode during Functional access After Patch: OMAP4 same as above OMAP5 [Corrected] IPU accessing Timer4 [ 67.896693] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 67.901940] mstaddr = 0x220 mask = 0x7e0 masterid = 0x11 [ 67.907275] [ cut here ] [ 67.911924] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 67.921357] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5 [ 24.452565] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 24.457552] mstaddr = 0x100 mask = 0x7e0 masterid = 0x8 [ 24.462798] [ cut here ] [ 24.467449] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 24.476795] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access .../devicetree/bindings/arm/omap/l3-noc.txt| 1 + arch/arm/boot/dts/omap5.dtsi | 2 +- drivers/bus/omap_l3_noc.c | 5 ++- drivers/bus/omap_l3_noc.h | 52 -- 4 files changed, 44 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index 974624ea68f6..161448da959d 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,7 @@ provided by Arteris. Required properties: - compatible : Should be ti,omap3-l3-smx for OMAP3 family Should be ti,omap4-l3-noc for OMAP4 family + Should be ti,omap5-l3-noc for OMAP5 family Should be ti,dra7-l3-noc for DRA7 family Should be ti,am4372-l3-noc for AM43 family - reg: Contains L3 register address range for each noc domain. diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index efe5f737f39b..7d24ae0306b5 100644 ---
Re: Enabling IPU on OMAP44xx
On 04/24/2015 11:21 AM, Jack Mitchell wrote: I've been fighting for a week with trying to get the IPU booted over remoteproc on an OMAP4470. I feel like I've got most of the way there we do not have support for OMAP4470 on git.kernel.org. If you are interested in TI vendor kernel support, please use e2e.ti.com. ... -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap: Allow building as a loadable module
On 4/23/2015 4:56 PM, Tony Lindgren wrote: We currently get all kinds of errors building the omap gpio driver as a module starting with: undefined reference to `omap2_gpio_resume_after_idle' undefined reference to `omap2_gpio_prepare_for_idle' ... Let's fix the issue by adding inline functions to the header. Note that we can now also remove the two unused functions for omap_set_gpio_debounce and omap_set_gpio_debounce_time. Then doing rmmod on the module produces further warnings because of missing exit related functions. Let's add those. And finally, we can make the Kconfig entry just a tristate option that's selected for omaps. Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Grygorii Strashko grygorii.stras...@linaro.org Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Nishanth Menon n...@ti.com Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/gpio/Kconfig| 2 +- drivers/gpio/gpio-omap.c| 24 include/linux/platform_data/gpio-omap.h | 12 ++-- 3 files changed, 35 insertions(+), 3 deletions(-) That platform header needs serious clean-up and we now add two more inlines there. But, being able to use gpio as loadable module might be good enough reason to take this one. Acked-by: Santosh Shilimkar ssant...@kernel.org -- 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: Enabling IPU on OMAP44xx
Hi Jack, On 24/04/15 19:34, Nishanth Menon wrote: On 04/24/2015 11:21 AM, Jack Mitchell wrote: I've been fighting for a week with trying to get the IPU booted over remoteproc on an OMAP4470. I feel like I've got most of the way there we do not have support for OMAP4470 on git.kernel.org. If you are interested in TI vendor kernel support, please use e2e.ti.com. ... Hi Nishanth, I understand; and booting an omap4470 isn't the issue, I've hacked in the support for booting it as it's basically the same as 4460; which is supported. It's the IPU that I'm trying to get working, which is the same across all the 44xx omap SoCs, right? I'm using the latest mainline and the logs I posted are from the git HEAD early this morning. I'm not looking for offical support, just pointers to people who may have been using mainline and the IPU, the support seems to be in there but none of the plumbing so I assume someone is probably using it otherwise it's dead code. Yeah, these are indeed used downstream in the TI product kernels, and it's just that adding the support for them has been progressing slowly upstream. There are couple of things that are wrong with your minimal patch, things that stand out 1. omap_ctrl_write_dsp_boot_addr is for DSP, not for IPU, so you need not set that. 2. omap_device_enable is not enough to release the processor resets in general, you can check the PRCM RSTCTRL registers, my bet is the processor is still in reset. 3. You also need to have an associated CMA pool with the remoteproc, and the CMA start address needs to match to that of your resource table, atleast with the current firmware images. In anycase, to be closer to use mainline sources, you would want to create a DT-based remoteproc device and not legacy style platform device. The mailbox and IOMMU support are converted to DT and should support OMAP4 in mainline already. FYI, you may want to look at the following TI trees, http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=shortlog;h=refs/heads/rpmsg-ti-linux-3.14.y (integrated remoteproc with rpmsg) or just http://git.ti.com/gitweb/?p=rpmsg/remoteproc.git;a=shortlog;h=refs/heads/rproc-linux-3.14.y (remoteproc without any rpmsg pieces) Those should boot on OMAP4, OMAP5 and DRA7 platforms provided you have the firmwares with appropriate resource tables. regards Suman -- 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 0/5] PM / clock_ops: provide default runtime ops and cleanup users
On Fri, Apr 24, 2015 at 4:41 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:
Most users of PM clocks do the exact same thing in runtime callbacks.
Provide default callbacks and cleanup the existing users (keystone/davinci
/omap1/sh)
Rajendra Nayak (5):
PM / clock_ops: Provide default runtime ops to users
arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
arch/arm/mach-davinci/pm_domain.c | 32 +-
arch/arm/mach-keystone/pm_domain.c | 33 +-
arch/arm/mach-omap1/pm_bus.c | 37 ++
drivers/base/power/clock_ops.c | 38 ++
drivers/sh/pm_runtime.c| 47
++
include/linux/pm_clock.h | 10
6 files changed, 54 insertions(+), 143 deletions(-)
It is not particularly clear to me who is supposed to apply this series, but
I can do that if people don't have problems with that.
All later patches depend on the first patch.
For shmobile, Simon has queued up changes for drivers/sh/pm_runtime.c,
but I think they don't conflict with this series.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] gpio: omap: Allow building as a loadable module
On 04/24/2015 02:56 AM, Tony Lindgren wrote:
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...
Let's fix the issue by adding inline functions to the header.
Note that we can now also remove the two unused functions for
omap_set_gpio_debounce and omap_set_gpio_debounce_time.
Then doing rmmod on the module produces further warnings
because of missing exit related functions. Let's add those.
And finally, we can make the Kconfig entry just a tristate
option that's selected for omaps.
Reviewed-by: Grygorii Strashko grygorii.stras...@linaro.org
boot tested on: dra7-evm with gpio-omap.ko
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/Kconfig| 2 +-
drivers/gpio/gpio-omap.c| 24
include/linux/platform_data/gpio-omap.h | 12 ++--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..ff7df95 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -308,7 +308,7 @@ config GPIO_OCTEON
family of SOCs.
config GPIO_OMAP
- bool TI OMAP GPIO support if COMPILE_TEST !ARCH_OMAP2PLUS
+ tristate TI OMAP GPIO support if ARCH_OMAP2PLUS || COMPILE_TEST
default y if ARCH_OMAP
depends on ARM
select GENERIC_IRQ_CHIP
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b59c3ca..384a852 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1202,6 +1202,17 @@ static int omap_gpio_probe(struct platform_device *pdev)
return 0;
}
+static int omap_gpio_remove(struct platform_device *pdev)
+{
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+
+ list_del(bank-node);
+ gpiochip_remove(bank-chip);
+ pm_runtime_disable(bank-dev);
+
+ return 0;
+}
+
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM)
@@ -1387,6 +1398,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
}
#endif /* CONFIG_PM */
+#if IS_BUILTIN(CONFIG_GPIO_OMAP)
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
@@ -1412,6 +1424,7 @@ void omap2_gpio_resume_after_idle(void)
pm_runtime_get_sync(bank-dev);
}
}
+#endif
#if defined(CONFIG_PM)
static void omap_gpio_init_context(struct gpio_bank *p)
@@ -1567,6 +1580,7 @@ MODULE_DEVICE_TABLE(of, omap_gpio_match);
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
+ .remove = omap_gpio_remove,
.driver = {
.name = omap_gpio,
.pm = gpio_pm_ops,
@@ -1584,3 +1598,13 @@ static int __init omap_gpio_drv_reg(void)
return platform_driver_register(omap_gpio_driver);
}
postcore_initcall(omap_gpio_drv_reg);
+
+static void __exit omap_gpio_exit(void)
+{
+ platform_driver_unregister(omap_gpio_driver);
+}
+module_exit(omap_gpio_exit);
+
+MODULE_DESCRIPTION(omap gpio driver);
+MODULE_ALIAS(platform:gpio-omap);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/platform_data/gpio-omap.h
b/include/linux/platform_data/gpio-omap.h
index 5d50b25..cb26181 100644
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@ -208,9 +208,17 @@ struct omap_gpio_platform_data {
int (*get_context_loss_count)(struct device *dev);
};
+#if IS_BUILTIN(CONFIG_GPIO_OMAP)
extern void omap2_gpio_prepare_for_idle(int off_mode);
extern void omap2_gpio_resume_after_idle(void);
-extern void omap_set_gpio_debounce(int gpio, int enable);
-extern void omap_set_gpio_debounce_time(int gpio, int enable);
+#else
+static inline void omap2_gpio_prepare_for_idle(int off_mode)
+{
+}
+
+static inline void omap2_gpio_resume_after_idle(void)
+{
+}
+#endif
#endif
--
regards,
-grygorii
--
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 3/5] arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS
* Rajendra Nayak rna...@codeaurora.org [150423 01:34]:
USE_PM_CLK_RUNTIME_OPS is introduced so we don't repeat the same code
to do runtime_suspend and runtime_resume across users of PM clocks.
Use it to remove the boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/pm_bus.c | 37 ++---
1 file changed, 2 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index c40e209..667c163 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -21,48 +21,15 @@
#include soc.h
-#ifdef CONFIG_PM
-static int omap1_pm_runtime_suspend(struct device *dev)
-{
- int ret;
-
- dev_dbg(dev, %s\n, __func__);
-
- ret = pm_generic_runtime_suspend(dev);
- if (ret)
- return ret;
-
- ret = pm_clk_suspend(dev);
- if (ret) {
- pm_generic_runtime_resume(dev);
- return ret;
- }
-
- return 0;
-}
-
-static int omap1_pm_runtime_resume(struct device *dev)
-{
- dev_dbg(dev, %s\n, __func__);
-
- pm_clk_resume(dev);
- return pm_generic_runtime_resume(dev);
-}
-
static struct dev_pm_domain default_pm_domain = {
.ops = {
- .runtime_suspend = omap1_pm_runtime_suspend,
- .runtime_resume = omap1_pm_runtime_resume,
+ USE_PM_CLK_RUNTIME_OPS
USE_PLATFORM_PM_SLEEP_OPS
},
};
-#define OMAP1_PM_DOMAIN (default_pm_domain)
-#else
-#define OMAP1_PM_DOMAIN NULL
-#endif /* CONFIG_PM */
static struct pm_clk_notifier_block platform_bus_notifier = {
- .pm_domain = OMAP1_PM_DOMAIN,
+ .pm_domain = default_pm_domain,
.con_ids = { ick, fck, NULL, },
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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/3] watchdog: omap: use watchdog_init_timeout
Hi, On Fri, Apr 24, 2015 at 11:48:31AM +0200, Uwe Kleine-König wrote: Instead of (partly) open coding it use the core function. As a side effect the timeout-sec devicetree property is used now. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Documentation/devicetree/bindings/watchdog/omap-wdt.txt | 9 + drivers/watchdog/omap_wdt.c | 5 + 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt index c227970671ea..4f18ec38be2f 100644 --- a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt @@ -1,10 +1,11 @@ TI Watchdog Timer (WDT) Controller for OMAP Required properties: -compatible: -- ti,omap3-wdt for OMAP3 -- ti,omap4-wdt for OMAP4 -- ti,hwmods: Name of the hwmod associated to the WDT +- compatible : ti,omap3-wdt (for OMAP3) or ti,omap4-wdt (for OMAP4) +- ti,hwmods : Name of the hwmod associated to the WDT + +Optional properties: +- timeout-sec : default watchdog timeout in seconds adding a new property here ? Why ? In fact, none of these DT binding doc changes fit in $subject. Sure, watchdog_init_timeout() needs timeout-sec, but no OMAP DT today passes it. diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 39a6cfcba016..0eb9ca04e672 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -234,10 +234,7 @@ static int omap_wdt_probe(struct platform_device *pdev) omap_wdt-min_timeout = TIMER_MARGIN_MIN; omap_wdt-max_timeout = TIMER_MARGIN_MAX; - if (timer_margin = TIMER_MARGIN_MIN - timer_margin = TIMER_MARGIN_MAX) - omap_wdt-timeout = timer_margin; - else + if (watchdog_init_timeout(omap_wdt, timer_margin, pdev-dev) 0) omap_wdt-timeout = TIMER_MARGIN_DEFAULT; watchdog_set_drvdata(omap_wdt, wdev); -- 2.1.4 -- balbi signature.asc Description: Digital signature
Re: [PATCH] gpio: omap: Fix regression for MPUIO interrupts
On 04/24/2015 02:54 AM, Tony Lindgren wrote:
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old code trying to do the same.
Reviewed-by: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/gpio/gpio-omap.c | 48 +---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 6553361..b59c3ca 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1023,38 +1023,8 @@ static void omap_gpio_mod_init(struct gpio_bank *bank)
dev_err(bank-dev, Could not get gpio dbck\n);
}
-static void
-omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start,
- unsigned int num)
-{
- struct irq_chip_generic *gc;
- struct irq_chip_type *ct;
-
- gc = irq_alloc_generic_chip(MPUIO, 1, irq_start, bank-base,
- handle_simple_irq);
- if (!gc) {
- dev_err(bank-dev, Memory alloc failed for gc\n);
- return;
- }
-
- ct = gc-chip_types;
-
- /* NOTE: No ack required, reading IRQ status clears it. */
- ct-chip.irq_mask = irq_gc_mask_set_bit;
- ct-chip.irq_unmask = irq_gc_mask_clr_bit;
- ct-chip.irq_set_type = omap_gpio_irq_type;
-
- if (bank-regs-wkup_en)
- ct-chip.irq_set_wake = omap_gpio_wake_enable;
-
- ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride;
- irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
- IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-}
-
static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc)
{
- int j;
static int gpio;
int irq_base = 0;
int ret;
@@ -1101,6 +1071,15 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
struct irq_chip *irqc)
}
#endif
+ /* MPUIO is a bit different, reading IRQ status clears it */
+ if (bank-is_mpuio) {
+ irqc-irq_ack = dummy_irq_chip.irq_ack;
+ irqc-irq_mask = irq_gc_mask_set_bit;
+ irqc-irq_unmask = irq_gc_mask_clr_bit;
+ if (!bank-regs-wkup_en)
+ irqc-irq_set_wake = NULL;
+ }
+
ret = gpiochip_irqchip_add(bank-chip, irqc,
irq_base, omap_gpio_irq_handler,
IRQ_TYPE_NONE);
@@ -1114,15 +1093,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
struct irq_chip *irqc)
gpiochip_set_chained_irqchip(bank-chip, irqc,
bank-irq, omap_gpio_irq_handler);
- for (j = 0; j bank-width; j++) {
- int irq = irq_find_mapping(bank-chip.irqdomain, j);
- if (bank-is_mpuio) {
- omap_mpuio_alloc_gc(bank, irq, bank-width);
- irq_set_chip_and_handler(irq, NULL, NULL);
- set_irq_flags(irq, 0);
- }
- }
-
return 0;
}
--
regards,
-grygorii
--
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] gpio: omap: Fix regression for MPUIO interrupts
On 4/23/2015 4:54 PM, Tony Lindgren wrote: At some point with all the GPIO clean-up we've broken the MPUIO interrupts. Those are just a little bit different from the GPIO interrupts, so we can fix it up just by setting different irqchip functions for it. And then we can just remove all old code trying to do the same. Cc: Aaro Koskinen aaro.koski...@iki.fi Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Grygorii Strashko grygorii.stras...@linaro.org Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Nishanth Menon n...@ti.com Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- Acked-by: Santosh Shilimkar ssant...@kernel.org -- 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 3/3] watchdog: omap: simplify assignment of bootstatus
On Fri, Apr 24, 2015 at 11:48:33AM +0200, Uwe Kleine-König wrote:
Instead of using an over-long expression involving the ?: operator use
an if and intead of an else branch rely on the fact that the data
structure was allocated using devm_kzalloc. This also allows to put the
used helper variable into a more local scope.
There is no functional change.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
looks good to me
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/watchdog/omap_wdt.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 479e7c8e44f5..0421c06a6cf0 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -209,7 +209,6 @@ static int omap_wdt_probe(struct platform_device *pdev)
struct omap_wd_timer_platform_data *pdata =
dev_get_platdata(pdev-dev);
struct resource *res;
struct omap_wdt_dev *wdev;
- u32 rs;
int ret;
wdev = devm_kzalloc(pdev-dev, sizeof(*wdev), GFP_KERNEL);
@@ -242,12 +241,11 @@ static int omap_wdt_probe(struct platform_device *pdev)
pm_runtime_enable(wdev-dev);
pm_runtime_get_sync(wdev-dev);
- if (pdata pdata-read_reset_sources)
- rs = pdata-read_reset_sources();
- else
- rs = 0;
- wdev-wdog.bootstatus = (rs (1 OMAP_MPU_WD_RST_SRC_ID_SHIFT)) ?
- WDIOF_CARDRESET : 0;
+ if (pdata pdata-read_reset_sources) {
+ u32 rs = pdata-read_reset_sources();
+ if (rs (1 OMAP_MPU_WD_RST_SRC_ID_SHIFT))
+ wdev-wdog.bootstatus = WDIOF_CARDRESET;
+ }
omap_wdt_disable(wdev);
--
2.1.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/5] PM / clock_ops: provide default runtime ops and cleanup users
On 4/24/2015 7:41 AM, Rafael J. Wysocki wrote: On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote: Most users of PM clocks do the exact same thing in runtime callbacks. Provide default callbacks and cleanup the existing users (keystone/davinci /omap1/sh) Rajendra Nayak (5): PM / clock_ops: Provide default runtime ops to users arm: keystone: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: omap1: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arm: davinci: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS drivers: sh: remove boilerplate code and use USE_PM_CLK_RUNTIME_OPS arch/arm/mach-davinci/pm_domain.c | 32 +- arch/arm/mach-keystone/pm_domain.c | 33 +- arch/arm/mach-omap1/pm_bus.c | 37 ++ drivers/base/power/clock_ops.c | 38 ++ drivers/sh/pm_runtime.c| 47 ++ include/linux/pm_clock.h | 10 6 files changed, 54 insertions(+), 143 deletions(-) It is not particularly clear to me who is supposed to apply this series, but I can do that if people don't have problems with that. I am fine by that given dependency with first patch. Another way is, you pick up the first patch and give us an immutable branch. Either way is fine by me. Regards, Santosh -- 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 1a/3] watchdog: omap: clearify device tree documentation
On Fri, Apr 24, 2015 at 10:20:50PM +0200, Uwe Kleine-König wrote: ti,hwmods doesn't belong into the compatible section but is a property on it's own. Also reformat the section of required properties to match the usual style of dt binding documents. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de looks great to me, thanks Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- Hello Felipe, what about this patch before the previously sent patch 1? Best regards Uwe Documentation/devicetree/bindings/watchdog/omap-wdt.txt | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt index c227970671ea..597e19d18dca 100644 --- a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt @@ -1,10 +1,8 @@ TI Watchdog Timer (WDT) Controller for OMAP Required properties: -compatible: -- ti,omap3-wdt for OMAP3 -- ti,omap4-wdt for OMAP4 -- ti,hwmods: Name of the hwmod associated to the WDT +- compatible : ti,omap3-wdt for OMAP3 or ti,omap4-wdt for OMAP4 +- ti,hwmods : Name of the hwmod associated to the WDT Examples: -- 2.1.4 -- balbi signature.asc Description: Digital signature
Enabling IPU on OMAP44xx
I've been fighting for a week with trying to get the IPU booted over
remoteproc on an OMAP4470. I feel like I've got most of the way there
but I don't get a response from the first kick after boot. Has anyone
ever had the IPU booted on mainline? Dmesg from remoteproce boot is as
below:
[ 47.430084] remoteproc0: ipu_c0 is available
[ 47.431274] remoteproc0: Note: remoteproc is still under development
and considered experimental.
[ 47.445312] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and
backward compatibility isn't yet guaranteed.
[ 47.869476] remoteproc0: unsupported resource 5
[ 47.876831] remoteproc0: registered virtio0 (type 7)
[ 47.882385] remoteproc0: unsupported resource 5
[ 47.888244] cma: cma_alloc(cma c1211f98, count 3, align 2)
[ 47.897613] cma: cma_alloc(): returned deda7990
[ 47.902465] cma: cma_alloc(cma c1211f98, count 3, align 2)
[ 47.908813] cma: cma_alloc(): returned deda7a20
[ 47.913604] remoteproc0: powering up ipu_c0
[ 47.967895] remoteproc0: Booting fw image ducati-m3-core0.xem3, size
14862876
[ 47.983947] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[ 47.990112] cma: cma_alloc(cma c1211f98, count 1536, align 8)
[ 47.997894] cma: cma_alloc(): returned deda9400
[ 48.022949] cma: cma_alloc(cma c1211f98, count 58880, align 8)
[ 48.047454] cma: cma_alloc(): returned dedb6c00
[ 48.762756] cma: cma_alloc(cma c1211f98, count 256, align 8)
[ 48.769165] cma: cma_alloc(): returned defbc400
[ 48.779113] remoteproc0: unsupported resource 5
[ 48.887756] omap-rproc omap-rproc.1: JACK1
[ 48.893157] omap-rproc omap-rproc.1: JACK2
[ 48.893157] omap-rproc omap-rproc.1: JACK3
[ 48.901794] omap-rproc omap-rproc.1: JACK4
[ 48.906097] remoteproc0: remote processor ipu_c0 is now up
[ 48.912231] cma: cma_alloc(cma c1211f98, count 64, align 6)
[ 48.922851] cma: cma_alloc(): returned deda8200
[ 48.929321] virtio_rpmsg_bus virtio0: rpmsg host is online
What I would expect next (as is the case on my 3.4 TI vendor kernel) is
something like:
[ 13.647338] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 15.996520] omap-rproc omap-rproc.1: received echo reply from ipu_c0
[ 15.996887] virtio_rpmsg_bus virtio0: creating channel rpmsg-dce addr
0x2a
[ 16.000335] virtio_rpmsg_bus virtio0: creating channel rpmsg-omx1
addr 0x3c
[ 16.000732] rpmsg_omx rpmsg-omx1: new OMX connection srv channel:
1025 - 60!
[ 16.000915] virtio_rpmsg_bus virtio0: creating channel omaprpc addr 0x3b
I imagine the echo reply is remoteproc, but the other stuff is maybe
omapdce?
The patch that I've hacked together to get this far is attached. I had
to comment out some of the zero checking parts as it was failing, saying
that the reserved memory was not zeroed; could this be the iommu that
isn't translating properly?
Any input at all on the subject would be much appreciated!
Cheers,
Jack.
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f5e68a7..b628498 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4792,7 +4792,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
omap44xx_l4_per__i2c4,
omap44xx_l3_main_2__ipu,
omap44xx_l3_main_2__iss,
- /* omap44xx_iva__sl2if, */
+ omap44xx_iva__sl2if,
omap44xx_l3_main_2__iva,
omap44xx_l4_wkup__kbd,
omap44xx_l4_cfg__mailbox,
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index af11511..ad4eacf 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -14,9 +14,11 @@
#include linux/kernel.h
#include linux/of_platform.h
#include linux/ti_wilink_st.h
+#include linux/dma-contiguous.h
#include linux/platform_data/pinctrl-single.h
#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/remoteproc-omap.h
#include common.h
#include common-board-devices.h
@@ -243,6 +245,55 @@ static void __init nokia_n900_legacy_init(void)
}
}
+static struct platform_device omap4_ducati = {
+.name = omap-rproc,
+.id = 1,
+};
+
+static struct omap_rproc_pdata omap4_rproc_data[] = {
+{
+.name = ipu_c0,
+.firmware = ducati-m3-core0.xem3,
+.mbox_name = mbox_ipu,
+.oh_name= ipu,
+.oh_name_opt= iss,
+.set_bootaddr = omap_ctrl_write_dsp_boot_addr,
+ .device_enable = omap_device_enable,
+},
+};
+
+static struct omap_iommu_arch_data omap4_ipu_iommu = {
+.name = 55082000.mmu,
+};
+
+static void __init custboard_legacy_init(void)
+{
+ omap4_ducati.dev.archdata.iommu = omap4_ipu_iommu;
+ platform_device_register(omap4_ducati);
+
+ platform_device_add_data(omap4_ducati,
+ omap4_rproc_data,
+ sizeof(struct omap_rproc_pdata));
+
+}
+
Re: [PATCH] gpio: omap: Allow building as a loadable module
On Thu, Apr 23, 2015 at 04:56:22PM -0700, Tony Lindgren wrote:
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...
Let's fix the issue by adding inline functions to the header.
Note that we can now also remove the two unused functions for
omap_set_gpio_debounce and omap_set_gpio_debounce_time.
Then doing rmmod on the module produces further warnings
because of missing exit related functions. Let's add those.
And finally, we can make the Kconfig entry just a tristate
option that's selected for omaps.
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
Just to be clear: when GPIO is a module, we can't really idle, can we ?
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/Kconfig| 2 +-
drivers/gpio/gpio-omap.c| 24
include/linux/platform_data/gpio-omap.h | 12 ++--
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..ff7df95 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -308,7 +308,7 @@ config GPIO_OCTEON
family of SOCs.
config GPIO_OMAP
- bool TI OMAP GPIO support if COMPILE_TEST !ARCH_OMAP2PLUS
+ tristate TI OMAP GPIO support if ARCH_OMAP2PLUS || COMPILE_TEST
default y if ARCH_OMAP
depends on ARM
select GENERIC_IRQ_CHIP
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b59c3ca..384a852 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1202,6 +1202,17 @@ static int omap_gpio_probe(struct platform_device
*pdev)
return 0;
}
+static int omap_gpio_remove(struct platform_device *pdev)
+{
+ struct gpio_bank *bank = platform_get_drvdata(pdev);
+
+ list_del(bank-node);
+ gpiochip_remove(bank-chip);
+ pm_runtime_disable(bank-dev);
+
+ return 0;
+}
+
#ifdef CONFIG_ARCH_OMAP2PLUS
#if defined(CONFIG_PM)
@@ -1387,6 +1398,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
}
#endif /* CONFIG_PM */
+#if IS_BUILTIN(CONFIG_GPIO_OMAP)
void omap2_gpio_prepare_for_idle(int pwr_mode)
{
struct gpio_bank *bank;
@@ -1412,6 +1424,7 @@ void omap2_gpio_resume_after_idle(void)
pm_runtime_get_sync(bank-dev);
}
}
+#endif
#if defined(CONFIG_PM)
static void omap_gpio_init_context(struct gpio_bank *p)
@@ -1567,6 +1580,7 @@ MODULE_DEVICE_TABLE(of, omap_gpio_match);
static struct platform_driver omap_gpio_driver = {
.probe = omap_gpio_probe,
+ .remove = omap_gpio_remove,
.driver = {
.name = omap_gpio,
.pm = gpio_pm_ops,
@@ -1584,3 +1598,13 @@ static int __init omap_gpio_drv_reg(void)
return platform_driver_register(omap_gpio_driver);
}
postcore_initcall(omap_gpio_drv_reg);
+
+static void __exit omap_gpio_exit(void)
+{
+ platform_driver_unregister(omap_gpio_driver);
+}
+module_exit(omap_gpio_exit);
+
+MODULE_DESCRIPTION(omap gpio driver);
+MODULE_ALIAS(platform:gpio-omap);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/platform_data/gpio-omap.h
b/include/linux/platform_data/gpio-omap.h
index 5d50b25..cb26181 100644
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@ -208,9 +208,17 @@ struct omap_gpio_platform_data {
int (*get_context_loss_count)(struct device *dev);
};
+#if IS_BUILTIN(CONFIG_GPIO_OMAP)
extern void omap2_gpio_prepare_for_idle(int off_mode);
extern void omap2_gpio_resume_after_idle(void);
-extern void omap_set_gpio_debounce(int gpio, int enable);
-extern void omap_set_gpio_debounce_time(int gpio, int enable);
+#else
+static inline void omap2_gpio_prepare_for_idle(int off_mode)
+{
+}
+
+static inline void omap2_gpio_resume_after_idle(void)
+{
+}
+#endif
#endif
--
2.1.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] gpio: omap: Fix regression for MPUIO interrupts
On Thu, Apr 23, 2015 at 04:54:17PM -0700, Tony Lindgren wrote:
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old code trying to do the same.
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Felipe Balbi ba...@ti.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Grygorii Strashko grygorii.stras...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Nishanth Menon n...@ti.com
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c | 48
+---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 6553361..b59c3ca 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1023,38 +1023,8 @@ static void omap_gpio_mod_init(struct gpio_bank *bank)
dev_err(bank-dev, Could not get gpio dbck\n);
}
-static void
-omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start,
- unsigned int num)
-{
- struct irq_chip_generic *gc;
- struct irq_chip_type *ct;
-
- gc = irq_alloc_generic_chip(MPUIO, 1, irq_start, bank-base,
- handle_simple_irq);
- if (!gc) {
- dev_err(bank-dev, Memory alloc failed for gc\n);
- return;
- }
-
- ct = gc-chip_types;
-
- /* NOTE: No ack required, reading IRQ status clears it. */
- ct-chip.irq_mask = irq_gc_mask_set_bit;
- ct-chip.irq_unmask = irq_gc_mask_clr_bit;
- ct-chip.irq_set_type = omap_gpio_irq_type;
-
- if (bank-regs-wkup_en)
- ct-chip.irq_set_wake = omap_gpio_wake_enable;
-
- ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride;
- irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE,
-IRQ_NOREQUEST | IRQ_NOPROBE, 0);
-}
-
static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc)
{
- int j;
static int gpio;
int irq_base = 0;
int ret;
@@ -1101,6 +1071,15 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
struct irq_chip *irqc)
}
#endif
+ /* MPUIO is a bit different, reading IRQ status clears it */
+ if (bank-is_mpuio) {
+ irqc-irq_ack = dummy_irq_chip.irq_ack;
+ irqc-irq_mask = irq_gc_mask_set_bit;
+ irqc-irq_unmask = irq_gc_mask_clr_bit;
+ if (!bank-regs-wkup_en)
+ irqc-irq_set_wake = NULL;
+ }
+
ret = gpiochip_irqchip_add(bank-chip, irqc,
irq_base, omap_gpio_irq_handler,
IRQ_TYPE_NONE);
@@ -1114,15 +1093,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
struct irq_chip *irqc)
gpiochip_set_chained_irqchip(bank-chip, irqc,
bank-irq, omap_gpio_irq_handler);
- for (j = 0; j bank-width; j++) {
- int irq = irq_find_mapping(bank-chip.irqdomain, j);
- if (bank-is_mpuio) {
- omap_mpuio_alloc_gc(bank, irq, bank-width);
- irq_set_chip_and_handler(irq, NULL, NULL);
- set_irq_flags(irq, 0);
- }
- }
-
return 0;
}
--
2.1.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] gpio: omap: Allow building as a loadable module
* Felipe Balbi ba...@ti.com [150424 09:14]: On Thu, Apr 23, 2015 at 04:56:22PM -0700, Tony Lindgren wrote: We currently get all kinds of errors building the omap gpio driver as a module starting with: undefined reference to `omap2_gpio_resume_after_idle' undefined reference to `omap2_gpio_prepare_for_idle' ... Let's fix the issue by adding inline functions to the header. Note that we can now also remove the two unused functions for omap_set_gpio_debounce and omap_set_gpio_debounce_time. Then doing rmmod on the module produces further warnings because of missing exit related functions. Let's add those. And finally, we can make the Kconfig entry just a tristate option that's selected for omaps. Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Grygorii Strashko grygorii.stras...@linaro.org Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Nishanth Menon n...@ti.com Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Just to be clear: when GPIO is a module, we can't really idle, can we ? Right we cannot do off idle because of the context loss until we have some way to register driver specific idle functions. 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
[PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:
1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
11 bits on OMAP5 as against 8 bits on OMAP4, with the master
NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
field.
2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
input sources on OMAP5. The common DEBUGSS source is at a
different input on each SoC.
Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
Some validation traces by adding couple of traces and intentionally
creating L3 errors from DSP IPU by accessing invalid Timers
Before Patch:
OMAP4 [Correct]
IPU accessing Timer4
[ 46.548095] flagmux = 1, err_reg = 0x8000 err_src = 0xf
[ 46.553344] mstaddr = 0x44 mask = 0xfc masterid = 0x11
[ 46.553955] [ cut here ]
[ 46.563171] WARNING: CPU: 0 PID: 4 at drivers/bus/omap_l3_noc.c:149
l3_interrupt_handler+0x280/0x388()
[ 46.564941] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3
(Idle): Data Access in User mode during
Functional access
DSP accessing Timer5:
[ 114.018524] flagmux = 0, err_reg = 0x4 err_src = 0x2
[ 114.023498] mstaddr = 0x20 mask = 0xfc masterid = 0x8
[ 114.028564] [ cut here ]
[ 114.033233] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149
l3_interrupt_handler+0x280/0x388()
[ 114.042572] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data
Access in Supervisor mode during Functional
access
OMAP5 [Incorrect]
IPU accessing Timer4:
[ 29.579306] flagmux = 1, err_reg = 0x8000 err_src = 0xf
[ 29.584550] mstaddr = 0x220 mask = 0xfc masterid = 0x8
[ 29.589705] [ cut here ]
[ 29.594345] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149
l3_interrupt_handler+0x280/0x388()
[ 29.603774] 4400.ocp:L3 Custom Error: MASTER DSP TARGET L4PER3 (Idle):
Data Access in User mode during Functional
access
DSP accessing Timer5:
[ 21.347105] flagmux = 0, err_reg = 0x4 err_src = 0x2
[ 21.352091] mstaddr = 0x100 mask = 0xfc masterid = 0x0
[ 21.357250] [ cut here ]
[ 21.361896] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149
l3_interrupt_handler+0x280/0x388()
[ 21.371242] 4400.ocp:L3 Custom Error: MASTER MPU TARGET ABE (Idle): Data
Access in Supervisor mode during Functional
access
After Patch:
OMAP4 same as above
OMAP5 [Corrected]
IPU accessing Timer4
[ 67.896693] flagmux = 1, err_reg = 0x8000 err_src = 0xf
[ 67.901940] mstaddr = 0x220 mask = 0x7e0 masterid = 0x11
[ 67.907275] [ cut here ]
[ 67.911924] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149
l3_interrupt_handler+0x280/0x388()
[ 67.921357] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3
(Idle): Data Access in User mode during
Functional access
DSP accessing Timer5
[ 24.452565] flagmux = 0, err_reg = 0x4 err_src = 0x2
[ 24.457552] mstaddr = 0x100 mask = 0x7e0 masterid = 0x8
[ 24.462798] [ cut here ]
[ 24.467449] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149
l3_interrupt_handler+0x280/0x388()
[ 24.476795] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data
Access in Supervisor mode during Functional
access
.../devicetree/bindings/arm/omap/l3-noc.txt| 1 +
arch/arm/boot/dts/omap5.dtsi | 2 +-
drivers/bus/omap_l3_noc.c | 5 ++-
drivers/bus/omap_l3_noc.h | 52 --
4 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
index 974624ea68f6..161448da959d 100644
--- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -6,6 +6,7 @@ provided by Arteris.
Required properties:
- compatible : Should be ti,omap3-l3-smx for OMAP3 family
Should be ti,omap4-l3-noc for OMAP4 family
+ Should be ti,omap5-l3-noc for OMAP5 family
Should be ti,dra7-l3-noc for DRA7 family
Should be ti,am4372-l3-noc for AM43 family
- reg: Contains L3 register address range for each noc domain.
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index efe5f737f39b..7d24ae0306b5 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -128,7 +128,7 @@
* hierarchy.
*/
ocp {
- compatible = ti,omap4-l3-noc,
Re: [PATCH 2/3] watchdog: omap: put struct watchdog_device into driver data
On Fri, Apr 24, 2015 at 11:48:32AM +0200, Uwe Kleine-König wrote:
This way only a single allocation is needed (per device). Also this
stops making use of watchdog_{set,get}_drvdata.
And this is better because ... ?
Nothing against it, just feels like this commit log needs a little more
verbosity
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
drivers/watchdog/omap_wdt.c | 55
-
1 file changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 0eb9ca04e672..479e7c8e44f5 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -53,7 +53,10 @@ static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, initial watchdog timeout (in seconds));
+#define to_omap_wdt_dev(_wdog) container_of(_wdog, struct
omap_wdt_dev, wdog)
+
struct omap_wdt_dev {
+ struct watchdog_device wdog;
void __iomem*base; /* physical */
struct device *dev;
boolomap_wdt_users;
@@ -123,7 +126,7 @@ static void omap_wdt_set_timer(struct omap_wdt_dev *wdev,
static int omap_wdt_start(struct watchdog_device *wdog)
{
- struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+ struct omap_wdt_dev *wdev = to_omap_wdt_dev(wdog);
void __iomem *base = wdev-base;
mutex_lock(wdev-lock);
@@ -151,7 +154,7 @@ static int omap_wdt_start(struct watchdog_device *wdog)
static int omap_wdt_stop(struct watchdog_device *wdog)
{
- struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+ struct omap_wdt_dev *wdev = to_omap_wdt_dev(wdog);
mutex_lock(wdev-lock);
omap_wdt_disable(wdev);
@@ -163,7 +166,7 @@ static int omap_wdt_stop(struct watchdog_device *wdog)
static int omap_wdt_ping(struct watchdog_device *wdog)
{
- struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+ struct omap_wdt_dev *wdev = to_omap_wdt_dev(wdog);
mutex_lock(wdev-lock);
omap_wdt_reload(wdev);
@@ -175,7 +178,7 @@ static int omap_wdt_ping(struct watchdog_device *wdog)
static int omap_wdt_set_timeout(struct watchdog_device *wdog,
unsigned int timeout)
{
- struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+ struct omap_wdt_dev *wdev = to_omap_wdt_dev(wdog);
mutex_lock(wdev-lock);
omap_wdt_disable(wdev);
@@ -204,16 +207,11 @@ static const struct watchdog_ops omap_wdt_ops = {
static int omap_wdt_probe(struct platform_device *pdev)
{
struct omap_wd_timer_platform_data *pdata =
dev_get_platdata(pdev-dev);
- struct watchdog_device *omap_wdt;
struct resource *res;
struct omap_wdt_dev *wdev;
u32 rs;
int ret;
- omap_wdt = devm_kzalloc(pdev-dev, sizeof(*omap_wdt), GFP_KERNEL);
- if (!omap_wdt)
- return -ENOMEM;
-
wdev = devm_kzalloc(pdev-dev, sizeof(*wdev), GFP_KERNEL);
if (!wdev)
return -ENOMEM;
@@ -229,18 +227,17 @@ static int omap_wdt_probe(struct platform_device *pdev)
if (IS_ERR(wdev-base))
return PTR_ERR(wdev-base);
- omap_wdt-info= omap_wdt_info;
- omap_wdt-ops = omap_wdt_ops;
- omap_wdt-min_timeout = TIMER_MARGIN_MIN;
- omap_wdt-max_timeout = TIMER_MARGIN_MAX;
+ wdev-wdog.info = omap_wdt_info;
+ wdev-wdog.ops = omap_wdt_ops;
+ wdev-wdog.min_timeout = TIMER_MARGIN_MIN;
+ wdev-wdog.max_timeout = TIMER_MARGIN_MAX;
- if (watchdog_init_timeout(omap_wdt, timer_margin, pdev-dev) 0)
- omap_wdt-timeout = TIMER_MARGIN_DEFAULT;
+ if (watchdog_init_timeout(wdev-wdog, timer_margin, pdev-dev) 0)
+ wdev-wdog.timeout = TIMER_MARGIN_DEFAULT;
- watchdog_set_drvdata(omap_wdt, wdev);
- watchdog_set_nowayout(omap_wdt, nowayout);
+ watchdog_set_nowayout(wdev-wdog, nowayout);
- platform_set_drvdata(pdev, omap_wdt);
+ platform_set_drvdata(pdev, wdev);
pm_runtime_enable(wdev-dev);
pm_runtime_get_sync(wdev-dev);
@@ -249,12 +246,12 @@ static int omap_wdt_probe(struct platform_device *pdev)
rs = pdata-read_reset_sources();
else
rs = 0;
- omap_wdt-bootstatus = (rs (1 OMAP_MPU_WD_RST_SRC_ID_SHIFT)) ?
- WDIOF_CARDRESET : 0;
+ wdev-wdog.bootstatus = (rs (1 OMAP_MPU_WD_RST_SRC_ID_SHIFT)) ?
+ WDIOF_CARDRESET : 0;
omap_wdt_disable(wdev);
- ret = watchdog_register_device(omap_wdt);
+ ret = watchdog_register_device(wdev-wdog);
if (ret) {
pm_runtime_disable(wdev-dev);
return ret;
@@ -262,7 +259,7 @@ static int omap_wdt_probe(struct platform_device *pdev)
pr_info(OMAP Watchdog Timer Rev 0x%02x: initial timeout %d sec\n,
readl_relaxed(wdev-base +
Re: [PATCH 2/3] watchdog: omap: put struct watchdog_device into driver data
Hello Felipe,
On Fri, Apr 24, 2015 at 09:44:48AM -0500, Felipe Balbi wrote:
On Fri, Apr 24, 2015 at 11:48:32AM +0200, Uwe Kleine-König wrote:
This way only a single allocation is needed (per device). Also this
stops making use of watchdog_{set,get}_drvdata.
And this is better because ... ?
a single allocation is better because AFAIK it takes less memory to
allocate a + b bytes in a single piece than in two.
watchdog_{set,get}_drvdata seems ugly to me. Judging from the other
frameworks I know better than wdog I'd say there is no need for these
functions. I didn't know if I should be more explicit about my view in
the commitlog and if so how.
Also I didn't check other wdog drivers, but using this style of
embedding the framework struct into driver data is a common idiom for
uart and gpio drivers for example.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.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 1/3] watchdog: omap: use watchdog_init_timeout
On Fri, Apr 24, 2015 at 09:42:59AM -0500, Felipe Balbi wrote: Hi, On Fri, Apr 24, 2015 at 11:48:31AM +0200, Uwe Kleine-König wrote: Instead of (partly) open coding it use the core function. As a side effect the timeout-sec devicetree property is used now. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Documentation/devicetree/bindings/watchdog/omap-wdt.txt | 9 + drivers/watchdog/omap_wdt.c | 5 + 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt index c227970671ea..4f18ec38be2f 100644 --- a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt @@ -1,10 +1,11 @@ TI Watchdog Timer (WDT) Controller for OMAP Required properties: -compatible: -- ti,omap3-wdt for OMAP3 -- ti,omap4-wdt for OMAP4 -- ti,hwmods: Name of the hwmod associated to the WDT +- compatible : ti,omap3-wdt (for OMAP3) or ti,omap4-wdt (for OMAP4) +- ti,hwmods : Name of the hwmod associated to the WDT + +Optional properties: +- timeout-sec : default watchdog timeout in seconds adding a new property here ? Why ? In fact, none of these DT binding doc changes fit in $subject. Sure, watchdog_init_timeout() needs timeout-sec, but no OMAP DT today passes it. watchdog_init_timeout doesn't *need* the new property. After all it's optional. The other changes are just reformatting to make it match the usual style and make it understandable. Could have mentioned it in the commitlog, that's true. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.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: Enabling IPU on OMAP44xx
On 24/04/15 19:34, Nishanth Menon wrote: On 04/24/2015 11:21 AM, Jack Mitchell wrote: I've been fighting for a week with trying to get the IPU booted over remoteproc on an OMAP4470. I feel like I've got most of the way there we do not have support for OMAP4470 on git.kernel.org. If you are interested in TI vendor kernel support, please use e2e.ti.com. ... Hi Nishanth, I understand; and booting an omap4470 isn't the issue, I've hacked in the support for booting it as it's basically the same as 4460; which is supported. It's the IPU that I'm trying to get working, which is the same across all the 44xx omap SoCs, right? I'm using the latest mainline and the logs I posted are from the git HEAD early this morning. I'm not looking for offical support, just pointers to people who may have been using mainline and the IPU, the support seems to be in there but none of the plumbing so I assume someone is probably using it otherwise it's dead code. Cheers, Jack. -- 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] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-{0x0300, DEBUG SOURCE,},
-{0x0, HOST CLK3,},
^^ this was HOST CLK3
..
+/* OMAP5 data */
+static struct l3_target_data omap5_l3_target_data_clk3[] = {
+{0x0100, L3INSTR,},
+{0x0300, DEBUGSS,},
+{0x0,HOSTCLK3,},
HOST CLK
Why? I followed the convention used for the other two HOST CLKs for the
so asked, if it should be HOSTspaceCLK3
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 01:33 PM, Nishanth Menon wrote: On 04/24/2015 12:54 PM, Suman Anna wrote: The L3 Error handling on OMAP5 for the most part is very similar to that of OMAP4, and had leveraged common data structures and register layout definitions so far. Upon closer inspection, there are a few minor differences causing an incorrect decoding and reporting of the master NIU upon an error: 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies 11 bits on OMAP5 as against 8 bits on OMAP4, with the master NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR field. 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3 input sources on OMAP5. The common DEBUGSS source is at a different input on each SoC. Fix the above issues by using a OMAP5-specific compatible property and using SoC-specific data where there are differences. Cc: Nishanth Menon n...@ti.com Signed-off-by: Suman Anna s-a...@ti.com --- Some validation traces by adding couple of traces and intentionally creating L3 errors from DSP IPU by accessing invalid Timers Before Patch: OMAP4 [Correct] IPU accessing Timer4 [ 46.548095] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 46.553344] mstaddr = 0x44 mask = 0xfc masterid = 0x11 [ 46.553955] [ cut here ] [ 46.563171] WARNING: CPU: 0 PID: 4 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 46.564941] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 114.018524] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 114.023498] mstaddr = 0x20 mask = 0xfc masterid = 0x8 [ 114.028564] [ cut here ] [ 114.033233] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 114.042572] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access OMAP5 [Incorrect] IPU accessing Timer4: [ 29.579306] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 29.584550] mstaddr = 0x220 mask = 0xfc masterid = 0x8 [ 29.589705] [ cut here ] [ 29.594345] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 29.603774] 4400.ocp:L3 Custom Error: MASTER DSP TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 21.347105] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 21.352091] mstaddr = 0x100 mask = 0xfc masterid = 0x0 [ 21.357250] [ cut here ] [ 21.361896] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 21.371242] 4400.ocp:L3 Custom Error: MASTER MPU TARGET ABE (Idle): Data Access in Supervisor mode during Functional access After Patch: OMAP4 same as above OMAP5 [Corrected] IPU accessing Timer4 [ 67.896693] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 67.901940] mstaddr = 0x220 mask = 0x7e0 masterid = 0x11 [ 67.907275] [ cut here ] [ 67.911924] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 67.921357] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5 [ 24.452565] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 24.457552] mstaddr = 0x100 mask = 0x7e0 masterid = 0x8 [ 24.462798] [ cut here ] [ 24.467449] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 24.476795] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access .../devicetree/bindings/arm/omap/l3-noc.txt| 1 + arch/arm/boot/dts/omap5.dtsi | 2 +- drivers/bus/omap_l3_noc.c | 5 ++- drivers/bus/omap_l3_noc.h | 52 -- 4 files changed, 44 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index 974624ea68f6..161448da959d 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,7 @@ provided by Arteris. Required properties: - compatible : Should be ti,omap3-l3-smx for OMAP3 family Should be ti,omap4-l3-noc for OMAP4 family + Should be ti,omap5-l3-noc for OMAP5 family Should be ti,dra7-l3-noc for DRA7 family Should be ti,am4372-l3-noc for AM43 family - reg: Contains L3 register address range for each noc domain. diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index efe5f737f39b..7d24ae0306b5
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 02:38 PM, Nishanth Menon wrote:
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-{0x0300, DEBUG SOURCE,},
-{0x0, HOST CLK3,},
^^ this was HOST CLK3
..
+/* OMAP5 data */
+static struct l3_target_data omap5_l3_target_data_clk3[] = {
+{0x0100, L3INSTR,},
+{0x0300, DEBUGSS,},
+{0x0,HOSTCLK3,},
HOST CLK
Why? I followed the convention used for the other two HOST CLKs for the
so asked, if it should be HOSTspaceCLK3
Aah ok, you missed the trailing number before. In anycase, this was
intentional to match HOSTCLK1 and HOSTCLK2 on OMAP4/5. Overall, the
names are somewhat non-standard, some use underscores and some others
strip out the underscore and do not use any spaces in between either.
HOST CLK3 would be the only one to use a space for OMAP4, so I got rid
of it, so hope that's ok with you.
regards
Suman
--
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 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..9cd2a36 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarities: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarities property is omitted, the value must be interpreted + as 0 (normal). This property is valid for serial busses only. I am interested in this functionality. But I do have the following question. If the lane-polarities property is not specified, shouldn't the relevant struct member (bus-lane_polarities[i]) be set to 0? Regards, Benoit Example -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media 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
Re: Enabling IPU on OMAP44xx
On 24/04/15 19:34, Nishanth Menon wrote: On 04/24/2015 11:21 AM, Jack Mitchell wrote: I've been fighting for a week with trying to get the IPU booted over remoteproc on an OMAP4470. I feel like I've got most of the way there we do not have support for OMAP4470 on git.kernel.org. If you are interested in TI vendor kernel support, please use e2e.ti.com. ... Hi Nishanth, I understand; and booting an omap4470 isn't the issue, I've hacked in the support for booting it as it's basically the same as 4460; which is supported. It's the IPU that I'm trying to get working, which is the same across all the 44xx omap SoCs, right? I'm using the latest mainline and the logs I posted are from the git HEAD early this morning. I'm not looking for offical support, just pointers to people who may have been using mainline and the IPU, the support seems to be in there but none of the plumbing so I assume someone is probably using it otherwise it's dead code. Cheers, Jack. -- 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 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Benoit, On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote: Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..9cd2a36 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarities: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarities property is omitted, the value must be interpreted + as 0 (normal). This property is valid for serial busses only. I am interested in this functionality. But I do have the following question. If the lane-polarities property is not specified, shouldn't the relevant struct member (bus-lane_polarities[i]) be set to 0? This is done in the caller function; endpoint-bus is zeroed in v4l2_of_parse_endpoint(). I believe reading rest of the properties relies on the same. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Sakari Ailus sakari.ai...@iki.fi wrote on Fri [2015-Apr-24 22:49:33 +0300]: Hi Benoit, On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote: Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..9cd2a36 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarities: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarities property is omitted, the value must be interpreted + as 0 (normal). This property is valid for serial busses only. I am interested in this functionality. But I do have the following question. If the lane-polarities property is not specified, shouldn't the relevant struct member (bus-lane_polarities[i]) be set to 0? This is done in the caller function; endpoint-bus is zeroed in v4l2_of_parse_endpoint(). I believe reading rest of the properties relies on the same. Dang, missed that. Sorry for the noise. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 02:54 PM, Suman Anna wrote:
On 04/24/2015 02:38 PM, Nishanth Menon wrote:
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-{0x0300, DEBUG SOURCE,},
-{0x0, HOST CLK3,},
^^ this was HOST CLK3
..
+/* OMAP5 data */
+static struct l3_target_data omap5_l3_target_data_clk3[] = {
+{0x0100, L3INSTR,},
+{0x0300, DEBUGSS,},
+{0x0,HOSTCLK3,},
HOST CLK
Why? I followed the convention used for the other two HOST CLKs for the
so asked, if it should be HOSTspaceCLK3
Aah ok, you missed the trailing number before. In anycase, this was
Sorry about that..
intentional to match HOSTCLK1 and HOSTCLK2 on OMAP4/5. Overall, the
names are somewhat non-standard, some use underscores and some others
strip out the underscore and do not use any spaces in between either.
HOST CLK3 would be the only one to use a space for OMAP4, so I got rid
of it, so hope that's ok with you.
would have been nice to cover that in commit message. no biggie for me.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1a/3] watchdog: omap: clearify device tree documentation
ti,hwmods doesn't belong into the compatible section but is a property on it's own. Also reformat the section of required properties to match the usual style of dt binding documents. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Hello Felipe, what about this patch before the previously sent patch 1? Best regards Uwe Documentation/devicetree/bindings/watchdog/omap-wdt.txt | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt index c227970671ea..597e19d18dca 100644 --- a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt @@ -1,10 +1,8 @@ TI Watchdog Timer (WDT) Controller for OMAP Required properties: -compatible: -- ti,omap3-wdt for OMAP3 -- ti,omap4-wdt for OMAP4 -- ti,hwmods: Name of the hwmod associated to the WDT +- compatible : ti,omap3-wdt for OMAP3 or ti,omap4-wdt for OMAP4 +- ti,hwmods : Name of the hwmod associated to the WDT Examples: -- 2.1.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
