On Thu, Sep 9, 2010 at 6:56 PM, Gary Thomas g...@mlbassoc.com wrote:
I'm trying to use McBSP4 with an external CODEC which is a
slave device (i.e. the OMAP generates the Frame Sync pulses)
In this mode, the BSP is purely the master of these signals.
What can it possibly mean to get Frame Sync
On 09/13/2010 03:07 AM, Grazvydas Ignotas wrote:
On Thu, Sep 9, 2010 at 6:56 PM, Gary Thomasg...@mlbassoc.com wrote:
I'm trying to use McBSP4 with an external CODEC which is a
slave device (i.e. the OMAP generates the Frame Sync pulses)
In this mode, the BSP is purely the master of these
Hello.
tom.leim...@gmail.com wrote:
From: Ming Lei tom.leim...@gmail.com
Complete the current request only if the data transfer is over.
Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand
Hi all,
I'm working on a zoom2 dev board (omap34x-II MDP). There is my actual config :
I've built kernel 2.6.35 from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
and then applied the following patchs :
[PATCH 1/2 V7] OMAP: ZOOM2/3SDP3630: Add display board file for
Hi,
On Mon, Sep 13, 2010 at 07:43:27AM -0500, Yanick Saugy wrote:
Finally I've enabled DSS and lcd NEC_NL8048HL11 in kernel config file.
At this time the kernel boots well, and my LCD backlight turns on but I
can't see TUX while booting, and I can't draw anything after logging
to see tux you
Bill,
I was looking at your PWM patch set[1] and it seems this has been pending for a
long time (since February). Do you know if this is any closer to being
accepted, ie. have you done any additional work or has it been accepted to some
maintainer's tree?
There was a Google Summer of Code
Hi Caglar,
[...]
Unfortunately emac driver is not stable after this series. I face lock-ups
time to time, followed by attached kernel trace.
Could you elaborate on your test scenario so that I can try and
reproduce the problem at my end? Also, did you have the contents of my
commit stack in
2010/9/13 Sergei Shtylyov sshtyl...@mvista.com:
But why not modify the conditional above all that code, just excluding
'is_dma' from it. This conditional already includes (request-actual ==
request-length) check. Please recast this patch.
The two condition is OR relation, not and, so we
Thomas Petazzoni thomas.petazz...@free-electrons.com writes:
On Fri, 10 Sep 2010 14:54:23 -0700
Kevin Hilman khil...@deeprootsystems.com wrote:
It's the CPUfreq driver that's failing to suspend.
Ok.
Yes, CPUfreq is not supported in l-o master or pm-core (only in the
full pm branch.) If
Varadarajan, Charulatha ch...@ti.com writes:
This patch adds pm_bus.o for OMAP2 architecture which is required
while using PM runtime APIs on OMAP2.
This patch series is created on origin/pm-core and is
tested on 2430 SDP board (with watchdog and GPIO patches
using PM runtime APIs. These
[snip]
[Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3,
4430
ES2.0 SDP, Blaze and Panda and all booting fine.
And omap_4430sdp_defconfig also ok omap4.
Which Panda version are you using during your tests? I tried
omap_4430sdp_defconfig using omap4-for-tony
Series of patches to port watchdog module to use hwmod
and omap_device apis for OMAP2plus chips. For this hwmod data
structures are poulated. This patch series also implements watchdog
module to use PM runtime APIs.
This patch series is created on origin/pm-core and are
tested on OMAP2430,
Add watchdog timer hwmod data for OMAP3 chip
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 61
arch/arm/mach-omap2/prcm-common.h |4 ++
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git
Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings instead of using
clock FW APIs.
Signed-off-by: Charulatha V ch...@ti.com
---
drivers/watchdog/omap_wdt.c | 57 --
1 files changed,
Hi Caglar,
[...]
Assuming that the DMA got stuck at some point leading up to the transmit
timeout, any ideas as to why a host error was not thrown? To help
debug, I'll post out a set of patches that dump out the MAC (and DMA)
registers on timeout. That should give us some visibility into
I have zero knowledge of DSS, but shouldn't the kernel be able to
suspend properly even if the DSS driver is disabled ? But maybe it's
too complicated to have the DSS init sequence required to allow the
system to hit RET outside the DSS driver. Thoughts ?
I'm not sure if it's supposed to work
Hello.
I wrote:
But why not modify the conditional above all that code, just excluding
'is_dma' from it. This conditional already includes (request-actual ==
request-length) check. Please recast this patch.
The two condition is OR relation, not and, so we can't exclude
'is_dma' simply.
On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On ES2.0 the L2 cache init parameter ineeds to be changed to take
care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0
This patch fixes the init parameter to update the same using
dynamic cpu
-Original Message-
From: Gadiyar, Anand
Sent: Monday, September 13, 2010 9:58 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; t...@atomide.com;
khil...@deeprootsystems.com
Subject: Re: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0
On Thu, Sep 9, 2010 at 4:53 PM,
On Monday 13 September 2010 05:09:15 pm Cyril Chemparathy wrote:
Hi Caglar,
[...]
Unfortunately emac driver is not stable after this series. I face
lock-ups time to time, followed by attached kernel trace.
Could you elaborate on your test scenario so that I can try and
reproduce the
With this patch, phy_id can be one of the following:
1) NULL : use the first phy on the bus,
2) : force to 100/full, no mdio control
3) bus:addr : use the specified bus and phy
The ability to force 100/full is necessary on some platforms (e.g. da830 evm),
The cpdma/mdio refactoring incorrectly defaulted to using the first phy
detected on the platform. Although auto detection works on most sane
platforms, it can prove to be problematic on some.
For example, the da830/omap-l137 evm has an on-board switch that always
connects 100/full.
This patch adds the following fixes to the emac receive handler:
1. WARN_ON during interface shutdown.
Although harmless, these complaints were quite disconcerting. With this
patch, the receive handler explicitly checks for the shutdown condition, in
which case is bails quietly.
2.
This series consists of fixes for issues found during broader testing of the
davinci cpdma/mdio separation series.
The fixes included here are:
1. Ability to force 100/full rather than auto-detect phy. This is necessary
for the external switch on the da830 evm platform
2. Fix
When chaining descriptors to the end of a cpdma queue, there is a chance that
the cpdma engine has already traversed the last descriptor and signalled an
end-of-queue. The original cpdma code detected this condition and requeued
descriptors on submission.
With this patch, an early end-of-queue
This patch adds register dump routines at both controller and channel levels.
These are intended to be used in higher level driver debug dumps, e.g.
emac_dump_regs().
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by:
This patch separates out the controller reset logic, and makes this available
via mii_bus-reset.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar Akyuz caglarak...@gmail.com
---
drivers/net/davinci_mdio.c |
This patch hooks up the emac_dump_regs() function to use cpdma dump routines.
Further, we dump registers on transmit timeout, to make such timeouts
debuggable.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Signed-off-by: Caglar
On certain devices (e.g. da8xx), the hardware design ties emac soft-reset to
the mdio module. In these cases, when the emac device is opened, an in-flight
mdio transaction could fail by returning the controller to idle state. This
patch detects this condition and works around it by retrying the
This patch replaces the hardcoded scan delay with a calculated delay that
adjusts to clock rates. This delay is calculated on the basis of a worst case
bus transaction time, with generous built-in margins of error.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Michael Williamson
On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
[Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3,
4430
ES2.0 SDP, Blaze and Panda and all booting fine.
And omap_4430sdp_defconfig also ok omap4.
Which Panda version are you using during your
Thomas Petazzoni thomas.petazz...@free-electrons.com writes:
Hello,
On Mon, 13 Sep 2010 07:56:54 -0700
Kevin Hilman khil...@deeprootsystems.com wrote:
Looks like DSS has not been initialized, so is not hitting RET.
Do you have the DSS driver enabled and built-in? Without this (and
Dear all,
I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).
The issue is describing as below mentioned way,
1). The Device is getting DSP MMU Fault when playing MP4 video clip.
The system is not hitting off mode in the below scenario,
2). System boot
From: Kevin Hilman khil...@ti.com
This series is a cleanup/reorg/streamline of the core idle path.
The goal is to remove all device-specific idle management out of the
core idle path into device-specific code.
This series starts with some of the device-specific hacks currently in
the idle
From: Kevin Hilman khil...@ti.com
In an effort to simplify the core idle path, move any device-specific
special case handling from the core PM idle path into the CPUidle
pre-idle checking path.
This keeps the core, interrupts-disabled idle path streamlined and
independent of any device-specific
From: Kevin Hilman khil...@ti.com
Currently, we wait until late in the idle path where interrupts are
disabled to do runtime-PM-like management for certain special-case
devices like GPIO.
As a prerequiste to moving GPIO to the new runtime PM framework, move
this runtime-PM-like code out of the
-Original Message-
From: Ricardo Salveti [mailto:rsalv...@rsalveti.net]
Sent: Tuesday, September 14, 2010 12:22 AM
To: Ghorai, Sukumar
Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org;
t...@atomide.com; Bryan Wu
Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for
Unnecessary cast from void* in assignment.
Signed-off-by: matt mooney m...@muteddisk.com
---
arch/arm/mach-omap2/mailbox.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 42dbfa4..40ddeca 100644
38 matches
Mail list logo
