Re: [PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
On Wednesday 20 March 2013 08:58 PM, Tomi Valkeinen wrote:
On 2013-03-20 17:17, Archit Taneja wrote:
On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
Add new way to iterate over DSS clock divisors. dss_div_calc() provides
a generic way to go over all the divisors, within given clock range.
dss_div_calc() will call a callback function for each divider set,
making the function reusable for all use cases.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 36
drivers/video/omap2/dss/dss.h |3 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c
b/drivers/video/omap2/dss/dss.c
index 054c2a2..21a3dc8 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -473,6 +473,42 @@ int dss_calc_clock_rates(struct dss_clock_info
*cinfo)
return 0;
}
+bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void
*data)
+{
+int fckd, fckd_start, fckd_stop;
+unsigned long fck;
+unsigned long fck_hw_max;
+unsigned long fckd_hw_max;
+unsigned long prate;
+
+if (dss.dpll4_m4_ck == NULL) {
+/* XXX can we change the clock on omap2? */
We can change dss_fclk1 on omap2, and the cclock2420_data.c and
cclock2430_data.c have clksel structs which allow a set of dividers. The
dividers are not continuous though, 1 to 12 and 16 are allowed. So we
might need to change the code here a bit, if we want to change the clock
in the first place.
Ok, good to know. Note that the comment is copied from the old code. I
think I tried changing the clock on N800 with clk_set_rate long ago, but
I didn't get it to work. Things might have changed, but, well, I don't
think we should spend time on omap2 code. I'm sure we'll get a patch if
somebody needs it =).
We could change the comment to a TODO for now.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] ARM: dts: omap: update usb_otg_hs data
Hi, On Thursday 21 March 2013 02:29 AM, Stephen Warren wrote: On 03/20/2013 03:12 AM, Kishon Vijay Abraham I wrote: Updated the usb_otg_hs dt data to include the *phy* and *phy-names* binding in order for the driver to use the new generic PHY framework. Also updated the Documentation to include the binding information. diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index abce256..3d6f9f6 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -19,6 +19,9 @@ OMAP MUSB GLUE - power : Should be 50. This signifies the controller can supply upto 100mA when operating in host mode. - usb-phy : the phandle for the PHY device + - phy : the phandle for the PHY device (used by generic PHY framework) + - phy-names : the names of the PHY corresponding to the PHYs present in the + *phy* phandle. If the intent is for those properties to be generic and used by any DT binding that refers to a PHY node, I think you'd want to define those properties in e.g. Documentation/devicetree/bindings/phy/phy.txt, just like common clock/GPIO/... properties are defined in standalone common files. Ok. Will add it. I think you want to require that DT nodes that represent PHYs have a #phy-cells property, and that the format of the phy property be phy_phandle phy_specifier*, where #phy-cells in the referenced node defines how many cells are part of phy_specifier*, just like (almost) any other DT property that references another node by phandle. That way, if a single DT node represents a HW block that implements e.g. 3 PHYs, it can use #phy-cells = 1, and the referencing phy property can include a cell that indicates which of those 3 PHYs is being referenced. Currently, if a single phandle have reference to multiple PHYs, we can get PHY by passing index or by name as give in phy-names. I'm not sure if we have phy_phandle phy_specifier*, what could that phy_specifier be? Maybe phy_type? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
On 2013-03-21 08:14, Archit Taneja wrote:
On Wednesday 20 March 2013 08:58 PM, Tomi Valkeinen wrote:
On 2013-03-20 17:17, Archit Taneja wrote:
On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote:
+if (dss.dpll4_m4_ck == NULL) {
+/* XXX can we change the clock on omap2? */
We can change dss_fclk1 on omap2, and the cclock2420_data.c and
cclock2430_data.c have clksel structs which allow a set of dividers. The
dividers are not continuous though, 1 to 12 and 16 are allowed. So we
might need to change the code here a bit, if we want to change the clock
in the first place.
Ok, good to know. Note that the comment is copied from the old code. I
think I tried changing the clock on N800 with clk_set_rate long ago, but
I didn't get it to work. Things might have changed, but, well, I don't
think we should spend time on omap2 code. I'm sure we'll get a patch if
somebody needs it =).
We could change the comment to a TODO for now.
Yep, not a bad idea. I'll make the change.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
Hi Frank, On Thu, Mar 21, 2013 at 11:29 AM, Frank Rowand frank.row...@am.sony.com wrote: I found the problem on 3.6.11, but have not replicated it on 3.9-rcX yet because my config fails to build on 3.9-rc1 and 3.9-rc2. I'll try to work on that issue tomorrow. I play upstream kernel on Pandaboard A1 frequently, looks not see the failure problem before. Maybe the problem is config dependent. If you may share your config file, I'd like to do the test too. Thanks, -- Ming Lei -- 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/6] OF: Introduce Device Tree resolve support.
Hi Grant, On Mar 19, 2013, at 7:18 PM, Grant Likely wrote: On Tue, 19 Mar 2013 13:51:01 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, On Mar 16, 2013, at 11:24 AM, Grant Likely wrote: On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi David, On Jan 23, 2013, at 6:40 AM, David Gibson wrote: Ok. Nonetheless it's not hard to avoid a recursive approach here. How can I find the maximum phandle value of a subtree without using recursion. Note that the whole function is just 6 lines long. It's a failure in the existing kernel DT data structures. We need a hash lookup for the phandles to eliminate the search entirely. Then you'd be able to allocated new phandles on the fly easily and resolve phandles without searching the whole tree (which has always been horrible). Yes, it is pretty obvious that the in-kernel data structures are sub-optimal. But I was not after modifying them, since that's a different kind of problem. Think about it this way; fixing up that aspect of the data structure makes the job you're trying to do a lot easier. I don't feel bad about asking you to add a radix tree for phandle lookups when it makes your patches a whole lot better. :-) Oh that's going to be fun... maybe. Since we're having a 'sub-optimal' data structures, I'd like to point out that the usage of of_find_by_name(), mostly by drivers trying to find a child of their own node, works by a lucky accident of how the device nodes are instantiated by the flat tree loader. Most of the use cases should be replaced by a call to of_get_child_by_name() which does the right thing. It is true. In fact, calling of_find_node_by_name() when using .dtb is most likely a bug since using node name to determine behaviour is strongly discouraged. Maybe mark the function as deprecated then? Easier to get people to fix it. Fair enough, but be warned that phandle resolution the overlay feature is mostly useless. In actual practice the amount of driver nodes that can be overlaid without a single case of referencing phandles outside (or within) their own blob is close to zero. That's not what I'm saying. I'm saying that (at least for now) we should require the overlay to already know the phandles from the parent and to refuse to load an overlay that defines phandles already in use in the base. Overlays do become usable at that point. A mechanism for phandle resolution so that conflicts can be found and resolved can be added as a feature enhancement. By splitting it out you'll be able to get the overlay feature merged even if we don't have agreement on the resolution mechanism yet. As long as we don't come up with something that's too difficult to use for non kernel developers. I would hate to punt and push all the complexity of phandle resolution to the driver/cape developer. FWIW, the resolution mechanism we use on the beaglebone seems to work just fine, and people seem to handle it just fine. The part that trips them is mostly how to install the updated dtc compiler that's required. g. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
clk inits on OMAP happen quite early, even before slab is available. The dependency comes from the fact that the timer init code starts to use clocks and hwmod and we need clocks to be initialized by then. There are various problems doing clk inits this early, one is, not being able to do dynamic clk registrations and hence the dependency on clk-private.h. The other is, inability to debug early kernel crashes without enabling DEBUG_LL and earlyprintk. Doing early clk init also exposed another instance of a kernel panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled. [0.00] Kernel BUG at c01174f8 [verbose debug info unavailable] [0.00] Internal error: Oops - BUG: 0 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.9.0-rc1-12179-g72d48f9 #6) [0.00] PC is at __kmalloc+0x1d4/0x248 [0.00] LR is at __clk_init+0x2e0/0x364 [0.00] pc : [c01174f8]lr : [c0441f54]psr: 61d3 [0.00] sp : c076ff28 ip : c065cefc fp : c0441f54 [0.00] r10: 001c r9 : 80d0 r8 : c076ffd4 [0.00] r7 : c074b578 r6 : c0794d88 r5 : 0040 r4 : [0.00] r3 : r2 : c07cac70 r1 : 80d0 r0 : 001c [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c53c7d Table: 8000404a DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc076e240) [0.00] Stack: (0xc076ff28 to 0xc077) [0.00] ff20: c0794ec8 c06546e8 0040 c0794d88 [0.00] ff40: c074b578 c076ffd4 c07951c8 c076e000 c0441f54 c074b578 c076ffd4 [0.00] ff60: c0793828 0040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac [0.00] ff80: 2f80 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 [0.00] ffa0: 0001 c074cd6c c077b1ec 8000406a c0715724 [0.00] ffc0: c074c968 10c53c7d c0776974 [0.00] ffe0: c074cd6c c077b1ec 8000406a 411fc092 80008074 [0.00] [c01174f8] (__kmalloc+0x1d4/0x248) from [c0441f54] (__clk_init+0x2e0/0x364) [0.00] [c0441f54] (__clk_init+0x2e0/0x364) from [c07272ac] (omap4xxx_clk_init+0xbc/0x140) [0.00] [c07272ac] (omap4xxx_clk_init+0xbc/0x140) from [c0719780] (setup_arch+0x15c/0x284) [0.00] [c0719780] (setup_arch+0x15c/0x284) from [c0715724] (start_kernel+0x7c/0x334) [0.00] [c0715724] (start_kernel+0x7c/0x334) from [80008074] (0x80008074) [0.00] Code: e5883004 e1a6 e28dd00c e8bd8ff0 (e7f001f2) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! It was a know issue, that slab allocations would fail when common clock core tries to cache parent pointers for mux clocks on OMAP, and hence a patch 'clk: Allow late cache allocation for clk-parents, commit 7975059d' was added to work this problem around. A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely overlooked causing this regression. More details on the issue reported can be found here, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html With all these issues around clk inits happening way too early, it makes sense to atleast move them to a point where dynamic memory allocations are possible. So move them to a point just before the timer code starts using clocks and hwmod. This should atleast pave way for clk inits on OMAP moving to dynamic clock registrations instead of using the static macros defined in clk-private.h. The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled was reported by Piotr Haber and Tony Lindgren and this patch fixes the reported issue as well. Reported-by: Piotr Haber pha...@broadcom.com Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Rajendra Nayak rna...@ti.com --- applies on 3.9-rc3 and tested on omap4 pandaES, omap3 beagle XM, and am335x bone. v2: updated changelog based on comments from Tony Lindgren arch/arm/mach-omap2/common.h |3 +++ arch/arm/mach-omap2/io.c | 18 -- arch/arm/mach-omap2/timer.c |4 3 files changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 40f4a03..d6ba13e 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -293,5 +293,8 @@ extern void omap_reserve(void); struct omap_hwmod; extern int omap_dss_reset(struct omap_hwmod *); +/* SoC specific clock initializer */ +extern int (*omap_clk_init)(void); + #endif /* __ASSEMBLER__ */ #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */ diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 2c3fdd6..5c445ca 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -55,6 +55,12 @@ #include prm44xx.h /* + *
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
Hi Rob,
(adding Marc to Cc as he may have comments).
On Wed, Mar 20, 2013 at 10:34:35PM +, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.
This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.
Nice! I was just about to post a (slightly updated) version of Thomas Abraham's
arch_timer clocksource_of_init patch, but this seems much more comprehensive.
I have some other arch_timer patches which may clash, but they could be rebased
atop of this.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Kukjin Kim kgene@samsung.com
Cc: Tony Lindgren t...@atomide.com
Cc: Simon Horman ho...@verge.net.au
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: John Stultz john.stu...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux...@vger.kernel.org
---
This is dependent on my CLKSRC_OF clean-up in arm-soc, my 64-bit sched_clock
support series, and Arnd's default machine descriptor patch (for default
clocksource_of_init call). This is only compile tested on arm.
The full series (including sp804 work) is available here:
git://sources.calxeda.com/kernel/linux.git arm-timers
Rob
[...]
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index d0ad789..6215717 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -1,6 +1,7 @@
/*
* Versatile Express V2M Motherboard Support
*/
+#include linux/clocksource.h
#include linux/device.h
#include linux/amba/bus.h
#include linux/amba/mmci.h
@@ -23,7 +24,6 @@
#include linux/regulator/machine.h
#include linux/vexpress.h
-#include asm/arch_timer.h
#include asm/mach-types.h
#include asm/sizes.h
#include asm/mach/arch.h
@@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
irq_of_parse_and_map(node, 0));
}
- arch_timer_of_register();
-
- if (arch_timer_sched_clock_init() != 0)
- versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
+ versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
2400);
}
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
Switching to timer-based delay loop
Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
As they both have the same frequency, neither overrides the other, and
whichever gets registered last is used as the sched_clock. As accesses to the
architected timer are going to have a much lower overhead, this isn't very nice
(and it could be better to use it even if it had a lower frequency).
We could move the versatile_sched_clock_init call before the
clocksource_of_init, but that doesn't feel like an ideal solution. We may have
similar problems elsewhere.
[...]
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index b0ef18d..a551f88 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -32,6 +32,7 @@
#include linux/timer.h
#include linux/irq.h
#include linux/delay.h
+#include linux/clocksource.h
#include clocksource/arm_arch_timer.h
@@ -77,10 +78,11 @@ void __init time_init(void)
{
u32 arch_timer_rate;
- if (arch_timer_init())
- panic(Unable to initialise architected timer.\n);
+ clocksource_of_init();
arch_timer_rate = arch_timer_get_rate();
+ if (!arch_timer_rate)
+ panic(Unable to initialise architected timer.\n);
/* Cache the sched_clock multiplier to save a divide in the hot path.
*/
sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e507ab7..d98e7e1 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -62,6 +62,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
config ARM_ARCH_TIMER
bool
+ select CLKSRC_OF if OF
config CLKSRC_METAG_GENERIC
def_bool y if METAG
[...]
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..afb70aa 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -337,24 +337,11 @@ out:
return err;
}
-static const struct of_device_id
Re: [PATCH v2] ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
On Thursday 21 March 2013 04:34 PM, Rajendra Nayak wrote: clk inits on OMAP happen quite early, even before slab is available. The dependency comes from the fact that the timer init code starts to use clocks and hwmod and we need clocks to be initialized by then. There are various problems doing clk inits this early, one is, not being able to do dynamic clk registrations and hence the dependency on clk-private.h. The other is, inability to debug early kernel crashes without enabling DEBUG_LL and earlyprintk. Doing early clk init also exposed another instance of a kernel panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled. [0.00] Kernel BUG at c01174f8 [verbose debug info unavailable] [0.00] Internal error: Oops - BUG: 0 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.9.0-rc1-12179-g72d48f9 #6) [0.00] PC is at __kmalloc+0x1d4/0x248 [0.00] LR is at __clk_init+0x2e0/0x364 [0.00] pc : [c01174f8]lr : [c0441f54]psr: 61d3 [0.00] sp : c076ff28 ip : c065cefc fp : c0441f54 [0.00] r10: 001c r9 : 80d0 r8 : c076ffd4 [0.00] r7 : c074b578 r6 : c0794d88 r5 : 0040 r4 : [0.00] r3 : r2 : c07cac70 r1 : 80d0 r0 : 001c [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c53c7d Table: 8000404a DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc076e240) [0.00] Stack: (0xc076ff28 to 0xc077) [0.00] ff20: c0794ec8 c06546e8 0040 c0794d88 [0.00] ff40: c074b578 c076ffd4 c07951c8 c076e000 c0441f54 c074b578 c076ffd4 [0.00] ff60: c0793828 0040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac [0.00] ff80: 2f80 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 [0.00] ffa0: 0001 c074cd6c c077b1ec 8000406a c0715724 [0.00] ffc0: c074c968 10c53c7d c0776974 [0.00] ffe0: c074cd6c c077b1ec 8000406a 411fc092 80008074 [0.00] [c01174f8] (__kmalloc+0x1d4/0x248) from [c0441f54] (__clk_init+0x2e0/0x364) [0.00] [c0441f54] (__clk_init+0x2e0/0x364) from [c07272ac] (omap4xxx_clk_init+0xbc/0x140) [0.00] [c07272ac] (omap4xxx_clk_init+0xbc/0x140) from [c0719780] (setup_arch+0x15c/0x284) [0.00] [c0719780] (setup_arch+0x15c/0x284) from [c0715724] (start_kernel+0x7c/0x334) [0.00] [c0715724] (start_kernel+0x7c/0x334) from [80008074] (0x80008074) [0.00] Code: e5883004 e1a6 e28dd00c e8bd8ff0 (e7f001f2) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! It was a know issue, that slab allocations would fail when common clock core tries to cache parent pointers for mux clocks on OMAP, and hence a patch 'clk: Allow late cache allocation for clk-parents, commit 7975059d' was added to work this problem around. A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely overlooked causing this regression. More details on the issue reported can be found here, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html With all these issues around clk inits happening way too early, it makes sense to atleast move them to a point where dynamic memory allocations are possible. So move them to a point just before the timer code starts using clocks and hwmod. This should atleast pave way for clk inits on OMAP moving to dynamic clock registrations instead of using the static macros defined in clk-private.h. The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled was reported by Piotr Haber and Tony Lindgren and this patch fixes the reported issue as well. Reported-by: Piotr Haber pha...@broadcom.com Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Rajendra Nayak rna...@ti.com --- applies on 3.9-rc3 and tested on omap4 pandaES, omap3 beagle XM, and am335x bone. Acked-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] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 21/03/13 11:06, Mark Rutland wrote: Hi Rob, (adding Marc to Cc as he may have comments). On Wed, Mar 20, 2013 at 10:34:35PM +, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Nice! I was just about to post a (slightly updated) version of Thomas Abraham's arch_timer clocksource_of_init patch, but this seems much more comprehensive. I have some other arch_timer patches which may clash, but they could be rebased atop of this. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Russell King li...@arm.linux.org.uk Cc: Kukjin Kim kgene@samsung.com Cc: Tony Lindgren t...@atomide.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas Gleixner t...@linutronix.de Cc: linux-samsung-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux...@vger.kernel.org --- This is dependent on my CLKSRC_OF clean-up in arm-soc, my 64-bit sched_clock support series, and Arnd's default machine descriptor patch (for default clocksource_of_init call). This is only compile tested on arm. The full series (including sp804 work) is available here: git://sources.calxeda.com/kernel/linux.git arm-timers Rob [...] diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c index d0ad789..6215717 100644 --- a/arch/arm/mach-vexpress/v2m.c +++ b/arch/arm/mach-vexpress/v2m.c @@ -1,6 +1,7 @@ /* * Versatile Express V2M Motherboard Support */ +#include linux/clocksource.h #include linux/device.h #include linux/amba/bus.h #include linux/amba/mmci.h @@ -23,7 +24,6 @@ #include linux/regulator/machine.h #include linux/vexpress.h -#include asm/arch_timer.h #include asm/mach-types.h #include asm/sizes.h #include asm/mach/arch.h @@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void) irq_of_parse_and_map(node, 0)); } - arch_timer_of_register(); - - if (arch_timer_sched_clock_init() != 0) - versatile_sched_clock_init(vexpress_get_24mhz_clock_base(), + versatile_sched_clock_init(vexpress_get_24mhz_clock_base(), 2400); } On TC2 this series leads to using the vexpress 24MHz clock as the sched clock in preference to the architected timer: Architected local timer running at 24.00MHz (virt). Switching to timer-based delay loop Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source As they both have the same frequency, neither overrides the other, and whichever gets registered last is used as the sched_clock. As accesses to the architected timer are going to have a much lower overhead, this isn't very nice (and it could be better to use it even if it had a lower frequency). Indeed. And if I look at it with my KVM hat on, it is even worse (the guest will exit all the way to platform emulation in userspace on each sched_clock read - a sure performance killer). Of course, emulating a VE is not the best option, but that's all we have so far when using QEMU as platform emulation. M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: support deferred probing for GPIOs
On Thu, 2013-02-14 at 19:23 +0530, Balaji T K wrote: On Thursday 14 February 2013 04:13 PM, Jan Lübbe wrote: On Wed, 2013-01-30 at 10:07 +0100, Jan Luebbe wrote: If the CD/WP-GPIOs are not provided by the SoC's GPIO controller, we need to handle the case where omap_hsmmc is probed earlier than the GPIO controller chosen in the device tree. Fix this by checking the return value of of_get_named_gpio against -EPROBE_DEFER and passing it through to the probe function. Signed-off-by: Jan Luebbe j...@pengutronix.de Balaji, since you seem to be the new OMAP HSMMC maintainer, do you have any comments on this patch? Looks good to me, Acked-by: Balaji T K balaj...@ti.com Chris, would you take this? Thanks, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [PATCHv3 00/14] drivers: mailbox: framework creation
On Wed, Mar 13, 2013 at 4:23 AM, Suman Anna s-a...@ti.com wrote: Please find the updated mailbox patch series for pulling into linux-next. The series is rebased on top of 3.9-rc2, and includes one new patch to rename an existing mailbox.h added as part of the highbank cpufreq support for 3.9 merge window [1]. ARM SoC folks: would you consider pulling this stuff into the ARM SoC tree? It turns out that ux500 multiplatform support is sort of relying on this refactoring since it helps us to break apart the huge PRCMU driver. I am proceeding with my multiplatform work but things like this not being upstream will make the patches look ugly and I cannot quite consider it properly done before this is fixed too. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUGFIX PATCH] ARM: OMAP: fix type of return values in omap_device_get_by_hwmod_name()
The merge bda5e141fbe96295c669692114d18687730269fb erroneously changed
the return value of some error exits of omap_device_get_by_hwmod_name()
from ERR_PTR() to -ENODEV.
This fixes the warnings:
arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from
integer without a cast
arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from
integer without a cast
Signed-off-by: Lothar Waßmann l...@karo-electronics.de
---
arch/arm/mach-omap2/omap_device.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 2448c7a..eeea4fa 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -818,12 +818,12 @@ struct device *omap_device_get_by_hwmod_name(const char
*oh_name)
if (!oh) {
WARN(1, %s: no hwmod for %s\n, __func__,
oh_name);
- return -ENODEV;
+ return ERR_PTR(-ENODEV);
}
if (!oh-od) {
WARN(1, %s: no omap_device for %s\n, __func__,
oh_name);
- return -ENODEV;
+ return ERR_PTR(-ENODEV);
}
return oh-od-pdev-dev;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/21/2013 06:06 AM, Mark Rutland wrote:
Hi Rob,
(adding Marc to Cc as he may have comments).
On Wed, Mar 20, 2013 at 10:34:35PM +, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.
This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.
Nice! I was just about to post a (slightly updated) version of Thomas
Abraham's
arch_timer clocksource_of_init patch, but this seems much more comprehensive.
I have some other arch_timer patches which may clash, but they could be
rebased
atop of this.
[snip]
@@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
irq_of_parse_and_map(node, 0));
}
- arch_timer_of_register();
-
- if (arch_timer_sched_clock_init() != 0)
- versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
+ versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
2400);
}
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
Switching to timer-based delay loop
Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
As they both have the same frequency, neither overrides the other, and
whichever gets registered last is used as the sched_clock. As accesses to the
architected timer are going to have a much lower overhead, this isn't very
nice
(and it could be better to use it even if it had a lower frequency).
We could move the versatile_sched_clock_init call before the
clocksource_of_init, but that doesn't feel like an ideal solution. We may have
similar problems elsewhere.
The intention was that a 64-bit counter is preferred. This should fix
that. It would be nice if we could describe access overhead to make a decision.
For now, I think 32 vs. 64 bit is sufficient.
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 1708357..aa18e45 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -115,7 +115,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate)
u64 res, wrap;
char r_unit;
- if (cd.rate rate)
+ if (cd.rate rate || read_sched_clock_64)
return;
BUG_ON(bits 32);
@@ -168,7 +168,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate)
void __init setup_sched_clock_64(u64 (*read)(void), unsigned long rate)
{
- if (cd.rate rate)
+ if (read_sched_clock_64 (cd.rate rate))
return;
WARN_ON(!irqs_disabled());
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..afb70aa 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -337,24 +337,11 @@ out:
return err;
}
-static const struct of_device_id arch_timer_of_match[] __initconst = {
- { .compatible = arm,armv7-timer,},
- { .compatible = arm,armv8-timer,},
- {},
-};
-
-int __init arch_timer_init(void)
+static void __init arch_timer_init(struct device_node *np)
{
- struct device_node *np;
u32 freq;
int i;
If we the following here:
if (arch_timer_get_rate()) {
pr_warn(arch_timer: multiple nodes in dt, skipping\n);
return;
}
We may save ourselves a whole world of pain with dts which (erroneously) have
multiple timer nodes (though these are now disappearing). Otherwise we could
have a memory leak and multiple instances of the cpu0 timer registered, which
could lead to all sorts of weirdness. The existing code side-steps this issue
by only grabbing the first node, so this would keep things consistent.
Okay, I'll add.
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
[]..
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..23f2064 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
- .init_time = omap4_local_timer_init,
+ .init_time = omap4_init_time,
.dt_compat = omap4_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
[]..
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+ if (np) {
+ scrm_data.clks = scrm_clks;
+ scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+ }
+
+ return 0;
+}
[]..
+
+void __init omap4_init_time(void)
+{
+ omap4_clk_init_dt();
+ omap4_local_timer_init();
+}
I guess you did all this because of_clk_add_provider() needs
slab to be initialized. With the below patch[1], now clk inits
happen within .init_timer already, so none of this would
be needed.
[1] http://www.spinics.net/lists/arm-kernel/msg231288.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: [PATCHv2 5/7] usb: phy: twl4030-usb: check if vbus is driven by twl itself
On Wed, Mar 20, 2013 at 3:07 PM, Felipe Balbi ba...@ti.com wrote:
On Sun, Mar 17, 2013 at 08:23:25PM +0200, Grazvydas Ignotas wrote:
At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/phy/phy-twl4030-usb.c | 36
+++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 425c18a..87bf11d 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8
reg, u8 bits)
/*-*/
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+ int ret;
+
+ ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+ if (ret 0 || !(ret PHY_DPLL_CLK))
+ /*
+ * if clocks are off, registers are not updated,
+ * but we can assume we don't drive VBUS in this case
+ */
+ return false;
+
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0)
+ return false;
+
+ return (ret (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
{
int status;
enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
+ booldriving_vbus = false;
twl-vbus_supplied = false;
@@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
if (status 0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status (BIT(7) | BIT(2))) {
- if (status (BIT(7)))
-twl-vbus_supplied = true;
+ if (status BIT(7)) {
+ driving_vbus = twl4030_is_driving_vbus(twl);
+ if (driving_vbus)
how about just:
if (twl4030_is_driving_vbus(twl))
status = ~BIT(7);
I'm logging driving_vbus below with dev_dbg(), so that it's easier to
see what going on..
--
balbi
--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: clock: Initialize USB DPLL
If the bootloader doesn't configure USB DPLL (e.g. in u-boot,
disable CONFIG_USB_EHCI_OMAP), then we get all sorts of problems
like
- division by zero errors at boot [1]
- USB DPLL fails to enter locked state
- USB EHCI Host is non functional
- Device can't enter OFF mode
Initializing the USB DPLL fixes all these issues.
[1]
[0.00] clock: dpll_usb_ck failed transition to 'locked'
[0.00] Division by zero in kernel.
[0.00] [c001b00c] (unwind_backtrace+0x0/0xf0) from [c02b2378]
(Ldiv0+0x8/0x10)
[0.00] [c02b2378] (Ldiv0+0x8/0x10) from [c041cf3c]
(clk_divider_set_rate+0x10/0x124)
[0.00] [c041cf3c] (clk_divider_set_rate+0x10/0x124) from [c041bfc4]
(clk_change_rate+0x3c/0xb4)
[0.00] [c041bfc4] (clk_change_rate+0x3c/0xb4) from [c041c028]
(clk_change_rate+0xa0/0xb4)
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock44xx_data.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index bfc46c1..6127bb9 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -53,6 +53,12 @@
*/
#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+/*
+ * OMAP4450 TRM Rev X, section 3.6.3.9.5 DPLL_USB Preferred Settings
+ * states it must be at 960MHz
+ */
+#define OMAP4_DPLL_USB_DEFFREQ 96000
+
/* Root clocks */
DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
@@ -1729,6 +1735,19 @@ int __init omap4xxx_clk_init(void)
omap2_clk_disable_autoidle_all();
/*
+* Lock USB_DPLL to avoid issues with USB host and OFF mode
+*/
+ rc = clk_set_rate(dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
+ if (rc) {
+ pr_err(%s: failed to configure DPLL_USB: %d\n, __func__, rc);
+ } else {
+ rc = clk_set_rate(dpll_usb_m2_ck, OMAP4_DPLL_USB_DEFFREQ/2);
+ if (rc)
+ pr_err(%s: failed to configure DPLL_USB_M2: %d\n,
+ __func__, rc);
+ }
+
+ /*
* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
* state when turning the ABE clock domain. Workaround this by
* locking the ABE DPLL on boot.
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 03/21/2013 03:08 PM, Rajendra Nayak wrote:
[]..
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..23f2064 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
-.init_time = omap4_local_timer_init,
+.init_time = omap4_init_time,
.dt_compat = omap4_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
[]..
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+struct device_node *np;
+
+np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+if (np) {
+scrm_data.clks = scrm_clks;
+scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+}
+
+return 0;
+}
[]..
+
+void __init omap4_init_time(void)
+{
+omap4_clk_init_dt();
+omap4_local_timer_init();
+}
I guess you did all this because of_clk_add_provider() needs
slab to be initialized. With the below patch[1], now clk inits
happen within .init_timer already, so none of this would
be needed.
[1] http://www.spinics.net/lists/arm-kernel/msg231288.html
Right. I can then call omap4_clk_init_dt() from within omap4xxx_clk_init().
Any comments about the main subject? Does the approach look fine?
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: clock: Initialize USB DPLL
On 03/21/2013 03:48 PM, Roger Quadros wrote: If the bootloader doesn't configure USB DPLL (e.g. in u-boot, disable CONFIG_USB_EHCI_OMAP), then we get all sorts of problems like - division by zero errors at boot [1] - USB DPLL fails to enter locked state - USB EHCI Host is non functional - Device can't enter OFF mode Initializing the USB DPLL fixes all these issues. [1] [0.00] clock: dpll_usb_ck failed transition to 'locked' [0.00] Division by zero in kernel. [0.00] [c001b00c] (unwind_backtrace+0x0/0xf0) from [c02b2378] (Ldiv0+0x8/0x10) [0.00] [c02b2378] (Ldiv0+0x8/0x10) from [c041cf3c] (clk_divider_set_rate+0x10/0x124) [0.00] [c041cf3c] (clk_divider_set_rate+0x10/0x124) from [c041bfc4] (clk_change_rate+0x3c/0xb4) [0.00] [c041bfc4] (clk_change_rate+0x3c/0xb4) from [c041c028] (clk_change_rate+0xa0/0xb4) Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c index bfc46c1..6127bb9 100644 --- a/arch/arm/mach-omap2/cclock44xx_data.c +++ b/arch/arm/mach-omap2/cclock44xx_data.c @@ -53,6 +53,12 @@ */ #define OMAP4_DPLL_ABE_DEFFREQ 98304000 +/* + * OMAP4450 TRM Rev X, section 3.6.3.9.5 DPLL_USB Preferred Settings 4460 actually. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thursday 21 March 2013 07:24 PM, Roger Quadros wrote:
On 03/21/2013 03:08 PM, Rajendra Nayak wrote:
[]..
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..23f2064 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
- .init_time = omap4_local_timer_init,
+ .init_time = omap4_init_time,
.dt_compat = omap4_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
[]..
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+ if (np) {
+ scrm_data.clks = scrm_clks;
+ scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+ }
+
+ return 0;
+}
[]..
+
+void __init omap4_init_time(void)
+{
+ omap4_clk_init_dt();
+ omap4_local_timer_init();
+}
I guess you did all this because of_clk_add_provider() needs
slab to be initialized. With the below patch[1], now clk inits
happen within .init_timer already, so none of this would
be needed.
[1] http://www.spinics.net/lists/arm-kernel/msg231288.html
Right. I can then call omap4_clk_init_dt() from within omap4xxx_clk_init().
Any comments about the main subject? Does the approach look fine?
It looks fine, except for the fact that I was wondering if the clock
provider needs to restrict itself to SCRM.
Nishant Menon brought up a need for specifying the mpu clock source
from within DT, to be able to use a generic cpufreq driver.
It could be a provider (not specific to scrm, but having only scrm
clocks for now) which we could add clocks as and when we see a need for
them to be specified from DT.
Btw, you need to copy Paul Walmsley for any clock related patches as
he is the OMAP clock maintainer.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
+Paul Nishant
On 03/19/2013 04:26 PM, Roger Quadros wrote:
Register a device tree clock provider for AUX clocks
on the OMAP4 SoC. Also provide the binding information.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/omap4-clock.txt | 32 ++
arch/arm/boot/dts/omap4.dtsi |5 +++
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/cclock44xx_data.c | 35
arch/arm/mach-omap2/clock44xx.h|1 +
arch/arm/mach-omap2/common.h |9 +
arch/arm/mach-omap2/io.c |6 +++
7 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/omap4-clock.txt
b/Documentation/devicetree/bindings/clock/omap4-clock.txt
new file mode 100644
index 000..9d5448b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
@@ -0,0 +1,32 @@
+* Clock bindings for Texas Instruments OMAP4 SCRM clocks
+
+Required properties:
+- compatible: Should be ti,omap4-scrm
+- #clock-cells: Should be 1
+
+The clock consumer should specify the desired clock by having the clock
+ID in its clocks phandle cell. The following is a full list of SCRM
+clocks and IDs.
+
+ Clock ID
+ --
+ auxclk0_ck 0
+ auxclk1_ck 1
+ auxclk1_ck 1
+ auxclk1_ck 1
+ auxclk1_ck 1
+
+Example:
+
+aux_clks: scrmclks {
+ compatible = ti,omap4-scrm;
+ #clock-cells = 1;
+};
+
+hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ clocks = aux_clks 3;
+ clock-names = main_clk;
+ clock-frequency = 1920;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b7db1a2..97de56c 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -101,6 +101,11 @@
ti,hwmods = counter_32k;
};
+ aux_clks: scrmclks {
+ compatible = ti,omap4-scrm;
+ #clock-cells = 1;
+ };
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..23f2064 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
- .init_time = omap4_local_timer_init,
+ .init_time = omap4_init_time,
.dt_compat = omap4_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bfc46c1 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
+static struct clk *scrm_clks[] = {
+ auxclk0_ck,
+ auxclk1_ck,
+ auxclk2_ck,
+ auxclk3_ck,
+ auxclk4_ck,
+ auxclk5_ck,
+};
+
+static struct clk_onecell_data scrm_data;
+
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+ if (np) {
+ scrm_data.clks = scrm_clks;
+ scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+ }
+
+ return 0;
+}
+
+#else
+
+int __init omap4_clk_init_dt(void)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
int __init omap4xxx_clk_init(void)
{
u32 cpu_clkflg;
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 287a46f..6395f63 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -16,5 +16,6 @@
#define OMAP4430_REGM4XEN_MULT 4
int omap4xxx_clk_init(void);
+int omap4_clk_init_dt(void);
#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0a6b9c7..1941d1c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -98,6 +98,7 @@ void am35xx_init_early(void);
void ti81xx_init_early(void);
void
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 03/21/2013 04:04 PM, Rajendra Nayak wrote:
On Thursday 21 March 2013 07:24 PM, Roger Quadros wrote:
On 03/21/2013 03:08 PM, Rajendra Nayak wrote:
[]..
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..23f2064 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
- .init_time = omap4_local_timer_init,
+ .init_time = omap4_init_time,
.dt_compat = omap4_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
[]..
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+ if (np) {
+ scrm_data.clks = scrm_clks;
+ scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+ }
+
+ return 0;
+}
[]..
+
+void __init omap4_init_time(void)
+{
+ omap4_clk_init_dt();
+ omap4_local_timer_init();
+}
I guess you did all this because of_clk_add_provider() needs
slab to be initialized. With the below patch[1], now clk inits
happen within .init_timer already, so none of this would
be needed.
[1] http://www.spinics.net/lists/arm-kernel/msg231288.html
Right. I can then call omap4_clk_init_dt() from within omap4xxx_clk_init().
Any comments about the main subject? Does the approach look fine?
It looks fine, except for the fact that I was wondering if the clock
provider needs to restrict itself to SCRM.
Nishant Menon brought up a need for specifying the mpu clock source
from within DT, to be able to use a generic cpufreq driver.
It could be a provider (not specific to scrm, but having only scrm
clocks for now) which we could add clocks as and when we see a need for
them to be specified from DT.
OK, I will revise the patch to not make it SCRM specific.
Btw, you need to copy Paul Walmsley for any clock related patches as
he is the OMAP clock maintainer.
OK. Thanks for letting know.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: clock: Initialize USB DPLL
+Paul
On 03/21/2013 03:48 PM, Roger Quadros wrote:
If the bootloader doesn't configure USB DPLL (e.g. in u-boot,
disable CONFIG_USB_EHCI_OMAP), then we get all sorts of problems
like
- division by zero errors at boot [1]
- USB DPLL fails to enter locked state
- USB EHCI Host is non functional
- Device can't enter OFF mode
Initializing the USB DPLL fixes all these issues.
[1]
[0.00] clock: dpll_usb_ck failed transition to 'locked'
[0.00] Division by zero in kernel.
[0.00] [c001b00c] (unwind_backtrace+0x0/0xf0) from [c02b2378]
(Ldiv0+0x8/0x10)
[0.00] [c02b2378] (Ldiv0+0x8/0x10) from [c041cf3c]
(clk_divider_set_rate+0x10/0x124)
[0.00] [c041cf3c] (clk_divider_set_rate+0x10/0x124) from
[c041bfc4] (clk_change_rate+0x3c/0xb4)
[0.00] [c041bfc4] (clk_change_rate+0x3c/0xb4) from [c041c028]
(clk_change_rate+0xa0/0xb4)
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock44xx_data.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index bfc46c1..6127bb9 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -53,6 +53,12 @@
*/
#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+/*
+ * OMAP4450 TRM Rev X, section 3.6.3.9.5 DPLL_USB Preferred Settings
+ * states it must be at 960MHz
+ */
+#define OMAP4_DPLL_USB_DEFFREQ 96000
+
/* Root clocks */
DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
@@ -1729,6 +1735,19 @@ int __init omap4xxx_clk_init(void)
omap2_clk_disable_autoidle_all();
/*
+ * Lock USB_DPLL to avoid issues with USB host and OFF mode
+ */
+ rc = clk_set_rate(dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
+ if (rc) {
+ pr_err(%s: failed to configure DPLL_USB: %d\n, __func__, rc);
+ } else {
+ rc = clk_set_rate(dpll_usb_m2_ck, OMAP4_DPLL_USB_DEFFREQ/2);
+ if (rc)
+ pr_err(%s: failed to configure DPLL_USB_M2: %d\n,
+ __func__, rc);
+ }
+
+ /*
* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
* state when turning the ABE clock domain. Workaround this by
* locking the ABE DPLL on boot.
--
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: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
On Wed, 20 Mar 2013, Frank Rowand wrote: Hi All, Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, other???), so casting the nets wide... The PandaBoard frequently fails to boot with an eth0 error when mounting the root file system via NFS (ethernet driver fails due to a USB timeout; no ethernet means NFS won't work). A typical set of error messages is: [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id [3.275543] smsc95xx v1.0.4 [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d [8.091003] hub 1-1:1.0: state 7 ports 5 chg evt 0002 [ 13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4 [ 13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x0108 [ 13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110 [ 13.529998] IP-Config: Failed to open eth0 I have bisected this to: commit 18aafe64d75d0e27dae206cacf4171e4e485d285 Author: Alan Stern st...@rowland.harvard.edu Date: Wed Jul 11 11:23:04 2012 -0400 USB: EHCI: use hrtimer for the I/O watchdog I don't understand how that commit could cause a timeout unless there are at least two other bugs present in your system. Note that to compile this version of the kernel, an additional fix must also be applied: commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee Author: Ming Lei ming@canonical.com Date: Fri Jul 13 17:25:24 2012 +0800 USB: ehci-omap: fix compile failure(v1) The symptom can be worked around by retrying the USB access if a timeout occurs. This is clearly _not_ the fix, just a hack that I used to investigate the problem: http://article.gmane.org/gmane.linux.rt.user/9773 My kernel configuration is: arch/arm/configs/omap2plus_defconfig plus to get the ethernet driver I add: CONFIG_USB_EHCI_HCD CONFIG_USB_NET_SMSC95XX I found the problem on 3.6.11, but have not replicated it on 3.9-rcX yet because my config fails to build on 3.9-rc1 and 3.9-rc2. I'll try to work on that issue tomorrow. Let me know how it works out. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: Enable fix for Cortex-A9 erratas
This enables the fixes for the below erratas applicable for OMAP4 Socs. 754322: Faulty MMU translations following ASID switch 775420: A data cache maintenance operation which aborts, followed by an ISB, without any DSB in-between, might lead to deadlock Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c3477e7..c4a3f3f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -73,6 +73,8 @@ config ARCH_OMAP4 select PM_RUNTIME if CPU_IDLE select USB_ARCH_HAS_EHCI if USB_SUPPORT select COMMON_CLK + select ARM_ERRATA_754322 + select ARM_ERRATA_775420 config SOC_OMAP5 bool TI OMAP5 -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 5/7] usb: phy: twl4030-usb: check if vbus is driven by twl itself
Hi,
On Thu, Mar 21, 2013 at 03:42:46PM +0200, Grazvydas Ignotas wrote:
At least on pandora, STS_VBUS gets set even when VBUS is driven by twl
itself. Reporting VBUS in this case confuses OMAP musb glue and charger
driver, so check if OTG VBUS charge pump is on before reporting VBUS
event to avoid this problem.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/phy/phy-twl4030-usb.c | 36
+++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 425c18a..87bf11d 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -248,11 +248,31 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8
reg, u8 bits)
/*-*/
+static bool twl4030_is_driving_vbus(struct twl4030_usb *twl)
+{
+ int ret;
+
+ ret = twl4030_usb_read(twl, PHY_CLK_CTRL_STS);
+ if (ret 0 || !(ret PHY_DPLL_CLK))
+ /*
+ * if clocks are off, registers are not updated,
+ * but we can assume we don't drive VBUS in this case
+ */
+ return false;
+
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0)
+ return false;
+
+ return (ret (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
+}
+
static enum omap_musb_vbus_id_status
twl4030_usb_linkstat(struct twl4030_usb *twl)
{
int status;
enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
+ booldriving_vbus = false;
twl-vbus_supplied = false;
@@ -270,20 +290,26 @@ static enum omap_musb_vbus_id_status
if (status 0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status (BIT(7) | BIT(2))) {
- if (status (BIT(7)))
-twl-vbus_supplied = true;
+ if (status BIT(7)) {
+ driving_vbus = twl4030_is_driving_vbus(twl);
+ if (driving_vbus)
how about just:
if (twl4030_is_driving_vbus(twl))
status = ~BIT(7);
I'm logging driving_vbus below with dev_dbg(), so that it's easier to
see what going on..
is that really necessary ? Don't we expose it through sysfs already ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 5/6] ARM: dts: omap: update usb_otg_hs data
On 03/21/2013 12:23 AM, kishon wrote:
Hi,
On Thursday 21 March 2013 02:29 AM, Stephen Warren wrote:
On 03/20/2013 03:12 AM, Kishon Vijay Abraham I wrote:
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..3d6f9f6 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply
upto
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phy : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs
present in the
+ *phy* phandle.
If the intent is for those properties to be generic and used by any DT
binding that refers to a PHY node, I think you'd want to define those
properties in e.g. Documentation/devicetree/bindings/phy/phy.txt, just
like common clock/GPIO/... properties are defined in standalone common
files.
Ok. Will add it.
I think you want to require that DT nodes that represent PHYs have a
#phy-cells property, and that the format of the phy property be
phy_phandle phy_specifier*, where #phy-cells in the referenced node
defines how many cells are part of phy_specifier*, just like (almost)
any other DT property that references another node by phandle. That way,
if a single DT node represents a HW block that implements e.g. 3 PHYs,
it can use #phy-cells = 1, and the referencing phy property can
include a cell that indicates which of those 3 PHYs is being referenced.
Currently, if a single phandle have reference to multiple PHYs, we can
get PHY by passing index or by name as give in phy-names.
I'm not sure if we have phy_phandle phy_specifier*, what could that
phy_specifier be? Maybe phy_type?
I'm not talking about the case where a consumer node references multiple
PHYs. As you say, that is indeed handled by the driver looking at a
particular index in the phys property, or using phy-names.
I'm talking about the case where a single provider provides multiple
PHYs. For example, consider:
phys: phy {
compatible = xxx;
reg = ...;
#phy-cells = 1;
};
That node describes an IP block that implements 3 different PHYs. The
registers are inter-mixed in such a way that you can't split it into 3
separate nodes each with a separate device instance. If the consumers
simply say:
phys = phys;
then which of the 3 PHYs are you referring to?
Instead, the consumer needs to say one of:
phys = phys 0;
phys = phys 1;
phys = phys 2;
in order to specify which of the PHYs it refers to.
The number of cells in the phy property after the phandle is specified
by the #phy-cells property in the node referred to by the phandle. The
meaning of all those cells is defined by the binding for the phy node.
This could include both the PHY ID (as in my example here), or whatever
configuration information or flags the provider needs. For example, both
GPIOs and interrupts have specifiers than describe both of these things.
For more background, take a look at almost any other binding that uses
phandles.
By the way, the property in the consumer should probably be phys not
phy to be consistent with other similar properties (e.g. gpios,
interrupts, ... which are all plural).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/8]: omap4: clk: move clock data under drivers/clk
Hi, This is an RFC version of the clock data move under drivers/clk. Tested under 3.8 and boots fine, but don't try this out unless you are experimental sort (I quickly tried with 3.9-rc3 and it failed to boot with that.) The approach taken here has minimal impact on the clock data and should make it easy to transfer clock data for omap2 / omap3 and omap5 also. omap4 was only done as a proof of concept. Any comments appreciated. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/8] CLK: OMAP4: Clock header register declarations to struct
Clock header register declarations were previously converting
addresses to direct pointers. This doesn't work with an ioremapping
driver, so these are changed into { module, offset } tuples.
These are parsed by the driver into actual register addresses.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/omap/cm1_44xx.h |2 +-
drivers/clk/omap/cm2_44xx.h |2 +-
drivers/clk/omap/prm44xx.h |6 +-
drivers/clk/omap/scrm44xx.h |2 +-
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/omap/cm1_44xx.h b/drivers/clk/omap/cm1_44xx.h
index 1bc00dc..9c80aa0 100644
--- a/drivers/clk/omap/cm1_44xx.h
+++ b/drivers/clk/omap/cm1_44xx.h
@@ -29,7 +29,7 @@
#define OMAP4430_CM1_BASE 0x4a004000
#define OMAP44XX_CM1_REGADDR(inst, reg)\
- OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + (inst) + (reg))
+ OMAP4_CM1_INDEX, ((inst) + (reg))
/* CM1 instances */
#define OMAP4430_CM1_OCP_SOCKET_INST 0x
diff --git a/drivers/clk/omap/cm2_44xx.h b/drivers/clk/omap/cm2_44xx.h
index b9de72d..3b47ac1 100644
--- a/drivers/clk/omap/cm2_44xx.h
+++ b/drivers/clk/omap/cm2_44xx.h
@@ -29,7 +29,7 @@
#define OMAP4430_CM2_BASE 0x4a008000
#define OMAP44XX_CM2_REGADDR(inst, reg)\
- OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + (inst) + (reg))
+ OMAP4_CM2_INDEX, ((inst) + (reg))
/* CM2 instances */
#define OMAP4430_CM2_OCP_SOCKET_INST 0x
diff --git a/drivers/clk/omap/prm44xx.h b/drivers/clk/omap/prm44xx.h
index 8ee1fbd..2f9b652 100644
--- a/drivers/clk/omap/prm44xx.h
+++ b/drivers/clk/omap/prm44xx.h
@@ -25,14 +25,10 @@
#ifndef __ARCH_ARM_MACH_OMAP2_PRM44XX_H
#define __ARCH_ARM_MACH_OMAP2_PRM44XX_H
-#include prcm-common.h
-#include prm.h
-
#define OMAP4430_PRM_BASE 0x4a306000
#define OMAP44XX_PRM_REGADDR(inst, reg)\
- OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE + (inst) + (reg))
-
+ OMAP4_PRM_INDEX, ((inst) + (reg))
/* PRM instances */
#define OMAP4430_PRM_OCP_SOCKET_INST 0x
diff --git a/drivers/clk/omap/scrm44xx.h b/drivers/clk/omap/scrm44xx.h
index e897ac8..9069917 100644
--- a/drivers/clk/omap/scrm44xx.h
+++ b/drivers/clk/omap/scrm44xx.h
@@ -22,7 +22,7 @@
#define OMAP4_SCRM_BASE0x4a30a000
#define OMAP44XX_SCRM_REGADDR(reg) \
- OMAP2_L4_IO_ADDRESS(OMAP4_SCRM_BASE + (reg))
+ OMAP4_SCRM_INDEX, (reg)
/* Registers offset */
#define OMAP4_SCRM_REVISION_SCRM_OFFSET0x
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/8] RFC: CLK: OMAP: Add basic infrastructure for OMAP clocks
This patch adds basic infrastructure support for registering clocks
under common clock framework. This patch is done in preparation for
moving clock data from arch/arm/mach-omap2/ folder under /drivers/clk/omap.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/omap/clk.c | 220
drivers/clk/omap/clock.h | 645 ++
2 files changed, 865 insertions(+), 0 deletions(-)
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 drivers/clk/omap/clock.h
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..246f70d
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,209 @@
+/*
+ * OMAP clock support
+ *
+ * Copyright (c) 2013, Texas Instruments. All rights reserved.
+ *
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * Highly based on drivers/clk/tegra/clk.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/clk.h
+#include linux/clk/omap.h
+#include linux/clk-provider.h
+
+#include clock.h
+
+static void __iomem **clk_base;
+
+static struct clk_ops dummy_ck_ops __initdata = {};
+
+static struct clk_hw_omap dummy_ck_hw __initdata = {
+};
+
+struct omap_init_clk omap_dummy_ck __initdata = {
+.name = dummy_clk,
+.ops = dummy_ck_ops,
+.clk_register = omap_clk_register,
+.hw = dummy_ck_hw,
+};
+
+static struct clksel *omap_clk_init_clksel(struct omap_init_clk *c)
+{
+ struct clksel *sel;
+ struct clksel_init *init;
+ int sz, i;
+
+ init = c-hw-clksel.init;
+
+ if (!init)
+ return NULL;
+
+ if (init-clksel)
+ return init-clksel;
+
+ /* Check size for clksel array */
+ sz = 0;
+ while (init[sz].parent_name) {
+ sz++;
+ }
+
+ sel = kzalloc(sizeof(struct clksel) * (sz + 1), GFP_KERNEL);
+
+ for (i = 0; i sz; i++) {
+ sel[i].parent = clk_get(NULL, init[i].parent_name);
+ sel[i].rates = init[i].rates;
+ }
+
+ init-clksel = sel;
+
+ return sel;
+}
+
+static inline void __iomem *omap_clk_reg_to_ptr(struct clk_reginfo *reg)
+{
+ void __iomem *base;
+
+ base = clk_base[reg-module];
+ return base + reg-offset;
+}
+
+static struct dpll_data *omap_clk_init_dpll_data(struct omap_init_clk *c)
+{
+ struct dpll_data *init = c-hw-dpll_data;
+ struct dpll_data *dd;
+
+ if (!init)
+ return NULL;
+
+ dd = kmalloc(sizeof(struct dpll_data), GFP_KERNEL);
+
+ memcpy(dd, init, sizeof(struct dpll_data));
+
+ dd-clk_bypass.clk = clk_get(NULL, init-clk_bypass.name);
+ dd-clk_ref.clk = clk_get(NULL, init-clk_ref.name);
+ dd-mult_div1_reg.ptr =
+ omap_clk_reg_to_ptr(init-mult_div1_reg.reginfo);
+ dd-control_reg.ptr =
+ omap_clk_reg_to_ptr(init-control_reg.reginfo);
+ dd-autoidle_reg.ptr =
+ omap_clk_reg_to_ptr(init-autoidle_reg.reginfo);
+ dd-idlest_reg.ptr =
+ omap_clk_reg_to_ptr(init-idlest_reg.reginfo);
+
+ return dd;
+}
+
+struct clk *omap_clk_register(struct omap_init_clk *c)
+{
+ struct clk_init_data init;
+ struct clk_hw_omap *hw;
+
+ init.name = c-name;
+ init.ops = c-ops;
+ init.parent_names = c-parent_names;
+ init.num_parents = c-num_parents;
+ init.flags = 0;
+
+ hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+
+ memcpy(hw, c-hw, sizeof(struct clk_hw_omap));
+
+ hw-hw.init = init;
+
+ hw-clksel.ptr = omap_clk_init_clksel(c);
+
+ hw-dpll_data = omap_clk_init_dpll_data(c);
+
+ if (c-hw-clksel_reg.reginfo.module)
+ hw-clksel_reg.ptr =
+ omap_clk_reg_to_ptr(c-hw-clksel_reg.reginfo);
+
+ if (c-hw-enable_reg.reginfo.module)
+ hw-enable_reg.ptr =
+ omap_clk_reg_to_ptr(c-hw-enable_reg.reginfo);
+
+ return clk_register(NULL, hw-hw);
+}
+
+struct clk *omap_clk_register_fixed_rate(struct omap_init_clk *c)
+{
+ return clk_register_fixed_rate(NULL, c-name, c-parent_name,
+ c-clk_flags, c-rate);
+}
+
+struct clk *omap_clk_register_mux(struct omap_init_clk *c)
+{
+ return clk_register_mux(NULL, c-name, c-parent_names, c-num_parents,
+
[RFC 6/8] CLK: OMAP4: add support for the new clock init code
Modifies the omap4 clock init code to support the new clock
registration method.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/omap/cclock44xx_data.c | 52 ++-
1 files changed, 21 insertions(+), 31 deletions(-)
diff --git a/drivers/clk/omap/cclock44xx_data.c
b/drivers/clk/omap/cclock44xx_data.c
index 25285a3..aba9bcb 100644
--- a/drivers/clk/omap/cclock44xx_data.c
+++ b/drivers/clk/omap/cclock44xx_data.c
@@ -20,20 +20,15 @@
#include linux/kernel.h
#include linux/list.h
-#include linux/clk-private.h
+#include linux/clk-provider.h
#include linux/clkdev.h
#include linux/io.h
-#include soc.h
-#include iomap.h
#include clock.h
-#include clock44xx.h
#include cm1_44xx.h
#include cm2_44xx.h
#include cm-regbits-44xx.h
#include prm44xx.h
-#include prm-regbits-44xx.h
-#include control.h
#include scrm44xx.h
/* OMAP4 modulemode control */
@@ -48,6 +43,13 @@
*/
#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+enum {
+ OMAP4_CM1_INDEX = 1,
+ OMAP4_CM2_INDEX,
+ OMAP4_PRM_INDEX,
+ OMAP4_SCRM_INDEX
+};
+
/* Root clocks */
OMAP_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
@@ -1925,37 +1927,24 @@ static const char *enable_init_clks[] = {
int __init omap4xxx_clk_init(void)
{
- u32 cpu_clkflg;
- struct omap_clk *c;
- int rc;
-
- if (cpu_is_omap443x()) {
- cpu_mask = RATE_IN_4430;
- cpu_clkflg = CK_443X;
- } else if (cpu_is_omap446x() || cpu_is_omap447x()) {
- cpu_mask = RATE_IN_4460 | RATE_IN_4430;
- cpu_clkflg = CK_446X | CK_443X;
-
- if (cpu_is_omap447x())
- pr_warn(WARNING: OMAP4470 clock data incomplete!\n);
- } else {
- return 0;
- }
-
- for (c = omap44xx_clks; c omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
- c++) {
- if (c-cpu cpu_clkflg) {
- clkdev_add(c-lk);
- if (!__clk_init(NULL, c-lk.clk))
- omap2_init_clk_hw_omap_clocks(c-lk.clk);
- }
- }
+ void __iomem *base[5];
+
+ base[OMAP4_CM1_INDEX] = ioremap(OMAP4430_CM1_BASE, SZ_64K);
+ base[OMAP4_CM2_INDEX] = ioremap(OMAP4430_CM2_BASE, SZ_64K);
+ base[OMAP4_PRM_INDEX] = ioremap(OMAP4430_PRM_BASE, SZ_64K);
+ base[OMAP4_SCRM_INDEX] = ioremap(OMAP4_SCRM_BASE, SZ_64K);
+
+ cpu_mask = RATE_IN_4430;
+
+ omap_clk_register_clks(omap44xx_clks, ARRAY_SIZE(omap44xx_clks),
+ CK_443X, base);
omap2_clk_disable_autoidle_all();
omap2_clk_enable_init_clocks(enable_init_clks,
ARRAY_SIZE(enable_init_clks));
+#if 0
/*
* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
* state when turning the ABE clock domain. Workaround this by
@@ -1967,6 +1956,7 @@ int __init omap4xxx_clk_init(void)
rc = clk_set_rate(dpll_abe_ck, OMAP4_DPLL_ABE_DEFFREQ);
if (rc)
pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+#endif
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 7/8] clk: use strncmp for matching con_id in clk_find
As clkdev register forces the con_id length down to a maximum of 15
characters and terminating null, replace the internal implementation
of clk_find to use strncmp instead of strcmp. This makes sure that
if a user registers a clkdev with con_id name which gets trimmed,
the same string used in the clk_lookup will still succeed despite
this.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/clkdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..05b01a1 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -120,7 +120,7 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
match += 2;
}
if (p-con_id) {
- if (!con_id || strcmp(p-con_id, con_id))
+ if (!con_id || strncmp(p-con_id, con_id, 15))
continue;
match += 1;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
Quoting Santosh Shilimkar (2013-03-21 04:18:08) On Thursday 21 March 2013 04:34 PM, Rajendra Nayak wrote: clk inits on OMAP happen quite early, even before slab is available. The dependency comes from the fact that the timer init code starts to use clocks and hwmod and we need clocks to be initialized by then. There are various problems doing clk inits this early, one is, not being able to do dynamic clk registrations and hence the dependency on clk-private.h. The other is, inability to debug early kernel crashes without enabling DEBUG_LL and earlyprintk. Doing early clk init also exposed another instance of a kernel panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled. [0.00] Kernel BUG at c01174f8 [verbose debug info unavailable] [0.00] Internal error: Oops - BUG: 0 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.9.0-rc1-12179-g72d48f9 #6) [0.00] PC is at __kmalloc+0x1d4/0x248 [0.00] LR is at __clk_init+0x2e0/0x364 [0.00] pc : [c01174f8]lr : [c0441f54]psr: 61d3 [0.00] sp : c076ff28 ip : c065cefc fp : c0441f54 [0.00] r10: 001c r9 : 80d0 r8 : c076ffd4 [0.00] r7 : c074b578 r6 : c0794d88 r5 : 0040 r4 : [0.00] r3 : r2 : c07cac70 r1 : 80d0 r0 : 001c [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c53c7d Table: 8000404a DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc076e240) [0.00] Stack: (0xc076ff28 to 0xc077) [0.00] ff20: c0794ec8 c06546e8 0040 c0794d88 [0.00] ff40: c074b578 c076ffd4 c07951c8 c076e000 c0441f54 c074b578 c076ffd4 [0.00] ff60: c0793828 0040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac [0.00] ff80: 2f80 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 [0.00] ffa0: 0001 c074cd6c c077b1ec 8000406a c0715724 [0.00] ffc0: c074c968 10c53c7d c0776974 [0.00] ffe0: c074cd6c c077b1ec 8000406a 411fc092 80008074 [0.00] [c01174f8] (__kmalloc+0x1d4/0x248) from [c0441f54] (__clk_init+0x2e0/0x364) [0.00] [c0441f54] (__clk_init+0x2e0/0x364) from [c07272ac] (omap4xxx_clk_init+0xbc/0x140) [0.00] [c07272ac] (omap4xxx_clk_init+0xbc/0x140) from [c0719780] (setup_arch+0x15c/0x284) [0.00] [c0719780] (setup_arch+0x15c/0x284) from [c0715724] (start_kernel+0x7c/0x334) [0.00] [c0715724] (start_kernel+0x7c/0x334) from [80008074] (0x80008074) [0.00] Code: e5883004 e1a6 e28dd00c e8bd8ff0 (e7f001f2) [0.00] ---[ end trace 1b75b31a2719ed1c ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! It was a know issue, that slab allocations would fail when common clock core tries to cache parent pointers for mux clocks on OMAP, and hence a patch 'clk: Allow late cache allocation for clk-parents, commit 7975059d' was added to work this problem around. A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely overlooked causing this regression. More details on the issue reported can be found here, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html With all these issues around clk inits happening way too early, it makes sense to atleast move them to a point where dynamic memory allocations are possible. So move them to a point just before the timer code starts using clocks and hwmod. This should atleast pave way for clk inits on OMAP moving to dynamic clock registrations instead of using the static macros defined in clk-private.h. The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled was reported by Piotr Haber and Tony Lindgren and this patch fixes the reported issue as well. Reported-by: Piotr Haber pha...@broadcom.com Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Rajendra Nayak rna...@ti.com --- applies on 3.9-rc3 and tested on omap4 pandaES, omap3 beagle XM, and am335x bone. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com This is nice :) Reviewed-by: Mike Turquette mturque...@linaro.org Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mach_omap2: use PTR_RET instead of IS_ERR + PTR_ERR
On Wed, Mar 20, 2013 at 8:28 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/12/2013 06:05 AM, Russell King - ARM Linux wrote:
On Tue, Mar 12, 2013 at 09:58:29AM +0200, Silviu-Mihai Popescu wrote:
This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
readability.
Signed-off-by: Silviu-Mihai Popescu silviupopescu1...@gmail.com
---
arch/arm/mach-omap2/devices.c |4 ++--
arch/arm/mach-omap2/fb.c |5 +
arch/arm/mach-omap2/gpmc.c|2 +-
arch/arm/mach-omap2/pmu.c |5 +
4 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1ec7f05..2a0816e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -66,7 +66,7 @@ static int __init omap3_l3_init(void)
WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
-return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
+return PTR_RET(pdev);
This is incorrect.
The return value will be tested for 0. Kernel pointers in general are
all above 3GB, and so are all 0.
I'm afraid none of these changes stuff is an improvement - they all
introduce bugs.
Sorry I am now not sure I follow you here. Someone just pointed out to
me that PTR_RET() is defined as ...
static inline int __must_check PTR_RET(const void *ptr)
{
if (IS_ERR(ptr))
return PTR_ERR(ptr);
else
return 0;
}
So the above change appears to be equivalent. Is there something that is
wrong with the current implementation that needs to be fixed?
As the patch message says, it's just for readability purposes.
I used make coccicheck and it suggested this minor change.
--
Silviu Popescu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/8] RFC: CLK: OMAP: Add basic infrastructure for OMAP clocks
Quoting Tero Kristo (2013-03-21 10:35:40)
This patch adds basic infrastructure support for registering clocks
under common clock framework. This patch is done in preparation for
moving clock data from arch/arm/mach-omap2/ folder under /drivers/clk/omap.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
Thanks for taking a crack at this Tero! This is a great step towards
getting rid of clk-private.h.
Regarding the long-term roadmap of the omap clock code:
In general all of the changes to the omap clock code for using the
common struct clk have been very incremental. We still have the old
legacy struct clk definition, the name of that struct was changed to
clk_hw_omap, but it is still a fairly large, monolithic structure. Are
there plans to break the clock types up into smaller, more focused clock
types? E.g. get rid of struct dpll_data and have a dedicated dpll clock
type.
The question above is not reason to block this patch since it is a
fairly large refactoring effort, but it is something to consider.
Some comments below.
snip
+struct omap_clk {
+ u16 cpu;
+ const char *dev_id;
+ const char *con_id;
+ struct omap_init_clk*clk;
+};
+
+#define CLK(dev, con, ck, cp) \
+ { \
+ .cpu = cp, \
+ .dev_id = dev, \
+ .con_id = con, \
+ .clk = ck, \
+ }
+
IS omap_clk and CLK really necessary today? I thought that the move to
separate clocks out by tables got rid of this macro/structure?
+#define OMAP_CLK_FIXED_RATE(_name, _flags, _rate, _ignore) \
+ static struct omap_init_clk _name __initdata = {\
+ .name = #_name, \
+ .clk_flags = _flags,\
+ .rate = _rate, \
+ .clk_register = omap_clk_register_fixed_rate, \
+ };
+
These macros are unreadable. They were originally born out of the nasty
clk-private.h stuff which included forward declarations of struct clk
and all sorts of ugliness. I know it saves you LoC to use them now but
I really prefer to use designated initializers for the sake of
readability. Do you plan to convert the OMAP clock code back to how it
was, pre-macros?
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
On 03/21/13 07:41, Alan Stern wrote: On Wed, 20 Mar 2013, Frank Rowand wrote: Hi All, Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, other???), so casting the nets wide... The PandaBoard frequently fails to boot with an eth0 error when mounting the root file system via NFS (ethernet driver fails due to a USB timeout; no ethernet means NFS won't work). A typical set of error messages is: [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id [3.275543] smsc95xx v1.0.4 [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d [8.091003] hub 1-1:1.0: state 7 ports 5 chg evt 0002 [ 13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4 [ 13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x0108 [ 13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110 [ 13.529998] IP-Config: Failed to open eth0 I have bisected this to: commit 18aafe64d75d0e27dae206cacf4171e4e485d285 Author: Alan Stern st...@rowland.harvard.edu Date: Wed Jul 11 11:23:04 2012 -0400 USB: EHCI: use hrtimer for the I/O watchdog I don't understand how that commit could cause a timeout unless there are at least two other bugs present in your system. Yes, I would not be at all surprised if this commit merely exposes a problem in other code. That is why I included so many different people and subsystems on the email distribution list. snip -Frank -- 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: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
On 03/21/13 02:00, Ming Lei wrote:
Hi Frank,
On Thu, Mar 21, 2013 at 11:29 AM, Frank Rowand frank.row...@am.sony.com
wrote:
I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
yet because my config fails to build on 3.9-rc1 and 3.9-rc2. I'll try
to work on that issue tomorrow.
I play upstream kernel on Pandaboard A1 frequently, looks not
see the failure problem before. Maybe the problem is config dependent.
If you may share your config file, I'd like to do the test too.
I will do a separate reply with the actual config at the point where
the bisect completed.
I create the config for each commit during the bisect with scripts
that do the equivalent of:
make omap2plus_defconfig
make menuconfig
# this allows USB thumb drive
# Device Drivers - USB support - EHCI HCD (USB 2.0) support
CONFIG_USB_EHCI_HCD=y
# ethernet device
# Device Drivers - Network device support - USB Network Adapters -
# Multi-purpose USB Networking Framework -
# SMSC LAN95XX based USB 2.0 10/100 ethernet devices
CONFIG_USB_NET_SMSC95XX=y
Some more random information that may be helpful
--
$ cat /proc/cmdline
ip=192.168.1.85:192.168.1.1:192.168.1.1:255.255.255.0:panda
nfsroot=192.168.1.1:/a/target/panda root=/dev/nfs ip=dhcp mem=463M
console=ttyO2,115200n8 debug earlyprintk
--
The percentage of boots that show the problem varies quite a bit between
the kernel versions that I tried during my bisect. For my first attempt
at bisecting, I decided a version was good if it booted 12 times. That
bisect failed for various reasons. For my second attempt at bisecting,
I decided a version was good if it booted 18 times.
--
There are some timeout messages that I am not positive are symptoms of
the problem. With these messages, the smsc95xx driver initialization is
successful, so the ethernet device is available. For the first bisect
attempt, I did not treat these messages as errors. For the second bisect
attempt I treated these messages as errors. A typical example of the
timeout message is:
[9.537811] hub 1-1:1.0: state 7 ports 5 chg evt 0002
[ 17.056701] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
[ 17.062652] smsc95xx 1-1.1:1.0: eth0: Failed to write register index
0x0108
[ 17.070343] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
[ 17.076751] IP-Config: Failed to open eth0
The mention of swapper is not relevent, it just happens to be the
current process when the time out occurs.
I have only seen these timeout messages in the boot log, so they may not
be a very visible symptom. They also _might_ be unrelated to the problem,
but my gut feel is that they are related.
--
The problem manifests as a timeout from at least two different locations
in drivers/net/usb/smsc95xx.c:
656 static int smsc95xx_set_mac_address(struct usbnet *dev)
657 {
...
663 ret = smsc95xx_write_reg(dev, ADDRL, addr_lo);
664 if (ret 0) {
665 netdev_warn(dev-net, Failed to write ADDRL: %d\n, ret);
666 return ret;
667 }
751 static int smsc95xx_reset(struct usbnet *dev)
752 {
...
783 write_buf = PM_CTL_PHY_RST_;
784 ret = smsc95xx_write_reg(dev, PM_CTRL, write_buf);
785 if (ret 0) {
786 netdev_warn(dev-net, Failed to write PM_CTRL: %d\n,
ret);
787 return ret;
788 }
There may be additional locations. These are just two that I captured when
debugging. Some of the other smsc95xx_write_reg() calls in smsc95xx_reset()
are protected with checks for timeout, with up to 100 retries. I don't know
if more checks for timeout, or longer timeout, is a solution or just an
incorrect way of papering over the real problem -- this is not an area of
expertise for me.
Thanks,
Frank
--
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: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
On 03/21/13 13:25, Frank Rowand wrote: On 03/21/13 02:00, Ming Lei wrote: snip -- There are some timeout messages that I am not positive are symptoms of the problem. With these messages, the smsc95xx driver initialization is successful, so the ethernet device is available. For the first bisect attempt, I did not treat these messages as errors. For the second bisect attempt I treated these messages as errors. A typical example of the timeout message is: [9.537811] hub 1-1:1.0: state 7 ports 5 chg evt 0002 [ 17.056701] usb 1-1.1: swapper/0 timed out on ep0out len=0/4 [ 17.062652] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x0108 [ 17.070343] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110 [ 17.076751] IP-Config: Failed to open eth0 Oops, pasted the wrong example. This is an example of a timeout, but the driver still works, and the system boots: [6.072357] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, fa:50:73:02:79:67 [6.084655] hub 1-1:1.0: state 7 ports 5 chg evt 0002 [ 11.220672] usb 1-1.1: swapper/0 timed out on ep0out len=4/4 [ 18.183441] usb 1-1.1: link qh8-0001/dc8d6640 start 2 [1/0 us] [ 19.822296] IP-Config: Complete: The mention of swapper is not relevent, it just happens to be the current process when the time out occurs. I have only seen these timeout messages in the boot log, so they may not be a very visible symptom. They also _might_ be unrelated to the problem, but my gut feel is that they are related. snip -Frank -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: remove config MACH_OMAP_HTCWIZARD
The Kconfig symbol MACH_OMAP_HTCWIZARD got added in v2.6.30. It has never been used. Its entry can safely be removed. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. arch/arm/mach-omap1/Kconfig | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index 903da8e..cdd05f2 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -55,12 +55,6 @@ config MACH_OMAP_H3 TI OMAP 1710 H3 board support. Say Y here if you have such a board. -config MACH_OMAP_HTCWIZARD - bool HTC Wizard - depends on ARCH_OMAP850 - help - HTC Wizard smartphone support (AKA QTEK 9100, ...) - config MACH_HERALD bool HTC Herald depends on ARCH_OMAP850 -- 1.7.11.7 -- 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: [PATCHv3 00/14] drivers: mailbox: framework creation
Hi Suman, On Tue, 12 Mar 2013 22:23:41 -0500 Suman Anna s-a...@ti.com wrote: Stephen, I have hosted the series at [3]. Can you pull this into linux-next sometime next week? [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox Please quote git URLs ... I guessed you meant git://github.com/sumananna/mailbox.git, branch dbx500-prcmu-mailbox ? Added from today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgpLKnUqdhm6A.pgp Description: PGP signature
RE: [PATCHv3 00/14] drivers: mailbox: framework creation
Stephen, I have hosted the series at [3]. Can you pull this into linux-next sometime next week? [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox Please quote git URLs ... I guessed you meant git://github.com/sumananna/mailbox.git, branch dbx500-prcmu-mailbox ? Added from today. Yes, that's correct. Thanks Stephen. Regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
On 03/21/13 07:41, Alan Stern wrote: On Wed, 20 Mar 2013, Frank Rowand wrote: Hi All, Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, other???), so casting the nets wide... The PandaBoard frequently fails to boot with an eth0 error when mounting the root file system via NFS (ethernet driver fails due to a USB timeout; no ethernet means NFS won't work). A typical set of error messages is: [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id [3.275543] smsc95xx v1.0.4 [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d [8.091003] hub 1-1:1.0: state 7 ports 5 chg evt 0002 [ 13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4 [ 13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x0108 [ 13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110 [ 13.529998] IP-Config: Failed to open eth0 I have bisected this to: commit 18aafe64d75d0e27dae206cacf4171e4e485d285 Author: Alan Stern st...@rowland.harvard.edu Date: Wed Jul 11 11:23:04 2012 -0400 USB: EHCI: use hrtimer for the I/O watchdog I don't understand how that commit could cause a timeout unless there are at least two other bugs present in your system. Note that to compile this version of the kernel, an additional fix must also be applied: commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee Author: Ming Lei ming@canonical.com Date: Fri Jul 13 17:25:24 2012 +0800 USB: ehci-omap: fix compile failure(v1) The symptom can be worked around by retrying the USB access if a timeout occurs. This is clearly _not_ the fix, just a hack that I used to investigate the problem: http://article.gmane.org/gmane.linux.rt.user/9773 My kernel configuration is: arch/arm/configs/omap2plus_defconfig plus to get the ethernet driver I add: CONFIG_USB_EHCI_HCD CONFIG_USB_NET_SMSC95XX I found the problem on 3.6.11, but have not replicated it on 3.9-rcX yet because my config fails to build on 3.9-rc1 and 3.9-rc2. I'll try to work on that issue tomorrow. Let me know how it works out. My PandaBoard builds fail on 3.9-rcX due to ARM multiplatform issues. Either there is something I need to change about the way I build it, or it is broken (that is a side issue). My simple expedient was to hack around multiplatform, and just make it build (patch below if anyone else wants a _temporary_ hack). The problem appears to not be present in 3.9-rc3. In older kernel versions, the worst case to see the problem was 18 boots. For 3.9-rc3 I booted 42 times without seeing the problem. The problem occurs at least up through 3.8. I'll try to reverse bisect between 3.8 and 3.9-rc3 to see when the problem disappeared (I'm running short of time, so no promises for a near term result). -Frank This patch is a _temporary_ hack, not fit for man or beast. Avert your eyes, do not apply to any respectable repository! --- arch/arm/Kconfig |2 1 + 1 - 0 ! arch/arm/Makefile |2 2 + 0 - 0 ! 2 files changed, 3 insertions(+), 1 deletion(-) Index: b/arch/arm/Kconfig === --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1013,7 +1013,7 @@ config ARCH_MULTI_V7 bool ARMv7 based platforms (Cortex-A, PJ4, Krait) default y select ARCH_MULTI_V6_V7 - select ARCH_VEXPRESS + select ARCH_VEXPRESS if !ARCH_OMAP2PLUS select CPU_V7 config ARCH_MULTI_V6_V7 Index: b/arch/arm/Makefile === --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -227,8 +227,10 @@ else MACHINE := endif ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y) +ifneq ($(CONFIG_ARCH_OMAP2PLUS),y) MACHINE := endif +endif machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y)) platdirs := $(patsubst %,arch/arm/plat-%/,$(plat-y)) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/8]: omap4: clk: move clock data under drivers/clk
Tero, On Thursday 21 March 2013 11:05 PM, Tero Kristo wrote: Hi, This is an RFC version of the clock data move under drivers/clk. Tested under 3.8 and boots fine, but don't try this out unless you are experimental sort (I quickly tried with 3.9-rc3 and it failed to boot with that.) The approach taken here has minimal impact on the clock data and should make it easy to transfer clock data for omap2 / omap3 and omap5 also. omap4 was only done as a proof of concept. Any comments appreciated. I strangely only see the cover letter delivered to me and no patches. Do you have a branch with the patches which you can share? regards, Rajendra -Tero ___ 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
