Re: [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:26]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
As mentioned, you might consider dropping the export until needed.
Here's this one updated to drop the export.
Tony
From: Tony Lindgren t...@atomide.com
Date: Tue, 4 Oct 2011 18:26:27 -0700
Subject: [PATCH] ARM: Add __arm_ioremap_exec for mapping external memory as
MT_MEMORY
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d66605d..4ff152e 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long,
size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t,
unsigned int);
extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, int cached);
extern void __iounmap(volatile void __iomem *addr);
/*
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..a2d94ac 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,27 @@ __arm_ioremap(unsigned long phys_addr, size_t size,
unsigned int mtype)
}
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
Why don't we allow user to pass the mtype here ?
We do have a need also to map a page of DDR and SRAM as
strongly ordered for errata fix and this interface can be
used for that.
Ofcourse, SO memory type is not executable memories, so the
API name might be miss-leading.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP: Avoid cpu_is_omapxxxx usage until map_io is done
On Wednesday 05 October 2011 06:15 AM, Tony Lindgren wrote: This way we don't need to initialize SoC detection early and can start using generic map_io. Signed-off-by: Tony Lindgren t...@atomide.com --- Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] drivercore: add new error value for deferred probe
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote: Add new error value so that drivers can request deferred probe from drivercore. Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Reported-by: Grant Likely grant.lik...@secretlab.ca --- Cc: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Greg Kroah-Hartman g...@kroah.com Cc: Dilan Lee di...@nvidia.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Manjunath GKondaiah manjunath.gkonda...@linaro.org Cc: Arnd Bergmann a...@arndb.de include/linux/errno.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/errno.h b/include/linux/errno.h index 4668583..83d8fcf 100644 --- a/include/linux/errno.h +++ b/include/linux/errno.h @@ -16,6 +16,7 @@ #define ERESTARTNOHAND 514 /* restart if no handler.. */ #define ENOIOCTLCMD 515 /* No ioctl command */ #define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */ +#define EPROBE_DEFER 517 /* restart probe again after some time */ Can we really do this? Isn't this some user/kernel api here? What's wrong with just overloading on top of an existing error code? Surely one of the other 516 types could be used here, right? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
From: Grant Likely grant.lik...@secretlab.ca
Allow drivers to report at probe time that they cannot get all the
resources required by the device, and should be retried at a
later time.
This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
mucking about with initcall ordering which is a complete hack, and
doesn't even remotely handle the case where device drivers are in
modules. This approach completely sidesteps the issues by allowing
driver registration to occur in any order, and any driver can request
to be retried after a few more other drivers get probed.
Original patch posted by Grant Likely grant.lik...@secretlab.ca at:
http://lwn.net/Articles/460522/
Enhancements to original patch by G, Manjunath Kondaiah manj...@ti.com
- checkpatch warning fixes
- added Kconfig symbol CONFIG_PROBE_DEFER
- replacing normal workqueue with singlethread_workqueue
- handling -EPROBE_DEFER error
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Greg Kroah-Hartman g...@kroah.com
Cc: Dilan Lee di...@nvidia.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Manjunath GKondaiah manjunath.gkonda...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
drivers/base/Kconfig | 11
drivers/base/base.h|3 +
drivers/base/core.c|6 ++
drivers/base/dd.c | 145
include/linux/device.h |7 ++
5 files changed, 172 insertions(+), 0 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 21cf46f..b412a71 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -172,6 +172,17 @@ config SYS_HYPERVISOR
bool
default n
+config PROBE_DEFER
+ bool Deferred Driver Probe
+ default y
+ help
+ This option provides deferring driver probe if it has dependency on
+ other driver. Without this feature, initcall ordering should be done
+ manually to resolve driver dependencies. This feature completely side
+ steps the issues by allowing driver registration to occur in any
+ order, and any driver can request to be retried after a few more other
+ drivers get probed.
Why is this even an option? Why would you ever want it disabled? Why
does it need to be selected?
If you are going to default something to 'y' then just make it so it
can't be turned off any other way by just not making it an option at
all.
It also cleans up this diff a lot, as you really don't want #ifdef in .c
files.
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -28,6 +28,136 @@
#include base.h
#include power/power.h
+#if defined CONFIG_PROBE_DEFER
+/*
+ * Deferred Probe infrastructure.
Why not use kerneldoc?
+ *
+ * Sometimes driver probe order matters, but the kernel doesn't always have
+ * dependency information which means some drivers will get probed before a
+ * resource it depends on is available. For example, an SDHCI driver may
+ * first need a GPIO line from an i2c GPIO controller before it can be
+ * initialized. If a required resource is not available yet, a driver can
+ * request probing to be deferred by returning -EPROBE_DEFER from its probe
hook
+ *
+ * Deferred probe maintains two lists of devices, a pending list and an
active
+ * list. A driver returning -EPROBE_DEFER causes the device to be added to
the
+ * pending list.
+ *
+ * The deferred_probe_mutex *must* be held any time the deferred_probe_*_list
+ * of the (struct device*)-deferred_probe pointers are manipulated
+ */
+static DEFINE_MUTEX(deferred_probe_mutex);
+static LIST_HEAD(deferred_probe_pending_list);
+static LIST_HEAD(deferred_probe_active_list);
+static struct workqueue_struct *deferred_wq;
+
+/**
+ * deferred_probe_work_func() - Retry probing devices in the active list.
+ */
+static void deferred_probe_work_func(struct work_struct *work)
+{
+ struct device *dev;
+ /*
Extra blank line please.
+ * This bit is tricky. We want to process every device in the
+ * deferred list, but devices can be removed from the list at any
+ * time while inside this for-each loop. There are two things that
+ * need to be protected against:
That's what the klist structure is supposed to make easier, why not use
that here?
+ * - if the device is removed from the deferred_probe_list, then we
+ * loose our place in the loop. Since any device can be removed
+ * asynchronously, list_for_each_entry_safe() wouldn't make things
+ * much better. Simplest solution is to restart walking the list
+ * whenever the
Re: [PATCH 0/5] Driver Probe Deferral Mechanism
On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote: Why did you send this series of patches out twice? Were they different? confused, greg k-h -- 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/4] ARM: OMAP: Map SRAM later on with ioremap_exec()
On Thursday 06 October 2011 03:43 AM, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111004 17:34]: On Tue, 4 Oct 2011, Tony Lindgren wrote: This allows us to remove omap hacks for map_io. Signed-off-by: Tony Lindgren t...@atomide.com Nice cleanup. Acked-by: Nicolas Pitre nicolas.pi...@linaro.org This one needed minor changes for the omap1 omap_sram_init call. Updated patch below, still assuming I have your ack for this one too. Tony From: Tony Lindgren t...@atomide.com Date: Tue, 4 Oct 2011 13:52:57 -0700 Subject: [PATCH] ARM: OMAP: Map SRAM later on with ioremap_exec() This allows us to remove omap hacks for map_io. Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Are you considering this change for 3.2? OMAP4 errata WA would have a conflict with the change is sram code and hence the question ? O.w patch looks fine to me. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early
On Thursday 06 October 2011 07:06 AM, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111004 18:17]: On Tue, 4 Oct 2011, Tony Lindgren wrote: Otherwise we can't do generic map_io as we currently rely on static mappings that work only because of arch_ioremap. Signed-off-by: Tony Lindgren t...@atomide.com That's great. Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Here's an updated version with all the early ioremap access converted to use L3/L4_IO_ADDRESS macros. Some of this may not be needed after generic map_io, but until then we can't use ioremap until in init_early after the SoC detection is done. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Tue, 4 Oct 2011 18:17:41 -0700 Subject: [PATCH] ARM: OMAP: Move set_globals initialization to happen in init_early Otherwise we can't do generic map_io as we currently rely on static mappings that work only because of arch_ioremap. Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com The changes looks fine to me. Though the ugly hard-coding is back with it, it's a step towards generic_io, so hopefully it won't have to stay for long time. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Tested-by: Santosh Shilimkar santosh.shilim...@ti.com considering it's commin -- 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/4] initialize omap SRAM later on with __arm_ioremap_exec()
On Thursday 06 October 2011 07:12 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [111004 23:29]: Will look at this series in next couple of days and do some testing. Thanks, turns out there were a few issues with early ioremap that I fixed. Care to check the L4_IO_ADDRESS changes? They look ok to me. It's all pushed now into sram-map-io branch at: https://github.com/tmlind/linux/tree/sram-map-io It seems it's booting now on all omaps I've tried, so will merge it into linux-omap master branch as well for testing. I have reviewed and tested this series. No problems seen. As asked on other thread, if you are targeting this one for 3.2, then sram changes would have a small conflict with OMAP4 errata patch. If it is for 3.3, we should be able to sort out that conflict easily. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2+: clock: use clock's recalc in DPLL handling
On Thu, 29 Sep 2011, Mike Turquette wrote:
Not all DPLLs are identical; some require special consideration such as
OMAP4's ABE DPLL, which can have an additional 4x multiplier added to
it's clock rate based on programming the REGM4XEN bit in it's CLKMODE
register.
Unfortunately the clock framework makes a few assumptions that all DPLLs
can have their rates calculated the same way which has led to incorrect
rates for OMAP4's DPLL_ABE in some cases. This patch fixes the same by
replacing explicit calls to omap2_dpll_get_rate with clk-recalc if
.recalc is populated for a clock. If .recalc is NULL then fall back to
omap2_dpll_get_rate.
Reported-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Mike Turquette mturque...@ti.com
I've merged this patch with Jon's ARM: OMAP3+: dpll: use DPLLs recalc
function instead of omap2_get_dpll_rate patch, which does almost exactly
the same thing, just without the conditionals on clk-recalc. Updated
patch below. Please let me know if you think I should change anything
about the changelog.
- Paul
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 7 Oct 2011 00:53:01 -0600
Subject: [PATCH] ARM: OMAP3+: dpll: use DPLLs recalc function instead of
omap2_get_dpll_rate
This is a continuation of Mike Turquette's patch OMAP3+: use
DPLL's round_rate when setting rate.
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function and so use the DPLLs recalc()
function pointer instead.
An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
in addition to the usual MN multipler and dividers and therefore
uses a different round_rate and recalc function.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Cc: Mike Turquette mturque...@ti.com
Cc: Misael Lopez Cruz misael.lo...@ti.com
[p...@pwsan.com: merged this patch with Mike's use clock's recalc in DPLL
handling patch; also reported by Misael]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/dpll3xxx.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 73a1595..fc56745 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -390,7 +390,8 @@ int omap3_noncore_dpll_enable(struct clk *clk)
* propagating?
*/
if (!r)
- clk-rate = omap2_get_dpll_rate(clk);
+ clk-rate = (clk-recalc) ? clk-recalc(clk) :
+ omap2_get_dpll_rate(clk);
return r;
}
@@ -424,6 +425,7 @@ void omap3_noncore_dpll_disable(struct clk *clk)
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
{
struct clk *new_parent = NULL;
+ unsigned long hw_rate;
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
@@ -435,7 +437,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (!dd)
return -EINVAL;
- if (rate == omap2_get_dpll_rate(clk))
+ hw_rate = (clk-recalc) ? clk-recalc(clk) : omap2_get_dpll_rate(clk);
+ if (rate == hw_rate)
return 0;
/*
--
1.7.6.3
--
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] OMAP DSS for v3.2
Hi Florian, Please pull OMAP DSS patches for v3.2 merge window. Note that there are some conflicts with other trees. The board file conflicts are trivial, changes in code which just happen to be next to each other. The LCD driver conflicts are even simpler, there were changes to them from some other tree, but I have removed the files. The conflicts have been solved properly by Stephen in linux-next: https://github.com/sfrothwell/linux-next/commit/3e31b3042760e3906d0a275d7adedfaf55ee5b0a I also attached the output from git show, as github seems to show the full diff for the merge commit. Are you ok with the conflicts? Tomi The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linux 3.1-rc6 (2011-09-12 14:02:02 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-florian Andy Doan (1): OMAPFB: make debug message more useful Archit Taneja (26): OMAP: DSS2: DISPC: Prepare dispc_dump_regs() for shortening OMAP: DSS2: DISPC: Shorten dispc_dump_regs() OMAP: DSS2: DISPC: dispc_save_context() and dispc_restore_context() cleanup OMAP: DSS2: DISPC: Shorten _dispc_set_color_conv_coef() OMAP: DSS2: Use a macro to declare size of the fifo_size array in dispc.c OMAP: DSS2: Use MIPI DSI enums from include/video/mipi_display.h OMAP: DSS2: DSI: Represent L4 and VP as sources of VC instead of modes OMAP: DSS2: Create enum for DSI operation modes OMAP: DSS2: DSI: Introduce generic write functions OMAP: DSS2: DSI: Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2() OMAP: DSS2: DSI: Split dsi_vc_dcs_read() into 2 functions OMAP: DSS2: DSI: Introduce generic read functions OMAP: DSS2: Clean up stallmode and io pad mode selection OMAP: DSS2: Create an enum for DSI pixel formats OMAP: DSS2: DSI: Send zero length packet in dsi_vc_send_null() OMAP: DSS2: DSI Video mode support OMAPDSS: DISPC: Reduce the number of arguments in dispc_ovl_setup() OMAPDSS: DISPC: Pass overlay params as arguments to dispc_ovl_setup() OMAPDSS: DISPC: Create helper function dispc_mgr_is_lcd() OMAPDSS: DISPC: Get correct pixel clock for TV manager OMAPDSS: DISPC: Remove hardcoded use of PPL in five tap clock calculation OMAPDSS: DISPC: Clean up scaling related clock and five tap calculations OMAPDSS: FEATURES: Create a range param to get max downscaling OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting OMAPDSS: DISPC: VIDEO3 pipeline support OMAPDSS: DISPC: zorder support for DSS overlays Arnd Bergmann (1): video/omap: fix build dependencies Daniel Morsing (1): OMAP: DSS2: Don't allow moving managers away from enabled displays Dima Zavin (1): OMAP: DSS: dispc: enable/disable clocks in error handler Mayuresh Janorkar (1): OMAP: DSS2: Add picodlp panel driver Mythri P K (14): OMAP4: DSS2: HDMI: HDMI clean up to pass base_address OMAP4: DSS2: HDMI: Move pll and video configuration OMAP4: DSS2: HDMI: Use specific HDMI timings structure OMAP4: DSS2: HDMI: Move HDMI IP independent generic header OMAP4: DSS2: HDMI: Move the EDID definition from HDMI OMAP4: DSS2: HDMI: Split the current HDMI driver to move OMAP4: DSS2: HDMI: Move the HDMI IP dependent audio OMAP4: DSS2: HDMI: Rename the functions in HDMI IP library OMAP4: DSS2: HDMI: Function pointer approach to call OMAP4: DSS2: Rename hdmi_omap4_panel.c to hdmi_panel.c OMAPDSS: HDMI: Move the comments in avi infoframe OMAPDSS: HDMI: Replace hdmi_reg struct with u16 OMAPDSS: HDMI: Add missing register definitions OMAPDSS: HDMI: Add support to dump registers through debugfs Thomas Weber (2): OMAP: DSS2: Support for Innolux AT070TN83 OMAP: Devkit8000: Change lcd driver to AT070TN83 Tomi Valkeinen (63): OMAP: DSS2: PicoDLP: fix error handling in power_on OMAP: DSS2: check for manager when enabling display Revert HACK: OMAP: DSS2: clk hack for OMAP2/3 Revert OMAP: DSS2: HDMI: fix hdmi clock name OMAP: DSS2: remove unneeded fck enable/disables OMAP: DSS2: Change DSI device naming OMAP4: TWL: Add common omapdss supplies OMAP: DSS2: DSI: Improve dsi_mux_pads parameters OMAP: DSS2: Implement dsi_mux_pads for OMAP4 OMAP: OMAPFB: make omapfb start even when a display is missing a driver OMAP: DSS2: fix clock sources on error and uninit OMAP: DSS2: Handle manager change in apply OMAP: DSS2: Remove EXPERIMENTAL from Kconfig OMAP: DSS2: Remove support for non-DISPC overlays OMAP: DSS2: DISPC: use lookup tables for bit shifts OMAP: DSS2: Add overlay caps to DSS features OMAP: DSS2: Add GLOBAL_ALPHA PRE_MULT_ALPHA to ovl caps OMAP: DSS2: string parsing cleanups OMAP: OMAPFB: string parsing cleanups OMAP: DSS2:
Re: [PATCH 0/5] Driver Probe Deferral Mechanism
Hi Greg, On Thu, Oct 06, 2011 at 11:50:42PM -0700, Greg KH wrote: On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote: Why did you send this series of patches out twice? Were they different? confused, Looks like this patch series has reached only individual recepients and not the mailing lists hence it was posted once again. Sorry for the spam. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Thu, Oct 6, 2011 at 10:05 PM, Paul Walmsley p...@pwsan.com wrote:
Hi Keshava,
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 227
1 files changed, 227 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 59fdb9f..b8ca690 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
...
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__ick = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_usb_host_hs_hwmod,
+ .clk = usbhost_ick,
+ .addr = omap34xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+/*
+ * This clock should be on/off only with main clock; If auto idle is set,
+ * the usbhs controller prevents the omap to enter in to low power mode,
+ * hence don't use auto idle here.
+ */
+ .flags = OCPIF_SWSUP_IDLE,
This is still unclear to me. Doesn't this interface clock support
interface clock auto-idle? If so, then when the UHH's target port is
forced idle and its initiator port is forced to standby, then shouldn't
the PRCM automatically idle this interface clock?
Thanks paul;
Now I am seeing that without OCPIF_SWSUP_IDLE the system is going to
low power mode but after
adding HWMOD_INIT_NO_RESET flag ; After adding this flag; I dint
check the system without this flag;
so, PRCM automatically idle this interface clock if UHH target port is
forced idle and force standby.
I can remove it now. :-)
Or is there some hardware problem where the PRCM won't auto-idle this
clock when the UHH is in idle + standby?
+};
+
...
+static struct omap_hwmod_ocp_if omap34xx_ick_cfg__usb_tll_hs = {
+ .clk = usbtll_ick,
+ .addr = omap34xx_usb_tll_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+/*
+ * This clock should be on/off only with main clock; If auto idle is set,
+ * the usbhs controller prevents the omap to enter in to low power mode,
+ * hence don't use auto idle here.
+ */
+ .flags = OCPIF_SWSUP_IDLE,
Same comment here, with the exception of the part about standby since the
TLL doesn't have an initiator port.
I will remove this also;
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
[GIT PULL] ARM: OMAP3+: clock fixes for 3.2
Hi Tony, The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap_clock_fixes_3.2 Jon Hunter (3): ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices Mike Turquette (3): ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate ARM: OMAP3+: dpll: assign clk rate from rounded rate during rate set Paul Walmsley (1): ARM: OMAP4460: Clock: Adding support for 4460 specific clocks arch/arm/mach-omap2/clkt_dpll.c | 51 + arch/arm/mach-omap2/clock.h |2 + arch/arm/mach-omap2/clock44xx.h |7 +++ arch/arm/mach-omap2/clock44xx_data.c | 32 +++ arch/arm/mach-omap2/dpll3xxx.c |9 +++- arch/arm/mach-omap2/dpll44xx.c | 69 ++ 6 files changed, 142 insertions(+), 28 deletions(-) - 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: [GIT PULL] ARM: OMAP3+: clock fixes for 3.2
On Fri, 7 Oct 2011, Paul Walmsley wrote: The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap_clock_fixes_3.2 Jon Hunter (3): ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices By the way, the subject line for this patch has been updated in the git branch to be prefixed with ARM: . - 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 2/4] ARM: OMAP4 PM: Add IO Daisychain support
Hi
some comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 36
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 9a36a7c..2e09d72 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
extern void omap3_enable_io_chain(void);
+extern void omap4_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..aa7cff4 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -16,8 +16,17 @@
#include linux/err.h
#include linux/slab.h
+#include plat/common.h
+
#include powerdomain.h
#include mach/omap4-common.h
+#include pm.h
+#include cm-regbits-44xx.h
+#include cminst44xx.h
+#include prm-regbits-44xx.h
+#include prcm44xx.h
+#include prm44xx.h
+#include prminst44xx.h
struct power_state {
struct powerdomain *pwrdm;
@@ -30,6 +39,33 @@ struct power_state {
static LIST_HEAD(pwrst_list);
+#define MAX_IOPAD_LATCH_TIME 1000
This macro is missing a comment, which should precede it, describing what
this value is.
+
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!omap4_cminst_read_inst_reg_bits(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET,
+ OMAP4430_GLOBAL_WUEN_MASK))
The above line doesn't look right. It's accessing a PRM instance register
with omap4_cminst_*()? Shouldn't that be omap4_prminst_*()?
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ ((omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
+ OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+ /* Trigger WUCLKIN disable */
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
This function belongs in mach-omap2/prminst44xx.c. I still think it would
be good if we moved all PRM/CM direct register accesses into prm*.c or
cm*.c files in mach-omap2/. Then none of those prm*.h includes would be
needed in pm44xx.c either.
+
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
--
1.7.0.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
- 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 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
Hi
a few comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for enabling IO
Daisy
chain is The I/O wake-up scheme is enabled by triggering the I/O daisy chain
control (Wu clock) by programming a dedicated register
(PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software must wait for
the I/O daisy chain to complete before it transitions the PER domain to a
nonfunctional state. This is done by polling a dedicated status bit in the
PRCM
module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared by
software when the bit is read to 1.
The original code was polling on a wrong register which is fixed in this
patch.
Also omap3_enable_io_chain is made non static as it's going to be used in
subsequent patches.
This patch should be split into a fix (for the WKEN/WKST bug) and then a
new patch that drops the 'static'. The new patch should also move this
function to prm2xxx_3xxx.c for the same reason that the OMAP4 version of
this function should be in prminst44xx.c.
In the medium-term, a bunch of the functions from prm2xxx_3xxx.c,
prminst44xx.c, etc. that are only used by the mach-omap2/pm*.c code should
be moved into the PRM driver that Tero is working on that will live in
drivers/.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c |6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..9a36a7c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+extern void omap3_enable_io_chain(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..61f1a5b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -95,7 +95,7 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
+void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN)
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
@@ -114,7 +114,7 @@ static void omap3_enable_io_chain(void)
return;
}
omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
- WKUP_MOD, PM_WKEN);
+ WKUP_MOD, PM_WKST);
}
}
}
--
1.7.0.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
- 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 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
Hi Paul Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
+ Benoît
On Fri, 16 Sep 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently the interface clocks for the two SLIMBUS peripherals are
named slimbus1_fck and slimbus2_fck. Rename these clocks to be
slimbus1_ick and slimbus2_ick so it is clear that these are
interface clocks and not functional clocks.
Signed-off-by: Jon Hunterjon-hun...@ti.com
This one, I don't quite understand. We should probably be removing these
MODULEMODE-only clocks from the OMAP4 tree, and using their parent clock
as the main_clk. That would be a good cleanup for 3.3...
Yes, but in order to remove that from the clock data we must ensure that
the hwmod entry is there.
I kept a lot of legacy MODULEMODE clocks just because of missing hwmod /
runtime_pm adaptation on some drivers.
In the case of slimbus, there is no main_clk but a bunch of optional
clocks. It looks similar to the DSS case. So we should not use the
parent clock as a main_clk.
We should probably promote one of the opt_clk as the main_clk. The
slimbus_clk seems to be the good candidate for both instances.
static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus1_fclk_1 },
{ .role = fclk_0, .clk = slimbus1_fclk_0 },
{ .role = fclk_2, .clk = slimbus1_fclk_2 },
{ .role = slimbus_clk, .clk = slimbus1_slimbus_clk },
};
static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
{ .role = fclk_1, .clk = slimbus2_fclk_1 },
{ .role = fclk_0, .clk = slimbus2_fclk_0 },
{ .role = slimbus_clk, .clk = slimbus2_slimbus_clk },
};
Jon,
Do you know if that one is indeed mandatory to use the slimbus IP?
Thanks,
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
[PATCH v3] omap: dmtimer: convert printk to pr_err
Convert a printk(KERN_ERR) message in the driver to pr_err().
v2:
* Replaced dump_stack() with WARN()
v3:
* Rebased against omap/master
Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index de7896f..5492ae1 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
while (!(__raw_readl(timer-sys_stat) 1)) {
c++;
if (c 10) {
- printk(KERN_ERR Timer failed to reset\n);
+ pr_err(Timer failed to reset\n);
return;
}
}
--
1.7.6.3
--
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/6 v3] omap: musb: Adding hwmod data for ti81xx
Hi, On Mon, Sep 26, 2011 at 03:21:07PM +0530, Gupta, Ajay Kumar wrote: To: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org; Balbi, Felipe; t...@atomide.com; B, Ravi; Cousson, Benoit; Gupta, Ajay Kumar Subject: [PATCH 1/6 v3] omap: musb: Adding hwmod data for ti81xx Felipe, I am planning to send patch 1/6 along with next revision of ti81xx hwmod baseport patch from Hemant so that all hwmod data gets reviewed at one place. So now only rest 5 (2/6 to 6/6) patches needs to be queued for usb. I hope this will be fine with you. Let me know if you want me to post Same 5 patches separately. I guess it's better to queue them separately. I will only take whatever lies in drivers/usb/musb -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/6 v3] omap: musb: Adding support for ti81xx
On Fri, Sep 09, 2011 at 07:17:46PM +0530, Ajay Kumar Gupta wrote: From: Ravi Babu ravib...@ti.com Added musb support for ti81xx platform which has two instances of musb interface and uses CPPI4.1 DMA. The current patch set adds support for single instance and in PIO mode only. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com Should go through OMAP tree: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/6 v3] omap: musb: ti81xx: Add phy power function
On Fri, Sep 09, 2011 at 07:17:47PM +0530, Ajay Kumar Gupta wrote:
Adding ti81xx_musb_phy_power() which will be used by musb driver through
its function pointer in board_data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
this should go through OMAP tree.
---
arch/arm/mach-omap2/omap_phy_internal.c | 24 +++
arch/arm/plat-omap/include/plat/usb.h | 32
+++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 58775e3..d5e8497 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -260,3 +260,27 @@ void am35x_set_mode(u8 musb_mode)
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
}
+
+void ti81xx_musb_phy_power(u8 on)
+{
+ u32 usbphycfg = omap_ctrl_readl(USBCTRL0);
+
+ if (on) {
+ if (cpu_is_ti816x()) {
+ usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
+ usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
+ } else if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN
+ | USBPHY_DPINPUT | USBPHY_DMINPUT);
+ usbphycfg |= (USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN
+ | USBPHY_DPOPBUFCTL | USBPHY_DMOPBUFCTL);
+ }
+ } else {
+ if (cpu_is_ti816x())
+ usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
+ else if (cpu_is_ti814x())
+ usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
+
+ }
+ omap_ctrl_writel(usbphycfg, USBCTRL0);
don't use omap_ctrl_*(). ioremap your memory space.
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 17d3c93..c616385 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -114,6 +114,7 @@ extern void am35x_musb_reset(void);
extern void am35x_musb_phy_power(u8 on);
extern void am35x_musb_clear_irq(void);
extern void am35x_set_mode(u8 musb_mode);
+extern void ti81xx_musb_phy_power(u8 on);
/*
* FIXME correct answer depends on hmc_mode,
@@ -273,6 +274,37 @@ static inline void omap2_usbfs_init(struct
omap_usb_config *pdata)
#define CONF2_OTGPWRDN (1 2)
#define CONF2_DATPOL (1 1)
+/* TI81XX specific definitions */
+#define USBCTRL0 0x620
+#define USBSTAT0 0x624
+
+/* TI816X PHY controls bits */
+#define TI816X_USBPHY0_NORMAL_MODE (1 0)
+#define TI816X_USBPHY_REFCLK_OSC (1 8)
+
+/* TI814X PHY controls bits */
+#define USBPHY_CM_PWRDN (1 0)
+#define USBPHY_OTG_PWRDN (1 1)
+#define USBPHY_CHGDET_DIS(1 2)
+#define USBPHY_CHGDET_RSTRT (1 3)
+#define USBPHY_SRCONDM (1 4)
+#define USBPHY_SINKONDP (1 5)
+#define USBPHY_CHGISINK_EN (1 6)
+#define USBPHY_CHGVSRC_EN(1 7)
+#define USBPHY_DMPULLUP (1 8)
+#define USBPHY_DPPULLUP (1 9)
+#define USBPHY_CDET_EXTCTL (1 10)
+#define USBPHY_GPIO_MODE (1 12)
+#define USBPHY_DPOPBUFCTL(1 13)
+#define USBPHY_DMOPBUFCTL(1 14)
+#define USBPHY_DPINPUT (1 15)
+#define USBPHY_DMINPUT (1 16)
+#define USBPHY_DPGPIO_PD (1 17)
+#define USBPHY_DMGPIO_PD (1 18)
+#define USBPHY_OTGVDET_EN(1 19)
+#define USBPHY_OTGSESSEND_EN (1 20)
+#define USBPHY_DATA_POLARITY (1 23)
+
#if defined(CONFIG_ARCH_OMAP1) defined(CONFIG_USB)
u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
u32 omap1_usb1_init(unsigned nwires);
--
1.6.2.4
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/6 v3] ti816evm: Add support for musb interface
Hi, On Fri, Sep 09, 2011 at 07:17:48PM +0530, Ajay Kumar Gupta wrote: From: Ravi Babu ravib...@ti.com Adding musb support in ti816 EVM board file. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com this looks ok, but should go through OMAP tree: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/6 v3] ti814evm: Add support for musb interface
On Fri, Sep 09, 2011 at 07:17:49PM +0530, Ajay Kumar Gupta wrote: From: Ravi Babu ravib...@ti.com Adding musb support in ti814 EVM board file. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Signed-off-by: Ravi Babu ravib...@ti.com similarly: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 6/6 v3] usb: musb: Add support for ti81xx platform
Hi, On Fri, Sep 09, 2011 at 07:17:50PM +0530, Ajay Kumar Gupta wrote: diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c new file mode 100644 index 000..fb59e34 --- /dev/null +++ b/drivers/usb/musb/musb_dsps.c @@ -0,0 +1,693 @@ +/* + * Texas Instruments DSPS platforms glue layer + * + * Copyright (C) 2011, by Texas Instruments + * + * Based on the am35x glue layer code. + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux is free software; you + * can redistribute it and/or modify it under the terms of the GNU + * General Public License version 2 as published by the Free Software + * Foundation. + * + * The Inventra Controller Driver for Linux is distributed in + * the hope that it will be useful, but WITHOUT ANY WARRANTY; + * without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public + * License for more details. + * + * You should have received a copy of the GNU General Public License + * along with The Inventra Controller Driver for Linux ; if not, + * write to the Free Software Foundation, Inc., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + * musb_dsps.c will be a common file for all the TI DSPS platforms + * such as dm64x, dm36x, dm35x, da8x, am35x and ti81x. + * For now only ti81x is using this and in future davinci.c, am35x.c + * da8xx.c would be merged to this file after testing. + */ + +#include linux/init.h +#include linux/io.h +#include linux/platform_device.h +#include linux/dma-mapping.h +#include linux/pm_runtime.h + +#include plat/usb.h can you avoid using plat/usb.h ?? Then we can compile on all architectures. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap3
Hi
On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
Thanks paul;
Now I am seeing that without OCPIF_SWSUP_IDLE the system is going to
low power mode but after
adding HWMOD_INIT_NO_RESET flag ; After adding this flag; I dint
check the system without this flag;
so, PRCM automatically idle this interface clock if UHH target port is
forced idle and force standby.
I can remove it now. :-)
Great. So I've cleaned up a few other issues in your patch, and the
following is what I plan to submit for upstream. Please review it to see
if there are any more changes which are needed.
regards
- Paul
From: Keshava Munegowda keshava_mgo...@ti.com
Date: Fri, 7 Oct 2011 02:40:51 -0600
Subject: [PATCH] arm: omap: usb: ehci and ohci hwmod structures for omap3
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
[p...@pwsan.com: dropped OCPIF_SWSUP_IDLE from interfaces; fixed whitespace;
updated to apply on Tony's cleanup branch; don't register on OMAP3430ES1;
rename 34xx in names to 3xxx; fixed multi-line comment style]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 217
1 files changed, 217 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..27d0ec4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap3xxx_usb_host_hs_hwmod;
+static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3123,6 +3125,214 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.class = omap34xx_mmc_class,
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap3xxx_usb_host_hs__l3_main_2 = {
+ .master = omap3xxx_usb_host_hs_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap3xxx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usb_host_hs_masters[] = {
+ omap3xxx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647ff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064cff,
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_usb_host_hs__ick = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_usb_host_hs_hwmod,
+ .clk= usbhost_ick,
+ .addr = omap3xxx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usb_host_hs_slaves[] = {
+ omap3xxx_usb_host_hs__ick,
+};
+
+static struct omap_hwmod_opt_clk omap3xxx_usb_host_hs_opt_clks[] = {
+ { .role = ehci_logic_fck, .clk = usbhost_120m_fck, },
+};
+
+static struct omap_hwmod_irq_info omap3xxx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 },
+ { .name = ehci-irq, .irq = 77 },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod omap3xxx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap3xxx_usb_host_hs_hwmod_class,
+
Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Hi
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- rebased to kernel version 3.0
- Workarounds for hardware issues
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
A few minor issues in this patch have been fixed. Please be careful with
whitespace and with multi-line comment style - see
Documentation/CodingStyle for more information.
- Paul
From fdf7c66244af5ca5ba4cdc820f7644efb9f6c1bf Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Fri, 7 Oct 2011 02:40:51 -0600
Subject: [PATCH] arm: omap: usb: ehci and ohci hwmod structures for omap4
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- rebased to kernel version 3.0
- Workarounds for hardware issues
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
[p...@pwsan.com: fixed whitespace, fixed multi-line comment style]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206 +++-
1 files changed, 205 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index caaf409..6149407 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,8 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5254,6 +5256,205 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x4a064800,
+ .pa_end = 0x4a064bff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x4a064c00,
+ .pa_end = 0x4a064fff,
+ },
+ {}
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .name = ehci-irq, .irq = 77 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_usb_host_hs_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = usb_host_hs,
+ .class = omap44xx_usb_host_hs_hwmod_class,
+
Re: [PATCH v5 1/3] AM35x: Using OMAP3 generic hwmods
Hi,
On Fri, 30 Sep 2011, Abhilash K V wrote:
From: Abhilash K V abhilash...@ti.com
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
I've dropped the mailbox class comments from this patch -- updated patch
below:
- Paul
From: Abhilash K V abhilash...@ti.com
Date: Fri, 7 Oct 2011 03:08:56 -0600
Subject: [PATCH] AM35x: Using OMAP3 generic hwmods
Removing modules iva, sr1_hwmod, sr2_hwmod, mailbox from
the base omap3xxx_hwmods list, so that they can be excluded
for am35x.
Signed-off-by: Abhilash K V abhilash...@ti.com
[p...@pwsan.com: dropped 'mailbox class' comments]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..ac12cd5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3132,7 +3132,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_mmc2_hwmod,
omap3xxx_mmc3_hwmod,
omap3xxx_mpu_hwmod,
- omap3xxx_iva_hwmod,
omap3xxx_timer1_hwmod,
omap3xxx_timer2_hwmod,
@@ -3161,8 +3160,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_i2c1_hwmod,
omap3xxx_i2c2_hwmod,
omap3xxx_i2c3_hwmod,
- omap34xx_sr1_hwmod,
- omap34xx_sr2_hwmod,
/* gpio class */
omap3xxx_gpio1_hwmod,
@@ -3184,8 +3181,6 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_mcbsp2_sidetone_hwmod,
omap3xxx_mcbsp3_sidetone_hwmod,
- /* mailbox class */
- omap3xxx_mailbox_hwmod,
/* mcspi class */
omap34xx_mcspi1,
@@ -3198,31 +3193,39 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[]
= {
/* 3430ES1-only hwmods */
static __initdata struct omap_hwmod *omap3430es1_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3430es1_dss_core_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 3430ES2+-only hwmods */
static __initdata struct omap_hwmod *omap3430es2plus_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3xxx_dss_core_hwmod,
omap3xxx_usbhsotg_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 34xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap34xx_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap34xx_sr1_hwmod,
omap34xx_sr2_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
/* 36xx-only hwmods (all ES revisions) */
static __initdata struct omap_hwmod *omap36xx_hwmods[] = {
+ omap3xxx_iva_hwmod,
omap3xxx_uart4_hwmod,
omap3xxx_dss_core_hwmod,
omap36xx_sr1_hwmod,
omap36xx_sr2_hwmod,
omap3xxx_usbhsotg_hwmod,
+ omap3xxx_mailbox_hwmod,
NULL
};
--
1.7.6.3
--
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: PRCM/SCM/hwmod miscellaneous fixes for 3.2
Hi Tony, The following changes since commit be73246058737beec52ae232bcab7776332a9e06: ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 prcm_scm_misc_fixes_3.2 Abhilash K V (1): ARM: OMAP: AM35x: remove hwmods that aren't generic Archit Taneja (1): ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields .../include/mach/ctrl_module_pad_core_44xx.h |8 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 - 2 files changed, 12 insertions(+), 9 deletions(-) - 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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Fri, Oct 7, 2011 at 2:36 PM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Thu, 6 Oct 2011, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- rebased to kernel version 3.0
- Workarounds for hardware issues
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
A few minor issues in this patch have been fixed. Please be careful with
whitespace and with multi-line comment style - see
Documentation/CodingStyle for more information.
Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please confirm.
I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed.
Thanks for guiding me and helping on the finalizing the hwmod configurations.
regards
keshava
- Paul
From fdf7c66244af5ca5ba4cdc820f7644efb9f6c1bf Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Fri, 7 Oct 2011 02:40:51 -0600
Subject: [PATCH] arm: omap: usb: ehci and ohci hwmod structures for omap4
Following 2 hwmod structures are added
1. usb_host_hs
The hwmod of usbhs with uhh, ehci and ohci base addresses
functional clock and ehci, ohci irqs
2. usb_tll_hs
hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson b-cous...@ti.com
- rebased to kernel version 3.0
- Workarounds for hardware issues
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
[p...@pwsan.com: fixed whitespace, fixed multi-line comment style]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206
+++-
1 files changed, 205 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index caaf409..6149407 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,8 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5254,6 +5256,205 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = omap44xx_usb_host_hs_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk = l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields = omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = usb_host_hs,
+ .sysc = omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = uhh,
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = ohci,
+ .pa_start = 0x4a064800,
+ .pa_end = 0x4a064bff,
+ },
+ {
+ .name = ehci,
+ .pa_start = 0x4a064c00,
+ .pa_end = 0x4a064fff,
+ },
+ {}
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+ { .name = ohci-irq, .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .name = ehci-irq, .irq = 77 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave =
Re: [PATCH v3] omap: dmtimer: convert printk to pr_err
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
Convert a printk(KERN_ERR) message in the driver to pr_err().
...
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
while (!(__raw_readl(timer-sys_stat) 1)) {
c++;
if (c 10) {
- printk(KERN_ERR Timer failed to reset\n);
+ pr_err(Timer failed to reset\n);
What is the reason behind this change? It looks like it's to use the
latest and greatest function.
If so, please don't make these changes - we have on many occasions been
blamed for size of diffstat, churn, needless change, and this patch is
exactly that.
By all means fix printk's without KERN_ constants, possibly converting
them to pr_*, but don't go around replacing printk(KERN_* with pr_*(
without ensuring that there's a real benefit to the change.
--
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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Fri, 7 Oct 2011, Munegowda, Keshava wrote: Thanks Paul; yes, I can your changes in the patches. so, you don't need v14 from me right? please confirm. I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed. Thanks for guiding me and helping on the finalizing the hwmod configurations. The first two patches of the series -- the OMAP3/4 hwmod data patches -- have been queued for 3.2 in the 'hwmod_devel_3.2' branch of git://git.pwsan.com/linux-2.6 So we don't need new versions of those two. But we need to figure out what to do about the remaining three patches. I still think that the TLL and UHH hwmods should have separate drivers. Looks like Felipe has a question pending about that but it's unlikely that I'll have time to dig into it for at least a few days. So I'd encourage you to try splitting those UHH and TLL drivers in the meantime. - 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 1/3] am335xevm: Add support for musb interface
Hi, On Mon, Sep 26, 2011 at 03:33:11PM +0530, Ajay Kumar Gupta wrote: Adding musb support in am335x EVM board file. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com should go through OMAP tree: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] arm: omap: am335x: enable phy controls
Hi, On Mon, Sep 26, 2011 at 03:33:12PM +0530, Ajay Kumar Gupta wrote: Switch on the phy for am335x. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com should go through OMAP tree: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] usb: musb: enable support for am335x
Hi, On Mon, Sep 26, 2011 at 02:47:11PM +0400, Sergei Shtylyov wrote: Hello. On 26-09-2011 14:03, Ajay Kumar Gupta wrote: Enabled the flag so that musb_dsps glue file can be used for am335x Signed-off-by: Ajay Kumar Guptaajay.gu...@ti.com --- drivers/usb/musb/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index d6abdec..4e21aee 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -8,7 +8,7 @@ config USB_MUSB_HDRC depends on USB USB_GADGET depends on (ARM || (BF54x !BF544) || (BF52x !BF522 !BF523)) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) -select NOP_USB_XCEIV if SOC_OMAPTI81XX +select NOP_USB_XCEIV if (SOC_OMAPTI81XX || SOC_OMAPAM33XX) select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA select USB_OTG_UTILS @@ -57,7 +57,7 @@ config USB_MUSB_AM35X config USB_MUSB_DSPS tristate TI DSPS platforms -depends on SOC_OMAPTI81XX +depends on (SOC_OMAPTI81XX || SOC_OMAPAM33XX) Parens not needed here and above. are we getting a revised version ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] drivercore: add new error value for deferred probe
On Thu, Oct 06, 2011 at 11:43:49PM -0700, Greg KH wrote: On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote: +#define EPROBE_DEFER 517 /* restart probe again after some time */ Can we really do this? Isn't this some user/kernel api here? What's wrong with just overloading on top of an existing error code? Surely one of the other 516 types could be used here, right? There was some discussion of this in the previous patch round before the code was changed - it does end up adding an externally visible error code but it doesn't really make any difference, especially if we don't propagate it externally. We've already got some other codes in a similar style, though I can't remember the examples that were quoted offhand. Adding the new code avoids confusion about exactly what the intent of the driver is. -- 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: OMAP4 PM: Add IO Daisychain support
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, October 07, 2011 1:44 PM
To: Vishwanath BS
Cc: linux-omap@vger.kernel.org; khil...@ti.com; linux-arm-
ker...@lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH 2/4] ARM: OMAP4 PM: Add IO Daisychain support
Hi
some comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in
OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 36
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 9a36a7c..2e09d72 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state);
extern int omap3_idle_init(void);
extern void omap3_enable_io_chain(void);
+extern void omap4_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-
omap2/pm44xx.c
index 59a870b..aa7cff4 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -16,8 +16,17 @@
#include linux/err.h
#include linux/slab.h
+#include plat/common.h
+
#include powerdomain.h
#include mach/omap4-common.h
+#include pm.h
+#include cm-regbits-44xx.h
+#include cminst44xx.h
+#include prm-regbits-44xx.h
+#include prcm44xx.h
+#include prm44xx.h
+#include prminst44xx.h
struct power_state {
struct powerdomain *pwrdm;
@@ -30,6 +39,33 @@ struct power_state {
static LIST_HEAD(pwrst_list);
+#define MAX_IOPAD_LATCH_TIME 1000
This macro is missing a comment, which should precede it, describing
what
this value is.
OK
+
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!omap4_cminst_read_inst_reg_bits(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET,
+ OMAP4430_GLOBAL_WUEN_MASK))
The above line doesn't look right. It's accessing a PRM instance
register
with omap4_cminst_*()? Shouldn't that be omap4_prminst_*()?
Ya, it would make sense to use omap4_prminst_* though functionally both
have the same effect.
+
omap4_prminst_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ ((omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
+OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+ MAX_IOPAD_LATCH_TIME, i);
+ /* Trigger WUCLKIN disable */
+ omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
This function belongs in mach-omap2/prminst44xx.c. I still think it
would
be good if we moved all PRM/CM direct register accesses into prm*.c
or
cm*.c files in mach-omap2/. Then none of those prm*.h includes
would be
needed in pm44xx.c either.
OK. Let me explore that.
Regards
Vishwa
+
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
{
--
1.7.0.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
- 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 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, October 07, 2011 1:50 PM
To: Vishwanath BS
Cc: linux-omap@vger.kernel.org; khil...@ti.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
Hi
a few comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for
enabling IO Daisy
chain is The I/O wake-up scheme is enabled by triggering the I/O
daisy chain
control (Wu clock) by programming a dedicated register
(PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software
must wait for
the I/O daisy chain to complete before it transitions the PER
domain to a
nonfunctional state. This is done by polling a dedicated status
bit in the PRCM
module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must
be cleared by
software when the bit is read to 1.
The original code was polling on a wrong register which is fixed
in this patch.
Also omap3_enable_io_chain is made non static as it's going to be
used in
subsequent patches.
This patch should be split into a fix (for the WKEN/WKST bug) and
then a
new patch that drops the 'static'. The new patch should also move
this
function to prm2xxx_3xxx.c for the same reason that the OMAP4
version of
this function should be in prminst44xx.c.
OK, Understood.
In the medium-term, a bunch of the functions from prm2xxx_3xxx.c,
prminst44xx.c, etc. that are only used by the mach-omap2/pm*.c code
should
be moved into the PRM driver that Tero is working on that will live
in
drivers/.
OK.
Vishwa
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c |6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..9a36a7c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state);
extern int omap3_idle_init(void);
+extern void omap3_enable_io_chain(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-
omap2/pm34xx.c
index 7255d9b..61f1a5b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -95,7 +95,7 @@ static inline void
omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
+void omap3_enable_io_chain(void)
{
int timeout = 0;
@@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN)
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
@@ -114,7 +114,7 @@ static void omap3_enable_io_chain(void)
return;
}
omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
-WKUP_MOD, PM_WKEN);
+WKUP_MOD, PM_WKST);
}
}
}
--
1.7.0.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
- 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 4/5] gpiolib: handle deferral probe error
On Fri, 07 Oct 2011 10:33:09 +0500 G, Manjunath Kondaiah manj...@ti.com wrote: The gpio library should return -EPROBE_DEFER in gpio_request if gpio driver is not ready. Why not use the perfectly good existing error codes we have for this ? We have EAGAIN and EUNATCH both of which look sensible. -- 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 7 Oct 2011, Munegowda, Keshava wrote: Thanks Paul; yes, I can your changes in the patches. so, you don't need v14 from me right? please confirm. I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed. Thanks for guiding me and helping on the finalizing the hwmod configurations. The first two patches of the series -- the OMAP3/4 hwmod data patches -- have been queued for 3.2 in the 'hwmod_devel_3.2' branch of git://git.pwsan.com/linux-2.6 So we don't need new versions of those two. But we need to figure out what to do about the remaining three patches. I still think that the TLL and UHH hwmods should have separate drivers. Looks like Felipe has a question pending about that but it's unlikely that I'll have time to dig into it for at least a few days. So I'd encourage you to try splitting those UHH and TLL drivers in the meantime. some time last week; I had a discussion with Felipe and he is ok to have current design as it is for now; But, he wants to redesign this driver with UHH and TLL as two platform drivers. I will have discussion with Felipe and Partha to redesign it soon. 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 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 7 Oct 2011, Munegowda, Keshava wrote: Thanks Paul; yes, I can your changes in the patches. so, you don't need v14 from me right? please confirm. I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed. Thanks for guiding me and helping on the finalizing the hwmod configurations. The first two patches of the series -- the OMAP3/4 hwmod data patches -- have been queued for 3.2 in the 'hwmod_devel_3.2' branch of git://git.pwsan.com/linux-2.6 Ok, then I will host a tree for remaining three patches and another last patch for MFD tree. regards keshava So we don't need new versions of those two. But we need to figure out what to do about the remaining three patches. I still think that the TLL and UHH hwmods should have separate drivers. Looks like Felipe has a question pending about that but it's unlikely that I'll have time to dig into it for at least a few days. So I'd encourage you to try splitting those UHH and TLL drivers in the meantime. - 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] omap: dmtimer: convert printk to pr_err
On Fri, Oct 07, 2011 at 10:22:43AM +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
Convert a printk(KERN_ERR) message in the driver to pr_err().
...
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
while (!(__raw_readl(timer-sys_stat) 1)) {
c++;
if (c 10) {
- printk(KERN_ERR Timer failed to reset\n);
+ pr_err(Timer failed to reset\n);
What is the reason behind this change? It looks like it's to use the
latest and greatest function.
If so, please don't make these changes - we have on many occasions been
blamed for size of diffstat, churn, needless change, and this patch is
exactly that.
By all means fix printk's without KERN_ constants, possibly converting
them to pr_*, but don't go around replacing printk(KERN_* with pr_*(
without ensuring that there's a real benefit to the change.
Thanks a lot Russell, and sorry for the noise. I'm still learning how to
collaborate in the kernel.
vmjl
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.1-rc3] gpio/omap: fix build error with certain OMAP1 configs
Dnia wtorek, 23 sierpnia 2011 o 19:11:47 Kevin Hilman napisał(a): Janusz Krzysztofik jkrzy...@tis.icnet.pl writes: With commit f64ad1a0e21a, gpio/omap: cleanup _set_gpio_wakeup(), remove ifdefs, access to build time conditionally omitted 'suspend_wakeup' member of the 'gpio_bank' structure has been placed unconditionally in function _set_gpio_wakeup(), which is always built. This resulted in the driver compilation broken for certain OMAP1, i.e., non-OMAP16xx, configurations. Really required or not in previously excluded cases, define this structure member unconditionally as a fix. Tested with a custom OMAP1510 only configuration. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl Verified that this fixes a build problem when building for OMAP1 (730/850 only) Acked-by: Kevin Hilman khil...@ti.com Grant, can you queue this as a fix for 3.1-rc? Hi, Sorry for being so late with checking this, but it looks like this patch never got into 3.1-rc, as it should, leaving the issue not fixed. Any chance for it still being pushed into 3.1? Thanks, Janusz -- 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 2/3] ARM: OMAP: TI814X: Add cpu type macros and detection support
Hi Paul, linux-arm-kernel-boun...@lists.infradead.org wrote on : macros and detection support Hi Paul, Paul Walmsley wrote on Friday, September 30, 2011 2:17 AM: Hello Hemant, a few comments: On Thu, 29 Sep 2011, Hemant Pedanekar wrote: [...] Note that following update to common OMAP data structures is made: cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: Hemant Pedanekar hema...@ti.com Also, the opp2xxx.h change looks spurious, is that really needed? I will be removing the above mentioned code changes from v4 since the same were added in arm:omap:am33xx: Update common omap platform files patch and as per Tony's reply today ([1]) the am33xx patch will be added to SoC branch. Thanks. Hemant [1] http://www.spinics.net/lists/linux-omap/msg58853.html I changed prcm_config.flags to accommodate cpu_mask change, as cpu_mask is used with prcm_config.flags (mostly) in clkt2xxx_virt_prcm_set.c as below: prcm-flags cpu_mask And flags is assigned in opp2420_data.c (e.g., RATE_IN_242X) But yes, these are already defined RATE_INs and do not cross 8-bits, so no warnings even if flags is 8-bit and cpu_mask changed to 16-bit. What is your suggestion? I see you mentioned Also in the above comment, but didn't see any comment preceeding. Could you please split the clock-related changes into a separate patch? Then this patch would just be the id.c and cpu.h changes. Other than that, the patch looks okay to me. - Paul Will do that. Thanks. Hemant ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel-- 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/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Fri, Oct 7, 2011 at 4:13 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 7 Oct 2011, Munegowda, Keshava wrote: Thanks Paul; yes, I can your changes in the patches. so, you don't need v14 from me right? please confirm. I am preparing/validating next version patches with OCPIF_SWSUP_IDLE removed. Thanks for guiding me and helping on the finalizing the hwmod configurations. The first two patches of the series -- the OMAP3/4 hwmod data patches -- have been queued for 3.2 in the 'hwmod_devel_3.2' branch of git://git.pwsan.com/linux-2.6 Ok, then I will host a tree for remaining three patches and another last patch for MFD tree. Hi Felipe and Sameo The patches are available in the branch kmg-usbhs-pm of git repository: g...@gitorious.org:~kmg/mirrors/kmg-usbhs-pm.git if you have review comment on v13 of these series; please let me know. so I that I will make the changes in time. regards keshava So we don't need new versions of those two. But we need to figure out what to do about the remaining three patches. I still think that the TLL and UHH hwmods should have separate drivers. Looks like Felipe has a question pending about that but it's unlikely that I'll have time to dig into it for at least a few days. So I'd encourage you to try splitting those UHH and TLL drivers in the meantime. - 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 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:06]:
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:26]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
Why don't we allow user to pass the mtype here ?
Well we want to keep the MT_MEMORY types out of asm/io.h.
We do have a need also to map a page of DDR and SRAM as
strongly ordered for errata fix and this interface can be
used for that.
Yeah..
Ofcourse, SO memory type is not executable memories, so the
API name might be miss-leading.
..so I think we should just have a separate static mapping for
the omap4 errata fix SO page, and just limit the memory available
for SRAM code to ioremap.
How does that sounds to you?
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 0/4] initialize omap SRAM later on with __arm_ioremap_exec()
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:25]: On Thursday 06 October 2011 07:12 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [111004 23:29]: Will look at this series in next couple of days and do some testing. Thanks, turns out there were a few issues with early ioremap that I fixed. Care to check the L4_IO_ADDRESS changes? They look ok to me. Thanks for testing. It's all pushed now into sram-map-io branch at: https://github.com/tmlind/linux/tree/sram-map-io It seems it's booting now on all omaps I've tried, so will merge it into linux-omap master branch as well for testing. I have reviewed and tested this series. No problems seen. As asked on other thread, if you are targeting this one for 3.2, then sram changes would have a small conflict with OMAP4 errata patch. If it is for 3.3, we should be able to sort out that conflict easily. Yeah let's if we can map the errata fix page separately. 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 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:22]: The changes looks fine to me. Though the ugly hard-coding is back with it, it's a step towards generic_io, so hopefully it won't have to stay for long time. Nico please correct me if I'm wrong, but I think that with generic map_io we have static mappings in place after map_io, and then ioremap should work for the static mappings right after map_io except without the need for __arch_ioremap. 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 4/4] ARM: OMAP: Map SRAM later on with ioremap_exec()
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:18]: Are you considering this change for 3.2? I think we should as this is blocking development for generic map_io and genalloc changes for SRAM code. OMAP4 errata WA would have a conflict with the change is sram code and hence the question ? Right, let's see if we can fix that with a static mapping. 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 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:06]:
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111004 17:26]:
On Tue, 4 Oct 2011, Tony Lindgren wrote:
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
Why don't we allow user to pass the mtype here ?
Well we want to keep the MT_MEMORY types out of asm/io.h.
ok.
We do have a need also to map a page of DDR and SRAM as
strongly ordered for errata fix and this interface can be
used for that.
Yeah..
Ofcourse, SO memory type is not executable memories, so the
API name might be miss-leading.
..so I think we should just have a separate static mapping for
the omap4 errata fix SO page, and just limit the memory available
for SRAM code to ioremap.
How does that sounds to you?
That's more or less what the patch is already doing.
Instead of static mapping, I was dynamically stealing one
page ( SZ_4K) and mapping it as MT_MEMORY_SO and rest
of the memory as MT_MEMORY for OMAP4.
It should be doable with your updates as well,
I guess with or without static mapping since the only
requisite is to keep one page of SRAM free on OMAP4 and
them map them using iotable_init() with MT_MEMORY_SO.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
* Santosh Shilimkar santosh.shilim...@ti.com [111007 07:29]:
On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
..so I think we should just have a separate static mapping for
the omap4 errata fix SO page, and just limit the memory available
for SRAM code to ioremap.
How does that sounds to you?
That's more or less what the patch is already doing.
Instead of static mapping, I was dynamically stealing one
page ( SZ_4K) and mapping it as MT_MEMORY_SO and rest
of the memory as MT_MEMORY for OMAP4.
Yeah cool.
It should be doable with your updates as well,
I guess with or without static mapping since the only
requisite is to keep one page of SRAM free on OMAP4 and
them map them using iotable_init() with MT_MEMORY_SO.
How about something like the following, this won't compile
without at least moving the defines around a bit, but shows
what I had in mind:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,6 +238,14 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.length = L4_EMU_44XX_SIZE,
.type = MT_DEVICE,
},
+#ifdef CONFIG_OMAP4_ERRATA_I688
+ {
+ .virtual= OMAP4_SRAM_VA,
+ .pfn= __phys_to_pfn(OMAP4_SRAM_PA),
+ .length = PAGE_SIZE,
+ .type = MT_MEMORY_SO,
+ },
+#endif
};
#endif
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -125,6 +125,9 @@ static void __init omap_detect_sram(void)
omap_sram_size = 0x1; /* 64K */
} else if (cpu_is_omap44xx()) {
omap_sram_start = OMAP4_SRAM_PA;
+#ifdef CONFIG_OMAP4_ERRATA_I688
+ omap_sram_start += PAGE_SIZE;
+#endif
omap_sram_size = 0xe000; /* 56K */
} else {
omap_sram_start = OMAP2_SRAM_PA;
Eventually the SRAM code will be a generic driver, so let's try
to keep the errata fix out of the SRAM code.
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 8/8] OMAP3: powerdomain data: add wake-up latency figures
Hi Jean
On Wed, 21 Sep 2011, jean.pi...@newoldbits.com wrote:
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf.
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers magically coming from.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
A few more question about these numbers.
- Are these numbers the ones right off the hardware, or rounded, or
worst-case plus a certain percentage?
- What frequency/voltage were these measured at?
- Also, you mention OMAP3 Beagleboard. Is that 34xx or 36xx Beagleboard?
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 78
+++
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index 469a920..32922bb 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -31,6 +31,14 @@
/*
* Powerdomains
+ *
+ * The wakeup_lat values are derived from measurements on
+ * the actual target.
+ *
+ * Note: the latency figures for MPU, PER, CORE, NEON have been obtained
+ * from actual measurements.
+ * The latency figures for the other power domains are preliminary and
+ * shall be added.
*/
static struct powerdomain iva2_pwrdm = {
@@ -52,6 +60,13 @@ static struct powerdomain iva2_pwrdm = {
[2] = PWRSTS_OFF_ON,
[3] = PWRSTS_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1100,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 350,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain mpu_3xxx_pwrdm = {
@@ -68,6 +83,13 @@ static struct powerdomain mpu_3xxx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_OFF_ON,
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1830,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 121,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/*
@@ -98,6 +120,13 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 3082,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 153,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain core_3xxx_es3_1_pwrdm = {
@@ -121,6 +150,13 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {
[0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
[1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 3082,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 153,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain dss_pwrdm = {
@@ -136,6 +172,13 @@ static struct powerdomain dss_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 70,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 20,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
/*
@@ -157,6 +200,13 @@ static struct powerdomain sgx_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 1000,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+ },
};
static struct powerdomain cam_pwrdm = {
@@ -172,6 +222,13 @@ static struct powerdomain cam_pwrdm = {
.pwrsts_mem_on= {
[0] = PWRSTS_ON, /* MEMONSTATE */
},
+ .wakeup_lat = {
+ [PWRDM_FUNC_PWRST_OFF] = 850,
+ [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_CSWR] = 35,
+ [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE,
+ [PWRDM_FUNC_PWRST_ON] = 0,
+
Re: ARM SoC tree: OMAP PM dependency on tip irq/core
On Thursday 06 October 2011, Tony Lindgren wrote: * Rob Herring robherri...@gmail.com [111001 13:21]: On 09/30/2011 05:29 PM, Kevin Hilman wrote: Hi Arnd, Kevin Hilman khil...@ti.com writes: The upcoming OMAP4 PM series from Santosh[1] that we're planning to queue for v3.2 has a dependency[2] on a patch currently queued for v3.2 in the irq/core branch of Thomas' tip tree[3]. In the past, I noticed you merged external trees like this to solve dependencies. Could you pull the irq/core branch into your tree to meet this dependency? On second thought, since Santosh's branch is the only one with this dependency (and we also have a dependency on Russell's devel-stable) I'll just build up a branch for Santosh's series that includes rmk/devel-stable and tglx/irq-core. Any new platforms will have a dependency on rmk/devel-stable with the mach header clean-up. I'll probably have a dependency on tglx's tree as well. Sounds like Arnd should pull this into some branch then. I've pulled in rmk/devel-stable as a dependency now, thanks for reminding me of that. Thomas, where should I get the irq-core branch (or whichever I should wait for) to pull in as another dependency. Is that branch one that never gets rebased? Arnd -- 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/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
On Friday 07 October 2011 08:41 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111007 07:29]:
On Friday 07 October 2011 08:13 PM, Tony Lindgren wrote:
..so I think we should just have a separate static mapping for
the omap4 errata fix SO page, and just limit the memory available
for SRAM code to ioremap.
How does that sounds to you?
That's more or less what the patch is already doing.
Instead of static mapping, I was dynamically stealing one
page ( SZ_4K) and mapping it as MT_MEMORY_SO and rest
of the memory as MT_MEMORY for OMAP4.
Yeah cool.
It should be doable with your updates as well,
I guess with or without static mapping since the only
requisite is to keep one page of SRAM free on OMAP4 and
them map them using iotable_init() with MT_MEMORY_SO.
How about something like the following, this won't compile
without at least moving the defines around a bit, but shows
what I had in mind:
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -238,6 +238,14 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
.length = L4_EMU_44XX_SIZE,
.type = MT_DEVICE,
},
+#ifdef CONFIG_OMAP4_ERRATA_I688
+ {
+ .virtual= OMAP4_SRAM_VA,
+ .pfn= __phys_to_pfn(OMAP4_SRAM_PA),
+ .length = PAGE_SIZE,
+ .type = MT_MEMORY_SO,
+ },
+#endif
};
I initially tried some thing similar but the issue was GP and
HS devices. SRAM_PA isn't same on GP and EMU device and hence
did that dynamically. One way is I can make GP and HS
device SRAM_PA same for OMAP4 (Will loose 16 KB of
SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM
for OMAP4 with errata enabled.
Below change works on both GP and HS device
If you are OK with it, I can update errata patch accordingly.
diff --git a/arch/arm/plat-omap/include/plat/sram.h
b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..111b1a8 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -95,6 +95,11 @@ static inline void omap_push_sram_idle(void) {}
*/
#define OMAP2_SRAM_PA 0x4020
#define OMAP3_SRAM_PA 0x4020
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PA 0x40304000
+#else
#define OMAP4_SRAM_PA 0x4030
+#endif
+#define OMAP4_SRAM_VA 0xfe404000
#endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 363c91e..cdd303f 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -48,9 +48,13 @@
#define OMAP3_SRAM_VA 0xfe40
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_VA 0xfe40
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
+#define OMAP4_SRAM_PUB_VA OMAP4_SRAM_VA
+#else
#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
#define OMAP4_SRAM_PUB_VA (OMAP4_SRAM_VA + 0x4000)
+#endif
#if defined(CONFIG_ARCH_OMAP2PLUS)
#define SRAM_BOOTLOADER_SZ 0x00
@@ -203,6 +207,11 @@ static void __init omap_map_sram(void)
if (omap_sram_size == 0)
return;
+#ifdef CONFIG_OMAP4_ERRATA_I688
+ omap_sram_base += PAGE_SIZE;
+ omap_sram_start += PAGE_SIZE;
+ omap_sram_size -= SZ_16K;
+#endif
if (cpu_is_omap34xx()) {
/*
* SRAM must be marked as non-cached on OMAP3 since the
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] omap: dmtimer: convert printk to pr_err
On Fri, 2011-10-07 at 10:22 +0100, Russell King - ARM Linux wrote:
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
Convert a printk(KERN_ERR) message in the driver to pr_err().
...
@@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
while (!(__raw_readl(timer-sys_stat) 1)) {
c++;
if (c 10) {
- printk(KERN_ERR Timer failed to reset\n);
+ pr_err(Timer failed to reset\n);
What is the reason behind this change? It looks like it's to use the
latest and greatest function.
Hi Russell
I'm not promoting this patch, just commenting.
At some point in the next couple of years, I want
to convert all of, or as many as possible of, the
remaining printk uses to pr_level.
This would allow finer grained control over the
prefixing of KBUILD_MODNAME and __func__, and
could possibly make the kernel image smaller.
Today, arch/arm has ~3:1 ratio of printk to pr_level.
grep shows 1427 printks, 468 pr_level, 405 pr_debug's.
If so, please don't make these changes - we have on many occasions been
blamed for size of diffstat, churn, needless change, and this patch is
exactly that.
True.
These trivial changes could wait until arch/arm settles
down a bit more.
By all means fix printk's without KERN_ constants,
There's still more than 250 of those in arch/arm.
Even more with the uses of secondary things like:
#define PRINTK(x...) (foo printk(x))
possibly converting
them to pr_*, but don't go around replacing printk(KERN_* with pr_*(
without ensuring that there's a real benefit to the change.
Style consistency patches do need to be governed by
acceptable churn rate.
--
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: ARM SoC tree: OMAP PM dependency on tip irq/core
Arnd Bergmann a...@arndb.de writes: On Thursday 06 October 2011, Tony Lindgren wrote: * Rob Herring robherri...@gmail.com [111001 13:21]: On 09/30/2011 05:29 PM, Kevin Hilman wrote: Hi Arnd, Kevin Hilman khil...@ti.com writes: The upcoming OMAP4 PM series from Santosh[1] that we're planning to queue for v3.2 has a dependency[2] on a patch currently queued for v3.2 in the irq/core branch of Thomas' tip tree[3]. In the past, I noticed you merged external trees like this to solve dependencies. Could you pull the irq/core branch into your tree to meet this dependency? On second thought, since Santosh's branch is the only one with this dependency (and we also have a dependency on Russell's devel-stable) I'll just build up a branch for Santosh's series that includes rmk/devel-stable and tglx/irq-core. Any new platforms will have a dependency on rmk/devel-stable with the mach header clean-up. I'll probably have a dependency on tglx's tree as well. Sounds like Arnd should pull this into some branch then. I've pulled in rmk/devel-stable as a dependency now, thanks for reminding me of that. Thomas, where should I get the irq-core branch (or whichever I should wait for) to pull in as another dependency. Is that branch one that never gets rebased? git://tesla.tglx.de/git/linux-2.6-tip irq/core I asked Thomas about this earlier when I was going to build up the dependencies myself, and he said it won't be rebased. 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
[PATCHv2 4/7] ARM: OMAP3 PM: Enable IO Wake up
Enable IO Wake up for OMAP3 as part of PM Init.
Currently this has been managed in cpuidle path which is not the right place.
Subsequent patch will remove IO Daisy chain handling in cpuidle path once daisy
chain is handled as part of hwmod mux.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 352ad3c..c282552 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -854,6 +854,9 @@ static int __init omap3_pm_init(void)
goto err1;
}
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
+
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
--
1.7.0.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
[PATCHv2 0/7]ARM: OMAP3PLUS PM: Add IO DaisyChain support via hwmod mux
The folowing patch series provides IO Daisychain feature via omap hwmod mux framework. The patch series has been generated against 3.1 rc9 and tested on OMAP3 Platform (ZOOM3 and OMAP3430 SDP) for Retentiona and OFF mode in suspend/cpuidle path. Tested on OMAP4 using [1] as OMAP4 Core PM is not yet supported mainline. [1]: git://gitorious.org/omap-pm/linux.git omap4_core_pm Also tested against latest UART Runtime with Chain Handler patches [1]. [2]: git://gitorious.org/runtime_3-0/runtime_3-0.git v6_uart_runtime Mohan V (1): ARM: OMAP3 PM: correct enable/disable of daisy io chain Rajendra Nayak (1): ARM: OMAP4 PM: Add IO Daisychain support Vishwanath BS (5): ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file ARM: OMAP3 PM: Enable IO Wake up ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle ARM: OMAP3 PM: Enable IO Daisychain for supported chips arch/arm/mach-omap2/omap_hwmod.c |9 +- arch/arm/mach-omap2/pm.c | 11 arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm34xx.c | 49 ++- arch/arm/mach-omap2/prm2xxx_3xxx.c | 27 +++ arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++ arch/arm/mach-omap2/prm44xx.c | 33 arch/arm/mach-omap2/prm44xx.h |1 + 8 files changed, 97 insertions(+), 48 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 7/7] ARM: OMAP3 PM: Enable IO Daisychain for supported chips
IO Daisychain has to be enabled only if the corresponding omap has
io wake up capability.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 0c70bc4..9a92fef 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -168,7 +168,7 @@ void omap3_trigger_wuclk_ctrl(void)
{
int i = 0;
- if (omap_rev() = OMAP3430_REV_ES3_1) {
+ if ((omap_rev() = OMAP3430_REV_ES3_1) omap3_has_io_wakeup()) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
PM_WKEN);
/* Do a readback to assure write has been done */
--
1.7.0.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
[PATCHv2 1/7] ARM: OMAP3 PM: correct enable/disable of daisy io chain
From: Mohan V moh...@ti.com
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain according to the Sec 3.5.7.2.2
I/O Wake-Up Mechanism in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V moh...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..041f6e6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
/* Do a readback to assure write has been done */
omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN)
+ while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
OMAP3430_ST_IO_CHAIN_MASK)) {
timeout++;
if (timeout 1000) {
@@ -113,9 +113,9 @@ static void omap3_enable_io_chain(void)
activation failed.\n);
return;
}
- omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
-WKUP_MOD, PM_WKEN);
}
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
+PM_WKEN);
}
}
--
1.7.0.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
[PATCHv2 6/7] ARM: OMAP3 PM: Remove IO Daisychain control from cpuidle
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 15 ---
arch/arm/mach-omap2/prm2xxx_3xxx.c |8
2 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c282552..ea78d72 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -341,12 +341,6 @@ void omap_sram_idle(void)
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- omap3_trigger_wuclk_ctrl();
- }
/* Block console output in case it is on one of the OMAP UARTs */
if (!is_suspending())
@@ -438,15 +432,6 @@ void omap_sram_idle(void)
console_unlock();
console_still_active:
- /* Disable IO-PAD and IO-CHAIN wakeup */
- if (omap3_has_io_wakeup()
- (per_next_state PWRDM_POWER_ON ||
-core_next_state PWRDM_POWER_ON)) {
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
-PM_WKEN);
- omap3_disable_io_chain();
- }
-
pwrdm_post_transition();
clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 915d726..0c70bc4 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -183,11 +183,3 @@ void omap3_trigger_wuclk_ctrl(void)
PM_WKEN);
}
}
-
-/* OMAP3 Daisychain disable sequence */
-void omap3_disable_io_chain(void)
-{
- if (omap_rev() = OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
- PM_WKEN);
-}
--
1.7.0.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
[PATCHv2 3/7] ARM: OMAP4 PM: Add IO Daisychain support
From: Rajendra Nayak rna...@ti.com
patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
Public TRM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/prm44xx.c | 33 +
arch/arm/mach-omap2/prm44xx.h |1 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 0016555..7e19678 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -23,6 +23,8 @@
#include prm44xx.h
#include prm-regbits-44xx.h
+#include prcm44xx.h
+#include prminst44xx.h
/* PRM low-level functions */
@@ -50,3 +52,34 @@ u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16
inst, s16 reg)
return v;
}
+
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ /* Enable GLOBAL_WUEN */
+ if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET)
+OMAP4430_GLOBAL_WUEN_MASK))
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+ OMAP4430_GLOBAL_WUEN_MASK,
OMAP4430_PRM_DEVICE_INST,
+ OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+ /* Trigger WUCLKIN enable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap_test_timeout(
+ ((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_PRM_IO_PMCTRL_OFFSET)
+OMAP4430_WUCLK_STATUS_SHIFT) == 1), MAX_IOPAD_LATCH_TIME, i);
+ /* Trigger WUCLKIN disable */
+ omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+ OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+ return;
+}
+
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7dfa379..275b25a 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -750,6 +750,7 @@
extern u32 omap4_prm_read_inst_reg(s16 inst, u16 idx);
extern void omap4_prm_write_inst_reg(u32 val, s16 inst, u16 idx);
extern u32 omap4_prm_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
+extern void omap4_trigger_wuclk_ctrl(void);
# endif
--
1.7.0.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
[PATCHv2 2/7] ARM: OMAP3 PM: Move IO Daisychain function to omap3 prm file
Since IO Daisychain modifies only PRM registers, it makes sense to move it to
PRM File.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 33 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 35 +++
arch/arm/mach-omap2/prm2xxx_3xxx.h | 14 ++
3 files changed, 50 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 041f6e6..352ad3c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -95,37 +95,6 @@ static inline void omap3_per_restore_context(void)
omap_gpio_restore_context();
}
-static void omap3_enable_io_chain(void)
-{
- int timeout = 0;
-
- if (omap_rev() = OMAP3430_REV_ES3_1) {
- omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
-PM_WKEN);
- /* Do a readback to assure write has been done */
- omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
-
- while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
-OMAP3430_ST_IO_CHAIN_MASK)) {
- timeout++;
- if (timeout 1000) {
- printk(KERN_ERR Wake up daisy chain
- activation failed.\n);
- return;
- }
- }
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
-PM_WKEN);
- }
-}
-
-static void omap3_disable_io_chain(void)
-{
- if (omap_rev() = OMAP3430_REV_ES3_1)
- omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
- PM_WKEN);
-}
-
static void omap3_core_save_context(void)
{
omap3_ctrl_save_padconf();
@@ -376,7 +345,7 @@ void omap_sram_idle(void)
(per_next_state PWRDM_POWER_ON ||
core_next_state PWRDM_POWER_ON)) {
omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
PM_WKEN);
- omap3_enable_io_chain();
+ omap3_trigger_wuclk_ctrl();
}
/* Block console output in case it is on one of the OMAP UARTs */
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 051213f..915d726 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -156,3 +156,38 @@ int omap2_prm_deassert_hardreset(s16 prm_mod, u8
rst_shift, u8 st_shift)
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP3 Daisychain trigger sequence */
+void omap3_trigger_wuclk_ctrl(void)
+{
+ int i = 0;
+
+ if (omap_rev() = OMAP3430_REV_ES3_1) {
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK, WKUP_MOD,
+PM_WKEN);
+ /* Do a readback to assure write has been done */
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+
+ omap_test_timeout(
+ (((omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST)
+OMAP3430_ST_IO_CHAIN_MASK) == 1)),
+ MAX_IOPAD_LATCH_TIME, i);
+
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
+PM_WKEN);
+ }
+}
+
+/* OMAP3 Daisychain disable sequence */
+void omap3_disable_io_chain(void)
+{
+ if (omap_rev() = OMAP3430_REV_ES3_1)
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN_MASK,
WKUP_MOD,
+ PM_WKEN);
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index a1fc62a..8bc574d 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,18 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
not suppose to be used on omap4\n);
return 0;
}
+extern void omap3_trigger_wuclk_ctrl(void)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
+extern void omap3_disable_io_chain(void)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -302,6 +314,8 @@ extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16
idx, u32 mask);
extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16
[PATCHv2 5/7] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a window
where device
is idled and corresponding powerdomain can be ON/INACTIVE state. In such
situations,
since both module wake up is enabled at padlevel as well as io daisychain
sequence is
triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup
and IO Pad
interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit
in the
first interrupt, module specific interrupt handler will not triggered for the
second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
This has been tested on OMAP3 using Chain Handler + UART Runtime patches [1].
Special
thanks to GOvind for testing and confirming this behaviour on UART3.
[1]: git://gitorious.org/runtime_3-0/runtime_3-0.git v6_uart_runtime
arch/arm/mach-omap2/omap_hwmod.c |9 +++--
arch/arm/mach-omap2/pm.c | 11 +++
arch/arm/mach-omap2/pm.h |1 +
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 84cc0bd..070f3f5 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -151,6 +151,7 @@
#include prm44xx.h
#include prminst44xx.h
#include mux.h
+#include pm.h
/* Maximum microseconds to wait for OMAP module to softreset */
#define MAX_MODULE_SOFTRESET_WAIT 1
@@ -1462,8 +1463,10 @@ static int _enable(struct omap_hwmod *oh)
/* Mux pins for device runtime if populated */
if (oh-mux (!oh-mux-enabled ||
((oh-_state == _HWMOD_STATE_IDLE)
-oh-mux-pads_dynamic)))
+oh-mux-pads_dynamic))) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED);
+ omap_trigger_wuclk_ctrl();
+ }
_add_initiator_dep(oh, mpu_oh);
@@ -1553,8 +1556,10 @@ static int _idle(struct omap_hwmod *oh)
clkdm_hwmod_disable(oh-clkdm, oh);
/* Mux pins for device idle if populated */
- if (oh-mux oh-mux-pads_dynamic)
+ if (oh-mux oh-mux-pads_dynamic) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE);
+ omap_trigger_wuclk_ctrl();
+ }
oh-_state = _HWMOD_STATE_IDLE;
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 472bf22..79be7af 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -23,6 +23,8 @@
#include powerdomain.h
#include clockdomain.h
#include pm.h
+#include prm2xxx_3xxx.h
+#include prm44xx.h
static struct omap_device_pm_latency *pm_lats;
@@ -95,6 +97,15 @@ static void omap2_init_processor_devices(void)
}
}
+void omap_trigger_wuclk_ctrl(void)
+{
+ if (cpu_is_omap34xx())
+ omap3_trigger_wuclk_ctrl();
+
+ if (cpu_is_omap44xx())
+ omap4_trigger_wuclk_ctrl();
+}
+
/* Types of sleep_switch used in omap_set_pwrdm_state */
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH 1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4e166ad..05c2da2 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
extern int omap3_idle_init(void);
+void omap_trigger_wuclk_ctrl(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
--
1.7.0.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/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
* Santosh Shilimkar santosh.shilim...@ti.com [111007 10:05]:
I initially tried some thing similar but the issue was GP and
HS devices. SRAM_PA isn't same on GP and EMU device and hence
did that dynamically. One way is I can make GP and HS
device SRAM_PA same for OMAP4 (Will loose 16 KB of
SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM
for OMAP4 with errata enabled.
Oh yeah, the beginning is different too, I forgot that.
Below change works on both GP and HS device
If you are OK with it, I can update errata patch accordingly.
OK to me to loose 16KB when the errata is enabled. That can
be fixed later on for example by passing the SRAM area from
device tree.
I assume now you can add the mapping to io.c instead? If so,
then it's easier to apply the patches whatever way makes more
sense.
Regards,
Tony
diff --git a/arch/arm/plat-omap/include/plat/sram.h
b/arch/arm/plat-omap/include/plat/sram.h
index f500fc3..111b1a8 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -95,6 +95,11 @@ static inline void omap_push_sram_idle(void) {}
*/
#define OMAP2_SRAM_PA0x4020
#define OMAP3_SRAM_PA 0x4020
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PA0x40304000
+#else
#define OMAP4_SRAM_PA0x4030
+#endif
+#define OMAP4_SRAM_VA0xfe404000
#endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 363c91e..cdd303f 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -48,9 +48,13 @@
#define OMAP3_SRAM_VA 0xfe40
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_VA0xfe40
+#ifdef CONFIG_OMAP4_ERRATA_I688
+#define OMAP4_SRAM_PUB_PAOMAP4_SRAM_PA
+#define OMAP4_SRAM_PUB_VAOMAP4_SRAM_VA
+#else
#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
#define OMAP4_SRAM_PUB_VA(OMAP4_SRAM_VA + 0x4000)
+#endif
#if defined(CONFIG_ARCH_OMAP2PLUS)
#define SRAM_BOOTLOADER_SZ 0x00
@@ -203,6 +207,11 @@ static void __init omap_map_sram(void)
if (omap_sram_size == 0)
return;
+#ifdef CONFIG_OMAP4_ERRATA_I688
+ omap_sram_base += PAGE_SIZE;
+ omap_sram_start += PAGE_SIZE;
+ omap_sram_size -= SZ_16K;
+#endif
if (cpu_is_omap34xx()) {
/*
* SRAM must be marked as non-cached on OMAP3 since the
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
On Friday 07 October 2011 11:46 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [111007 10:05]: I initially tried some thing similar but the issue was GP and HS devices. SRAM_PA isn't same on GP and EMU device and hence did that dynamically. One way is I can make GP and HS device SRAM_PA same for OMAP4 (Will loose 16 KB of SRAM on OMAP4 GP). It's ok to loose that 16 KB SRAM for OMAP4 with errata enabled. Oh yeah, the beginning is different too, I forgot that. Below change works on both GP and HS device If you are OK with it, I can update errata patch accordingly. OK to me to loose 16KB when the errata is enabled. That can be fixed later on for example by passing the SRAM area from device tree. Yep. I assume now you can add the mapping to io.c instead? If so, then it's easier to apply the patches whatever way makes more sense. io.c change I took as you suggested. The below change on top of it. I just updated PM branch with this change. Thanks for the tip. The errata code looks bit more clean now. :) Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
* Santosh Shilimkar santosh.shilim...@ti.com [111007 10:46]: On Friday 07 October 2011 11:46 PM, Tony Lindgren wrote: I assume now you can add the mapping to io.c instead? If so, then it's easier to apply the patches whatever way makes more sense. io.c change I took as you suggested. The below change on top of it. I just updated PM branch with this change. Thanks for the tip. The errata code looks bit more clean now. :) 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: ARM SoC tree: OMAP PM dependency on tip irq/core
On Friday 07 October 2011, Kevin Hilman wrote: I've pulled in rmk/devel-stable as a dependency now, thanks for reminding me of that. Thomas, where should I get the irq-core branch (or whichever I should wait for) to pull in as another dependency. Is that branch one that never gets rebased? git://tesla.tglx.de/git/linux-2.6-tip irq/core I asked Thomas about this earlier when I was going to build up the dependencies myself, and he said it won't be rebased. Ok, thanks for the info. I think I've now also come up with a workflow for tracking the dependencies: I have a depends/xxx branch for each other branch that I need to wait for getting merged first. When I want to send a pull request, I first check all the depends/* branches using 'git branch --merged next/xxx | grep depends' to see what the dependencies are, and 'git branch --merged torvalds/master | grep depends' to see if they are already merged upstream. When a dependency is already merged, I can remove its tracking branch from the arm-soc tree. Arnd -- 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: ARM SoC tree: OMAP PM dependency on tip irq/core
On Fri, 7 Oct 2011, Arnd Bergmann wrote: On Friday 07 October 2011, Kevin Hilman wrote: I've pulled in rmk/devel-stable as a dependency now, thanks for reminding me of that. Thomas, where should I get the irq-core branch (or whichever I should wait for) to pull in as another dependency. Is that branch one that never gets rebased? git://tesla.tglx.de/git/linux-2.6-tip irq/core I asked Thomas about this earlier when I was going to build up the dependencies myself, and he said it won't be rebased. Ok, thanks for the info. I think I've now also come up with a workflow for tracking the dependencies: I have a depends/xxx branch for each other branch that I need to wait for getting merged first. When I want to send a pull request, I first check all the depends/* branches using 'git branch --merged next/xxx | grep depends' to see what the dependencies are, and 'git branch --merged torvalds/master | grep depends' to see if they are already merged upstream. When a dependency is already merged, I can remove its tracking branch from the arm-soc tree. For your internal dependecies, yes. But for irq/core you don't have to wait. You just need to tell Linus in the pull request that you pulled my branch with my ack as it contains modifications which are prerequisite for arm/whatever. When I send my pull request later, then this wont do any damage as Linus has the commits already. Same the other way round. We do that all the time, otherwise pull dependencies would be a nightmare. Thanks, tglx -- 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] omap fixes for -rc series and merge window
On Monday 03 October 2011, Tony Lindgren wrote: Please pull omap fixes from: git://github.com/tmlind/linux.git fixes Out of these the first three commits would be nice to get into the -rc series with the first two causing boot issues and the musb fixing an ugly warning. Note however the recent commit message update on the third patch. I added Bjarne's SOB to the third patch because of the earlier reference. The last two are mostly cosmetic and not so urgent. Hi Tony, I've pulled them all into the fixes branch for now, but I'm not sure if I still want to send another pull request. If I do, I'll have to rebase that branch and put some into the next/fixes branch instead as I already have patches that I don't want to send for 3.1 any more. Are the patches all fixes against 3.1 only or do some of them also apply to older releases? Arnd -- 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] omap: dmtimer: convert printk to pr_err
On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote: At some point in the next couple of years, I want to convert all of, or as many as possible of, the remaining printk uses to pr_level. If the idea is also to get rid of printk() too (which IMHO would be a good thing as it kills off the constant need to continually patch for missing KERN_ prefixes) then that's a good reason (provided Linus accepts the idea.) At that point having such patches as part of a progressive series of patches also makes sense. Doing it piecemeal when we've already had frequent complaints from Linus about useless churn with no apparant reasoning behind it doesn't help relieve us of those accusations. -- 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] omap fixes for -rc series and merge window
* Arnd Bergmann a...@arndb.de [111007 11:37]: On Monday 03 October 2011, Tony Lindgren wrote: Please pull omap fixes from: git://github.com/tmlind/linux.git fixes Out of these the first three commits would be nice to get into the -rc series with the first two causing boot issues and the musb fixing an ugly warning. Note however the recent commit message update on the third patch. I added Bjarne's SOB to the third patch because of the earlier reference. The last two are mostly cosmetic and not so urgent. Hi Tony, I've pulled them all into the fixes branch for now, but I'm not sure if I still want to send another pull request. If I do, I'll have to rebase that branch and put some into the next/fixes branch instead as I already have patches that I don't want to send for 3.1 any more. Are the patches all fixes against 3.1 only or do some of them also apply to older releases? Thanks. Well we can certainly manage if the first three commits did not make it in during the -rc cycle. But assuming that we had valid fixes, you could just do something like this too: $ git checkout -b omap/fixes-for-rc $ git reset --hard b8e111a74d281b70e88bd67fec48cfda4f9bdce2 ... Then merge all the -rc fixes for various ARM platforms with: $ git checkout fixes-for-rc $ git reset --hard v3.1-rc9 $ git merge omap/fixes-for-rc soc foo/fixes-for-rc bar/fixes-for-rc And then no rebasing is needed. Of course I could also set up a separate fixes-for-rc for that if you prefrer that :) 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] OMAP2+: clock: use clock's recalc in DPLL handling
On Fri, Oct 7, 2011 at 12:07 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 29 Sep 2011, Mike Turquette wrote:
Not all DPLLs are identical; some require special consideration such as
OMAP4's ABE DPLL, which can have an additional 4x multiplier added to
it's clock rate based on programming the REGM4XEN bit in it's CLKMODE
register.
Unfortunately the clock framework makes a few assumptions that all DPLLs
can have their rates calculated the same way which has led to incorrect
rates for OMAP4's DPLL_ABE in some cases. This patch fixes the same by
replacing explicit calls to omap2_dpll_get_rate with clk-recalc if
.recalc is populated for a clock. If .recalc is NULL then fall back to
omap2_dpll_get_rate.
Reported-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Mike Turquette mturque...@ti.com
I've merged this patch with Jon's ARM: OMAP3+: dpll: use DPLLs recalc
function instead of omap2_get_dpll_rate patch, which does almost exactly
the same thing, just without the conditionals on clk-recalc. Updated
patch below. Please let me know if you think I should change anything
about the changelog.
Heh, I hadn't realized we had overlapping patches like that. Looks fine to me.
Regards,
Mike
- Paul
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 7 Oct 2011 00:53:01 -0600
Subject: [PATCH] ARM: OMAP3+: dpll: use DPLLs recalc function instead of
omap2_get_dpll_rate
This is a continuation of Mike Turquette's patch OMAP3+: use
DPLL's round_rate when setting rate.
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function and so use the DPLLs recalc()
function pointer instead.
An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
in addition to the usual MN multipler and dividers and therefore
uses a different round_rate and recalc function.
Signed-off-by: Jon Hunter jon-hun...@ti.com
Cc: Mike Turquette mturque...@ti.com
Cc: Misael Lopez Cruz misael.lo...@ti.com
[p...@pwsan.com: merged this patch with Mike's use clock's recalc in DPLL
handling patch; also reported by Misael]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/dpll3xxx.c | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 73a1595..fc56745 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -390,7 +390,8 @@ int omap3_noncore_dpll_enable(struct clk *clk)
* propagating?
*/
if (!r)
- clk-rate = omap2_get_dpll_rate(clk);
+ clk-rate = (clk-recalc) ? clk-recalc(clk) :
+ omap2_get_dpll_rate(clk);
return r;
}
@@ -424,6 +425,7 @@ void omap3_noncore_dpll_disable(struct clk *clk)
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
{
struct clk *new_parent = NULL;
+ unsigned long hw_rate;
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
@@ -435,7 +437,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (!dd)
return -EINVAL;
- if (rate == omap2_get_dpll_rate(clk))
+ hw_rate = (clk-recalc) ? clk-recalc(clk) : omap2_get_dpll_rate(clk);
+ if (rate == hw_rate)
return 0;
/*
--
1.7.6.3
--
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/7] Repost of omap SRAM map_io changes
Hi all, Here's a repost of the original patches with minimal changes to fix some compile warnings and with the acks added. There's also one new patch to warn about trying to use the omap_ioremap too early that's good to have for some sanity checks. These patches are against the dt branch in linux-omap tree because of dependencies to earlier cleanup. Regards, Tony --- Tony Lindgren (7): ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY ARM: OMAP1: Use generic map_io, init_early and init_irq ARM: OMAP: Avoid cpu_is_omap usage until map_io is done ARM: OMAP: Remove calls to SRAM allocations for framebuffer ARM: OMAP: Map SRAM later on with ioremap_exec() ARM: OMAP: Move set_globals initialization to happen in init_early ARM: OMAP: Warn if omap_ioremap is called before SoC detection arch/arm/include/asm/io.h|1 arch/arm/mach-omap1/board-ams-delta.c| 16 +--- arch/arm/mach-omap1/board-fsample.c | 76 +- arch/arm/mach-omap1/board-generic.c | 16 +--- arch/arm/mach-omap1/board-h2.c | 16 +--- arch/arm/mach-omap1/board-h3.c | 16 +--- arch/arm/mach-omap1/board-htcherald.c| 12 +-- arch/arm/mach-omap1/board-innovator.c| 36 - arch/arm/mach-omap1/board-nokia770.c | 34 +++- arch/arm/mach-omap1/board-osk.c | 16 +--- arch/arm/mach-omap1/board-palmte.c | 16 +--- arch/arm/mach-omap1/board-palmtt.c | 16 +--- arch/arm/mach-omap1/board-palmz71.c | 18 +--- arch/arm/mach-omap1/board-perseus2.c | 75 +- arch/arm/mach-omap1/board-sx1.c | 17 +--- arch/arm/mach-omap1/board-voiceblue.c| 16 +--- arch/arm/mach-omap1/devices.c|3 + arch/arm/mach-omap1/io.c | 57 ++--- arch/arm/mach-omap2/board-omap3beagle.c |7 -- arch/arm/mach-omap2/board-ti8168evm.c|1 arch/arm/mach-omap2/common.c | 50 +--- arch/arm/mach-omap2/control.c| 14 +-- arch/arm/mach-omap2/io.c | 127 +++--- arch/arm/mach-omap2/io.h |7 -- arch/arm/mach-omap2/omap-smp.c |7 +- arch/arm/mach-omap2/prcm.c | 19 +--- arch/arm/mach-omap2/sdrc.c | 13 +-- arch/arm/mm/ioremap.c| 21 + arch/arm/plat-omap/include/plat/common.h | 17 ++-- arch/arm/plat-omap/include/plat/io.h | 29 ++- arch/arm/plat-omap/io.c | 10 ++ arch/arm/plat-omap/sram.c| 85 +--- 32 files changed, 356 insertions(+), 508 deletions(-) -- 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
[PATCH 1/7] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/include/asm/io.h |1 +
arch/arm/mm/ioremap.c | 21 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d66605d..4ff152e 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long,
size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t,
unsigned int);
extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, int cached);
extern void __iounmap(volatile void __iomem *addr);
/*
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..a2d94ac 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,27 @@ __arm_ioremap(unsigned long phys_addr, size_t size,
unsigned int mtype)
}
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
+ return __arm_ioremap_caller(phys_addr, size, mtype,
+ __builtin_return_address(0));
+}
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK (unsigned long)io_addr);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: OMAP1: Use generic map_io, init_early and init_irq
This allows removing omap hacks for map_io allowing generic
map_io.
Note that in the future we can't do cpu_is_omap detection
until in init_early. This means that board-innovator.c now
assumes 15xx only, and board-generic.c assumes 16xx only.
This is best fixed later on by passing the SoC type from
device tree.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-ams-delta.c | 16 +--
arch/arm/mach-omap1/board-fsample.c | 76 -
arch/arm/mach-omap1/board-generic.c | 16 +--
arch/arm/mach-omap1/board-h2.c| 16 +--
arch/arm/mach-omap1/board-h3.c| 16 +--
arch/arm/mach-omap1/board-htcherald.c | 12 +
arch/arm/mach-omap1/board-innovator.c | 36 +++-
arch/arm/mach-omap1/board-nokia770.c | 34 +--
arch/arm/mach-omap1/board-osk.c | 16 +--
arch/arm/mach-omap1/board-palmte.c| 16 +--
arch/arm/mach-omap1/board-palmtt.c| 16 +--
arch/arm/mach-omap1/board-palmz71.c | 18 +---
arch/arm/mach-omap1/board-perseus2.c | 75 -
arch/arm/mach-omap1/board-sx1.c | 17 +--
arch/arm/mach-omap1/board-voiceblue.c | 16 +--
arch/arm/mach-omap1/io.c | 56 +++-
arch/arm/plat-omap/include/plat/io.h | 27 +++-
17 files changed, 183 insertions(+), 296 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 312ea6b..4427737 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -135,12 +135,6 @@ void ams_delta_latch2_write(u16 mask, u16 value)
*(volatile __u16 *) AMS_DELTA_LATCH2_VIRT = ams_delta_latch2_reg;
}
-static void __init ams_delta_init_irq(void)
-{
- omap1_init_common_hw();
- omap1_init_irq();
-}
-
static struct map_desc ams_delta_io_desc[] __initdata = {
/* AMS_DELTA_LATCH1 */
{
@@ -379,17 +373,13 @@ static int __init ams_delta_modem_init(void)
}
arch_initcall(ams_delta_modem_init);
-static void __init ams_delta_map_io(void)
-{
- omap1_map_common_io();
-}
-
MACHINE_START(AMS_DELTA, Amstrad E3 (Delta))
/* Maintainer: Jonathan McDowell nood...@earth.li */
.boot_params= 0x1100,
- .map_io = ams_delta_map_io,
+ .map_io = omap15xx_map_io,
+ .init_early = omap1_init_early,
.reserve= omap_reserve,
- .init_irq = ams_delta_init_irq,
+ .init_irq = omap1_init_irq,
.init_machine = ams_delta_init,
.timer = omap1_timer,
MACHINE_END
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index a6b1bea..b09dfe6 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -297,6 +297,39 @@ static struct omap_board_config_kernel fsample_config[]
__initdata = {
static void __init omap_fsample_init(void)
{
+ /* Early, board-dependent init */
+
+ /*
+* Hold GSM Reset until needed
+*/
+ omap_writew(omap_readw(OMAP7XX_DSP_M_CTL) ~1, OMAP7XX_DSP_M_CTL);
+
+ /*
+* UARTs - done automagically by 8250 driver
+*/
+
+ /*
+* CSx timings, GPIO Mux ... setup
+*/
+
+ /* Flash: CS0 timings setup */
+ omap_writel(0xfff3, OMAP7XX_FLASH_CFG_0);
+ omap_writel(0x0088, OMAP7XX_FLASH_ACFG_0);
+
+ /*
+* Ethernet support through the debug board
+* CS1 timings setup
+*/
+ omap_writel(0xfff3, OMAP7XX_FLASH_CFG_1);
+ omap_writel(0x, OMAP7XX_FLASH_ACFG_1);
+
+ /*
+* Configure MPU_EXT_NIRQ IO in IO_CONF9 register,
+* It is used as the Ethernet controller interrupt
+*/
+ omap_writel(omap_readl(OMAP7XX_IO_CONF_9) 0x1FFF,
+ OMAP7XX_IO_CONF_9);
+
fsample_init_smc91x();
if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, NAND ready) 0)
@@ -326,12 +359,6 @@ static void __init omap_fsample_init(void)
omap_register_i2c_bus(1, 100, NULL, 0);
}
-static void __init omap_fsample_init_irq(void)
-{
- omap1_init_common_hw();
- omap1_init_irq();
-}
-
/* Only FPGA needs to be mapped here. All others are done with ioremap */
static struct map_desc omap_fsample_io_desc[] __initdata = {
{
@@ -350,49 +377,18 @@ static struct map_desc omap_fsample_io_desc[] __initdata
= {
static void __init omap_fsample_map_io(void)
{
- omap1_map_common_io();
+ omap15xx_map_io();
iotable_init(omap_fsample_io_desc,
ARRAY_SIZE(omap_fsample_io_desc));
-
- /* Early, board-dependent init */
-
- /*
-* Hold GSM Reset until needed
-*/
- omap_writew(omap_readw(OMAP7XX_DSP_M_CTL) ~1, OMAP7XX_DSP_M_CTL);
-
- /*
-* UARTs - done automagically by 8250
[PATCH 5/7] ARM: OMAP: Map SRAM later on with ioremap_exec()
This allows us to remove omap hacks for map_io.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/devices.c|3 +
arch/arm/mach-omap1/io.c |2 -
arch/arm/mach-omap2/io.c | 21 +
arch/arm/mach-omap2/io.h |7 ---
arch/arm/plat-omap/include/plat/common.h |2 +
arch/arm/plat-omap/sram.c| 69 +-
6 files changed, 28 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 36f26c3..38e1142 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -21,6 +21,7 @@
#include mach/hardware.h
#include asm/mach/map.h
+#include plat/common.h
#include plat/tc.h
#include plat/board.h
#include plat/mux.h
@@ -291,6 +292,8 @@ static int __init omap1_init_devices(void)
if (!cpu_class_is_omap1())
return -ENODEV;
+ omap_sram_init();
+
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index a16aab7..8140a4e 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -21,7 +21,6 @@
#include clock.h
extern void omap_check_revision(void);
-extern void omap_sram_init(void);
/*
* The machine specific code may provide the extra mapping besides the
@@ -133,7 +132,6 @@ void omap1_init_early(void)
*/
omap1_clk_init();
omap1_mux_init();
- omap_sram_init();
}
/*
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e8123d0..b42bbb8 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -35,8 +35,8 @@
#include clock2xxx.h
#include clock3xxx.h
#include clock44xx.h
-#include io.h
+#include plat/common.h
#include plat/omap-pm.h
#include voltage.h
#include powerdomain.h
@@ -240,22 +240,11 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
-static void __init _omap2_map_common_io(void)
-{
- /* Normally devicemaps_init() would flush caches and tlb after
-* mdesc-map_io(), but we must also do it here because of the CPU
-* revision check below.
-*/
- local_flush_tlb_all();
- flush_cache_all();
-}
-
#ifdef CONFIG_SOC_OMAP2420
void __init omap242x_map_common_io(void)
{
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap242x_io_desc, ARRAY_SIZE(omap242x_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -264,7 +253,6 @@ void __init omap243x_map_common_io(void)
{
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap243x_io_desc, ARRAY_SIZE(omap243x_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -272,7 +260,6 @@ void __init omap243x_map_common_io(void)
void __init omap34xx_map_common_io(void)
{
iotable_init(omap34xx_io_desc, ARRAY_SIZE(omap34xx_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -280,7 +267,6 @@ void __init omap34xx_map_common_io(void)
void __init omapti816x_map_common_io(void)
{
iotable_init(omapti816x_io_desc, ARRAY_SIZE(omapti816x_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -288,7 +274,6 @@ void __init omapti816x_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -337,7 +322,6 @@ void __iomem *omap_irq_base;
static void __init omap_common_init_early(void)
{
omap2_check_revision();
- omap_sram_init();
}
static void __init omap_hwmod_init_postsetup(void)
@@ -449,11 +433,12 @@ void __init omap4430_init_early(void)
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
+ omap_sram_init();
+
if (cpu_is_omap24xx() || omap3_has_sdrc()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
}
-
}
/*
diff --git a/arch/arm/mach-omap2/io.h b/arch/arm/mach-omap2/io.h
index fd230c6..e69de29 100644
--- a/arch/arm/mach-omap2/io.h
+++ b/arch/arm/mach-omap2/io.h
@@ -1,7 +0,0 @@
-
-#ifndef __MACH_OMAP2_IO_H__
-#define __MACH_OMAP2_IO_H__
-
-extern int __init omap_sram_init(void);
-
-#endif /* __MACH_OMAP2_IO_H__ */
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 5eac355..ed85720 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -55,6 +55,8 @@ void am35xx_init_early(void);
void ti816x_init_early(void);
void omap4430_init_early(void);
+void
[PATCH 6/7] ARM: OMAP: Move set_globals initialization to happen in init_early
Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-ti8168evm.c|1 -
arch/arm/mach-omap2/common.c | 50 ++
arch/arm/mach-omap2/control.c| 14 ++--
arch/arm/mach-omap2/io.c | 14
arch/arm/mach-omap2/omap-smp.c |7 +++-
arch/arm/mach-omap2/prcm.c | 19 ---
arch/arm/mach-omap2/sdrc.c | 13 ++--
arch/arm/plat-omap/include/plat/common.h | 14
8 files changed, 62 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index 981ca00..b0a16d2 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,7 +37,6 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
- omap2_set_globals_ti816x();
omapti816x_map_common_io();
}
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index de61f15..110e5b9 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -45,11 +45,11 @@ static void __init __omap2_set_globals(struct omap_globals
*omap2_globals)
static struct omap_globals omap242x_globals = {
.class = OMAP242X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x48014000),
- .sdrc = OMAP2420_SDRC_BASE,
- .sms= OMAP2420_SMS_BASE,
- .ctrl = OMAP242X_CTRL_BASE,
- .prm= OMAP2420_PRM_BASE,
- .cm = OMAP2420_CM_BASE,
+ .sdrc = OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE),
+ .sms= OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP242X_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE),
};
void __init omap2_set_globals_242x(void)
@@ -59,7 +59,6 @@ void __init omap2_set_globals_242x(void)
void __init omap242x_map_io(void)
{
- omap2_set_globals_242x();
omap242x_map_common_io();
}
#endif
@@ -69,11 +68,11 @@ void __init omap242x_map_io(void)
static struct omap_globals omap243x_globals = {
.class = OMAP243X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x4900a000),
- .sdrc = OMAP243X_SDRC_BASE,
- .sms= OMAP243X_SMS_BASE,
- .ctrl = OMAP243X_CTRL_BASE,
- .prm= OMAP2430_PRM_BASE,
- .cm = OMAP2430_CM_BASE,
+ .sdrc = OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE),
+ .sms= OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP243X_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE),
};
void __init omap2_set_globals_243x(void)
@@ -83,7 +82,6 @@ void __init omap2_set_globals_243x(void)
void __init omap243x_map_io(void)
{
- omap2_set_globals_243x();
omap243x_map_common_io();
}
#endif
@@ -93,11 +91,11 @@ void __init omap243x_map_io(void)
static struct omap_globals omap3_globals = {
.class = OMAP343X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(0x4830A000),
- .sdrc = OMAP343X_SDRC_BASE,
- .sms= OMAP343X_SMS_BASE,
- .ctrl = OMAP343X_CTRL_BASE,
- .prm= OMAP3430_PRM_BASE,
- .cm = OMAP3430_CM_BASE,
+ .sdrc = OMAP2_L3_IO_ADDRESS(OMAP343X_SDRC_BASE),
+ .sms= OMAP2_L3_IO_ADDRESS(OMAP343X_SMS_BASE),
+ .ctrl = OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE),
};
void __init omap2_set_globals_3xxx(void)
@@ -107,7 +105,6 @@ void __init omap2_set_globals_3xxx(void)
void __init omap3_map_io(void)
{
- omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
@@ -122,9 +119,9 @@ void __init omap3_map_io(void)
static struct omap_globals ti816x_globals = {
.class = OMAP343X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(TI816X_TAP_BASE),
- .ctrl = TI816X_CTRL_BASE,
- .prm= TI816X_PRCM_BASE,
- .cm = TI816X_PRCM_BASE,
+ .ctrl = OMAP2_L4_IO_ADDRESS(TI816X_CTRL_BASE),
+ .prm= OMAP2_L4_IO_ADDRESS(TI816X_PRCM_BASE),
+ .cm = OMAP2_L4_IO_ADDRESS(TI816X_PRCM_BASE),
};
void __init omap2_set_globals_ti816x(void)
@@ -137,11 +134,11 @@ void __init omap2_set_globals_ti816x(void)
static struct omap_globals omap4_globals = {
.class = OMAP443X_CLASS,
.tap= OMAP2_L4_IO_ADDRESS(OMAP443X_SCM_BASE),
- .ctrl = OMAP443X_SCM_BASE,
- .ctrl_pad = OMAP443X_CTRL_BASE,
- .prm= OMAP4430_PRM_BASE,
- .cm =
[PATCH 3/7] ARM: OMAP: Avoid cpu_is_omapxxxx usage until map_io is done
This way we don't need to initialize SoC detection early
and can start using generic map_io.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3beagle.c |7 --
arch/arm/mach-omap2/io.c | 95 +++---
arch/arm/plat-omap/include/plat/common.h |1
3 files changed, 50 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 4a5d75f..4c25742 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -444,11 +444,6 @@ static struct platform_device keys_gpio = {
},
};
-static void __init omap3_beagle_init_early(void)
-{
- omap2_init_common_infrastructure();
-}
-
static struct platform_device *omap3_beagle_devices[] __initdata = {
leds_gpio,
keys_gpio,
@@ -555,7 +550,7 @@ MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board)
.boot_params= 0x8100,
.reserve= omap_reserve,
.map_io = omap3_map_io,
- .init_early = omap3_beagle_init_early,
+ .init_early = omap3_init_early,
.init_irq = omap3_init_irq,
.init_machine = omap3_beagle_init,
.timer = omap3_secure_timer,
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 15f91c4..e8123d0 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -248,9 +248,6 @@ static void __init _omap2_map_common_io(void)
*/
local_flush_tlb_all();
flush_cache_all();
-
- omap2_check_revision();
- omap_sram_init();
}
#ifdef CONFIG_SOC_OMAP2420
@@ -337,33 +334,15 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod
*oh, void *data)
/* See irq.c, omap4-common.c and entry-macro.S */
void __iomem *omap_irq_base;
-void __init omap2_init_common_infrastructure(void)
+static void __init omap_common_init_early(void)
{
- u8 postsetup_state;
+ omap2_check_revision();
+ omap_sram_init();
+}
- if (cpu_is_omap242x()) {
- omap2xxx_voltagedomains_init();
- omap242x_powerdomains_init();
- omap242x_clockdomains_init();
- omap2420_hwmod_init();
- } else if (cpu_is_omap243x()) {
- omap2xxx_voltagedomains_init();
- omap243x_powerdomains_init();
- omap243x_clockdomains_init();
- omap2430_hwmod_init();
- } else if (cpu_is_omap34xx()) {
- omap3xxx_voltagedomains_init();
- omap3xxx_powerdomains_init();
- omap3xxx_clockdomains_init();
- omap3xxx_hwmod_init();
- } else if (cpu_is_omap44xx()) {
- omap44xx_voltagedomains_init();
- omap44xx_powerdomains_init();
- omap44xx_clockdomains_init();
- omap44xx_hwmod_init();
- } else {
- pr_err(Could not init hwmod data - unknown SoC\n);
-}
+static void __init omap_hwmod_init_postsetup(void)
+{
+ u8 postsetup_state;
/* Set the default postsetup state for all hwmods */
#ifdef CONFIG_PM_RUNTIME
@@ -392,57 +371,79 @@ void __init omap2_init_common_infrastructure(void)
postsetup_state);
omap_pm_if_early_init();
-
- if (cpu_is_omap2420())
- omap2420_clk_init();
- else if (cpu_is_omap2430())
- omap2430_clk_init();
- else if (cpu_is_omap34xx())
- omap3xxx_clk_init();
- else if (cpu_is_omap44xx())
- omap4xxx_clk_init();
- else
- pr_err(Could not init clock framework - unknown SoC\n);
}
void __init omap2420_init_early(void)
{
- omap2_init_common_infrastructure();
+ omap_common_init_early();
+ omap2xxx_voltagedomains_init();
+ omap242x_powerdomains_init();
+ omap242x_clockdomains_init();
+ omap2420_hwmod_init();
+ omap_hwmod_init_postsetup();
+ omap2420_clk_init();
}
void __init omap2430_init_early(void)
{
- omap2_init_common_infrastructure();
+ omap_common_init_early();
+ omap2xxx_voltagedomains_init();
+ omap243x_powerdomains_init();
+ omap243x_clockdomains_init();
+ omap2430_hwmod_init();
+ omap_hwmod_init_postsetup();
+ omap2430_clk_init();
+}
+
+/*
+ * Currently only board-omap3beagle.c should call this because of the
+ * same machine_id for 34xx and 36xx beagle.. Will get fixed with DT.
+ */
+void __init omap3_init_early(void)
+{
+ omap_common_init_early();
+ omap3xxx_voltagedomains_init();
+ omap3xxx_powerdomains_init();
+ omap3xxx_clockdomains_init();
+ omap3xxx_hwmod_init();
+ omap_hwmod_init_postsetup();
+ omap3xxx_clk_init();
}
void __init
[PATCH 7/7] ARM: OMAP: Warn if omap_ioremap is called before SoC detection
We don't have cpu_is_omap SoC detection initialized until
SoC detection is initialized from init_early.
Note that with the common map_io we should no longer need
cpu_is_omap for ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/io.c |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/plat-omap/include/plat/io.h |2 ++
arch/arm/plat-omap/io.c | 10 ++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 8140a4e..fd9eb09 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -121,6 +121,7 @@ void __init omap16xx_map_io(void)
void omap1_init_early(void)
{
omap_check_revision();
+ omap_ioremap_init();
/* REVISIT: Refer to OMAP5910 Errata, Advisory SYS_1: Timeout Abort
* on a Posted Write in the TIPB Bridge.
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d5caac3..aa96538 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,6 +323,7 @@ void __iomem *omap_irq_base;
static void __init omap_common_init_early(void)
{
omap2_check_revision();
+ omap_ioremap_init();
}
static void __init omap_hwmod_init_postsetup(void)
diff --git a/arch/arm/plat-omap/include/plat/io.h
b/arch/arm/plat-omap/include/plat/io.h
index c0c7850..5ffbea6 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -247,6 +247,8 @@
* NOTE: Please use ioremap + __raw_read/write where possible instead of these
*/
+void omap_ioremap_init(void);
+
extern u8 omap_readb(u32 pa);
extern u16 omap_readw(u32 pa);
extern u32 omap_readl(u32 pa);
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index f1ecfa9..1bbcbde 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -23,11 +23,16 @@
#define BETWEEN(p,st,sz) ((p) = (st) (p) ((st) + (sz)))
#define XLATE(p,pst,vst) ((void __iomem *)((p) - (pst) + (vst)))
+static int initialized;
+
/*
* Intercept ioremap() requests for addresses in our fixed mapping regions.
*/
void __iomem *omap_ioremap(unsigned long p, size_t size, unsigned int type)
{
+
+ WARN(!initialized, Do not use ioremap before init_early\n);
+
#ifdef CONFIG_ARCH_OMAP1
if (cpu_class_is_omap1()) {
if (BETWEEN(p, OMAP1_IO_PHYS, OMAP1_IO_SIZE))
@@ -139,3 +144,8 @@ void omap_iounmap(volatile void __iomem *addr)
__iounmap(addr);
}
EXPORT_SYMBOL(omap_iounmap);
+
+void __init omap_ioremap_init(void)
+{
+ initialized++;
+}
--
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/7] ARM: OMAP: Remove calls to SRAM allocations for framebuffer
This assumes fixed mappings which will not work once we move
to use ioremap_exec(). It seems that these are currently
not in use, or in use for some out of tree corner cases.
If SRAM support for framebuffer is wanted, it should be done
with ioremap in the driver.
Note that further removal of the code can now be done,
but that can be done seprately by the driver maintainers.
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/sram.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 363c91e..3c8aa44 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -19,7 +19,6 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
-#include linux/omapfb.h
#include asm/tlb.h
#include asm/cacheflush.h
@@ -29,10 +28,8 @@
#include plat/sram.h
#include plat/board.h
#include plat/cpu.h
-#include plat/vram.h
#include sram.h
-#include fb.h
/* XXX These sideways includes are a sign that something is wrong */
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
@@ -112,8 +109,6 @@ static int is_sram_locked(void)
*/
static void __init omap_detect_sram(void)
{
- unsigned long reserved;
-
if (cpu_class_is_omap2()) {
if (is_sram_locked()) {
if (cpu_is_omap34xx()) {
@@ -170,17 +165,6 @@ static void __init omap_detect_sram(void)
omap_sram_size = 0x4000;
}
}
- reserved = omapfb_reserve_sram(omap_sram_start, omap_sram_base,
- omap_sram_size,
- omap_sram_start + SRAM_BOOTLOADER_SZ,
- omap_sram_size - SRAM_BOOTLOADER_SZ);
- omap_sram_size -= reserved;
-
- reserved = omap_vram_reserve_sram(omap_sram_start, omap_sram_base,
- omap_sram_size,
- omap_sram_start + SRAM_BOOTLOADER_SZ,
- omap_sram_size - SRAM_BOOTLOADER_SZ);
- omap_sram_size -= reserved;
omap_sram_ceil = omap_sram_base + omap_sram_size;
}
--
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] omap: dmtimer: convert printk to pr_err
On Fri, 2011-10-07 at 20:18 +0100, Russell King - ARM Linux wrote: On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote: At some point in the next couple of years, I want to convert all of, or as many as possible of, the remaining printk uses to pr_level. If the idea is also to get rid of printk() too (which IMHO would be a good thing as it kills off the constant need to continually patch for missing KERN_ prefixes) then that's a good reason (provided Linus accepts the idea.) I don't accept that idea yet. There are about 50K printks vs 20K pr_levels in kernel source. I think 50K lines is _way_ too many to convert in a couple of years. I think it needs to be done subsystem by subsystem, arch by arch, as maintainers accept. And there's no hurry. I have a script that automates most all of the conversions, argument alignments, etc. -- 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] omap: dmtimer: convert printk to pr_err
On Fri, Oct 07, 2011 at 12:48:21PM -0700, Joe Perches wrote: On Fri, 2011-10-07 at 20:18 +0100, Russell King - ARM Linux wrote: On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote: At some point in the next couple of years, I want to convert all of, or as many as possible of, the remaining printk uses to pr_level. If the idea is also to get rid of printk() too (which IMHO would be a good thing as it kills off the constant need to continually patch for missing KERN_ prefixes) then that's a good reason (provided Linus accepts the idea.) I don't accept that idea yet. There are about 50K printks vs 20K pr_levels in kernel source. I think 50K lines is _way_ too many to convert in a couple of years. I think it needs to be done subsystem by subsystem, arch by arch, as maintainers accept. Agreed - but doing one instance here, maybe another instance somewhere else, and come the merge window having several of these patches scattered around with no real coherent this is what we're doing, and its all done for this bit of the tree kind of story is not the way to do it. It would be good to get core code done, or a sub-arch, and then say we're not accepting any patch which re-introduces the problem... It's a little late in the cycle for that now though. -- 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/7] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
* Tony Lindgren t...@atomide.com [111007 12:11]:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
FYI this I've sent to Russell's patch system:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7126/1
Regards,
Tony
---
arch/arm/include/asm/io.h |1 +
arch/arm/mm/ioremap.c | 21 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d66605d..4ff152e 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long,
size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t,
unsigned int);
extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, int cached);
extern void __iounmap(volatile void __iomem *addr);
/*
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..a2d94ac 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,27 @@ __arm_ioremap(unsigned long phys_addr, size_t size,
unsigned int mtype)
}
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
+ return __arm_ioremap_caller(phys_addr, size, mtype,
+ __builtin_return_address(0));
+}
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK (unsigned long)io_addr);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] omap: dmtimer: convert printk to pr_err
On Fri, 2011-10-07 at 20:57 +0100, Russell King - ARM Linux wrote: On Fri, Oct 07, 2011 at 12:48:21PM -0700, Joe Perches wrote: I think it needs to be done subsystem by subsystem, arch by arch, as maintainers accept. Agreed - but doing one instance here, maybe another instance somewhere else, and come the merge window having several of these patches scattered around with no real coherent this is what we're doing, and its all done for this bit of the tree kind of story is not the way to do it. It would be good to get core code done, or a sub-arch, and then say we're not accepting any patch which re-introduces the problem... It's a little late in the cycle for that now though. Well, if you want it done for arch/arm, just let me know when it would be convenient for you and I'll do them all as a single patch. -- 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: OMAP1: Fix warnings about enabling 32 KiHz timer
* Tony Lindgren t...@atomide.com [111006 16:38]: Fix Enable 32kHz OS timer in order to allow sleep states in idle warning. We are now compiling in bothe MPU timer and 32 KiHz timer, so this warning is only valid when CONFIG_OMAP_32K_TIMER is not set. -#ifdef CONFIG_OMAP_MPU_TIMER +#if defined(CONFIG_OMAP_MPU_TIMER) !defined(CONFIG_OMAP_32K_TIMER) #warning Enable 32kHz OS timer in order to allow sleep states in idle use_idlect1 = use_idlect1 ~(1 9); #else This should be !defined(CONFIG_OMAP_DM_TIMER) instead of CONFIG_OMAP_32K timer. Corrected patch below. Tony From: Tony Lindgren t...@atomide.com Date: Thu, 6 Oct 2011 17:05:51 -0700 Subject: [PATCH] ARM: OMAP1: Fix warnings about enabling 32 KiHz timer Fix Enable 32kHz OS timer in order to allow sleep states in idle warning. We are now compiling in bothe MPU timer and 32 KiHz timer, so this warning is only valid when MPU_TIMER is set and OMAP_DM_TIMER is not set. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c index 495b398..89ea20c 100644 --- a/arch/arm/mach-omap1/pm.c +++ b/arch/arm/mach-omap1/pm.c @@ -116,7 +116,7 @@ void omap1_pm_idle(void) return; } -#ifdef CONFIG_OMAP_MPU_TIMER +#if defined(CONFIG_OMAP_MPU_TIMER) !defined(CONFIG_OMAP_DM_TIMER) #warning Enable 32kHz OS timer in order to allow sleep states in idle use_idlect1 = use_idlect1 ~(1 9); #else -- 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] omap fixes for -rc series and merge window
On Friday 07 October 2011, Tony Lindgren wrote: Then merge all the -rc fixes for various ARM platforms with: $ git checkout fixes-for-rc $ git reset --hard v3.1-rc9 $ git merge omap/fixes-for-rc soc foo/fixes-for-rc bar/fixes-for-rc And then no rebasing is needed. Of course I could also set up a separate fixes-for-rc for that if you prefrer that :) Right, that works. I normally have a 'fixes' branch for the current release and a 'next/fixes' branch for stuff that should wait for the merge window. Unfortunately, some of the stuff I already merged into 'fixes' turned out not to be 3.1 material after all. Adding a third branch of course works, so I can do that tomorrow. Thanks for the suggestion. Arnd -- 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: ARM SoC tree: OMAP PM dependency on tip irq/core
On Friday 07 October 2011, Thomas Gleixner wrote: For your internal dependecies, yes. But for irq/core you don't have to wait. You just need to tell Linus in the pull request that you pulled my branch with my ack as it contains modifications which are prerequisite for arm/whatever. When I send my pull request later, then this wont do any damage as Linus has the commits already. Same the other way round. We do that all the time, otherwise pull dependencies would be a nightmare. Ok, makes sense. Thanks, Arnd -- 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/2] OMAP: Update nr_irqs field in machine descriptors
On Thu, 6 Oct 2011, Tony Lindgren wrote: * S, Venkatraman svenk...@ti.com [110825 07:23]: On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? Currently, the goal is to get rid of the singleton nature of NR_IRQS. Then it just becomes a property of the platform, and the arm common code should not see this define. This cleanup has to be done across multiple SoCs, not just OMAP. After I get to complete some meaningful cleanup of NR_IRQS, I can look into the static defines that you mention. I suggest we wait on this patch as the NR_IRQS should be the board specific true number of interrupts including chained interrupts from external devices like twl. So just setting it to NR_IRQS does not help much. Also, the board-*.c files will be going aways with device tree at some point. This is prerequisite to some other cleanup orthogonal to DT being worked in parallel. I would prefer if DT wasn't a serialization point for this. Nicolas
Re: [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec()
On Fri, 7 Oct 2011, Santosh Shilimkar wrote: I have reviewed and tested this series. No problems seen. As asked on other thread, if you are targeting this one for 3.2, then sram changes would have a small conflict with OMAP4 errata patch. If it is for 3.3, we should be able to sort out that conflict easily. 3.2 please. I've postponed one of my series to 3.3 because it breaks OMAP unless those changes are applied first. Nicolas -- 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 7/7] ARM: OMAP: Warn if omap_ioremap is called before SoC detection
On Fri, 7 Oct 2011, Tony Lindgren wrote:
We don't have cpu_is_omap SoC detection initialized until
SoC detection is initialized from init_early.
Note that with the common map_io we should no longer need
cpu_is_omap for ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
---
arch/arm/mach-omap1/io.c |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/plat-omap/include/plat/io.h |2 ++
arch/arm/plat-omap/io.c | 10 ++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 8140a4e..fd9eb09 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -121,6 +121,7 @@ void __init omap16xx_map_io(void)
void omap1_init_early(void)
{
omap_check_revision();
+ omap_ioremap_init();
/* REVISIT: Refer to OMAP5910 Errata, Advisory SYS_1: Timeout Abort
* on a Posted Write in the TIPB Bridge.
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d5caac3..aa96538 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,6 +323,7 @@ void __iomem *omap_irq_base;
static void __init omap_common_init_early(void)
{
omap2_check_revision();
+ omap_ioremap_init();
}
static void __init omap_hwmod_init_postsetup(void)
diff --git a/arch/arm/plat-omap/include/plat/io.h
b/arch/arm/plat-omap/include/plat/io.h
index c0c7850..5ffbea6 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -247,6 +247,8 @@
* NOTE: Please use ioremap + __raw_read/write where possible instead of
these
*/
+void omap_ioremap_init(void);
+
extern u8 omap_readb(u32 pa);
extern u16 omap_readw(u32 pa);
extern u32 omap_readl(u32 pa);
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index f1ecfa9..1bbcbde 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -23,11 +23,16 @@
#define BETWEEN(p,st,sz) ((p) = (st) (p) ((st) + (sz)))
#define XLATE(p,pst,vst) ((void __iomem *)((p) - (pst) + (vst)))
+static int initialized;
+
/*
* Intercept ioremap() requests for addresses in our fixed mapping regions.
*/
void __iomem *omap_ioremap(unsigned long p, size_t size, unsigned int type)
{
+
+ WARN(!initialized, Do not use ioremap before init_early\n);
+
#ifdef CONFIG_ARCH_OMAP1
if (cpu_class_is_omap1()) {
if (BETWEEN(p, OMAP1_IO_PHYS, OMAP1_IO_SIZE))
@@ -139,3 +144,8 @@ void omap_iounmap(volatile void __iomem *addr)
__iounmap(addr);
}
EXPORT_SYMBOL(omap_iounmap);
+
+void __init omap_ioremap_init(void)
+{
+ initialized++;
+}
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
Paul Walmsley p...@pwsan.com writes: The way that we detect which OMAP3 chips support I/O wakeup and software I/O chain clock control is broken. Currently, I/O wakeup is marked as present for all OMAP3 SoCs other than the AM3505/3517. The TI81xx family of SoCs are at present considered to be OMAP3 SoCs, but don't support I/O wakeup. To resolve this, convert the existing blacklist approach to an explicit, whitelist support, in which only SoCs which are known to support I/O wakeup are listed. (At present, this only includes OMAP34xx, OMAP3503, OMAP3515, OMAP3525, OMAP3530, and OMAP36xx.) Also, the current code incorrectly detects the presence of a software-controllable I/O chain clock on several chips that don't support it. This results in writes to reserved bitfields, unnecessary delays, and console messages on kernels running on those chips: http://www.spinics.net/lists/linux-omap/msg58735.html Convert this test to a feature test with a chip-by-chip whitelist. Thanks to Dave Hylands dhyla...@gmail.com for reporting this problem and doing some testing to help isolate the cause. Thanks to Steve Sakoman sako...@gmail.com for catching a bug in the first version of this patch. Thanks to Russell King li...@arm.linux.org.uk for comments. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Dave Hylands dhyla...@gmail.com Cc: Steve Sakoman sako...@gmail.com Tested-by: Steve Sakoman sako...@gmail.com Cc: Russell King - ARM Linux li...@arm.linux.org.uk --- This version incorporates some comments from RMK - an unnecessary set of parentheses are removed and a two-part error message string is joined. Also, the printk(KERN_ERR has been converted into a pr_err(. OK, looks like we made some parallel changes. Dropping my version and will queue this one (branch: for_3.2/pm-cleanup-2) 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: [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
* Nicolas Pitre n...@fluxnic.net [111007 12:41]: On Thu, 6 Oct 2011, Tony Lindgren wrote: * S, Venkatraman svenk...@ti.com [110825 07:23]: On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? Currently, the goal is to get rid of the singleton nature of NR_IRQS. Then it just becomes a property of the platform, and the arm common code should not see this define. This cleanup has to be done across multiple SoCs, not just OMAP. After I get to complete some meaningful cleanup of NR_IRQS, I can look into the static defines that you mention. I suggest we wait on this patch as the NR_IRQS should be the board specific true number of interrupts including chained interrupts from external devices like twl. So just setting it to NR_IRQS does not help much. Also, the board-*.c files will be going aways with device tree at some point. This is prerequisite to some other cleanup orthogonal to DT being worked in parallel. I would prefer if DT wasn't a serialization point for this. I see. How about let's populate the real number of interrupts for the known boards then while at it. 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 2/5] drivercore: Add driver probe deferral mechanism
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote: On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote: +config PROBE_DEFER + bool Deferred Driver Probe + default y + help + This option provides deferring driver probe if it has dependency on + other driver. Without this feature, initcall ordering should be done + manually to resolve driver dependencies. This feature completely side + steps the issues by allowing driver registration to occur in any + order, and any driver can request to be retried after a few more other + drivers get probed. Why is this even an option? Why would you ever want it disabled? Why does it need to be selected? If you are going to default something to 'y' then just make it so it can't be turned off any other way by just not making it an option at all. Given that the drivers which use this mechanism will not necessarily get built into the kernel, I'd suggest that it should remain optional and default to n. Those drivers can then add a dependency on PROBE_DEFER. Let's try to avoid adding more infrastructure to the kernel that takes up space even when unused; certainly embedded will appreciate not having this feature unless a driver needs it. (That said, it still feels to me like an explicit dependency mechanism would make more sense than this try again later mechanism, but nonetheless try again later seems like an improvement over what we have now.) It also cleans up this diff a lot, as you really don't want #ifdef in .c files. Ideally the entire .c file could become conditional on PROBE_DEFER via kbuild, with the usual compatibility inlines in a .h file for the !PROBE_DEFER case. - Josh Triplett -- 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] OMAP: few more PM cleanup/fixes for v3.2
Tony, Please pull the (hopefully) last few PM fixes/cleanups for v3.2. Kevin The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84: Linux 3.1-rc9 (2011-10-04 18:11:50 -0700) are available in the git repository at: git://github.com/khilman/linux-omap-pm.git for_3.2/pm-cleanup-2 Charulatha V (1): ARM: OMAP3: PM: fix pwrdm_post_transition call sequence Paul Walmsley (2): ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only arch/arm/mach-omap2/id.c |5 ++- arch/arm/mach-omap2/pm34xx.c | 70 +--- arch/arm/plat-omap/include/plat/cpu.h | 17 ++-- 3 files changed, 53 insertions(+), 39 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote: On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote: On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote: +config PROBE_DEFER + bool Deferred Driver Probe + default y + help + This option provides deferring driver probe if it has dependency on + other driver. Without this feature, initcall ordering should be done + manually to resolve driver dependencies. This feature completely side + steps the issues by allowing driver registration to occur in any + order, and any driver can request to be retried after a few more other + drivers get probed. Why is this even an option? Why would you ever want it disabled? Why does it need to be selected? If you are going to default something to 'y' then just make it so it can't be turned off any other way by just not making it an option at all. Given that the drivers which use this mechanism will not necessarily get built into the kernel, I'd suggest that it should remain optional and default to n. Those drivers can then add a dependency on PROBE_DEFER. Let's try to avoid adding more infrastructure to the kernel that takes up space even when unused; certainly embedded will appreciate not having this feature unless a driver needs it. How much extra space is this feature really? I don't see it being anything larger than the amount of memory increase that just happened as I typed this email as part of the ongoing memory density changes. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
On Fri, Oct 7, 2011 at 12:49 AM, Greg KH g...@kroah.com wrote: On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote: +config PROBE_DEFER + bool Deferred Driver Probe + default y + help + This option provides deferring driver probe if it has dependency on + other driver. Without this feature, initcall ordering should be done + manually to resolve driver dependencies. This feature completely side + steps the issues by allowing driver registration to occur in any + order, and any driver can request to be retried after a few more other + drivers get probed. Why is this even an option? Why would you ever want it disabled? Why does it need to be selected? If you are going to default something to 'y' then just make it so it can't be turned off any other way by just not making it an option at all. It also cleans up this diff a lot, as you really don't want #ifdef in .c files. Okay, we'll drop the kconfig + * This bit is tricky. We want to process every device in the + * deferred list, but devices can be removed from the list at any + * time while inside this for-each loop. There are two things that + * need to be protected against: That's what the klist structure is supposed to make easier, why not use that here? + * - if the device is removed from the deferred_probe_list, then we + * loose our place in the loop. Since any device can be removed + * asynchronously, list_for_each_entry_safe() wouldn't make things + * much better. Simplest solution is to restart walking the list + * whenever the current device gets removed. Not the most efficient, + * but is simple to implement and easy to audit for correctness. + * - if the device is unregistered, and freed, then there is a risk + * of a null pointer dereference. This code uses get/put_device() + * to ensure the device cannot disappear from under our feet. Ick, use a klist, it was created to handle this exact problem in the driver core, so to not use it would be wrong, right? This comment block is stale. I reworked the code before I handed it off to Manjunath, but I never rewrote the comment. The current code uses a pair of list to keep deferred devices separate from devices currently being probed, and the problem described above no longer exists. However, Manjunath and I will look into switching from the two list design to using klist. Thanks for the feedback. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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/5] gpiolib: handle deferral probe error
On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Fri, 07 Oct 2011 10:33:09 +0500 G, Manjunath Kondaiah manj...@ti.com wrote: The gpio library should return -EPROBE_DEFER in gpio_request if gpio driver is not ready. Why not use the perfectly good existing error codes we have for this ? We have EAGAIN and EUNATCH both of which look sensible. I want a distinct error code for probe deferral so that a) it doesn't overlap with something a driver is already doing, and b) so that all the users can be found again at a later date. That said, I'm not in agreement with this patch. It is fine for gpio lib to have a code that means the pin doesn't exist (yet), but the device driver needs to be the one to decide whether or not it is appropriate to use probe deferral. 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/5] drivercore: add new error value for deferred probe
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH g...@kroah.com wrote: On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote: Add new error value so that drivers can request deferred probe from drivercore. Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Reported-by: Grant Likely grant.lik...@secretlab.ca --- Cc: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Greg Kroah-Hartman g...@kroah.com Cc: Dilan Lee di...@nvidia.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Manjunath GKondaiah manjunath.gkonda...@linaro.org Cc: Arnd Bergmann a...@arndb.de include/linux/errno.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/errno.h b/include/linux/errno.h index 4668583..83d8fcf 100644 --- a/include/linux/errno.h +++ b/include/linux/errno.h @@ -16,6 +16,7 @@ #define ERESTARTNOHAND 514 /* restart if no handler.. */ #define ENOIOCTLCMD 515 /* No ioctl command */ #define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */ +#define EPROBE_DEFER 517 /* restart probe again after some time */ Can we really do this? According to Arnd, yes this is okay. Isn't this some user/kernel api here? What's wrong with just overloading on top of an existing error code? Surely one of the other 516 types could be used here, right? overloading makes it really hard to find the users at a later date. 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 v2 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
Hi Paul, On 10/6/2011 20:40, Paul Walmsley wrote: On Fri, 16 Sep 2011, Jon Hunter wrote: From: Jon Hunterjon-hun...@ti.com The OMAP36xx and OMAP4xxx DPLLs have a different internal reference clock frequency (fint) operating range than OMAP3430. Update the dpll_test_fint() function to check for the correct frequency ranges for OMAP36xx and OMAP4xxx. For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to 2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all other DPLLs. Signed-off-by: Jon Hunterjon-hun...@ti.com This looks okay to me for now - queued for 3.2. Ideally we would move the Fint DPLL data to the struct dpll_data, but this would be a fairly significant undertaking, since we don't have a clean way to use different dpll_data for different OMAP3 variants. Something good to keep in mind for the common clock conversion. You know at first I was thinking about adding this to the dpll_data struct, but then I thought these ranges only change for a couple dplls and so adding a few more members to each dpll struct was bloating the struct and making this a massive change. So I went the other path and just added a couple defines to minimise the changes. However, we could definitely do that if it is preferred and if with next-gen devices (such as omap5) more dplls have different ranges then this would make more sense too. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
On Fri, 7 Oct 2011, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111007 12:41]: On Thu, 6 Oct 2011, Tony Lindgren wrote: * S, Venkatraman svenk...@ti.com [110825 07:23]: On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? Currently, the goal is to get rid of the singleton nature of NR_IRQS. Then it just becomes a property of the platform, and the arm common code should not see this define. This cleanup has to be done across multiple SoCs, not just OMAP. After I get to complete some meaningful cleanup of NR_IRQS, I can look into the static defines that you mention. I suggest we wait on this patch as the NR_IRQS should be the board specific true number of interrupts including chained interrupts from external devices like twl. So just setting it to NR_IRQS does not help much. Also, the board-*.c files will be going aways with device tree at some point. This is prerequisite to some other cleanup orthogonal to DT being worked in parallel. I would prefer if DT wasn't a serialization point for this. I see. How about let's populate the real number of interrupts for the known boards then while at it. Sure, if you know what you are doing (which I'm sure you do). Otherwise using NR_IRQS is more or less a functional no-op wrt the current situation, and therefore what I would have used myself because I don't know much about the various OMAP boards. Nicolas
