[PATCH V3 0/3] Watchdog: OMAP3: bootstatus fix and changes for the current watchdog framework
Hello, The following patches based on the 3.5-rc6 from Wim, which focus on: 1. bootstatus fix for omap3, 2. omap-wdt framework update cater for the current framework as Shubhrajyoti comments mentioned. V3 changes: 1. New comments updated as Kevin mentioned in the third patch; 2. 3530evm works well, AM33xx seems work well with the following changes: + if (cpu_is_am335x()) + return omap2_prm_read_mod_reg(AM33XX_PRM_DEVICE_MOD, + AM33XX_PRM_RSTST_OFFSET) & 0x7f; But since some definitions not ready for am33xx, so I don't give the patch, if they have been updated, feel free to take these. Regards, Zumeng Chen (3): Watchdog: Omap: Changes for the new watchdog framework Watchdog: Omap: select watchdog core for framework change Watchdog: Omap: get the bootstatus for OMAP34xx arch/arm/mach-omap2/prcm.c |9 +- drivers/watchdog/Kconfig|1 + drivers/watchdog/omap_wdt.c | 342 --- drivers/watchdog/omap_wdt.h |5 + 4 files changed, 136 insertions(+), 221 deletions(-) -- 1.7.5.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
[PATCH v3 2/3] Watchdog: Omap: select watchdog core for framework change
Since the current watchdog framework depends on the watchdog core so select it in Kconfig. Signed-off-by: Zumeng Chen --- drivers/watchdog/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index fe819b7..fb5b108 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -232,6 +232,7 @@ config EP93XX_WATCHDOG config OMAP_WATCHDOG tristate "OMAP Watchdog" depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS + select WATCHDOG_CORE help Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog. Say 'Y' here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog timer. -- 1.7.5.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
[PATCH v3 1/3] Watchdog: Omap: Changes for the new watchdog framework
This patch implements the current watchdog framework for OMAP WDTimer,
which factored out the common components, so the driver can just focus
on the hardware related parts.
Signed-off-by: Zumeng Chen
---
drivers/watchdog/omap_wdt.c | 342 ---
drivers/watchdog/omap_wdt.h |5 +
2 files changed, 128 insertions(+), 219 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..cc5bc3e 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -24,6 +24,9 @@
*
* Copyright (c) 2005 David Brownell
* Use the driver model and standard identifiers; handle bigger timeouts.
+ *
+ * Copyright (c) 2012 WindRiver
+ * Changes cater for the current watchdog framework.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -33,7 +36,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -50,8 +52,6 @@
#include "omap_wdt.h"
-static struct platform_device *omap_wdt_dev;
-
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
@@ -59,32 +59,14 @@ MODULE_PARM_DESC(timer_margin, "initial watchdog timeout
(in seconds)");
static unsigned int wdt_trgr_pattern = 0x1234;
static DEFINE_SPINLOCK(wdt_lock);
-struct omap_wdt_dev {
+struct omap_wdt_drvdata {
+ struct watchdog_device wdt;
void __iomem*base; /* physical */
struct device *dev;
- int omap_wdt_users;
struct resource *mem;
- struct miscdevice omap_wdt_miscdev;
};
-static void omap_wdt_ping(struct omap_wdt_dev *wdev)
-{
- void __iomem*base = wdev->base;
-
- /* wait for posted write to complete */
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
- cpu_relax();
-
- wdt_trgr_pattern = ~wdt_trgr_pattern;
- __raw_writel(wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
-
- /* wait for posted write to complete */
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
- cpu_relax();
- /* reloaded WCRR from WLDR */
-}
-
-static void omap_wdt_enable(struct omap_wdt_dev *wdev)
+static void omap_wdt_enable(struct omap_wdt_drvdata *wdev)
{
void __iomem *base = wdev->base;
@@ -98,7 +80,7 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
cpu_relax();
}
-static void omap_wdt_disable(struct omap_wdt_dev *wdev)
+static void omap_wdt_disable(struct omap_wdt_drvdata *wdev)
{
void __iomem *base = wdev->base;
@@ -121,12 +103,19 @@ static void omap_wdt_adjust_timeout(unsigned new_timeout)
timer_margin = new_timeout;
}
-static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
+static int omap_wdt_set_timeout(struct watchdog_device *wdt_dev,
+ unsigned int new_timeout)
{
- u32 pre_margin = GET_WLDR_VAL(timer_margin);
- void __iomem *base = wdev->base;
+ u32 pre_margin;
+ struct omap_wdt_drvdata *omap_wdev = watchdog_get_drvdata(wdt_dev);
+ void __iomem *base = omap_wdev->base;
- pm_runtime_get_sync(wdev->dev);
+ pm_runtime_get_sync(omap_wdev->dev);
+ omap_wdt_disable(omap_wdev);
+
+ /* adjust timeout based on the new timeout */
+ omap_wdt_adjust_timeout(new_timeout);
+ pre_margin = GET_WLDR_VAL(timer_margin);
/* just count up at 32 KHz */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
@@ -136,147 +125,88 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
*wdev)
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
cpu_relax();
- pm_runtime_put_sync(wdev->dev);
+ omap_wdt_enable(omap_wdev);
+ wdt_dev->timeout = new_timeout;
+ pm_runtime_put_sync(omap_wdev->dev);
+ return 0;
}
-/*
- * Allow only one task to hold it open
- */
-static int omap_wdt_open(struct inode *inode, struct file *file)
+static int omap_wdt_ping(struct watchdog_device *wdt_dev)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev->base;
-
- if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
- return -EBUSY;
-
- pm_runtime_get_sync(wdev->dev);
+ struct omap_wdt_drvdata *omap_wdev = watchdog_get_drvdata(wdt_dev);
+ void __iomem*base = omap_wdev->base;
- /* initialize prescaler */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
- cpu_relax();
+ pm_runtime_get_sync(omap_wdev->dev);
+ spin_lock(&wdt_lock);
- __raw_writel((1 << 5) | (PTV << 2), base + OMAP_WATCHDOG_CNTRL);
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
+ /* wait for posted write to complete */
+ while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
cpu_relax();
- file->private_data = (void *) wdev;
+
[PATCH v3 3/3] Watchdog: Omap: get the bootstatus for OMAP34xx
The offset of WKUP_MOD is not right for the PRM_RSTST of OMAP3. So here
put the right one to match to the actual physical addr 0x48307258, which
defined in PRCM Registers section named as Global_Reg_PRM.
And there is a MPU_WD_RST bit in PRM_RSTST(0x48307258) holding the signal
from omap-wdt reboot, so that we can return WDIOF_CARDRESET if the board
wakes up from omap-wdt reboot for WDIOC_GETBOOTSTATUS ioctl.
Signed-off-by: Zumeng Chen
---
arch/arm/mach-omap2/prcm.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..3ca8aa7 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -48,9 +48,14 @@ void __iomem *prcm_mpu_base;
u32 omap_prcm_get_reset_sources(void)
{
- /* XXX This presumably needs modification for 34XX */
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ if (cpu_is_omap24xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST) & 0x7f;
+
+ /* XXX This presumably needs modification for AM33XX when ready. */
+ if (cpu_is_omap34xx())
+ return omap2_prm_read_mod_reg(OMAP3430_GR_MOD, OMAP2_RM_RSTST) &
+ 0x7f;
+
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST) & 0x7f;
--
1.7.5.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: Mis?use of aliases
On Sat, Jul 14, 2012 at 07:07:17AM -1000, Mitch Bradley wrote: > On 7/14/2012 6:37 AM, David Gibson wrote: > > On Fri, Jul 13, 2012 at 07:30:42PM -1000, Mitch Bradley wrote: > >>> I'm not sure this is really a good use of aliases. UARTs use aliases > >>> because it is important that the UART number to tty number is known and > >>> fixed. > >> > >> This brings up an issue that I've been meaning to comment on. > >> > >> The use of phandle-valued properties in the aliases node causes real OFW > >> implementations some amount of heartburn. The Open Firmware standard > >> says that the properties in /aliases are string-valued. That's > >> important, because aliases are shorthand for fragments of full device > >> specifiers (pathnames that can include arguments to nodes). Phandles > >> can point to nodes, but can't be relative, and can't encode > >> per-node-component arguments. > > > > Um, so, properties in /aliases should not have phandle values, flat > > tree or otherwise. Has this been seen in the wild, or are you being > > misled by the fact that dtc's reference-to-phandle and > > reference-to-path syntax is very similar: > > Yes, I was indeed being misled. Thanks for the clarification. The > "&fred" syntax is present in the .dts files that I have looked at. Right, it's all about the context. &label is always a reference to another node, but in cell context < ... > that's expanded as a phandle, in bare context it's expanded as a path. > > prop = <&fred>; > > Will generate a phandle valued property, but > > prop = &fred; > > Will generate a string (path) valued property. > > > >> For binding a Linux unit number to a device node, I would prefer to > >> decorate the node with a property like "linux,unit#", instead of > >> breaking the standard semantics of /aliases. > > > > I don't see how using aliases for unit numbering (inherently) breaks > > the semantics of /aliases. If phandle valued properties are being > > used that is wrong, but it's not necessary for the unit numbering > > anyway. > > I agree, the use of string-valued /aliases is not a semantic problem. > That said, I still think that decorating individual nodes is a better > approach, for locality reasons. But, now that my misunderstanding has > been cleared up, it's a mild preference instead of "heartburn". So, I think aliases was suggested for this sort of numbering precisely because it _isn't_ local. Particularly when numbering similar devices across unrelated busses, the ordering more or less has to be a global platform convention, and may not be derived from - or even contradict - local numbering conventions from individual busses or components. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- 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 V3 0/3] Watchdog: OMAP3: bootstatus fix and changes for the current watchdog framework
Hello, The following patches based on the 3.5-rc6 from Wim, which focus on: 1. bootstatus fix for omap3, 2. omap-wdt framework update cater for the current framework as Shubhrajyoti comments mentioned. V3 changes: 1. New comments updated as Kevin mentioned in the third patch; 2. 3530evm works well, AM33xx seems work well with the following changes: + if (cpu_is_am335x()) + return omap2_prm_read_mod_reg(AM33XX_PRM_DEVICE_MOD, + AM33XX_PRM_RSTST_OFFSET) & 0x7f; But since some definitions not ready for am33xx, so I don't give the patch, if they have been updated, feel free to take these. Regards, Zumeng Chen (3): Watchdog: Omap: Changes for the new watchdog framework Watchdog: Omap: select watchdog core for framework change Watchdog: Omap: get the bootstatus for OMAP34xx arch/arm/mach-omap2/prcm.c |9 +- drivers/watchdog/Kconfig|1 + drivers/watchdog/omap_wdt.c | 342 --- drivers/watchdog/omap_wdt.h |5 + 4 files changed, 136 insertions(+), 221 deletions(-) -- 1.7.5.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
[PATCH RESEND v3 2/3] Watchdog: Omap: select watchdog core for framework change
Since the current watchdog framework depends on the watchdog core so select it in Kconfig. Signed-off-by: Zumeng Chen --- drivers/watchdog/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index fe819b7..fb5b108 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -232,6 +232,7 @@ config EP93XX_WATCHDOG config OMAP_WATCHDOG tristate "OMAP Watchdog" depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS + select WATCHDOG_CORE help Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog. Say 'Y' here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog timer. -- 1.7.5.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
[PATCH RESEND v3 3/3] Watchdog: Omap: get the bootstatus for OMAP34xx
The offset of WKUP_MOD is not right for the PRM_RSTST of OMAP3. So here
put the right one to match to the actual physical addr 0x48307258, which
defined in PRCM Registers section named as Global_Reg_PRM.
And there is a MPU_WD_RST bit in PRM_RSTST(0x48307258) holding the signal
from omap-wdt reboot, so that we can return WDIOF_CARDRESET if the board
wakes up from omap-wdt reboot for WDIOC_GETBOOTSTATUS ioctl.
Signed-off-by: Zumeng Chen
---
arch/arm/mach-omap2/prcm.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..3ca8aa7 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -48,9 +48,14 @@ void __iomem *prcm_mpu_base;
u32 omap_prcm_get_reset_sources(void)
{
- /* XXX This presumably needs modification for 34XX */
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ if (cpu_is_omap24xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST) & 0x7f;
+
+ /* XXX This presumably needs modification for AM33XX when ready. */
+ if (cpu_is_omap34xx())
+ return omap2_prm_read_mod_reg(OMAP3430_GR_MOD, OMAP2_RM_RSTST) &
+ 0x7f;
+
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST) & 0x7f;
--
1.7.5.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
[PATCH RESEND v3 1/3] Watchdog: Omap: Changes for the new watchdog framework
This patch implements the current watchdog framework for OMAP WDTimer,
which factored out the common components, so the driver can just focus
on the hardware related parts.
Signed-off-by: Zumeng Chen
---
drivers/watchdog/omap_wdt.c | 342 ---
drivers/watchdog/omap_wdt.h |5 +
2 files changed, 128 insertions(+), 219 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..cc5bc3e 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -24,6 +24,9 @@
*
* Copyright (c) 2005 David Brownell
* Use the driver model and standard identifiers; handle bigger timeouts.
+ *
+ * Copyright (c) 2012 WindRiver
+ * Changes cater for the current watchdog framework.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -33,7 +36,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -50,8 +52,6 @@
#include "omap_wdt.h"
-static struct platform_device *omap_wdt_dev;
-
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
@@ -59,32 +59,14 @@ MODULE_PARM_DESC(timer_margin, "initial watchdog timeout
(in seconds)");
static unsigned int wdt_trgr_pattern = 0x1234;
static DEFINE_SPINLOCK(wdt_lock);
-struct omap_wdt_dev {
+struct omap_wdt_drvdata {
+ struct watchdog_device wdt;
void __iomem*base; /* physical */
struct device *dev;
- int omap_wdt_users;
struct resource *mem;
- struct miscdevice omap_wdt_miscdev;
};
-static void omap_wdt_ping(struct omap_wdt_dev *wdev)
-{
- void __iomem*base = wdev->base;
-
- /* wait for posted write to complete */
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
- cpu_relax();
-
- wdt_trgr_pattern = ~wdt_trgr_pattern;
- __raw_writel(wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
-
- /* wait for posted write to complete */
- while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
- cpu_relax();
- /* reloaded WCRR from WLDR */
-}
-
-static void omap_wdt_enable(struct omap_wdt_dev *wdev)
+static void omap_wdt_enable(struct omap_wdt_drvdata *wdev)
{
void __iomem *base = wdev->base;
@@ -98,7 +80,7 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
cpu_relax();
}
-static void omap_wdt_disable(struct omap_wdt_dev *wdev)
+static void omap_wdt_disable(struct omap_wdt_drvdata *wdev)
{
void __iomem *base = wdev->base;
@@ -121,12 +103,19 @@ static void omap_wdt_adjust_timeout(unsigned new_timeout)
timer_margin = new_timeout;
}
-static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
+static int omap_wdt_set_timeout(struct watchdog_device *wdt_dev,
+ unsigned int new_timeout)
{
- u32 pre_margin = GET_WLDR_VAL(timer_margin);
- void __iomem *base = wdev->base;
+ u32 pre_margin;
+ struct omap_wdt_drvdata *omap_wdev = watchdog_get_drvdata(wdt_dev);
+ void __iomem *base = omap_wdev->base;
- pm_runtime_get_sync(wdev->dev);
+ pm_runtime_get_sync(omap_wdev->dev);
+ omap_wdt_disable(omap_wdev);
+
+ /* adjust timeout based on the new timeout */
+ omap_wdt_adjust_timeout(new_timeout);
+ pre_margin = GET_WLDR_VAL(timer_margin);
/* just count up at 32 KHz */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
@@ -136,147 +125,88 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
*wdev)
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x04)
cpu_relax();
- pm_runtime_put_sync(wdev->dev);
+ omap_wdt_enable(omap_wdev);
+ wdt_dev->timeout = new_timeout;
+ pm_runtime_put_sync(omap_wdev->dev);
+ return 0;
}
-/*
- * Allow only one task to hold it open
- */
-static int omap_wdt_open(struct inode *inode, struct file *file)
+static int omap_wdt_ping(struct watchdog_device *wdt_dev)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev->base;
-
- if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
- return -EBUSY;
-
- pm_runtime_get_sync(wdev->dev);
+ struct omap_wdt_drvdata *omap_wdev = watchdog_get_drvdata(wdt_dev);
+ void __iomem*base = omap_wdev->base;
- /* initialize prescaler */
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
- cpu_relax();
+ pm_runtime_get_sync(omap_wdev->dev);
+ spin_lock(&wdt_lock);
- __raw_writel((1 << 5) | (PTV << 2), base + OMAP_WATCHDOG_CNTRL);
- while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
+ /* wait for posted write to complete */
+ while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
cpu_relax();
- file->private_data = (void *) wdev;
+
Re: [PATCH] remoteproc: allocate vrings on demand, free when not needed
On Sun, May 20, 2012 at 3:00 PM, Ohad Ben-Cohen wrote: > Dynamically allocate the vrings' DMA when the remote processor > is about to be powered on (i.e. when ->find_vqs() is invoked), > and release them as soon as it is powered off (i.e. when ->del_vqs() > is invoked). > > The obvious and immediate benefit is better memory utilization, since > memory for the vrings is now only allocated when the relevant remote > processor is being used. > > Additionally, this approach also makes recovery of a (crashing) > remote processor easier: one just needs to remove the relevant > vdevs, and the entire vrings cleanup takes place automagically. > > Tested-by: Fernando Guzman Lugo > Signed-off-by: Ohad Ben-Cohen > --- > drivers/remoteproc/remoteproc_core.c | 109 > +++--- > drivers/remoteproc/remoteproc_internal.h |2 + > drivers/remoteproc/remoteproc_virtio.c | 13 +++- > 3 files changed, 67 insertions(+), 57 deletions(-) Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remoteproc: maintain a generic child device for each rproc
On Thu, Jul 5, 2012 at 11:35 PM, Stephen Boyd wrote: > Ok then. Please add > > Reviewed-by: Stephen Boyd Added, and applied patch. thanks! > It would be nice if you got an ack from Greg or Kay on the device_type > usage too. I agree, I'd just hate bothering them on this now. Probably a topic for a conference chat :) -- 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/2] remoteproc: remove the now-redundant kref
On Sat, May 26, 2012 at 10:36 AM, Ohad Ben-Cohen wrote:
> Now that every rproc instance contains a device, we don't need a
> kref anymore to maintain the refcount of the rproc instances:
> that's what device are good with!
>
> This patch removes the now-redundant kref, and switches to
> {get, put}_device instead of kref_{get, put}.
>
> We also don't need the kref's release function anymore, and instead,
> we just utilize the class's release handler (which is now responsible
> for all memory de-allocations).
>
> Cc: Stephen Boyd
> Cc: Fernando Guzman Lugo
> Signed-off-by: Ohad Ben-Cohen
> ---
> drivers/remoteproc/remoteproc_core.c | 59
> +++-
> drivers/remoteproc/remoteproc_virtio.c |8 ++--
> include/linux/remoteproc.h |3 --
> 3 files changed, 24 insertions(+), 46 deletions(-)
Applied (after moving the kerneldoc for rproc_class_release() to the
patch where that function was introduced).
--
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/2] remoteproc: remove the now-redundant kref
On Mon, Jul 2, 2012 at 11:52 AM, Ohad Ben-Cohen wrote: > From 0fbf3004c1a52ae4c0554366409a2bfe401801ef Mon Sep 17 00:00:00 2001 > From: Ohad Ben-Cohen > Date: Mon, 2 Jul 2012 11:41:16 +0300 > Subject: [PATCH] remoteproc: simplify unregister/free interfaces > > Simplify the unregister/free interfaces, and make them easier > to understand and use, by moving to a symmetric and consistent > alloc() -> register() -> unregister() -> free() flow. > > To create and register an rproc instance, one needed to invoke > rproc_alloc() followed by rproc_register(). > > To unregister and free an rproc instance, one now needs to invoke > rproc_unregister() followed by rproc_free(). > > Cc: Stephen Boyd > Signed-off-by: Ohad Ben-Cohen > --- > Documentation/remoteproc.txt | 21 - > drivers/remoteproc/omap_remoteproc.c | 5 - > drivers/remoteproc/remoteproc_core.c | 25 - > 3 files changed, 20 insertions(+), 31 deletions(-) Applied. -- 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] remoteproc: remove the get_by_name/put API
On Tue, Jul 3, 2012 at 9:11 PM, Stephen Boyd wrote: > On 07/02/12 13:10, Ohad Ben-Cohen wrote: >> Remove rproc_get_by_name() and rproc_put(), and the associated >> remoteproc infrastructure that supports it (i.e. klist and friends), >> because: >> >> 1. No one uses them >> 2. Using them is highly discouraged, and any potential user >>will be deeply scrutinized and encouraged to move. >> >> If a user, that absolutely can't live with the direct boot/shutdown >> model, does show up one day, then bringing this functionality back >> is going to be trivial. >> >> At this point though, keeping this functionality around is way too >> much of a maintenance burden. >> > > Acked-by: Stephen Boyd Thanks, applied. -- 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] remoteproc: adopt the driver core's alloc/add/del/put naming
On Thu, Jul 5, 2012 at 5:50 AM, Stephen Boyd wrote: > On 7/4/2012 6:36 AM, Ohad Ben-Cohen wrote: >> To make remoteproc's API more intuitive for developers, we adopt >> the driver core's naming, i.e. alloc -> add -> del -> put. We'll also >> add register/unregister when their first user shows up. >> >> Otherwise - there's no functional change here. >> >> Suggested by Russell King . >> >> Cc: Russell King > > Acked-by: Stephen Boyd On Thu, Jul 5, 2012 at 2:50 AM, Linus Walleij wrote: > I understand this patch and it's a good thing, so: > Reviewed-by: Linus Walleij > > Yours, > Linus Walleij Thanks Linus and Stephen. Applied. -- 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 RFT 1/2] regulator: twl: Fix the formula to calculate vsel and voltage for twl6030ldo
On Mon, Jul 09, 2012 at 07:01:26PM +0800, Axel Lin wrote: > I found a problem that before commit 3e3d3be79c, the voltage tables were > not linear mapping. So why we can convert these voltage mapping table to > Voltage(in mV) = 1000mv + 100mv * (vsel - 1)? Guys, it's pretty concerning that there's been no response at all to this. Looking at the changes Axel's statement above is accurate for at least VAUX1 and VMMC, I didn't check all the regulators, so either the original code was buggy or there's an issue that needs fixing in the current code. signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP: hwmod: Disable module when hwmod enable fails
On Fri, 6 Jul 2012, Rajendra Nayak wrote: > From: Misael Lopez Cruz > > Clock and module mode are explictly enable when hwmod is enabled. But if > the hwmod doesn't get ready on time, clocks are disabled but module is left > enabled. > > Signed-off-by: Misael Lopez Cruz > Signed-off-by: Rajendra Nayak > Cc: Paul Walmsley > Cc: Benoit Cousson Thanks, queued for 3.6-rc. - Paul -- 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/6] ARM: OMAP3: hwmod data: fix iva2 reset info
On Fri, 13 Jul 2012, Tero Kristo wrote: > IVA2 hwmod resets were missing the status bit offsets. Also, as the > hwmod itself didn't have prcm info at all, resetting iva hwmod was > accessing some bogus memory addresses. Added both infos to fix this. > > Signed-off-by: Tero Kristo Thanks, this one looks like it's fodder for the -rc series due to the accesses, so, queuing for 3.6-rc. - Paul -- 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 5/6] ARM: OMAP3: hwmod data: add sad2d hwmod
On Fri, 13 Jul 2012, Tero Kristo wrote: > SAD2D stands for the die to die interface, and is used for communicating > with the optional stacked modem. This hwmod is added in preparation for > the d2d_idle move from pm34xx.c to hwmod data. > > Signed-off-by: Tero Kristo Thanks, queued this for 3.7. - Paul -- 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 5/6] ARM: OMAP3: hwmod data: add sad2d hwmod
Hi
One comment
On Fri, 13 Jul 2012, Tero Kristo wrote:
> @@ -3203,6 +3239,7 @@ static struct omap_hwmod_ocp_if
> *omap3xxx_hwmod_ocp_ifs[] __initdata = {
> &omap34xx_l4_core__mcspi3,
> &omap34xx_l4_core__mcspi4,
> &omap3xxx_l4_wkup__counter_32k,
> + &omap3xxx_sad2d__l3,
> NULL,
This part of the patch doesn't seem right. As far as I know, AM35xx
doesn't support the D2D interface. So it wouldn't make sense to add this
to the OMAP3-common list. So instead the patch has been updated here to
add this to the OMAP34xx and OMAP36xx lists.
Updated patch below.
- Paul
From: Tero Kristo
Date: Fri, 13 Jul 2012 19:37:38 +0300
Subject: [PATCH] ARM: OMAP3: hwmod data: add sad2d hwmod
SAD2D stands for the die to die interface, and is used for communicating
with the optional stacked modem. This hwmod is added in preparation for
the d2d_idle move from pm34xx.c to hwmod data.
Signed-off-by: Tero Kristo
[p...@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx,
so only add it to the OMAP34xx/OMAP36xx lists]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 37
2 files changed, 39 insertions(+)
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 975f6bd..59598ff 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -218,6 +218,8 @@
#define OMAP3430_ST_MAILBOXES_MASK (1 << 7)
#define OMAP3430_ST_OMAPCTRL_SHIFT 6
#define OMAP3430_ST_OMAPCTRL_MASK (1 << 6)
+#define OMAP3430_ST_SAD2D_SHIFT3
+#define OMAP3430_ST_SAD2D_MASK (1 << 3)
#define OMAP3430_ST_SDMA_SHIFT 2
#define OMAP3430_ST_SDMA_MASK (1 << 2)
#define OMAP3430_ST_SDRC_SHIFT 1
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ce7e606..0dce77e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2033,6 +2033,33 @@ static struct omap_hwmod omap3xxx_hdq1w_hwmod = {
.class = &omap2_hdq1w_class,
};
+/* SAD2D */
+static struct omap_hwmod_rst_info omap3xxx_sad2d_resets[] = {
+ { .name = "rst_modem_pwron_sw", .rst_shift = 0 },
+ { .name = "rst_modem_sw", .rst_shift = 1 },
+};
+
+static struct omap_hwmod_class omap3xxx_sad2d_class = {
+ .name = "sad2d",
+};
+
+static struct omap_hwmod omap3xxx_sad2d_hwmod = {
+ .name = "sad2d",
+ .rst_lines = omap3xxx_sad2d_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap3xxx_sad2d_resets),
+ .main_clk = "sad2d_ick",
+ .prcm = {
+ .omap2 = {
+ .module_offs = CORE_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_SAD2D_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_SAD2D_SHIFT,
+ },
+ },
+ .class = &omap3xxx_sad2d_class,
+};
+
/*
* '32K sync counter' class
* 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
@@ -2137,6 +2164,14 @@ static struct omap_hwmod_ocp_if am35xx_usbhsotg__l3 = {
.user = OCP_USER_MPU,
};
+/* l3_core -> sad2d interface */
+static struct omap_hwmod_ocp_if omap3xxx_sad2d__l3 = {
+ .master = &omap3xxx_sad2d_hwmod,
+ .slave = &omap3xxx_l3_main_hwmod,
+ .clk= "core_l3_ick",
+ .user = OCP_USER_MPU,
+};
+
/* L4_CORE -> L4_WKUP interface */
static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
.master = &omap3xxx_l4_core_hwmod,
@@ -3371,6 +3406,7 @@ static struct omap_hwmod_ocp_if *omap34xx_hwmod_ocp_ifs[]
__initdata = {
&omap34xx_l4_core__sr2,
&omap3xxx_l4_core__mailbox,
&omap3xxx_l4_core__hdq1w,
+ &omap3xxx_sad2d__l3,
NULL
};
@@ -3391,6 +3427,7 @@ static struct omap_hwmod_ocp_if *omap36xx_hwmod_ocp_ifs[]
__initdata = {
&omap3xxx_l4_core__es3plus_mmc1,
&omap3xxx_l4_core__es3plus_mmc2,
&omap3xxx_l4_core__hdq1w,
+ &omap3xxx_sad2d__l3,
NULL
};
--
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
