Re: [PATCH 02/29] clk: Add CLK_IS_BASIC flag to identify basic clocks
On Tue, Jul 3, 2012 at 5:34 AM, Rajendra Nayak rna...@ti.com wrote:
Hi Mike,
On Thursday 14 June 2012 06:16 PM, Rajendra Nayak wrote:
Most platforms end up using a mix of basic clock types and
some which use clk_hw_foo struct for filling in custom platform
information when the clocks don't fit into basic types supported.
In platform code, its useful to know if a clock is using a basic
type or clk_hw_foo, which helps platforms know if they can
safely use to_clk_hw_foo to derive the clk_hw_foo pointer from
clk_hw.
Mark all basic clocks with a CLK_IS_BASIC flag.
Signed-off-by: Rajendra Nayakrna...@ti.com
While you have already pulled all of my other patches touching
the Common Clk framework, which were part of this series, this is
one patch where there hasn't been any discussion. Do you have any
thoughts on this patch?
See 'Patch 15/29: ARM: omap: clk: list all clk_hw_omap clks to
enable/disable autoidle' how I use this to create a clk_hw_omap
specific list to handle clock autoidle in OMAP.
Hi Rajendra,
I don't have any outstanding review comments for this patch and I've
taken it into clk-next. Pull the latest and you'll find it there.
Thanks,
Mike
regards,
Rajendra
---
drivers/clk/clk-divider.c |2 +-
drivers/clk/clk-fixed-factor.c |2 +-
drivers/clk/clk-fixed-rate.c |2 +-
drivers/clk/clk-gate.c |2 +-
drivers/clk/clk-mux.c |2 +-
include/linux/clk-private.h|2 +-
include/linux/clk-provider.h |1 +
7 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index e4911ee..53f9dd7 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -266,7 +266,7 @@ struct clk *clk_register_divider(struct device *dev,
const char *name,
init.name = name;
init.ops =clk_divider_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ?parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
diff --git a/drivers/clk/clk-fixed-factor.c
b/drivers/clk/clk-fixed-factor.c
index c8c003e..a489985 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -82,7 +82,7 @@ struct clk *clk_register_fixed_factor(struct device
*dev, const char *name,
init.name = name;
init.ops =clk_fixed_factor_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names =parent_name;
init.num_parents = 1;
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index cbd2462..7e14645 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -63,7 +63,7 @@ struct clk *clk_register_fixed_rate(struct device *dev,
const char *name,
init.name = name;
init.ops =clk_fixed_rate_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ?parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 578465e..15114fe 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -130,7 +130,7 @@ struct clk *clk_register_gate(struct device *dev,
const char *name,
init.name = name;
init.ops =clk_gate_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = (parent_name ?parent_name: NULL);
init.num_parents = (parent_name ? 1 : 0);
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index fd36a8e..508c032 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -106,7 +106,7 @@ struct clk *clk_register_mux(struct device *dev, const
char *name,
init.name = name;
init.ops =clk_mux_ops;
- init.flags = flags;
+ init.flags = flags | CLK_IS_BASIC;
init.parent_names = parent_names;
init.num_parents = num_parents;
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 2479239..0835bda 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -64,7 +64,7 @@ struct clk {
.parent_names = _parent_names, \
.num_parents = ARRAY_SIZE(_parent_names), \
.parents = _parents,\
- .flags = _flags,\
+ .flags = _flags | CLK_IS_BASIC, \
}
#define DEFINE_CLK_FIXED_RATE(_name, _flags, _rate, \
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index aa63aca..4b94f59 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -25,6 +25,7 @@
#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one
level */
#define CLK_IGNORE_UNUSED
Re: [GIT PULL 1/6] omap non-critical fixes for v3.6 merge window
* Arnd Bergmann a...@arndb.de [120703 13:28]: On Sunday 01 July 2012, Tony Lindgren wrote: The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc: Linux 3.5-rc4 (2012-06-24 12:53:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-non-critical-for-v3.6 Merged all six pull request. Thanks a lot for all your thorough work, it's always great to pull requests like these. I ended up putting both tags/omap-devel-pm-for-v3.6 and and tags/omap-devel-driver-for-v3.6 into the next/pm branch as they are both mostly power management related in some way. Everything else went into the obvious place. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.5-rc3: PM/DSS broken (was vdd_mpu_iva warnings)
On Tue, 2012-07-03 at 16:29 +0530, Archit Taneja wrote: Thanks for testing this out. I was going through Tomi's queue for the 3.6 merge window: git://gitorious.org/linux-omap-dss2/linux.git master There is a commit called: 2b8501d777346ce1d4fe99167e9b3c0e42aae7a8 OMAPDSS: Use PM notifiers for system suspend The commit message mentions the issue you see, and seems to resolve it. Could you give this a try? Tomi is out on vacation, and I don't know why this wasn't intended for the 3.5-rcs, maybe there are still some discussion going on about this? I just missed it due to the pre-vacation hassle, I was so focused on getting the stuff ready for next merge window. With a quick glance to my master branch, the OMAPDSS: Use PM notifiers for system suspend looks like it could go for 3.5-rc, and also OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n. Archit, can you check that both apply fine to mainline, and send them to Florian for 3.5-rc. And make clear they are for him, so that he doesn't think I'll handle them =). Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 02/29] clk: Add CLK_IS_BASIC flag to identify basic clocks
On Wednesday 04 July 2012 11:48 AM, Turquette, Mike wrote: Hi Rajendra, I don't have any outstanding review comments for this patch and I've taken it into clk-next. Pull the latest and you'll find it there. great, thanks Mike. Thanks, Mike -- 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: [GIT PULL 6/6] am33xx changes for v3.6 merge window
* Hiremath, Vaibhav hvaib...@ti.com [120703 05:00]: On Tue, Jul 03, 2012 at 17:18:56, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120703 04:37]: Few patches got missed in this pull request, ARM: OMAP2+: am33xx: Make am33xx as a separate class ARM: OMAP2+: am33xx: Change cpu_is_am33xx to soc_is_am33xx OK, at least the first needs to be rebased to apply. Can you please refresh those against current devel-am33xx branch at commit 6fd8246b1c1167c983b089f9eaafa13ef9ca7adf and repost? I'll do a separate pull request for those once they are ready. Thanks Tony, I will resubmit them again today. Also, request you to review and merge Cleanup patch-series I had posted few days back. Yes thanks will look. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120702 10:30]: 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. Sorry, not sure whether I follow you properly, based on what has been understood, will try to rephrase, All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-* to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e like smsc911x, tusb6010 needs to register their retime function with gpmc driver. And gpmc driver will invoke these registered retime function, when clock frequency changes. But wouldn't it need changes in the existing drivers like smsc911x that are used by multiple architectures with gpmc specific registration (put under a macro ?). We will be having gpmc driver code that contains knowledge about peripheral timing calculation, seems there is no way out of this. Peripheral agnostic gpmc code may not happen it seems In that case gpmc driver probe would have to be relieved of the task of setting up gpmc timings as we have to wait till peripheral drivers register their callback, right ?, seems in that case no timing information needs (or can be) to be passed from DT It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. I believe you are referring to tusb6010_platform_retime(), other than during initial setup, i.e. in tusb6010_setup_interface(), it is not invoked. tusb6010_platform_retime() is an exported symbol, unless I am missing something it is not invoked other than during initial setup. Did find this function in tusb6010.c, it is commented out, may be this was present earlier ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class
* Vaibhav Hiremath hvaib...@ti.com [120703 06:12]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_AM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Thanks applying both. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/5] ARM: OMAP: TLL driver implementation for USB host driver
Hi On Mon, 2 Jul 2012, Keshava Munegowda wrote: The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. This sentence doesn't parse. Try something simpler like the TLL is an separate IP block, independent of the host controller, that basically acts as a USB PHY. Otherwise it's impossible for other people to understand what this IP block does. - 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: [PATCH-V3 1/3] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry
Hi Applying these, but few comments below to make my life easier.. * Vaibhav Hiremath hvaib...@ti.com [120628 08:04]: All OMAP2PLUS based devices, builds omap-device.o target; so just add one entry so that there is no need to patch this file for any future OMAP2+ devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com NOTE: No code change from last version. Extra comments like this should be within the --- sections so they down't show up when applying the patch. Otherwise I have to manually edit every patch, which sucks. Then, I'm leaving out the CLEANUP part in $Subject, that alone is not a reason to patch anything. The description should say why the patch is needed, which it does. If you want to specify that this should be grouped in the clean-up branch, then that too could be mentioned within the --- sections. --- arch/arm/plat-omap/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 6d87532..961bf85 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -10,9 +10,7 @@ obj-n := obj- := # omap_device support (OMAP2+ only at the moment) -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o -- 1.7.0.4 This patch did not apply for some reason, I got: patching file arch/arm/plat-omap/Makefile patch: malformed patch at line 73: 1.7.0.4 So please tune up your scripts a bit to the patches can be applied as they are without manual editing ;) Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 5/5] ARM: OMAP: change the USB TLL clocks device name
On Mon, 2 Jul 2012, Keshava Munegowda wrote: The platform device name for the functional, interface and channel clocks of the TLL module is changed from usbhs device to usb tll platform device name. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com The basic idea of this patch looks reasonable, but you should make sure that this series doesn't result in a broken TLL at any point during the series. Otherwise 'git bisect' operations will break. To do this, you'll presumably need to add the new clkdev aliases much earlier in the series, and remove the old ones at the end of the series. - 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: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120704 00:05]: Hi Tony, On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [120702 10:30]: 2. Provide some sort of retime callback that the gpmc driver can call at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. Sorry, not sure whether I follow you properly, based on what has been understood, will try to rephrase, All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-* to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e like smsc911x, tusb6010 needs to register their retime function with gpmc driver. And gpmc driver will invoke these registered retime function, when clock frequency changes. But wouldn't it need changes in the existing drivers like smsc911x that are used by multiple architectures with gpmc specific registration (put under a macro ?). We will be having gpmc driver code that contains knowledge about peripheral timing calculation, seems there is no way out of this. Peripheral agnostic gpmc code may not happen it seems It depends. For some drivers scaling both gpmc clock and the device clock can happen, like with tusb6010 for example. But the smsc911x does not know about the clocks.. So to additional changes to the driver would be required to if device clocks need scaling. But for now, we should be able to do it at gpmc level with the retime function, or just disable DFS for those clocks if not supported. The ideal solution in the long run would be to have gpmc scaling frequency as the bus and device scaling frequency using cpufreq/devicefreq whatever notifiers. In that case gpmc driver probe would have to be relieved of the task of setting up gpmc timings as we have to wait till peripheral drivers register their callback, right ?, seems in that case no timing information needs (or can be) to be passed from DT Well we should pass all the gpmc timing information from DT. And then the driver also still needs to register it's retime function with gpmc. It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. I believe you are referring to tusb6010_platform_retime(), other than during initial setup, i.e. in tusb6010_setup_interface(), it is not invoked. tusb6010_platform_retime() is an exported symbol, unless I am missing something it is not invoked other than during initial setup. Did find this function in tusb6010.c, it is commented out, may be this was present earlier ? Hmm yes looks like it's commented out.. But in theory the retime function should be called between idle clock and runtime clock. And also for DFS, so it's something we should be considered for proper gpmc support. 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] remoteproc: fix missing CONFIG_FW_LOADER configurations
Remoteproc requires user space firmware loading support, so let's select FW_LOADER explicitly to avoid painful misconfigurations (which only show up in runtime). Cc: stable sta...@vger.kernel.org Reported-by: Mark Grosen mgro...@ti.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/remoteproc/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index db4e39b..f8d818a 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -4,6 +4,7 @@ menu Remoteproc drivers (EXPERIMENTAL) config REMOTEPROC tristate depends on EXPERIMENTAL + select FW_CONFIG config OMAP_REMOTEPROC tristate OMAP remoteproc support -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class
* Tony Lindgren t...@atomide.com [120704 00:29]: * Vaibhav Hiremath hvaib...@ti.com [120703 06:12]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_AM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Thanks applying both. I believe all your patches are now applied. I've pushed them out into devel-am33xx-part2 branch. Can you please check and send additional patches as needed? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 5/5] ARM: OMAP: change the USB TLL clocks device name
On Wed, Jul 4, 2012 at 1:00 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 2 Jul 2012, Keshava Munegowda wrote: The platform device name for the functional, interface and channel clocks of the TLL module is changed from usbhs device to usb tll platform device name. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com The basic idea of this patch looks reasonable, but you should make sure that this series doesn't result in a broken TLL at any point during the series. Otherwise 'git bisect' operations will break. To do this, you'll presumably need to add the new clkdev aliases much earlier in the series, and remove the old ones at the end of the series. Thanks Paul I will change this. please let me if you have other comments on this series. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: hwmod data: temporarily remove data for the usb_host_fs and aess IP blocks
On Tue, 3 Jul 2012, Benoit Cousson wrote:
On 06/30/2012 05:53 AM, Paul Walmsley wrote:
The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle. Without this programming, they
will prevent the rest of the chip from entering full chip idle.
To implement the idle programming cleanly, this will take some
coordination between maintainers. This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7. So, in the
meantime, simply remove this data.
I'd rather keep the data and comment the ocp_if entry.
We can even add a disclaimer on top to explain the reason.
It will be less confusing for the driver folks that are currently working on
the AESS support.
It will as well minimize the churn.
Well I'm not a big fan of adding __maybe_unused to this data, but I guess
changing the approach doesn't matter that much to me. Updated patch
below.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Fri, 29 Jun 2012 17:10:41 -0600
Subject: [PATCH] ARM: OMAP4: hwmod data: temporarily comment out data for the
usb_host_fs and aess IP blocks
The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle. Without this programming, they
will prevent the rest of the chip from entering full chip idle.
To implement the idle programming cleanly, this will take some
coordination between maintainers. This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7. So, in the
meantime, prevent these IP blocks from being registered.
Later, once the appropriate support is available, this patch can be
reverted.
This second version comments out the IP block data since Benoît didn't
like removing it.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f30e861..0a1b247 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3864,7 +3864,7 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_2 = {
};
/* usb_host_fs - l3_main_2 */
-static struct omap_hwmod_ocp_if omap44xx_usb_host_fs__l3_main_2 = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_usb_host_fs__l3_main_2
= {
.master = omap44xx_usb_host_fs_hwmod,
.slave = omap44xx_l3_main_2_hwmod,
.clk= l3_div_ck,
@@ -3922,7 +3922,7 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_cfg__l3_main_3 = {
};
/* aess - l4_abe */
-static struct omap_hwmod_ocp_if omap44xx_aess__l4_abe = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_aess__l4_abe = {
.master = omap44xx_aess_hwmod,
.slave = omap44xx_l4_abe_hwmod,
.clk= ocp_abe_iclk,
@@ -4013,7 +4013,7 @@ static struct omap_hwmod_addr_space omap44xx_aess_addrs[]
= {
};
/* l4_abe - aess */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__aess = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_l4_abe__aess = {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_aess_hwmod,
.clk= ocp_abe_iclk,
@@ -4031,7 +4031,7 @@ static struct omap_hwmod_addr_space
omap44xx_aess_dma_addrs[] = {
};
/* l4_abe - aess (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__aess_dma = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_l4_abe__aess_dma = {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_aess_hwmod,
.clk= ocp_abe_iclk,
@@ -5857,7 +5857,7 @@ static struct omap_hwmod_addr_space
omap44xx_usb_host_fs_addrs[] = {
};
/* l4_cfg - usb_host_fs */
-static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_fs = {
+static struct omap_hwmod_ocp_if __maybe_unused omap44xx_l4_cfg__usb_host_fs = {
.master = omap44xx_l4_cfg_hwmod,
.slave = omap44xx_usb_host_fs_hwmod,
.clk= l4_div_ck,
@@ -6014,13 +6014,13 @@ static struct omap_hwmod_ocp_if
*omap44xx_hwmod_ocp_ifs[] __initdata = {
omap44xx_iva__l3_main_2,
omap44xx_l3_main_1__l3_main_2,
omap44xx_l4_cfg__l3_main_2,
- omap44xx_usb_host_fs__l3_main_2,
+ /* omap44xx_usb_host_fs__l3_main_2, */
omap44xx_usb_host_hs__l3_main_2,
omap44xx_usb_otg_hs__l3_main_2,
omap44xx_l3_main_1__l3_main_3,
omap44xx_l3_main_2__l3_main_3,
omap44xx_l4_cfg__l3_main_3,
- omap44xx_aess__l4_abe,
+ /* omap44xx_aess__l4_abe, */
omap44xx_dsp__l4_abe,
omap44xx_l3_main_1__l4_abe,
omap44xx_mpu__l4_abe,
@@ -6029,8 +6029,8 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l4_cfg__l4_wkup,
Re: [PATCH] OMAP4: Clock: Correct OTG clock to use otg_60m_gfclk.
On Mon, 2 Jul 2012, Benoit Cousson wrote: Unfortunately the clock fmwk cannot handle module as a clock node. Hmm. We have to have similar support in the clockfw for the CLKDIV32K clock for AM33xx. That uses the modulemode bits to enable and disable the clock. Or does this require something more complicated? - 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: [PATCH] ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework
On Tue, 3 Jul 2012, Hiremath, Vaibhav wrote: On Thu, Jun 28, 2012 at 21:14:16, Hiremath, Vaibhav wrote: AM33XX PRCM architecture is different that any OMAP family of devices, so it is required to have separate implementation to handle AM33XX module enable/disable, reset assert/deassert functionality. This patch adds wrapper api's in omap_hwmod framework to access prm/cm for AM33XX family of devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com --- Ping !!! Doesn't this have a cross-dependency on Kevin's series that is part of this tag: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=tag;h=0c66cfc31db4d4fc97c50ecf96fc5e3807a039ee ? If so then it probably makes sense for this to wait until 3.7, since Tony's AM33xx devel branch is based on v3.5-rc1. - 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: [PATCH-V3 1/3] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry
On Wed, Jul 04, 2012 at 12:57:58, Tony Lindgren wrote: Hi Applying these, but few comments below to make my life easier.. * Vaibhav Hiremath hvaib...@ti.com [120628 08:04]: All OMAP2PLUS based devices, builds omap-device.o target; so just add one entry so that there is no need to patch this file for any future OMAP2+ devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com NOTE: No code change from last version. Extra comments like this should be within the --- sections so they down't show up when applying the patch. Otherwise I have to manually edit every patch, which sucks. Oops...my bad. These comments I keep deliberately after signoff so that I can move it after --- section while submitting, but somehow missed to do it for this patch-series. I will take care of it in the future, sorry for inconvenience. Then, I'm leaving out the CLEANUP part in $Subject, that alone is not a reason to patch anything. The description should say why the patch is needed, which it does. If you want to specify that this should be grouped in the clean-up branch, then that too could be mentioned within the --- sections. Point taken, and will follow now. --- arch/arm/plat-omap/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 6d87532..961bf85 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -10,9 +10,7 @@ obj-n := obj- := # omap_device support (OMAP2+ only at the moment) -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o -- 1.7.0.4 This patch did not apply for some reason, I got: patching file arch/arm/plat-omap/Makefile patch: malformed patch at line 73: 1.7.0.4 So please tune up your scripts a bit to the patches can be applied as they are without manual editing ;) H... I usually submit the patch against linux-omap/master (to handle cross dependencies), which in some cases fails on other branches you maintain. Probably I will make sure that it allies atleast to relevant branches, for example, in this case it should be applied on linux-omap/cleanup branch as well. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP AM33xx: clock data for 3.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 6fd8246b1c1167c983b089f9eaafa13ef9ca7adf: Merge tag 'omap-devel-a-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-am33xx (2012-06-22 01:50:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-e-for-3.5 for you to fetch changes up to e30384abd63dfa11508a38243e1d78f1d70486b1: ARM: OMAP3+: clock33xx: Add AM33XX clock tree data (2012-06-29 16:16:40 -0600) - OMAP AM33xx clock data - Test logs are at: http://www.pwsan.com/omap/testlogs/am33xx_clock_hwmod_devel_3.6/20120704015524/ All the usual v3.5-rc1 problems are visible. Note that this branch was not tested on an AM33xx itself, but Vaibhav Hiremath has apparently been doing this and the patches aren't significantly changed from his. object size (delta in bytes from test_6fd8246b1c1167c983b089f9eaafa13ef9ca7adf (6fd8246b1c1167c983b089f9eaafa13ef9ca7adf)): textdata bss total kernel 0+192 0+192 2430_testconfig/vmlinux 0 0 0 0 5912osk_testconfig/vmlinux +4272 +8000 0 +12272 am33xx_testconfig/vmlinux 0+192 0+192 n800_b_testconfig/vmlinux 0+160 0+160 n800_multi_omap2xxx/vmlinux 0+192 0+192 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux 0 0 0 0 omap2_4_testconfig/vmlinux +240 +8064 0 +8304 omap2plus_defconfig/vmlinux +176 +7744 0 +7920 omap2plus_no_pm/vmlinux +4272 +8000 0 +12272 omap3_4_testconfig/vmlinux +4264 +8192 0 +12456 omap3_testconfig/vmlinux 0 0 0 0 omap4_testconfig/vmlinux Paul Walmsley (1): ARM: OMAP3+: clock: Move common clksel_rate clock data to common file Vaibhav Hiremath (1): ARM: OMAP3+: clock33xx: Add AM33XX clock tree data arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/clock.h | 14 + arch/arm/mach-omap2/clock33xx_data.c | 1105 + arch/arm/mach-omap2/clock3xxx_data.c | 20 +- arch/arm/mach-omap2/clock44xx_data.c | 72 -- arch/arm/mach-omap2/clock_common_data.c | 77 ++ arch/arm/mach-omap2/io.c |2 + arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + 8 files changed, 1205 insertions(+), 88 deletions(-) create mode 100644 arch/arm/mach-omap2/clock33xx_data.c -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP9AuSAAoJEMePsQ0LvSpL97MQAKxhDSNn0eaZRU8fBUcktg+G ABgT6rYafascU1EwdR4xa0qi6PFbFKfN34azBVcoafbXIhz1ia3XszI3tPWRjDvV gZRj18IAbFOmJnO634gA4vecNEU1RBIGeHCRUVz3ILPpDYI3mg0zNE/w7pysbuZa /Su8uF09ei95vipWQswd8Mcrgm8QAN+xPHdkjjT4etl2/hsa8HXW5ofp0Yqa14VB eSpTYrRGcyD7I8wOMp8NRFOWggcvC2sRv9yZBQUcWRMo8HPsF8x38h+CWlScUhYN OB+Wd3/oFSyOuCmEaZ0AbEgg5LQ9zEpWutZ6Rgq/kAREalqs6rTgFYQrYcabNreA M8yGaZCk9bnsqxwDTJfL9dlt3M3H0Rv5TbFU6C/1bpXqAyioQN/OvRQPqCCkDP8G XerzFug0d+MwP6fWujOOPSLh2Fl4Gw54EgLQTkCalEMjLuQgZEzBo8a1IzU2kr82 bDkWjsGzwSaYlWidx4eYWaL6Esiztjj32x/JZwjPudtNIoKcTbQgjvzumoH+StFC wR7/xnvSVQXuDIt7UGRvYdua6qyG5VjVHkzjolShGuVcz64fKUM06njsK1Ifu0up ZLl66hEhbZx+RAW1Myu5jgUBq82VvRa8CowZy/SnVj8+15MLEYEulY4PobdKwjnp +q6sZask4hCxc7eiqogI =Po23 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework
On Wed, Jul 04, 2012 at 14:43:15, Paul Walmsley wrote: On Tue, 3 Jul 2012, Hiremath, Vaibhav wrote: On Thu, Jun 28, 2012 at 21:14:16, Hiremath, Vaibhav wrote: AM33XX PRCM architecture is different that any OMAP family of devices, so it is required to have separate implementation to handle AM33XX module enable/disable, reset assert/deassert functionality. This patch adds wrapper api's in omap_hwmod framework to access prm/cm for AM33XX family of devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com --- Ping !!! Doesn't this have a cross-dependency on Kevin's series that is part of this tag: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=tag;h=0c66cfc31db4d4fc97c50ecf96fc5e3807a039ee ? Yes it does, and was expecting it to go along with Kevin's series. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework
On Wed, Jul 04, 2012 at 14:43:15, Paul Walmsley wrote: On Tue, 3 Jul 2012, Hiremath, Vaibhav wrote: On Thu, Jun 28, 2012 at 21:14:16, Hiremath, Vaibhav wrote: AM33XX PRCM architecture is different that any OMAP family of devices, so it is required to have separate implementation to handle AM33XX module enable/disable, reset assert/deassert functionality. This patch adds wrapper api's in omap_hwmod framework to access prm/cm for AM33XX family of devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com --- Ping !!! Doesn't this have a cross-dependency on Kevin's series that is part of this tag: http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=tag;h=0c66cfc31db4d4fc97c50ecf96fc5e3807a039ee ? If so then it probably makes sense for this to wait until 3.7, since Tony's AM33xx devel branch is based on v3.5-rc1. Paul, Two more patches got missed last time, ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm Can this also be merged into your pull request? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: how to specify dma_mask and coherent_dma_mask in hwmod
On Mon, 2 Jul 2012, N, Mugunthan V wrote: Extending omap_device_build() to accommodate dma masks will endup with lot of code changes in other modules Why? - 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: [PATCH] ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework
On Wed, 4 Jul 2012, Hiremath, Vaibhav wrote: Yes it does, and was expecting it to go along with Kevin's series. The AM33xx patch isn't a cleanup -- it adds new functionality -- so it doesn't belong as part of a cleanup series. - 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: how to specify dma_mask and coherent_dma_mask in hwmod
On Thu, Jun 07, 2012 at 04:22:17PM +, N, Mugunthan V wrote: While converting platform device registry to Hwmod for CPSW Ethernet driver which is present in AM335X (OMAP2+), I am not finding a way to specify dma_mask and coherent_dma_mask. Is there a way to specify dma_mask and coherent_dma_mask in hwmod? Just remember that we're moving stuff to DMA engine, and that means the sDMA device has DMA masks, but none of the peripherals which make use of sDMA should have DMA masks set. The reason for this is because the device responsible for accessing memory is sDMA, not the peripheral device, and therefore any memory properties for DMA should come from the sDMA device, not the peripheral device. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: architected timers: Mark the clockevent with the C3_STOP feature
ARM arch timers stop in low power state and hence can not wakeup CPUs in deeper idle states when used as cloc event devices. Marking these clock event devices with C3_STOP so that during lowpower states, the tick is managed by wakeup capable broadcast timer. Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/arch_timer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c index dd58035..df44c8c 100644 --- a/arch/arm/kernel/arch_timer.c +++ b/arch/arm/kernel/arch_timer.c @@ -137,7 +137,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk) /* Be safe... */ arch_timer_disable(); - clk-features = CLOCK_EVT_FEAT_ONESHOT; + clk-features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP; clk-name = arch_sys_timer; clk-rating = 450; clk-set_mode = arch_timer_set_mode; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: architected timers: Mark the clockevent with the C3_STOP feature
On 04/07/12 10:54, Santosh Shilimkar wrote: ARM arch timers stop in low power state and hence can not wakeup CPUs in deeper idle states when used as cloc event devices. Marking these clock event devices with C3_STOP so that during lowpower states, the tick is managed by wakeup capable broadcast timer. Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Hi Santosh, I already have queued an identical patch from Lorenzo. Thanks for reminder anyway! M. --- arch/arm/kernel/arch_timer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c index dd58035..df44c8c 100644 --- a/arch/arm/kernel/arch_timer.c +++ b/arch/arm/kernel/arch_timer.c @@ -137,7 +137,7 @@ static int __cpuinit arch_timer_setup(struct clock_event_device *clk) /* Be safe... */ arch_timer_disable(); - clk-features = CLOCK_EVT_FEAT_ONESHOT; + clk-features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_C3STOP; clk-name = arch_sys_timer; clk-rating = 450; clk-set_mode = arch_timer_set_mode; -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: architected timers: Mark the clockevent with the C3_STOP feature
On Wed, Jul 4, 2012 at 3:26 PM, Marc Zyngier marc.zyng...@arm.com wrote: On 04/07/12 10:54, Santosh Shilimkar wrote: ARM arch timers stop in low power state and hence can not wakeup CPUs in deeper idle states when used as cloc event devices. Marking these clock event devices with C3_STOP so that during lowpower states, the tick is managed by wakeup capable broadcast timer. Cc: Marc Zyngier marc.zyng...@arm.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Hi Santosh, I already have queued an identical patch from Lorenzo. Thanks for reminder anyway! OK. Thanks for the information Mark. Looks like I missed that one on the list. 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
[PATCH] Add missing modules aliases to get sound working on omap devices
This patch add missing modules aliases to get sound working on omap devices. Tested on Beagleboard xM rev. B. This patch is against 3.5-rc5 vanilla. Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr --- ./sound/soc/omap/omap-pcm.c.orig 2012-07-04 10:30:13.611641186 +0200 +++ ./sound/soc/omap/omap-pcm.c 2012-07-04 10:30:38.894034111 +0200 @@ -441,3 +441,4 @@ module_platform_driver(omap_pcm_driver); MODULE_AUTHOR(Jarkko Nikula jarkko.nik...@bitmer.com); MODULE_DESCRIPTION(OMAP PCM DMA module); MODULE_LICENSE(GPL); +MODULE_ALIAS(platform:omap-pcm-audio); --- ./sound/soc/omap/omap-mcbsp.c.orig 2012-07-04 10:29:14.240066817 +0200 +++ ./sound/soc/omap/omap-mcbsp.c 2012-07-04 12:03:28.020756978 +0200 @@ -820,3 +820,4 @@ module_platform_driver(asoc_mcbsp_driver MODULE_AUTHOR(Jarkko Nikula jarkko.nik...@bitmer.com); MODULE_DESCRIPTION(OMAP I2S SoC Interface); MODULE_LICENSE(GPL); +MODULE_ALIAS(platform:omap-mcbsp-dai);
Re: [PATCH] ARM: architected timers: Mark the clockevent with the C3_STOP feature
On Wed, Jul 04, 2012 at 03:24:33PM +0530, Santosh Shilimkar wrote: ARM arch timers stop in low power state and hence can not wakeup CPUs in deeper idle states when used as cloc event devices. Marking these clock event devices with C3_STOP so that during lowpower states, the tick is managed by wakeup capable broadcast timer. Will tells me that the arch timers don't stop in low power modes, they just can't produce wakeup events. Apparantly the spec says: The system counter must be implemented in an always-on power domain. Use of lower-frequency modes must not affect the implemented accuracy. Are you sure your above description of the problem is correct? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RESEND PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class
On Wed, Jul 04, 2012 at 12:54:54, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120703 06:12]: Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_AM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Thanks applying both. Thanks Tony, Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.5-rc3: PM/DSS broken (was vdd_mpu_iva warnings)
On Wednesday 04 July 2012 11:58 AM, Tomi Valkeinen wrote: On Tue, 2012-07-03 at 16:29 +0530, Archit Taneja wrote: Thanks for testing this out. I was going through Tomi's queue for the 3.6 merge window: git://gitorious.org/linux-omap-dss2/linux.git master There is a commit called: 2b8501d777346ce1d4fe99167e9b3c0e42aae7a8 OMAPDSS: Use PM notifiers for system suspend The commit message mentions the issue you see, and seems to resolve it. Could you give this a try? Tomi is out on vacation, and I don't know why this wasn't intended for the 3.5-rcs, maybe there are still some discussion going on about this? I just missed it due to the pre-vacation hassle, I was so focused on getting the stuff ready for next merge window. With a quick glance to my master branch, the OMAPDSS: Use PM notifiers for system suspend looks like it could go for 3.5-rc, and also OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n. Archit, can you check that both apply fine to mainline, and send them to Florian for 3.5-rc. And make clear they are for him, so that he doesn't think I'll handle them =). Sure, will do. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: architected timers: Mark the clockevent with the C3_STOP feature
On Wed, Jul 4, 2012 at 3:56 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jul 04, 2012 at 03:24:33PM +0530, Santosh Shilimkar wrote: ARM arch timers stop in low power state and hence can not wakeup CPUs in deeper idle states when used as cloc event devices. Marking these clock event devices with C3_STOP so that during lowpower states, the tick is managed by wakeup capable broadcast timer. Will tells me that the arch timers don't stop in low power modes, they just can't produce wakeup events. Apparantly the spec says: The system counter must be implemented in an always-on power domain. Use of lower-frequency modes must not affect the implemented accuracy. Are you sure your above description of the problem is correct? Yes. Will is right. The arch timers don't stop with a real time counter implementation. The issue is they are not wakeup capable hence you need a broad-cast switching which in turn needs C3_STOP. 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: Current state of AM33xx patches
On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote: On Sat, 30 Jun 2012, Daniel Mack wrote: Ok, thanks for the explaining this. For now, I'll add hwmod stubs for the components I need. Hmm. Which drivers are you working on? Vaibhav Hiremath has hwmod data for the AM33xx. There might be some missing integration code to build the devices for the newer IP blocks, though. I would also be interested to know more here. Btw, has anyone yet worked on getting the MDIO/EMAC driver merged? Mainline has: drivers/net/ethernet/ti/davinci_emac.c Not required for AM335X. drivers/net/ethernet/ti/davinci_mdio.c Those might work for you. Few more files, drivers/net/ethernet/ti/cpsw.c drivers/net/ethernet/ti/davinci_cpdma.c Wanted to highlight one point, You still have to add platform device code to get it working. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] omap3: Provide means for changing CSI2 PHY configuration
Hello Sakari, On Wed, 9 May 2012, Sakari Ailus wrote: The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to the actual CSI-2 receivers outside the ISP itself. Allow changing this configuration from the ISP driver. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi just checking on this one. Any update? A few comments: it would be nice to have some kerneldoc for this function. Also it would be nice to use macros rather than the raw bitshifts in this function. And one level of indentation can be saved if you bail out early if the function is not running on a 3630. - 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: [PATCH] omap: hwmod: add support to set dmadisable in hwmod framework
On Wed, 9 May 2012, Kishon Vijay Abraham I wrote:
The DMADISABLE bit is a semi-automatic bit present in sysconfig register
of some modules. When the DMA must perform read/write accesses, the
DMADISABLE bit is cleared by the hardware. But when the DMA must stop for
power
management, software must set the DMADISABLE bit back to 1.
In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
In order for the kernel to start in a clean state, it is
necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
of whether it's been set to 1 in romcode or bootloader).
During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
prevents the system to idle)
DMADISABLE bit is present in usbotgss module of omap5.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Thanks for the detailed comments and the kerneldoc. This one has been
updated to apply and also to resolve some checkpatch warnings. Updated
patch below.
- Paul
From: Kishon Vijay Abraham I kis...@ti.com
Date: Wed, 4 Jul 2012 05:09:21 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod code: add support to set dmadisable in
hwmod framework
The DMADISABLE bit is a semi-automatic bit present in sysconfig register
of some modules. When the DMA must perform read/write accesses, the
DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power
management, software must set the DMADISABLE bit back to 1.
In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
In order for the kernel to start in a clean state, it is
necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
of whether it's been set to 1 in romcode or bootloader).
During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
prevents the system to idle)
DMADISABLE bit is present in usbotgss module of omap5.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
[p...@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 61 +++---
arch/arm/mach-omap2/omap_hwmod_common_data.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |5 +++
3 files changed, 62 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a89214e..98cde62 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -388,6 +388,49 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
}
/**
+ * _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
+ * @oh: struct omap_hwmod *
+ *
+ * The DMADISABLE bit is a semi-automatic bit present in sysconfig register
+ * of some modules. When the DMA must perform read/write accesses, the
+ * DMADISABLE bit is cleared by the hardware. But when the DMA must stop
+ * for power management, software must set the DMADISABLE bit back to 1.
+ *
+ * Set the DMADISABLE bit in @v for hwmod @oh. Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int _set_dmadisable(struct omap_hwmod *oh)
+{
+ u32 v;
+ u32 dmadisable_mask;
+
+ if (!oh-class-sysc ||
+ !(oh-class-sysc-sysc_flags SYSC_HAS_DMADISABLE))
+ return -EINVAL;
+
+ if (!oh-class-sysc-sysc_fields) {
+ WARN(1, omap_hwmod: %s: offset struct for sysconfig not
provided in class\n, oh-name);
+ return -EINVAL;
+ }
+
+ /* clocks must be on for this operation */
+ if (oh-_state != _HWMOD_STATE_ENABLED) {
+ pr_warn(omap_hwmod: %s: dma can be disabled only from enabled
state\n, oh-name);
+ return -EINVAL;
+ }
+
+ pr_debug(omap_hwmod: %s: setting DMADISABLE\n, oh-name);
+
+ v = oh-_sysc_cache;
+ dmadisable_mask =
+ (0x1 oh-class-sysc-sysc_fields-dmadisable_shift);
+ v |= dmadisable_mask;
+ _write_sysconfig(v, oh);
+
+ return 0;
+}
+
+/**
* _set_module_autoidle: set the OCP_SYSCONFIG AUTOIDLE field in @v
* @oh: struct omap_hwmod *
* @autoidle: desired AUTOIDLE bitfield value (0 or 1)
@@ -1698,11 +1741,17 @@ dis_opt_clks:
* therefore have no OCP header registers to access. Others (like the
* IVA) have idiosyncratic reset sequences. So for these relatively
* rare cases, custom reset code can be supplied in the struct
- * omap_hwmod_class .reset function pointer. Passes along the return
- * value from either _ocp_softreset() or the custom
Re: Current state of AM33xx patches
On 04.07.2012 12:50, Hiremath, Vaibhav wrote: On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote: On Sat, 30 Jun 2012, Daniel Mack wrote: Ok, thanks for the explaining this. For now, I'll add hwmod stubs for the components I need. Hmm. Which drivers are you working on? Vaibhav Hiremath has hwmod data for the AM33xx. There might be some missing integration code to build the devices for the newer IP blocks, though. I would also be interested to know more here. Btw, has anyone yet worked on getting the MDIO/EMAC driver merged? Mainline has: drivers/net/ethernet/ti/davinci_emac.c Not required for AM335X. drivers/net/ethernet/ti/davinci_mdio.c Those might work for you. Few more files, drivers/net/ethernet/ti/cpsw.c drivers/net/ethernet/ti/davinci_cpdma.c Wanted to highlight one point, You still have to add platform device code to get it working. Exactly. And a hwmod binding for DT. Do you have patches for that? Daniel -- 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: how to specify dma_mask and coherent_dma_mask in hwmod
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Wednesday, July 04, 2012 3:12 PM To: N, Mugunthan V Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: how to specify dma_mask and coherent_dma_mask in hwmod On Thu, Jun 07, 2012 at 04:22:17PM +, N, Mugunthan V wrote: While converting platform device registry to Hwmod for CPSW Ethernet driver which is present in AM335X (OMAP2+), I am not finding a way to specify dma_mask and coherent_dma_mask. Is there a way to specify dma_mask and coherent_dma_mask in hwmod? Just remember that we're moving stuff to DMA engine, and that means the sDMA device has DMA masks, but none of the peripherals which make use of sDMA should have DMA masks set. The reason for this is because the device responsible for accessing memory is sDMA, not the peripheral device, and therefore any memory properties for DMA should come from the sDMA device, not the peripheral device. I agree that properties of DMA should come from sDMA device. In my case (CPSW Ethernet) has a peripheral DMA (davinci_cpdma) which takes care of transferring packet from memory to Ethernet IP and vice versa. For allocating DMA memory space for davinci_cpdma, dma_alloc_coherent is used which requires dma_masks to be specified for the device. To pass the dma_masks to the device following ways can be followed. 1. Extend omap_device_build arguments to hold dma_mask and coherent_dma_mask which will affect all other devices which uses omap_device_build api. 2. Hardcode the dma_mask and coherent_dma_mask in omap_device_build with 0x which can harm other devices 3. Specify the dma_mask and coherent_dma_mask after creating the device as done in musb device. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/a rm/mach-omap2/usb-musb.c;h=c4a576856661014ea3bec9acc70f80e32d62c33b;hb=HEAD Regards, Mugunthan V N -- 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/3] ARM: OMAP2/3: DSS HWMOD fixes
Hi Tomi On Wed, 27 Jun 2012, Paul Walmsley wrote: On Thu, 10 May 2012, Tomi Valkeinen wrote: These patches fix DSS hwmod data related to sysc flags. I haven't seen any problem produced by these missing bits, but by looking at the TRM it's clear that they should be defined. However, applying these will cause additional warnings to show during boot: omap_hwmod: dss_dispc: softreset failed (waited 1 usec) omap_hwmod: dss_rfbi: softreset failed (waited 1 usec) Most likely the softreset fails even now, but as there's no check to verify it, no warnings are visible. I think the reason for the failing softreset is the same problem as we have on OMAP4: dss_core hwmod should be enabled before other dss hwmods can be enabled (and reset). Thanks, queued for 3.6. Not sure what to do about the softreset issues at the moment, due to competing priorities. But for sure the data should match the hardware. I've dropped these for 3.6 since they cause a PM regression during a system suspend test: [ 39.721282] Powerdomain (dss_pwrdm) didn't enter target state 1 Probably before we can pull these in, we need to figure out what's going on there. - 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
[PATCH 0/2] OMAPDSS: PM runtime fixes for 3.5-rc
Hi Florian, These are 2 fixes which Tomi had intended to push for the coming rcs. He is currently on vacation and asked me to post the patches on his behalf. The first patch ensures that system suspend doesn't break on OMAP if DSS is enabled. The second patch prevents some warning backtraces when the kernel is not built with PM runtime. Could you please queue these for the upcoming rc? Thanks, Archit Tomi Valkeinen (2): OMAPDSS: Use PM notifiers for system suspend OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n drivers/video/omap2/dss/core.c | 45 +-- drivers/video/omap2/dss/dispc.c |2 +- drivers/video/omap2/dss/dsi.c |2 +- drivers/video/omap2/dss/dss.c |2 +- drivers/video/omap2/dss/hdmi.c |2 +- drivers/video/omap2/dss/rfbi.c |2 +- drivers/video/omap2/dss/venc.c |2 +- 7 files changed, 35 insertions(+), 22 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAPDSS: Use PM notifiers for system suspend
From: Tomi Valkeinen tomi.valkei...@ti.com
The current way how omapdss handles system suspend and resume is that
omapdss device (a platform device, which is not part of the device
hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
the suspend and resume callbacks from platform_driver to handle system
suspend. It does this by disabling all enabled panels on suspend, and
resuming the previously disabled panels on resume.
This presents a few problems.
One is that as omapdss device is not related to the panel devices or the
DSS HW devices, there's no ordering in the suspend process. This means
that suspend could be first ran for DSS HW devices and panels, and only
then for omapdss device. Currently this is not a problem, as DSS HW
devices and panels do not handle suspend.
Another, more pressing problem, is that when suspending or resuming, the
runtime PM functions return -EACCES as runtime PM is disabled during
system suspend. This causes the driver to print warnings, and operations
to fail as they think that they failed to bring up the HW.
This patch changes the omapdss suspend handling to use PM notifiers,
which are called before suspend and after resume. This way we have a
normally functioning system when we are suspending and resuming the
panels.
This patch, I believe, creates a problem that somebody could enable or
disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
similarly the other way around in resume. I choose to ignore the problem
for now, as it sounds rather unlikely, and if it happens, it's not
fatal.
In the long run the system suspend handling of omapdss and panels should
be thought out properly. The current approach feels rather hacky.
Perhaps the panel drivers should handle system suspend, or the users of
omapdss (omapfb, omapdrm) should handle system suspend.
Note that after this patch we could probably revert
0eaf9f52e94f756147dbfe1faf1f77a02378dbf9 (OMAPDSS: use sync versions of
pm_runtime_put). But as I said, this patch may be temporary, so let's
leave the sync version still in place.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Jassi Brar jaswinder.si...@linaro.org
Tested-by: Jassi Brar jaswinder.si...@linaro.org
Tested-by: Joe Woodward j...@terrafix.co.uk
---
drivers/video/omap2/dss/core.c | 45 ++--
1 file changed, 29 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5066eee..c35a248 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -32,6 +32,7 @@
#include linux/io.h
#include linux/device.h
#include linux/regulator/consumer.h
+#include linux/suspend.h
#include video/omapdss.h
@@ -201,6 +202,30 @@ int dss_debugfs_create_file(const char *name, void
(*write)(struct seq_file *))
#endif /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
+static int omap_dss_pm_notif(struct notifier_block *b, unsigned long v, void
*d)
+{
+ DSSDBG(pm notif %lu\n, v);
+
+ switch (v)
+ {
+ case PM_SUSPEND_PREPARE:
+ DSSDBG(suspending displays\n);
+ return dss_suspend_all_devices();
+
+ case PM_POST_SUSPEND:
+ DSSDBG(resuming displays\n);
+ return dss_resume_all_devices();
+
+ default:
+ return 0;
+ }
+}
+
+static struct notifier_block omap_dss_pm_notif_block =
+{
+ .notifier_call = omap_dss_pm_notif,
+};
+
static int __init omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
@@ -224,6 +249,8 @@ static int __init omap_dss_probe(struct platform_device
*pdev)
else if (pdata-default_device)
core.default_display_name = pdata-default_device-name;
+ register_pm_notifier(omap_dss_pm_notif_block);
+
return 0;
err_debugfs:
@@ -233,6 +260,8 @@ err_debugfs:
static int omap_dss_remove(struct platform_device *pdev)
{
+ unregister_pm_notifier(omap_dss_pm_notif_block);
+
dss_uninitialize_debugfs();
dss_uninit_overlays(pdev);
@@ -247,25 +276,9 @@ static void omap_dss_shutdown(struct platform_device *pdev)
dss_disable_all_devices();
}
-static int omap_dss_suspend(struct platform_device *pdev, pm_message_t state)
-{
- DSSDBG(suspend %d\n, state.event);
-
- return dss_suspend_all_devices();
-}
-
-static int omap_dss_resume(struct platform_device *pdev)
-{
- DSSDBG(resume\n);
-
- return dss_resume_all_devices();
-}
-
static struct platform_driver omap_dss_driver = {
.remove = omap_dss_remove,
.shutdown = omap_dss_shutdown,
- .suspend= omap_dss_suspend,
- .resume = omap_dss_resume,
.driver = {
.name = omapdss,
.owner = THIS_MODULE,
--
1.7.9.5
--
To unsubscribe from this list: send the line
[PATCH 2/2] OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n
From: Tomi Valkeinen tomi.valkei...@ti.com If runtime PM is not enabled in the kernel config, pm_runtime_get_sync() will always return 1 and pm_runtime_put_sync() will always return -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to print a warning. One option would be to ignore errors returned by pm_runtime_put_sync() totally, as they only say that the call was unable to put the hardware into suspend mode. However, I chose to ignore the returned -ENOSYS explicitly, and print a warning for other errors, as I think we should get notified if the HW failed to go to suspend properly. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Jassi Brar jaswinder.si...@linaro.org Cc: Grazvydas Ignotas nota...@gmail.com --- drivers/video/omap2/dss/dispc.c |2 +- drivers/video/omap2/dss/dsi.c |2 +- drivers/video/omap2/dss/dss.c |2 +- drivers/video/omap2/dss/hdmi.c |2 +- drivers/video/omap2/dss/rfbi.c |2 +- drivers/video/omap2/dss/venc.c |2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index 4749ac3..397d4ee 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -384,7 +384,7 @@ void dispc_runtime_put(void) DSSDBG(dispc_runtime_put\n); r = pm_runtime_put_sync(dispc.pdev-dev); - WARN_ON(r 0); + WARN_ON(r 0 r != -ENOSYS); } static inline bool dispc_mgr_is_lcd(enum omap_channel channel) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index ca8382d..14ce8cc 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -1075,7 +1075,7 @@ void dsi_runtime_put(struct platform_device *dsidev) DSSDBG(dsi_runtime_put\n); r = pm_runtime_put_sync(dsi-pdev-dev); - WARN_ON(r 0); + WARN_ON(r 0 r != -ENOSYS); } /* source clock for DSI PLL. this could also be PCLKFREE */ diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c index 7706323..d2b5719 100644 --- a/drivers/video/omap2/dss/dss.c +++ b/drivers/video/omap2/dss/dss.c @@ -731,7 +731,7 @@ static void dss_runtime_put(void) DSSDBG(dss_runtime_put\n); r = pm_runtime_put_sync(dss.pdev-dev); - WARN_ON(r 0 r != -EBUSY); + WARN_ON(r 0 r != -ENOSYS r != -EBUSY); } /* DEBUGFS */ diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 8195c71..26a2430 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -138,7 +138,7 @@ static void hdmi_runtime_put(void) DSSDBG(hdmi_runtime_put\n); r = pm_runtime_put_sync(hdmi.pdev-dev); - WARN_ON(r 0); + WARN_ON(r 0 r != -ENOSYS); } static int __init hdmi_init_display(struct omap_dss_device *dssdev) diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c index 3d8c206..7985fa1 100644 --- a/drivers/video/omap2/dss/rfbi.c +++ b/drivers/video/omap2/dss/rfbi.c @@ -141,7 +141,7 @@ static void rfbi_runtime_put(void) DSSDBG(rfbi_runtime_put\n); r = pm_runtime_put_sync(rfbi.pdev-dev); - WARN_ON(r 0); + WARN_ON(r 0 r != -ENOSYS); } void rfbi_bus_lock(void) diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c index 2b89739..3907c8b 100644 --- a/drivers/video/omap2/dss/venc.c +++ b/drivers/video/omap2/dss/venc.c @@ -402,7 +402,7 @@ static void venc_runtime_put(void) DSSDBG(venc_runtime_put\n); r = pm_runtime_put_sync(venc.pdev-dev); - WARN_ON(r 0); + WARN_ON(r 0 r != -ENOSYS); } static const struct venc_config *venc_timings_to_config( -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm/dts: am33xx wdt node
Add am33xx wdt node.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
This was tested on AM335X EVM. This depends on,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69424.html
Regards
Afzal
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f46e353..08b2a5b 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -185,5 +185,10 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ wdt2: wdt@44e35000 {
+ compatible = ti,omap3-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
--
1.7.11.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On Wed, 4 Jul 2012, Paul Walmsley wrote: So the updated patch below uses a clockdomain data flag for this instead. Here's a version that's a little cleaner. No functional changes. - Paul From: Paul Walmsley p...@pwsan.com Date: Wed, 4 Jul 2012 05:22:53 -0600 Subject: [PATCH] ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c (ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database) broke CORE idle on OMAP3. This prevents device low power states. The root cause is that the 32K sync timer IP block does not support smart-idle mode[1], and so the hwmod code keeps the IP block in no-idle mode while it is active. This in turn prevents the WKUP clockdomain from transitioning to idle. There is a hardcoded sleep dependency that prevents the CORE_L3 and CORE_CM clockdomains from transitioning to idle when the WKUP clockdomain is active[2], so the chip cannot enter any device low power states. It turns out that there is no need to take the 32k sync timer out of idle. The IP block itself probably does not have any native idle handling at all, due to its simplicity. Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-force-idle mode, even while we continue to access it. This workaround is implemented by defining a new clockdomain flag, CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is guaranteed to be active whenever the MPU is inactive. If an IP block's main functional clock exists inside this clockdomain, and the IP block does not support smart-idle modes, then the hwmod code will place the IP block into target force-idle mode even when enabled. The WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx, no OCP header existed on the 32k sync timer.) Other clockdomains also should be marked with this flag, but those changes are deferred until a later merge window, to create a minimal fix. Another theoretically clean fix for this problem would be to implement PM runtime-based control for 32k sync timer accesses. These PM runtime calls would need to located in a custom clocksource, since the 32k sync timer is currently used as an MMIO clocksource. But in practice, there would be little benefit to doing so; and there would be some cost, due to the addition of unnecessary lines of code and the additional CPU overhead of the PM runtime and hwmod code - unnecessary in this case. Another possible fix would have been to modify the pm34xx.c code to force the IP block idle before entering WFI. But this would not have been an acceptable approach: we are trying to remove this type of centralized IP block idle control from the PM code. This patch is a collaboration between Kevin Hilman khil...@ti.com and Paul Walmsley p...@pwsan.com. Thanks to Vaibhav Hiremath hvaib...@ti.com for providing comments on an earlier version of this patch. Thanks to Tero Kristo t-kri...@ti.com for identifying a bug in an earlier version of this patch. Thanks to Benoît Cousson b-cous...@ti.com for identifying some bugs in an earlier version of this patch and for implementation comments. References: 1. Table 16-96 REG_32KSYNCNT_SYSCONFIG of the OMAP34xx TRM Rev. ZU (SWPU223U), available from: http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip 2. Table 4-72 Sleep Dependencies of the OMAP34xx TRM Rev. ZU (SWPU223U) 3. ibid. Cc: Tony Lindgren t...@atomide.com Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Benoît Cousson b-cous...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/clockdomain.h|4 +++ arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |1 + arch/arm/mach-omap2/clockdomains44xx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod.c | 32 -- 4 files changed, 30 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h index f7b5860..6227e95 100644 --- a/arch/arm/mach-omap2/clockdomain.h +++ b/arch/arm/mach-omap2/clockdomain.h @@ -31,12 +31,16 @@ * * CLKDM_NO_AUTODEPS: Prevent autodeps from being added/removed from this * clockdomain. (Currently, this applies to OMAP3 clockdomains only.) + * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is + * active whenever the MPU is active. True for interconnects and + * the WKUP clockdomains. */ #define CLKDM_CAN_FORCE_SLEEP (1 0) #define CLKDM_CAN_FORCE_WAKEUP (1 1) #define CLKDM_CAN_ENABLE_AUTO (1 2) #define CLKDM_CAN_DISABLE_AUTO (1 3) #define CLKDM_NO_AUTODEPS (1 4) +#define
Re: [PATCH] OMAP4: Clock: Correct OTG clock to use otg_60m_gfclk.
Hi Paul, On 07/04/2012 11:10 AM, Paul Walmsley wrote: On Mon, 2 Jul 2012, Benoit Cousson wrote: Unfortunately the clock fmwk cannot handle module as a clock node. Hmm. We have to have similar support in the clockfw for the CLKDIV32K clock for AM33xx. That uses the modulemode bits to enable and disable the clock. Or does this require something more complicated? I don't think so, in that case, that should probably be enough. But playing with the modulemode in the clock frmwk still looks like a hack to me. Ideally it should be represented by a hwmod instead, but then it will not fit in the clock fmwk. That being said, using an IP (internal or not) as a source clock should be supported. That will allow us to handle the power dependency we have with Phoenix audio that is the source clock of the McPDM. Regards, Benoit -- 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: how to specify dma_mask and coherent_dma_mask in hwmod
On Wed, Jul 04, 2012 at 11:47:35AM +, N, Mugunthan V wrote: -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Wednesday, July 04, 2012 3:12 PM To: N, Mugunthan V Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: how to specify dma_mask and coherent_dma_mask in hwmod On Thu, Jun 07, 2012 at 04:22:17PM +, N, Mugunthan V wrote: While converting platform device registry to Hwmod for CPSW Ethernet driver which is present in AM335X (OMAP2+), I am not finding a way to specify dma_mask and coherent_dma_mask. Is there a way to specify dma_mask and coherent_dma_mask in hwmod? Just remember that we're moving stuff to DMA engine, and that means the sDMA device has DMA masks, but none of the peripherals which make use of sDMA should have DMA masks set. The reason for this is because the device responsible for accessing memory is sDMA, not the peripheral device, and therefore any memory properties for DMA should come from the sDMA device, not the peripheral device. I agree that properties of DMA should come from sDMA device. In my case (CPSW Ethernet) has a peripheral DMA (davinci_cpdma) which takes care of transferring packet from memory to Ethernet IP and vice versa. Right, so you have two devices here. You have the Ethernet device, and you have the cpdma device. The cpdma device is the device actually performing the memory accesses on behalf of the Ethernet device. For allocating DMA memory space for davinci_cpdma, dma_alloc_coherent is used which requires dma_masks to be specified for the device. So, memory which you allocate for DMA purposes should use the struct device associated with the cpdma device, not the struct device associated with the Ethernet device. That becomes possible when DMA implementations are converted to use the DMA engine API, and with proper channel virtualization, device drivers can retain their virtual channel handle (and therefore access to the DMA engine struct device) indefinitely. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Munegowda, Keshava keshava_mgo...@ti.com writes: On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote: Felipe, Keshava, Kevin Hilman khil...@ti.com writes: Felipe Balbi ba...@ti.com writes: [...] Keshava is reverting a fix for a HW errata. I can't accept it as it will cause regressions. Granted, regression by regression, there's no change, but I simply can't knowingly cause a regression to the driver just to have PM working. We need a real fix for this issue. Sure, as long as there is a fix in this -rc cycle. This driver intoduced changes in v3.5 that break PM for the whole SoC (by preventing CORE retention.) These changes were clearly not tested with PM. If you cannot fix this during the -rc cycle, then you need to revert the driver PM changes that broke PM for the *whole* SoC. What's the status of this regression? This is still broken in v3.5-rc and is preventing CORE retention for the *whole* SoC. Please fix this, either with a proper fix, or a revert for 3.5-rc. The proper fix for this is implement ion of ehci remote wakeup through I/O chain handler; it takes time. As Felipe also mentioned, This patch is OK for now. Sorry, Felipe still insist not to revert this patch, but to change this patch requires quite more changes in the usbhs core and we need to see the how the hub control changes need to be brought in to usbhs core. so , reverting is the best solution to time being. Its observed that ehci was enabled after linux kernal version 3.3 ; before that even though driver was there the ehci deriver was disabled by defaults; and it is expected the people who want to use NFS then can enable it explicitly. so, the solution is 1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and suspend/resume crash Or, use the patches from Russ Dill where were more targetted fixes. Either way, I'm OK with that. 2. Disable the ehci driver to make the pm work in idle case ; This configuration should exist till the ehci remote wakeup implementation completes. Yes. Please disabled it by default. Until PM in this driver can work without breaking PM for the whole SoC, it should remain disabled. Please queue up all of these fixes ASAP for the v3.5 Kevin -- 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] remoteproc: adopt the driver core's alloc/add/del/put naming
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 li...@arm.linux.org.uk.
Cc: Russell King li...@arm.linux.org.uk
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Fernando Guzman Lugo fernando.l...@ti.com
Cc: Sjur Brændeland sjur.brandel...@stericsson.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
Documentation/remoteproc.txt | 18 +-
drivers/remoteproc/omap_remoteproc.c | 8
drivers/remoteproc/remoteproc_core.c | 32
include/linux/remoteproc.h | 6 +++---
4 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt
index f33c3bb..23a09b8 100644
--- a/Documentation/remoteproc.txt
+++ b/Documentation/remoteproc.txt
@@ -90,21 +90,21 @@ int dummy_rproc_example(struct rproc *my_rproc)
This function should be used by rproc implementations during
initialization of the remote processor.
After creating an rproc handle using this function, and when ready,
- implementations should then call rproc_register() to complete
+ implementations should then call rproc_add() to complete
the registration of the remote processor.
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
- yet. Instead, when you need to unroll rproc_alloc(), use rproc_free().
+ yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
- void rproc_free(struct rproc *rproc)
+ void rproc_put(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
This function essentially unrolls rproc_alloc(), by decrementing the
rproc's refcount. It doesn't directly free rproc; that would happen
only if there are no other references to rproc and its refcount now
dropped to zero.
- int rproc_register(struct rproc *rproc)
+ int rproc_add(struct rproc *rproc)
- Register @rproc with the remoteproc framework, after it has been
allocated with rproc_alloc().
This is called by the platform-specific rproc implementation, whenever
@@ -117,15 +117,15 @@ int dummy_rproc_example(struct rproc *my_rproc)
of registering this remote processor, additional virtio drivers might get
probed.
- int rproc_unregister(struct rproc *rproc)
-- Unroll rproc_register().
+ int rproc_del(struct rproc *rproc)
+- Unroll rproc_add().
This function should be called when the platform specific rproc
implementation decides to remove the rproc device. it should
- _only_ be called if a previous invocation of rproc_register()
+ _only_ be called if a previous invocation of rproc_add()
has completed successfully.
- After rproc_unregister() returns, @rproc is still valid, and its
- last refcount should be decremented by calling rproc_free().
+ After rproc_del() returns, @rproc is still valid, and its
+ last refcount should be decremented by calling rproc_put().
Returns 0 on success and -EINVAL if @rproc isn't valid.
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 0f1afc9..a1f7ac1 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -199,14 +199,14 @@ static int __devinit omap_rproc_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, rproc);
- ret = rproc_register(rproc);
+ ret = rproc_add(rproc);
if (ret)
goto free_rproc;
return 0;
free_rproc:
- rproc_free(rproc);
+ rproc_put(rproc);
return ret;
}
@@ -214,8 +214,8 @@ static int __devexit omap_rproc_remove(struct
platform_device *pdev)
{
struct rproc *rproc = platform_get_drvdata(pdev);
- rproc_unregister(rproc);
- rproc_free(rproc);
+ rproc_del(rproc);
+ rproc_put(rproc);
return 0;
}
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index cbe4f7a..c0a701d 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1102,7 +1102,7 @@ static void rproc_fw_config_virtio(const struct firmware
*fw, void *context)
out:
if (fw)
release_firmware(fw);
- /* allow rproc_unregister() contexts, if any, to proceed */
+ /* allow rproc_del() contexts, if any, to proceed */
complete_all(rproc-firmware_loading_complete);
}
@@ -1251,7 +1251,7 @@ out:
EXPORT_SYMBOL(rproc_shutdown);
/**
- * rproc_register() - register a remote processor
+ * rproc_add() - register a remote processor
* @rproc: the remote processor handle to register
*
* Registers
RE: [PATCH] arm/dts: am33xx wdt node
+ Grant and device tree, watchdog lists
On Wed, Jul 04, 2012 at 18:00:37, Mohammed, Afzal wrote:
Add am33xx wdt node.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
This was tested on AM335X EVM. This depends on,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69424.html
Regards
Afzal
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f46e353..08b2a5b 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -185,5 +185,10 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ wdt2: wdt@44e35000 {
+ compatible = ti,omap3-wdt;
+ ti,hwmods = wd_timer2;
+ };
};
};
--
1.7.11.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.5-rc3: PM/DSS broken (was vdd_mpu_iva warnings)
Joe Woodward j...@terrafix.co.uk writes: ...snip... # Thanks for testing this out. I was going through Tomi's queue for the 3.6 merge window: git://gitorious.org/linux-omap-dss2/linux.git master There is a commit called: 2b8501d777346ce1d4fe99167e9b3c0e42aae7a8 OMAPDSS: Use PM notifiers for system suspend The commit message mentions the issue you see, and seems to resolve it. Could you give this a try? Tomi is out on vacation, and I don't know why this wasn't intended for the 3.5-rcs, maybe there are still some discussion going on about this? Thanks, this did remove the DSS warnings when suspending. Is there any chance this patch will make 3.5, or is it far too late now? However, core still fails to power down: # echo mem /sys/power/state [ 64.905975] PM: Syncing filesystems ... done. [ 64.926879] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 64.952697] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 64.983947] Suspending console(s) (use no_console_suspend to debug) [ 65.115112] PM: suspend of devices complete after 121.215 msecs [ 65.117797] PM: late suspend of devices complete after 2.655 msecs [ 65.122314] PM: noirq suspend of devices complete after 4.486 msecs [ 65.122344] Disabling non-boot CPUs ... [ 66.095733] Powerdomain (core_pwrdm) didn't enter target state 1 [ 66.095733] Could not enter target state in pm_suspend [ 66.098236] PM: noirq resume of devices complete after 2.319 msecs [ 66.101409] PM: early resume of devices complete after 1.770 msecs [ 66.471008] mmc1: error -110 during resume (card was removed?) [ 66.516784] PM: resume of devices complete after 415.252 msecs [ 66.580841] Restarting tasks ... done. sh: write error: Operation not permitted I'm guessing this is a question for Kevin, any idea how to debug this? Already debugged and fixed. The exact solution is still under discussion, but while waiting for the right fix, you can use this patch and you should see CORE hitting retention: http://marc.info/?l=linux-omapm=13453229888w=2 Also, why is it now saing sh: write error: Operation not permitted after waking, this never happened with 3.4? I have seen this here and there and have never looked into why that is happening. Clearly the write actually worked because the suspend happened, so I'm not sure what's going on there. Kevin -- 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
[GIT PULL] ARM: OMAP2+: more fixes intended for 3.5-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-3.5rc for you to fetch changes up to d7a0b5133f6b1d53d693b9b9873e64e3c8f0db0e: ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4 (2012-07-04 06:55:29 -0600) - A few more OMAP fixes for 3.5-rc. These fix some bugs with power management and McBSP. - object size (delta in bytes from test_v3.5-rc5 (6887a4131da3adaab011613776d865f4bcfb5678)): textdata bss total kernel 0 0 0 0 2430_testconfig/vmlinux 0 0 0 0 5912osk_testconfig/vmlinux 0-800 0-800 am33xx_testconfig/vmlinux 0 0 0 0 n800_b_testconfig/vmlinux 0 0 0 0 n800_multi_omap2xxx/vmlinux 0 0 0 0 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux 0-736 0-736 omap2_4_testconfig/vmlinux 0-736 0-736 omap2plus_defconfig/vmlinux 0-736 0-736 omap2plus_no_pm/vmlinux 0-736 0-736 omap3_4_testconfig/vmlinux 0 0 0 0 omap3_testconfig/vmlinux 0-736 0-736 omap4_testconfig/vmlinux Test logs are here: http://www.pwsan.com/omap/testlogs/omap_fixes_b_3.5rc/20120704065841/ 3530ES3 Beagle doesn't wake up from dynamic idle. CORE powerdomain on 3530ES3 Beagle and 37xx EVM doesn't enter low-power states. AM35xx boards have the usual boot-time warnings. All of these issues existed on v3.5-rc5. object size (delta in bytes from test_v3.5-rc5 (6887a4131da3adaab011613776d865f4bcfb5678)): textdata bss total kernel 0 0 0 0 2430_testconfig/vmlinux 0 0 0 0 5912osk_testconfig/vmlinux 0-800 0-800 am33xx_testconfig/vmlinux 0 0 0 0 n800_b_testconfig/vmlinux 0 0 0 0 n800_multi_omap2xxx/vmlinux 0 0 0 0 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux 0-736 0-736 omap2_4_testconfig/vmlinux 0-736 0-736 omap2plus_defconfig/vmlinux 0-736 0-736 omap2plus_no_pm/vmlinux 0-736 0-736 omap3_4_testconfig/vmlinux 0 0 0 0 omap3_testconfig/vmlinux 0-736 0-736 omap4_testconfig/vmlinux Benoit Cousson (1): ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4 Paul Walmsley (1): ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and aess IP blocks arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP9E4TAAoJEMePsQ0LvSpLtrMP/1oQH3zcKGbWRZOZto0RuK4O MbBFlnkJXXSlcNMhW5KNhQzROLrSltA7hv8Y4eVtpCDKYjdvpWGCdfuEn6H3mrYV Dhq8Uk7oB46PX95s76coQOPnegocrAJmHc+stokaVB5KxwqxC6k/C/A9fAAuG3Uf aR2+Rfv80AW66ZjgrCYbsMFrXUrzXPTIvEXNtmPrO+KXa10rthcVFUmW8OKHj9Kg p97pTfEK9Xtmat6m6E57yE3qao3osp/FPtpAhxzc+xbs4BlArhrxPfru2KJwgquu gzmwsE8xeVJYOz3+9Fpe7G7XZ1Lwt6+L8X0HrWXBC6R9dbeu54GwmLuflTNbR6Kd BtZw47rYFQSqyCqtpr2bJX61tOe/jRCoo17ANkMUKroz1MdnV9Q/QTauuphrLwPr DSFkWPkwGLtt8FI1pH9HvjWxVpcVAouJOdTHwysKx35J5gXLw2pC9Cmu1GTqEVav aZIZdcaoLkgJ7Y2m0UouUEAXXWAN8pJ0yOlHEwXJquPkYTmd1pJFFJI3EbxRZbb6 rix2Nx/J+560orfDl1nuLGGMPU/2iMb0H9eLDhn+zdnQTuneklen8bNfTr2DEev3 A4urjs9iY8fRQmzB29A9qjIL+NnMTS8ofHkrhJLCftsbWL50shDHxAuq+geWhqgR PGrKH29yL9HtGiY2hGYO =KKTu -END PGP SIGNATURE- -- 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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Paul Walmsley p...@pwsan.com writes: On Wed, 4 Jul 2012, Paul Walmsley wrote: So the updated patch below uses a clockdomain data flag for this instead. Here's a version that's a little cleaner. No functional changes. - Paul From: Paul Walmsley p...@pwsan.com Date: Wed, 4 Jul 2012 05:22:53 -0600 Subject: [PATCH] ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c (ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database) broke CORE idle on OMAP3. This prevents device low power states. The root cause is that the 32K sync timer IP block does not support smart-idle mode[1], and so the hwmod code keeps the IP block in no-idle mode while it is active. This in turn prevents the WKUP clockdomain from transitioning to idle. There is a hardcoded sleep dependency that prevents the CORE_L3 and CORE_CM clockdomains from transitioning to idle when the WKUP clockdomain is active[2], so the chip cannot enter any device low power states. It turns out that there is no need to take the 32k sync timer out of idle. The IP block itself probably does not have any native idle handling at all, due to its simplicity. Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-force-idle mode, even while we continue to access it. This workaround is implemented by defining a new clockdomain flag, CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is guaranteed to be active whenever the MPU is inactive. If an IP block's main functional clock exists inside this clockdomain, and the IP block does not support smart-idle modes, then the hwmod code will place the IP block into target force-idle mode even when enabled. The WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx, no OCP header existed on the 32k sync timer.) Other clockdomains also should be marked with this flag, but those changes are deferred until a later merge window, to create a minimal fix. Another theoretically clean fix for this problem would be to implement PM runtime-based control for 32k sync timer accesses. These PM runtime calls would need to located in a custom clocksource, since the 32k sync timer is currently used as an MMIO clocksource. But in practice, there would be little benefit to doing so; and there would be some cost, due to the addition of unnecessary lines of code and the additional CPU overhead of the PM runtime and hwmod code - unnecessary in this case. Another possible fix would have been to modify the pm34xx.c code to force the IP block idle before entering WFI. But this would not have been an acceptable approach: we are trying to remove this type of centralized IP block idle control from the PM code. This patch is a collaboration between Kevin Hilman khil...@ti.com and Paul Walmsley p...@pwsan.com. Thanks to Vaibhav Hiremath hvaib...@ti.com for providing comments on an earlier version of this patch. Thanks to Tero Kristo t-kri...@ti.com for identifying a bug in an earlier version of this patch. Thanks to Benoît Cousson b-cous...@ti.com for identifying some bugs in an earlier version of this patch and for implementation comments. References: 1. Table 16-96 REG_32KSYNCNT_SYSCONFIG of the OMAP34xx TRM Rev. ZU (SWPU223U), available from: http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip 2. Table 4-72 Sleep Dependencies of the OMAP34xx TRM Rev. ZU (SWPU223U) 3. ibid. Cc: Tony Lindgren t...@atomide.com Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Benoît Cousson b-cous...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com Tested-by: Kevin Hilman khil...@ti.com I confirm this version is now allowing CORE to hit retention during suspend. Benoit, I hope this is OK with you. We need a fix for this in v3.5 since this is last core bug preventing CORE retention in v3.5. Kevin -- 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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On Wed, 4 Jul 2012, Kevin Hilman wrote: Tested-by: Kevin Hilman khil...@ti.com I confirm this version is now allowing CORE to hit retention during suspend. Thanks, want me to add your S-o-b also? - 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: [PATCH] omap: hwmod: add support to set dmadisable in hwmod framework
Hi, On Wed, Jul 4, 2012 at 4:46 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 9 May 2012, Kishon Vijay Abraham I wrote: The DMADISABLE bit is a semi-automatic bit present in sysconfig register of some modules. When the DMA must perform read/write accesses, the DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power management, software must set the DMADISABLE bit back to 1. In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the DMADISABLE bit (but the romcode/bootloader might not set it back to 1). In order for the kernel to start in a clean state, it is necessary for the kernel to set DMADISABLE bit back to 1 (irrespective of whether it's been set to 1 in romcode or bootloader). During _reset of the (hwmod)device, the DMADISABLE bit is set so that it does not prevent idling of the system. (NOTE: having DMADISABLE to 0, prevents the system to idle) DMADISABLE bit is present in usbotgss module of omap5. Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Thanks for the detailed comments and the kerneldoc. This one has been updated to apply and also to resolve some checkpatch warnings. Updated patch below. Thanks :-) -Kishon -- 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/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi
On Thu, 28 Jun 2012, R, Sricharan wrote:
Ping..
Since the prcm.c cleanup series isn't ready yet, I've queued this modified
version of your patch.
Once the prcm.c cleanup series is ready, hopefully in the 3.7 time frame,
we'll be able to get rid of all of these nasty stubs.
- Paul
From: R Sricharan r.sricha...@ti.com
Date: Thu, 10 May 2012 22:36:53 +0530
Subject: [PATCH] ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions
to prcm.c file and make them __weak
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.
This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: R Sricharan r.sricha...@ti.com
[p...@pwsan.com: unsplit quoted strings; moved PRM functions to
mach-omap2/prm_common.c; resolved sparse warnings]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/cminst44xx.h | 25 --
arch/arm/mach-omap2/prcm.c | 23 +
arch/arm/mach-omap2/prm2xxx_3xxx.h | 65
arch/arm/mach-omap2/prm_common.c | 62 ++
4 files changed, 85 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index a018a73..d69fdef 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -16,38 +16,13 @@ extern void omap4_cminst_clkdm_enable_hwsup(u8 part, s16
inst, u16 cdoffs);
extern void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_sleep(u8 part, s16 inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs);
-
extern int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs, u16
clkctrl_offs);
-
-# ifdef CONFIG_ARCH_OMAP4
extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
-
extern void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
extern void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
-
-# else
-
-static inline int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
- u16 clkctrl_offs)
-{
- return 0;
-}
-
-static inline void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
- s16 cdoffs, u16 clkctrl_offs)
-{
-}
-
-static inline void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
-u16 clkctrl_offs)
-{
-}
-
-# endif
-
/*
* In an ideal world, we would not export these low-level functions,
* but this will probably take some time to fix properly
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..28cbfb2 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -35,6 +35,7 @@
#include prm2xxx_3xxx.h
#include prm44xx.h
#include prminst44xx.h
+#include cminst44xx.h
#include prm-regbits-24xx.h
#include prm-regbits-44xx.h
#include control.h
@@ -164,3 +165,25 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
omap_cm_base_init();
}
}
+
+/*
+ * Stubbed functions so that common files continue to build when
+ * custom builds are used
+ * XXX These are temporary and should be removed at the earliest possible
+ * opportunity
+ */
+int __weak omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
+ u16 clkctrl_offs)
+{
+ return 0;
+}
+
+void __weak omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
+ s16 cdoffs, u16 clkctrl_offs)
+{
+}
+
+void __weak omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
+u16 clkctrl_offs)
+{
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 70ac2a1..f7bb57f 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -228,68 +228,6 @@
#ifndef __ASSEMBLER__
-/*
- * Stub omap2xxx/omap3xxx functions so that common files
- * continue to build when custom builds are used
- */
-#if defined(CONFIG_ARCH_OMAP4) !(defined(CONFIG_ARCH_OMAP2) || \
- defined(CONFIG_ARCH_OMAP3))
-static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
-{
- WARN(1, prm: omap2xxx/omap3xxx specific function and
- not suppose to be used on omap4\n);
- return 0;
-}
-static inline void omap2_prm_write_mod_reg(u32 val, s16 module,
Re: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Hi Paul, On Wed, Jul 4, 2012 at 8:49 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Thu, 28 Jun 2012, R, Sricharan wrote: Ping.. Since the prcm.c cleanup series isn't ready yet, I've queued this modified version of your patch. Once the prcm.c cleanup series is ready, hopefully in the 3.7 time frame, we'll be able to get rid of all of these nasty stubs. Thanks a lot. I think this should help to get rid of the OMAP5 dependency. Thanks, Sricharan -- 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 RESEND] ARM: OMAP2+: Fix Wake-up power domain power status
Thanks everyone, queued. - 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: [PATCH V2 07/10] ARM: OMAP4: CLKDM: Update supported transition modes
On Thu, 7 Jun 2012, Jon Hunter wrote: For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the following transition modes ... Thanks, queued. - 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: [PATCH v2 2/4] ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API
On Fri, 20 Apr 2012, Tarun Kanti DebBarma wrote: Add an API to get main clock name associated with a given @oh. This will avoid the need to construct fclk names during early initialization in order to get fclk handle using clk_get(). Thanks, queued. - 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
[GIT PULL] ARM: OMAP2+: miscellaneous PRCM hwmod patches for 3.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-f-for-3.6 for you to fetch changes up to 8cb8de5d87b75f2ecaa1189079764340ea366c0e: Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 'misc_devel_3.6' into omap_devel_f_3.6 (2012-07-04 06:05:51 -0600) - Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches for 3.6. Mostly small infrastructure improvements, and preparation for OMAP5 and AM33xx code. - Test logs are available here: http://www.pwsan.com/omap/testlogs/omap_devel_f_3.6/20120704085233/ On 3530ES3 Beagle, wakeup from dynamic retention idle is broken; can be worked around by reverting commit 91930652a23de0873a157aa1d9962cb878d64451 (OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup) -- but needs a better fix. Evidently this is being gated by lack of availability of a BeagleBoard for testing. On 3530ES3 Beagle and 37xx EVM, CORE powerdomain won't enter low power states; this seems to be due to the 32k sync timer problem; a revised fix has been posted. On 4430ES2 Panda, large UART transmit buffers are being corrupted when dynamic idle is enabled; no fix yet for this. All of these problems are present with the stock v3.5-rc5 kernel. object size (delta in bytes from test_v3.5-rc5 (6887a4131da3adaab011613776d865f4bcfb5678)): textdata bss total kernel +680+192 0+872 2430_testconfig/vmlinux 0 0 0 0 5912osk_testconfig/vmlinux +760+704 0 +1464 am33xx_testconfig/vmlinux +712+160 0+872 n800_b_testconfig/vmlinux +744+224 0+968 n800_multi_omap2xxx/vmlinux +712+160 0+872 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux +712+640 0 +1352 omap2_4_testconfig/vmlinux +752+960 0 +1712 omap2plus_defconfig/vmlinux +752+896 0 +1648 omap2plus_no_pm/vmlinux +688+704 0 +1392 omap3_4_testconfig/vmlinux +4784+256 0 +5040 omap3_testconfig/vmlinux +4784+448 0 +5232 omap4_testconfig/vmlinux Jon Hunter (2): ARM: OMAP4: clockdomain/CM code: Update supported transition modes ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status Kishon Vijay Abraham I (1): ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework Paul Walmsley (1): Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 'misc_devel_3.6' into omap_devel_f_3.6 R Sricharan (1): ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak Sakari Ailus (1): ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL Tarun Kanti DebBarma (1): ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API Vaibhav Hiremath (2): ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm Vikram Pandita (1): ARM: OMAP3+: dpll: optimize noncore dpll locking logic arch/arm/mach-omap2/clockdomain44xx.c| 10 +++- arch/arm/mach-omap2/cminst44xx.c | 14 - arch/arm/mach-omap2/cminst44xx.h | 25 - arch/arm/mach-omap2/control.h|1 + arch/arm/mach-omap2/dpll3xxx.c | 12 +++- arch/arm/mach-omap2/omap_hwmod.c | 76 -- arch/arm/mach-omap2/omap_hwmod_common_data.c | 10 arch/arm/mach-omap2/powerdomain.c|6 +- arch/arm/mach-omap2/prcm.c | 23 arch/arm/mach-omap2/prm2xxx_3xxx.h | 65 -- arch/arm/mach-omap2/prm_common.c | 62 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 19 +++ 12 files changed, 209 insertions(+), 114 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP9GKMAAoJEMePsQ0LvSpLu0QP/0tWcwek93htyYJ4N2vg64rq uazy+wXY+SDOIDBazkY5OgWlgrpT8CSy37Qg5hfNfmXO78aTwOVI38JFG664i6TB ld+s85VXOrWpP5qO0GyZ9THy8ZBv57HrBz4wisVS2KM+CoVsIyczmLCFgSM9LKR4 3muQi2Z0Zcwjpk6AozHvGihkX2gvzd+urRFqCeo5ksWroMohTyl4E8fhtfAxFKd0 rXkmrrPGKpaqwuX6xMrlx5Tx3jzDweXzKRQFjrNCs7LwupCKSDx1fFTL5ZnMCApI XeAupUrk4R0Wdg0TMpkGoIoLUGiqhDdn6jQ/Stn2Ge1DNrHUxiXqe+x4vqVxJcqx Ez8QKqvZ34btcQ2nS9m0y8Kau2yeUGcc2PJAtb+WzA1xu1l+gR2oKToSY8dy0dPW HCKnSaxk1OsqfmHSMeK+kS12O33jdouzOdhna9nO1BdB61gNK6qNQE828jJ8/5W+
RE: [PATCH] ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework
On Wed, 4 Jul 2012, Hiremath, Vaibhav wrote: ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm Can this also be merged into your pull request? Those have been sent as part of http://marc.info/?l=linux-omapm=134141682714516w=2 - 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
[PATCH 1/1] Watchdog: OMAP3: fix wrong boot status from wdt reboot
Does the following fix make sense?
WDIOC_GETBOOTSTATUS always return 0 even if the machine
comes from omap-wdt reboot. Because WKUP_MOD is not right
for OMAP3, so give the right addr 0xA00 of PRM_RSTST for
get_reset_sources, which inputs the signal from omap-wdt
reboot, and return 1 when coming from omap-wdt reboot for
WDIOC_GETBOOTSTATUS.
Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
---
arch/arm/mach-omap2/prcm.c |4 +++-
drivers/watchdog/omap_wdt.c |3 +++
drivers/watchdog/omap_wdt.h |3 +++
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..43f3feb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -49,8 +49,10 @@ 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;
+ if (cpu_is_omap34xx())
+ return omap2_prm_read_mod_reg(0xA00, OMAP2_RM_RSTST) 0x7f;
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST) 0x7f;
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..ea57078 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -234,6 +234,9 @@ static long omap_wdt_ioctl(struct file *file, unsigned int
cmd,
if (cpu_is_omap24xx())
return put_user(omap_prcm_get_reset_sources(),
(int __user *)arg);
+ if (cpu_is_omap34xx())
+ return put_user(omap_prcm_get_reset_sources() 0x10
+ OMAP3_PRM_RSTST_BIT, (int __user *)arg);
return put_user(0, (int __user *)arg);
case WDIOC_KEEPALIVE:
pm_runtime_get_sync(wdev-dev);
diff --git a/drivers/watchdog/omap_wdt.h b/drivers/watchdog/omap_wdt.h
index 09b774c..d8d5daa 100644
--- a/drivers/watchdog/omap_wdt.h
+++ b/drivers/watchdog/omap_wdt.h
@@ -40,6 +40,9 @@
#define OMAP_WATCHDOG_WPS (0x34)
#define OMAP_WATCHDOG_SPR (0x48)
+/* PRM_RSTST MPU_WD_RST bit */
+#define OMAP3_PRM_RSTST_BIT4
+
/* Using the prescaler, the OMAP watchdog could go for many
* months before firing. These limits work without scaling,
* with the 60 second default assumed by most tools and docs.
--
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: [PATCH 1/1] Watchdog: OMAP3: fix wrong boot status from wdt reboot
To: Shubhrajyoti
On 2012年07月04日 23:54, Zumeng Chen wrote:
Does the following fix make sense?
WDIOC_GETBOOTSTATUS always return 0 even if the machine
comes from omap-wdt reboot. Because WKUP_MOD is not right
for OMAP3, so give the right addr 0xA00 of PRM_RSTST for
get_reset_sources, which inputs the signal from omap-wdt
reboot, and return 1 when coming from omap-wdt reboot for
WDIOC_GETBOOTSTATUS.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
arch/arm/mach-omap2/prcm.c |4 +++-
drivers/watchdog/omap_wdt.c |3 +++
drivers/watchdog/omap_wdt.h |3 +++
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..43f3feb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -49,8 +49,10 @@ 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;
+ if (cpu_is_omap34xx())
+ return omap2_prm_read_mod_reg(0xA00, OMAP2_RM_RSTST) 0x7f;
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST) 0x7f;
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..ea57078 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -234,6 +234,9 @@ static long omap_wdt_ioctl(struct file *file, unsigned int
cmd,
if (cpu_is_omap24xx())
return put_user(omap_prcm_get_reset_sources(),
(int __user *)arg);
+ if (cpu_is_omap34xx())
+ return put_user(omap_prcm_get_reset_sources() 0x10
+ OMAP3_PRM_RSTST_BIT, (int __user *)arg);
return put_user(0, (int __user *)arg);
case WDIOC_KEEPALIVE:
pm_runtime_get_sync(wdev-dev);
diff --git a/drivers/watchdog/omap_wdt.h b/drivers/watchdog/omap_wdt.h
index 09b774c..d8d5daa 100644
--- a/drivers/watchdog/omap_wdt.h
+++ b/drivers/watchdog/omap_wdt.h
@@ -40,6 +40,9 @@
#define OMAP_WATCHDOG_WPS (0x34)
#define OMAP_WATCHDOG_SPR (0x48)
+/* PRM_RSTST MPU_WD_RST bit */
+#define OMAP3_PRM_RSTST_BIT4
+
/* Using the prescaler, the OMAP watchdog could go for many
* months before firing. These limits work without scaling,
* with the 60 second default assumed by most tools and docs.
--
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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Paul,
On 07/04/2012 02:48 PM, Paul Walmsley wrote:
Hi Benoît,
On Fri, 15 Jun 2012, Cousson, Benoit wrote:
My point is simple, we should not add any new custom flag when all the
information to detect such exception are already there in the current
data and represent accurately what the HW is doing.
This seems like the crux of the issue. We don't have sufficient
information to detect this exception in our current data, in my view.
The software additionally must know when it can rely on a clockdomain
remaining active when the MPU is active.
Yes, indeed, but that will be accurate mostly for OMAP3.
On OMAP4, *in theory* the dynamic dependency should always ensure that a
clock domain will be accessible upon any initiator requests.
In that case the notion of a domain active when the MPU is active become
a little bit less accurate.
Except when we have to force the static dep because of HW bugs
workaround. In that case, we are in the same situation than OMAP3.
Ideally the hardcoded clockdomain sleep dependencies would be encoded, and
we could test the intersection of those and the software-programmable
clockdomain sleep dependencies. But such a change seems too complex for
the -rc cycle. So the updated patch below uses a clockdomain data flag
for this instead.
Yep, I do agree that encoding that kind of information will require more
thought and much more code.
I have the feeling that some information about the IP idle behavior
should help figuring out that module like counter_32k, GPIO or mailbox
can be handled without real SW control.
This intermediate approach is thus good for the moment.
From: Paul Walmsley p...@pwsan.com
Date: Wed, 4 Jul 2012 05:22:53 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
[...]
@@ -1208,8 +1219,13 @@ static void _idle_sysc(struct omap_hwmod *oh)
sf = oh-class-sysc-sysc_flags;
if (sf SYSC_HAS_SIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_FORCE : HWMOD_IDLEMODE_SMART;
+ /* XXX What about HWMOD_IDLEMODE_SMART_WKUP? */
What do you mean here?
Regards,
Benoit
--
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] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.
Wim, On Mon, Jun 18, 2012 at 11:11 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: (You should cc linux-omap too. CC'ing linux-omap) On Mon, Jun 18, 2012 at 10:53 AM, Lokesh Vutla lokeshvu...@ti.com wrote: OMAP watchdong driver is adapted to runtime PM like a general device driver but it is not appropriate. It is causing couple of functional issues. 1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module, which constantly stays in in transition state. Value of register CM_WKUP_WDTIMER2_CLKCTRL is always 0x0001 in this case. Issue occurs immediately after first idle, when hwmod framework tries to disable WDTIMER2 functional clock - wd_timer2_fck. After this module falls to in transition state, and SYSCLK gating is blocked. 2. Due to runtime PM, watchdog timer may be completely disabled. In current code base watchdog timer is not disabled only because of issue 1. Otherwise state of WDTIMER2 module will be Disabled, and there will be no interrupts from omap_wdt. In other words watchdog will not work at all. Watchdong is a special IP and it should not be disabled otherwise purpose of it itself is defeated. Watchdog functional clock should never be disabled. This patch updates the runtime PM handling in driver so that runtime PM is limited only during probe/shutdown and suspend/resume. The patch fixes issue 1 and 2 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Wim Van Sebroeck w...@iguana.be --- Any comments on this patch ? If not, can you please queue this up for the 3.5-rc? 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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Kevin, On 07/04/2012 04:27 PM, Kevin Hilman wrote: [...] Tested-by: Kevin Hilman khil...@ti.com I confirm this version is now allowing CORE to hit retention during suspend. Benoit, I hope this is OK with you. We need a fix for this in v3.5 since this is last core bug preventing CORE retention in v3.5. On OMAP4 as well? I've just tried with the hwmod fix for AESS and USB and still cannot reach RET. Am I missing some other patches for OMAP4? Regards, Benoit -- 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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On Wed, 2012-07-04 at 18:14 +0200, Benoit Cousson wrote: Hi Kevin, On 07/04/2012 04:27 PM, Kevin Hilman wrote: [...] Tested-by: Kevin Hilman khil...@ti.com I confirm this version is now allowing CORE to hit retention during suspend. Benoit, I hope this is OK with you. We need a fix for this in v3.5 since this is last core bug preventing CORE retention in v3.5. On OMAP4 as well? I've just tried with the hwmod fix for AESS and USB and still cannot reach RET. Am I missing some other patches for OMAP4? You need also fixes for sl2if and mcpdm in addition to above. -Tero -- 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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On 07/04/2012 06:41 PM, Tero Kristo wrote: On Wed, 2012-07-04 at 18:14 +0200, Benoit Cousson wrote: Hi Kevin, On 07/04/2012 04:27 PM, Kevin Hilman wrote: [...] Tested-by: Kevin Hilman khil...@ti.com I confirm this version is now allowing CORE to hit retention during suspend. Benoit, I hope this is OK with you. We need a fix for this in v3.5 since this is last core bug preventing CORE retention in v3.5. On OMAP4 as well? I've just tried with the hwmod fix for AESS and USB and still cannot reach RET. Am I missing some other patches for OMAP4? You need also fixes for sl2if and mcpdm in addition to above. Are they in some lo branch already? Benoit -- 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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Paul,
On 07/04/2012 02:53 PM, Paul Walmsley wrote:
On Wed, 4 Jul 2012, Paul Walmsley wrote:
So the updated patch below uses a clockdomain data flag for this
instead.
Here's a version that's a little cleaner. No functional changes.
[...]
@@ -1141,8 +1144,16 @@ static void _enable_sysc(struct omap_hwmod *oh)
sf = oh-class-sysc-sysc_flags;
if (sf SYSC_HAS_SIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ clkdm_act = ((oh-clkdm
+ oh-clkdm-flags CLKDM_ACTIVE_WITH_MPU) ||
+ (oh-_clk-clkdm
This is crashing on OMAP4 due to a NULL oh-_clk that can happen on some
hwmod.
+(oh-_clk oh-_clk-clkdm
Is fixing the issue.
Regards,
Benoit
+ oh-_clk-clkdm-flags CLKDM_ACTIVE_WITH_MPU));
+ if (clkdm_act !(oh-class-sysc-idlemodes
+(SIDLE_SMART | SIDLE_SMART_WKUP)))
+ idlemode = HWMOD_IDLEMODE_FORCE;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_SIDLE) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
_set_slave_idlemode(oh, idlemode, v);
}
--
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: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Benoît
On Wed, 4 Jul 2012, Benoit Cousson wrote:
@@ -1141,8 +1144,16 @@ static void _enable_sysc(struct omap_hwmod *oh)
sf = oh-class-sysc-sysc_flags;
if (sf SYSC_HAS_SIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ clkdm_act = ((oh-clkdm
+ oh-clkdm-flags CLKDM_ACTIVE_WITH_MPU) ||
+(oh-_clk-clkdm
This is crashing on OMAP4 due to a NULL oh-_clk that can happen on some
hwmod.
+ (oh-_clk oh-_clk-clkdm
Is fixing the issue.
Thanks, just made the change and pushed the patch up to
git://git.pwsan.com/linux-2.6 in the branch 'omap_fixes_c_3.5rc'
- Paul
Re: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
On Wed, 4 Jul 2012, Benoit Cousson wrote: On 07/04/2012 06:41 PM, Tero Kristo wrote: On Wed, 2012-07-04 at 18:14 +0200, Benoit Cousson wrote: On OMAP4 as well? I've just tried with the hwmod fix for AESS and USB and still cannot reach RET. Am I missing some other patches for OMAP4? You need also fixes for sl2if and mcpdm in addition to above. Are they in some lo branch already? The old version of these patches are in the 'sl2if_mcpdm_reset_fix_3.5rc` branch of git://git.pwsan.com/linux-2.6 - they haven't yet been updated and tested per Benoît's comments. If someone else wants to take that over for 3.5-rc, by all means please do. - Paul
Re: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hi Benoît
On Wed, 4 Jul 2012, Benoit Cousson wrote:
From: Paul Walmsley p...@pwsan.com
Date: Wed, 4 Jul 2012 05:22:53 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync
timer
[...]
@@ -1208,8 +1219,13 @@ static void _idle_sysc(struct omap_hwmod *oh)
sf = oh-class-sysc-sysc_flags;
if (sf SYSC_HAS_SIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_SIDLE) ?
- HWMOD_IDLEMODE_FORCE : HWMOD_IDLEMODE_SMART;
+ /* XXX What about HWMOD_IDLEMODE_SMART_WKUP? */
What do you mean here?
We're not programming IP block target idle modes to smart idle + wakeup on
OMAP4. We're only programming them to smart idle :-(
- Paul
[PATCH] omap-rng: Use struct dev_pm_ops for power management
From: Rafael J. Wysocki r...@sisk.pl
Make the omap-rng driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/char/hw_random/omap-rng.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
Index: linux/drivers/char/hw_random/omap-rng.c
===
--- linux.orig/drivers/char/hw_random/omap-rng.c
+++ linux/drivers/char/hw_random/omap-rng.c
@@ -162,22 +162,24 @@ static int __exit omap_rng_remove(struct
#ifdef CONFIG_PM
-static int omap_rng_suspend(struct platform_device *pdev, pm_message_t message)
+static int omap_rng_suspend(struct device *dev)
{
omap_rng_write_reg(RNG_MASK_REG, 0x0);
return 0;
}
-static int omap_rng_resume(struct platform_device *pdev)
+static int omap_rng_resume(struct device *dev)
{
omap_rng_write_reg(RNG_MASK_REG, 0x1);
return 0;
}
+static SIMPLE_DEV_PM_OPS(omap_rng_pm, omap_rng_suspend, omap_rng_resume);
+#defineOMAP_RNG_PM (omap_rng_pm)
+
#else
-#defineomap_rng_suspendNULL
-#defineomap_rng_resume NULL
+#defineOMAP_RNG_PM NULL
#endif
@@ -188,11 +190,10 @@ static struct platform_driver omap_rng_d
.driver = {
.name = omap_rng,
.owner = THIS_MODULE,
+ .pm = OMAP_RNG_PM,
},
.probe = omap_rng_probe,
.remove = __exit_p(omap_rng_remove),
- .suspend= omap_rng_suspend,
- .resume = omap_rng_resume
};
static int __init omap_rng_init(void)
--
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 Wed, Jul 4, 2012 at 3:36 PM, Ohad Ben-Cohen o...@wizery.com 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 li...@arm.linux.org.uk. Cc: Russell King li...@arm.linux.org.uk Cc: Stephen Boyd sb...@codeaurora.org Cc: Fernando Guzman Lugo fernando.l...@ti.com Cc: Sjur Brændeland sjur.brandel...@stericsson.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com I understand this patch and it's a good thing, so: Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at net/ethernet taking care of accepting device path / MAC mapping registrations and running a notifier to enforce the requested MAC when the matching network device turns up. On PandaBoard / ES, two devices have no board-level MAC either assigned by the manufacturer or stored on the board, the last patch in the series adds these device paths and gets them set when the network device is registered. Lastly for convenient testing, there's a little patch on omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard. The patches are against today's linux-omap. Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the helper in net/ethernet. --- Andy Green (4): OMAP: add cpu id register to MAC address helper NET ethernet introduce mac_platform helper OMAP4 PANDA register ethernet and wlan for automatic mac allocation config test config extending omap2plus with wl12xx etc arch/arm/configs/omap2plus_defconfig | 35 +++ arch/arm/mach-omap2/Kconfig|1 arch/arm/mach-omap2/board-omap4panda.c | 30 ++ arch/arm/mach-omap2/id.c | 39 arch/arm/mach-omap2/include/mach/id.h |1 include/net/mac-platform.h | 39 net/Kconfig|5 + net/ethernet/Makefile |3 + net/ethernet/mac-platform.c| 151 9 files changed, 282 insertions(+), 22 deletions(-) create mode 100644 include/net/mac-platform.h create mode 100644 net/ethernet/mac-platform.c -- 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 4 1/4] OMAP: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address space has space set aside for these kind of locally
administered MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.
The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.
Signed-off-by: Andy Green andy.gr...@linaro.org
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Nicolas Pitre nicolas.pi...@linaro.org
Tested-by: Steven Rostedt rost...@goodmis.org
---
arch/arm/mach-omap2/id.c | 39 +
arch/arm/mach-omap2/include/mach/id.h |1 +
2 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37eb95a..3ab5d4d 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address. Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+ struct omap_die_id odi;
+ u32 tap = read_tap_reg(OMAP_TAP_IDCODE);
+
+ omap_get_die_id(odi);
+
+ mac[0] = odi.id_2;
+ mac[1] = odi.id_2 8;
+ mac[2] = odi.id_1;
+ mac[3] = odi.id_1 8;
+ mac[4] = odi.id_1 16;
+ mac[5] = odi.id_1 24;
+
+ /* XOR other chip-specific data with ID */
+
+ tap ^= odi.id_3;
+
+ mac[0] ^= tap;
+ mac[1] ^= tap 8;
+ mac[2] ^= tap 16;
+ mac[3] ^= tap 24;
+
+ /* allow four MACs from this same basic data */
+
+ mac[1] = (mac[1] ~0xc0) | ((subtype 3) 6);
+
+ /* mark it as not multicast, and outside official 80211 MAC namespace */
+
+ mac[0] = (mac[0] ~1) | 2;
+}
diff --git a/arch/arm/mach-omap2/include/mach/id.h
b/arch/arm/mach-omap2/include/mach/id.h
index 02ed3aa..d6c8d63 100644
--- a/arch/arm/mach-omap2/include/mach/id.h
+++ b/arch/arm/mach-omap2/include/mach/id.h
@@ -18,5 +18,6 @@ struct omap_die_id {
};
void omap_get_die_id(struct omap_die_id *odi);
+void omap_die_id_to_ethernet_mac(u8 *mac, int subtype);
#endif
--
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 4 2/4] NET ethernet introduce mac_platform helper
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed to be assigned to the device when it appears.
This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface. It has been tested with USB
and SDIO probed devices.
Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.
This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address. The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory. Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.
Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.
Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).
Cc: net...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/net/mac-platform.h | 39 +++
net/Kconfig |5 +
net/ethernet/Makefile |3 +
net/ethernet/mac-platform.c | 151 +++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
diff --git a/include/net/mac-platform.h b/include/net/mac-platform.h
new file mode 100644
index 000..3a59098
--- /dev/null
+++ b/include/net/mac-platform.h
@@ -0,0 +1,39 @@
+/*
+ * mac-platform.h: Enforces platform-defined MAC for Async probed devices
+ */
+
+#ifndef __NET_MAC_PLATFORM_H__
+#define __NET_MAC_PLATFORM_H__
+
+#include linux/if_ether.h
+
+/**
+ * struct mac_platform - associates asynchronously probed device path with
+ * MAC address to be assigned to the device when it
+ * is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_platform {
+ char *device_path;
+ u8 mac[ETH_ALEN];
+ struct list_head list; /* unused in platform data usage */
+};
+
+#ifdef CONFIG_NET
+/**
+ * mac_platform_register_device_macs - add an array of device path to monitor
+ * and MAC to apply when the network device
+ * at the device path appears
+ * @macs: array of struct mac_platform terminated by entry with
+ * NULL device_path
+ */
+int mac_platform_register_device_macs(const struct mac_platform *macs);
+#else
+static inline int mac_platform_register_device_macs(macs) { return 0; }
+#endif /* !CONFIG_NET */
+
+#endif /* __NET_MAC_PLATFORM_H__ */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..487c9e6 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,9 +335,12 @@ source net/caif/Kconfig
source net/ceph/Kconfig
source net/nfc/Kconfig
-
endif # if NET
+# used by board / dt platform to enforce MACs for Async-probed devices
+config MAC_PLATFORM
+ bool
+
# Used by archs to tell that they support BPF_JIT
config HAVE_BPF_JIT
bool
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..475db2b 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,6 @@
obj-y += eth.o
obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
+ifneq ($(CONFIG_NET),)
+obj-$(CONFIG_MAC_PLATFORM) += mac-platform.o
+endif
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
new file mode 100644
index 000..88e50ce
--- /dev/null
+++ b/net/ethernet/mac-platform.c
@@ -0,0 +1,151 @@
+/*
+ * Helper to allow platform code to enforce association of a locally-
+ * administered MAC address automatically on asynchronously probed devices,
+ * such as SDIO and USB based devices.
+ *
+ * Because the device
[PATCH 4 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00. No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.
This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/board-omap4panda.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 83fb31c..06fadf4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select MAC_PLATFORM
config MACH_PCM049
bool OMAP4 based phyCORE OMAP4
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..b028141 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
#include linux/wl12xx.h
#include linux/platform_data/omap-abe-twl6040.h
+#include net/mac-platform.h
+
#include mach/hardware.h
+#include mach/id.h
#include asm/hardware/gic.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
}
}
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct mac_platform panda_mac_platform[] = {
+
+ { /* smsc USB - Ethernet bridge */
+ .device_path = usb1/1-1/1-1.1/1-1.1:1.0,
+ },
+ { /* wlan0 module */
+ .device_path = wl12xx,
+ },
+ { /* terminator */
+ }
+};
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
int ret;
+ int n;
if (omap_rev() == OMAP4430_REV_ES1_0)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, NULL, package);
omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ /*
+* provide MAC addresses computed from device ID for network
+* devices that have no MAC address otherwise on Panda
+*/
+ for (n = 0; n ARRAY_SIZE(panda_mac_platform) - 1; n++)
+ omap_die_id_to_ethernet_mac(panda_mac_platform[n].mac, n);
+ if (mac_platform_register_device_macs(panda_mac_platform))
+ pr_err(Unable to register mac_platform devices\n);
+
ret = wl12xx_set_platform_data(omap_panda_wlan_data);
if (ret)
pr_err(error setting wl12xx data: %d\n, ret);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4 4/4] config test config extending omap2plus with wl12xx etc
From: Andy Green a...@warmcat.com This is just provided for testing convenience, it has enough config options to get Ethernet and WL12xx driver on PandaBoard / ES up You should be able to reproduce something like this, with different MAC addresses. # ifconfig -a eth0 Link encap:Ethernet HWaddr 2e:20:3c:ea:46:01 inet addr:10.42.0.98 Bcast:10.42.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:31 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1647 (1.6 KB) TX bytes:5534 (5.5 KB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 B) TX bytes:100 (100.0 B) wlan0 Link encap:Ethernet HWaddr 2e:60:3c:ea:46:01 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Signed-off-by: Andy Green andy.gr...@linaro.org --- arch/arm/configs/omap2plus_defconfig | 35 ++ 1 file changed, 14 insertions(+), 21 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index f3087cb..7dcd384 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -2,13 +2,13 @@ CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y -# CONFIG_SYSCTL_SYSCALL is not set -CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_SLAB=y CONFIG_PROFILING=y CONFIG_OPROFILE=y @@ -20,13 +20,12 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_LEDS=y @@ -60,6 +59,7 @@ CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_CFG80211=m +CONFIG_LIB80211=m CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y @@ -87,22 +87,20 @@ CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_MD=y CONFIG_NETDEVICES=y -CONFIG_SMSC_PHY=y -CONFIG_NET_ETHERNET=y -CONFIG_SMC91X=y -CONFIG_SMSC911X=y CONFIG_KS8851=y CONFIG_KS8851_MLL=y -CONFIG_LIBERTAS=m -CONFIG_LIBERTAS_USB=m -CONFIG_LIBERTAS_SDIO=m -CONFIG_LIBERTAS_DEBUG=y +CONFIG_SMC91X=y +CONFIG_SMSC911X=y +CONFIG_SMSC_PHY=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y +CONFIG_WL_TI=y +CONFIG_WL12XX=m +CONFIG_WLCORE_SDIO=m CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y @@ -131,14 +129,14 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y -CONFIG_REGULATOR_TWL4030=y +CONFIG_MFD_WL1273_CORE=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TWL4030=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y -CONFIG_FB_OMAP_LCD_VGA=y CONFIG_OMAP2_DSS=m CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y @@ -153,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_PLATFORM=y -CONFIG_DISPLAY_SUPPORT=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONTS=y @@ -173,7 +170,6 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y @@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y CONFIG_UBIFS_FS=y CONFIG_CRAMFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y -CONFIG_PARTITION_ADVANCED=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y -CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y -CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set +CONFIG_DEBUG_LL=y +CONFIG_EARLY_PRINTK=y CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_ANSI_CPRNG is not set -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
Re: [PATCH] remoteproc: adopt the driver core's alloc/add/del/put naming
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 li...@arm.linux.org.uk. Cc: Russell King li...@arm.linux.org.uk Acked-by: Stephen Boyd sb...@codeaurora.org Cc: Fernando Guzman Lugo fernando.l...@ti.com Cc: Sjur Brændeland sjur.brandel...@stericsson.com Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 4 2/4] NET ethernet introduce mac_platform helper
On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed to be assigned to the device when it appears.
The mac prefix is poor. I think eth_mac is better.
[]
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
[]
+static int mac_platform_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
alignment to parenthesis please.
[]
+int mac_platform_register_device_macs(const struct mac_platform *macs)
+{
[]
+ next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
+ if (!next) {
+ ret = -ENOMEM;
+ goto bail;
+ }
+
+ next-device_path = kmalloc(strlen(macs-device_path) + 1,
+GFP_KERNEL);
+ if (!next-device_path) {
+ ret = -ENOMEM;
+ goto bail;
+ }
+
+ strcpy(next-device_path, macs-device_path);
+ memcpy(next-mac, macs-mac, sizeof macs-mac);
kmemdup and kstrdup()
+ list_add(next-list, mac_platform_list);
+
+ macs++;
+ }
+
+bail:
+ mutex_unlock(mac_platform_mutex);
+
+ return ret;
+}
leaking memory on failures.
--
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 4 2/4] NET ethernet introduce mac_platform helper
On 05/07/12 11:12, the mail apparently from Joe Perches included:
Thanks for the comments.
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed to be assigned to the device when it appears.
The mac prefix is poor. I think eth_mac is better.
OK.
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
[]
+static int mac_platform_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
alignment to parenthesis please.
OK. Although different places in the kernel seem to have different
expectations about that.
+int mac_platform_register_device_macs(const struct mac_platform *macs)
+{
[]
+ next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
+ if (!next) {
+ ret = -ENOMEM;
+ goto bail;
+ }
+
+ next-device_path = kmalloc(strlen(macs-device_path) + 1,
+ GFP_KERNEL);
+ if (!next-device_path) {
+ ret = -ENOMEM;
+ goto bail;
+ }
+
+ strcpy(next-device_path, macs-device_path);
+ memcpy(next-mac, macs-mac, sizeof macs-mac);
kmemdup and kstrdup()
OK
+ list_add(next-list, mac_platform_list);
+
+ macs++;
+ }
+
+bail:
+ mutex_unlock(mac_platform_mutex);
+
+ return ret;
+}
leaking memory on failures.
Right... I'll fix these and wait for more comments.
Thanks again for the review.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper
On Thu, 2012-07-05 at 11:20 +0800, Andy Green wrote: On 05/07/12 11:12, the mail apparently from Joe Perches included: [] diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c [] +static int mac_platform_netdev_event(struct notifier_block *this, + unsigned long event, void *ptr) alignment to parenthesis please. OK. Although different places in the kernel seem to have different expectations about that. net and drivers/net is pretty consistent. Most of the exceptions are old code. Some of those exceptions are being slowly updated too. cheers, Joe -- 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 0/4] ARM: OMAP2+: dmtimer: cleanup related to devm API and clk usage
Hi Tony, On Thu, Jun 14, 2012 at 4:28 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Tony, On Thu, Jun 14, 2012 at 4:24 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Fri, Apr 20, 2012 at 6:09 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: The devm API usage in probe() simplifies error handling operation. Since iclk is not used in the driver it is removed from wherever not needed. Corrected the timer fck name mis-match between clock44xx_data.c and omap_hwmod_44xx_data.c. Added omap_hwmod_get_main_clk() API. There is no more need to construct clock names using sprintf() to be used in clk_get() during initialization. Reference: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Commit: e816b57a337ea3b755de72bec38c10c864f23015 (Linux 3.4-rc3) Series is available here for reference: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev dmtimer_cleanup_for_3.5 Tested on following platforms: OMAP5, OMAP4430SDP, OMAP3430SDP, OMAP2430SDP. Could not test on OMAP2420 due to unavailability of board. v2: - Use devm_request_and_ioremap() instead of request_mem_region() and ioremap() - Add omap_hwmod_get_main_clk() API - Reverted changes of clock names from OMAP2 and OMAP3 platforms Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Tarun Kanti DebBarma (4): ARM: OMAP: dmtimer: use devm_ API and do some cleanup in probe() ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API ARM: OMAP2+: dmtimer: cleanup iclk usage ARM: OMAP2+: dmtimer: cleanup fclk usage [ping] Only one of the patches in the series (ARM: OMAP2+: dmtimer: cleanup iclk usage) has been taken. I just applied the remaining patches on top of Linux 3.5-rc2 and tested on OMAP3 and OMAP4. Can the remaining patches be taken as well? Just to let you know that this cleanup is essential for Benoit's OMAP4 hwmod cleanup and OMAP5 minimal support series. This is a gentle reminder in case you have missed somehow!! Let me know if anything else needs to be done. Thanks. -- Tarun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] add new cache maintenance api
From 393c4effbbec74ff9b969d53ce4d36fde56b71df Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Wed, 4 Jul 2012 16:43:41 +0530 Subject: [PATCH v4 0/2] add new cache maintenance api This patch series is the next version to - add a new cache maintenance api to support non-coherent iommu drivers. - flush both L1 and L2 caches from OMAP iommu whenever the page table memory is updated. Changes since the previous patch set (v3) - Minor cleanup for fixing checkpatch warnings. The implementation of the new api is based on the approach[1] discussed. [1]http://marc.info/?l=linux-kernelm=131316512713815w=2 Signed-off-by: Ramesh Gupta G grgu...@ti.com Ramesh Gupta G (2): ARM: new cache maintenance api for iommu OMAP:IOMMU:flush L1 and L2 caches arch/arm/include/asm/cacheflush.h | 26 ++ arch/arm/include/asm/glue-cache.h |1 + arch/arm/mm/cache-fa.S| 15 +++ arch/arm/mm/cache-v3.S| 14 +- arch/arm/mm/cache-v4.S| 15 +++ arch/arm/mm/cache-v4wb.S | 21 + arch/arm/mm/cache-v4wt.S | 17 + arch/arm/mm/cache-v6.S| 20 arch/arm/mm/cache-v7.S| 21 + arch/arm/mm/proc-arm1020.S| 22 ++ arch/arm/mm/proc-arm1020e.S | 20 arch/arm/mm/proc-arm1022.S| 20 arch/arm/mm/proc-arm1026.S| 20 arch/arm/mm/proc-arm920.S | 17 + arch/arm/mm/proc-arm922.S | 17 + arch/arm/mm/proc-arm925.S | 22 ++ arch/arm/mm/proc-arm926.S | 22 ++ arch/arm/mm/proc-arm940.S | 25 + arch/arm/mm/proc-arm946.S | 24 arch/arm/mm/proc-feroceon.S | 30 ++ arch/arm/mm/proc-macros.S |1 + arch/arm/mm/proc-mohawk.S | 18 ++ arch/arm/mm/proc-xsc3.S | 17 + arch/arm/mm/proc-xscale.S | 19 +++ drivers/iommu/omap-iommu.c| 26 +- 25 files changed, 452 insertions(+), 18 deletions(-) -- regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] ARM: new cache maintenance api for iommu
From 647d636610c62b13a5b1c28d35fde120f307fd62 Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Wed, 27 Jun 2012 16:50:32 +0530
Subject: [PATCH v4 1/2] ARM: new cache maintenance api for iommu
Non-coherent IOMMU drivers need to make sure
that the data held in the caches is available
for the slave processor MMU hardware whenever
there is an update to the pagetable memory of
the slave processor.
The page table memory is always updated from
the main processor and read from the slave
processor MMU.
A new cache maintenance api flush_iommu_mem is
added to handle this.The api clean and invalidate
the specified virtual address range (the pagetable
memory area that need to be flushed).The
implementation is based on the dma cache apis.
Thanks to RMK's suggestions on creating a
dedicated API for this purpose.
ref:http://marc.info/?l=linux-kernelm=131316512713815w=2
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/include/asm/cacheflush.h | 26 ++
arch/arm/include/asm/glue-cache.h |1 +
arch/arm/mm/cache-fa.S| 15 +++
arch/arm/mm/cache-v3.S| 14 +-
arch/arm/mm/cache-v4.S| 15 +++
arch/arm/mm/cache-v4wb.S | 21 +
arch/arm/mm/cache-v4wt.S | 17 +
arch/arm/mm/cache-v6.S| 20
arch/arm/mm/cache-v7.S| 21 +
arch/arm/mm/proc-arm1020.S| 22 ++
arch/arm/mm/proc-arm1020e.S | 20
arch/arm/mm/proc-arm1022.S| 20
arch/arm/mm/proc-arm1026.S| 20
arch/arm/mm/proc-arm920.S | 17 +
arch/arm/mm/proc-arm922.S | 17 +
arch/arm/mm/proc-arm925.S | 22 ++
arch/arm/mm/proc-arm926.S | 22 ++
arch/arm/mm/proc-arm940.S | 25 +
arch/arm/mm/proc-arm946.S | 24
arch/arm/mm/proc-feroceon.S | 30 ++
arch/arm/mm/proc-macros.S |1 +
arch/arm/mm/proc-mohawk.S | 18 ++
arch/arm/mm/proc-xsc3.S | 17 +
arch/arm/mm/proc-xscale.S | 19 +++
24 files changed, 443 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index d5d8d5c..a985881 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -84,6 +84,16 @@
* - kaddr - page address
* - size - region size
*
+ * flush_iommu_mem(start, end)
+ *
+ * Clean and invalidate the specified virtual address range.
+ * This is to support the non coherent iommu drivers.
+ * The iommu driver need to call this api with the page
+ * table memory address range to ensure the data held in
+ * the cache is visible to the slave processor MMU.
+ * - start - virtual start address
+ * - end- virtual end address
+ *
* DMA Cache Coherency
* ===
*
@@ -108,6 +118,7 @@ struct cpu_cache_fns {
void (*dma_unmap_area)(const void *, size_t, int);
void (*dma_flush_range)(const void *, const void *);
+ void (*flush_iommu_mem)(const void *, const void *);
};
/*
@@ -135,6 +146,14 @@ extern struct cpu_cache_fns cpu_cache;
#define dmac_unmap_areacpu_cache.dma_unmap_area
#define dmac_flush_range cpu_cache.dma_flush_range
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that the data held in the cache is visible
+ * to the MMU of the slave processor. This is called from
+ * the IOMMU driver whenever there is an update in the page tables
+ * for the slave processor.
+ */
+#define flush_iommu_mem(cpu_cache.flush_iommu_mem)
+
#else
extern void __cpuc_flush_icache_all(void);
@@ -155,6 +174,13 @@ extern void dmac_map_area(const void *, size_t, int);
extern void dmac_unmap_area(const void *, size_t, int);
extern void dmac_flush_range(const void *, const void *);
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that the data held in the cache is visible
+ * to the MMU of the slave processor. This is called from
+ * the IOMMU driver whenever there is an update in the page tables
+ * for the slave processor.
+ */
+extern void flush_iommu_mem(const void *, const void *);
#endif
/*
diff --git a/arch/arm/include/asm/glue-cache.h
b/arch/arm/include/asm/glue-cache.h
index 7e30874..ab8589a 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -141,6 +141,7 @@
#define dmac_map_area
[PATCH v4 2/2] OMAP:IOMMU:flush L1 and L2 caches
From 393c4effbbec74ff9b969d53ce4d36fde56b71df Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012 16:46:46 +0530
Subject: [PATCH v4 2/2] OMAP:IOMMU:flush L1 and L2 caches
OMAP IOMMU need to make sure that data in the L1 and L2
caches is visible to the MMU hardware whenever the
pagetables are updated. The current code only takes
care of L1 cache using assembly code. Added code to
handle this using a new L1 cache maintenance function
and the outer cache function.
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
drivers/iommu/omap-iommu.c | 26 +-
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6899dcd..f909019 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -469,22 +469,14 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
*/
static void flush_iopgd_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ flush_iommu_mem(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void flush_iopte_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ flush_iommu_mem(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void iopte_free(u32 *iopte)
@@ -513,7 +505,7 @@ static u32 *iopte_alloc(struct omap_iommu *obj,
u32 *iopgd, u32 da)
return ERR_PTR(-ENOMEM);
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
@@ -542,7 +534,7 @@ static int iopgd_alloc_section(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
}
*iopgd = (pa IOSECTION_MASK) | prot | IOPGD_SECTION;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
return 0;
}
@@ -559,7 +551,7 @@ static int iopgd_alloc_super(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
for (i = 0; i 16; i++)
*(iopgd + i) = (pa IOSUPER_MASK) | prot | IOPGD_SUPER;
- flush_iopgd_range(iopgd, iopgd + 15);
+ flush_iopgd_range(iopgd, iopgd + 16);
return 0;
}
@@ -700,7 +692,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
}
bytes *= nent;
memset(iopte, 0, nent * sizeof(*iopte));
- flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
+ flush_iopte_range(iopte, iopte + nent * sizeof(*iopte));
/*
* do table walk to check if this table is necessary or not
@@ -722,7 +714,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
bytes *= nent;
}
memset(iopgd, 0, nent * sizeof(*iopgd));
- flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
+ flush_iopgd_range(iopgd, iopgd + nent * sizeof(*iopgd));
out:
return bytes;
}
--
1.7.0.4
--
regards
Ramesh Gupta G
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Watchdog: OMAP3: fix wrong boot status from wdt reboot
Hello,
On Wednesday 04 July 2012 09:27 PM, zumeng.chen wrote:
To: Shubhrajyoti
On 2012年07月04日 23:54, Zumeng Chen wrote:
Does the following fix make sense?
yes , thanks for the patch.
IIRC Rajendra had a similar one.
Some comments below.
WDIOC_GETBOOTSTATUS always return 0 even if the machine
comes from omap-wdt reboot. Because WKUP_MOD is not right
for OMAP3,so give the right addr 0xA00 of PRM_RSTST for
get_reset_sources, which inputs the signal from omap-wdt
reboot, and return 1 when coming from omap-wdt reboot for
WDIOC_GETBOOTSTATUS.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
arch/arm/mach-omap2/prcm.c |4 +++-
drivers/watchdog/omap_wdt.c |3 +++
drivers/watchdog/omap_wdt.h |3 +++
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..43f3feb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -49,8 +49,10 @@ 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;
+if (cpu_is_omap34xx())
+return omap2_prm_read_mod_reg(0xA00, OMAP2_RM_RSTST) 0x7f;
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST)
0x7f;
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..ea57078 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -234,6 +234,9 @@ static long omap_wdt_ioctl(struct file *file,
unsigned int cmd,
if (cpu_is_omap24xx())
return put_user(omap_prcm_get_reset_sources(),
(int __user *)arg);
+if (cpu_is_omap34xx())
+return put_user(omap_prcm_get_reset_sources() 0x10
+OMAP3_PRM_RSTST_BIT, (int __user *)arg);
Actually instead of returning yes/no.
The correct expectation is to return WDIOF_* flags as defined in
include/linux/watchdog.h.
(BTW I agree that was something even current code is not
following).Since you are at it may be that’s
something you can consider.
return put_user(0, (int __user *)arg);
case WDIOC_KEEPALIVE:
pm_runtime_get_sync(wdev-dev);
diff --git a/drivers/watchdog/omap_wdt.h b/drivers/watchdog/omap_wdt.h
index 09b774c..d8d5daa 100644
--- a/drivers/watchdog/omap_wdt.h
+++ b/drivers/watchdog/omap_wdt.h
@@ -40,6 +40,9 @@
#define OMAP_WATCHDOG_WPS(0x34)
#define OMAP_WATCHDOG_SPR(0x48)
+/* PRM_RSTST MPU_WD_RST bit */
+#define OMAP3_PRM_RSTST_BIT4
+
/* Using the prescaler, the OMAP watchdog could go for many
* months before firing. These limits work without scaling,
* with the 60 second default assumed by most tools and docs.
--
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
