Re: [PATCH v2] printk: add option to print cpu id
Borislav/Kay On Fri, Aug 3, 2012 at 3:42 AM, Borislav Petkov b...@alien8.de wrote: On Fri, Aug 03, 2012 at 12:09:15PM +0200, Kay Sievers wrote: That would be needed, I guess. We easily have server systems with more than 255 CPUs. It will only be a matter of time, that the number of CPUs will increase for everybody, I guess. Actually, AFAICR, we already have SGI machines booting Linux on 4K cpus. Now. b) to put cpuid in struct cont and struct log - under the #ifdef macro? As said, I really can't tell how generally useful it is, and if people think that it should be there unconditionally, should not be there at all, or as a compile time option. Others might have an opinion on that. I personally never missed the CPU-ID in the logs. I personally would find the PID/task ID more interesting, and even that I never really missed. :) I mostly work with ARM Soc - specifically on OMAP. SMP multi core systems in ARM-v7 world started to show up only few years back - unlike x86 world. ARM systems are a bit unique when it comes to security( read trust zone ), and handling of FIQ's. Most of the ARM cortex-A series SoC's out there have some kind of affinity to CPU0 being the master. One use case has been, it has helped to know with this printk logging, if such constraints are honored. Sometimes, tracking of some lockup cases between cpu's because of bad code has also been helpful with this logging support. For now i will post v3 of the patch and add arm-list and linux-omap list, and there might be users there can benefit. And even then you can add debugging code to dump the stuff you need. And I have to agree with Kai here, having the cpu number in dmesg is not something I'd wish for - printk timestampts OTOH has at least some usecases. Thanks. -- Regards/Gruss, Boris. -- 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] printk: add option to print cpu id
On Fri, Aug 3, 2012 at 10:54 AM, Andi Kleen a...@firstfloor.org wrote: Vikram Pandita vikram.pand...@ti.com writes: From: Vikram Pandita vikram.pand...@ti.com Introduce config option to enable CPU id reporting for printk() calls. What's wrong with using trace_printk for this? trace_printk works only when you know the _exact_ path in code that you want to profile. When you have no idea of a random lockup, then it would be kind of touch and time consuming to put trace prints all around the code. That's much faster anyways. Generally printk is so slow that it's typically useless for instrumenting races. As stated in another thread, its found useful to debug some specific cases: Check thread: http://marc.info/?l=linux-omapm=134401269106619w=2 And really: Wasting 1/3 of the 80 character line is too much. You _WASTE_ 4 chars only if you are interested in this info by enabling: CONFIG_PRINTK_CPUID Just like you _WASTE_ 15 chars when you enable existing: CONFIG_PRINTK_TIME For general usecase, recommendation would be to keep these options disabled. Working on shipping products, i find almost all shipping with CONFIG_PRINTK_TIME enabled, so there must be some value. Same would hold for the use case being debugged for CPUID enabling. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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] printk: add option to print cpu id
Aaro On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote: And really: Wasting 1/3 of the 80 character line is too much. You _WASTE_ 4 chars only if you are interested in this info by enabling: CONFIG_PRINTK_CPUID I guess you waste 4 + 3 chars? You could optimize the length by checking CONFIG_NR_CPUS? Good point. Looks there is a variable 'nr_cpu_ids' that could be used as well. If there is general consensus that the patch can help the arm community, and others in general, this optimization should be easy to implement - saving few chars space in each line of console output. For now i will stick to this v3 version of path, unless you think otherwise. A. -- 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] printk: add option to print cpu id
On Fri, Aug 3, 2012 at 2:59 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote: Aaro On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote: And really: Wasting 1/3 of the 80 character line is too much. You _WASTE_ 4 chars only if you are interested in this info by enabling: CONFIG_PRINTK_CPUID I guess you waste 4 + 3 chars? You could optimize the length by checking CONFIG_NR_CPUS? Good point. Looks there is a variable 'nr_cpu_ids' that could be used as well. If there is general consensus that the patch can help the arm community, and others in general, this optimization should be easy to implement - saving few chars space in each line of console output. For now i will stick to this v3 version of path, unless you think otherwise. I don't think is is something that anyone needs, and if you do, as pointed out, you can use the trace function to make it happen. This was something that got used internally and helped at times. This attempt to give back to community, but i understand the rationale to go with larger consensus. At least the patch is out there in public for anyone to make use of. Adding features are not free, someone has to maintain them and all of the other work involved with it. So don't just think that because it is hidden behind a config option, that it doesn't affect people. At least the v3 patch is a complete working implementation wrt kernel/printk.c file as it exists on linus tree master today. Understand long term this does have maintenance overhead just like printk_time does. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] printk: add option to print cpu id
On Fri, Aug 3, 2012 at 3:13 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 03, 2012 at 03:07:39PM -0700, Pandita, Vikram wrote: On Fri, Aug 3, 2012 at 2:59 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 03, 2012 at 02:24:20PM -0700, Pandita, Vikram wrote: Aaro On Fri, Aug 3, 2012 at 1:08 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Aug 03, 2012 at 11:25:37AM -0700, Pandita, Vikram wrote: And really: Wasting 1/3 of the 80 character line is too much. You _WASTE_ 4 chars only if you are interested in this info by enabling: CONFIG_PRINTK_CPUID I guess you waste 4 + 3 chars? You could optimize the length by checking CONFIG_NR_CPUS? Good point. Looks there is a variable 'nr_cpu_ids' that could be used as well. If there is general consensus that the patch can help the arm community, and others in general, this optimization should be easy to implement - saving few chars space in each line of console output. For now i will stick to this v3 version of path, unless you think otherwise. I don't think is is something that anyone needs, and if you do, as pointed out, you can use the trace function to make it happen. This was something that got used internally and helped at times. Could you have used the trace point instead? As i understood the trace_prink(), one would need to modify existing printk - trace_printk. Is my understanding correct? Most of the times the problem exhibits as a random hang, without having a clue which code to modify. That time one generic defconfig global switch is your first tool. Other issue i found, using this patch, that on multi-core ARM systems, almost 99% of times, IRQ's are handled by CPU0, even if CPU0 was really busy and other CPU's were free. I am yet to understand a good reason why. this patch also helped in other areas as mentioned in the thread http://marc.info/?l=linux-omapm=134401269106619w=2 Not sure how easy its to use trace_printk for such issues, i found having one defconfig option was much easier to get going. Correct me if i have not understood trace_printk well enough. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] printk: add option to print cpu id
On Fri, Aug 3, 2012 at 3:36 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote: This was something that got used internally and helped at times. Could you have used the trace point instead? As i understood the trace_prink(), one would need to modify existing printk - trace_printk. Is my understanding correct? No, you should just be able to watch the tracepoint, right? yes. Assumption being you know _EXACTLY_ what code piece to watch for. Which may not be the case all times. Most of the times the problem exhibits as a random hang, without having a clue which code to modify. That time one generic defconfig global switch is your first tool. Other issue i found, using this patch, that on multi-core ARM systems, almost 99% of times, IRQ's are handled by CPU0, even if CPU0 was really busy and other CPU's were free. I am yet to understand a good reason why. Can't you see that from /proc/interrupts today? You are right that was the next step i did and that shows the problem as well. The point i was trying to make, with printk showing cpu-id, there are problems in system that could get highlighted, given printk almost always runs with linux kernel. this patch also helped in other areas as mentioned in the thread http://marc.info/?l=linux-omapm=134401269106619w=2 I still don't understand how adding the cpu number to printk enabled you to find any problem like this. Can't you just add the cpu number to the printk messages you care about for your specific hardware? The assumption here is that a developer knows well enough, which code to modify for logging. I my experience, that is not true most of the times. A global defconfig switch is much easier to enable. Eg: when i have some timing related issue, first thing i go for is to enable PRINTK_TIME, without even having to think about the erring code. Then time-stamps lead to bad code. That is the same though process behind the cpu-id in printk. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter jon-hun...@ti.com wrote:
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
can create a PMU device based upon the DEBUGSS HWMOD and use the CTI
interrupts
for routing ARM PMU events for OMAP4430 devices.
This is based upon Benoit Cousson's patch [1].
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..faf5a6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -482,10 +482,17 @@ static struct omap_hwmod_class
omap44xx_debugss_hwmod_class = {
};
/* debugss */
+static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
+ { .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
Data manual assigns cit0 == MA_IRQ_1 and cti1 == MA_IRQ_2
Why do you add 32 base GIC_START ?
+ { .irq = -1 }
+};
+
static struct omap_hwmod omap44xx_debugss_hwmod = {
.name = debugss,
.class = omap44xx_debugss_hwmod_class,
.clkdm_name = emu_sys_clkdm,
+ .mpu_irqs = omap44xx_debugss_irqs,
.main_clk = trace_clk_div_ck,
.prcm = {
.omap4 = {
@@ -2447,8 +2454,6 @@ static struct omap_hwmod_class omap44xx_mpu_hwmod_class
= {
/* mpu */
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
{ .name = pl310, .irq = 0 + OMAP44XX_IRQ_GIC_START },
- { .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
- { .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
On Tue, Jun 12, 2012 at 11:07 PM, Pandita, Vikram vikram.pand...@ti.com wrote:
On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter jon-hun...@ti.com wrote:
In order to use the CTI interrupts inconjunction with the DEBUGSS we need to
re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we
can create a PMU device based upon the DEBUGSS HWMOD and use the CTI
interrupts
for routing ARM PMU events for OMAP4430 devices.
This is based upon Benoit Cousson's patch [1].
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/073319.html
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..faf5a6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -482,10 +482,17 @@ static struct omap_hwmod_class
omap44xx_debugss_hwmod_class = {
};
/* debugss */
+static struct omap_hwmod_irq_info omap44xx_debugss_irqs[] = {
+ { .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
Data manual assigns cit0 == MA_IRQ_1 and cti1 == MA_IRQ_2
Why do you add 32 base GIC_START ?
Looks we do the same for pl310:
{ .name = pl310, .irq = 0 + OMAP44XX_IRQ_GIC_START },
so u can ignore my comment .. excuse the noise...
+ { .irq = -1 }
+};
+
static struct omap_hwmod omap44xx_debugss_hwmod = {
.name = debugss,
.class = omap44xx_debugss_hwmod_class,
.clkdm_name = emu_sys_clkdm,
+ .mpu_irqs = omap44xx_debugss_irqs,
.main_clk = trace_clk_div_ck,
.prcm = {
.omap4 = {
@@ -2447,8 +2454,6 @@ static struct omap_hwmod_class
omap44xx_mpu_hwmod_class = {
/* mpu */
static struct omap_hwmod_irq_info omap44xx_mpu_irqs[] = {
{ .name = pl310, .irq = 0 + OMAP44XX_IRQ_GIC_START },
- { .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
- { .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
{ .irq = -1 }
};
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 1/2] usb: musb: omap2+: fix context api's
On Sun, Oct 9, 2011 at 11:08 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Sep 07, 2011 at 09:19:23AM -0700, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com RxFifoSz, TxFifoSz, RxFifoAddr, TxFifoAddr are all indexed registers. So before doing a context save or restore, INDEX register should be set, then only one gets to the right register offset. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com applied, thanks thanks. (sorry for the long delay) Late is better than never :-) -- balbi -- 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] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Thu, Sep 8, 2011 at 3:41 PM, Mark Salter msal...@redhat.com wrote: On Wed, 2011-08-31 at 20:35 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 07:19:33PM +0100, Rob Herring wrote: On 08/31/2011 12:51 PM, Will Deacon wrote: Another thing that Marc and I tried on OMAP4 was not bringing up the secondary CPU during boot (by commenting out most of smp_init). In this case, I/O performance was good until we tried to online the secondary CPU. The online failed but after that the I/O performance was certainly degraded. Was the SCU enabled at that point? One diff between nosmp boot and offlining the 2nd core would be that the SCU remains enabled in the latter case. I think the SCU does not get enabled for nosmp. Our rudimentary test (printing out the SCU control register during boot) showed that it *was* enabled for nosmp. I think this is due to the secure world having to do that on OMAP so it's probably not true for other platforms. I've done a little test and found that turning on the MMU of the second core causes the problem to show up. I patched head.S so I stopped the second core in an infinite loop just before turning on the MMU. The system continues booting on core#0 and I see ~20MB/s with hdparm -t to an attached usb disk. Same setup but with second core being stopped with infinite loop just after MMU is enabled shows ~5MB/s. So whatever is going wrong, its not because of anything the second core is doing beyond turning on its MMU and doing an empty loop. what was the final take on the optimization? Excuse if i could not follow the whole thread - could someone summarize for the benefit of many. Thanks --Mark ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: fix compile break
On Sat, Oct 29, 2011 at 5:39 PM, Marek Vasut marek.va...@gmail.com wrote:
From: Vikram Pandita vikram.pand...@ti.com
omap_hsmmc.c: In function 'omap_hsmmc_protect_card':
omap_hsmmc.c:1273: error: 'pr_info' undeclared (first use in this function)
omap_hsmmc.c:1273: error: (Each undeclared identifier is reported only once
omap_hsmmc.c:1273: error: for each function it appears in.)
omap_hsmmc.c:1273: error: expected ';' before string constant
omap_hsmmc.c:1275: error: expected statement before ')' token
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e8ff123..101cd31 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1270,7 +1270,7 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host) }
} else {
if (!host-protect_card) {
- pr_info%s: cover is open,
+ pr_info(%s: cover is open,
card is now inaccessible\n,
mmc_hostname(host-mmc));
host-protect_card = 1;
Hey,
please care to check mailing list next time before you submit patch.
Cool down sir, no need to sound like hell broke loose.
If its already there, i may have missed it.
Please ignore.
This is
already fixed for about five hours now. Actually, the last patch submitted to
the mailing list fixes exactly this problem:
[PATCH] omap_hsmmc: fix missing parenthesis in pr_info
--
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] usb: musb: fix pm_runtime calls while atomic
Felipe On Fri, Aug 12, 2011 at 10:21 AM, Pandita, Vikram vikram.pand...@ti.com wrote: On Fri, Aug 12, 2011 at 10:04 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Pandita, Vikram wrote: On Fri, Aug 12, 2011 at 8:50 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com musb pm_runtime_get_sync call happens in intrrupt context on cable attach case That can result in re-enabling the interrupts and cause side affects. So move the code to a work queue. Any chance you go to line this up for the merge window? Instead of creating your own, new work queue, just use the pre-existing PM work queue. In other words, replace pm_runtime_get_sync() with pm_runtime_get(). In this case it may not work, because immediately after a pm_runtime_get_sync(), we are going to access MUSB registers and xxx_sync() call ensures we will not abort. I don't understand. Why not just access those registers from within the runtime_resume callback? I am not the runtime_pm expert, but as i understand, in this case: USB cable attach Get Interrupt from Power IC (twl6030) Interrupt handler calls notifier_call_chain - cable attach/detach notification handler in MUSB code Notification_handler does: * enable clocks for musb register access ** setup musb registers to start getting control ep0 interrupts for usb enumeration * is the part were we need to do the clock enabling synchronously. The runtime_resume() call-back today for musb does not have to do anything with USB enumeration. 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
Re: [PATCH] usb: musb: use put_sync_suspend instead of put_sync
On Fri, Aug 12, 2011 at 2:01 AM, Felipe Balbi ba...@ti.com wrote: Hi, (sorry for top-posting) Moiz, are we going to have another set of this ? The problem was with pm_runtime() functions getting called from atomic context and we did a work around by calling the runtime functions from a work queue. That seems to fix the issue. We will post that out as an alternative to marking the irq_safe and thus causing the parent to never idle. On Thu, Aug 04, 2011 at 05:18:37PM -0700, Kevin Hilman wrote: Moiz Sonasath m-sonas...@ti.com writes: From: Axel Haslam axelhas...@ti.com As Documented in runtime documentation, drivers can call put_sync in contexts where sleep is allowed, in contexts where sleep is not possible, the drivers need to mark these as to be made interrupt safe and also use put_sync_suspend instead of put_sync as the idle callbacks will be called with interrupt enabled - which is not a good thing to happen in isr context. There are several things happening in this patch, and I think this needs to be broken into separate fixes/features. Re: the put_sync_suspend change, for mainline, I posted a fix that allows a normal _put_sync() to work from IRQ-safe context: https://lists.linux-foundation.org/pipermail/linux-pm/2011-July/032261.html That will be merging for v3.2, likely for v3.1-rc and possible for v3.0.stable, so while changing the driver is harmless, it's no longer necessary. [...] A call to pm_runtime_irq_safe, will indefently prevent the parent from sleeping by doing a call to get-sync on the parent. this is to prevent a irq-safe child to wait for a non-irq safe parent. For this reason, the parent runtime-pm suspend is blocked, and we dont let L3 and CORE enter into low power. First, you should describe why you need to use pm_runtime_irq_safe() in the first place, since the rest of the workarounds in this patch are a result of using that. For those of us not intimately familar with this driver, a description of why IRQ-safe callbacks are needed would be most helpful. It might be that a simpler solution would be switching to using asynchronous runtime PM calls so that IRQ-safe mode is not required. As a workaround, we call the parent runtime functions on the child runtime hooks, for this to work, the parent has to be set to ignere children, otherwise, even with a timmed autosuspend call, will return BUSY, as the child is not yet suspended. Hmm, why is the child not yet suspended when the parent's autosuspend delay expires? Also, It's not clear to me how the parent is eventually suspending at all. After pm_runtime_irq_safe() is called on the child, the parent should *never* runtime suspend. Not only does pm_runtime_irq_safe() do a get_sync() on the parent, but rpm_suspend() has an explict check for !dev-power.irq_safe before suspending the parent. Something else must be going on (actually, going wrong) in order for the parent device to runtime suspend. Is the problem with L3/CORE not runtime suspending? or is it a problem with system suspend? If system suspend, are you using current mainline? There is now support at the omap_device level[1] to ensure all devices are idled at the omap_device level during system suspend. This patch is based off: https://lkml.org/lkml/2011/7/20/357 Signed-off-by: Axel Haslam axelhas...@ti.com Reported-by: Colin Cross ccr...@google.com Signed-off-by: Moiz Sonasath m-sonas...@ti.com --- drivers/usb/musb/musb_core.c | 9 + drivers/usb/musb/musb_gadget.c | 2 +- drivers/usb/musb/omap2430.c | 4 +++- 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index c71b037..d22bc73 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1941,7 +1941,11 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl) pm_runtime_use_autosuspend(musb-controller); pm_runtime_set_autosuspend_delay(musb-controller, 200); + pm_runtime_use_autosuspend(musb-controller-parent); + pm_runtime_set_autosuspend_delay(musb-controller-parent, 500); + pm_suspend_ignore_children(musb-controller-parent,true); Running checkpatch would have yelled at you on this line: ERROR: space required after that ',' (ctx:VxV) pm_runtime_enable(musb-controller); + pm_runtime_irq_safe(musb-controller); spin_lock_init(musb-lock); musb-board_mode = plat-mode; @@ -2375,6 +2379,9 @@ static int musb_runtime_suspend(struct device *dev) musb_save_context(musb); + pm_runtime_mark_last_busy(musb-controller-parent); + pm_runtime_put_autosuspend(musb-controller-parent); + return 0; } @@ -2392,6 +2399,8 @@ static int musb_runtime_resume(struct device *dev) * Also context restore without save does not make * any sense */ + if
Re: [PATCH] usb: musb: use put_sync_suspend instead of put_sync
On Fri, Aug 12, 2011 at 6:55 AM, Pandita, Vikram vikram.pand...@ti.com wrote: On Fri, Aug 12, 2011 at 2:01 AM, Felipe Balbi ba...@ti.com wrote: Hi, (sorry for top-posting) Moiz, are we going to have another set of this ? The problem was with pm_runtime() functions getting called from atomic context and we did a work around by calling the runtime functions from a work queue. That seems to fix the issue. We will post that out as an alternative to marking the irq_safe and thus causing the parent to never idle. Here is the new post: https://patchwork.kernel.org/patch/1061282/ [.] -- 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] usb: musb: fix pm_runtime calls while atomic
On Fri, Aug 12, 2011 at 8:50 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com musb pm_runtime_get_sync call happens in intrrupt context on cable attach case That can result in re-enabling the interrupts and cause side affects. So move the code to a work queue. Instead of creating your own, new work queue, just use the pre-existing PM work queue. In other words, replace pm_runtime_get_sync() with pm_runtime_get(). In this case it may not work, because immediately after a pm_runtime_get_sync(), we are going to access MUSB registers and xxx_sync() call ensures we will not abort. 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
Re: [PATCH] usb: musb: fix pm_runtime calls while atomic
On Fri, Aug 12, 2011 at 10:04 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Pandita, Vikram wrote: On Fri, Aug 12, 2011 at 8:50 AM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 12 Aug 2011, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com musb pm_runtime_get_sync call happens in intrrupt context on cable attach case That can result in re-enabling the interrupts and cause side affects. So move the code to a work queue. Instead of creating your own, new work queue, just use the pre-existing PM work queue. In other words, replace pm_runtime_get_sync() with pm_runtime_get(). In this case it may not work, because immediately after a pm_runtime_get_sync(), we are going to access MUSB registers and xxx_sync() call ensures we will not abort. I don't understand. Why not just access those registers from within the runtime_resume callback? I am not the runtime_pm expert, but as i understand, in this case: USB cable attach Get Interrupt from Power IC (twl6030) Interrupt handler calls notifier_call_chain - cable attach/detach notification handler in MUSB code Notification_handler does: * enable clocks for musb register access ** setup musb registers to start getting control ep0 interrupts for usb enumeration * is the part were we need to do the clock enabling synchronously. The runtime_resume() call-back today for musb does not have to do anything with USB enumeration. 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
Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Thu, Jul 28, 2011 at 9:45 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 19, 2011 at 10:11:58PM -0700, Vikram Pandita wrote:
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
applied this one, but I changed commit log and code comment a little
bit. Here's updated commit:
commit e9c281b174f188adb7950ea8f6a55ca07be69914
Author: Anand Gadiyar gadi...@ti.com
Date: Tue Jul 19 22:11:58 2011 -0700
usb: musb: Enable DMA mode1 RX for transfers without short packets
This patch enables DMA mode1 for the RX patch when we know
there won't be any short packets. We check that by looking
into the short_no_ok flag, if it's true we enable mode1, otherwise
we use mode0 to transfer the data.
This will result in a throughput performance gain of around
40% for USB mass-storage/mtp use cases.
[ ba...@ti.com : updated commit log and code comments slightly ]
Ack
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b67a062..d314f58 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -634,6 +634,7 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
u16 len;
u16 csr = musb_readw(epio, MUSB_RXCSR);
struct musb_hw_ep *hw_ep = musb-endpoints[epnum];
+ u8 use_mode_1;
if (hw_ep-is_shared_fifo)
musb_ep = hw_ep-ep_in;
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+ * Enable Mode 1 on RX transfers only when short_not_ok flag
+ * is set. Currently short_not_ok flag is set only from
+ * file_storage and f_mass_storage drivers
+ */
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
if (request-actual request-length) {
#ifdef CONFIG_USB_INVENTRA_DMA
if (is_buffer_mapped(req)) {
@@ -714,37 +727,41 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
* then becomes usable as a runtime use mode 1 hint...
*/
- csr |= MUSB_RXCSR_DMAENAB;
-#ifdef USE_MODE1
- csr |= MUSB_RXCSR_AUTOCLEAR;
- /* csr |= MUSB_RXCSR_DMAMODE; */
-
- /* this special sequence (enabling and then
- * disabling MUSB_RXCSR_DMAMODE) is required
- * to get DMAReq to activate
- */
- musb_writew(epio, MUSB_RXCSR,
- csr | MUSB_RXCSR_DMAMODE);
-#else
- if (!musb_ep-hb_mult
- musb_ep-hw_ep-rx_double_buffered)
+ /* Experimental: Mode1 works with mass
storage use cases */
+ if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
-#endif
- musb_writew(epio, MUSB_RXCSR, csr);
+ musb_writew(epio, MUSB_RXCSR, csr);
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ /*
+ * this special sequence (enabling
and then
+ * disabling MUSB_RXCSR_DMAMODE) is
required
+ * to get DMAReq to activate
+ */
+ musb_writew(epio, MUSB_RXCSR,
+ csr | MUSB_RXCSR_DMAMODE);
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ } else {
+ if (!musb_ep-hb_mult
+
Re: [PATCH v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Tue, Jul 19, 2011 at 10:53 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Jul 20, 2011 at 11:15 AM, Pandita, Vikram vikram.pand...@ti.com
wrote:
On Tue, Jul 19, 2011 at 10:34 PM, Jassi Brar jassisinghb...@gmail.com
wrote:
On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com
wrote:
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei
Shtylyovsshtyl...@mvista.com comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
v4 - adding my signed-off as per Kevin Hilman khil...@ti.com
drivers/usb/musb/musb_gadget.c | 68
---
1 files changed, 42 insertions(+), 26 deletions(-)
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+ * Enable Mode 1 for RX transfers only for mass-storage
+ * use-case, based on short_not_ok flag which is set only
+ * from file_storage and f_mass_storage drivers
+ */
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
There is nothing UMS class specific in this patch...
(request-short_not_ok len == musb_ep-packet_sz) may not be the
signature of, and only of, Mass Storage Functions. So maybe removing
the UMS mention from
comment and change-log is a good idea.
Have you grepped the code in drivers/usb/gadget/*.*
only UMS sets this flag today and hence the use of this flag.
As i understand, on UMS, CSW/data/CBW - the data part size is a known
size and to be safe that mode=1 dma is not stuck up,
the mode is enabled only for the gadget driver that sets short_not_ok
flag - and that today happens to be only UMS.
This *today happens to be only UMS* is my exact point here.
Can you guarantee no other function driver will ever expect only
full packet xfers and treat short as errors ?
We are trying to test if short_not_ok may not be needed at all. But
all gadgets need to be tested on MUSB for that.
We will need wider help from MUSB maintainer/author(anand g) to
determine if removing short_not_ok is fine on MUSB for _all_ gadgets.
To be safe we only enable for UMS use case today that is definitely
working fine.
Time for Maintainer/author to pitch in !!
You might want to add is-ep-type-bulk-out check to the condition
though, so that it doesn't affect
cases that you didn't verify.
TX path (IN host), already uses the mode=1 DMA and hence the comment
is not valid.
This patch just also enables mode=1 on RX path.
Well, then no need for the ep-type check.
where did u see ep-type check? i can see only packet size check. Did i miss?
--
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] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand gadi...@ti.com wrote: From: Vikram Pandita vikram.pand...@ti.com This patch enables the DMA mode1 RX support. This feature is enabled based on the short_not_ok flag passed from gadget drivers. This will result in a thruput performance gain of around 40% for USB mass-storage/mtp use cases. Based on Original work by Anand Gadiyar gadi...@ti.com on 2.6.35 kernel Change-Id: I9b3a7cae73b63e86128d2caf4cdd67ab77556e75 Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com I think the change-id should not be included in upstream submissions - it may not be useful to someone looking at the changelog. So you probably should drop it. yes will drop that. This comes from gerrit commit hook that does not have a meaning for upstream. Could you please retain my authorship and sign off from the original patch, since I did pretty much all the original work on writing this patch That is given and clearly mentioned in the commit message. I will change the authorship with no issues, but would have been nice if you could have taken this upstream. We have been carrying this optimisation around in product kernels for a long time now and we keep redoing on each migration, with the downside of sometimes loosing the authorship. (and if I remember correctly several attempts to get this merged upstream)? I don't see any functional changes from my original patch. Wonder what were the reasons for not getting accepted? Can you re-ignite the discussion why it cannot be taken in then? - Anand -- 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] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Tue, Jul 19, 2011 at 12:46 AM, Gadiyar, Anand gadi...@ti.com wrote:
Pandita, Vikram wrote:
On Mon, Jul 18, 2011 at 11:22 PM, Gadiyar, Anand gadi...@ti.com wrote:
snip
But you can't just change authorship when the entire functional code
is the same. (It doesn't matter much to me - I'm not as active on
MUSB as I used to be; it's just the principle of the thing).
Moiz fixed the second part of your patch - which was not there on your
original work:
snip
+ if (use_mode_1) {
+ transfer_size =
min(request-length - request-actual,
+
channel-max_len);
musb_ep-dma-desired_mode = 1;
+ } else {
+ transfer_size =
min(request-length - request-actual,
+ (unsigned)len);
+
musb_ep-dma-desired_mode = 0;+
if (use_mode_1) {
+ transfer_size =
min(request-length - request-actual,
+
channel-max_len);
musb_ep-dma-desired_mode = 1;
+ } else {
+ transfer_size =
min(request-length - request-actual,
+ (unsigned)len);
+ musb_ep-dma-desired_mode = 0;
snip end
The history is:
Original author on .35 or .32 kernel : Anand Gadiyar
Fixes done by and some more forward ports: Moiz Sonasath
Tested on 3.0 and code cleanups, commit message updates, community
comment fixes: Vikram Pandita
Wonder if original author did not act all this while, is there
anything wrong in changing authorship with proper accreditation to
original author?
For future pushes, i would really like to learn what the linux
community suggests the right approach for such cases.
As i said, i am open to change and will repost as decided - there is
no attempt to sabotage anyone's work here :-)
We have been carrying this optimisation around in product kernels for
a long time now and we keep redoing on each migration,
with the downside of sometimes loosing the authorship.
(and if I remember correctly several
attempts to get this merged upstream)? I don't see any
functional changes from my original patch.
Wonder what were the reasons for not getting accepted?
Can you re-ignite the discussion why it cannot be taken in then?
You've already re-ignited this discussion. I haven't tested the patch
with the current kernel (and will do so soon), but if it does still
work and there are no objections, it ought to be merged.
- Anand
--
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 v4] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Tue, Jul 19, 2011 at 10:34 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Wed, Jul 20, 2011 at 10:41 AM, Vikram Pandita vikram.pand...@ti.com
wrote:
From: Anand Gadiyar gadi...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Tested-by: Vikram Pandita vikram.pand...@ti.com
---
v1 - initial push
v2 - fixed whitespace issues as per Sergei Shtylyovsshtyl...@mvista.com
comments
v3 - restor authorship to Anand Gadiyar gadi...@ti.com
v4 - adding my signed-off as per Kevin Hilman khil...@ti.com
drivers/usb/musb/musb_gadget.c | 68
---
1 files changed, 42 insertions(+), 26 deletions(-)
@@ -683,6 +684,18 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
if (csr MUSB_RXCSR_RXPKTRDY) {
len = musb_readw(epio, MUSB_RXCOUNT);
+
+ /*
+ * Enable Mode 1 for RX transfers only for mass-storage
+ * use-case, based on short_not_ok flag which is set only
+ * from file_storage and f_mass_storage drivers
+ */
+
+ if (request-short_not_ok len == musb_ep-packet_sz)
+ use_mode_1 = 1;
+ else
+ use_mode_1 = 0;
+
There is nothing UMS class specific in this patch...
(request-short_not_ok len == musb_ep-packet_sz) may not be the
signature of, and only of, Mass Storage Functions. So maybe removing
the UMS mention from
comment and change-log is a good idea.
Have you grepped the code in drivers/usb/gadget/*.*
only UMS sets this flag today and hence the use of this flag.
As i understand, on UMS, CSW/data/CBW - the data part size is a known
size and to be safe that mode=1 dma is not stuck up,
the mode is enabled only for the gadget driver that sets short_not_ok
flag - and that today happens to be only UMS.
You might want to add is-ep-type-bulk-out check to the condition
though, so that it doesn't affect
cases that you didn't verify.
TX path (IN host), already uses the mode=1 DMA and hence the comment
is not valid.
This patch just also enables mode=1 on RX path.
--
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] usb: musb: Enable DMA mode1 RX for USB-Mass-Storage
On Sat, Jul 16, 2011 at 4:22 AM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 16-07-2011 3:44, Vikram Pandita wrote:
From: Vikram Pandita vikram.pand...@ti.com
This patch enables the DMA mode1 RX support.
This feature is enabled based on the short_not_ok flag passed from
gadget drivers.
This will result in a thruput performance gain of around
40% for USB mass-storage/mtp use cases.
Based on Original work by
Anand Gadiyargadi...@ti.com on 2.6.35 kernel
Tested on OMAP4460 Blaze board.
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/musb/musb_gadget.c | 42
---
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 9412410..e643ec2 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -624,6 +624,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
/*
* Context: controller locked, IRQs blocked, endpoint selected
*/
+
Why?
typo - will fix in v2
static void rxstate(struct musb *musb, struct musb_request *req)
{
const u8 epnum = req-epnum;
@@ -714,10 +728,13 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
* then becomes usable as a runtime use mode 1 hint...
*/
- csr |= MUSB_RXCSR_DMAENAB;
-#ifdef USE_MODE1
+ /* Experimental: Mode1 works with mass storage use cases
+ */
+ if (use_mode_1) {
No, you can't put the code at the arbitrary indentation levels. Please
indent properly.
agree. v2 will address.
csr |= MUSB_RXCSR_AUTOCLEAR;
- /* csr |= MUSB_RXCSR_DMAMODE; */
+ musb_writew(epio, MUSB_RXCSR, csr);
+ csr |= MUSB_RXCSR_DMAENAB;
+ musb_writew(epio, MUSB_RXCSR, csr);
/* this special sequence (enabling and then
* disabling MUSB_RXCSR_DMAMODE) is required
@@ -725,26 +742,27 @@ static void rxstate(struct musb *musb, struct
musb_request *req)
*/
musb_writew(epio, MUSB_RXCSR,
csr | MUSB_RXCSR_DMAMODE);
-#else
+ musb_writew(epio, MUSB_RXCSR, csr);
+
+ } else {
if (!musb_ep-hb_mult
musb_ep-hw_ep-rx_double_buffered)
csr |= MUSB_RXCSR_AUTOCLEAR;
-#endif
+ csr |= MUSB_RXCSR_DMAENAB;
musb_writew(epio, MUSB_RXCSR, csr);
+ }
if (request-actual request-length) {
int transfer_size = 0;
-#ifdef USE_MODE1
+ if (use_mode_1) {
Same here.
agree. v2 will address.
transfer_size = min(request-length -
request-actual,
channel-max_len);
-#else
+ musb_ep-dma-desired_mode = 1;
+ } else {
transfer_size = min(request-length -
request-actual,
(unsigned)len);
-#endif
- if (transfer_size =
musb_ep-packet_sz)
- musb_ep-dma-desired_mode =
0;
- else
- musb_ep-dma-desired_mode =
1;
+ musb_ep-dma-desired_mode = 0;
+ }
use_dma = c-channel_program(
channel,
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP4: Regulator: Specify system has fully specified constraints
On Tue, Jun 21, 2011 at 5:24 PM, Girish S G giris...@ti.com wrote:
snip
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 04b7770..46f6800 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -560,6 +560,9 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
};
static int __init omap4_i2c_init(void)
{
+ /* This will allow unused regulator to be shutdown */
+ regulator_has_full_constraints();
+
Any particular reason to keep this call in i2c_init() function?
Does not look very intuitive to have generic regulator disable call in
an i2c init function !
omap4_pmic_init(twl6030, sdp4430_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 3415a5e..c425f9f 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -412,6 +412,9 @@ static struct i2c_board_info __initdata
panda_i2c_eeprom[] = {
static int __init omap4_panda_i2c_init(void)
{
+ /* This will allow unused regulator to be shutdown */
+ regulator_has_full_constraints();
+
ditto
omap4_pmic_init(twl6030, omap4_panda_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
/*
--
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 10/9] OMAP4: HWMOD: differentiate 4430 and 4460 bandgap
On Wed, May 25, 2011 at 8:41 PM, Nishanth Menon n...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
snip
+static struct omap_hwmod_opt_clk bandgap446x_opt_clks[] = {
+ { .role = fclk, .clk = bandgap_ts_fclk },
+};
+
+static struct omap_hwmod omap446x_bandgap_hwmod = {
+ .name = bandgap,
+ .class = omap44xx_bandgap_hwmod_class,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
+ },
+ },
+ .opt_clks = bandgap446x_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(bandgap446x_opt_clks),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
Does it call for having CHIP_IS_OMAP446X instead of CHIP_IS_OMAP4460 ?
What happens when we get say es2.0 for 4460? how do you accommodate that?
Take care of that case when the new silicon arrives or fix it now :-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3] Fix omap_type() function
-Original Message- From: Shilimkar, Santosh Sent: Saturday, July 10, 2010 2:32 AM To: Pandita, Vikram; linux-omap@vger.kernel.org Subject: RE: [PATCH 0/3] Fix omap_type() function -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram Sent: Saturday, July 10, 2010 12:39 PM To: linux-omap@vger.kernel.org Cc: Pandita, Vikram Subject: [PATCH 0/3] Fix omap_type() function Aim was to get omap_type() function work on omap4. In doing so, fixing an issue with is_sram_locked() function. Patches tested/verified on omap4 sdp. Patches based of latest linus commit: e467e10 Vikram Pandita (3): omap: sram: fix is_sram_locked check omap4: fix omap_type() function omap4: SRAM start and size change for EMU/HS devices arch/arm/plat-omap/include/plat/omap44xx.h |2 +- arch/arm/plat-omap/sram.c | 28 ++ - In summary only fixing is_sram_locked() and adding the OMAP_2PLUS is enough. All Valid comments. Thanks for the review. The control module needs to be fixed in right way because with different bases in wakeup and core control modules makes the current omap_control_read/write break on OMAP4. This is similar problem what we have on powerdomain base offsets and needs a proper handling. Fixing one base will break other register acceses Yes I can now see how my patch 2 has broken the MMC part in: omap4_hsmmc1_before_set_reg(...) Will post a saner V2 with: Patch 1 - your ACK Patch 2 - will fix omap_type() in right way by not using omap_ctrl_readl() instead using right offset Patch 3 - just add OMAP_2PLUS change -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Friday, July 02, 2010 5:18 AM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Basak, Partha; Gopinath, Thara
Subject: [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API
This patch updates the cpufreq driver to use the device
set rate API to scale the mpu frequency for OMAP3.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/cpu-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 9467827..cde02b5 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -29,6 +29,7 @@
#include mach/hardware.h
#include plat/clock.h
#include asm/system.h
+#include plat/omap_device.h
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
#include plat/omap-pm.h
@@ -84,7 +85,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
-#ifdef CONFIG_ARCH_OMAP1
+#ifdef CONFIG_ARiCH_OMAP1
^^
Typo I guess. Needs correction.
struct cpufreq_freqs freqs;
#endif
#if defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
@@ -117,7 +118,7 @@ static int omap_target(struct cpufreq_policy *policy,
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
freq = target_freq * 1000;
if (opp_find_freq_ceil(mpu_dev, freq))
- omap_pm_cpu_set_freq(freq);
+ omap_device_set_rate(mpu_dev, freq);
#endif
return ret;
}
--
1.7.0.rc1.33.g07cf0f
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] omap: hwspinlock: Added hwspinlock driver
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Que, Simon
Sent: Thursday, June 24, 2010 7:40 PM
To: linux-omap@vger.kernel.org
Cc: Kanigeri, Hari; Ohad Ben-Cohen
Subject: [RFC] omap: hwspinlock: Added hwspinlock driver
Hi,
snip
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6725b3a..14af19a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -170,3 +170,5 @@ obj-y += $(nand-
m) $(nand-y)
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
+
+obj-y += hwspinlocks.o
If this block is only on OMAP4, why build it for omap2 and omap3?
\ No newline at end of file
diff --git a/arch/arm/mach-omap2/hwspinlocks.c b/arch/arm/mach-
omap2/hwspinlocks.c
new file mode 100644
index 000..de813a0
--- /dev/null
+++ b/arch/arm/mach-omap2/hwspinlocks.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP hardware spinlock driver
+ *
+ * Copyright (C) 2010 Texas Instruments. All rights reserved.
+ *
+ * Contact: Simon Que s...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/slab.h
+
+#include plat/hwspinlock.h
+
+/* Base address of HW spinlock module */
+#define HWSPINLOCK_BASE(L4_44XX_BASE + 0xF6000)
+#define HWSPINLOCK_REGADDR(reg)\
+ OMAP2_L4_IO_ADDRESS(HWSPINLOCK_BASE + (reg))
+
+/* Spinlock register offsets */
+#define HWSPINLOCK_REVISION0x
+#define HWSPINLOCK_SYSCONFIG 0x0010
+#define HWSPINLOCK_SYSSTATUS 0x0014
+#define HWSPINLOCK_LOCK_BASE 0x0800
+
+/* Spinlock register addresses */
+#define HWSPINLOCK_REVISION_REG\
+ HWSPINLOCK_REGADDR(HWSPINLOCK_REVISION)
+#define HWSPINLOCK_SYSCONFIG_REG \
+ HWSPINLOCK_REGADDR(HWSPINLOCK_SYSCONFIG)
+#define HWSPINLOCK_SYSSTATUS_REG \
+ HWSPINLOCK_REGADDR(HWSPINLOCK_SYSSTATUS)
+#define HWSPINLOCK_LOCK_REG(i) \
+ HWSPINLOCK_REGADDR(HWSPINLOCK_LOCK_BASE + 0x4 * (i))
+
+/* Spinlock count code */
+#define HWSPINLOCK_32_REGS 1
+#define HWSPINLOCK_64_REGS 2
+#define HWSPINLOCK_128_REGS4
+#define HWSPINLOCK_256_REGS8
+#define HWSPINLOCK_NUMLOCKS_OFFSET 24
+
+
+/* Initialization function */
+int __init hwspinlocks_init(void)
+{
+ int i;
+ int retval = 0;
+
+ struct platform_device *pdev;
+ struct hwspinlock_plat_info *pdata;
+ void __iomem *base;
+ int num_locks;
+ bool is_reserved;
+
+ /* Determine number of locks */
+ switch (__raw_readl(HWSPINLOCK_SYSSTATUS_REG)
+ HWSPINLOCK_NUMLOCKS_OFFSET) {
+ case HWSPINLOCK_32_REGS:
+ num_locks = 32;
+ break;
+ case HWSPINLOCK_64_REGS:
+ num_locks = 64;
+ break;
+ case HWSPINLOCK_128_REGS:
+ num_locks = 128;
+ break;
+ case HWSPINLOCK_256_REGS:
+ num_locks = 256;
+ break;
+ default:
+ return -EINVAL; /* Invalid spinlock count code */
+ }
+
+ /* Device drivers */
+ for (i = 0; i num_locks; i++) {
+ pdev = platform_device_alloc(hwspinlock, i);
+
+ base = HWSPINLOCK_LOCK_REG(i); /* Get register address */
+
+ /* Some locks are reserved for system use */
+ if (i CONFIG_OMAP_HWSPINLOCK_NUM_RESERVED)
+ is_reserved = true;
+ else
+ is_reserved = false;
+
+ /* Pass data to device initialization */
+ pdata = kzalloc(sizeof(struct hwspinlock_plat_info),
+
GFP_KERNEL);
+ pdata-num_locks = num_locks;
+ pdata-io_base = base;
Any reason not to have the driver ioremap the HWSPINLOCK address and rather
pass the physical
RE: [RFC] [PATCH v2 3/4] OMAP4: Keyboard board support
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Arce, Abraham
Sent: Thursday, May 13, 2010 3:51 PM
To: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: [RFC] [PATCH v2 3/4] OMAP4: Keyboard board support
Keyboard support for SDP OMAP4430
Signed-off-by: Abraham Arce x0066...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 157
+++
1 files changed, 157 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 6cce6f2..19742c5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -19,6 +19,8 @@
#include linux/gpio.h
#include linux/usb/otg.h
#include linux/spi/spi.h
+#include linux/input.h
+#include linux/input/matrix_keypad.h
...
+
+struct omap_device *od;
Any reason to have this global?
+
+static int __init sdp4430_keypad_init(void)
+{
+ struct omap_hwmod *oh;
+ struct matrix_keypad_platform_data *pdata;
+
...
--
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 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Tony -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, May 03, 2010 7:59 PM To: Pandita, Vikram Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Pais, Allen Subject: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 And here's this patch one more time. Both 2a and 2b are needed for zoom debug uart to work. Test 1: Tested on Zoom3 with 02a and 02b applied. Enabled DEBUG_LL. Booted fine. Test 2: Applied Hack printk.patch (attached) Booted fine and duplicate logs can be seen on console = printascii is working. Ack-by: Vikram Pandita vikram.pand...@ti.com Regards, Tony printk.patch Description: printk.patch
RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, April 30, 2010 8:51 PM To: Kevin Hilman Cc: Pandita, Vikram; linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Pais, Allen Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 * Tony Lindgren t...@atomide.com [100430 18:33]: So far only tested on n900, will give it a try also on zoom3 after updating the zoom3 related patch. And here's the updated zoom debug_ll patch, seems to work. For testing if I put this printk hack (the good old days patch), Zoom3 does not boot after applying your patch. So looks like we are still missing something for zoom2/3 to work. Can debug tomorrow. --- a/arch/arm/plat-omap/include/plat/uncompress.h +++ b/arch/arm/plat-omap/include/plat/uncompress.h @@ -20,27 +20,22 @@ #include linux/types.h #include linux/serial_reg.h +#include asm/memory.h +#include asm/io.h #include asm/mach-types.h #include plat/serial.h BTW, the include of asm/io.h is not needed, I'll remove that. Regards, Tony printk-dbg.patch Description: printk-dbg.patch
RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, April 30, 2010 4:21 PM To: Tony Lindgren Cc: linux-arm-ker...@lists.infradead.org; Pandita, Vikram; linux- o...@vger.kernel.org; Pais, Allen Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [100430 13:50]: Tony Lindgren t...@atomide.com writes: Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL. Additionally, 0xfb00 overlaps with other areas, so use 0xfa40 for the virtual address instead. Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline. Cc: Allen Pais allen.p...@ti.com Cc: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/kernel/head.S | 10 ++ arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- arch/arm/mach-omap2/io.c |9 + arch/arm/plat-omap/include/plat/serial.h |2 +- 5 files changed, 23 insertions(+), 4 deletions(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index eb62bf9..fd870e1 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -328,6 +328,16 @@ __create_page_tables: add r0, r4, #0xd800 18 str r3, [r0] #endif +#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3) + /* + * Zoom2 and Zoom3 have UARTs only on the debug board. + * The debug board is connected to the GPMC. + */ + add r0, r4, #0xfa00 18 + orr r0, r0, #0x0040 18 @ ZOOM_UART_VIRT + orr r3, r7, #0x1000 @ ZOOM_UART_BASE + str r3, [r0] +#endif I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S That mapping does not cover the GPMC area where this UART is. Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else. Here is the problem - with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io Why: Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register. this introduces a dependency that UART1 registers also be mapped (virt-phy). So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x480 based mapping and for external uart zoom3 port, create this extra mapping. So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram Sent: Friday, April 30, 2010 4:37 PM To: Kevin Hilman; Tony Lindgren Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pais, Allen Subject: RE: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, April 30, 2010 4:21 PM To: Tony Lindgren Cc: linux-arm-ker...@lists.infradead.org; Pandita, Vikram; linux- o...@vger.kernel.org; Pais, Allen Subject: Re: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@deeprootsystems.com [100430 13:50]: Tony Lindgren t...@atomide.com writes: Zoom2 and 3 have UARTs only on the external debug board. GPMC needs to be mapped early to use it for DEBUG_LL. Additionally, 0xfb00 overlaps with other areas, so use 0xfa40 for the virtual address instead. Note that with the pending serial.c patches you need to set console=ttyS0,115200n8 as it will be the only UART mapped. To use DEBUG_LL, you need to pass also earlyprintk in cmdline. Cc: Allen Pais allen.p...@ti.com Cc: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/kernel/head.S | 10 ++ arch/arm/mach-omap2/board-zoom-debugboard.c|2 +- arch/arm/mach-omap2/include/mach/debug-macro.S |4 ++-- arch/arm/mach-omap2/io.c |9 + arch/arm/plat-omap/include/plat/serial.h |2 +- 5 files changed, 23 insertions(+), 4 deletions(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index eb62bf9..fd870e1 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -328,6 +328,16 @@ __create_page_tables: add r0, r4, #0xd800 18 str r3, [r0] #endif +#if defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3) +/* + * Zoom2 and Zoom3 have UARTs only on the debug board. + * The debug board is connected to the GPMC. + */ +add r0, r4, #0xfa00 18 +orr r0, r0, #0x0040 18 @ ZOOM_UART_VIRT +orr r3, r7, #0x1000 @ ZOOM_UART_BASE +str r3, [r0] +#endif I don't see why this part is needed. The same mapping is done using the .io_pg_offset in the machine description which is done just before this in head.S That mapping does not cover the GPMC area where this UART is. Hmm, then shouldn't that be fixed? I understood the .phys_io and and .io_pg_offset fields of the mach_desc to be specifically for mapping the early UART, and nothing else. Here is the problem - with current approach we need two mappings to happen and the MACHINE_START() code allows for only one via .io_pg_offset and .phys_io Why: Tony's approach is to pass the information about the debug uart number from the UART1 Scratchpad register. this introduces a dependency that UART1 registers also be mapped (virt-phy). So for Tony's approach to work, .phys_io/.io_pg_offset continued to have 0x480 based mapping and for external uart zoom3 port, create this extra mapping. So find a better way from compressed.S to pass the uart number to kernel, and we can solve the problem. Reference to that dependency: Commit: 0c8219f0 snip/start +/* + * Store the DEBUG_LL uart number into UART1 scratchpad register. + * See also debug-macro.S, and serial.c for related code. + * + * Please note that we currently assume that: + * - UART1 clocks are enabled for register access + * - UART1 scratchpad register can be used + */ +static void set_uart1_scratchpad(unsigned char port) snip/end Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v4 1/1] Registering sgx device and it's platform data
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Friday, April 23, 2010 10:45 AM To: Agarwal, Preshit Cc: linux-omap@vger.kernel.org; felipe.ba...@nokia.com; Pais, Allen Subject: Re: [PATCH v4 1/1] Registering sgx device and it's platform data On Thu, 22 Apr 2010, Agarwal, Preshit wrote: In this patch SGX powervr_device is registered with it's platform specific data to provide information about setting constraint through omap_pm_set_min_bus_tput. This patch removes the requirement of EXPORT_SYMBOL for the same function. Signed-off-by: Preshit Agarwal preshit.agar...@ti.com Reviewed-by: Paul Walmsley p...@pwsan.com That's the right way to pass these function pointers. Just to keep you posted, effort is happening on TI android kernel(.32) on integrating the sgx driver parts [1]. With user space still being non-GPL, not clear on the amount of functionality that can be enabled in upstream kernel. But a good start though to converge on the out-of-tree gaps !! Regards, Vikram [1] Internal tree references for sgx driver: http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=f33345b97ad528e8093cc4f865570a17024bbf85 http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=d9a3d7884c05fb310ff3d937e846202843c7c437 http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=bf6accefac104660ea9b8fc5e1a782a97793692e - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, March 19, 2010 10:03 PM To: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Cc: Pais, Allen; Pandita, Vikram Subject: Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 * Tony Lindgren t...@atomide.com [100319 19:43]: * Tony Lindgren t...@atomide.com [100319 17:42]: * Tony Lindgren t...@atomide.com [100319 17:30]: Hi all, Got a zoom3 finally! This is needed to boot with DEBUG_LL + earlyprintk. And of course it won't compile because of a missing #. Here's the working version. One more time. Looks like what I posted is not enough, we also need to make sure the mapping does not overlap with other regions. So basically we can't use 0xfb00 like we currently have, let's use 0xf700 instead unless somebody has better ideas. And now 0xf700 is in vmalloc area.. Needs to be looked more. On internal TI trees, we do have 0xfa40 working. Guess that is the magic number. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Tuesday, March 02, 2010 10:11 AM To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Manju, snip So, if you want to boot, take series [1] and [2], and then you should be able to boot with ttyS0. Yes I could boot the zoom3 with your patchset with console on ttyS0: Relevant Boot Log: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x1000 (irq = 262) is a ST16654 console [ttyS0] enabled Regards, Sergio --- [1] http://marc.info/?l=linux-omapm=126730356232287w=2 [2] http://marc.info/?l=linux-omapm=126746974103007w=2 -- 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: omap3evm: Doesn't boot at 4fa42e46
Sanjeev/Tony
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
Lindgren
Sent: Wednesday, February 10, 2010 11:34 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: omap3evm: Doesn't boot at 4fa42e46
* Premi, Sanjeev pr...@ti.com [100210 09:09]:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
Sent: Tuesday, February 09, 2010 9:34 PM
To: linux-omap@vger.kernel.org
Subject: RE: omap3evm: Doesn't boot at 4fa42e46
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Premi, Sanjeev
Sent: Tuesday, February 09, 2010 9:02 PM
To: linux-omap@vger.kernel.org
Subject: omap3evm: Doesn't boot at 4fa42e46
Hi all,
Just updated my repo to the commit:
commit 4fa42e4679324b0e3c54fb509535eea3923ccb63
Merge: e599f12 c446167
Author: Tony Lindgren t...@atomide.com
Date: Thu Feb 4 20:07:44 2010 -0800
The kernel builds fine; but doesn't boot on the OMAP3EVM.
I have been able to trace the code until rest_init(); but
will need to restart debugging.
There seems to be an exception during execution.
Will continue to dig further. This is just an FYI.
The kernel panics during I2C init in function omap3_evm_i2c_init()
during this call:
omap_register_i2c_bus(2, 400, NULL, 0);
I see that Zoom2/3 also don't boot up and given that DEBUG_LL does not work for
these boards,
its very difficult to narrow down the problem.
After around 2 hours of narrowing down, this is what solves the issue probably:
m0_entry seems to be null, causing strcmp() to crash.
Patch: (will not apply as TABS are not there :) )
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 986077f..d5a03f8 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -435,7 +435,7 @@ int __init omap_mux_init_signal(char *muxname, int val)
char *m0_entry = m-muxnames[0];
int i;
- if (m0_name strcmp(m0_name, m0_entry))
+ if (m0_name m0_entry strcmp(m0_name, m0_entry))
continue;
for (i = 0; i OMAP_MUX_NR_MODES; i++) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, January 21, 2010 9:07 PM To: Pandita, Vikram Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2 * Pandita, Vikram vikram.pand...@ti.com [100118 17:48]: * Russell King - ARM Linux li...@arm.linux.org.uk [100116 11:31]: Why not do something like this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 .popsection Updated patch below using .data. This assumes getting an additional tmp register passed to addruart as in the patch I posted earlier. Also We may need a: omap_uart_shift: .word 0 Since shift also varies depending on different omap boards (external debug board shift=1, internal omap has shift=2) OK, I've added that too, but for mach-omap2 only. I've also added an experimental zoom2/3 support. Care to take try it out and see what happens on a zoom? Test on zoom3 failed with multi-omap branch. Debugging the same, should have a zoom correction patch out today. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/7] usb: musb: Add context save and restore support
Ajay/Felipe
Off usb list not to interfere with your merge req to Gregkh
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
On Behalf Of Felipe
Balbi
Sent: Thursday, January 21, 2010 7:34 AM
To: Greg KH
Cc: Linux USB Mailing List; Linux OMAP Mailing List; Gupta, Ajay Kumar;
Gadiyar, Anand; Felipe Balbi
Subject: [PATCH 1/7] usb: musb: Add context save and restore support
Importance: High
From: Ajay Kumar Gupta ajay.gu...@ti.com
Adding support for MUSB register save and restore during system
suspend and resume.
Changes:
- Added musb_save/restore_context() functions
- Added platform specific musb_platform_save/restore_context()
to handle platform specific jobs.
- Maintaining BlackFin compatibility by adding read/write
functions for registers which are not available in BlackFin
Tested system suspend and resume on OMAP3EVM board.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/usb/musb/musb_core.c | 146 ++
drivers/usb/musb/musb_core.h | 39 +++
drivers/usb/musb/musb_regs.h | 90 ++
drivers/usb/musb/omap2430.c | 16 +
4 files changed, 291 insertions(+), 0 deletions(-)
snip
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 83beeac..15a3f27 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -255,6 +255,22 @@ int __init musb_platform_init(struct musb *musb)
return 0;
}
+#ifdef CONFIG_PM
+void musb_platform_save_context(struct musb_context_registers
+ *musb_context)
+{
+ musb_context-otg_sysconfig = omap_readl(OTG_SYSCONFIG);
+ musb_context-otg_forcestandby = omap_readl(OTG_FORCESTDBY);
Any reason not to store: OTG_INTERFSEL
Depending on reset value is not a good idea.
+}
+
+void musb_platform_restore_context(struct musb_context_registers
+ *musb_context)
+{
+ omap_writel(musb_context-otg_sysconfig, OTG_SYSCONFIG);
+ omap_writel(musb_context-otg_forcestandby, OTG_FORCESTDBY);
+}
+#endif
+
int musb_platform_suspend(struct musb *musb)
{
u32 l;
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 22, 2010 2:55 PM To: Pandita, Vikram Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2 * Pandita, Vikram vikram.pand...@ti.com [100122 06:46]: OK, I've added that too, but for mach-omap2 only. I've also added an experimental zoom2/3 support. Care to take try it out and see what happens on a zoom? Test on zoom3 failed with multi-omap branch. Debugging the same, should have a zoom correction patch out today. Heh OK. I just pushed more updates into the multi-omap branch if you want to try to boot zoom2/zoom3 using the same .config. Refreshed my tree and I don't see your patches yet. There are still issues with booting 2420 though.. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2
Tony -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 22, 2010 3:11 PM To: Pandita, Vikram Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2 * Pandita, Vikram vikram.pand...@ti.com [100122 12:56]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 22, 2010 2:55 PM To: Pandita, Vikram Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic, v2 * Pandita, Vikram vikram.pand...@ti.com [100122 06:46]: OK, I've added that too, but for mach-omap2 only. I've also added an experimental zoom2/3 support. Care to take try it out and see what happens on a zoom? Test on zoom3 failed with multi-omap branch. Debugging the same, should have a zoom correction patch out today. Heh OK. I just pushed more updates into the multi-omap branch if you want to try to boot zoom2/zoom3 using the same .config. Refreshed my tree and I don't see your patches yet. Takes a few minutes to get mirrored from master.kernel.org.. Yes I tried with new branch and zoom2/3 does not work. Root cause: There is a very basic issue in low level code. We are allowed to create only one Physical to Virtual mapping using MACHINE_START() phys_io and io_pg_offst of size 0x10(1MB). Now for zoom2/3 we need to do following: MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board) - .phys_io= 0x4800, - .io_pg_offst= ((0xfa00) 18) 0xfffc, + .phys_io= 0x100, /*ZOOM_UART_BASE*/ + .io_pg_offst= ((0xfb00) 18) 0xfffc, /*ZOOM_UART_VIRT*/ .boot_params= 0x8100, .map_io = omap_zoom_map_io, .init_irq = omap_zoom_init_irq, This will create mapping: 0x100 - 0xfb00 of 1MB Now that leaves the phy address 0x480 omap register mapping, unmapped. So the code to get scratchpad contents will abort: arch/arm/mach-omap2/include/mach/debug-macro.S moveq \rx, #0x4800@ physical base address movne \rx, #0xfa00@ virtual base orr \rx, \rx, #0x0006a000 @ uart1 on omap2/3/4 This seems to be a basic limitation of low level code and I have not clue how to circumvent this. Thoughts? Regards, Vikram -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] omap: 3630: Disable internal pull-ups
Allen -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Pais, Allen Sent: Thursday, January 21, 2010 4:33 AM To: linux-omap@vger.kernel.org Subject: [PATCH 2/2] omap: 3630: Disable internal pull-ups From 9a6b34dca3ff8ce4a200df4b65037978e4325452 Mon Sep 17 00:00:00 2001 From: Allen Pais allen.p...@ti.com Please repost with From: Moiz Sonasath m-sonas...@ti.com Authorship needs to be preserved. I know it's a common miss and just needs minor correction. Date: Thu, 21 Jan 2010 21:23:41 +0530 Subject: [PATCH 2/2] omap: 3630: Disable internal pull-ups snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] omap: Clean the serial port defines
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
Lindgren
Sent: Friday, January 15, 2010 7:35 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 1/4] omap: Clean the serial port defines
This way we don't have conflicts with the defines
with compiling in multiple omaps. Set the addresses
for uarts in struct omap_globals for the early serial
init code.
Nice and much needed cleanup.
Signed-off-by: Tony Lindgren t...@atomide.com
snip
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 6e5207c..349de90 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -64,7 +64,7 @@ static void __init omap_serial_reset(struct
plat_serial8250_port *p)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase= OMAP_UART1_BASE,
+ .mapbase= OMAP1_UART1_BASE,
Is it possible to use the same approach as mach-omap2/ for physical address
assignments?
I like that approach.
Refer this part from mach-omap2:
+ serial_platform_data0[0].mapbase = omap2_globals-uart1_phys;
+ serial_platform_data1[0].mapbase = omap2_globals-uart2_phys;
+ serial_platform_data2[0].mapbase = omap2_globals-uart3_phys;
.irq= INT_UART1,
.flags = UPF_BOOT_AUTOCONF,
.iotype = UPIO_MEM,
snip
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
b/arch/arm/mach-omap2/include/mach/debug-
macro.S
index e9f255d..0c96e1c 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -11,6 +11,10 @@
*
*/
+#include linux/serial_reg.h
+
+#include plat/serial.h
+
.macro addruart,rx
mrc p15, 0, \rx, c1, c0
tst \rx, #1 @ MMU enabled?
@@ -44,15 +48,10 @@
.endm
.macro busyuart,rd,rx
-1001: ldrb\rd, [\rx, #(0x5 2)] @ OMAP-1510 and friends
- and \rd, \rd, #0x60
- teq \rd, #0x60
- beq 1002f
- ldrb\rd, [\rx, #(0x5 0)] @ OMAP-730 only
- and \rd, \rd, #0x60
- teq \rd, #0x60
+1001: ldrb\rd, [\rx, #(UART_LSR OMAP_PORT_SHIFT)]
Zoom2/3 kind of boards have external debug Serial port.
For those boards and maybe others, the shift value is 1 and not
OMAP_PORT_SHIFT(2).
This solution is not extensible to zoom2/3 boards with external debug board
uarts.
How do we address that?
+ and \rd, \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
+ teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
bne 1001b
-1002:
.endm
.macro waituart,rd,rx
snip
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
snip
@@ -269,11 +278,15 @@ static struct omap_globals omap343x_globals = {
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE),
+ .uart1_phys = OMAP3_UART1_BASE,
+ .uart2_phys = OMAP3_UART2_BASE,
+ .uart3_phys = OMAP3_UART3_BASE,
OMAP3630 also has 4 UARTS and this same global is getting used for both 34xx
and 36xx.
This is not right.
For 3630 uart4_phys = 0x49042000
};
void __init omap2_set_globals_343x(void)
{
__omap2_set_globals(omap343x_globals);
+ omap2_set_globals_uart(omap343x_globals);
}
#endif
@@ -285,6 +298,10 @@ static struct omap_globals omap4_globals = {
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
.cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
+ .uart1_phys = OMAP4_UART1_BASE,
+ .uart2_phys = OMAP4_UART2_BASE,
+ .uart3_phys = OMAP4_UART3_BASE,
+ .uart4_phys = OMAP4_UART4_BASE,
};
void __init omap2_set_globals_443x(void)
@@ -292,6 +309,7 @@ void __init omap2_set_globals_443x(void)
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
+ omap2_set_globals_uart(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 32c2227..a8fa0d7 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -47,6 +47,10 @@ struct omap_globals {
void __iomem*prm; /* Power and Reset Management */
void __iomem*cm;/* Clock Management */
void __iomem*cm2;
+ unsigned long uart1_phys;
+ unsigned long uart2_phys;
+ unsigned long uart3_phys;
+ unsigned long uart4_phys;
};
void omap2_set_globals_242x(void);
@@ -59,6
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
Lindgren
Sent: Friday, January 15, 2010 7:35 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic
UART_SCR- this is the scratchpad register
UART_OMAP_SCR - This is TI-only Supplementary control register
You probably confused the two (as rightly so since SCR is same name).
So there is no need to save/restore the UART_SCR register as you have done, see
inlined --
Define arch_decomp_setup() the same way as some other
architectures do. Use arch_id to configure the debug uart
based on the machine_is by storing it into the uart
scratchpad register for DEBUG_LL code to use.
Signed-off-by: Tony Lindgren t...@atomide.com
snip
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -161,11 +161,22 @@ static inline void serial_write_reg(struct
plat_serial8250_port *p, int offset,
static inline void __init omap_uart_reset(struct omap_uart_state *uart)
{
struct plat_serial8250_port *p = uart-p;
+ u8 scratchpad = 0;
+
+ /*
+ * Save UART1 scratchpad register value for UART1 for DEBUG_LL.
+ * See also include/plat/uncompress.h and include/mach/debug-macro.S.
+ */
+ if (p-mapbase == OMAP2_UART1_BASE) /* OMAP2/3/4UART1_BASE */
+ scratchpad = serial_read_reg(p, UART_SCR);
No need to save and restore the UART_SCR register.
This never gets used in this function.
What gets used is UART_OMAP_SCR which is OMAP specific supplimantry control
register
and not scratchpad.
serial_write_reg(p, UART_OMAP_MDR1, 0x07);
serial_write_reg(p, UART_OMAP_SCR, 0x08);
serial_write_reg(p, UART_OMAP_MDR1, 0x00);
serial_write_reg(p, UART_OMAP_SYSC, (0x02 3) | (1 2) | (1 0));
+
+ if (p-mapbase == OMAP2_UART1_BASE) /* OMAP2/3/4UART1_BASE */
+ serial_write_reg(p, UART_SCR, scratchpad);
Remove this as well. No need.
snip
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-
omap/include/plat/uncompress.h
index 13c305d..479bac8 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -19,62 +19,36 @@
#include linux/types.h
#include linux/serial_reg.h
+
+#include asm/mach-types.h
+
#include plat/serial.h
-unsigned int system_rev;
+static volatile u8 *uart1_base;
+static volatile u8 *uart_base;
+static volatile int uart_shift;
Just like uart_base is stored in scratchpad,
Somehow the uart_shift also needs to be stored so that boards with different
uart_shift requirements can be addressed. Where can we store this another
variable?
snip
/*
+ * Macros to configure UART1 and debug UART
+ */
+#define _DEBUG_LL_ENTRY(mach, uart1, dbg_uart, shift, dbg_id, reset_fn)
\
+ if (machine_is_##mach()) { \
+ uart1_base = (volatile u8 *)(uart1);\
+ uart_base = (volatile u8 *)(dbg_uart); \
+ uart_shift = (shift); \
+ port = (dbg_id);\
+ reset_fn; \
+ break; \
+ }
Nice Idea... you are the man !!
snip
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, January 16, 2010 2:00 PM To: Russell King - ARM Linux Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic * Russell King - ARM Linux li...@arm.linux.org.uk [100116 11:31]: On Sat, Jan 16, 2010 at 11:18:20AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100116 01:33]: On Fri, Jan 15, 2010 at 05:35:15PM -0800, Tony Lindgren wrote: diff --git a/arch/arm/mach-omap1/include/mach/debug-macro.S b/arch/arm/mach- omap1/include/mach/debug-macro.S index 23e4724..0174858 100644 --- a/arch/arm/mach-omap1/include/mach/debug-macro.S +++ b/arch/arm/mach-omap1/include/mach/debug-macro.S @@ -15,18 +15,71 @@ #include plat/serial.h +omap_uart_phys: .word 0x0 +omap_uart_virt: .word 0x0 I assume that you have no plans for XIP kernel support on OMAP, since these will be placed in the .text section, and is therefore read-only on XIP kernels. Did not think of that.. Maybe some addruart_premable solution here would. Or adding \tmp register for addruart and just do the detection for each character. How does doing it per-character help? The code is: ENTRY(printascii) addruart r3 b 2f 1: waituart r2, r3 senduart r1, r3 busyuart r2, r3 teq r1, #'\n' moveq r1, #'\r' beq 1b 2: teq r0, #0 ldrneb r1, [r0], #1 teqne r1, #0 bne 1b mov pc, lr Your wait/send/busy macros are just using the already provided base address which comes via r3 from addruart. That much is fine. I'm at a loss to understand why you think moving the address-getting functionality out of addruart into the individual wait/send/busy macros is going to help in any way. Sorry, I meant doing the detection each time addruart is run, not for each character. Why not do something like this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 Also We may need a: omap_uart_shift: .word 0 Since shift also varies depending on different omap boards (external debug board shift=1, internal omap has shift=2) Bingo..I think this was the key solution to the problem. I had posted long ago similar kind of implementation [1] and I wish rmk had given this nice idea then :) [1] http://marc.info/?l=linux-omapm=125269221820632w=2 See this part: + .align + .type __phy_uart_addr, #object +__phy_uart_addr: .word 0xFF + .type __virt_uart_addr, #object +__virt_uart_addr: .word 0xFF .popsection .macro addruart, rx ... + ldreq \rx, =omap_uart_phys@ physical base address + ldrne \rx, =omap_uart_virt@ virtual base ldr \rx, [\rx] + cmp \rx, #0 @ is port configured? + bne 99f @ already configured ... ? Sounds good to me. Will play with them and post refreshed patches. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: serial port input corruption with 2.6.32?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Wednesday, January 06, 2010 5:27 PM To: Steve Sakoman Cc: Robert Nelson; linux-omap@vger.kernel.org Subject: Re: serial port input corruption with 2.6.32? Steve Sakoman sako...@gmail.com writes: On Wed, Dec 23, 2009 at 1:06 PM, Robert Nelson robertcnel...@gmail.com wrote: On Wed, Dec 23, 2009 at 2:59 PM, Steve Sakoman sako...@gmail.com wrote: I'm seeing some strange behavior with my console serial port with 2.6.32. snip This will also have obvious and serious PM implications for non serial-console devices connected to UARTs (IrDA, bluetooth, modems, etc.) OMAP uarts for BT etc use h/w flow control, which is another way of waking up omap before sending any chars and hence don’t loose data. Console uses no flow control as you know. I've heard some ideas of muxing the UART into GPIO mode when idle and having a bitbanging to get the first char so it is not lost, but haven't seen any patches to do it. While it doesn't really solve your problem, I hope it at least helps understand the reason for it. You could write a book on uart pm :) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Anyone using an ISP1505?
-Original Message- From: Bill Gatliff [mailto:b...@billgatliff.com] Sent: Monday, December 21, 2009 11:07 AM To: Pandita, Vikram Cc: Gadiyar, Anand; linux-omap@vger.kernel.org; beaglebo...@googlegroups.com Subject: Re: Anyone using an ISP1505? Pandita, Vikram wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Bill Gatliff Sent: Friday, December 18, 2009 1:11 PM To: Gadiyar, Anand Cc: linux-omap@vger.kernel.org; beaglebo...@googlegroups.com Subject: Re: Anyone using an ISP1505? snip If it's with the EHCI controller, you need to take care of a couple of issues on the board (due to the input clocking mode used in the OMAP3). Can you elaborate? Thanks! For omap-ehci, the OMAP feeds in the 60Mhz clock to the PHY(1505 in your case). This is the input clocking mode of phy. It looks like the PHY state machine requires sometime to stabilize and lock into this 60Mhz clock input and this is done with a GPIO form omap. In ehci_hcd_omap_platform_data, Typically boards have . phy_reset = true . reset_gpio_port[0] = GPIO going to phy reset pin On your board you need to find, if there is a GPIO hooked from omap to PHY. And the GPIO behavior is decided by the PHY pin property ( whether its active high/low and whether its chipselect or reset of phy). By default the code assumes that the GPIO is connected to RESET pin: going 0 while the 60mhz clock input stabilizes and then once done, make it 1. So find out what GPIO from omap is connected to phy to control the phy. Ok, I'll look at that. I'm not sure if I have such a GPIO pin going to the PHY. Bill There is a basic confusion whether you are using MUSB OTG core of omap Or are you using EHCI core of omap. Both can be connected to a ULPI PHY and so you need to be very precise? I do have the XTAL input tied to SYS_CLK1/GPIO_10, and I've verified that I'm sending out a 19.2MHz clock signal on that pin. That seems to be what the ISP1505ABS chip needs. I start that clock in my board setup code. I just re-re-re-read the ISP1505 datasheet, and noticed this remark: Remark: When CLOCK starts toggling after power-up, the USB link must issue a reset command over the ULPI bus to ensure correct operation of the ISP1505. I see in drivers/usb/host/ehci-omap.c where the TLL is reset, but I can't find any code that sends a ULPI reset command out over the link. Or am I missing something? I also see drivers/usb/otg/ulpi.c which claims to support the ISP1504, which is a very similar chip to the ISP1505. But it also lacks any mention of a ULPI reset-type command. ULPI reset is implemented in hardware. No s/w intervention is required for this feature. As soon as 60Mhz clock starts, and iclocks are enabled to the USB core of omap, the ULPI reset goes on the ULPI bus. No surprise you are not finding this code, as there is none. Any additional thoughts? I'm losing hair fast on this one :) b.g. -- Bill Gatliff b...@billgatliff.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: [RFC] MUSB: Workaround for Ethernet data alignment issue
Nilkesh
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Patra,
Nilkesh
Sent: Sunday, December 13, 2009 10:51 PM
To: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; David Brownell; Gadiyar, Anand
Subject: [RFC] MUSB: Workaround for Ethernet data alignment issue
On the latest version of MUSB, DMA is not working properly if the Data in the
packet doesn't start at
32bit aligned address. This issue was found while using MUSB as g_ether. The
basic ping does not
work, if the data in the Ethernet packet does not start at 32bit aligned
address.
To overcome this issue, we found one solution mentioned in the below patch.
This patch moves data
(skb-data) by 2 bytes backwards in ethernet packet, which is nothing but
skb-head.
I want to know, if there are any better approaches to fix this issue.
I would NAK the first part of patch for following reasons (and suggestions are
inlined):
a) this change is specific to OMAP hw only and so should not try to change
generic files like usb/gadget/u_ether.c
that get compiled for all the architectures having usb.
b) there are two issues to be handled separately ( separate patches are good
for review )
RX side buffer alignments handling
TX side buffer alignments handling
Signed-off-by: Nilkesh Patra nilkesh.pa...@ti.com
---
drivers/usb/gadget/u_ether.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 2fc02bd..432b1bd 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -249,7 +249,6 @@ rx_submit(struct eth_dev *dev, struct usb_request *req,
gfp_t gfp_flags)
* but on at least one, checksumming fails otherwise. Note:
* RNDIS headers involve variable numbers of LE32 values.
*/
- skb_reserve(skb, NET_IP_ALIGN);
NAK. Do not remove this line,
Instead over-ride the NET_IP_ALIGN macro for your architecture.
One suggestion to do so:
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 058e7e9..b16c5f7 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -514,6 +514,10 @@ static inline unsigned long long __cmpxchg64_mb(volatile
void *ptr,
#define arch_align_stack(x) (x)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#define NET_IP_ALIGN 0
+#endif
+
#endif /* __KERNEL__ */
#endif
This has been verified to work for OMAP3630.
req-buf = skb-data;
req-length = size;
@@ -500,6 +499,8 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
unsigned long flags;
struct usb_ep *in;
u16 cdc_filter;
+ int i = 0;
+
spin_lock_irqsave(dev-lock, flags);
if (dev-port_usb) {
@@ -573,9 +574,6 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
length = skb-len;
}
- req-buf = skb-data;
- req-context = skb;
- req-complete = tx_complete;
This change would be to handle TX un-alignments.
So I would prefer to handle it separately ( a separate patch)
Have you explored the option of over-riding #define NET_SKB_PAD ??
/* use zlp framing on tx for strict CDC-Ether conformance,
* though any robust network rx path ignores extra padding.
@@ -585,6 +583,14 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
if (!dev-zlp (length % in-maxpacket) == 0)
length++;
+ if ((int)skb-data 0x2) {
+ skb_push(skb, 2);
Where have you made sure that skb-data allocation has this extra space of two
bytes?
+ for (i = 0; i length; i++)
+ skb-data[i] = skb-data[i+2];
+ }
+ req-buf = skb-data;
+ req-context = skb;
+ req-complete = tx_complete;
req-length = length;
--
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
Break: SMSC911x problems on Zoom3
SMSC911x is preventing Zoom3 board from booting on latest master (06d9e4fdd20e). Bootup logs and shows getting stuck here: --- net eth0: SMSC911x/921x identified at 0xd080c000, IRQ: 318 mmc1: new high speed MMC card at address 0001 mmcblk1: mmc1:0001 STM16G 1.00 GiB mmcblk1: unknown partition table Sending DHCP requests .. timed out! IP-Config: Retrying forever (NFS root)... net eth0: SMSC911x/921x identified at 0xd080c000, IRQ: 318 Sending DHCP requests ... -- 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 107/122] USB: ehci-omap.c: introduce missing kfree
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
On Behalf Of Greg
Kroah-Hartman
Sent: Friday, December 11, 2009 4:26 PM
To: linux-...@vger.kernel.org
Cc: Julia Lawall; Greg Kroah-Hartman
Subject: [PATCH 107/122] USB: ehci-omap.c: introduce missing kfree
Importance: High
From: Julia Lawall ju...@diku.dk
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
Impressive.
Wondering if sparse do such kind of things?
// smpl
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
... when != x
when != if (...) { +...x...+ }
(
x-f1 = E
|
(x-f1 == NULL || ...)
|
f(...,x-f1,...)
)
...
(
return \(0\|+...x...+\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 r.p1;
p2 r.p2;
@@
print * file: %s kmalloc %s return %s % (p1[0].file,p1[0].line,p2[0].line)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/usb/host/ehci-omap.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 7ba8df3..12f1ad2 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -558,7 +558,7 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
omap = kzalloc(sizeof(*omap), GFP_KERNEL);
if (!omap) {
ret = -ENOMEM;
- goto err_create_hcd;
+ goto err_disabled;
}
hcd = usb_create_hcd(ehci_omap_hc_driver, pdev-dev,
@@ -653,6 +653,7 @@ err_ioremap:
usb_put_hcd(hcd);
err_create_hcd:
+ kfree(omap);
err_disabled:
err_pdata:
return ret;
--
1.6.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig
Santosh -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. # CONFIG_RELAY is not set -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig
-Original Message- From: Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:49 PM To: Pandita, Vikram; t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk Subject: RE: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Wednesday, December 09, 2009 12:29 PM To: t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; li...@arm.linux.org.uk; Shilimkar, Santosh Subject: [PATCH 6/6] OMAP4: Sync up omap4430 defconfig Enable minimum features to boot omap4430 on es1.0 samples Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/configs/omap_4430sdp_defconfig | 146 ++- 1 files changed, 84 insertions(+), 62 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index a464ca3..49df3ad 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -1,26 +1,29 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc7 -# Tue Jun 9 12:36:23 2009 +# Linux kernel version: 2.6.32 +# Sun Dec 6 23:37:45 2009 snip -# CONFIG_SYSFS_DEPRECATED=y is not set -# CONFIG_SYSFS_DEPRECATED_V2=y is not set +CONFIG_SYSFS_DEPRECATED_V2=y This is a deprecated feature and don't introduce it back again. There haven been patches in recent past to get rid of this. Thanks Vikram. The thing is some of the busy box people are using get confused and stuck without this. The reason is they have not upgraded to latest busybox yet. Do you have pointers to those patches ? Here's the reference in k.org http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6502401d8169f76c6a72849cb55e8302226ca930 Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] omap: serial: fix non-empty uart fifo read abort
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, December 04, 2009 1:04 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org; Cousson, Benoit Subject: Re: [PATCH v2] omap: serial: fix non-empty uart fifo read abort snip + +#ifdef CONFIG_ARCH_OMAP4 +/* Never read empty UART fifo on omap4 */ +p-serial_in = serial_in_override; +#else +/* OMAP2/3 */ +/* Never read empty UART fifo on UARTs with IP rev =0x52 */ +if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF) += UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) +uart-p-serial_in = serial_in_override; +#endif } } We need to avoid ifdef else stuff, that just causes problems compiling in support for many omaps. In theory, we should be able to compile in support for all omaps starting with 16xx with v5 options.. Using cpu_is_omap() should do the trick here. The intent was to have check entirely based of UART IP revision. That worked fine for omap3xxx. But omap4 has totally different IP revision register (as per commit message) But I can see the point, and v3 of patch I can replace: #ifdef CONFIG_ARCH_OMAP4 by cpu_is_omap44xx() I tried following what was done in current serial.c file of many #ifdef CONFIG_ARCH_OMAP4 Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: I2C broken on OMAP 2430SDP?
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, December 03, 2009 7:01 AM To: Sonasath, Moiz Cc: linux-omap@vger.kernel.org; Pandita, Vikram; G, Manjunath Kondaiah Subject: RE: I2C broken on OMAP 2430SDP? Hello Moiz, On Wed, 2 Dec 2009, Sonasath, Moiz wrote: Hello Paul! snip bio: create slab bio-0 at 0 6i2c_omap i2c_omap.1: bus 1 rev3.6 at 400 kHz 6i2c_omap i2c_omap.2: bus 2 rev3.6 at 2600 kHz By any chance is this related to running i2c at slower clock speed? commit 6b61a83b31744d143b0e7bc92f463d831319eabc The maximum I2C speed depends on the system clock for GAIA: 2.2 MHz (sys-clk = 19.2 MHz) 2.4 MHz (sys-clk = 26 MHz) 2.9 MHz (sys-clk = 38.4 MHz) 4i2c_omap i2c_omap.2: timeout waiting for bus ready 4i2c_omap i2c_omap.2: timeout waiting for bus ready 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: clock init err [-110] 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio SIH_CTRL -- 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: Merge plans for 2.6.33 merge window
Tony -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, December 03, 2009 11:36 AM To: linux-omap@vger.kernel.org Subject: Merge plans for 2.6.33 merge window Hi all, snip Then there are some new board files, like touchbook and various fixes. 3630 board support (zoom3/sdp3630) is already integrated in for-next. However the only pending patches missing for 3630 boards to boot are these serial patches: http://patchwork.kernel.org/patch/61671/ http://patchwork.kernel.org/patch/61672/ Now there has been much discussion on the approach (errata vs feature). As a moderator, how would you like us to proceed on this? Regards, Vikram -- 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: u-boot for omap3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Weng, Wending Sent: Thursday, December 03, 2009 12:32 PM To: linux-omap@vger.kernel.org Subject: u-boot for omap3 Hi all, Anybody knows who takes care of u-boot for omap3, I wish to fix a L2 cahe related bug if Tom Rix is the Arm u-boot maintainer. Omap3 falls as one of the silicon he maintains. In reality, there are always internal/forked versions of the upstream that get used. Like for zoom boards I maintain it at dev.omapzoom.org /bootloader/* it's not done yet. Regards Wending -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] MUSB DMA_INTR register may sometimes read zero when infact there
Anand
From: Anand Gadiyar vikram.pand...@ti.com
MUSB DMA_INTR register may sometimes read zero when infact there
was a pending interrupt. Workaround this by reading the DMA_COUNT
values for all enabled channels when this condition occurs.
Flag these channels as the ones needing to be serviced.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Ajay Kumar Gupta ajay.gu...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
This issue exists on versions of the controller newer than 1.8.
The first version of this patch checked for this version
before acting. However to keep the code clean, I felt that
it is acceptable to do this unconditionally on all versions.
Also, the absence of the debug print meant that we would
never catch a spurious DMA interrupt on the older versions,
so adding the prints helps there.
drivers/usb/musb/musbhsdma.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
Index: linux-omap-2.6/drivers/usb/musb/musbhsdma.c
===
--- linux-omap-2.6.orig/drivers/usb/musb/musbhsdma.c
+++ linux-omap-2.6/drivers/usb/musb/musbhsdma.c
@@ -256,14 +256,34 @@ static irqreturn_t dma_controller_irq(in
spin_lock_irqsave(musb-lock, flags);
int_hsdma = musb_readb(mbase, MUSB_HSDMA_INTR);
- if (!int_hsdma)
- goto done;
#ifdef CONFIG_BLACKFIN
/* Clear DMA interrupt flags */
musb_writeb(mbase, MUSB_HSDMA_INTR, int_hsdma);
#endif
+ if (!int_hsdma) {
+ DBG(2, spurious DMA irq\n);
+
+ for (bchannel = 0; bchannel MUSB_HSDMA_CHANNELS; bchannel++) {
+ musb_channel = (struct musb_dma_channel *)
+ (controller-channel[bchannel]);
+ channel = musb_channel-channel;
+ if (channel-status == MUSB_DMA_STATUS_BUSY) {
+ csr = musb_readw(mbase,
+ MUSB_HSDMA_CHANNEL_OFFSET(bchannel,
+ MUSB_HSDMA_COUNT));
csr is a misnomer. It should be called count.
Also I recommend to add a function:
musb_read_hsdma_count() in musbhsdma.h just like the write
counterpart and use here.
+ if (csr == 0)
Should this not be if (csr != 0) only then you mark that dma channel as
generated the interrupt?
+ int_hsdma |= (1 bchannel);
+ }
+ }
+
+ DBG(2, int_hsdma = 0x%x\n, int_hsdma);
+
+ if (!int_hsdma)
+ goto done;
+ }
+
for (bchannel = 0; bchannel MUSB_HSDMA_CHANNELS; bchannel++) {
if (int_hsdma (1 bchannel)) {
musb_channel = (struct musb_dma_channel *)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] arm: omap: Add omap3_defconfig
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Olof snip +# CONFIG_OMAP_LL_DEBUG_UART1 is not set +# CONFIG_OMAP_LL_DEBUG_UART2 is not set +CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_NONE is not set I will suggest to keep LL_DEBUG_NONE as the default option and also disable the DEBUG_LL by default. a) Not all omap boards have UART3 as the debug low level interface b) Boards like zoom2/zoom3 have external uarts and should not define internal omap uart as Low level debug function. +# CONFIG_OMAP_PM_NONE is not set +CONFIG_OMAP_PM_NOOP=y +CONFIG_ARCH_OMAP34XX=y +CONFIG_ARCH_OMAP3430=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: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag
Tony From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, November 17, 2009 11:06 AM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag * Vikram Pandita vikram.pand...@ti.com [091116 15:00]: OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. So interoduce a flag in 8250 driver: UPF_NO_EMPTY_FIFO_READ If this flag is specified for an 8250 port, then first check if rx fifo has contents, and only then proceed to read the fifo. The change affects only boards passing this flag in port data and hence is non-disruptive for other boards. First reported/fixed on omap4430 by Shilimkar, Santosh This should go to linux-ser...@vger.kernel.org and Alan Cox. Patches were posted to l-o for review. Next step was to get it to the right subsystem. I thought Alan Cox stepped down from the maintainership of serial/tty subsystem. Not sure if Andrew Morton is taking these patches to MM tree for now. Any idea? Regards, Tony snip -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP clock/hwmod: fix off-by-one errors
Paul
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul
Walmsley
Sent: Tuesday, November 17, 2009 11:39 AM
To: Russell King - ARM Linux
Cc: linux-arm-ker...@lists.infradead.org; Juha Leppänen;
linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/3] OMAP clock/hwmod: fix off-by-one errors
snip
+/**
+ * omap_test_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ */
+#define omap_test_timeout(cond, timeout, index) \
+({\
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
+
There is a similar kind of function implemented in USB host, that returns
-ETIMEDOUT
Which makes more sense for failure case.
Maybe such a generic function for all omaps is needed.
Refer:
drivers/usb/host/ehci-hcd.c
static int handshake (struct ehci_hcd *ehci, void __iomem *ptr,
u32 mask, u32 done, int usec)
{
u32 result;
do {
result = ehci_readl(ehci, ptr);
if (result == ~(u32)0) /* card removed */
return -ENODEV;
result = mask;
if (result == done)
return 0;
udelay (1);
usec--;
} while (usec 0);
return -ETIMEDOUT;
}
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
1.6.5.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag
-Original Message- From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] Sent: Tuesday, November 17, 2009 3:26 PM To: Pandita, Vikram Cc: linux-ser...@vger.kernel.org; a...@linux-foundation.org; linux-omap@vger.kernel.org; Pandita, Vikram; Shilimkar, Santosh Subject: Re: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag On Tue, 17 Nov 2009 15:16:55 -0600 Vikram Pandita vikram.pand...@ti.com wrote: OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. Nothing wrong with the requirement but I think it would keep 8250.c a lot cleaner if you implemented that in the serial_in method for the OMAP3630/4430. It would also mean anyone adding a UART_RX or any cases you miss don't break in future Agree. Was contemplating this change in beginning, but lost that train of thought. Thx for your review time. This is especially true now as you can pass a private serial_in/serial_out method in the port register function. Our requirement is to over-right the serial_in for now. Is it fine to just add serial_in over-load or do you suggest both in/out? Care to submit an alternate patch doing it that way, or see any reason for not ? Working on it right away. See my patch in an hours time. Alan -- 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] omap3: ehci: Add regulator framework
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Pandita, Vikram
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gupta,
Ajay Kumar
Sent: Sunday, November 15, 2009 2:46 AM
To: linux-omap@vger.kernel.org
Cc: felipe.ba...@nokia.com; broo...@opensource.wolfsonmicro.com; Gupta, Ajay
Kumar
Subject: [PATCH] omap3: ehci: Add regulator framework
snip
+ /* get ehci regulator and enable */
+ for (i = 0 ; i OMAP3_HS_USB_PORTS ; i++) {
+ if (omap-port_mode[i] != EHCI_HCD_OMAP_MODE_PHY) {
+ omap-regulator[i] = NULL;
+ continue;
+ }
+ snprintf(supply, sizeof(supply), hsusb%d, i);
supply[] being auto variable, is it guaranteed to be null terminated?
Suggestion:
n = snprintf(supply, sizeof(supply), hsusb%d, i);
supply[n] = '\0';
Setting null is redundant as snprintf() does that internally too.
Can see snprinf calls vsnprintf and:
vsnprintf( ... )
...
if (size 0) {
if (str end)
*str = '\0';
else
end[-1] = '\0';
}
...
So I guess this is a noisy review comment :) and please ignore.
Patch looks good.
+ omap-regulator[i] = regulator_get(omap-dev, supply);
+ if (IS_ERR(omap-regulator[i]))
+ dev_dbg(pdev-dev,
+ failed to get ehci port%d regulator\n, i);
+ else
+ regulator_enable(omap-regulator[i]);
+ }
+
snip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: ehci: Add regulator framework
Ajay
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gupta,
Ajay Kumar
Sent: Sunday, November 15, 2009 2:46 AM
To: linux-omap@vger.kernel.org
Cc: felipe.ba...@nokia.com; broo...@opensource.wolfsonmicro.com; Gupta, Ajay
Kumar
Subject: [PATCH] omap3: ehci: Add regulator framework
snip
+ /* get ehci regulator and enable */
+ for (i = 0 ; i OMAP3_HS_USB_PORTS ; i++) {
+ if (omap-port_mode[i] != EHCI_HCD_OMAP_MODE_PHY) {
+ omap-regulator[i] = NULL;
+ continue;
+ }
+ snprintf(supply, sizeof(supply), hsusb%d, i);
supply[] being auto variable, is it guaranteed to be null terminated?
Suggestion:
n = snprintf(supply, sizeof(supply), hsusb%d, i);
supply[n] = '\0';
+ omap-regulator[i] = regulator_get(omap-dev, supply);
+ if (IS_ERR(omap-regulator[i]))
+ dev_dbg(pdev-dev,
+ failed to get ehci port%d regulator\n, i);
+ else
+ regulator_enable(omap-regulator[i]);
+ }
+
snip
--
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: CPUFREQ for beagle
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of tarek attia Sent: Friday, November 13, 2009 11:09 AM To: linux-omap Subject: CPUFREQ for beagle I want the CPUFREQdriver for the beagleboard which can work with linux2.6.29 properly You should be able to find that in Kevin's git tree: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-2.6.29 plz any one Help thnx in Advance tarek -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Some patches need reposting, inbox cleared, patchwork cleared
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, November 13, 2009 12:03 PM To: Gadiyar, Anand Cc: linux-omap@vger.kernel.org Subject: Re: Some patches need reposting, inbox cleared, patchwork cleared Tony, What happened to the 3630 support stuff that had been merged to your master branch as of yesterday? - Anand I meant, I see these patches in for-next, but they're not present in the l-o master branch. Is this deliberate? Hmm, it should be all merged into master branch also: $ git log --pretty=oneline --grep=3630 -n100 master arch/arm/mach-omap2 1739bbc268aeffc8d3d040cf6493ef4399a1a181 omap: 3630sdp: introduce 3630 sdp board support 13ac7e77f407e4c529eb1cb058031f896fd3e80c omap: zoom3: introduce zoom3 board support 79c6fce9daa80936eba830c49b6c559f5ca6295d omap: zoom: drop i2c-1 speed to 2400 3efbe15e7755108268b9ed72d3b6c6539f671ebe omap: zoom: rename zoom2 name to generic zoom 97bd76cf5e5c18ddcc8d38f997ae7aec4db3bb01 omap: zoom2: split board file for software reuse 2c8681ac36b4247c26c5789f63de9f522436c1c5 omap3630: Set omap3630 MMC1 I/O speed to 52Mhz 9283cf8a9d21889fb838634e7017e84acf69e79f omap3630: Configure HSMMC1 to 4-bit 1a309b7370e5aa6d703eded1afc53218a205a71f omap3630: Add HSMMC related checks 1e9e0b997c30b81b2165fa68cad4411e6136a8d2 omap3: 3630: update is_chip variable 6fb081fb525c05aed6fee28bf73fe4ee1fe2d5bd omap3: Introduce OMAP3630 Can you check and let me know if something is missing? I just verified booting zoom3 on l-o master, and its working fine. Only extra patch that I have to add is the 8250 patch, that needs posting separately. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: Some patches need reposting, inbox cleared, patchwork cleared
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] I just verified booting zoom3 on l-o master, and its working fine. OK good. Can you also try booting this patch from Felipe on 3630: http://patchwork.kernel.org/patch/59540/ Patch does not apply. Rebasing now and testing. Only extra patch that I have to add is the 8250 patch, that needs posting separately. OK Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Some patches need reposting, inbox cleared, patchwork cleared
Tony -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Pandita, Vikram From: Tony Lindgren [mailto:t...@atomide.com] I just verified booting zoom3 on l-o master, and its working fine. OK good. Can you also try booting this patch from Felipe on 3630: http://patchwork.kernel.org/patch/59540/ Patch does not apply. Rebasing now and testing. Rebased Patch (attached) boots up fine now on 3630 Zoom3 board. Logs: CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP Zoom3 board Memory policy: ECC disabled, Data cache writeback OMAP3630 ES1.0 (l2cache iva sgx neon isp ) arm-omap-code-cleanup-to-id.c.patch Description: arm-omap-code-cleanup-to-id.c.patch
RE: CPUFREQ for beagle
-Original Message- From: tarek attia [mailto:tarek.m.at...@gmail.com] Sent: Friday, November 13, 2009 12:12 PM To: Pandita, Vikram Subject: Re: CPUFREQ for beagle thnx for reply :) I tried it before but it downloaded kernel 2.6.32 which didn't work with the root file system of Angstrom wich relies on kernel 2.6.29 ! $git clone git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git $git checkout -b pm-29 origin/pm-2.6.29 This will get you to 2.6.29 pm code for sure. Any idea ??? any help will be appreciated Best Regards tarek On Fri, Nov 13, 2009 at 8:03 PM, Pandita, Vikram vikram.pand...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of tarek attia Sent: Friday, November 13, 2009 11:09 AM To: linux-omap Subject: CPUFREQ for beagle I want the CPUFREQdriver for the beagleboard which can work with linux2.6.29 properly You should be able to find that in Kevin's git tree: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git pm-2.6.29 plz any one Help thnx in Advance tarek -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/8] introduce 3630 boards
-Original Message- From: Gadiyar, Anand Sent: Wednesday, November 11, 2009 9:19 AM To: Pandita, Vikram; linux-omap@vger.kernel.org Subject: RE: [PATCH v2 0/8] introduce 3630 boards Vikram, I'm afraid current linux-omap master + these patches does not boot on my 3630SDP. Yes you are right because its missing one patch for the 8250 driver. Refer: git://dev.omapzoom.org/pub/scm/vikram/omap3.git zoom3 Patch: HACK: 8250: fix RX fifo access for 3630 I don't have a good implementation for this patch yet and hence I have kept it in my tree as a hack patch for now. Once the board files are upstreamed, I plan to look into this 8250 patch. 8250 maintainer is not there (alan cox). Also the omap-serial patch is being worked in parallel, and does not have this crash issue. So there are variables and reasons not to post that patch yet. The bootargs used were: mem=256M console=ttyS0,115200n8 noinitrd root=/dev/nfs rw nfsroot=172.24.162.66:/vol/vol2/swcoe_omapsw_linux1/anand/targ et,nolock,tcp ip=172.24.190.229:172.24.162.66:172.24.188.1:255.255.252.0:myomap::off -- 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 v3 1/3] input:misc:driver support for Kionix kxte9 accelerometer
Chris -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of chud...@kionix.com Sent: Wednesday, November 11, 2009 2:26 PM To: linux-omap@vger.kernel.org Cc: linux-in...@vger.kernel.org; dmitry.torok...@gmail.com; Chris Hudson Subject: [RFC PATCH v3 1/3] input:misc:driver support for Kionix kxte9 accelerometer From: Chris Hudson chud...@kionix.com This is a request for comments regarding adding driver support for the Kionix KXTE9 digital tri-axis accelerometer. This part features built-in tilt position (orientation), wake-up and back-to-sleep algorithms, which can trigger a user-configurable physical interrupt. The driver uses i2c for device communication, a misc node for IOCTLs, and input nodes for reporting acceleration data and interrupt status information. Moved to drivers/input/misc after discussion on linux-omap mailing list. Any way to test these features of accelerometer with your set of 3 patches applied? Say with a busybox filesystem or poky? Changes in this version: snip -- 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 v3 1/3] input:misc:driver support for Kionix kxte9 accelerometer
-Original Message- From: Chris Hudson [mailto:chud...@kionix.com] Pandita, Vikram wrote: Chris snip Any way to test these features of accelerometer with your set of 3 patches applied? Say with a busybox filesystem or poky? Sure, I've been using busybox with the ZoomII and testing the hardware throughout the development process. You'll need to attach a KXTE9 to I thought the accelerometer was a built-in feature of zoom2? Can you give reference of details of KXTE9 module? Is it to be plugged in to come connector on zoom2? the i2c-2 bus, vdd, iovdd, ground, and gpio156 on the J43 header if using a ZoomII. I can give you the exact pins I'm using if you would like. Thank you, Chris -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] RFC: introduce 3630 boards
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Subject: [PATCH 0/8] RFC: introduce 3630 boards Introducing 3630 boards: zoom3 and sdp3630 These patches are in my git tree at: git://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git zoom3 Sorry for the wrong tree. This is the right one: git://dev.omapzoom.org/pub/scm/vikram/omap3.git zoom3 this is to help ease cloning in case required. The peripherals are very similar for the two bards as per this discussion: http://marc.info/?l=linux-omapm=125676595710748w=2 So maximum reuse is done for the board files for zoom3 and sdp3630 Review comments incorporated: http://marc.info/?l=linux-omapm=125632676504364w=2 http://marc.info/?l=linux-omapm=125632720804869w=2 http://marc.info/?l=linux-omapm=125633994320138w=2 Vikram Pandita (8): omap: 3630: update is_chip variable omap: DEBUG_LL: allow no omap uart configuration omap: zoom2: split baord file for reuse omap: zoom2: update defconfig omap: zoom3: introduce zoom3 board support omap: zoom3: defconfig creation omap: 3630sdp: introduce 3630 sdp board support omap: 3630sdp: defconfig creation arch/arm/configs/omap_3630sdp_defconfig| 1606 arch/arm/configs/omap_zoom2_defconfig | 231 ++-- arch/arm/configs/omap_zoom3_defconfig | 1605 +++ arch/arm/mach-omap2/Kconfig|8 + arch/arm/mach-omap2/Makefile |8 + arch/arm/mach-omap2/board-3630sdp.c| 96 ++ arch/arm/mach-omap2/board-zoom-peripherals.c | 414 + arch/arm/mach-omap2/board-zoom2.c | 261 +--- arch/arm/mach-omap2/board-zoom3.c | 59 + arch/arm/mach-omap2/id.c |2 + arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 54 + arch/arm/plat-omap/Kconfig |3 + arch/arm/plat-omap/include/plat/cpu.h |7 +- arch/arm/plat-omap/include/plat/uncompress.h |4 +- 14 files changed, 4018 insertions(+), 340 deletions(-) create mode 100644 arch/arm/configs/omap_3630sdp_defconfig create mode 100644 arch/arm/configs/omap_zoom3_defconfig create mode 100755 arch/arm/mach-omap2/board-3630sdp.c create mode 100755 arch/arm/mach-omap2/board-zoom-peripherals.c mode change 100644 = 100755 arch/arm/mach-omap2/board-zoom2.c create mode 100755 arch/arm/mach-omap2/board-zoom3.c create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: 3630: update is_chip variable
-Original Message- From: Alexander Shishkin [mailto:virtu...@slind.org] Sent: Monday, November 02, 2009 12:29 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org; Menon, Nishanth Subject: Re: [PATCH] omap: 3630: update is_chip variable On Mon, Nov 02, 2009 at 07:05:49PM +0200, Alexander Shishkin wrote: 2009/10/20 Vikram Pandita vikram.pand...@ti.com: 3630 is getting treated like next rev of 3430 omap_chip.oc variable has to be updated for 3630 version Otherwise the Core power domain is not getting registered. This gets used in the registration of power domains in: arch/arm/mach-omap2/powerdomains34xx.h core_34xx_es3_1_pwrdm OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1) Core power doman will get registered for 3630 only when .oc is pouplated correctly. Tested on Zoom3(3630) board Signed-off-by: Vikram Pandita vikram.pand...@ti.com FWIW, Signed-off-by: Alexander Shishkin virtu...@slind.org Please excuse me, I obviously wanted to say Acked-by: Alexander Shishkin virtu...@slind.org Posting Ver 3 of the patch as the current patch [1] does not apply because of header file changes. Regards, Vikram [1] http://patchwork.kernel.org/patch/54847/ Regards, -- Alex -- 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
Welcome: OMAPZoom Tutorial Hour
Hello All, The first OMAPZoom Tutorial Hour will be hosted on Oct 28th at 8:30 AM CST (Central Standard Time) http://omappedia.org/wiki/Tutorial_Hour Topics for this session: 1) OMAPZoom.org community overview 2) Zoom OMAP34x-II Mobile Development Platform overview - by LogicPD 3) OMAP Linux kernel development - Overview and process WebEx: https://ti.webex.com/mw0304l/mywebex/default.do?siteurl=tiservice=1 (VOIP enabled) Meeting Number: 757949967 Meeting Password: None Teleconference bridge number in USA: 1-877-561-6828 or (972) 995 Teleconference Participant Code: 71051156 Teleconference bridge numbers for other countries please visit: http://www.ticonferencing.com/globalaccess/ We invite you to present in a future session - please suggest your topics at: http://www.omappedia.org/wiki/Tutorial_Hour_Topics Regards, Vikram -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Added board-3630.c file.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Pais,
Sent: Monday, October 26, 2009 4:40 PM
To: Pais, Allen; linux-omap@vger.kernel.org
Subject: RE: [PATCH 1/2] Added board-3630.c file.
Signed-off-by: Allen Pais allen.p...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c | 188
+++
1 files changed, 188 insertions(+), 0 deletions(-) create mode
100644 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-
omap2/board-3630sdp.c new file mode 100644 index 000..d3ddbd1
--- /dev/null
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -0,0 +1,188 @@
+/*
+
NAK. Could we follow the same issue with zoom2 - break the keypad into a
Separate one and use it
instead? Same for all reused zoom2 components..
[Allen] Yes, we should do that. Not only for keypad but also
For display panel and touch screen so that sdp3630, zoom3 and
Zoom2 could use the same code, without having to duplicate
Code.
We just got the same image for zoom3 boot on SDP3630 (after mach-type change)
The peripheral set is almost 90% same: same keypad, same display, same RAM,
same NAND.
I see a good amount of re-use possible here.
Here is how we could do it:
Board-zoom2.c
Split into:
Board-zoom2.c
Board-zoom-peripheral.c [reuse]
3630 zoom3 uses:
Board-zoom3.c
Board-zoom-peripheral.c [reuse]
3630 SDP uses:
Board-3630sdp.c
Board-zoom-peripheral.c [reuse]
Will give a first pass at this split up and post patches.
+
+static struct matrix_keymap_data board_map_data = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Added board-3630.c file.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
Manjunath Kondaiah
Sent: Monday, October 26, 2009 9:49 AM
To: Pais, Allen; linux-omap@vger.kernel.org
Subject: RE: [PATCH 1/2] Added board-3630.c file.
+static int __init omap_i2c_init(void)
+{
+omap_register_i2c_bus(1, 2600, sdp3630_i2c_boardinfo,
+ARRAY_SIZE(sdp3630_i2c_boardinfo));
+omap_register_i2c_bus(2, 400, NULL, 0);
+omap_register_i2c_bus(3, 400, NULL, 0);
+return 0;
+}
If sdp3630 board is using TWL5030/GAIA, then you need to reduce I2C speed.
http://patchwork.kernel.org/patch/52760/
Very valid point.
-Manjunath--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] Added board-3630.c file.
Nishanth -Original Message- From: Menon, Nishanth From: Pandita, Vikram From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pais, Sent: Monday, October 26, 2009 4:40 PM To: Pais, Allen; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/2] Added board-3630.c file. Signed-off-by: Allen Pais allen.p...@ti.com --- arch/arm/mach-omap2/board-3630sdp.c | 188 +++ 1 files changed, 188 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-3630sdp.c diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach- omap2/board-3630sdp.c new file mode 100644 index 000..d3ddbd1 --- /dev/null +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -0,0 +1,188 @@ +/* + NAK. Could we follow the same issue with zoom2 - break the keypad into a Separate one and use it instead? Same for all reused zoom2 components.. [Allen] Yes, we should do that. Not only for keypad but also For display panel and touch screen so that sdp3630, zoom3 and Zoom2 could use the same code, without having to duplicate Code. We just got the same image for zoom3 boot on SDP3630 (after mach-type change) The peripheral set is almost 90% same: same keypad, same display, same RAM, same NAND. Ok zoom2,zoom3,sdp3630 - might be good to compare. Here is a quick attempt: Peripheralzoom2zoom3sdp3630 I was making that list already. Good to see you thinking on same lines. However your list does not match with mine and I tried to confirm the changes looking at h/w. Here is the list, in the order of impact: Peripheralzoom2zoom3sdp3630 Ethernet A A B **(may not be same) NOR n/an/a B ** different Onenand n/an/a B ** diffferent HDMI A A B **(Need to verify: not there on i2c3) NAND A A A (same nand) SDRAM A A A (same sdram) KeypadA A A (same twl) CameraA A A (same sensor can be mounted: can check further) LCD Display A A A (same wvga display) Power A A A (same chip level) Audio A A A (its the same) Voltage resources?? (not sure what you mean?) LEDs A A B (LEDs are board specific, can reside in separate board file) OPPs A A A (same chip feature) others?? ... NOTE: I am just using A and B to show the types of devices. So the files registering the same type would probably be shared.. could you expand this list? I see a good amount of re-use possible here. Here is how we could do it: Board-zoom2.c Split into: Board-zoom2.c Board-zoom-peripheral.c [reuse] 3630 zoom3 uses: Board-zoom3.c Board-zoom-peripheral.c [reuse] 3630 SDP uses: Board-3630sdp.c Board-zoom-peripheral.c [reuse] Will give a first pass at this split up and post patches. Thanks.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] omap: zoom3: add zoom3 board support
-Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Friday, October 23, 2009 6:04 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 3/3] omap: zoom3: add zoom3 board support Hi, On Fri, Oct 23, 2009 at 02:23:26PM -0500, Vikram Pandita wrote: diff --git a/arch/arm/mach-omap2/board-zoom2-zoom3.c b/arch/arm/mach-omap2/board-zoom2-zoom3.c index 4ad9b94..d806dbf 100644 --- a/arch/arm/mach-omap2/board-zoom2-zoom3.c +++ b/arch/arm/mach-omap2/board-zoom2-zoom3.c @@ -281,7 +281,11 @@ static void __init omap_zoom2_map_io(void) omap2_map_common_io(); } +#ifdef CONFIG_MACH_OMAP_ZOOM3 +MACHINE_START(OMAP_ZOOM3, OMAP ZOOM3 board) +#else MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board) +#endif what happens if you want to build a kernel for both boards ? how about just adding a new MACHINE_START() declaration without ifdeferry ? Take a look at arch/arm/mach-omap2/board-n8x0.c for an example ;-) Yes I will have a look at this. Thanks for all the comments. My zoom3 board has gone bad and so could not look into this yet. Will keep posted. -- balbi -- 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] updated mach-types file
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, October 22, 2009 3:54 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] updated mach-types file * Vikram Pandita vikram.pand...@ti.com [091021 18:07]: this patch updates the auto-generated mach-types file to enable addition of 3630 boards: 1) zoom3 2) sdp3630 Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- Tony: Could you Temporarily host this patch on linux-omap tree till rmk pulls in mach-types. This would allow us to add 3630 board files How about only add the lines needed? I can put it into omap-testing branch then. Yes that is fine too. Sending that patch now. I will add two lines for sdp3630 and zoom3 only. Tony arch/arm/tools/mach-types | 54 - 1 files changed, 53 insertions(+), 1 deletions(-) diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types index 94be7bb..0160378 100644 --- a/arch/arm/tools/mach-types +++ b/arch/arm/tools/mach-types @@ -12,7 +12,7 @@ # # http://www.arm.linux.org.uk/developer/machines/?action=new # -# Last update: Fri Sep 18 21:42:00 2009 +# Last update: Wed Oct 21 15:33:08 2009 # # machine_is_xxxCONFIG_ MACH_TYPE_xxx number # @@ -2421,3 +2421,55 @@ liberty MACH_LIBERTY LIBERTY 2434 mh355 MACH_MH355 MH355 2435 pc7802 MACH_PC7802 PC7802 2436 gnet_sgcMACH_GNET_SGC GNET_SGC2437 +einstein15 MACH_EINSTEIN15 EINSTEIN15 2438 +cmpdMACH_CMPD CMPD 2439 +davinci_hase1 MACH_DAVINCI_HASE1 DAVINCI_HASE1 2440 +lgeincitephone MACH_LGEINCITEPHONE LGEINCITEPHONE 2441 +ea313x MACH_EA313X EA313X 2442 +fwbd_39064 MACH_FWBD_39064 FWBD_39064 2443 +fwbd_390128 MACH_FWBD_390128FWBD_390128 2444 +pelco_moe MACH_PELCO_MOE PELCO_MOE 2445 +minimix27 MACH_MINIMIX27 MINIMIX27 2446 +omap3_thunder MACH_OMAP3_THUNDER OMAP3_THUNDER 2447 +passioncMACH_PASSIONC PASSIONC2448 +mx27amata MACH_MX27AMATA MX27AMATA 2449 +bgat1 MACH_BGAT1 BGAT1 2450 +buzzMACH_BUZZ BUZZ 2451 +mb9g20 MACH_MB9G20 MB9G20 2452 +yushan MACH_YUSHAN YUSHAN 2453 +lizard MACH_LIZARD LIZARD 2454 +omap3polycomMACH_OMAP3POLYCOM OMAP3POLYCOM 2455 +smdkv210MACH_SMDKV210 SMDKV2102456 +bravo MACH_BRAVO BRAVO 2457 +siogentoo1 MACH_SIOGENTOO1 SIOGENTOO1 2458 +siogentoo2 MACH_SIOGENTOO2 SIOGENTOO2 2459 +sm3kMACH_SM3K SM3K 2460 +acer_tempo_f900 MACH_ACER_TEMPO_F900ACER_TEMPO_F900 2461 +sst61vc010_dev MACH_SST61VC010_DEV SST61VC010_DEV 2462 +glittertind MACH_GLITTERTINDGLITTERTIND 2463 +omap_zoom3 MACH_OMAP_ZOOM3 OMAP_ZOOM3 2464 +omap_3630sdpMACH_OMAP_3630SDP OMAP_3630SDP 2465 +cybook2440 MACH_CYBOOK2440 CYBOOK2440 2466 +torino_sMACH_TORINO_S TORINO_S2467 +havana MACH_HAVANA HAVANA 2468 +beaumont_11 MACH_BEAUMONT_11BEAUMONT_11 2469 +vanguardMACH_VANGUARD VANGUARD2470 +s5pc110_draco MACH_S5PC110_DRACO S5PC110_DRACO 2471 +cartesio_twoMACH_CARTESIO_TWO CARTESIO_TWO 2472 +aster MACH_ASTER ASTER 2473 +voguesv210 MACH_VOGUESV210 VOGUESV210 2474 +acm500x MACH_ACM500XACM500X 2475 +km9260 MACH_KM9260 KM9260 2476 +nideflexg1 MACH_NIDEFLEXG1 NIDEFLEXG1 2477 +ctera_plug_io MACH_CTERA_PLUG_IO CTERA_PLUG_IO 2478 +smartq7
RE: [PATCH]Omap3630: Add hsmmc related checks
Madhu/Tony
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Chikkature Rajashekar, Madhusudhan
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, October 22, 2009 12:44 PM
To: Madhusudhan Chikkature
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH]Omap3630: Add hsmmc related checks
* Madhusudhan Chikkature madhu...@ti.com [091022 10:38]:
From 661b13474a7af62c54f7df7a33a818c5e782cc59 Mon Sep 17 00:00:00 2001
From: Madhu madhu...@ti.com
Date: Wed, 21 Oct 2009 16:16:31 -0400
Subject: [PATCH] Omap3630: Add HSMMC related checks.
Add omap3630 conditional checks to devices.c to allow HSMMC3 addition
and
mux configuration for HSMMC1/2.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
arch/arm/mach-omap2/devices.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
omap2/devices.c
index 7d4513b..1fdfc7f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -575,7 +575,7 @@ static inline void omap2_mmc_mux(struct
omap_mmc_platform_data *mmc_controller,
}
}
- if (cpu_is_omap3430()) {
+ if (cpu_is_omap3430() || cpu_is_omap3630()) {
Not needed.
For 34xx:
cpu_is_omap3430() returns True
cpu_is_omap3630() returns False
For 3630:
cpu_is_omap3430() returns True
cpu_is_omap3630() returns True
So no need to add an orring for 3630, as 3630 is treated just like a 34xx.
if (controller_nr == 0) {
omap_cfg_reg(N28_3430_MMC1_CLK);
omap_cfg_reg(M27_3430_MMC1_CMD);
How about using cpu_is_omap34xx() here instead? It's more future proof.
Regards,
Tony
Yes. That makes sense. I will submit V2.
Regards,
Madhu
@@ -642,7 +642,8 @@ void __init omap2_init_mmc(struct
omap_mmc_platform_data
**mmc_data,
irq = INT_24XX_MMC2_IRQ;
break;
case 2:
- if (!cpu_is_omap44xx() !cpu_is_omap34xx())
+ if (!cpu_is_omap44xx() !cpu_is_omap34xx()
+ !cpu_is_omap3630())
return;
base = OMAP3_MMC3_BASE;
irq = INT_34XX_MMC3_IRQ;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 1/2] omap: add bits for future 3430/3630 ES revisions
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, October 20, 2009 6:15 PM
To: Pandita, Vikram; Woodruff, Richard; Menon, Nishanth
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v2 1/2] omap: add bits for future 3430/3630 ES revisions
Hi Vikram, Nishanth, Richard,
a few comments on this:
On Tue, 20 Oct 2009, Vikram Pandita wrote:
Add bits for future expansion of omap_chip_id type field.
This is needed to accomodate 3630ES1 chip id which is bit10
...
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7cb0556..922bf1c 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -45,7 +45,7 @@ int omap_type(void);
struct omap_chip_id {
u8 oc;
-u8 type;
+u32 type;
};
Just wanted to understand the motivation for using the u32.
Earlier in the life of these patches, two comments were mentioned: the
desire to 'futureproof' and the desire to reserve space for other
34xx-family parts.
Regarding 'futureproofing:' that's part of the reason that a separate
struct was defined for this: to prevent code that uses it from depending
on the size of the type. (Originally it was a typedef, but Linus hates
typedefs...) So it shouldn't matter how big or small the type is here, as
long as it can handle all of the bits allocated for it.
Also mentioned was the idea of reserving space for other 34xx-family
chips. I'd suggest simply renumbering the bits when and if those versions
appear. Code that uses the omap_chip_id system should always use the
macros (e.g. CHIP_IS_OMAP3430) and not encode separate bit shift values,
so renumbering should be completely safe and transparent for core code.
Module code shouldn't be using the omap_chip code, it's for core usage
only.
So, since only one bit is being added, why not continue the use of the u8?
Then when the next bits need to be added, the type can be expanded at that
point, and the bits renumbered if necessary. This should be a completely
transparent operation for code that uses it. Vikram's original patch:
http://patchwork.kernel.org/patch/54847/
My preference is to go with version one patch.
As and when required, should we add the bits.
should be fine.
Or am I missing something?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: stable kernel version
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Janosch Machowinski Sent: Monday, October 19, 2009 9:15 AM To: linux-omap@vger.kernel.org Subject: Re: stable kernel version Can you try it with the omap-debug branch, and enable the CONFIG_DEBUG_LL option in your .config? Tony This time I got some debug output, looks like it crashed somewhere in the USB Code. Deactivating the USB suspend option didn't help. Any ideas how to debug this further / fix it ? Attached you'll finde the debug output and my kernel config. Here's the problem: 3HS USB OTG: no transceiver configured 3musb_hdrc musb_hdrc: musb_init_controller failed with status -19 Depending on your board, you will have to define the transceiver for MUSB. It could be TWL4030 or NO-transceiver... Drivers - USB - (last options) *** OTG and related infrastructure *** Or do u want to disable USB to start with !! Regards Janosch -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: 3630: update is_chip variable
-Original Message-
From: Woodruff, Richard
Sent: Monday, October 19, 2009 5:18 PM
To: Pandita, Vikram; linux-omap@vger.kernel.org
Cc: Menon, Nishanth
Subject: RE: [PATCH] omap: 3630: update is_chip variable
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Monday, October 19, 2009 4:58 PM
diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-
omap/include/mach/cpu.h
index 7cb0556..05a0a33 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -454,6 +454,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define CHIP_IS_OMAP3430ES2 (1 4)
#define CHIP_IS_OMAP3430ES3_0 (1 5)
#define CHIP_IS_OMAP3430ES3_1 (1 6)
Should we add a little space for 3430 to grow? Current TRM already defines a
3.1.2. For this version
changes are transparent to software. IIRC mostly internal cell tweaks to
allow for expanded
operating range.
The CONTROL.CONTROL_IDCODE value is 0x0B6D 602F for OMAP34xx ES1.0.
The CONTROL.CONTROL_IDCODE value is 0x1B7A E02F for OMAP34xx ES2.0.
The CONTROL.CONTROL_IDCODE value is 0x2B7A E02F for OMAP34xx ES2.1.
The CONTROL.CONTROL_IDCODE value is 0x3B7A E02F for OMAP34xx ES3.0.
The CONTROL.CONTROL_IDCODE value is 0x4B7A E02F for OMAP34xx ES3.1.
The CONTROL.CONTROL_IDCODE value is 0x7B7A E02F for OMAP34xx ES3.1.2.
+#define CHIP_IS_OMAP3630ES1 (1 7)
In that case we have to be careful.
arch/arm/plat-omap/include/mach/cpu.h
struct omap_chip_id {
u8 oc;
u8 type;
};
Type is u8 and we already are using the 8th bit now (17)
So a type u8 - u16 will also be needed.
Its hard to guess how many more will come. Ideally it will be 3630 which is
growing from this point
on. It is faster/smaller/cheaper along with some bug fixes.
Regards,
Richard W.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Enric
Balletbò i Serra
Sent: Wednesday, October 14, 2009 3:32 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 1/2] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
This patch adds minimal IGEP v2 support.
Could you give some link giving details of the board please.
The IGEP v2 board is a low-cost, fan-less and industrial temperature
range single board computer that unleashes laptop-like performance and
expandability without the bulk, expense, or noise of typical desktop
machines. Its architecture shares much in common with other OMAP3 boards.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/mach-omap2/Kconfig |4 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-igep0020.c | 252 ++
3 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-igep0020.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 75b1c7e..9936510 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -85,6 +85,10 @@ config MACH_OMAP_ZOOM2
bool OMAP3 Zoom2 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_IGEP0020
+ bool IGEP0020
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6b7702f..df0bdc4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -74,6 +74,8 @@ obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o
\
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
+ mmc-twl4030.o \
obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
new file mode 100644
index 000..15175e0
--- /dev/null
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -0,0 +1,252 @@
+/*
+ * Copyright (C) 2009 Integration Software and Electronic Engineering.
+ *
+ * Modified from mach-omap2/board-generic.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include mach/common.h
+#include mach/gpmc.h
+#include mach/onenand.h
+#include mach/usb.h
+
+#include mmc-twl4030.h
+
+#define IGEP2_SMSC911X_CS 5
+#define IGEP2_SMSC911X_GPIO 176
+#define IGEP2_GPIO_LED_0_RED 26
+#define IGEP2_GPIO_LED_0_GREEN27
+#define IGEP2_GPIO_LED_1_RED 28
+
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+
+#include linux/smsc911x.h
+
+static struct resource igep2_smsc911x_resources[] = {
+ {
+ .name = smsc911x-memory,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+static struct smsc911x_platform_config igep2_smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT ,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device igep2_smsc911x_device = {
+ .name = smsc911x,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(igep2_smsc911x_resources),
+ .resource = igep2_smsc911x_resources,
+ .dev= {
+ .platform_data = igep2_smsc911x_config,
+ },
+};
+
+static inline void __init igep2_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(IGEP2_SMSC911X_CS, SZ_16M, cs_mem_base) 0) {
+ pr_warning(igep2_init_smsc911x:
+ Failed request for GPMC mem\n);
+ gpmc_cs_free(IGEP2_SMSC911X_CS);
+ return;
+ }
+
+ igep2_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ igep2_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(IGEP2_SMSC911X_GPIO, SMSC911X IRQ) == 0)
+ (gpio_direction_input(IGEP2_SMSC911X_GPIO) == 0)) {
+ gpio_export(IGEP2_SMSC911X_GPIO, 0);
+ } else {
+ pr_warning(igep2_init_smsc911x:
+ Could not obtain gpio for IRQ\n);
+
Discussion: OMAP: PM: opp table handling
Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx Thanks to all the community members for taking time for this discussion. This will aid upsteaming of 35xx/36xx/44xx in coming future. Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, Rajendra, Benoit, Vikram Problem Statement: OMAP34xx has certain opp requirements (3420/3430/3440) OMAP35xx reuses the opp's from 34xx OMAP36xx has a totally new set of opps OMAP44xx has a totally new set of opps Solution: Align on a common approach to take for the Opp table definitions. Define Separate Tables for each family as follows: Step 1: Go with this approach: 3420(65nm) : new arrays [defer for now] 3430/35xx(65nm) : new arrays ** 3440(65nm) : new arrays [defer for now] 3630(45nm) : new arrays Omap4(45nm) : new arrays * new arrays = (mpu, dsp, l3) ** Check this valid flag. Kevin can take this base on comments http://marc.info/?l=linux-omapm=125512448216071w=2 between 3430/35xx, opp's can be managed with a flag and same table re-used 35xx has requirement for 720Mhz opp Step 2: Kevin suggestion: Define accessor APIs get the OPPs Check Users of accessor API DVFS constraints sysfs debug Define accessor api's eg: index = get_opp(VDD1_OPP1); num = get_max_opp(VDD1); set_opp(index); Step 3: Paul suggestion: VSEL values in opp table should be in terms of voltage Non TWL IC's need this Step4: Paul suggestion: VDD1 VDD2 dependencies for different chips Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2 dependency OMAP4 interconnect loading can be measured from registers Multi-cores dependency Step 5: Paul suggestion: Board files adding OPPs, Modifying OPPs Eg: Pendora passing its own opp Regards, Vikram -- 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] [RFC] omap: 3630: default cpu_is_omap3630 to zero
-Original Message- From: Menon, Nishanth Sent: Monday, October 12, 2009 4:05 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero -Original Message- From: Pandita, Vikram Sent: Monday, October 12, 2009 3:51 PM make default cpu_is_omap3630() return zero Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index da9e8f8..940946e 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 +#define cpu_is_omap3630() 0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530(cpu_is_omap3430()) +# undef cpu_is_omap3630() # define cpu_is_omap3630() is_omap363x() #endif Dumb question: why is this needed? cpu_is_omap3530,15,25,03 don't seems to declare these.. If in some file, you want to distinguish between 3630 vs 3430, and the build is for 3430 only, then cpu_is_omap3630() should return 0. Eg: opp table allocation based on run time check Omap35xx may also need it for the opp in future I guess. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][PATCH] OMAP3: introduce OMAP3630
-Original Message- From: Shilimkar, Santosh diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 431fec4..af1080f 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP3430_REV_ES2_1 0x34302034 #define OMAP3430_REV_ES3_0 0x34303034 #define OMAP3430_REV_ES3_1 0x34304034 +/* NOTE: Add 36xx series below + * If additional 34xx series are added, OMAP3430_REV_ES can be + * added above the 3630 defines and series renumbered to ensure + * rev() checks to work + */ +#define OMAP3630_REV_ES1_0 0x34305034 #define OMAP443X_CLASS 0x44300034 Was expecting that this patch will add cpu_is_omap36xx() in cpu.h apart from above. Is this handled in another patch ? Idea is to re-use all 34xx code for 36xx, as per the mail thread on list, and given in reference. Hence at run time, the check could be: if (omap_rev() == OMAP3630_REV_ES1_0) x cpu_is_omap34xx() will be true for 36xx as well. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: omap3630 board definitions
Could you please review the 3630 board definitions added: Zoom3: http://www.arm.linux.org.uk/developer/machines/list.php?id=2464 SDP3630: http://www.arm.linux.org.uk/developer/machines/list.php?id=2465 Regards, Vikram -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] OMAP: I2C: Add mpu wake up latency constraint in i2c
Jokiniemi
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kalle
Jokiniemi
Sent: Thursday, September 17, 2009 11:29 AM
To: khil...@deeprootsystems.com
Cc: jhnik...@gmail.com; linux-omap@vger.kernel.org; Kalle Jokiniemi
Subject: [PATCH 1/1] OMAP: I2C: Add mpu wake up latency constraint in i2c
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
How many bytes i2c read were you doing, that failed?
What OPP are you in when you observe these failures?
VDD1:OPP?
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Added a constraint that allows MPU to wake up in few
hundred usecs, which is roughly the average i2c wait
period.
How did you arrive at the number 500us for the wakeup latency?
On Zoom2 with Synaptic touch screen controller on I2C-2,
at vdd1:opp1 we need to put a wakeup latency of 400us else we see data
corruption.
Our case is doing a write of 1 byte followed by read of 16 bytes.
The constraint function is passed as platform data from
plat-omap/i2c.c and applied only on OMAP34XX devices.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
arch/arm/plat-omap/i2c.c | 49 +++--
drivers/i2c/busses/i2c-omap.c | 17 +++---
include/linux/i2c-omap.h |9 +++
3 files changed, 59 insertions(+), 16 deletions(-)
create mode 100644 include/linux/i2c-omap.h
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 8b84839..d43d0ad 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,8 +26,10 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c.h
+#include linux/i2c-omap.h
#include mach/irqs.h
#include mach/mux.h
+#include mach/omap-pm.h
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE0xfffb3800
@@ -69,14 +71,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], i2c_pdata[0]),
#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(2, i2c_resources[1], i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], i2c_pdata[1]),
#endif
#if defined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(3, i2c_resources[2], i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], i2c_pdata[2]),
#endif
};
@@ -100,6 +102,25 @@ static const int omap34xx_pins[][2] = {};
#define OMAP_I2C_CMDLINE_SETUP(BIT(31))
+/**
+ * omap_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
+ * @dev: i2c bus device pointer
+ * @set: set or clear constraints
+ *
+ * When waiting for completion of a i2c transfer, we need to set a wake up
+ * latency constraint for the MPU. This is to ensure quick enough wakeup
+ * from idle, when transfer completes.
+ */
+#ifdef CONFIG_ARCH_OMAP34XX
+static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int set)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, set ? 500 : -1);
+}
+#else
+static inline void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int set)
+{; }
+#endif
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -180,8 +201,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] 2 || ints[1] 1 || ints[1] ports)
return 0;
- i2c_rate[ints[1] - 1] = ints[2];
- i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[ints[1] - 1].clkrate = ints[2];
+ i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
@@ -195,9 +216,11 @@ static int __init omap_register_i2c_bus_cmdline(void)
{
int i, err = 0;
- for (i = 0; i ARRAY_SIZE(i2c_rate); i++)
- if (i2c_rate[i] OMAP_I2C_CMDLINE_SETUP) {
- i2c_rate[i] = ~OMAP_I2C_CMDLINE_SETUP;
+ for (i = 0; i ARRAY_SIZE(i2c_pdata); i++)
+ if (i2c_pdata[i].clkrate OMAP_I2C_CMDLINE_SETUP) {
+ i2c_pdata[i].clkrate = ~OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[i].set_mpu_wkup_lat =
+ omap_i2c_set_wfc_mpu_wkup_lat;
err = omap_i2c_add_bus(i + 1);
if (err)
goto out;
@@ -231,9 +254,11 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- if (!i2c_rate[bus_id - 1])
- i2c_rate[bus_id - 1] = clkrate;
-
RE: [OMAP3] ALSA driver 'suspend/resume' handlers
-Original Message- From: Shilimkar, Santosh Sent: Thursday, September 24, 2009 2:24 AM To: Jarkko Nikula; hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: RE: [OMAP3] ALSA driver 'suspend/resume' handlers Hari/Jarkko, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Thursday, September 24, 2009 12:16 PM To: hari n Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [OMAP3] ALSA driver 'suspend/resume' handlers On Wed, 23 Sep 2009 00:02:01 -0500 hari n hari.z...@gmail.com wrote: It appears OMAP ALSA driver does not seem to disable and idle the SDMA channel on a 'suspend' call. The problem seems to be with the 'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in 'omap_pcm_trigger()'. ALSA audio driver uses self linking and the function 'omap_stop_dma()', only unlinks the channels, but DOES NOT disable an active channel for linked channels. Good finding, definitely I was expecting that it will stop the transfer. I worder what's the background for current omap_stop_dma implementation? I would expect that omap_stop_dma would just stop the logical channel without touching the channel linking etc. as there is own API for chained transfers and thus omap_stop_dma could be used for non-chained transfers or 'hacking' with chained transfers. This means after a return from the 'omap_stop_dma()', there can still be an active DMA transaction on the channel. Is this the intent Or a bug? I can think of situations, where in, we may want to complete the DMA transfer and then disable the channel. In such a case, we need to wait until the channel is inactive. I don't know, probably there is no driver expecting that transfer will complete after the omap_stop_dma is called or they explicitly do some PIO based FIFO flush for their devices? The problem with the current implementation is that after the audio platform trigger (suspend) is called, SOC core calls the CPU DAI trigger (suspend) and this stops the McBSP. Depending on the current DMA pointer, this may leave the DMA channel in active state, since DMA is configured for DEST HW Synchronization and and the this never gets asserted after the McBSP is stopped.. This is true. Then the question is will the operation recover after the stream is resumed and after the low-level dma and mcbsp contexts are restored and operation started again. I see two ways to resolve this issue: a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend) until the DMA channel is inactive (i.e buffer transfer complete). But, i believe 'trigger' is supposed to be an atomic operation, so we may need to wait in a worker thread. And we need to flag the McBSP stop based on DMA transfer completion. b) Explicitly disable the DMA channel in 'omap_stop_dma(). Option 'b' above may mean losing some data on resume, if we hit 'OFF' state during suspend. This may not be a big deal for audio (loss of few secs audio), but for other drivers (ex: USB data file transfer?), this may not be acceptable. 'Option 'a' means more rework in audio driver, but no changes in DAM driver and no loss of data. Yeah, trigger callback is atomic and can be called from the interrupt context as well. Option 'a' doesn't help losing of audio samples since the soc-core is first muting the codec. Current Audio driver also does not seem to support 'OFF' mode during suspend. It seems to assume that all DMA and McBSP configurations are retained in a suspend to resume transition. It's true, this has not got so much attention. I think I was expecting that low-level mcbsp and dma modules will take care of their context back-up and restore and that's enough for audio as long as audio will inform those modules with _start/_stop calls. I don't see any problem if suspend and resume callbacks are added into omap-pcm.c and omap-mcbsp.c calling e.g. omap_mcbsp_config if needed. omap_stop_dma() should be issued when we really want to stop the DMA transfer and issuing this with an outstanding transfer is a BUG in ALSA driver. Having said that, there is also bug in the DMA driver which doesn't disable the channel in linking cases. Since we use always hardware synchronized method, hardware will take care of draining the buffer so no loss of data. So option B should be ok and USB case also would work as mentioned above. USB is not a valid use case to discuss here. Mentor OTG controller has its internal DMA and so does EHCI/OHCI host controller. USB on OMAP3 _does_not_ use system DMA. Regrads Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Build break on mainline tree for 3430 SDP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Thursday, September 24, 2009 6:08 AM To: linux-omap@vger.kernel.org Subject: Build break on mainline tree for 3430 SDP Build break compiling Linus' git tree for 3430 SDP. I get this with the default SDP config. Haven't looked at the code yet to find a fix. - Anand CC arch/arm/mach-omap2/board-3430sdp.o In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: KEY redefined In file included from include/linux/i2c/twl4030.h:29, from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/input/matrix_keypad.h:10:1: warning: this is the location of the previous definition In file included from arch/arm/mach-omap2/board-3430sdp.c:41: arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: PERSISTENT_KEY redefined In file included from arch/arm/mach-omap2/board-3430sdp.c:22: include/linux/i2c/twl4030.h:356:1: warning: this is the location of the previous definition arch/arm/mach-omap2/board-3430sdp.c:94: error: unknown field 'keymap' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:94: warning: the address of 'sdp3430_keymap' will always evaluate as 'true' arch/arm/mach-omap2/board-3430sdp.c:95: error: unknown field 'keymapsize' specified in initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: excess elements in struct initializer arch/arm/mach-omap2/board-3430sdp.c:95: warning: (near initialization for 'sdp3430_kp_data') make[1]: *** [arch/arm/mach-omap2/board-3430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Linus tree has more up-to-date commit on include/linux/i2c/twl4030.h That changes the keymap interface. const struct matrix_keymap_data *keymap_data; See the highlighted line below. All boards may have to adapt to the new keymap interface. commit 9d8340687c524ce61e3c9c76758c4c81303acfc0 Author: David Brownell dbrown...@users.sourceforge.net Date: Tue Aug 25 19:24:14 2009 -0700 Input: add twl4030_keypad driver Add a driver for the keypad controller on TWL4030 family chips. These support up to an 8x8 key matrix. The TWL4030 multifunction chips are mostly used on OMAP3 (or OMAP 2430) based boards. [d...@mail.ru: switch to matrix-keypad framework, fix changing keymap from userspace] Reviewed-by: Trilok Soni soni.tri...@gmail.com Signed-off-by: David Brownell dbrown...@users.sourceforge.net Signed-off-by: Dmitry Torokhov d...@mail.ru -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Any Nokia N900 support planning?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Stefano Panella Sent: Thursday, September 24, 2009 8:23 AM To: linux-omap@vger.kernel.org Subject: Any Nokia N900 support planning? Hi guys, I would like to buy a N900 as it will became available. Is there any plan to support it with linux-omap? I thought Rx51 board supported on linux-omap is N900 !! Is there someone already working on it? In case I would like to help :) Thanks, Stefano -- Stefano Panella, Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692452 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OMAP3] ALSA driver 'suspend/resume' handlers
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of hari n
Sent: Tuesday, September 22, 2009 9:38 PM
To: linux-omap@vger.kernel.org
Subject: [OMAP3] ALSA driver 'suspend/resume' handlers
Hi,
It appears OMAP ALSA driver does not seem to disable and idle the SDMA
channel on a 'suspend' call. The problem seems to be with the
'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in
'omap_pcm_trigger()'. ALSA audio driver uses self linking and the
function 'omap_stop_dma()', only unlinks the channels, but DOES NOT
disable an active channel for linked channels.
memset(dma_chan_link_map, 0, sizeof(dma_chan_link_map));
do {
/* The loop case: we've been here already */
if (dma_chan_link_map[cur_lch])
break;
/* Mark the current channel */
dma_chan_link_map[cur_lch] = 1;
disable_lnk(cur_lch);
What if we introduce this code here?
/* Stop the Channel transmission */
l = dma_read(CCR(cur_lch));
l = ~(1 OMAP_DMA_CCR_EN);
dma_write(l, CCR(cur_lch));
next_lch = dma_chan[cur_lch].next_lch;
cur_lch = next_lch;
} while (next_lch != -1);
return; ---
}
This means after a return from the 'omap_stop_dma()', there can still
be an active DMA transaction on the channel. Is this the intent Or a
bug? I can think of situations, where in, we may want to complete the
DMA transfer and then disable the channel. In such a case, we need to
wait until the channel is inactive.
The problem with the current implementation is that after the audio
platform trigger (suspend) is called, SOC core calls the CPU DAI
trigger (suspend) and this stops the McBSP. Depending on the current
DMA pointer, this may leave the DMA channel in active state, since DMA
is configured for DEST HW Synchronization and and the this never gets
asserted after the McBSP is stopped..
If you check the chaining DMA api: omap_stop_dma_chain_transfers() has this
kind of code:
/* Stop the Channel transmission */
l = dma_read(CCR(channels[i]));
l = ~(1 7);
dma_write(l, CCR(channels[i]));
Should audio be using chaining api's?
Not sure how linking and chaining are related though.
Is self-linking a case of chaining with two same elements?
I see two ways to resolve this issue:
a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend)
until the DMA channel is inactive (i.e buffer transfer complete). But,
i believe 'trigger' is supposed to be an atomic operation, so we may
need to wait in a worker thread. And we need to flag the McBSP stop
based on DMA transfer completion.
b) Explicitly disable the DMA channel in 'omap_stop_dma().
Option 'b' above may mean losing some data on resume, if we hit 'OFF'
state during suspend. This may not be a big deal for audio (loss of
few secs audio), but for other drivers (ex: USB data file transfer?),
this may not be acceptable. 'Option 'a' means more rework in audio
driver, but no changes in DAM driver and no loss of data.
Current Audio driver also does not seem to support 'OFF' mode during
suspend. It seems to assume that all DMA and McBSP configurations are
retained in a suspend to resume transition.
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH][RFC] OMAP3630: Create architecture macros and config entries.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Cousson, Benoit Sent: Sunday, September 20, 2009 10:08 AM To: Pais, Allen; linux-omap@vger.kernel.org Cc: Raju, Veeramanikandan; Bongale, Hariprasad Subject: RE: [PATCH][RFC] OMAP3630: Create architecture macros and config entries. Hi Allen, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pais, Allen Sent: Sunday, September 20, 2009 9:47 AM To: linux-omap@vger.kernel.org; Raju, Veeramanikandan; Bongale, Hariprasad Subject: [PATCH][RFC] OMAP3630: Create architecture macros and config entries. This patch creates the architectural macros for OMAP3630. Signed-off-by: Allen Pais allen.p...@ti.com arch/arm/mach-omap2/Kconfig | 13 ++ arch/arm/plat-omap/include/mach/cpu.h | 30 +- diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 75b1c7e..618b7d5 100755 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -19,11 +19,20 @@ config ARCH_OMAP34XX bool OMAP34xx Based System depends on ARCH_OMAP3 +config ARCH_OMAP36XX +bool OMAP36xx Based System +depends on ARCH_OMAP3 + config ARCH_OMAP3430 bool OMAP3430 support depends on ARCH_OMAP3 ARCH_OMAP34XX select ARCH_OMAP_OTG +config ARCH_OMAP3630 +bool OMAP3630 support +depends on ARCH_OMAP3 ARCH_OMAP34XX ARCH_OMAP36XX +select ARCH_OMAP_OTG + comment OMAP Board Type depends on ARCH_OMAP2 || ARCH_OMAP3 || ARCH_OMAP4 @@ -73,6 +82,10 @@ config MACH_OMAP_3430SDP bool OMAP 3430 SDP board depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP_3630SDP +bool OMAP 3630 SDP board +depends on ARCH_OMAP3 ARCH_OMAP34XX ARCH_OMAP36XX + config MACH_NOKIA_N8X0 bool Nokia N800/N810 depends on ARCH_OMAP2420 diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index 7a5f9e8..73c656c 100755 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -157,10 +157,12 @@ IS_OMAP_CLASS(15xx, 0x15) IS_OMAP_CLASS(16xx, 0x16) IS_OMAP_CLASS(24xx, 0x24) IS_OMAP_CLASS(34xx, 0x34) +IS_OMAP_CLASS(36xx, 0x36) OMAP3630 is just an OMAP3430 in disguise. I don't think it deserves a new class. It should probably be handled like it was done for 1610 and 1710. Theoretically, it should be considered as a 3430 ES4.0, because it is an OMAP3430 ES3 + couple of bug fixes + couple of improvements. I think, that the proposal from Sanjeev to support 35xx (http://marc.info/?l=linux- omapm=125050987112798w=2 ) might be leveraged to handle 36xx as well. How would we handle the various ES revs for 3630? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux omap on sdp broken?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Monday, September 21, 2009 1:43 PM To: Felipe Contreras; Nishanth Menon Cc: linux-omap Subject: RE: linux omap on sdp broken? Hi Folks, Has Anyone tried booting latest kernel from tmlind master tree recently? Ref: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Starting kernel ... Uncompressing Linux . done, booting the kernel. Gets stuck there.. Same on beagleboard. Something got broken from 2.6.30 to 2.6.31. -- Felipe Contreras It seems to work okay for me on SDP, so maybe it's related to the bootloader? Felipe, Nishant, What was the last known working version for you? Maybe it's the new bootloader: the new support for SDP on upstream u-boot that Nishant Menon added last week. - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, September 17, 2009 2:48 PM
To: Pandita, Vikram
Cc: Kevin Hilman; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.arm.linux.org.uk
Subject: Re: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
On Fri, Sep 18, 2009 at 12:30:25AM +0530, Pandita, Vikram wrote:
There are review comments by Kevin [2] still getting fixed,
but a 'Russell-look' will surely help to the in-lined patch [3] .
Still not good.
I have considered all your comments for this patch and
am working on a new approach.
I should be able to post V3 patch set in a day or so,
which does not touch any of the common files.
+mov r9, r0
+
+bl get_uart_base @ get uart phy address
+adr r2, __dummy
+str r0, [r2]@save uart phy adder in memory
+ldm r2, {r13}^ @save phyadder in usermode reg
+
+bl get_uart_virt_base @ get uart virtual address
+adr r2, __dummy
+str r0, [r2]@save uart phy adder in memory
+ldm r2, {r14}^ @save phyadder in usermode reg
+
+mov r0, r9
+
bl cache_clean_flush
add pc, r5, r0 @ call relocation code
@@ -303,6 +317,9 @@ LC0:.word LC0 @ r1
LC1:.word reloc_end - reloc_start
.size LC0, . - LC0
+.type __dummy, #object
+__dummy:.word __dummy
This appears to be in the text segment, and is written to. That's not
going to work if the text segment is stored in flash (and in fact might
be dangerous in some cases.)
+
#ifdef CONFIG_ARCH_RPC
.globl params
params: ldr r0, =params_phys
diff --git a/arch/arm/boot/compressed/misc.c
b/arch/arm/boot/compressed/misc.c
index 17153b5..0758656 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -22,6 +22,15 @@ unsigned int __machine_arch_type;
#include linux/types.h/* for size_t */
#include linux/stddef.h /* for NULL */
#include asm/string.h
+#include asm/mach-types.h
+/* TODO:
+ * Include of this header is not working.
+ * Gives Error: undefined reference to `omap_rev'
+ * This header is needed for constant:
+ * ZOOM2_EXT_QUART_VIRT = 0xFB00
+ * ZOOM2_EXT_QUART_PHYS = 0x1000
+ */
+/* #include mach/io.h */
#ifdef STANDALONE_DEBUG
#define putstr printf
@@ -316,6 +325,103 @@ static void error(char *x)
#ifndef STANDALONE_DEBUG
+u32 *omap_uart_debug_ll_phy_addr;
+
+static void find_debug_ll_uart_port(unsigned int arch_type)
+{
+omap_uart_debug_ll_phy_addr = 0;
+
+/* Add logic here for new platforms, using __macine_arch_type */
+
+/* TODO: REVISIT -- Check Completeness
+ * DEFINE PHY ADDRESS for EACH BOARD HERE: omap1/2/3/4 */
+#if defined(CONFIG_ARCH_OMAP1)
+switch (arch_type) {
+case MACH_TYPE_OMAP_PALMTT:
+case MACH_TYPE_SX1:
+/* UART2 */
+omap_uart_debug_ll_phy_addr = (u32 *)0xfffb0800;
+break;
+default:
+/* UART1 */
+omap_uart_debug_ll_phy_addr = (u32 *)0xfffb;
+break;
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2)
+switch (arch_type) {
+case MACH_TYPE_NOKIA_N800:
+case MACH_TYPE_NOKIA_N810:
+case MACH_TYPE_NOKIA_N810_WIMAX:
+/* UART3 */
+omap_uart_debug_ll_phy_addr = (u32 *)0x4806e000;
+break;
+default:
+/* UART1 */
+omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+break;
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP3)
+switch (arch_type) {
+case MACH_TYPE_OMAP_LDP:
+case MACH_TYPE_OVERO:
+case MACH_TYPE_OMAP3_PANDORA:
+case MACH_TYPE_NOKIA_RX51:
+case MACH_TYPE_OMAP3_BEAGLE:
+/* UART3 */
+omap_uart_debug_ll_phy_addr = (u32 *)0x4902;
+break;
+case MACH_TYPE_OMAP_ZOOM2:
+/* EXTERNEL UART */
+omap_uart_debug_ll_phy_addr = (u32 *)0x1000;
+break;
+default:
+/* UART1 */
+omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+break;
+}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+switch (arch_type) {
+/* OMAP3: UART1 */
+case MACH_TYPE_OMAP_4430SDP:
+default:
+omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+putstr(This is an OMAP4 ...\n);
+break;
+}
+#endif
+}
+
+ulg
+get_uart_base(void)
+{
+return (ulg)omap_uart_debug_ll_phy_addr;
+}
+
+ulg
+get_uart_virt_base(void)
+{
+ulg val = 0;
+
+#ifdef CONFIG_ARCH_OMAP1
+/* omap1 */
+val = 0xfef0;
+#else
+/* omap2/3/4... */
+if (MACH_TYPE_OMAP_ZOOM2 == __machine_arch_type)
+val
RE: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Russell
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Wednesday, September 16, 2009 2:11 PM
To: Kevin Hilman
Cc: Pandita, Vikram; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.arm.linux.org.uk
Subject: Re: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
On Thu, Aug 27, 2009 at 04:29:35PM +0300, Kevin Hilman wrote:
The idea is to write to phys_io and io_pg_offset from kernel/head.S
very early based on the uart address found in compressed/misc.c
To make map_io writable, I will have to change the MACHINE_START to
remove the const. It so happens that Russell has defined
MACHINE_START to be a const.
Not sure is removing const from MACHINE_START is acceptable?
we'll find out after you post for RFC.
The answer is no, it is not acceptable - it'll break XIP kernels
because this is placed into the read-only part of the kernel image
no matter what.
The good news is that Version 2 of DEBUG_LL cleanup patch [1],
does not change the const attribute of MACHINE_START.
There are review comments by Kevin [2] still getting fixed,
but a 'Russell-look' will surely help to the in-lined patch [3] .
Regards,
Vikram
[1] git://dev.omapzoom.org/pub/scm/vikram/omap3.git runtime-debug-ll
[2] http://patchwork.kernel.org/patch/46909/
[3] Patch inlined below ---
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4515728..7fcc21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -277,6 +277,20 @@ not_relocated:mov r0, #0
blo 1b
add sp, r1, #128@ relocate the stack
+ mov r9, r0
+
+ bl get_uart_base @ get uart phy address
+ adr r2, __dummy
+ str r0, [r2]@save uart phy adder in memory
+ ldm r2, {r13}^ @save phyadder in usermode reg
+
+ bl get_uart_virt_base @ get uart virtual address
+ adr r2, __dummy
+ str r0, [r2]@save uart phy adder in memory
+ ldm r2, {r14}^ @save phyadder in usermode reg
+
+ mov r0, r9
+
bl cache_clean_flush
add pc, r5, r0 @ call relocation code
@@ -303,6 +317,9 @@ LC0: .word LC0 @ r1
LC1: .word reloc_end - reloc_start
.size LC0, . - LC0
+ .type __dummy, #object
+__dummy: .word __dummy
+
#ifdef CONFIG_ARCH_RPC
.globl params
params:ldr r0, =params_phys
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 17153b5..0758656 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -22,6 +22,15 @@ unsigned int __machine_arch_type;
#include linux/types.h /* for size_t */
#include linux/stddef.h /* for NULL */
#include asm/string.h
+#include asm/mach-types.h
+/* TODO:
+ * Include of this header is not working.
+ * Gives Error: undefined reference to `omap_rev'
+ * This header is needed for constant:
+ * ZOOM2_EXT_QUART_VIRT = 0xFB00
+ * ZOOM2_EXT_QUART_PHYS = 0x1000
+ */
+/* #include mach/io.h */
#ifdef STANDALONE_DEBUG
#define putstr printf
@@ -316,6 +325,103 @@ static void error(char *x)
#ifndef STANDALONE_DEBUG
+u32 *omap_uart_debug_ll_phy_addr;
+
+static void find_debug_ll_uart_port(unsigned int arch_type)
+{
+ omap_uart_debug_ll_phy_addr = 0;
+
+ /* Add logic here for new platforms, using __macine_arch_type */
+
+ /* TODO: REVISIT -- Check Completeness
+* DEFINE PHY ADDRESS for EACH BOARD HERE: omap1/2/3/4 */
+#if defined(CONFIG_ARCH_OMAP1)
+ switch (arch_type) {
+ case MACH_TYPE_OMAP_PALMTT:
+ case MACH_TYPE_SX1:
+ /* UART2 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0xfffb0800;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0xfffb;
+ break;
+ }
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2)
+ switch (arch_type) {
+ case MACH_TYPE_NOKIA_N800:
+ case MACH_TYPE_NOKIA_N810:
+ case MACH_TYPE_NOKIA_N810_WIMAX:
+ /* UART3 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806e000;
+ break;
+ default:
+ /* UART1 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4806a000;
+ break;
+ }
+#endif
+
+#if defined(CONFIG_ARCH_OMAP3)
+ switch (arch_type) {
+ case MACH_TYPE_OMAP_LDP:
+ case MACH_TYPE_OVERO:
+ case MACH_TYPE_OMAP3_PANDORA:
+ case MACH_TYPE_NOKIA_RX51:
+ case MACH_TYPE_OMAP3_BEAGLE:
+ /* UART3 */
+ omap_uart_debug_ll_phy_addr = (u32 *)0x4902;
+ break
RE: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag
Tony/Kevin Any feedback on this patch for removal of SYSFS_DEPRECATED flag? Reference: http://marc.info/?l=linux-omapm=125011227920673q=raw -Original Message- From: Pandita, Vikram Sent: Wednesday, August 12, 2009 4:24 PM To: linux-omap@vger.kernel.org Cc: khil...@deeprootsystems.com; Pandita, Vikram Subject: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag Remove the SYSFS_DEPRECATED flag from OMAP3 board defconfigs This is a deprecated feature no longer needed. Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- [Note: Did not change omap2/1 boards as they may still be using old filesysterms requiring this flag] arch/arm/configs/omap3_beagle_defconfig |4 ++-- arch/arm/configs/omap3_evm_defconfig |4 ++-- arch/arm/configs/omap3_pandora_defconfig |5 +++-- arch/arm/configs/omap_3430sdp_defconfig |4 ++-- arch/arm/configs/omap_4430sdp_defconfig |4 ++-- arch/arm/configs/omap_ldp_defconfig |4 ++-- arch/arm/configs/omap_zoom2_defconfig|4 ++-- arch/arm/configs/overo_defconfig |4 ++-- 8 files changed, 17 insertions(+), 16 deletions(-) diff --git a/arch/arm/configs/omap3_beagle_defconfig b/arch/arm/configs/omap3_beagle_defconfig index fe38a83..0c48a7c 100644 --- a/arch/arm/configs/omap3_beagle_defconfig +++ b/arch/arm/configs/omap3_beagle_defconfig @@ -52,8 +52,8 @@ CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set +# CONFIG_SYSFS_DEPRECATED_V2=y is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig index 28be17f..9273dcc 100644 --- a/arch/arm/configs/omap3_evm_defconfig +++ b/arch/arm/configs/omap3_evm_defconfig @@ -59,8 +59,8 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set +# CONFIG_SYSFS_DEPRECATED_V2=y is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/arm/configs/omap3_pandora_defconfig b/arch/arm/configs/omap3_pandora_defconfig index b54ad2e..de0e659 100644 --- a/arch/arm/configs/omap3_pandora_defconfig +++ b/arch/arm/configs/omap3_pandora_defconfig @@ -51,8 +51,9 @@ CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set +# CONFIG_SYSFS_DEPRECATED_V2=y is not set + # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index 8a4a7e2..5c9a686 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -61,8 +61,8 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set +# CONFIG_SYSFS_DEPRECATED_V2=y is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index 23e43ea..a464ca3 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -52,8 +52,8 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set +# CONFIG_SYSFS_DEPRECATED_V2=y is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index b9c4891..9139532 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -49,8 +49,8 @@ CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set +# CONFIG_SYSFS_DEPRECATED_V2=y is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index f1739fa..a32d126 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -59,8 +59,8 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED=y is not set
RE: [PATCH v2 1/2] OMAP: Zoom2: Add DEBUG_LL interface using Quart
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
This patch adds DEBUG_LL interface for Zoom2 board.
The low level debug uart now points corrctly to External Quad uart
controller on detachable debug board.
The Quad uart is available over GPMC chip select with physical address
0x1000.
This physical address has been mapped to virtual address 0xFB00
as per static mapping.
I see you dropped the UPF_IOREMAP flag. Why do we need a static
mapping here? The early access will be taken care of by the .phys_io
field of the mach_desc, no?
Step 1:
The first early mapping happens with phys_io. Just for debug uart access.
Step 2:
This is over-written by mapping done by omap2_map_common_io - iotable_init
I removed the flag UPF_IOREMAP for the serial 8250 driver.
If UPF_IOREMAP flag is given, then serial driver will do yet one more mapping,
which is already done by step 2.
Hence the flag is no longer needed for serial port mapping.
Kevin
This patch is adapted from a version by Erik Gilling:
http://android.git.kernel.org/?p=kernel/omap.git;
a=commit;h=e9d72efdd88877d2d6ea74a08983ace0dcc771d3
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Erik Gilling konk...@android.com
---
arch/arm/mach-omap2/board-zoom-debugboard.c |5 +++--
arch/arm/mach-omap2/board-zoom2.c | 19 +--
arch/arm/plat-omap/include/mach/io.h|6 ++
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-debugboard.c
b/arch/arm/mach-omap2/board-zoom-
debugboard.c
index 1f13e2a..70a4bba 100644
--- a/arch/arm/mach-omap2/board-zoom-debugboard.c
+++ b/arch/arm/mach-omap2/board-zoom-debugboard.c
@@ -82,9 +82,10 @@ static inline void __init zoom2_init_smsc911x(void)
static struct plat_serial8250_port serial_platform_data[] = {
{
-.mapbase= 0x1000,
+.membase= IOMEM(ZOOM2_EXT_QUART_VIRT),
+.mapbase= ZOOM2_EXT_QUART_PHYS,
.irq= OMAP_GPIO_IRQ(102),
-.flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
+.flags = UPF_BOOT_AUTOCONF|UPF_SHARE_IRQ,
.irqflags = IRQF_SHARED | IRQF_TRIGGER_RISING,
.iotype = UPIO_MEM,
.regshift = 1,
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 324009e..467e961 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -19,10 +19,12 @@
#include asm/mach-types.h
#include asm/mach/arch.h
+#include asm/mach/map.h
#include mach/common.h
#include mach/usb.h
#include mach/keypad.h
+#include mach/uncompress.h
#include mmc-twl4030.h
@@ -269,15 +271,28 @@ static void __init omap_zoom2_init(void)
usb_musb_init();
}
+static struct map_desc zoom2_io_desc[] __initdata = {
+{
+.virtual= ZOOM2_EXT_QUART_VIRT,
+.pfn= __phys_to_pfn(ZOOM2_EXT_QUART_PHYS),
+.length = ZOOM2_EXT_QUART_SIZE,
+.type = MT_DEVICE
+}
+};
+
static void __init omap_zoom2_map_io(void)
{
omap2_set_globals_343x();
+
+/* Map external quad UART virt to phy mapping */
+iotable_init(zoom2_io_desc, ARRAY_SIZE(zoom2_io_desc));
+
omap2_map_common_io();
}
MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board)
-.phys_io= 0x4800,
-.io_pg_offst= ((0xd800) 18) 0xfffc,
+.phys_io= ZOOM2_EXT_QUART_PHYS,
+.io_pg_offst= ((ZOOM2_EXT_QUART_VIRT) 18) 0xfffc,
.boot_params= 0x8100,
.map_io = omap_zoom2_map_io,
.init_irq = omap_zoom2_init_irq,
diff --git a/arch/arm/plat-omap/include/mach/io.h
b/arch/arm/plat-omap/include/mach/io.h
index 8d32df3..d67f06c 100644
--- a/arch/arm/plat-omap/include/mach/io.h
+++ b/arch/arm/plat-omap/include/mach/io.h
@@ -169,6 +169,12 @@
#define DSP_MMU_34XX_VIRT 0xe200
#define DSP_MMU_34XX_SIZE SZ_4K
+/* Map External Quad UART for Zoom2 board */
+#define ZOOM2_EXT_QUART_PHYS0x1000 /* PHY address if
fixed */
+#define ZOOM2_EXT_QUART_PHY_TO_VIRT_OFF 0xEB00
+#define ZOOM2_EXT_QUART_VIRT0xFB00
+#define ZOOM2_EXT_QUART_SIZESZ_16
+
/*
*
* Omap4 specific IO mapping
--
1.6.3.3.334.g916e1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Friday, September 11, 2009 4:09 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org; Tony Lindgren Subject: Re: [PATCH] OMAP3: defconfigs: remove SYSFS_DEPRECATED flag Pandita, Vikram vikram.pand...@ti.com writes: Tony/Kevin Any feedback on this patch for removal of SYSFS_DEPRECATED flag? Reference: http://marc.info/?l=linux-omapm=125011227920673q=raw I already ack'd: http://marc.info/?l=linux-omapm=125011754929777w=2 What is the next step? Who will be lining this patch for upstream? ... -- 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] OMAP3: Lock DPLL5 at boot
Paul -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Wednesday, September 09, 2009 10:43 AM To: Gadiyar, Anand Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; Cousson, Benoit Subject: Re: [PATCH] OMAP3: Lock DPLL5 at boot On Tue, 8 Sep 2009, Anand Gadiyar wrote: From: Rajendra Nayak rna...@ti.com OMAP3: Lock DPLL5 at boot Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and USBTLL f-clock are the only users of this DPLL, and 120MHz is is the only recommended rate for these clocks. With this patch, the 60 MHz ULPI clock is generated correctly. Tested on an OMAP3430 SDP. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com --- Incorporated all 3 comments by Paul and Benoit. Updated $SUBJECT to reflect the change. Thanks for the changes, I will queue this in a for-next branch for .33. Is this for .33 or .32? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
