This workaround shouldn't be needed when all drivers are configuring
their sysconfig registers properly and using their clocks properly.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 37 +
1 files changed, 37
From: ext Jouni Hogander [EMAIL PROTECTED]
This workaround enables autoidle for interface clocks and plls. Also
automatic control of external oscillator through sys_clkreq is
enabled.
Proper fix to this is to generalize omap3_dpll_allow_idle,
omap3_dpll_deny_idle, omap3_dpll_autoidle_read and
Initial port from omapzoom:
http://omapzoom.org/gf/project/omapbridge
For details,
http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
arch/arm/Kconfig |1 +
drivers/Makefile |1 +
2 files changed, 2 insertions(+), 0
Hello all,
I have ported the latest TI DSP BRIDGE from omapzoom to linux
omap. The purpose of this port is to get this code kept in a new
dedicated branch(ex: dspbridge) in l-o, not intended to be merged
into master or some other existing branches for now, but to provide
an efficient development
Initial port from omapzoom
http://omapzoom.org/gf/project/omapbridge
For details,
http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
drivers/dsp/bridge/gen/_gt_para.c | 107
drivers/dsp/bridge/gen/gb.c | 182
Hi,
I updated Gforge site with some more patches they are now a total of 17
uploaded, the ones that were added are applied on top of the previous ones, you
can find them at:
http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseViewrelease_id=119
I remind you to update your API and
Refreshed PM workaround set without coding style errors and 24xx build
fixed. Here are instructions how to test them:
To get Omap into retention, this patch set still depends on:
1. ARCH: OMAP: MUSB: Do not block sleep (Felipe Balbi)
Test:
1. Apply dependency patch and workaround set on top of
From: ext Jouni Hogander [EMAIL PROTECTED]
This workaround enables autoidle for interface clocks and plls. Also
automatic control of external oscillator through sys_clkreq is
enabled.
Proper fix to this is to generalize omap3_dpll_allow_idle,
omap3_dpll_deny_idle, omap3_dpll_autoidle_read and
In omap3 gpios 2-6 are in per domain. Functional clocks for these
should be disabled. This patch is needed until gpio driver disables
gpio clocks.
GPIO modules in PER domain are not able to act as a wake up source if
PER domain is in retention. PER domain sleep transition before MPU is
prevented
Hello Rajendra,
Here are some comments on the SRF patches, based on a fairly quick look.
By the way, if you haven't already, could you also run checkpatch.pl and
sparse on it?
Bugs
1. In resource_request(), the first 'if' needs braces around the entire
block:
+ /* Call the
Hi Doyu-San,
On Fri, Aug 15, 2008 at 12:16 PM, Hiroshi DOYU [EMAIL PROTECTED] wrote:
Hello all,
I have ported the latest TI DSP BRIDGE from omapzoom to linux
omap. The purpose of this port is to get this code kept in a new
dedicated branch(ex: dspbridge) in l-o, not intended to be merged
On Thu, 14 Aug 2008 10:09:52 -0500
ext Hunter, Jon [EMAIL PROTECTED] wrote:
Hi Tony, Jarkko,
Let's rather get rid of the direct mcbsp register tinkering from
drivers and use following instead:
Workaround for omap_mcbsp3_aic23_clock_init not adding new McBSP API
would be to put
Leaving interface clocks enabled causes dss pwrdm to stay in active
state when mpu is in active state. This fix puts dss to sleep state
when it is not needed.
Earlier version broke framebuffer on 24xx. This is fixed by enabling
clocks before trying to access DISPC_IRQSTATUS register.
Without wakeup enable omap doesn't wake up on dispc interrupts. This
causes problems in a case where mpu is in sleep state and dispc
interrupt fires.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
---
drivers/video/omap/dispc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff
Hmm, well it should get the value straight from the 32KiHZ sync timer.
Does that get stopped somehow during suspend?
Tony
Timer is not stopped, because immediately after suspend I get
correct value from it (called from wakeup interrupt), but
after this it is reprogrammed by something, or
On Fri, Aug 15, 2008 at 10:52 AM, Trilok Soni [EMAIL PROTECTED] wrote:
Hi Doyu-San,
On Fri, Aug 15, 2008 at 12:16 PM, Hiroshi DOYU [EMAIL PROTECTED] wrote:
Hello all,
I have ported the latest TI DSP BRIDGE from omapzoom to linux
omap. The purpose of this port is to get this code kept in a
ext Igor Stoppa [EMAIL PROTECTED] writes:
On Fri, 2008-08-15 at 12:32 +0300, ext [EMAIL PROTECTED] wrote:
This behavior of the getnstimeofday() is breaking pm-debug and the
serial console wakeup hack if we use suspend. Enabling RTC module seems
to fix some of the issues in some cases, but we
On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote:
Using them both would also generate more complexity. What would be the
benefit in using them both?
The RTC should be used during suspend since it's supposed to keep track
of time regardless of how long the duration of the suspension is.
Thank you guys for your comments,
It seems that some of the patches couldn't be sent to ML because of
the size limitation of vger.kernel.org ML. Now Tony is finding the
place to put the rest up on somewhere for review. I don't know if
reviwing these base code makes so much sense at this momenent,
-Original Message-
From: Stoppa Igor (Nokia-D/Helsinki)
Sent: 15 August, 2008 13:11
To: Hogander Jouni (Nokia-D/Tampere)
Cc: Kristo Tero (Nokia-D/Tampere); [EMAIL PROTECTED];
linux-omap@vger.kernel.org
Subject: Re: getnstimeofday() and suspend
On Fri, 2008-08-15 at 12:55 +0300,
Igor Stoppa [EMAIL PROTECTED] writes:
On Fri, 2008-08-15 at 12:55 +0300, Högander Jouni wrote:
Using them both would also generate more complexity. What would be the
benefit in using them both?
The RTC should be used during suspend since it's supposed to keep track
of time regardless of
* Hiroshi DOYU [EMAIL PROTECTED] [080815 13:34]:
Thank you guys for your comments,
It seems that some of the patches couldn't be sent to ML because of
the size limitation of vger.kernel.org ML. Now Tony is finding the
place to put the rest up on somewhere for review. I don't know if
From: ext Tony Lindgren [EMAIL PROTECTED]
Subject: Re: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux-omap
Date: Fri, 15 Aug 2008 14:21:13 +0300
* Hiroshi DOYU [EMAIL PROTECTED] [080815 13:34]:
Thank you guys for your comments,
It seems that some of the patches couldn't be
-Original Message-
From: Felipe Balbi [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2008 7:25 PM
To: Syed Mohammed, Khasim
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP3530 EVM latest sources uploaded on linux.omap.com
On Fri, Aug 15, 2008 at 06:57:45PM +0530, Syed
On Fri, Aug 15, 2008 at 07:50:07PM +0530, Syed Mohammed, Khasim wrote:
Following shows an example of how to switch to DVI output and how to set the
720P mode on DVI and how to direct output of graphics to channel0.
echo DVI /sys/class/display_control/omap_disp_control/ch0_output
echo 720P
I've been trying to use JTAG (and an Abatron BDI-2000) to debug the ALSA
driver to determine why madplay can't keep up when pulling .mp3 from an
SD card, and have not had any luck trying to halt via JTAG and set/stop
at breakpoints within the kernelthe kernel. I've found that JTAG works
for a
Hi,
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Tony Lindgren
* Hiroshi DOYU [EMAIL PROTECTED] [080815 13:34]:
Thank you guys for your comments,
It seems that some of the patches couldn't be sent to ML because of
the size limitation of vger.kernel.org ML.
Hi,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Woodruff, Richard
Sent: Friday, August 15, 2008 9:32 PM
To: Tony Lindgren; Hiroshi DOYU
Cc: linux-omap@vger.kernel.org; [EMAIL PROTECTED]; Kanigeri, Hari; Ramirez
Luna, Omar; Gupta,
Ramesh;
On Fri, 2008-08-15 at 23:04 +0530, Syed Mohammed, Khasim wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter
Barada
Sent: Friday, August 15, 2008 8:34 PM
To: linux-omap@vger.kernel.org
Subject: JTAG debugging of the kernel
I've
Peter Barada wrote:
On Fri, 2008-08-15 at 23:04 +0530, Syed Mohammed, Khasim wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter
Barada
Any suggestions on what can cause the JTAG to stop working after the
kernel starts?
I think you should
Hi Khasim,
On Fri, Aug 15, 2008 at 11:02 PM, Syed Mohammed, Khasim [EMAIL PROTECTED]
wrote:
Really all the design, maintenance and test experience of that code is
inside of TI. This has lived
for years and derivates have shipped in products. Who ever watches over it
needs to be able to
On Fri, Aug 15, 2008 at 7:01 PM, Woodruff, Richard [EMAIL PROTECTED] wrote:
Hi,
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Tony Lindgren
* Hiroshi DOYU [EMAIL PROTECTED] [080815 13:34]:
Thank you guys for your comments,
It seems that some of the patches
On Fri, Aug 15, 2008 at 10:20 PM, Felipe Contreras
[EMAIL PROTECTED] wrote:
On Fri, Aug 15, 2008 at 7:01 PM, Woodruff, Richard [EMAIL PROTECTED] wrote:
Hi,
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Tony Lindgren
* Hiroshi DOYU [EMAIL PROTECTED] [080815
Hi Felipe,
[EMAIL PROTECTED] On Behalf Of Felipe Contreras
snip
As part of contributing this code there has been a lot of reworking
of the code. Last I had heard checkpatch and sparse warnings had been
killed. There was also a lot of work in making sure there would be no
legal impact to
Hi Richard,
It sounds to me that you meant that omapzoom should be the center of
the bridge development because of TI's internal expertise of this
area. I don't have any explicit objections at all and, at least, I
will pay some respects on omapzoom since originally TI has published
this bridge as
On Fri, Aug 15, 2008 at 11:16 PM, Woodruff, Richard [EMAIL PROTECTED] wrote:
Hi Felipe,
[EMAIL PROTECTED] On Behalf Of Felipe Contreras
snip
As part of contributing this code there has been a lot of reworking
of the code. Last I had heard checkpatch and sparse warnings had been
killed.
Hi Felipe,
What TI has offered so far is code, and the comments have been on this
code. You seem to want maintainers to understand that this is code
that works today, but I don't think the code can be tested right now
since the tools (CE/Link) are not available out in the open.
Err, I
I'm not familiar with checkpatch, but I guess the purpose is
not to highlight functional issues.
However, there are functional issues, but it makes sense to
cleanup the code first: there's no point in analyzing code
that is never used.
There are about 9 errors with the latest set of
Although this is a set of two patches they are next in patch order to the ones
stored on OmapZoom:
http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseViewrelease_id=119
- omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Fixed cosmetic changes reported from checkpatch
Signed-off-by: Omar Ramirez Luna [EMAIL PROTECTED]
Acked-by: Hari Kanigeri [EMAIL PROTECTED]
---
Index: omapkernel/drivers/dsp/bridge/gen/gs.c
===
---
Adding description to bridge debug option and indenting Kconfig lines
Signed-off-by: Omar Ramirez Luna [EMAIL PROTECTED]
Acked-by: Hari Kanigeri [EMAIL PROTECTED]
---
Index: omapkernel/drivers/dsp/bridge/Kconfig
===
---
Please ignore the previous patch.
Adding description to bridge debug option and indenting Kconfig lines
Signed-off-by: Omar Ramirez Luna [EMAIL PROTECTED]
Acked-by: Hari Kanigeri [EMAIL PROTECTED]
---
Index: omapkernel/drivers/dsp/bridge/Kconfig
42 matches
Mail list logo
