On Mon, 29 Jun 2009 00:08:59 +0200
Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote:
AFAIK, both CSSA_L and CDSA_L DMA registers are static. Loaded by CPU
with 16 LSB of initial source and destination port addresses
respectively, they are never updated by the DMA engine itself. That's
why they
On Monday 29 June 2009 01:08:59 ext Janusz Krzysztofik wrote:
AFAIK, both CSSA_L and CDSA_L DMA registers are static. Loaded by CPU with
16 LSB of initial source and destination port addresses respectively, they
are never updated by the DMA engine itself. That's why they can't be used
for
On Mon, 29 Jun 2009 09:37:58 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Hmmm, I had taken a look at the 2.4.21 kernel sources, which I have
laying around in my disk from an old project which used OMAP1510. The
OSS audio code does use the CPC register for determining the DMA
progress
I think we also need extra patch for fixing stability issue.
Sometimes after back from retention/off mode, OMAP3430 I2C controller
stops working even all register settings are restored.
OMAP3430 TRM says: During active mode (I2Ci.I2C_CON[15] I2C_EN bit is
set to 1), make no changes to the
Warn if OTG is selected in Kconfig but not initialized by platform code.
Add checks to prevent NULL pointer exception in case the
OTG transceiver has not been initialized. i.e. musb-xceiv == NULL
Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com
---
drivers/usb/musb/musb_core.c |7
On Wed, Jun 24, 2009 at 08:57:56AM +0100, Russell King - ARM Linux wrote:
On Wed, Jun 24, 2009 at 01:16:52PM +0530, Shilimkar, Santosh wrote:
After digging a bit, the proposed twl_irq change would need some major
changes.
1. All the T2(TWL)drivers ( rtc, madc, bci, gpio, keypad, usb,
Vikram,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Pandita, Vikram
Sent: Friday, June 26, 2009 11:18 AM
To: linux-omap@vger.kernel.org
Cc: Pandita, Vikram
Subject: [PATCH] OMAP2/3: DMA errata correction
This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses
are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures
are filled at runtime to have McSPI support on OMAP4.
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Acked-by: Kevin Hilman
This errata is valid for:
OMAP2420 Errata 1.85 Impacts all 2420 ES rev
OMAP2430 Errata 1.10 Impacts only ES1.0
Description: DMA may hang when several channels are used in parallel
OMAP3430: Not impacted, so remove the errata fix for omap3
Fixed issue reported on cpu_is_omap24xx check reported by
On Monday 29 June 2009 08:37:58 Peter Ujfalusi wrote:
On Monday 29 June 2009 01:08:59 ext Janusz Krzysztofik wrote:
For capture, reading CPC, that follows destination port address progress,
just works fine (for both old and new driver). For playback, similar
hardware functionality seems to
Hello,
Koskinen Aaro (Nokia-D/Helsinki) wrote:
I'm afraid this patch needs more work. The optimized restoration of
chconf can cause occasionally errors with off mode if multiple chip
selects are in use. In practice it is needed to restore all CHxCONF
registers, not just the one by a specific
Hi,
I am trying to get the latest IRQ registers from a timer or a work queue but I
am running into problems:
- get_irq_regs() returns NULL in some cases, so it is unsuable and even causes
crash when trying to get the registers values from the returned ptr
- I never get user space registers,
On Thu, Jun 25, 2009 at 02:48:38PM +0200, Janusz Krzysztofik wrote:
During my previous, gpio-keys based attempt, I submitted a patch
that added new SW_HANDSET_PICK_UP event definition to
include/linux/input.h. Even if not accepted because of no
Something like hook switch would be a more
Hi,
The setup times to be programmed in the PRM module on OMAP (for clksetup,
voltsetup etc)
are board specific. They depend heavily on the PMIC used and even on different
boards
with the same PMIC, they vary based on the sleep/wake sequence used, system
clock speed et al.
The CPUidle
The setup times to be programmed in the PRM module on OMAP
(for clksetup, voltsetup etc) are board specific.
They depend heavily on the PMIC used and even on different boards
with the same PMIC, they vary based on the sleep/wake
sequence used, system clock speed et al.
This patch makes it
The CPUidle C state latencies and thresholds are dependent
on various board specific details.
Hence this patch makes it possible to configure these values from the
respective board files.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 22 ++-
On Mon, Jun 29, 2009 at 04:31:18PM +0200, Jean Pihet wrote:
I am trying to get the latest IRQ registers from a timer or a work queue
but I am running into problems:
- get_irq_regs() returns NULL in some cases,
It will always return NULL outside of IRQ context - and only returns valid
pointers
And here it is - I've only build-tested it so far.
drivers/mfd/twl4030-irq.c | 55
++--
1 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index bae61b2..4bb1ea7 100644
---
On Monday 29 June 2009 17:19:31 Russell King - ARM Linux wrote:
On Mon, Jun 29, 2009 at 04:31:18PM +0200, Jean Pihet wrote:
I am trying to get the latest IRQ registers from a timer or a work queue
but I am running into problems:
- get_irq_regs() returns NULL in some cases,
It will always
On Mon, Jun 29, 2009 at 09:04:53PM +0530, Shilimkar, Santosh wrote:
Russell,
Just a question here.
In the enable_irq(irq) and disable_irq(irq) call tree, internally there are
calls to
the interrupt controller chip.
In disable_irq() path:
desc-chip-disable(irq);
And in
On Mon, Jun 29, 2009 at 05:35:37PM +0200, Jean Pihet wrote:
On Monday 29 June 2009 17:19:31 Russell King - ARM Linux wrote:
It's one of these things that nests itself - when you have several IRQs
being processed on one CPU, there are several register contexts saved,
and get_irq_regs()
On Monday 29 June 2009 18:07:44 Russell King - ARM Linux wrote:
On Mon, Jun 29, 2009 at 05:35:37PM +0200, Jean Pihet wrote:
On Monday 29 June 2009 17:19:31 Russell King - ARM Linux wrote:
It's one of these things that nests itself - when you have several IRQs
being processed on one CPU,
On Monday 29 June 2009 16:32:15 Mark Brown wrote:
On Thu, Jun 25, 2009 at 02:48:38PM +0200, Janusz Krzysztofik wrote:
During my previous, gpio-keys based attempt, I submitted a patch
that added new SW_HANDSET_PICK_UP event definition to
include/linux/input.h. Even if not accepted because of
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
Hi,
I am trying to get the latest IRQ registers from a timer or a work queue
but I am running into problems:
- get_irq_regs() returns NULL in some cases, so it is unsuable and even
causes crash when trying to get the registers values from
Hi Siarhei Siamashka,
On Monday 29 June 2009 18:36:57 Siarhei Siamashka wrote:
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
Hi,
I am trying to get the latest IRQ registers from a timer or a work queue
but I am running into problems:
- get_irq_regs() returns NULL in some cases,
HU TAO-TGHK48 ta...@motorola.com writes:
I think we also need extra patch for fixing stability issue.
Sometimes after back from retention/off mode, OMAP3430 I2C controller
stops working even all register settings are restored.
OMAP3430 TRM says: During active mode (I2Ci.I2C_CON[15] I2C_EN
On Mon, Jun 29, 2009 at 07:36:57PM +0300, Siarhei Siamashka wrote:
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
I am trying to get the latest IRQ registers from a timer or a work queue
but I am running into problems:
- get_irq_regs() returns NULL in some cases, so it is unsuable
On Mon, Jun 29, 2009 at 06:58:41PM +0200, Jean Pihet wrote:
I am trying to get a different approach, starting from the errata
description. The idea is to avoid the counters from overflowing,
which could cause a PMNC unit reset or lock-up (or both).
But this can't work.
Oprofile essentially
On Monday 29 June 2009 19:37:57 Russell King - ARM Linux wrote:
On Mon, Jun 29, 2009 at 07:36:57PM +0300, Siarhei Siamashka wrote:
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
I am trying to get the latest IRQ registers from a timer or a work
queue but I am running into problems:
On Mon, Jun 29, 2009 at 10:51:09AM -0700, Kevin Hilman wrote:
And if you look at the OMAP's MPU irq_chip implementation, these are
not populated either. We rely on the default lazy enable via unmask
and the lazy disable.
There's no lazy enable - it's immediate. There's only lazy disable.
--
On Monday 29 June 2009 19:46:33 Russell King - ARM Linux wrote:
On Mon, Jun 29, 2009 at 06:58:41PM +0200, Jean Pihet wrote:
I am trying to get a different approach, starting from the errata
description. The idea is to avoid the counters from overflowing,
which could cause a PMNC unit reset
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Mon, Jun 29, 2009 at 10:51:09AM -0700, Kevin Hilman wrote:
And if you look at the OMAP's MPU irq_chip implementation, these are
not populated either. We rely on the default lazy enable via unmask
and the lazy disable.
There's no
Rafiuddin
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Syed,
Rafiuddin
Sent: Monday, June 29, 2009 7:55 AM
To: spi-devel-gene...@lists.sourceforge.net; dbrown...@users.sourceforge.net
Cc: linux-omap@vger.kernel.org
On Monday 29 June 2009 19:54:23 Siarhei Siamashka wrote:
On Monday 29 June 2009 19:58:41 ext Jean Pihet wrote:
Hi Siarhei Siamashka,
On Monday 29 June 2009 18:36:57 Siarhei Siamashka wrote:
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
Hi,
I am trying to get the
On Monday 29 June 2009 20:37:57 ext Russell King - ARM Linux wrote:
On Mon, Jun 29, 2009 at 07:36:57PM +0300, Siarhei Siamashka wrote:
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
I am trying to get the latest IRQ registers from a timer or a work
queue but I am running into
On Monday 29 June 2009 20:38:59 Siarhei Siamashka wrote:
On Monday 29 June 2009 20:37:57 ext Russell King - ARM Linux wrote:
On Mon, Jun 29, 2009 at 07:36:57PM +0300, Siarhei Siamashka wrote:
On Monday 29 June 2009 17:31:18 ext Jean Pihet wrote:
I am trying to get the latest IRQ
Nayak, Rajendra rna...@ti.com writes:
-Original Message-
From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
Sent: Wednesday, June 17, 2009 6:18 PM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
Subject: RE: [PATCH 01/04] OMAP3: PM: Disable
Hi Kevin,
Shouldn't you do a read-modify-write of I2C_CON_REG here? Otherwise,
you're loosing any of the other settings in I2C_CON_REG.
Not being an expert in the I2C hardware, I'm not sure if it matters,
but this doesn't seem quite right due to possible side effects.
This is a good
On Monday 29 June 2009 21:49:59 ext Jean Pihet wrote:
[...]
We just need to use not a periodic timer, but kind of a watchdog (this
can be implemented with OMAP GPTIMER).
As long as PMU interrupts are coming fast, watchdog is frequently reset
and never shows up anywhere. Everything is
On Mon, Jun 29, 2009 at 7:35 AM, Rajendra Nayakrna...@ti.com wrote:
The CPUidle C state latencies and thresholds are dependent
on various board specific details.
Hence this patch makes it possible to configure these values from the
respective board files.
Signed-off-by: Rajendra Nayak
Jon Hunter jon-hun...@ti.com writes:
Please find the update patch below.
Hi Jon,
What should this apply to? The patch you sent had some lines wrapped,
but even after unwrapping, it didn't apply to either the current PM
branch or pm-2.6.29.
Kevin
There are two scenarios where a race
Hunter, Jon jon-hun...@ti.com writes:
Hi Kevin,
Shouldn't you do a read-modify-write of I2C_CON_REG here? Otherwise,
you're loosing any of the other settings in I2C_CON_REG.
Not being an expert in the I2C hardware, I'm not sure if it matters,
but this doesn't seem quite right due to
Nayak, Rajendra rna...@ti.com writes:
Nayak, Rajendra rna...@ti.com writes:
From: Högander Jouni [mailto:jouni.hogan...@nokia.com]
ext Rajendra Nayak rna...@ti.com writes:
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF
should not be set together. The PRCM FSM has been
Rajendra Nayak rna...@ti.com writes:
The ONLP and ONOFF values programed for both VDD1
and VDD2 were not optimal.
New values used are
VDD1
ON - 1.2v
ONLP - 1.0v
ONRET - .975v
ONOFF - .6v
VDD2
ON - 1.15v
ONLP - 1.0v
ONRET - .975v
ONOFF - .6v
Signed-off-by: Rajendra Nayak
Rajendra Nayak rna...@ti.com writes:
This patch enables CONFIG_TWL4030_POWER in omap_3430sdp_pm_defconfig
and updates the sleep and wake sequence for 3430sdp.
Sleep sequence:
-1-Turn off HFCLKOUT
-2-Turn off Vdd1
-3-Turn off Vdd2
-4-Turn off VPLL1
Wakeup p3 sequence
-1-Turn on HFCLKOUT
Rajendra Nayak rna...@ti.com writes:
The clock stabilization delay post a M2 divider change is needed
even before a SDRC interface clock re-enable and not only before
jumping back to SDRAM.
Signed-off-by: Rajendra Nayak rna...@ti.com
Thanks, pushing to PM branch (and pm-2.6.29)
Kevin
---
On Monday 29 June 2009 16:51:07 ext Janusz Krzysztofik wrote:
I am not able to find any information on how DMA can be configured for CPC
to reflect either source or destination port address progress. Official
documentation, even if not very clear for me, seems to suggest that it
always follows
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, June 30, 2009 12:28 AM
To: Nayak, Rajendra
Cc: Kalle Jokiniemi; linux-omap@vger.kernel.org; Derrick,
David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle
before OFF,
48 matches
Mail list logo
