* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120604 15:01]:
On Tue, 15 May 2012 14:35:08 Oleg Matcovschi wrote:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts
and disables interrupt on channel.
* Rajendra Nayak rna...@ti.com [120601 05:13]:
The data is autogenerated using the OMAP autogeneration scripts (python
scripts). Thanks to Mike Turquette for the initial efforts in updating
the script which was later updated by me.
All data is added into a new cclock44xx_data.c file, a later
All,
I'm **really** hoping someone out there can help us with this.
My team has been working with the AM3517 for several months now, and we seem to
be plagued every so often by what we have termed the slab bug. In short, it
looks something like the pasted bootlog below. This has been an
* Tony Lindgren t...@atomide.com [120604 23:47]:
* Rajendra Nayak rna...@ti.com [120601 05:13]:
The data is autogenerated using the OMAP autogeneration scripts (python
scripts). Thanks to Mike Turquette for the initial efforts in updating
the script which was later updated by me.
All data
* CF Adad cfa...@rocketmail.com [120604 23:47]:
All,
I'm **really** hoping someone out there can help us with this.
My team has been working with the AM3517 for several months now, and we seem
to be plagued every so often by what we have termed the slab bug. In
short, it looks
* Mohammed, Afzal af...@ti.com [120525 03:20]:
Hi Tony,
On Fri, May 25, 2012 at 12:56:59, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120523 17:55]:
On Tue, 22 May 2012, Tony Lindgren wrote:
Unfortunately for many of the older boards these values will probably
remain
* Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]:
On Thu, May 10, 2012 at 14:23:01, Hiremath, Vaibhav wrote:
From: Afzal Mohammed af...@ti.com
Add support for low level debugging on AM335X EVM (AM33XX family).
Currently only support for UART1 console, which is used on AM335X EVM
is
* Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]:
On Fri, May 11, 2012 at 00:38:49, Hiremath, Vaibhav wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X machine init.
During last merge window, two separate patches supporting am33xx
machine init had
On Tue, Jun 05, 2012 at 13:23:44, Tony Lindgren wrote:
* Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]:
On Fri, May 11, 2012 at 00:38:49, Hiremath, Vaibhav wrote:
From: Afzal Mohammed af...@ti.com
This patch adds minimal support for AM335X machine init.
During last merge
On Tue, Jun 05, 2012 at 13:29:52, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120529 03:01]:
This patch adds complete clockctree and hwmod data for the
AM33XX family of devices.
This patch-series is cleaned up further from Paul's cleanup
activity on AM33xx clocktree, where
* Hiremath, Vaibhav hvaib...@ti.com [120605 01:27]:
On Tue, Jun 05, 2012 at 13:29:52, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120529 03:01]:
This patch adds complete clockctree and hwmod data for the
AM33XX family of devices.
This patch-series is cleaned up further
On Tue, Jun 05, 2012 at 13:29:52, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [120529 03:01]:
This patch adds complete clockctree and hwmod data for the
AM33XX family of devices.
This patch-series is cleaned up further from Paul's cleanup
activity on AM33xx clocktree, where
Most part of this patch series was obtained by splitting
[RFC PATCH 2/3] usb: musb: omap glue: use omap-usb2 as the phy driver.
TO DO:
* dt adaptation of musb omap glue, twl4030, twl6030.
* Use control module driver API to write to control module registers
(mailbox and power control of phy)
*
Commit 712d8e fixed pm_runtime calls while atomic by using a work queue.
While the issue and the work queue implementation is specific to omap
(omap2430.c), the work_struct is defined as a member of struct musb
(musb_core.h). Hence moved the work_struct from musb_core to omap
glue.
Signed-off-by:
used devres API while allocating memory resource in twl4030 and twl6030
so that these resources are released automatically on driver detach.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c | 15 +++
drivers/usb/otg/twl6030-usb.c | 16
used devres API while allocating memory resource and while getting
usb phy so that these resources are released automatically on driver
detach.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 19 +++
1 files changed, 7 insertions(+), 12
Moved otg specific state(OTG_STATE_B_IDLE, OTG_STATE_A_IDLE) initializations
from twl to glue. These initializations are removed from twl4030 and
twl6030 and moved to the mailbox API defined in glue.
This is part of the cleanup in preparation to make use of usb2 phy
driver.
Signed-off-by: Kishon
The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID events,
is replaced by a direct call to omap musb blue.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 90 ++---
drivers/usb/otg/twl4030-usb.c | 42
On Tue, Jun 5, 2012 at 12:22 AM, Stephen Boyd sb...@codeaurora.org wrote:
Option 1 is nicer and it also follows the model other subsystems have
put forth such as the input subsystem.
Sounds good, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
On Tue, Jun 5, 2012 at 12:23 AM, Stephen Boyd sb...@codeaurora.org wrote:
I thought we wanted to allow both calls to proceed in parallel? If we
don't care about that
Yeah, I don't think we do.
then announcing it once the firmware is found the first time sounds correct.
I agree. Though this
* Kevin Hilman khil...@ti.com [120523 16:15]:
Govindraj.R govindraj.r...@ti.com writes:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was
* Govindraj.R govindraj.r...@ti.com [120511 02:45]:
From: Govindraj.R govindraj.r...@ti.com
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
#else
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata) {}
+static void __init
Hello.
On 05-06-2012 13:38, Kishon Vijay Abraham I wrote:
Commit 712d8e
Please also specify that commit's summary in parens.
fixed pm_runtime calls while atomic by using a work queue.
While the issue and the work queue implementation is specific to omap
(omap2430.c), the work_struct is
Hi Tomi,
On Tue, May 22, 2012 at 12:09 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi Florian,
Here are the OMAP DSS changes for 3.5.
I really tried this time to send the pull request early, but here I am
again, sending it when the merge window has already opened... A few
late-found
Hi Jean,
On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote:
Hi Tomi,
I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
I have an issue with suspend/resume on OMAP3 Beagleboard, where the
system hangs at resume time.
Here below is a log with the option
Hi Tomi,
On Tue, Jun 5, 2012 at 2:33 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi Jean,
On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote:
Hi Tomi,
I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
I have an issue with suspend/resume on OMAP3 Beagleboard,
Hi Rajendra,
On 06/04/2012 11:58 PM, Rajendra Nayak wrote:
Hi Jon,
On 06/04/2012 09:16 AM, Rajendra Nayak wrote:
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X(1 0)
+#define RATE_IN_243X(1 1)
+#define RATE_IN_3430ES1(1 2)/* 3430ES1
Hi Will,
On 06/04/2012 04:44 PM, Jon Hunter wrote:
[...]
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index 2334bf8..8ffbb09 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -13,6 +13,8 @@
#include linux/err.h
#include linux/kernel.h
#include
Hi,
On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]:
Looks like the DSS stuff has broken OMAP builds again during this
merge window:
drivers/video/omap2/dss/core.c:197: error: static declaration of
Considering that we have the RFC patches available for common
clk fwk, we should probably avoid the extra churn and have this
use the common clk fwk instead. Of course that is assuming the
common clk fwk patches will be mergeable soonish.
Tony,
I am not quite sure how much time it will take
Hi Florian,
Here are 5 small fixes for omapdss. The most important is the fix
registration... patch, without which omapdss crashes when
suspending/resuming. The compilation bug (fix build...) is also rather
annoying for those users not interested in debug outputs. The rest are
quite minor small
Hi Xiao,
On 06/04/2012 11:15 PM, Xiao Jiang wrote:
Ricardo Neri wrote:
Hi Xiao, Tomi, Jarkko,
On 05/30/2012 11:27 PM, Xiao Jiang wrote:
Ricardo Neri wrote:
+Tomi
Hi Xiao,
On 05/30/2012 02:14 AM, Xiao Jiang wrote:
Hello,
After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got
Hi Tony,
Thanks so much for the response! All good suggestions.
#1.) Missing retention/off idle workarounds
I'm highly suspect of this one. I've seen a lot of patches addressing things
in this category come out recently for the Sitara series, and we've tried to
incorporate everything we've
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct
For OMAP1 devices, it is necessary to perform a manual reset of the timer.
Currently, this is indicating by setting the needs_manual_reset variable in
the platform data. Instead of using an extra variable to indicate this add a new
timer capabilities flag to indicate this and remove the
OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the
omap_dm_timer_request() function fails to allocate a dmtimer because the call
to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply
because the clock data for the OMAP1 dmtimers is not present.
During early boot, one or two dmtimers are reserved by the kernel as system
timers (for clocksource and clockevents). These timers are marked as reserved
and the dmtimer driver is notified which timers have been reserved via the
platform data information.
For OMAP2+ devices the timers reserved
The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this flag is set the
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
OMAP1 uses an architecture specific function for setting the dmtimer clock
source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
device should also use the clock framework and hence we should not any
architecture specific functions.
For now move the OMAP2+ function for
For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform function, we can
The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a con-id string to search for the appropriate functional clock.
Currently, we define a clock alias for each functional clock source each timer
The OMAP2+ timer code has a definition for the maximum number of timers that
OMAP2+ devices have. This defintion is not used anywhere in the code and
appears to be left over. Furthermore the definition is not accurate for OMAP4
devices that only have 11 timers available because the 12th timer is
In the plat/dmtimer.h there is a structure named clk declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by: Jon Hunter
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is
Keshava, Felipe,
ping. This problem is still preventing CORE retention in mainline.
On 05/24/2012 03:13 PM, Kevin Hilman wrote:
Kevin Hilmankhil...@ti.com writes:
Munegowda, Keshavakeshava_mgo...@ti.com writes:
On Thu, May 24, 2012 at 5:55 AM, Kevin Hilmankhil...@ti.com wrote:
On
* Oleg Matcovschi oleg.matcovs...@ti.com [120515 14:40]:
Use omap_disable_channel_irq() function instead of directly accessing CICR.
The omap_disable_chanel_irq() function clears pending interrupts and
disables interrupt on channel.
Functions omap2_enable_irq_lch()/omap2_disable_irq_lch()
I pulled Linus' tree at 7am UTC, and reran the builds after updating
the build tree with that (plus my pending devel stuff). The resulting
randconfig spat out this:
arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/mach-omap2/dsp.c:58: error: implicit declaration
Hello Benoît
On Tue, 29 May 2012, Cousson, Benoit wrote:
On 5/25/2012 11:56 PM, Paul Walmsley wrote:
This patch is effectively a workaround for a hardware oversight. A
better hardware approach would have been to implement a smart-idle
target idle mode for this IP block. The smart-idle
Hello Benoît
On Tue, 5 Jun 2012, Paul Walmsley wrote:
On Tue, 29 May 2012, Cousson, Benoit wrote:
So in fact, I'm wondering if a new flag is needed. We can potentially
apply that if idlemodes == (SIDLE_FORCE | SIDLE_NO).
We need to check which IP will have that to ensure that does
On Tue, Jun 05, 2012 at 11:02:14PM +0100, Russell King - ARM Linux wrote:
arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: implicit declaration
of function 'OMAP_GPIO_IRQ'
arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: initializer element
is not constant
Hi Ricardo
Do you see that the playback finishes (even though you don't hear
anything)? Also, what version of Pandaboard are you using? Is it
Pandaboard or PandaboardES? Have you tried on different TVs?
Yes, it can finish normally, and board's version is OMAP4430 ES2.2.
After changed to
On 06/05/12 03:57, Ohad Ben-Cohen wrote:
What about using a separate file for the resource table ?
That should be very easy to support, and may make life easier for you
in the long term.
Resource tables tend to change in time, and hard coding it in the
kernel doesn't sound ideal (both in
On Wed, Jun 6, 2012 at 6:25 AM, Stephen Boyd sb...@codeaurora.org wrote:
What if I don't want to boot the device at kernel start-up? Do I have to
make it a module then?
Currently, yeah.
But we can change stuff if needed.
We took that design decision because it was simple and we didn't have
55 matches
Mail list logo
